From a technical standpoint there is nothing stopping Hulu or Netflix from streaming to the iPhone. What could be a barrier is getting permission from the content owners. I don't know the exact streaming infrastructure or codecs used by Hulu or Netflix, but we do know Hulu uses Flash as a media wrapper and Netflix uses Silverlight.
Currently on the iPhone we have TV.com and Joost that both stream the type of long form media that Hulu and Netflix would stream. Both have serious problems. The quality on TV.com is horrible. Their shows are divided into 5 minute sections. You have to manually stream each clip. The quality on Joost is better, but the connection is unreliable. Part of the problem is the fact Joost crashes a lot. Once you loose the streaming connection you have to start from the beginning.
I can imagine that Hulu and any other media service that care about providing quality would find this an unacceptable option for delivering video. From what I've seen of HTTP Live Streaming, it provides high quality video, and can stream long form content without breaking it up into clips like TV.com. I also found it easy to scrub along different parts of the timeline and the stream was picked up fairly quickly. Since the stream is being downloaded and buffered. If you were to loose the connection for some reason, the media player should be able to pick up where it left off.
To use HTTP Live Streaming the only major investment Hulu or Netflix would have to make is in re-encoding their content into H.264, if their content isn't already in that codec. Other than that the technology should be pretty easy and straightforward to use.
Quote:
Originally Posted by sseelman
So, my question is about what it will take for Hulu and Netflix to start streaming to the iPhone. I assume both use a flash server of some kind. Do they need to do anything on their side to stream to the iPhone with the new HTTP live streaming. Is their an investment in time, equipment, anything? If yes - any idea how painful? If no - is there any other inhibitor to keep them from starting to stream to the iPhone? There is such a big potential market here that I have to believe that they are seriously looking at it.
Why start a new standard. Why not use the one appearently defined in the 3G (UMTS) specs. Every other 3G phone other that I have used will stream content. Its what YouTube uses on the m.youtube.com and what television stations use in Europe. My 3G Nokia that I got back in 2005 supports this, as well as my more recent HTC TyTn. The streams appear to be identical in format.
Exactly what 3G standard are you talking about? How does it work across any network that isn't 3G? HTTP Live Stream is independent of the radio technology and will work across any network.
Quote:
Sure the iPhone may promote the adoption of a new standard (and IT IS NOT STANDARDS BASED if it has been adopted yet or signed on my a comittee) but there are alot more Nokia Phones out there. Will video providers have to direct people two different streams? Have two technologies? It will make it more costly. Like I said every other recent good phone has streaming, it appears to the same technology. Well exepct for the fact that maybe Apple hopes it can control a standard.
HTTP Live Stream has not been adopted by a standards board but what it uses is all based on open technologies.
To support HTTP LS, all that needs to happen is having a browser or media framework that can use MPEG Transport Streams. Nokia phones do play MPEG files, its all open standard tools.
I'm still not sure exactly what 3G streaming technology you are talking about. But of the streaming options used on the iPhone, so far from what I've seen HTTP LS is the best.
Man, the level of fanboyism in the article is crazy unprofessional. Why the unsolicited jab at the Palm Pre. They seem to forget that the type of applications the Pre launched with are lightyears ahead of the "webapps" that the iPhone was capable of. Soon, Palm is going to have an app store that they dont censor, and they will allow installation of apps outside of the app store. Apple wouldn't even have an app store if it werent for outside pressure from hackers (a thriving jailbreak community takes a revenue stream away from Apple) and other handsets that were gaining similar functionality. As another poster mentioned, this is also no novel invention. You people act like every time Apple adds something to the iPhone, it was some amazing invention that had never been done before and only Apple could have come up with.
Man, the level of fanboyism in the article is crazy unprofessional. Why the unsolicited jab at the Palm Pre. They seem to forget that the type of applications the Pre launched with are lightyears ahead of the "webapps" that the iPhone was capable of. Soon, Palm is going to have an app store that they dont censor, and they will allow installation of apps outside of the app store. Apple wouldn't even have an app store if it werent for outside pressure from hackers (a thriving jailbreak community takes a revenue stream away from Apple) and other handsets that were gaining similar functionality. As another poster mentioned, this is also no novel invention. You people act like every time Apple adds something to the iPhone, it was some amazing invention that had never been done before and only Apple could have come up with.
You can't be more right on this one! Even funnier: progressive download was created to cope with the fact that gprs and 1xrtt networks (2.5g) were unable to provide enough data throughput, so you would start downloading the file, and while it is downloading, you would eventually start watching (after a big chunk of the file was buffered, so that you could watch the video a little before you're done downloading). 3GPP or not, RTP/RTSP/RTCP is by far the best way to deliver real time streaming to any device, thanks to QoS management amongst other things. Most media players and phones support it by default. Apple just can't get RTP right for the iPhone, so they go down the lazy road and uses crappy ways of delivering multimedia. Don't expect magic things like adaptive bitrates or framerates (vital over a mobile network as the quality of the "coverage" changes constantly when you're on the go), just expect big fat buffers and longer loading time to mask the fact that it's more or less a download. They are hoping that the bigger 3g pipes will help mask that, we shall see...
Man, the level of fanboyism in the article is crazy unprofessional. Why the unsolicited jab at the Palm Pre.
What was the jab at the Palm Pre?
Quote:
They seem to forget that the type of applications the Pre launched with are lightyears ahead of the "webapps" that the iPhone was capable of. Soon, Palm is going to have an app store that they dont censor, and they will allow installation of apps outside of the app store.
The primary difference between the original iPhone web apps and WebOS apps, is HTML5 and native API's. The iPhone 3.0 is based on HTML5 and web apps can now use native API's. iPhone developers can built web apps that feel much like a native app without needing to open a Safari window.
Trust me if the Pre has an app that 14 year old girls use to post nude pictures of themselves, which has happened on the iPhone. Palm will be forced to sensor their app store.
Quote:
Apple wouldn't even have an app store if it werent for outside pressure from hackers (a thriving jailbreak community takes a revenue stream away from Apple) and other handsets that were gaining similar functionality. As another poster mentioned, this is also no novel invention. You people act like every time Apple adds something to the iPhone, it was some amazing invention that had never been done before and only Apple could have come up with.
Apple announced the SDK with full documentation about three months after the launch of the original iPhone. That makes it obvious the 3rd party apps were always apart of the plan, it just wasn't ready yet. The same way Palm did not officially released its SDK with the launch of the Pre.
I have not seen anyone say Apple has done anything that wasn't done before. But you have to look at the fact that with the iPhone Apple has gotten many things right.
The content provider has the media encoded at different bit rates, the HTTP LS protocol will automatically switch to the appropriate bit rate depending on the the data rate need for smooth playback.
How can you really know for sure RTCP is the only best way to deliver real time streaming? You really think its impossible to discover a better way?
Quote:
Originally Posted by warpdag
3GPP or not, RTP/RTSP/RTCP is by far the best way to deliver real time streaming to any device, thanks to QoS management amongst other things. Most media players and phones support it by default. Apple just can't get RTP right for the iPhone, so they go down the lazy road and uses crappy ways of delivering multimedia. Don't expect magic things like adaptive bitrates or framerates (vital over a mobile network as the quality of the "coverage" changes constantly when you're on the go), just expect big fat buffers and longer loading time to mask the fact that it's more or less a download. They are hoping that the bigger 3g pipes will help mask that, we shall see...
The content provider has the media encoded at different bit rates, the HTTP LS protocol will automatically switch to the appropriate bit rate depending on the the data rate need for smooth playback.
How can you really know for sure RTCP is the only best way to deliver real time streaming? You really think its impossible to discover a better way?
Oh boy... I think Apple should actually investigate using all the other application layer protocols available while we're at it! Why not "streaming" over DHCP, FTP, IRC, NTP, POP, RIP or even Telnet then? Would be so much fun!
I maintain that HTTP is not a very suitable protocol for any kind of real time video apps, whether you like it or not. Do you realize that HTTP works over TCP? Totally inefficient for such applications, but it's ok, Apple is putting so much pressure on the ATTs of the world, they will force these guys to have big enough pipes to hide their own shortcomings Simply read the RFCs related to RTP/RTCP/RTSP (and especially the QoS management via RTCP), could give you some insights.
Apple - as usual - chooses not to use dedicated protocols that were invented for that specific purpose a while back... Same story for the <video> tag, but let's not start another troll...
You've said nothing that addresses the problem of RTCP ports easily being blocked by network, router, or firewall controls. While HTTP ports are generally always open.
I don't doubt that RTSP has it's advatanges. But it's simply your opinion that HTTP is such an inferior option. I haven't read this sentiment anywhere else. Over at Ars they were largely positive about the potential of the HTTP protocal.
If RTSP is so much better why hasn' it become the defacto streaming
technology for mobile devices? Why hasn't anyone else gotten it to work?
Over all your argument is a collection of vague technical jargon with very little substance that clearly explains why RTSP is so much better than HTTP.
Quote:
Originally Posted by warpdag
I maintain that HTTP is not a very suitable protocol for any kind of real time video apps, whether you like it or not. Do you realize that HTTP works over TCP? Totally inefficient for such applications, but it's ok, Apple is putting so much pressure on the ATTs of the world, they will force these guys to have big enough pipes to hide their own shortcomings Simply read the RFCs related to RTP/RTCP/RTSP (and especially the QoS management via RTCP), could give you some insights.
Apple - as usual - chooses not to use dedicated protocols that were invented for that specific purpose a while back... Same story for the <video> tag, but let's not start another troll...
I agree with UltimateKylie, there is a current standard to support streaming to phones. Apple is proposing a new standard. That is fine but it would be best if they supported the current 3GPP standard in the iPhone like many of the other phone manufacturers.
I'm sure developers at WWDC were given some additional insight into the technology. Obviously OSX Server will incorporate this into the QuickTime Streaming Server as a protocal to broadcast with.
If I'm nit mistaken this is being used in the at bat app for the iPhone. I believe they use it to stream the games live. If anyone has the at bat app check it out it's pretty good
Over all your argument is a collection of vague technical jargon with very little substance that clearly explains why RTSP is so much better than HTTP.
That sounds quite petty for someone who seems so knowledgeable. RTSP runs over UDP to start with, no need to send useless acknowledgments like HTTP requires (HTTP rides over TCP, the real time nature of streaming makes UDP much more suitable because if a packet is lost, you don't really care, it's real time, if the information is lost, you simply move on). But RTSP is just a piece of the puzzle. The brilliant part is RTCP, RTSP's out of band buddy, which controls everything, and helps adapt bitrate and framerate in real time (both RTCP and RTSP sessions are opened when using RTSP). HTTP simply can't do that, the only thing it does is "download a chunk then play, if everything OK then download another chunk then play" and so on. Real time and HTTP are by essence contradictory. From wikipedia (I would assume most people can understand wikipedia's simple description):
RTCP provides out-of-band statistics and control information for an RTP flow. It partners RTP in the delivery and packaging of multimedia data, but does not transport any media streams itself. The primary function of RTCP is to provide feedback on the quality of service (QoS) in media distribution by periodically sending statistics information to participants in a streaming multimedia session. RTCP gathers statistics for a media connection and information such as transmitted octet and packet counts, lost packet counts, jitter, and round-trip delay time. An application may use this information to control quality of service parameters, perhaps by limiting flow, or using a different codec.
The RTSP protocol has similarities to HTTP, but RTSP adds new requests. While HTTP is stateless, RTSP is a stateful protocol. A session identifier is used to keep track of sessions when needed; thus, no permanent TCP connection is needed.
I'm using www.avcstreamer.com to stream my tv from my house to my iphone. Here's the thing - with apple's http live streaming you get huge delay. If I cut down the chunk segment length from apple's recommended 10sec down to 5 sec - you still get about a 12-17 second delay of the LIVE content. This isn't that great when I go to a baseball game and want to watch the live broadcast. I just don't understand why apple doesn't adopt a standard approach to read the same exact transport stream as a continuous download, instead of segmenting it into 5 second chunks.
Comments
Currently on the iPhone we have TV.com and Joost that both stream the type of long form media that Hulu and Netflix would stream. Both have serious problems. The quality on TV.com is horrible. Their shows are divided into 5 minute sections. You have to manually stream each clip. The quality on Joost is better, but the connection is unreliable. Part of the problem is the fact Joost crashes a lot. Once you loose the streaming connection you have to start from the beginning.
I can imagine that Hulu and any other media service that care about providing quality would find this an unacceptable option for delivering video. From what I've seen of HTTP Live Streaming, it provides high quality video, and can stream long form content without breaking it up into clips like TV.com. I also found it easy to scrub along different parts of the timeline and the stream was picked up fairly quickly. Since the stream is being downloaded and buffered. If you were to loose the connection for some reason, the media player should be able to pick up where it left off.
To use HTTP Live Streaming the only major investment Hulu or Netflix would have to make is in re-encoding their content into H.264, if their content isn't already in that codec. Other than that the technology should be pretty easy and straightforward to use.
So, my question is about what it will take for Hulu and Netflix to start streaming to the iPhone. I assume both use a flash server of some kind. Do they need to do anything on their side to stream to the iPhone with the new HTTP live streaming. Is their an investment in time, equipment, anything? If yes - any idea how painful? If no - is there any other inhibitor to keep them from starting to stream to the iPhone? There is such a big potential market here that I have to believe that they are seriously looking at it.
Any thoughts?
Why start a new standard. Why not use the one appearently defined in the 3G (UMTS) specs. Every other 3G phone other that I have used will stream content. Its what YouTube uses on the m.youtube.com and what television stations use in Europe. My 3G Nokia that I got back in 2005 supports this, as well as my more recent HTC TyTn. The streams appear to be identical in format.
Exactly what 3G standard are you talking about? How does it work across any network that isn't 3G? HTTP Live Stream is independent of the radio technology and will work across any network.
Sure the iPhone may promote the adoption of a new standard (and IT IS NOT STANDARDS BASED if it has been adopted yet or signed on my a comittee) but there are alot more Nokia Phones out there. Will video providers have to direct people two different streams? Have two technologies? It will make it more costly. Like I said every other recent good phone has streaming, it appears to the same technology. Well exepct for the fact that maybe Apple hopes it can control a standard.
HTTP Live Stream has not been adopted by a standards board but what it uses is all based on open technologies.
To support HTTP LS, all that needs to happen is having a browser or media framework that can use MPEG Transport Streams. Nokia phones do play MPEG files, its all open standard tools.
I'm still not sure exactly what 3G streaming technology you are talking about. But of the streaming options used on the iPhone, so far from what I've seen HTTP LS is the best.
it's a good idea, but if they're going to do live streaming they should do it with some sort of standard as opposed to a proprietary format.
Man, the level of fanboyism in the article is crazy unprofessional. Why the unsolicited jab at the Palm Pre. They seem to forget that the type of applications the Pre launched with are lightyears ahead of the "webapps" that the iPhone was capable of. Soon, Palm is going to have an app store that they dont censor, and they will allow installation of apps outside of the app store. Apple wouldn't even have an app store if it werent for outside pressure from hackers (a thriving jailbreak community takes a revenue stream away from Apple) and other handsets that were gaining similar functionality. As another poster mentioned, this is also no novel invention. You people act like every time Apple adds something to the iPhone, it was some amazing invention that had never been done before and only Apple could have come up with.
You can't be more right on this one! Even funnier: progressive download was created to cope with the fact that gprs and 1xrtt networks (2.5g) were unable to provide enough data throughput, so you would start downloading the file, and while it is downloading, you would eventually start watching (after a big chunk of the file was buffered, so that you could watch the video a little before you're done downloading). 3GPP or not, RTP/RTSP/RTCP is by far the best way to deliver real time streaming to any device, thanks to QoS management amongst other things. Most media players and phones support it by default. Apple just can't get RTP right for the iPhone, so they go down the lazy road and uses crappy ways of delivering multimedia. Don't expect magic things like adaptive bitrates or framerates (vital over a mobile network as the quality of the "coverage" changes constantly when you're on the go), just expect big fat buffers and longer loading time to mask the fact that it's more or less a download. They are hoping that the bigger 3g pipes will help mask that, we shall see...
Man, the level of fanboyism in the article is crazy unprofessional. Why the unsolicited jab at the Palm Pre.
What was the jab at the Palm Pre?
They seem to forget that the type of applications the Pre launched with are lightyears ahead of the "webapps" that the iPhone was capable of. Soon, Palm is going to have an app store that they dont censor, and they will allow installation of apps outside of the app store.
The primary difference between the original iPhone web apps and WebOS apps, is HTML5 and native API's. The iPhone 3.0 is based on HTML5 and web apps can now use native API's. iPhone developers can built web apps that feel much like a native app without needing to open a Safari window.
Trust me if the Pre has an app that 14 year old girls use to post nude pictures of themselves, which has happened on the iPhone. Palm will be forced to sensor their app store.
Apple wouldn't even have an app store if it werent for outside pressure from hackers (a thriving jailbreak community takes a revenue stream away from Apple) and other handsets that were gaining similar functionality. As another poster mentioned, this is also no novel invention. You people act like every time Apple adds something to the iPhone, it was some amazing invention that had never been done before and only Apple could have come up with.
Apple announced the SDK with full documentation about three months after the launch of the original iPhone. That makes it obvious the 3rd party apps were always apart of the plan, it just wasn't ready yet. The same way Palm did not officially released its SDK with the launch of the Pre.
I have not seen anyone say Apple has done anything that wasn't done before. But you have to look at the fact that with the iPhone Apple has gotten many things right.
How can you really know for sure RTCP is the only best way to deliver real time streaming? You really think its impossible to discover a better way?
3GPP or not, RTP/RTSP/RTCP is by far the best way to deliver real time streaming to any device, thanks to QoS management amongst other things. Most media players and phones support it by default. Apple just can't get RTP right for the iPhone, so they go down the lazy road and uses crappy ways of delivering multimedia. Don't expect magic things like adaptive bitrates or framerates (vital over a mobile network as the quality of the "coverage" changes constantly when you're on the go), just expect big fat buffers and longer loading time to mask the fact that it's more or less a download. They are hoping that the bigger 3g pipes will help mask that, we shall see...
Or is this just the author making stuff up like "Well, I downloaded silverlight and it also included a new feature. It must be a trojan!"
I'm an ADC Select member and iPhone dev but the link still says a I don't have permission to access that resource.
The content provider has the media encoded at different bit rates, the HTTP LS protocol will automatically switch to the appropriate bit rate depending on the the data rate need for smooth playback.
How can you really know for sure RTCP is the only best way to deliver real time streaming? You really think its impossible to discover a better way?
Oh boy... I think Apple should actually investigate using all the other application layer protocols available while we're at it! Why not "streaming" over DHCP, FTP, IRC, NTP, POP, RIP or even Telnet then? Would be so much fun!
I maintain that HTTP is not a very suitable protocol for any kind of real time video apps, whether you like it or not. Do you realize that HTTP works over TCP? Totally inefficient for such applications, but it's ok, Apple is putting so much pressure on the ATTs of the world, they will force these guys to have big enough pipes to hide their own shortcomings
Apple - as usual - chooses not to use dedicated protocols that were invented for that specific purpose a while back... Same story for the <video> tag, but let's not start another troll...
I don't doubt that RTSP has it's advatanges. But it's simply your opinion that HTTP is such an inferior option. I haven't read this sentiment anywhere else. Over at Ars they were largely positive about the potential of the HTTP protocal.
If RTSP is so much better why hasn' it become the defacto streaming
technology for mobile devices? Why hasn't anyone else gotten it to work?
Over all your argument is a collection of vague technical jargon with very little substance that clearly explains why RTSP is so much better than HTTP.
I maintain that HTTP is not a very suitable protocol for any kind of real time video apps, whether you like it or not. Do you realize that HTTP works over TCP? Totally inefficient for such applications, but it's ok, Apple is putting so much pressure on the ATTs of the world, they will force these guys to have big enough pipes to hide their own shortcomings
Apple - as usual - chooses not to use dedicated protocols that were invented for that specific purpose a while back... Same story for the <video> tag, but let's not start another troll...
I'm sure developers at WWDC were given some additional insight into the technology. Obviously OSX Server will incorporate this into the QuickTime Streaming Server as a protocal to broadcast with.
If I'm nit mistaken this is being used in the at bat app for the iPhone. I believe they use it to stream the games live. If anyone has the at bat app check it out it's pretty good
Over all your argument is a collection of vague technical jargon with very little substance that clearly explains why RTSP is so much better than HTTP.
That sounds quite petty for someone who seems so knowledgeable. RTSP runs over UDP to start with, no need to send useless acknowledgments like HTTP requires (HTTP rides over TCP, the real time nature of streaming makes UDP much more suitable because if a packet is lost, you don't really care, it's real time, if the information is lost, you simply move on). But RTSP is just a piece of the puzzle. The brilliant part is RTCP, RTSP's out of band buddy, which controls everything, and helps adapt bitrate and framerate in real time (both RTCP and RTSP sessions are opened when using RTSP). HTTP simply can't do that, the only thing it does is "download a chunk then play, if everything OK then download another chunk then play" and so on. Real time and HTTP are by essence contradictory. From wikipedia (I would assume most people can understand wikipedia's simple description):
RTCP provides out-of-band statistics and control information for an RTP flow. It partners RTP in the delivery and packaging of multimedia data, but does not transport any media streams itself. The primary function of RTCP is to provide feedback on the quality of service (QoS) in media distribution by periodically sending statistics information to participants in a streaming multimedia session. RTCP gathers statistics for a media connection and information such as transmitted octet and packet counts, lost packet counts, jitter, and round-trip delay time. An application may use this information to control quality of service parameters, perhaps by limiting flow, or using a different codec.
The RTSP protocol has similarities to HTTP, but RTSP adds new requests. While HTTP is stateless, RTSP is a stateful protocol. A session identifier is used to keep track of sessions when needed; thus, no permanent TCP connection is needed.