WebM support on 4chan(blog.4chan.org) |
WebM support on 4chan(blog.4chan.org) |
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.
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).
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".
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.
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/#...
APNG was still years away when Webkit was forked from KHTML. Webkit was so long ago that Firefox didn't exist, nor did "Mozilla Firebird", and IIRC nor did Phoenix.
_And_ sound, as evidenced by anybody who posts links to youtube or soundcloud, e.g., /a/ or /mu/. Having such functionality directly in 4chan uploads would further the goal of anonymous ephemerality/content creation better than links to other sites. I can see your point if by "4chan" you mean "moot and site admins" due to the copyright concerns, but my feeling from other anons is that audio support would be awesome overall.
>You haven't been on 4chan much, have you?
If the novelty truly never wore off, every gif would still turn into cheetus after the first frame, and every link to youtube would still be Rick Astley.
Plus, think of your argument if we already had audio webms for their legitimate uses and had never known restriction. Would you give up audio on all webms just because of an occasional "screamer"? Would you give up all images just because some anons occasionally post shock pictures?
Or people who post images that have audiodata hidden in them in increasingly sophisticated and hard to detect ways. /v/, /a/ and /mu/ have semi-regular sounds threads. I'm certain people will find a way to embed sound in video files in ways that can't be detected and update the media extension to handle those. We will have sounds one way or another.
These examples aren't actually gone, you know? Less common, certainly, but these trolling-memes don't really die out until there's something new to replace their exact use-case.
http://www.planet3dnow.de/vbulletin/showthread.php/406096-Be...
WebP is larger than APNG [1] and is supported more widely according to the following table [2]. There is a way to add compatibility to older browser too [3]. Other than that, there are also Opera [4] and Chrome [5] extensions for APNG.
Update: Found a successful APNG kickstarter campaign, which lists some interesting APNG tools and libraries. [6]
Also just tested myself how the filesize compares for different file formats able to host animated content for this source image [7].
gif – 679,6 Kb
apng – 547,1 Kb
mp4 – 273,8 Kb
webp – 618,9 Kb
---
[1] http://littlesvr.ca/apng/gif_apng_webp.html
[3] http://davidmz.github.io/apng-canvas/
[4] https://addons.opera.com/de/extensions/details/apng/?display...
[5] https://chrome.google.com/webstore/detail/apng/ehkepjiconegk...
[6] https://www.kickstarter.com/projects/374397522/apngasm-foss-...
[7] http://37.media.tumblr.com/70a88618cc58ac5ad670ab175f8a1419/...
I'd expect them to beat PNG with acceptable quality, since PNG's compression (gzip with some prefilters to make image data more gzippable) is the work of someone either limited by patents or not informed enough to make their own entropy coder.
Also try 'ffv1' in ffmpeg; it's lossless and will win every time.
Transcode a bunch of different-looking PNGs to a WebP losslessly, each pixel preserved exactly, and you'll see a byte savings in the neighborhood of 30%. Go lossy and much more savings, with the option of alpha transparency on lossy if you're into that.
It's not just efficiency, it's versatility that these formats bring to the table. Though the efficiency is compelling.
Second, that's a list of contributors to the "Google C++ Testing Framework", not WebM.
https://code.google.com/p/webm/source/browse/AUTHORS?repo=li...
People complain about it being closed but actually it is far more open on the hardware side since each of the big manufacturers are part of the H.264 process.
Pretty sure Firefox doesn't support H.264 out of the box on Linux, though. I couldn't wrangle the gstreamer plugin into displaying it either.
and
> Overall, VP8 appears to be significantly weaker than H.264 compression-wise.
don't seem to go very well together, to me. How can VP8 be a better H.264 and worse than H.264 at the same time?
