Why we chose to move to HTML5 video | Hacker News Reader

Why we chose to move to HTML5 video

code.facebook.com

76 pointsel_duderino51 comments

Very very late for a company like Facebook. I'm not sure they needed a blog post to explain such an obvious move.

It looks like they decided to go all for HTML5 at once and avoid having to live with both Flash and HTML5 support with the cost associated to it (maintenance, support, etc.).

They still seem to use a flash version for some browsers:

> That's why we waited until recently to ship the HTML5 player to all browsers by default, with the exception of a small set of them.

Then definitely no excuse :)

"Why I decided to stop slamming my hand in a car door."

"When we shipped the HTML5 player, we noticed that on average it took slightly longer for Facebook to load. By fixing several small performance regressions and making multiple micro-optimizations, we finally reached a level we felt happy with shipping."

The way that's worded, it sounds like Facebook with HTML5 video is still slower to load than it was with Flash. This is really surprising... Would love to read details on that. Do they mean loading a link to a video, or to the general News Feed?

I'm fairly sure it means the entire page. I recently attended a talk given by Mike Magruder about (mobile) performance at Facebook, and a lot of it involved testing the impact of changes on the overall speed of the entire product, this uses the same language, ie referring to Facebook directly when talking about speed.

Just a wild stab in the dark on the cause, but maybe a contributing factor is devices that wouldn't load Flash at all take a speed hit from trying to load HTML5 video and the supporting scripts, or maybe the browser doing more heavy lifting rather than offloading it to a plugin?

Well the answer's pretty obvious in 2015, but 'The challenges we had to overcome' section is pretty interesting.

Finally. Ever since I removed the flash plugin around a year or two ago, Facebook and Vimeo videos are the only things I regularly encounter that I can't play.

The BBC still uses flash for TV and radio, which is a real shame and I think is the only thing I still need Flash for.

They're trailing HTML5 I believe: http://www.bbc.co.uk/html5

Be an ipad (by spoofing your User-Agent header)

https://news.ycombinator.com/item?id=10298240

Wow! It even works for live radio, which they say HTML5 doesn't! Why isn't this the default?

http://isebaro.com/?ln=en The ViewTube and SaveTube userscripts let you get around not using flash.

The Vimeo player defaults to HTML5 (since Jan 2014): https://vimeo.com/player

Interesting. I went to Vimeo to check it was still the case just before I posted my comment and I got an error message about my setup.

twitch.tv doesn't work without flash either

Yeah, this is the last holdout for me.

I created an website that shows 100+ short small videos on a page. I tested it with common browsers on various platforms. And decided to load only the first 5 videos as HTML5 videos and show the rest as animated GIFs. The optimized GIFs have custom color pallet, the file size is slightly bigger, but the performance gain is enormous.

That's interesting, considering there's a whole new trend of websites dedicated to converting heavy GIF files into small video files instead - sites such as https://gfycat.com/about

The bizarre thing is that the vast majority of these "gifs" come from a video source in the first place, so all they're doing is converting from a video, to a gif, back to a video format. This process destroys the quality and sound channel. Strange how sites like reddit eat this up.

The reason why funny videos as gif became big is the promise they give you that they are funny without sound, so you can play them in the office or during commute without fear that something will suddenly be noisy, or that something won't be easily understood.

When gifs started breaking the promise of being fast to load, due to people sharing fairly large res animations, sites such as gfycat tried to replicate the promise of silent sketches, but with more modern technology.

This is not bizare at all. Less is sometimes more.

This is all certainly accomplishable without converting the video file twice. <video> tags support a mute attribute, and with minor javascript you can set a looping playback from a timestamp. Best of both worlds if you really want that.

I can't help but feel these tools are evolving in the wrong direction. And not even in a "Stop liking what I don't like!" kind of way; simply that the solution could have been reached with far fewer steps.

Not that reddit nor its average user are specially concerned about quality in general.

It seems the easier (older) the video codec format the bigger is the file but also the less CPU/GPU resources are required to play them.

