The general lack of adoption of animated png's is often pointed squarely on 4chan. Since it generated most of the web's viral funny content. And since most of it was in .gif, who needs to support .apng?
Hopefully we will see the opposite with WebM. More general funny content, more drive for it to be adopted on sites like reddit (which already to some extent uses gifcat on some subs), and imgur. Which will snowball its general adoption.
This is the most flattering thing I've ever read about 4chan.
H.264 versus WebM wasn't decided by Porn. BluRay versus HD-DVD wasn't either.
<video src="blah" autoplay loop controls>
<video src="blah" autoplay loop>
The commons reasons cited on 4chan are:
1. All videos with sound would be "screamers", where the audio would get really loud unexpectedly halfway through, as a simple troll.
2. 4chan is an _image_ board, not a video board.
3. the MPAA and other copyright holders would crush 4chan with DCMA takedown requests for audio.
I feel like (1) could be solved technically with auto-mute and/or a soundcloud-style visible meter, as well as the novelty eventually wearing off.
For (2), it seems that 4chan's main goal of ephemeral content/anonymity would overrule the historical precedent for content on the site (and already does, if /f/ is any indication). If it works for vine/snapchat, why not 4chan?
(3) though seems like the major issue, especially for +2 minute videos.
You haven't been on 4chan much, have you? I can promise you it would never get old. Anyway, what 4chan wants is basically better GIFs.
- at the start there is a stupid "fade in" effect.
- the loading animation does sometimes not disappear even though the video has fully loaded.
- the loading animation is generally annoying. Gifs just stop when bufffering and continue as soon as there is new data.
- a useless control bar shows at the bottom on hovering.
- Unlike gifs the video does not stop when you scroll beyond it which causes a huge amount of processor load.
Firefox's implementation of gifs isn't exactly sunshine and roses either. It appears to keep animating gifs in the background, even if they are in separate, not selected tabs. For one, you can see the tab icon animating pointlessly. More importantly, this uses up a surprising amount of CPU. All the time I hear my laptop's fans start whirring, and see that all of my cores are pegged at 20-40% (on a Sandy Bridge i5, mind you, not some toaster). When I realize that I have some gifs open and close those tabs, it immediately drops back down to a normal 0-2% usage idle.
This is only for non-embedded images. Also, I'm pretty sure this can be "fixed" with ease.
>- the loading animation does sometimes not disappear even though the video has fully loaded.
After viewing hundreds, if not thousands, of WebM files, I have never experienced this.
>- the loading animation is generally annoying. Gifs just stop when bufffering and continue as soon as there is new data.
Again, I have never seen this happen.
>- a useless control bar shows at the bottom on hovering.
Since when is being able to control playback useless?
>- Unlike gifs the video does not stop when you scroll beyond it which causes a huge amount of processor load.
Fair enough, but this will surely be implemented soon enough.
Starting in <https://bugzilla.mozilla.org/show_bug.cgi?id=963922>.
No it's not. I'm using nightly on linux so my experience may have differed somewhat, but 90% of gifs load just as fast or slower for me. Ever since I started seeing webM videos appear online I've enjoyed them immensely more than youtube videos or gifs because of the quality and loading times (they usually start immediately), and the fact that they're usually very short which forces them to be packed with the most in-demand content, but can be longer than a gif if need be. I'd take a webM over a gif any day of the week.
edit: and I'm running Ubuntu 14.04 on a laptop with an intel core i5 and integrated graphics and not experiencing any problems, but I'm also closing the videos after I watch them. The fact that they don't pause/stop when you scroll is kind of a minor bug that can be fixed pretty easily.
I'm glad to see WebM happening.
Not stopping is probably a feature; if it's music playing it should keep going. But it could stop rendering / taking up much cpu if not in view, I guess.
My use case is to have the best performance/quality ratio for a 30 second video under 3mb.
These are my ffmpeg flags:
h264: "-vcodec libx264 -crf 28"
webm: "-c:v libvpx -qmin 0 -qmax 50 -crf 5 -b:v 1M -c:a libvorbis -aq 4"
The video I tested with these setting last night took 5 seconds on h264 and 35 seconds for webm, both outputting to a 2.6mb file.
System Specs: - Intel Core i7 4770 Quad-Core 3.4GHz - 16gb 1866mhz memory - ssd drive - 64bit ubuntu 12.04 lts
What further frustrates this is that I can use OpenCL to improve encoding times even more, but only with h264 in ffmpeg (as far as I know).
Encoding WebM videos seems really slow. What are you doing about that?
Today, encoding VP8 in “best quality” mode is the slowest configuration. Using “good quality” mode with the speed parameter set between 0 and 5 will provide a range of speeds.
"Overall, VP8 appears to be significantly weaker than H.264 compression-wise. The primary weaknesses mentioned above are the lack of proper adaptive quantization, lack of B-frames, lack of an 8×8 transform, and non-adaptive loop filter. With this in mind, I expect VP8 to be more comparable to VC-1 or H.264 Baseline Profile than with H.264. Of course, this is still significantly better than Theora, and in my tests it beats Dirac quite handily as well.
...
Finally, the problem of patents appears to be rearing its ugly head again. VP8 is simply way too similar to H.264: a pithy, if slightly inaccurate, description of VP8 would be “H.264 Baseline Profile with a better entropy coder..."
I won't pretend to know what all of those terms mean off the top of my head, but if the lead x264 developer sees absolutely no technical advantage in WebM vs. h264, that sounds pretty damning to me.
As for why x264 encodes h264 so much faster than ffmpeg or whatever encodes WebM, the simplest explanation would be that there is much greater demand for an optimized h264 encoder. WebM has some admittedly large users (Wikimedia Foundation, Youtube for browsers with no h264 support and no flash player, and now 4chan), but they're still vanishingly small in comparison to the users of h264 ("the entire video industry").
I did try dropping the quality significantly with my webm profile, but it had a trivial performance improvement.
I am generally batch encoding thousands of short videos, so I just run the encoder in single thread mode, and create a queue for each core.
IME, VP8 is about half as fast as x264. If you are trying to encode a single video on a 24 core server, then it is about 20 times slower than x264.
1 - http://www.compression.ru/video/codec_comparison/h264_2012/#...
https://code.google.com/p/webm/source/browse/third_party/goo...
Edit: Thread 2 (Yeah, 4chan, possibly probably nsfw, etc): http://boards.4chan.org/g/res/41215438#p41215438
But imgur support would really drive the replacement of GIFs with HTML5 video mainstream, if/when it arrives.
And you need to disable HTTPS Everywhere for blog.4chan.org since Tumblr doesn't support HTTPS :(
Edit: I just noticed moot's comment about disabling HTTPS Everywhere. The XML has an exclusion for "status" but not "blog". I'll send a pull request.
WebP however for some reason hasn't gained as much traction as WebM. Firefox refuses to merge support, despite the fact it leverages the same library is WebM. I'd like to see WebP gain support more than WebM, Google's mod_speed converts images to WebM if using the Chrome browser to save on bandwidth.
I'd prefer to set some option of "free codecs first".