Create an Account
username: password:
 
  MemeStreams Logo

MemeStreams Discussion

search


This page contains all of the posts and discussion on MemeStreams referencing the following web page: Apple proposes HTTP streaming feature as protocol standard - Ars Technica. You can find discussions on MemeStreams as you surf the web, even if you aren't a MemeStreams member, using the Threads Bookmarklet.

Apple proposes HTTP streaming feature as protocol standard - Ars Technica
by Acidus at 7:56 am EDT, Jul 10, 2009

[As Apple sees it the] biggest issue with RTSP is that the protocol or its necessary ports may be blocked by routers or firewall settings, preventing a device from accessing the stream. As the standard protocol for the Web, though, HTTP is generally accessible. Furthermore, no special server is required other than a standard HTTP server, which is more widely supported in content distribution networks, and more expertise in optimizing HTTP delivery is generally available than for RTSP.

Enter HTTP Live Streaming. The basic mechanics involve using software on the server to break an MPEG-2 transport stream into small chunks saved as separate files, and an extension to the .m3u playlist specification (.m3u8) to tell the client where to get the files that make up the complete stream. The media player client merely downloads and plays the small chunks in the order specified in the playlist, and in the case of a live stream, periodically refreshes the playlist to see if there have been any new chunks added to the stream.

This is in contrast to real-time streaming, as there would necessarily be a minimum latency of whatever duration the server slices the stream into (Apple refers to 10 seconds as an example). As the server encodes the video and slices it into 10 second clips, for instance, it creates or updates a playlist for the stream with the URL of the next clip. The client begins by downloading one or more of the clips, playing them in order. As one clip plays, the client begins downloading the next specified clip until it reaches a tag in the playlist that signals the end of the stream.null

This idea sits poorly with me. The whole HTTP as the new TCP/IP has lot of ramifications people often don't discuss . Given the 33% to 66% failure rate of WAFs we as an industry obviously fail at deep packet inspection. Not to mention the resource overhead of delivering audio and video on an IP/TCP/HTTP/Video stack instead of IP/UDP/RTSP stack. I'd love to see a comparison given various network conditions of latency and loss. On AT&T like the iPhone is? You know those dropped or spotty calls? Thats AT&T consistently failing to deliver you the *compressed* equivalent of a POTS line (8 bits at 8000Hz).

Good luck with that.


 
 
Powered By Industrial Memetics