High quality GIF with FFmpeg • Hacker News Board

Re: High quality GIF with FFmpeg

#91

Post by joosters » Tue, Mar 17, 2015, 1:09 AM UTC

imaginenore wrote: post #6

And to complete the circle, run the gif through Gfycat and check out the mindblowing bandwidth savings: http://gfycat.com/IllustriousHairyGermanpinscher GIF: 1 MB Video: 73k

It is technically possible to do both directions of the GIFvideo conversion on-the-fly at all points of the network. Web servers could deliver/generate video files for clients that request GIFs, transparent proxies and caches could grab the video files and translate back to GIFs for dumb clients, and browser plugins could seamlessly replace GIFs on a page with the video files.

In fact, behind the scenes this might be happening now - technically your ISP could be doing this and the 1MB GIF you download has been reconverted from a video file back into a GIF at your local proxy cache!

Re: High quality GIF with FFmpeg

#92

Post by bigboat » Tue, Mar 17, 2015, 1:12 AM UTC

ux wrote: post #15

artursapek wrote: post #3

I use this shell script for generating gifs out of .mov files: https://gist.github.com/artursapek/5b3d15ecac5ff75593c4 I can probably improve it further by using some of what's in this article, but it's already faster and better than any online tool I've found.

> (convert -delay 5 -loop 0 $tmp_dir/ffout*.png $2) >& /dev/null So using ImageMagick for this... How is this memory wise BTW? (all frames are in memory at once or not?)

Yes, all frames will be in memory prior to making the GIF. Probably fine for most GIFs, but if you want to go FFmpeg | ImageMagick | FFmpeg for processing a video, or maybe for a longer GIF, you can use this script to keep only a frame at a time in memory: http://www.imagemagick.org/Usage/scripts/process_ppm_pipelin...

Re: High quality GIF with FFmpeg

#93

Post by ChrisLomont » Tue, Mar 17, 2015, 1:12 AM UTC

1ris wrote: post #38

ux wrote: post #34

Earlier quoted context omitted.

Can you show an example of an animation with more than 256 colors? As you said, the hack to get more than 256 colors is to redefine a sub rectangle with a new palette. But that's also the mechanism used to make animations. Are you able to get fluid playback with that? Note: I'm not talking about new frame being just a new sub rectangle, more about N sub rectangles for the same frame, then a delay event, then M sub re…

None that works with current browsers implantations, because they erroneous ignore no delay between frames and wait anyway. But that's a bug in the gif decoder, not a limitation of gif. OK, this is hairsplitting, but it illustrates how borken the state of gif is.

Actually, regarding the delay, the spec reads

    "vii) Delay Time - If not 0, this field specifies the number of hundredths (1/100) of a second to wait before continuing with the processing of the Data Stream. "

A zero delay is most certainly not covered by the spec, and anyone using one is creating GIFs that do not meet the spec.

[0] http://www.w3.org/Graphics/GIF/spec-gif89a.txt

Re: High quality GIF with FFmpeg

#94

Post by neeee » Tue, Mar 17, 2015, 1:13 AM UTC

Gifsicle is very good at making highly optimized GIFs, but slightly more cumbersome as you have to convert each frame to a separate image first.

http://www.lcdf.org/gifsicle/

Re: High quality GIF with FFmpeg

#95

Post by scrollaway » Tue, Mar 17, 2015, 1:13 AM UTC

joosters wrote: post #89

1ris wrote: post #65

Earlier quoted context omitted.

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 :)

> I'd bet

No, you're wrong. You have this preconception that videos are obligatorily 300 megabytes or something.

There's virtually no reason for in-hardware decoding of a smaller file to make the browser struggle more than with gifs, which are much less optimized and never in-hardware.

Re: High quality GIF with FFmpeg

#96

Post by [deleted] » Tue, Mar 17, 2015, 1:32 AM UTC

amelius wrote: post #64

dangerlibrary wrote: post #7

ffmpeg is downright magical - just don't get caught using the one in the Ubuntu/Debian repositories. Compile your own ffmpeg if you have any need to do serious work; the Libav fork just isn't as capable. The reasons are obvious if you look into the development philosophies of the two projects. https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav

> ffmpeg is downright magical Actually, in my experience, ffmpeg is the linux-program that by far outshines any other program in... failing or crashing :/ I'm sorry to say this. And, unfortunately, there isn't any other open source program doing a better job in terms of file format support.

