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)."
Another case in point is determining how long to buffer and what bitrate to use (change dynamically). Does HTML5 video offer these options?
Aren't those things that are dependent on the codec and container that is used? Right now, depending on the format, I believe that HTML5 Video using Ogg Theora does provide variable bitrate.
I'm not sure where to address the buffering problem but you would think that it would be dependent on the user's latency and determined by the container or a combination of container and browser.
So what you asked would depend on the format used inside the HTML5 tag and if your browser supports that format yet.
My work here is dung.
PERIOD !
Yours In Astrakhan,
Kilgore T.
P.S.: N.P.R. IS Commercial Radio ! Simply Listen to the list of sponsors every 15 minutes after 5 minutes for a local station pause followed by 15 minutes of "music" at any_hour:45 a.m. or p.m.
The NPR Website looks as if it was designed by someone from F.ear
O.ppression X.enophobia News, C.N.N., or C.B.S.
That's not the right kind of VBR. You are confusing the issue. Look: a video stream is encoded at a "target bit rate". This is meant to be an "average bit rate" for the stream. If the stream uses VBR, the encoder will use fewer bits for parts with less information content. If it was using a constant bit rate, it would have to use the same bit rate regardless of what the frame showed. A noisy (high information content) frame would use the same bit rate as a black screen (low information content). VBR lets you "shift" bits away from the low information content frames, where they are not useful, to the high information content frames. You can't "adjust" this bit rate unless you re-encode the stream.
Now, what happens if you have a slow connection? If the connection is slower than the average bit rate, you won't be able to play it without lots of buffering.
On the other hand, Hulu can have multiple streams. A client-server solution is necessary to signal that the h.264 decoder needs to switch to another stream. But the streams necessarily cannot be in the same h.264 file for this scheme to work. If they were, you would be downloading all the streams at the same time, which is extremely counter productive.
The "it can then adjust the stream's bit rate of accordingly" part of your post is what you are missing. There isn't a signal the server can send to your web browser to adjust the bit rate accordingly.