Live data from Hacker News

High quality GIF with FFmpeg

blog.pkh.me

81–90 of 131 posts

Re: High quality GIF with FFmpeg

#81
post #47

Earlier quoted context omitted.

Maybe someone who cares about this should submit patches? All of the major browser engines are open-source.

> All of the major browser engines are open-source. In a world where Internet Explorer is not a major browser.

Hah, I can't believe I actually forgot Internet Explorer was still around. Good point.

Re: High quality GIF with FFmpeg

#82
post #48
post #47

Earlier quoted context omitted.

Maybe someone who cares about this should submit patches? All of the major browser engines are open-source.

This would probably cause regressions with other GIFs that neglect to specify a delay but are supposed to have one. It's hard to imagine this universal behavior is accidental. It's probably like everything else on the Web — a hack to keep things that shouldn't work from actually not working.

Are there GIFs that specify a delay on some frames but not others, and expect all frames to have a delay? Because it should be easy to detect animated GIFs that specify no delay for any frame, and treat them all as having a delay.

Re: High quality GIF with FFmpeg

#83
post #82
post #48

Earlier quoted context omitted.

This would probably cause regressions with other GIFs that neglect to specify a delay but are supposed to have one. It's hard to imagine this universal behavior is accidental. It's probably like everything else on the Web — a hack to keep things that shouldn't work from actually not working.

Are there GIFs that specify a delay on some frames but not others, and expect all frames to have a delay? Because it should be easy to detect animated GIFs that specify no delay for any frame, and treat them all as having a delay.

As I understand it, that would still block this "large-palette GIF" trick, because those would also consist entirely of frames with no delay.

Re: High quality GIF with FFmpeg

#84
post #32

>As you probably know, GIF is limited to a palette of 256 colors. No, it's not. OK, the current, wrong, implementations do limit it to 256 colors, but that's not a limitation of gif. Mulitple frames without a delay allow multiple pallets and multiple times 265 colors. But this limitation is just another reason not to use it. Can I use Webm? http://caniuse.com/#feat=webm Yes, you can, and you should. Or h.264: http://…

While GIF is surely inferior to short looped videos, it's still ahead in terms of usability/portability: Drag & drop the file to the desktop and re-upload elsewhere (or embed in your own website). AFAIK this experience is unmatched by web video.

Yes, but the cost is tremendous. First there is the bandwidth. Next it's the hardware: Virtually all mobile Systems-of-a-chip have hardware support for JPEG, PNG, H264, etc decoding. Power-wise animated GIFs are terrible.

Re: High quality GIF with FFmpeg

#85
post #82
post #48

Earlier quoted context omitted.

This would probably cause regressions with other GIFs that neglect to specify a delay but are supposed to have one. It's hard to imagine this universal behavior is accidental. It's probably like everything else on the Web — a hack to keep things that shouldn't work from actually not working.

Are there GIFs that specify a delay on some frames but not others, and expect all frames to have a delay? Because it should be easy to detect animated GIFs that specify no delay for any frame, and treat them all as having a delay.

A workaround for the workaround: for a high-color gif, add a blank "animation" frame at the end that has a delay, after all the no-delay buildup elements.

However, that's unlikely to be necessary because if you are just doing a high-color image with no animation, you may as well use JPEG or PNG.

Re: High quality GIF with FFmpeg

#86
post #83
post #82

Earlier quoted context omitted.

Are there GIFs that specify a delay on some frames but not others, and expect all frames to have a delay? Because it should be easy to detect animated GIFs that specify no delay for any frame, and treat them all as having a delay.

As I understand it, that would still block this "large-palette GIF" trick, because those would also consist entirely of frames with no delay.

I assumed that the "large-palette GIF" would have animation. Otherwise, why are you bothering with tricky GIFs at all, why not just use a PNG (or JPEG, depending on the image type)?

Re: High quality GIF with FFmpeg

#87
post #70

There is no reason to create new content in .gif and not webm as of now. FFmpeg is really nice though.

I'm not going to tell you anything new here, but there are reasons to use GIF instead of video. WebM isn't supported on Safari & IE. H.264 isn't officially supported on Firefox (though I believe OS X and Window may now provide their own decoders that Firefox uses). To get a similar experience to GIF, you need two formats and it needs to be embedded in an HTML file using a tag. Compare that to the GIF experience, wher…

Actually, Firefox supports h264 nowadays. Cisco bought a license to the patent, and gave it to Mozilla for free, so they can freely distribute an h264 decoder.

Re: High quality GIF with FFmpeg

#88
post #61

Earlier quoted context omitted.

Unfortunately a VERY large chunk of the web still can't see webm. http://caniuse.com/#feat=webm

Doesn't IE use directshow filters for playback? As long as anything like ffdshow or lavfilters is installed it could just use those. Afaik firefox uses system-provided h.264 decoders to support that since they don't want to ship one with firefox.

Firefox ships their own decoder now, Cisco donated a license of the MPEG patents to Mozilla.

Re: High quality GIF with FFmpeg

#89
post #65

Earlier quoted context omitted.

While GIF is surely inferior to short looped videos, it's still ahead in terms of usability/portability: Drag & drop the file to the desktop and re-upload elsewhere (or embed in your own website). AFAIK this experience is unmatched by web video.

Global support for h.264 video in the browser: over 90%. And on the desktop it's close to 100%. That's IMO just good enough.

A large proportion of browsers won't auto-play video, but will auto-play GIFs, so that rules out many uses.

Also, I'd bet that video tags eat memory. A web page with ten animated GIFs might make the user puke, but a web page with ten auto-play videos will likely make the web browser puke :)

Re: High quality GIF with FFmpeg

#90
post #88
post #61

Earlier quoted context omitted.

Doesn't IE use directshow filters for playback? As long as anything like ffdshow or lavfilters is installed it could just use those. Afaik firefox uses system-provided h.264 decoders to support that since they don't want to ship one with firefox.

Firefox ships their own decoder now, Cisco donated a license of the MPEG patents to Mozilla.

I have been told that's only used for webrtc. playing tags uses ffmpeg on linux or media foundation on windows.
Post reply on HN