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

High quality GIF with FFmpeg

blog.pkh.me

Post reply on HN
Print view View original

101–110 of 131 posts

Re: High quality GIF with FFmpeg

#101

Post by voltagex_ »

1ris wrote: post #79
wukerplank wrote: post #69

Earlier quoted context omitted.

That's not what I was referring to. Yes, technically videos are superior, no doubt. The nice thing about GIFs is though that they are treated like images by the browser and the OS. That makes them easier to handle by non-technical users (think imgur, Tumblr, etc.).

I just realised that imgur does not support webm. I thought it does. Thats kind of stupid. For other websites it'd be as simple as adding a mime type to the list of accepted uploads. Unfortunalty you are right, right now webm is still exotic.

The silly thing is if you have a gif and change the URL on imgur to read ".gifv" you'll get WebM!

Re: High quality GIF with FFmpeg

#102

Post by [deleted] »

JoshTriplett wrote: post #98
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

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

[deleted]

Re: High quality GIF with FFmpeg

#103

Post by barrkel »

dublinben wrote: post #35
IgorPartola wrote: post #20

Earlier quoted context omitted.

If only iOS (and Android?) allowed you to play inline videos the way you can on the desktop, and the way they play animated GIF's inline. Besides allowing us to adopt video throughout and save on bandwidth and have better video quality, this will be a huge productivity boost to developers: we can finally stop having the GIF vis JIF pronunciation debate.

Firefox on Android plays inline videos just fine. Sites like GFYcat work as expected, and loop appropriately.

Much to my annoyance. I desire to disable all autoplay of all inline videos across all browsers on my phone. Quite difficult to achieve.

Re: High quality GIF with FFmpeg

#104

Post by Pephers »

This is pretty cool. I use GIFs for marketing for my SaaS startup[1] because it has the best support for autoplaying across devices, but the file sizes are a bit high (690 KB and 270KB for screencasts of a few minutes each). I use licecap[2] for recording and Gifsicle for optimizing, but perhaps I should give ffmpeg a go and compare the results.

[1] https://zapla.co

[2] http://www.cockos.com/licecap/

Re: High quality GIF with FFmpeg

#105

Post by Springtime »

1ris wrote: post #79
wukerplank wrote: post #69

Earlier quoted context omitted.

That's not what I was referring to. Yes, technically videos are superior, no doubt. The nice thing about GIFs is though that they are treated like images by the browser and the OS. That makes them easier to handle by non-technical users (think imgur, Tumblr, etc.).

I just realised that imgur does not support webm. I thought it does. Thats kind of stupid. For other websites it'd be as simple as adding a mime type to the list of accepted uploads. Unfortunalty you are right, right now webm is still exotic.

I've seen WebMs on Imgur. When saved and opened to check the encoding some are VPx, while others are h.264 encoded in a WebM container.

I can probably find some links later. As I see no option to upload video directly I'm wondering if it requires an account, or whether it was their new(ish) GIF conversion process (IIRC some look like original videos though).

Re: High quality GIF with FFmpeg

#106

Post by AlwaysBCoding »

dublinben wrote: post #10
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

Yes please. Let's leave GIF in the 20th Century, where it belongs.

AFAIK the Apple Watch doesn't support video of any sort, so if you want to get moving pictures on your watch the gif is the only way. Gif is about to make a comeback if anything.

Re: High quality GIF with FFmpeg

#107

Post by xai3luGi »

JoshTriplett wrote: post #98
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

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

Seems unlikely that the security team would be happy having both ffmpeg and libav in Debian, so a GR would be needed to override them.

Re: High quality GIF with FFmpeg

#108

Post by dilap »

1ris wrote: post #65
wukerplank wrote: post #62

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.

GIF autoplays inline in the page. Video doesn't (it animates on tap w/ all other content obscured). (On the iPhone, anyway.)

Makes it completely unsuitable for many uses of GIF.

Would love to be wrong or out of date on this, so feel free to let me know if I am ;)

Re: High quality GIF with FFmpeg

#109

Post by kevin_thibedeau »

JoshTriplett wrote: post #98
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

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

There are a number of useful codecs and filters that have non-free licenses. Debian packages will never have them enabled. Self compiles are the only way to get the ffmpeg kitchen sink.

Re: High quality GIF with FFmpeg

#110

Post by derf_ »

pornel wrote: post #100
derf_ wrote: post #72

Earlier quoted context omitted.

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 looku…

> However, Wu's method needs lookup tables for the whole color (hyper)cube,

You're talking about the 1991 method. The 1992 paper I cited explicitly claims as one of its advantages that it does not require lookup tables (and thus avoids the usual step of pre-quantizing down to 5 bit color to get a reasonably-sized table).

Your two big wins sound an awful lot like "K-means". I'd believe they are responsible for the bulk of the improvement (they're also the bulk of the computation), but they mean you don't have axis-aligned partitioning anymore, which was my point.

The problem is that K-means is notoriously sensitive to the initial clustering. For unsupervised learning, I'd want to do as good a job there as possible, and applying PCA means you are picking the split direction that exactly minimizes variance in the orthogonal directions. Random restarts are also a nice way to escape local minima, but are even more expensive computationally.

Post reply on HN