4 ms·

Hulu's video player is rock-solid. If they say HTML5 isn't good enough, I am inclined to take what they say seriously.

roc 16y ago
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.
- potatolicious 16y ago
  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.
  - roc 16y ago
    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.
  - KirinDave 16y ago
    The reporting complaints stuff seems like a non-sequitur. They could trivially be implemented and integrated with existing systems.
  - weixiyen 16y ago
    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?
- abstractbill 16y ago
  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.
  - pquerna 16y ago
    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/NetworkingInternet/Conceptual/StreamingMediaGuide/HTTPStreamingArchitecture/HTTPStreamingArchitecture.html 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 :)
    - abstractbill 16y ago
      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.
    - felixmar 16y ago
      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/ 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.
      - pquerna 16y ago
- cemerick 16y ago
  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.
strooltz 16y ago
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.
not_an_alien 16y ago
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.
- papachito 16y ago
  Fullscreen is supported by HTML5 side.
  - not_an_alien 16y ago
    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-not-quite-there-yet http://www.longtailvideo.com/support/blog/11887/html5-video-...
- ZeroGravitas 16y ago
  I thought most of the Hulu stuff was VP6 and only one or two versions were H.264. Has that changed?
  - kierank 16y ago
    It's all x264 encoded now afaik. (can't really check from the UK)
njharman 16y ago
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.

roc 16y ago

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.

potatolicious 16y ago
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.
- roc 16y ago
  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.
- KirinDave 16y ago
  The reporting complaints stuff seems like a non-sequitur. They could trivially be implemented and integrated with existing systems.
- weixiyen 16y ago
  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?
abstractbill 16y ago
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.
- pquerna 16y ago
  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/NetworkingInternet/Conceptual/StreamingMediaGuide/HTTPStreamingArchitecture/HTTPStreamingArchitecture.html 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 :)
  - abstractbill 16y ago
    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.
  - felixmar 16y ago
    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/ 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.
    - pquerna 16y ago
cemerick 16y ago
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.

strooltz 16y ago

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.

not_an_alien 16y ago

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.

papachito 16y ago
Fullscreen is supported by HTML5 side.
- not_an_alien 16y ago
  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-not-quite-there-yet http://www.longtailvideo.com/support/blog/11887/html5-video-...
ZeroGravitas 16y ago
I thought most of the Hulu stuff was VP6 and only one or two versions were H.264. Has that changed?
- kierank 16y ago
  It's all x264 encoded now afaik. (can't really check from the UK)

njharman 16y ago

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.