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.

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.

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.

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.

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.

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?

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

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.

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

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

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.

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.

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

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.

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

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.

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

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.

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/

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

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.

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.

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

What could possibly go wrong?