WebM support on 4chan | Hacker News Reader

WebM support on 4chan

blog.4chan.org

229 pointsivarious98 comments

This is a very big moment for WebM. I feel 4chan has become the 'porn' industry of the internet. With VHS vs Betamax the largely deciding factor was which standard porn supported (this was again to a lesser extent with bluray).

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.

> I feel 4chan has become the 'porn' industry of the internet.

This is the most flattering thing I've ever read about 4chan.

It's kind of hilarious how much easier it is to summon moot on HN than on, say, 4chan.

HN is pseudonymous, 4chan is mostly anonymous. Probably moot simply isn't a tripfag.

Porn industry? Isn't 4Chan an ocean of something or another?

I'd say Google has its own share of responsibility for the lack of adoption of APNGs. Chromium doesn't support them out of the box.

I suppose because that requires using libapng instead of libpng, maybe?

APNG support can be implemented on top of regular libpng. I have the working code.

You really shouldn't blame google, but blame KHTML (who's code base was forked to develop Webkit, and then Blink). KHTML didn't move to support apng until 2010-2011 which was a few years after the webkit fork.

So to get this straight, we should blame the KHTML devs for adding a feature after Google forked it's code? While not blaming Google for never adding the feature?

uh hwat?

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.

I just saw a one-minute porn WebM on /gif/. This is unbelievably great.

When is this "Porn decides video formats" argument going to die ?

H.264 versus WebM wasn't decided by Porn. BluRay versus HD-DVD wasn't either.

I doubt that it really won the VHS/BetaMax war either.

More details here: http://blog.4chan.org/post/81896300203/webm-support-on-4chan

Nice to see this rolled out. In the notes it's mentioned that you won't offer a fallback. Was this a bandwidth consideration or that you decided simply not to try and support the remaining 14%? Or that you didn't want to maintain the infrastructure for transcoding the fallback file. In my experience at work I've found that whilst webm is generally smaller the difference is minute especially when you are dealing with files as small as 3MB.

We don't have the resources to support transcoding, and since so much of our userbase is on browsers that support it I don't think we would regardless.

Not sure how you're going to solve the WebM hosting issues, but I would be really curious to see a list of issues large sites like 4chan have. I think me and other people would surely like to solve such «sysadmin/developer puzzles» for fun.

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

(sorry, have no webm converter here)

---

[1] http://littlesvr.ca/apng/gif_apng_webp.html

[2] http://caniuse.com/apng

