HTML5 Video and the End of Plugins | Hacker News Reader

HTML5 Video and the End of Plugins

blog.zencoder.com

126 pointsmilkers42 comments

> Some of the things I talked about, like Encrypted Media Extensions, were, for the most part, still a pipe dream with few to no working implementations.

Why would anyone dream about this DRM junk? Something to dream about is for example Daala codec which is supposed to arrive in 2015.

Also, is there any non patented and freely available technology for adaptive video streaming? Unless DASH is not patent encumbered.

You don't want to encrypt your video chats with your lover? With your business associates?

I guess you Don't Have Anything To Hide™.

EME has nothing to do with security and privacy. It's all about DRM. If you want to encrypt your video chats you'd use something like ZRTP.

Sadly, good, solid DRM (Here's an encryption key, an encrypted file, and a secure way for me to limit when and how you can use those) is the ultimate form of Snapchat.

If you don't have DRM backing it up, the scenario is "Here's a key, a locked box, do whatever you want with the decrypted file." Which is less secure than being able to actually limit usage of the decrypted file.

Nothing here implies that I think DRM is a good thing, mind you. I just think saying something is "just DRM", as if DRM wasn't basically encryption + limitations on use.

> a secure way for me to limit when and how you can use those

That would be having them access the file in a restricted environment (literally, guards and stuff). You can't have people accessing your secrets in the comforts of their own homes and at the same time not be able to reproduce them in some form – even if an exact duplicate of the original data would be infeasible to obtain.

It's the illusion of security. The DRM contains the private key (because, well, you have to decrypt it, at some point). A motivated hacker will be able to get it, and decrypt the file for its own use.

No, as soon as you have some black box unauditable code, you shouldn't trust it for any such thing. And DRM by definition is hiding something from the user.

When using WebRTC then data is already encrypted on the transport layer [1], otherwise use SSL. EME is a rebranding of DRM and nothing else.

[1]: http://tools.ietf.org/html/draft-ietf-avt-dtls-srtp-07

The context is an article titled "HTML5 Video and the End of Plugins." For somebody who only cares about ending plugins, that quote makes sense. A majority of browsers will implement the spec plugin-free, and Firefox-based browsers will have a single sandboxed plugin with less power than an NPAPI plugin, which is the only realistic alternative.

> For somebody who only cares about ending plugins, that quote makes sense.

Replacing NPAPI plugin with some other DRM doesn't make anything better, whether it will be cooked into the browser or remain an external black box. Surely not something to dream about.

Except baking things into the browser is what the author's whole point is. The author doesn't care about black boxes. He cares about the end of plugins. He doesn't share your motivations.

You're like Stallman wondering why an llvm user would be excited about a new feature in clang. That user doesn't necessarily care about free software purity.

So what's so good about cooking things into the browser? Is it a self goal? Regular issues with plugins are security risks and lack of trust. DRM inside the browser doesn't help it and doesn't solve it. I'd say the opposite, it becomes much harder to separate so it only increases the risk.

So the author can cheer for the abstract benefit of moving plugins in the browser, but actual benefit isn't explained, since it's actually not a benefit at all.

Hi there, I wrote this blog post, and I can assure you, as someone that works in the video industry EME is definitely something to dream about. DRM is absolutely, 100% a necessity if you want to deal with any content coming from anyone from whom you actually want their content.

I'm not a fan of DRM, but it's simply a reality of the industry. It's weird, but most content doesn't have the same liberal license as Big Buck Bunny :)

> So what's so good about cooking things into the browser?

Remember RealPlayer? Windows Media Player? Quicktime? DivX? Flash? You don't see the benefit in getting to deal with these things less as a developer and, more importantly, a user?

> You don't see the benefit in getting to deal with these things less as a developer and, more importantly, a user?

As a user you deal with trusting the code you run. I don't trust running any DRM blobs on my system. And it's irrelevant for Linux users anyway, since even if Firefox would for example enable EME, there is no Adobe DRM blob for Linux to work with it so the whole discussion doesn't even start there.

> DRM is absolutely, 100% a necessity if you want to deal with any content coming from anyone from whom you actually want their content.

No, thanks. They need the Web more than the Web needs them. So I'll use their services when they'll start treating users decently and not like criminals by default, shoving unethical preemptive policing in everyone's throat. I personally prefer to vote with my wallet, that's why I'm not dreaming about any DRMed services and clutches they need to function - I don't use them. So definitely EME isn't something that interests me in the least.