Remember Windows 95 played AVI videos e.g. in the file copying dialog. The AVI video consisted as a series of BMP pictures. All magenta colored areas where interpreted as transparent. (info about the special bitmap based AVI format: http://www.endurasoft.com/techtalk/AVI.aspx ) A 486 66 MHz with 4MB memory could play that short small videos. The Win95 CD contained two movie trailers afaik with an early Intel video codec, it took a more powerful Pentium 1 CPU to play them at 320x200 (Intel Indeo codec: https://en.wikipedia.org/wiki/Indeo ).

Coming back to GIFs and MP4/HTML5 videos. GIF is an old format from ca 1989, showing them is less CPU intensive than playing MP4 videos. Firefox on PC and all mobile browsers on iPad and Android that I tried had serious performance issues with 100+ very small videos. Interesting that GIFs mobile devices with even just 512MB memory can show at least 100 GIF videos (each 5-15 MB filesize) on one page.

Side question: is anyone aware of any computer-vision tools that effectively produce a visual comparison of two different video (where "video" includes GIF) formats?

It seems like something that would be quite possible, with a number of applications, but don't know offhand of any tools like that.

"At Facebook, we care about the experience we provide to people. How long Facebook takes to load is a contributing factor we look at to gauge user experience."

Do they really need to talk like this on a tech blog?

Ditto. I cringed when i read this. It's like Boeing writing: "At Boeing we really care about building planes that can fly and be safe too." As a reader, I feel they think I am a little dumb.

Sadly they care less about content theft - http://youtu.be/IrD96dNfHxk

eh, in the link to be reported he put the youtube link and not the page link, less than five days later issue is resolved, offending page is down, everyone's happy?

but the video lasts forever, with its partial information taken from a snapshot in time.

>“Freebooting” is a silly but oddly appropriate word invented by YouTubers CGP Grey and Brady Haran that means “taking online media and re-hosting it on your website without permission.”

http://www.itsokaytobesmart.com/post/108548517677/facebook-f...

https://www.youtube.com/watch?v=L6A1Lt0kvMA

"Freebooter" and "freebooting" mean "pirate" and "piracy", which is what I assume they're talking about: http://www.oxforddictionaries.com/definition/english/freeboo...

Yes, UI latency is part of tech. *

* I question how much FB cars about user experience given that Facebook looks and feels like a Linux window manager from 2003 but still latency is important.

Hey, my 2003 window manager looked much nicer than that.

Point taken. I meant FVWM with a really bad launcher and gkrellm everywhere rather than a classy XFCE setup.

I absolutely love fvwm. Motif beats the pants off gtk any day of the week.

You are JWZ and I claim my £5.

In case you don't get the joke: https://en.m.wikipedia.org/wiki/Lobby_Lud

Content from a massive company like Facebook will inevitably end up in the hands of aspiring journalists of all kinds. There is always a chance someone will sensationalize, distort, or outright mislead. You counter such unfortunate events by being overly scrupulous.

For canned video this decision is less than ground-breaking, but for me the more interesting question is what the state is with respect to live video broadcasting to a large audience.

I wonder if they know about this bug:

https://code.google.com/p/chromium/issues/detail?id=460709

It's been around for nearly a year, and Chromium eventually says they're following the spec and it's Facebook's fault.

it looks like something is hiding an ancestor of a video element so the video element is hidden...yes, sounds like a Facebook bug

"Videos are an enriching way to connect with the world around you"

Er... thanks FB for the insight into why videos are good.

Interesting that it doesn't sound like they got page loading time faster than with Flash, only to a point they were happy with.

Don't care. Haven't signed up to FB. Not until I can create feeds of my content to non-Facebook users, as simple as RSS. Unlisted content, similar to youtube unlisted videos. The URL discovery completely at my discretion and risk. You know, like more open, more choice and more in line with the web. Unshackled from branded ecosystem lock-in. That's all I want.

The reasons given for the switch could have been easily mitigated. At NYT we used an HTML5 player by default and then when HTML5 isn't supported we downgrade to a flash video container, while still maintaining the HTML/CSS/Javascript player controls. We also have a bridge from Actionscript to Javascript for logging. We barley have to update the flash video container, it just acts as a viewport for video.

Tangentially related question: what is the best software/hardware to economically stream HLS (HTTP Live Streaming) these days?

For live event webcasts, my employer has been using Wirecast to send an RTP stream to Brightcove. Brightcove is trying to move to HLS for all live streaming, but can't seem to give us a good recommendation for an economical, reliable way to create the HLS stream.

Any suggestions would be appreciated!

You could try out the live streaming feature of http://www.bitcodin.com, it supports HLS as well as MPEG DASH.

I really hope Daala (with input from Thor) will catch up and will force Apple to start supporting open codecs. The situation with fragmented and patent encumbered video is ridiculous.

Also, streaming situation is getting murky. MPEG-LA patent trolls tried to attack DASH a while ago. Is it patent free after all or not?

Yes, DASH is still royality free

I'm very glad they finally did. Means I can speed up playback speed (using the excellent https://github.com/igrigorik/videospeed chrome extension)

If Flash wasn't already dead...

Maybe it's time browsers improve the decoding performance of HTML5 videos. In my experience Wirth's law is in effect when it comes to browsers.

Regardless of their reasons, its a great move as it will push for better support.

Reply on news.ycombinator.com