[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/...

WebP/M and H.264 are lossy formats, so any comparison citing one ultimate filesize for them is nonsensical.

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.

Lossy and lossless.

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.

You probably know this but the blog breaks with https everywhere.

Tumblr doesn't support HTTPS, unfortunately. HTTPS Everywhere will need to update the 4chan config to account for it.

Are you going to be using this tumblr blog instead of /news from now on?

Not instead of, but in addition to: http://blog.4chan.org/post/81891220996/reintroducing-the-4ch...

Moot, fix the mime type of those pages. On Android it opens the new url on the browser and only when the browser got the file header it calls the video app to start the download again. I'm pretty sure there are ways for the link to go directly to the video app

We already send the proper MIME type:

  Content-Type: video/webm

Android is dumb then... Not surprised.

IIRC Android matches on the file extension in the URL...

Looks like they are in a freeze period waiting for a stable release and won't touch any rules for the time being. Happy regular expression fun times ahead.

I think it'll be in the new release; there was a ruleset freeze to work out kinks for quite some time.

Hey, could I suggest something? For the inline expansion, it would be neat if it played automatically without needing to click, just like an animated GIF:

  <video src="blah" autoplay loop controls>

You could also maybe hide the controls, they can be distracting (you could always add an option to enable them):

  <video src="blah" autoplay loop>

EDIT: Thanks for fixing it!

Clearly the better URL for HN, so I changed it.

Thanks Dan!

Why isn't it possible to play the video inline?

Click settings, then choose Inline Expansion or Image Hover.

What other reasons were there to limit videos to 2 minutes, without audio? They certainly aren't technical limits.

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.

>as well as the novelty eventually wearing off.

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.

>what 4chan wants is basically better GIFs.

_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?

> as evidenced by anybody who posts links to youtube or soundcloud

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.

>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.

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.

WebM is clearly a far inferior experience compared to gif on firefox:

- 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.

Hey, I think that a scroll bar is a feature, not a bug. Also, I'm pretty sure now that there's finally some traction happening for HTML5 video, Firefox may now improve the experience.

I'm glad to see WebM happening.

Don't think that's webm specific, just firefox's implementation thereof. I do agree though, they should just play.

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.

>- at the start there is a stupid "fade in" effect.

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.

> Fair enough, but this will surely be implemented soon enough.

Starting in <https://bugzilla.mozilla.org/show_bug.cgi?id=963922>.

Yeah, expanding WebMs inline is probably not the smartest idea. Someone made a video of them browsing a WebM thread in Firefox with the task manager, and Firefox swiftly growing in the gigabytes of memory usage until it ran out of address space (Firefox is still 32-bit only on Windows) and crashed. They will probably need to change the inline extension to automatically close videos after some limit has been reached.

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.

>WebM is clearly a far inferior experience compared to gif on firefox

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.

Take a look at gfycat: http://gfycat.com/CheapDecisiveChipmunk 30MB gif is a 17MB video that you can pause, resize, slow up/down. No fade No loading animation No bar

Has anyone had experience optimizing for webm? I really want to support this codec, but it's insanely slow in my experience. I'm finding that it's generally around 4x slower than mp4, but I've also had cases where it's taken up to a minute to encode a file where h264 take under 10 seconds.

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

I don't know the details, but how is the quality on both? I can image that webm takes longer, but if it creates a file that has a higher visual quality for the same filesize that is great. I think nearly all streaming providers would take an increase in processing time for a decrease in bandwith, while quality stays the same..

They are of comparable quality. I find the h264 slightly better, but I have not done extensive testing.

I did try dropping the quality significantly with my webm profile, but it had a trivial performance improvement.

My hypothesis for the performance disparity is that h264 encoding is hardware accelerated and webm is not.

x264 does not use GPU hardware, so they're both using just the CPU. WebM fails to use more threads or 256bit or 128bit registers correctly.

recent versions of x264 do use GPU hardware via OpenCL, but the performance gain is questionable.

http://www.planet3dnow.de/vbulletin/showthread.php/406096-Be...

I'm pretty sure h264 is the superior codec in all regards except for that pesky license issue. It encodes faster and creates smaller files that look better. From (lead x264 developer and HN user) DarkShikari[1]:

"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").

[1] http://x264dev.multimedia.cx/archives/377

> a pithy, if slightly inaccurate, description of VP8 would be “H.264 Baseline Profile with a better entropy coder..."

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?

H.264 Baseline Profile

https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Profiles

H.264 defines a number of profiles and levels that define the acceptable tools from the overall suite that a conforming decoder implementation can rely on. "Baseline" uses very few of these tools, relative to the more sophisticated profiles.

Oh, I didn't know about that, thanks!

I think you are underplaying the support of H.264. Almost every single camera (video or photo), console, handheld device, browser, editing tool, effects tool, phone, tablet, OS, digital video player, website available today supports H.264.

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.

If I came across as downplaying the adoption of H.264, it wasn't my intent.

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.

h.264 has several profiles. Support for particular profiles in hardware varies. If you want to do low latency encoding with a hardware "h.264 encoder" for video conferencing you may find that you're out of luck. Since there is only one VP8 profile, hardware VP8 means hardware VP8.

I was under the impression that one is hardware accelerated while the other is not?

While some systems do have H.264 encoders, bstar77 is using x264 which runs only on the CPU and produces much higher quality output than any hardware encoder[1].

1 - http://www.compression.ru/video/codec_comparison/h264_2012/#...

Regarding speed, I've had experience with very large batch WebP conversions, and I know firsthand that encoding speed has improved dramatically over time. Perhaps the same may happen with WebM.

