Slashdot Mirror
No HTML5 Hulu Anytime Soon
99BottlesOfBeerInMyF writes "The Hulu website briefly commented the other day about why they would not be implementing HTML5 video for their service: 'We continue to monitor developments on HTML5, but as of now it doesn't yet meet all of our customers' needs. Our player doesn't just simply stream video, it must also secure the content, handle reporting for our advertisers, render the video using a high performance codec to ensure premium visual quality, communicate back with the server to determine how long to buffer and what bitrate to stream, and dozens of other things that aren't necessarily visible to the end user.' They plan to release a dedicated application for the iPad and iPhone instead, likely a paid subscription service. Perhaps this is a good sign for Web-based television, as it will move more users away from the single, locked down channel from the networks and to more diverse options less interested in extracting subscription fees (like YouTube)."
that flash sucks and HTML5 is bestest way to stream video
It's probably more along the lines that Hulu isn't interested in rushing out an HTML5 app that will cost X to develop while their current client works perfectly well for the majority of their customers.
Rather than retooling their website it is more logical to do what they are actually doing and code a standalone app that will probably get rejected from the app store.
Yes, if a corporation dares to choose a widely-used product with a large install base, which fits their use requirements, as opposed to a relatively new, only moderate install base with different features available (no Firefox/Opera with H.264, no Safari/iPhone with Theora, no Internet Explorer period), which does not fit their use requirements on even one browser, then they must be 'in cahoots' with the company who makes that product.
I know you were going for a better-than-average first post without too much thought, but really, stop listening to Apple. Adobe is not a conspiracy.
Honesty in this case - admitting that "our customers" (plus their needs) and their users aren't the same thing...
One that hath name thou can not otter
This is not a surprise, I work with online video professionally and html5 is not yet a serious option.
RealPlayer, Windows Media Player and Flash are the only players that have the suite of features that are required to stream live and on-demand video properly.
I am looking forward to the day when html5 is ready but it looks like it is a long way off.
The "Flash is dead!" people have no idea what they're talking about.
I mean just look at the API for windows media player or realplayer and then go look at html5... they're not in the same league.
it must also secure the content
This, ladies and gentlemen, is the reason it won't happen. HTML5 is just too open for them. With Flash there are still various tricks to secure the stream (I believe the BBC iPlayer used to XOR it or something like that...)
Are you referring to Hulu or the HTML5 spec writers.
As Apple is in perfect shape now, I would be questioning "Why on earth our own Quicktime, even with DRM since V5 not even considered as an option?"
Someone should really start asking these questions now, that great framework is really being wasted. They didn't even bother to ship Quicktime X for Windows. Before attacking other companies frameworks/players/plugins, he should check the shape and missed opportunities of Quicktime department in Apple.
It's probably more along the lines that Hulu isn't interested in rushing out an HTML5 app that will cost X to develop while their current client works perfectly well for the majority of their customers.
This is probably true. It will be more cost effective in the short term, but you're missing the big motivation. Hulu does not want to provide open video. They want to provide subscription services, which they're moving to on the Web right now for a portion of content. They can make more money by only providing content to Apple devices that pay a subscription fee via an app, especially since those users won't be able to just use a Web browser for some content. Remember, Hulu is run by the networks.
Rather than retooling their website it is more logical to do what they are actually doing and code a standalone app that will probably get rejected from the app store.
Why would it get rejected from the app store? It will be trivial to provide the same content in different containers in a simple Web app using almost completely code provided in Apple's toolkits. Netflix has done it and they use Silverlight on the Web. Your assertion that it will probably be rejected is just your bias showing.
This proves once again that when the customers are advertisers the best solution is Flash. It will be some time before another technology becomes this ad friendly. As the article notes, HTML is great at delivering content, but not DRM or advertising.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
HTML5 could do the things they want, it would just not be very processor efficient
Hulu's new flash player that launched yesterday is also not processor efficient. Two days ago Hulu videos played at a reasonable frame rate on my old Mac laptop. Today it's impossible to watch. If it were in HTML5 it would run perfectly.
Developers: We can use your help.
Except that are doing more work (both upfront and in maintenance) in the form of a dedicated iPhone/iPad application. So I'm inclined to believe them.
That's not the right kind of "variable bit rate". The kind of VBR you're describing is merely varying the bit rate within a stream for compression efficiency. Hulu dynamically switches between streams at different bit rates, depending on the speed of your connection.
After all, I am strangely colored.
Go to archive.org, find a video you'd like to see, copy the link address for the file, then open that in mplayer. Works with absolutely no drama for me, whether I choose avi, mpg, ogv, etc. IOW, Hulu's explanation is mostly bullshit. They have exactly one reason, and that is "securing the content" -- which is pretty much nonsense. It isn't like your average "consumer" bothers with unauthorized copying/downloading. The hysteria on the "piracy" issue is completely absurd.
Caveat Utilitor
What 'single locked down channel' are we discussing here? There is presently more than Hulu alive on the web now, is there not?
Hulu is a joint venture of Fox, NBC, and ABC (now pulling out). The idea was they could maintain a singe front for providing mainstream TV, even as users moved way from cable and towards the internet for entertainment video. They were scared by YouTube and the like and wanted to make sure they could be the gatekeepers controlling the content as a cartel (like the RIAA has done with radio). That way they could extract more money in subscription fees going forward and at the same time reduce the threat of independent TV programming from being a more democratized source of content. Fox (for example) doesn't want to have to sell programs to users. They want to be able to sell subscriptions to all their content at once and so get paid just as much by people who think 90% of their content is crap.
Please do clarify, dear submitter.
Does that clarify my somewhat vague submission? I sort of assumed Slashdotters knew the history behind Hulu and the network's strategy with it.
DRM is an unsolved problem. I tell my customers not to bother with it. Most take my advice.
There can be no solution to DRM. All you can do is spend piles of money to make it more difficult for people to save/copy things. Then you have to do it all over again a few years later because everyone has the cracking tools installed.
You don't understand. By variable bitrate, they mean changing the bitrate on a per-viewer basis. So, if someone has a particularly bad connection, it gives them a lower quality picture so that they can keep up. And if they're connection improves (they turn off their torrents, for example) then the bitrate they are being provided would improve.
As far as I know, the object in HTML5 does not allow swapping out the referenced video while it's playing with another one encoded at a different bitrate. Silverlight does this for you with its streaming engine, with Flash it's at least possible to synchronize all the components, but it's rarely done. (You need to synchronize audio and video to a high degree of precision to avoid the user noticing.)
This is a valid complaint, and actually one of Microsoft's major selling points on Silverlight, and it's why Netflix adopted it for their online viewer. The variable bitrate per viewer playback that adjusts itself according to your connection is extremely important to providing at least a basic experience. Netflix's implementation is a little bad (it does pause the video if your connection quality goes down, but there are other Silverlight players that do it seamlessly.)
The HTML5 spec authors would do well to read that hulu blog. If they really want HTML5 to win, they need to provide the support necessary so sites like hulu can do what they want to do.
Really hulu has made it very easy for them, giving them an explicit goal to shoot for.
HTML5 advocates should really give an option for content security aka DRM, that is how real World works for now...
Even if they wanted to, how would you propose that they do that? It would be trivial enough to add a "donotallowworthlesspirateusertocopyonpainofdeath" option to the video tag; but that would only be as useful as the various browser's enforcement of it. You might get some vendors on board(though that would hardly be a given. The FOSS guys hate DRM on principle, and the corporates already have their own DRM systems, and it isn't clear that they want the competition); but you would have absolutely no way to go after the ones that refused, or the fly-by-night redistribution of copies of firefox compiled with the -ignore_DRM_flags option set.
If you observe real world DRM systems, they are all either single-party(WMDRM, Fairplay, etc.) or multi-vendor standards controlled by IP cartels bristling with patents that you must license in order to implement whatever the attached spec is(CSS, HDCP, AACS). HTML5 is in neither position. There would be absolutely no way to stop the proliferation of implementations compliant enough to receive the video; but noncompliant with respect to denying it to the user(good luck, for instance, having your site distinguish between a good-faith/best-effort DRM implementing webkit build, and a slightly tweaked build that reports exactly the same ID strings but "accidentally" lets the precious premium content sit in a snoopable memory location...
On closed platforms, where undesired binaries can simply be excluded, it'd be trivial enough; but there would be Just No Way on PCs generally.
While people love to hate on Flash, it actually performs quite will for video on most systems. It can chat with the video card and use it to accelerate decoding. This is important for HD content because you start to discover that HD can hit even a modern dual core hard if there's no acceleration. Well Flash accelerates nicely on Windows, and is supposed to be getting the ability to do so on the Mac (not sure on the status, I don't have a Mac).
Now I'm sure HTML5 can have this done, but it has to be done in the browsers people use before it would be a real contender. Saying "Well it could in theory accelerate video," does you fuck-all good if the web browsers out there don't do it. The net effect would be people would find HTML5 video choppy and it would bog their system down whereas Flash wouldn't. They wouldn't care about the reasons, they'd just say "This sucks."
For that matter, all the dynamic HTML5 type stuff itself may need new browser architectures. An interesting test to look at it Microsoft's IE9 platform preview (http://ie.microsoft.com/testdrive/). They've got a whole bunch of different demos of various types. Now the interesting thing is to look at them in Firefox, and in the IE9 preview. IE9 kills it speed wise, and function wise. Most things run twice as fast or more, and things like text scaling is smooth and fluid as you'd see in Flash, not jumpy.
So to truly have a good HTML5 experience, we may need a new generation of browser that makes good use of the video card to accelerate everything. As far as I know, there's nothing that does that right now, since IE9 is just a preview (and not really usable as a general web browser) and none of the rest are doing it. We may have to wait awhile before browsers can perform up to the level people would want with HTML5.