Hulu: HTML5 Isn’t Ready for Prime Time(newteevee.com)
newteevee.com
Hulu: HTML5 Isn’t Ready for Prime Time
http://newteevee.com/2010/05/13/hulu-html5-isnt-ready-for-prime-time/
10 comments
Well, the lack of support for DRM is always going to be an issue as long as content producers insist on having DRM. I know we've all been 'round this tree before, but I continue to be genuinely perplexed that they still insist on DRM. Network TV is broadcast over the air unencrypted to begin with. Why is the internet so special that all that same exact content has to be locked down? It's like a bank building a safe with several feet of reinforced concrete on the top, bottom, and sides, but putting a plywood door on the front.
Network TV is broadcast over the air unencrypted to begin with. Why is the internet so special that all that same exact content has to be locked down?
Because the devices that generally connect to the internet are good at storing and re-transmitting content, whereas TV's aren't.
Because the devices that generally connect to the internet are good at storing and re-transmitting content, whereas TV's aren't.
Not like it stops a select few individuals from recording OTA content and making it available online anyway. All it takes is one source to make the video available, so DRM really is pointless.
DRM in a browser doesn't stop a select few individuals from screen capturing content either. Hulu is only looking at stopping the majority so that they can secure their licensing rights.
Don't you mean, "The fiction that they maintain so that they can secure broadcasting rights?"
What about DVRs, DVD recorders and good old VCRs?
Media companies fought the introduction of those devices as well. They haven't lost the fight with internet video yet.
They have lost, they just haven't stopped fighting yet.
I think that your analogy is almost on the mark but it needs one little tweak:
"It's like a bank building a safe with several feet of reinforced concrete on the top, bottom, and sides, but putting a plywood door on the front which looks like reinforced concrete."
The reason for this tweak is that content is king and the content providers know it. Hulu by itself without content is yet another website - just a shell (recall Hulu's tears when Comedy Central pulled its shows).
Hulu's goal is to make content providers feel that their content is secure. Only when they do this will they get the content and have more content providers sign on. Consequently, it is in their best interest to perform a song and dance routine on how securing content is their number 1 goal.
The reason for this tweak is that content is king and the content providers know it. Hulu by itself without content is yet another website - just a shell (recall Hulu's tears when Comedy Central pulled its shows).
Hulu's goal is to make content providers feel that their content is secure. Only when they do this will they get the content and have more content providers sign on. Consequently, it is in their best interest to perform a song and dance routine on how securing content is their number 1 goal.
I guess the answer to this question is: Because they can. TV watchers would be furious if they had to buy a set top box to decrypt something that used to be unencrypted.
I'm pretty sure that this is exactly the case in the US, at least. You do need to buy a box to watch over the air broadcast after the digital transition, although technically it is probably encoded rather than encrypted.
That's actually not the case in the US. You don't need a box if your TV has an ATSC tuner. The only reason a lot of people need boxes is that they have old TV's with NTSC tuners.
The blog post itself seems to have been pulled, but here's a cached version: http://cc.bingj.com/cache.aspx?q=http%3a%2f%2fblog.hulu.com%...
[deleted]
I read it as "HTML's <video> doesn't have DRM". However, his concern about streaming and buffering capabilities seem valid. I'm assuming this will be improved as time moves on.
Bruce Schneier's expression Security Theatre really describes video DRM. It's to provide the illusion of control, to reassure content intermediaries that their business model is safe regardless of whether it is or isn't.
Basically, as of today, HTML5 video isn't ready. We all knew that.
The guy goes on to say that technology moves at a fast pace and they haven't ruled out HTML5.
Google's rumored VP8 release at I/O will help catapult it into prime time.
DRM is pointless imo, the sooner the networks realize that, the better.
The guy goes on to say that technology moves at a fast pace and they haven't ruled out HTML5.
Google's rumored VP8 release at I/O will help catapult it into prime time.
DRM is pointless imo, the sooner the networks realize that, the better.
Basically, as of today, HTML5 video isn't ready. We all knew that.
Tell that to the people that think HTML5 is 100% supported, that technologies like Flash aren't needed, and that Youtube has actually moved to HTML5.
Tell that to the people that think HTML5 is 100% supported, that technologies like Flash aren't needed, and that Youtube has actually moved to HTML5.
Rather, Hulu isn't ready for HTML5.
Hulu is an established platform, HTML5 is an upcoming spec that doesn't do what Hulu would need it to do. As cute as your post sounds (and we all love a pithy inversion), it's just wrong.
HTML5 video will never be acceptable by people who believe that DRM in Video is a requirement.
Fortunately, those people have over the last few years been proven more and more to be ignorant of what the wider market wants -- and the video-industry overall isn't being as stupid as the music industry, but fundamentally, they will try to hold on to DRM'ed video content for as long as possible, which is something that HTML5 streaming of video content will never allow.
Speaking as an ex-jooster, there are lots of things you can do to create white picket fences when streaming over HTTP, like one time tickets, dynamic rate limiting to prevent mass ripping[1], etc. At best these limit people 'stealing' content to doing it in real time, and makes it hard to 'rip' an entire site.
Today that is the situation even Flash is in -- there are lots of tools out there to steal content from Hulu in 1:1 time, and they could do it over HTTP for effectively the same protections, but the content owners still believe in the illusion that they have more viable white picket fences, which Adobe is happy to sell to customers in FMS: http://www.adobe.com/devnet/flashmediaserver/articles/protec...
[1] - http://svn.apache.org/viewvc?view=revision&revision=7219...
Fortunately, those people have over the last few years been proven more and more to be ignorant of what the wider market wants -- and the video-industry overall isn't being as stupid as the music industry, but fundamentally, they will try to hold on to DRM'ed video content for as long as possible, which is something that HTML5 streaming of video content will never allow.
Speaking as an ex-jooster, there are lots of things you can do to create white picket fences when streaming over HTTP, like one time tickets, dynamic rate limiting to prevent mass ripping[1], etc. At best these limit people 'stealing' content to doing it in real time, and makes it hard to 'rip' an entire site.
Today that is the situation even Flash is in -- there are lots of tools out there to steal content from Hulu in 1:1 time, and they could do it over HTTP for effectively the same protections, but the content owners still believe in the illusion that they have more viable white picket fences, which Adobe is happy to sell to customers in FMS: http://www.adobe.com/devnet/flashmediaserver/articles/protec...
[1] - http://svn.apache.org/viewvc?view=revision&revision=7219...
The worst part of the DRM illusion, is that HULU is entirely second-run TV. It is, by definition, video that has already be recorded, digitized and stored by any number of DVRs.
"Locking down" HULU won't stop the serious, won't stop the casual and won't have any effect on video availability past original broadcast. The networks have long since lost the ability to control rebroadcast availability and they remain in deep denial -- almost surely, because lucrative contracts for re-runs require them to maintain this fiction.
"Locking down" HULU won't stop the serious, won't stop the casual and won't have any effect on video availability past original broadcast. The networks have long since lost the ability to control rebroadcast availability and they remain in deep denial -- almost surely, because lucrative contracts for re-runs require them to maintain this fiction.
Hulu's video player is rock-solid. If they say HTML5 isn't good enough, I am inclined to take what they say seriously.
The thing to note is why they say it isn't good enough.
The argument essentially boils down to: the studios and the advertisers are their customers: the studios don't like the lack of perceived control over the data stream and the advertisers don't like the loss of finer-grained reporting on data-stream consumption.
The argument essentially boils down to: the studios and the advertisers are their customers: the studios don't like the lack of perceived control over the data stream and the advertisers don't like the loss of finer-grained reporting on data-stream consumption.
I've only skimmed the HTML5 video spec so far, but my guess at this point is that stuff like Hulu's new adaptive bitrate streaming, and their ad volume normalization, would be much more difficult (if not impossible) to implement in HTML5.
I certainly agree the studios' lack of perceived control is likely to be a factor too, but Hulu aren't alone here: HTML5 isn't (yet) good enough for us at Justin.TV either.
I certainly agree the studios' lack of perceived control is likely to be a factor too, but Hulu aren't alone here: HTML5 isn't (yet) good enough for us at Justin.TV either.
Yes, Adpative bit-rate is currently missing from HTML5.
However, Apple has a method of doing this with entirely standard HTTP and a few metadata files, as this is how you do adaptive bitrate content on the iphone: http://developer.apple.com/iphone/library/documentation/Netw...
The formats and methods Apple provides in the spec for the IPhone can be used for both Live Content and for adaptive bit-rate pre-recorded content.
I hope eventually the iphone http streaming spec or a derivative would get adopted into HTML5 :)
However, Apple has a method of doing this with entirely standard HTTP and a few metadata files, as this is how you do adaptive bitrate content on the iphone: http://developer.apple.com/iphone/library/documentation/Netw...
The formats and methods Apple provides in the spec for the IPhone can be used for both Live Content and for adaptive bit-rate pre-recorded content.
I hope eventually the iphone http streaming spec or a derivative would get adopted into HTML5 :)
Apple has one or more pending patents for it's (rather trivial) live streaming protocol and so far only agrees to RAND terms, see https://datatracker.ietf.org/ipr/1142/ I have not seen a confirmation from Apple that it will offer royalty-free licenses if the protocol becomes a IETF standard. That should imho be a requirement for HTML5 adoption.
Also it may be better to adopt another streaming protocol for HTML5 because the Apple's protocol is not suitable for low latency streaming.
Also it may be better to adopt another streaming protocol for HTML5 because the Apple's protocol is not suitable for low latency streaming.
A patent over a metadata/playlist file and various bit rate chunks of a file?
Well, they don't disclose what the patent is, but bleh, its just stupid to patent crap like that :(
Well, they don't disclose what the patent is, but bleh, its just stupid to patent crap like that :(
Yeah, we use Apple's spec in our own iPhone app. It would be very nice to see it, or something like it, in HTML5.
@pquerna (for some reason, your post didn't have a reply link):
Interesting scheme. I'm wondering if this same idea could be used by a client-side library to enable buffering and dynamic bitrate changes. It could also be used to dynamically insert advertising video content into the stream...
Interesting scheme. I'm wondering if this same idea could be used by a client-side library to enable buffering and dynamic bitrate changes. It could also be used to dynamically insert advertising video content into the stream...
And those are important why's.
The end user isn't the only term in the equation is that is the internet.
I would agree that HTML5 isn't ready for mass consumption just yet - client-side uptake is not there, and current implementations are first-generation and very, very slow. We need to go through some more cycles before this thing is in shape for a large-scale deployment like Hulu.
The end user isn't the only term in the equation is that is the internet.
I would agree that HTML5 isn't ready for mass consumption just yet - client-side uptake is not there, and current implementations are first-generation and very, very slow. We need to go through some more cycles before this thing is in shape for a large-scale deployment like Hulu.
I personally disagree. None of those why's are all that important except for the buffering because the end user is in fact the only term in the equation that matters.
Advertiser reporting tools are not crucial. They will advertise if they know the eyeballs are there.
Neither is DRM. If given a choice to monetize without DRM or not have a site at all and maintaining rights, the choice is obvious (if the business is interested in profits).
These are things that advertisers and studios "want", not necessarily need.
The only valid complaints are technical things like video quality and buffering. Everything else is secondary and only crucial to Hulu because their business thrives on giving a perceived illusion of ownership to distributors. But when push comes to shove, as it's been stated already in regards to DRM, your content is getting onto DVRs and can easily be redistributed illegally by other means, so what's the point?
Advertiser reporting tools are not crucial. They will advertise if they know the eyeballs are there.
Neither is DRM. If given a choice to monetize without DRM or not have a site at all and maintaining rights, the choice is obvious (if the business is interested in profits).
These are things that advertisers and studios "want", not necessarily need.
The only valid complaints are technical things like video quality and buffering. Everything else is secondary and only crucial to Hulu because their business thrives on giving a perceived illusion of ownership to distributors. But when push comes to shove, as it's been stated already in regards to DRM, your content is getting onto DVRs and can easily be redistributed illegally by other means, so what's the point?
I never said they were unimportant reasons. I just pointed out that no-one's actually arguing that HTML5 is ready to drop into HULU's business and replace their Flash client today.
The story's hook is the rationale, not the conclusion. You miss the point in discussing whether the conclusion is accurate or not.
The story's hook is the rationale, not the conclusion. You miss the point in discussing whether the conclusion is accurate or not.
The reporting complaints stuff seems like a non-sequitur. They could trivially be implemented and integrated with existing systems.
Um, yeah. If you're not handing over money to someone, you're not a customer -- you're a user. An important population, but customers will almost always trump users if there's differing interests.
People are assuming this is all about DRM, but there's a lot more than that. Interactive features, as well as tracking - all very possive with HTML5/JS, just more painful to work with. Not to mention things like fullscreen which are not even supported by the HTML5 side.
Hulu could easily implement an HTML5 player if they wanted - their catalog is already in H264. But the experience would suffer, and as such, they're just not doing it instead of jumping on a bandwagon that's poised for a trainwreck.
Hulu could easily implement an HTML5 player if they wanted - their catalog is already in H264. But the experience would suffer, and as such, they're just not doing it instead of jumping on a bandwagon that's poised for a trainwreck.
I thought most of the Hulu stuff was VP6 and only one or two versions were H.264. Has that changed?
It's all x264 encoded now afaik. (can't really check from the UK)
Fullscreen is supported by HTML5 side.
Not really. Implementing obscure and browser-specific solutions isn't the same as supporting it by the standard.
http://www.longtailvideo.com/support/blog/11887/html5-video-...
http://www.longtailvideo.com/support/blog/11887/html5-video-...
I would disagree with this. I think it's reliable but all too often i find that i have to restart the videos, advertisements fail to load, and it takes a while to start up. Don't get me wrong - i think it's great and i use it almost daily, however saying it's video player is rock solid is definitely an overstatement.
Their player is far from rock solid.
If I use the "wrong" DNS servers it claims I'm not from the USA. It's rather low quality/slow on my platform. I don't think the in browser player works at all.
If I use the "wrong" DNS servers it claims I'm not from the USA. It's rather low quality/slow on my platform. I don't think the in browser player works at all.
I would think they'd be best-off with writing their own software as a plugin... though granted, that's more work than coding it once for Flash. It's one of the things which Flash is really quite nicely suited for.
But if they're interested in offering higher quality w/ lower bandwidth and lower CPU usage on more machines, Flash is definitely not the way to go if you're making a custom DRM. Video decoding isn't exactly its strong point.
But if they're interested in offering higher quality w/ lower bandwidth and lower CPU usage on more machines, Flash is definitely not the way to go if you're making a custom DRM. Video decoding isn't exactly its strong point.
Is there a way yet to lock down the source file with HTML5 video in the same way that, say, Typekit locks down font files?
I certainly hope not.
Right, I'm not saying there should be or that I want there to be, but a) this entire post can be translated as "We're not using HTML5 because there's no DRM" and b) even though it's not a business I'd want to be in, certainly seems to be a market opportunity for it
Considering that TypeKit is just JS with some server-side stuff, there's not much that it could do; I'm sure you could craft some hack to do the same thing with <video>.
Edit: pquerna answered this better than I did: http://news.ycombinator.com/item?id=1344880
Edit: pquerna answered this better than I did: http://news.ycombinator.com/item?id=1344880
My first thought on reading the title was that they don't want the content accessible from the iPad so that they could charge for an app.
The other reasons discussed make sense (merits aside), but I still wonder.
The other reasons discussed make sense (merits aside), but I still wonder.
Its about time a major video provider stands up for the current limitations of HTML5. I'm glad to see them do this and I would love to hear some BS response from jobs on why they are wrong.