Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Twitter's GIF hack

blog.embed.ly

Post reply on HN
Print view View original

61–70 of 160 posts

Re: Twitter's GIF hack

#61

Post by viggity »

stonogo wrote: post #23
kintamanimatt wrote: post #19

Earlier quoted context omitted.

You choose not to use the appropriate software to experience what is being offered. This is akin to riding a decrepit horse on a racetrack while whining about how everyone else that is riding a healthy horse is going faster and having a better experience than you. Just upgrade.

Your analogy is stupid and your comments are not helpful. I'm not modifying 3,600 workstations because some web programmer decided to mangle user-uploaded content without doing fundamental work to ensure graceful degradation.

you're seeing that because they wanted to show you what it looked like as an MP4. My understanding was that twitter would ship you the GIF if your browser didn't support MP4.

Re: Twitter's GIF hack

#62

Post by chc »

smackfu wrote: post #49
chc wrote: post #34

Earlier quoted context omitted.

Are you saying that WebM, a file format introduced in 2010, is less bleeding-edge than H.264 MP4, a file format introduced in 2003? What definition of "bleeding-edge" are we using here?

The introduction date of the format doesn't seem very relevant, since what we are talking about is native inline browser support.

Same story. Most browsers supported H.264 first (because it was dominant before WebM was even born). Internet Explorer, Safari and MobileSafari still do not support WebM. I don't see any reasonable way to say that WebM is well-established and H.264 is not.

Re: Twitter's GIF hack

#64

Post by rudog »

We've been doing that at my company on our mobile applications for a few years now. There is no reason to be shoving 5-10mb GIFs down a users throat on a mobile device. Not only does are MP4s smaller (file size), frames per second will be constant on all browsers, unlike GIF (although most browsers are supporting up to 50fps these days). Although outdated, you can read more about that here. http://nullsleep.tumblr.com/post/16524517190/animated-gif-mi...

I wrote a simple js lib for detecting the duration of a GIF for each browser. It was a fun weekend project. https://github.com/rfrench/gify

If webp gains more adoption, it's another alternative now that it supports animation.

Re: Twitter's GIF hack

#65

Post by brigade »

mikeash wrote: post #53
anon4 wrote: post #48

Earlier quoted context omitted.

Not quite true yourself :). GIFs store deltas, true, but they are still raster images. H.264 on the other hand contains specific techniques for compressing sequential frames, including things like recording only pixel motion for some frames. You can see it in those "corrupt movies" gifs (which on twitter would be mp4s... talk about irony) where you take a clip and remove some keyframes from it - then transformations…

Just a nitpick, JPEG always encodes the color channels at half resolution. It's amazing how difficult it is to notice this, though.

No, there are 4:4:4 and 4:2:2 modes in JPEG.

H.264 also defines such modes, but no consumer hardware decoders support them so they aren't commonly used.

Re: Twitter's GIF hack

#67

Post by skrowl »

discreditable wrote: post #66
bluedino wrote: post #11

Haven't things like gfyCat been doing HTML5 video from GIF's for a while?

In a way they're doing it better. Twitter only seems to support MP4 whereas gfycat et al will deliver WEBM or MP4 based on the user's browser.

Agreed. MP4 doesn't work on Firefox (out of the box).

Re: Twitter's GIF hack

#68

Post by ars »

protopete wrote: post #30

Unfortunately the MP4 looks worse than the GIF, due to chroma compression in the YUV 420 colorspace. While each pixels luminance value is kept, the color information for a 4-pixel square is stored as a single CrCb pair, which is really obvious when you look at how the orange hat has artifacts against the blue background. Increasing the bitrate won't solve this either, since it's a limitation of the colorspace.

> Increasing the bitrate won't solve this either, since it's a limitation of the colorspace.

You can encode at 4:4:4 if you want, although obviously you have no control over what twitter does.

Re: Twitter's GIF hack

#69

Post by ferongr »

protopete wrote: post #30

Unfortunately the MP4 looks worse than the GIF, due to chroma compression in the YUV 420 colorspace. While each pixels luminance value is kept, the color information for a 4-pixel square is stored as a single CrCb pair, which is really obvious when you look at how the orange hat has artifacts against the blue background. Increasing the bitrate won't solve this either, since it's a limitation of the colorspace.

Or alternatively browsers could use non-terrible chroma upsampling algorithms.

http://screenshotcomparison.com/comparison/79805

Re: Twitter's GIF hack

#70

Post by gdulli »

Is there a flash blocker solution that removes all traces of the page element rather than leave an ugly placeholder? It's going to be annoying to see this on Twitter from now on.
Post reply on HN