[deleted]

Re: High quality GIF with FFmpeg

#97

Post by pornel » Tue, Mar 17, 2015, 1:36 AM UTC

quotedmycode wrote: post #12

So it's using a simple Median Cut quantization... which is okay, but you can get great results using an octree quantizer, and without dithering. Dithering kills your compression savings in GIF so you'd want to avoid it if possible. In any case, you can see the difference a better quantizer makes here: http://www.leptonica.com/color-quantization.html

If you want high-quality palette try libimagequant: http://pngquant.org/lib

pngquant's method is superior to octtree:

• it uses Voronoi iteration to get local minimum and minimize effects of axis-aligned subdivisions

• it uses sort-of gradient descent to optimize subdivisions

• to some degree edges and noise are included in histogram weights

• does not need to throw away any bits of precision (most implementations just naively discard 2-3 bits, because of RAM limits in '80-'90s)

pngquant undithered:

http://i.imgur.com/fOkZDjA.png

vs leptonica's:

http://www.leptonica.com/figs/tree-nodither.jpg

Re: High quality GIF with FFmpeg

#98

Post by JoshTriplett » Tue, Mar 17, 2015, 1:42 AM UTC

jamiesonbecker wrote: post #55

dangerlibrary wrote: post #7

ffmpeg is downright magical - just don't get caught using the one in the Ubuntu/Debian repositories. Compile your own ffmpeg if you have any need to do serious work; the Libav fork just isn't as capable. The reasons are obvious if you look into the development philosophies of the two projects. https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav

Use the version at http://deb-multimedia.org echo "deb http://www.deb-multimedia.org stable main non-free" > /etc/apt/sources.list.d/deb-multimedia.org.list apt-get -q update; apt-get -qy dist-upgrade apt-get -qqy install ffmpeg

Debian unstable has official ffmpeg packages, and as soon as the next release completes, those packages will migrate to testing and future stable.

Re: High quality GIF with FFmpeg

#99

Post by ars » Tue, Mar 17, 2015, 1:49 AM UTC

lozf wrote: post #75

jamiesonbecker wrote: post #55

Earlier quoted context omitted.

Use the version at http://deb-multimedia.org echo "deb http://www.deb-multimedia.org stable main non-free" > /etc/apt/sources.list.d/deb-multimedia.org.list apt-get -q update; apt-get -qy dist-upgrade apt-get -qqy install ffmpeg

I always build my own as, afaik, it's the only way to get full support for the more interesting codecs e.g. fdkaac & h265.

You can ask him to add them, he's pretty responsive to requests.

Re: High quality GIF with FFmpeg

#100

Post by pornel » Tue, Mar 17, 2015, 1:52 AM UTC

derf_ wrote: post #72

quotedmycode wrote: post #12

So it's using a simple Median Cut quantization... which is okay, but you can get great results using an octree quantizer, and without dithering. Dithering kills your compression savings in GIF so you'd want to avoid it if possible. In any case, you can see the difference a better quantizer makes here: http://www.leptonica.com/color-quantization.html

Any method that makes axis-aligned subdivisions (which includes both standard median cut and octree), even in a space like HSV, is going to be pretty suboptimal. There's probably been more sophisticated things done since I looked at this in the 1990's, but Xiaolin Wu's 1992 approach [1] works quite a bit better than both (including the 1991 Wu v2 implementation of an octree method linked elsewhere in this thread). It…

Aligned subdivisions are not that much of a problem actually.

I've tested median cut that can cut at various angles and variants that cut out spheres, and it didn't make much difference.

Choice of the box to cut and the location where you cut is more important. Wu's method is nice in this case because it exactly measures variance of sets after a split, while median cut just estimates.

However, Wu's method needs lookup tables for the whole color (hyper)cube, which requires either large (or for RGBA still ridiculous) amount of RAM or reduced precision, and losing bits of input is way worse than having suboptimal division.

The biggest wins I've found (and implemented in libimagequant) were:

• Voronoi iteration after generating palette (like a final step in LBG quantization). This shifts axis-aligned subdivisions to local optimum (I've tried applying that after every subdivision, but it didn't matter — once in postprocessing is enough!)

• Adjust weights/counts in histogram from quality feedback measured from remapped image. If you're aiming to minimize MSE, then that's not too expensive and it's similar to gradient descent.