I either use DRM-free services like GOG, or buy video on disks which nominally has no DRM (i.e. DRM there is obsolete, thanks to libdvdcss and the like).

Here is a good read about how GOG deals with this DRM idiocy in the video industry: https://www.gog.com/forum/general/introducing_gogcom_drmfree...

First of all, how in the world did we end up down the rabbit hole of the EME holy war? The EME comment was a tiny reference that ultimately had nothing to do with the point of the blog post...

You can do whatever you'd like with your wallet, but you live in a very different reality from most people. There's a reason why GOG can offer "Minecraft: The Story of Mojang" without DRM.

Again, this conversation has nothing to do with the actual blog post in question other than rabbling about something you disagree with. I disagree with you that EME is Satan's binary blob, but this is entirely irrelevant.

I'm not really criticizing the rest of the post. Just the EME part of it. And yes, that's my personal choice since I oppose DRM on many grounds (it's unethical, impractical, slows down the progress of technology and so on). And if we as users don't vote with our wallets, how else do you think this can be improved? Whether it's different reality or not, each one has personal responsibility for supporting or not supporting services which proliferate DRM.

In gaming sense GOG already broke quite a number of walls even with publishers who were usually viewed as thick skulled DRM proponents. Film industry however is one of the worst when it comes to this (it's older than the gaming industry in general so more legacy garbage and practices are attached).

Or alternatively, you're like a Microsoft devtools user circa 2000, wondering what crazies would use something besides windows/asp.net for their web stack, since in the "real world", no one cares about that crappy free software stuff, they just want stuff to work, and don't care about theoretical lock-in to a slow-moving company, don't care about being unable to modify/improve/adapt their own tools, etc.

You don't care about "free software purity", but we're not talking about "impure" open-source software. The EME module is completely closed source, trade secret, subject to opaque negotiations between large private companies. It is in fact quite pragmatic to have a problem with it. If you want to put a browser on a sufficiently different platform, it won't be able to play most of the videos on the web, if EME becomes popular. Or, if there's enough resistance to it, and DRM on video eventually goes the way of DRM on audio (i.e. goes away), you'll have put a bunch of effort and contracts and such into something that only holds you back from offering the best experience (whether you make websites or client platforms).

All that said, I suppose it is better that the DRM is relegated to the smallest possible piece, and delivery, decoding, and presentation are possibly open to improvement by the client platforms.

HLS (http live streaming, .m3u8 rotating playlists of chunks of video) isn't supported by desktop browsers except for Safari. That seems to be preventing live streaming sites from migrating away from flash. Notably, NASA's videos of the Orion mission were on flash on desktop, but their mobile site (mobile browsers—iOS, and Android since Honeycomb—support HLS) wasn't using flash.

HLS is on the way out. (Was it ever really in?) All the big video sites are implementing DASH.

I doubt this highly. And if they are moving to DASH it is implemented by Flash.

the recent "steam broadcasting" (live video game streams served via steam's service)

uses DASH and is works with pure HTML5 (no flash needed)

Not in safari or iOS

Safari on Mac now supports MSE, on which there are multiple DASH implementations. Safari on iOS is behind, but it's not hard to guess where it's going.

According to Steam it works in the Steam Client, Google Chrome, and Safari: https://support.steampowered.com/kb_article.php?ref=6730-TOA...

If they just say 'Safari', it probably doesn't work on iOS at the moment. But it should work on your Mac unless an extension/addon is interfering.

In order for DASH to work you need Media Source Extensions support. Firefox for example doesn't support them yet.

They're hidden behind an about:config flag - media.mediasource.enabled

The latest version of developer edition/aurora just enabled them by default, so version 36. They may be only ~12 weeks away from becoming default in the stable build.

Thanks, I didn't know that setting already made it into the stable build. Now I can watch Youtube in high resolution (and in VP9 with that!) without using Flash. Why is it still disabled though, there are some bugs left?

UPDATE: some remaining issues are listed here: https://bugzilla.mozilla.org/show_bug.cgi?id=778617

The webm video container live-streams fantastically well. It's just the MP4 container that is broken and doesn't live-stream.

Note that if you put H264 in an MPEG2-TS container that it will stream fine as well, but unfortunately that's not supported by browsers. (It also is inefficient, which makes it a poor choice.)

There is fragmented MP4, (usually called fMP4), which is a single MP4 file with multiple fragments inside. The last time I looked this wasn't supported by any browser, but now it looks like there's been work to integrate it into chrome and firefox.

The reason that single-file live-streaming is useful is that you can point the video tag's SRC at a URL that just calls popen on an FFMPEG process and transcode video on the fly, or even create new content immediately.

GP is talking about adaptive streaming with HLS. What you're discussing works only if all your clients have the same bandwidth.

I'm really impressed with how powerful HTML has become with respect to video content. Of particular note is the Flow Player [0], which I love to see websites use, primarily because it works without JS enabled! In addition, it is fast and runs smoothly.

I'm simultaneously really (un)impressed how often websites over-engineer their video content. Of particular interest is Youtube, which is neigh-unusable over a slow connection because the player refuses to buffer ahead and constantly tries to be smarter than it is by switching video quality :(

[0] https://flowplayer.org/player/

Can you really make that strong of an argument that YouTube's player is "overengineered"? I'm not always a fan of how they handle things but you have to at least consider the massive scale they are working at.

Since he was talking about slow connections, and I have seen YouTube issues on slow connections, here are two main issues:

1. The bandwidth switching is really messed up. When I'm playing something and it has buffered, let's say another 10 seconds and then quality of connection goes down, player will not switch quality after playing those 10 buffered settings. Instead, it discards all buffered data and fetches lower quality video again.

2. On iOS, video just gets stuck on low resolution. Picture will freeze, audio may stop or keep going and position indicator loops between 4-5 second interval. It will move forward 5 seconds, move back to the point it froze, repeat.

> 1. The bandwidth switching is really messed up.

Think about the opposite use case, you're watching in low quality and decide to switch it to higher, the buffered video is all not what the user wants.

Unfortunately, there are still some significant problems with the HTML5 video support in several major browsers. Among other things:

1. Chrome’s buffer size seems to be very small, enough to cause problems if you’re trying to watch very high resolution footage or play multiple videos together.

2. If you serve over HTTPS, Firefox sometimes seems to warn about mixed content even if everything is properly encrypted.

3. Some popular mobile devices/browsers don’t send cookies when requesting video files, which is a serious problem if you rely on those cookies for, say, authentication of logged-in users.

4. The canPlayType API is still one of the most bizarre and awkward I have ever encountered.

5. There is no standard for how video controls appear, or indeed if they appear at all before the video is actually playing. Moreover, some browsers will completely change their presentation of the controls as part of a software update from time to time. This makes it all but impossible to make clear to the user that something even is a video that they can click to play, if the video appears as part of a larger general content page rather than the obvious main element in a dedicated player page like YouTube. It also causes problems if you have short videos and include captions/annotations in the lower part of the video, as the controls may just stay there and obscure the content, which can be very frustrating for users.

I think HTML5 video will be a great development in time, but right now, it is still quite an immature technology. You can use it fine in trivial cases, which is sufficient in practice for a lot of useful pages, but all kinds of not-that-tricky-really things are still broken. The more worrying thing is that some of these issues have been broken literally for years, and the browser makers show no great enthusiasm for fixing them, which hampers developing anything using the HTML5 technology that is more interesting than another basic video hosting site.

I'm not terribly familiar with the technical details, but my experience as an end user is quite different from what you predict based on your knowledge of the technical details.

I watch a great deal of HD video content on both Netflix and YouTube in Chrome on Linux with only HTML5. I have no idea how big Chrome's buffers are, but I can say that both of these sites work better for me with HTML5 video than they did with Flash/Silverlight plugins. And without HTML5, I wasn't able to watch Netflix natively on Linux at all.

So while HTML5 video may certainly have room to mature, it is already significantly improving my experience of video on the web.

> Note – Before we get started, I need to be clear that the example we’re building only works in Firefox.

>> If you want to make this work in Chrome as well, there are projects such as RecordRTC and MediaStreamRecorder.

It's awesome to see that the Webrtc really started in Africa.

I saw this video very recently - http://bit.ly/1ytjdx0

I also saw an interesting presentation of the researcher here - http://bit.ly/1s4kitL - on HTML5 & Webrtc

Exciting! Just waiting for the adoption to be standard so I can try this for real, for example Chrome 39 on OS X 10.10 don't support recording.

allowing the browser access to your camera...

What could possibly go wrong?

HTML5 video! available everywhere and broken for everybody.

No kidding! I tried to make a landing page with a <video></video>... seems like you need 3 versions of the same video for cross browser format compatibility...

Reply on news.ycombinator.com