WebM FAQ

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.

The last time I did any testing was about 6 months ago, but libvpx is terrible at multi-core. x264 scales pretty much linearly with more cores.

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.

Any reason to not support h264, which seems to have similar levels of browser support? (trades Firefox on Linux/OS X/WinVista for support on IE/Safari/iOS/Android)

Probably he cares about software freedom?

Then why would 4chan be not free?

WebM is not free. It is controlled by a single company.

https://code.google.com/p/webm/source/browse/third_party/goo...

First, free software can be developed by one entity, or even one person.

Second, that's a list of contributors to the "Google C++ Testing Framework", not WebM.

Third, the AUTHORS file for libvpx lists people from nVidia, Opera, Broadcom, and many other non-Googlers.

https://code.google.com/p/webm/source/browse/AUTHORS?repo=li...

That trade might not be equal. As it is, the second one there according to the article only makes up 14% of traffic. I've got to imagine that Firefox makes up a significant portion of the 86% left. Couldn't guess about the platforms though.

Awesome! I'm still waiting for other sites like imgur to get with the program :D

Edit: Thread 2 (Yeah, 4chan, possibly probably nsfw, etc): http://boards.4chan.org/g/res/41215438#p41215438

https://mediacru.sh (I helped make this)

There's also http://gfycat.com, which seems fairly popular on reddit. And there's https://vine.co, too, though it's aimed at a different niche.

But imgur support would really drive the replacement of GIFs with HTML5 video mainstream, if/when it arrives.

OP's link is 404ing and moot's won't connect at all for me. There's no way HN took down 4chan. Anyone have additional info/a mirror?

The thread just got deleted, a new one here: http://boards.4chan.org/g/res/41216692

HN mods should probably update the submission URL to this one: http://blog.4chan.org/post/81896300203/webm-support-on-4chan

And you need to disable HTTPS Everywhere for blog.4chan.org since Tumblr doesn't support HTTPS :(

That link doesn't work either: Firefox can't establish a connection to the server at blog.4chan.org.

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.

The link works for me on Firefox Nightly (yesterday's update).

Tumblr does support HTTPS, just not by default yet.

WebM is a fantastic step forward. I prefer gfycat links over imgur gifs when browsing reddit (gfycat is a service that converts gifs to WebM). It does have minor teething problems (controls, loading animations, etc) but its advantages outweigh its negatives.

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.

Gyfycat does not use WebM, it uses mp4:

http://gfycat.com/about

They have both

http://gfycat.com/CheapDecisiveChipmunk.webm

http://gfycat.com/CheapDecisiveChipmunk.mp4

One problem I have is that there is no way to set format priority which would override page order. And because of some Apple's stupid bugs in Safari most pages list mp4 first. Current Firefox already supports mp4/H.264 through gstreamer, so it always picks that first even if WebM is available.

I'd prefer to set some option of "free codecs first".

Where can I go download a plugin for Safari on OS X?

It doesn't autoplay.

Why not use a <video> tag with the 'loop' attribute to better simulate animated GIFs?

and then, instead of using a browser, use a platform specific app. Persist user agent data so you can remove the captcha, and it will be just like the original 4chan.

I think Apple refuses to approve any 4chan apps for iOS.

It does use it. You need inline expansion or image hover enabled in settings though - 4chan has traditionally had minimal or no Javascript and this is an artifact of it.

It didn't when I wrote that comment. It works much better now.

And turn off video controls. They get in the way and lack of them never hurt gif.

Some browsers keep playing the video after you scroll past. Being able to stop it using the controls is valuable.

Hmm... the video controls only appear when I hover above the video, atleast on the 5 or so webm files I tried on 4chan just now.

Please don't. gifs are constrained by file size and usually 10-20 seconds or less. When you approach the minute range being able to navigate through rather than watching the whole thing again becomes valuable. Thankfully there's no sound, so at least there's no issue with volume levels.

Reply on news.ycombinator.com