Answers.Body: <p>CDNs. CDNs make delivering small static HTTP objects much cheeper due caching efficiency, supply and demand, and stateless servers (hence more viewers per server). Second is live video. HTTP does not really work well given a file of infinite length. Hence breaking the stream into segments to make the CDNs job easier.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-04T18:56:17.390Z
Answers.Text: interesting comment about caching, but couldn't you theoretically cache fixed-length segments of the bytestream in the RAM of your CDN's proxies or just stream from the streaming server continuously to the proxies and then the proxies would forward the stream to the client? Also, could you explain a little more about why HTTP doesn't work well for live streaming?
Answers.UserDisplayName: Æðelstan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-04T19:01:18.000Z
Answers.Text: Yes, you could do that. But that is a second technology that needs to be developed deployed and maintained. CDNs will charge a premium for that effort. In fact you can get RTMP services from CDNs, but it costs more per bit delivered. HTTP servers work best when they know the length of the asset before it is sent. A live stream has an undefined length. So its more difficult to manage. This is why video are broken into segments of known size.
Answers.UserDisplayName: SlimSCSI
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-04T19:09:19.627Z
Answers.Text: I see, very interesting, I didnt't know about the costs. Is that the reason why RTMP has basically died in the last 2-3 years? As for HTTP, yes, I was just thinking of a custom client not something generic, you are right. Upvoted your answer, but don't know if you can see it (don't have 15 rep here).
Answers.UserDisplayName: Æðelstan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-04T19:13:39.867Z
Answers.Text: This plus the stateless nature of HTTP makes it easier to achieve higher throughput per physical server.
Answers.UserDisplayName: SlimSCSI
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-04T19:20:46.983Z
Answers.Text: RTMP is also dying as it is a Flash based technology, and flash does not work on mobile.
Answers.UserDisplayName: SlimSCSI
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-04T19:22:16.127Z
Answers.Text: true... I was unable to play RTMFP streams for an Android application using Flash 11.1 :(
Answers.UserDisplayName: Æðelstan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-04T16:00:17.727Z
Answers.LastActivityDate: 2015-11-04T16:00:17.727Z
Answers.UserDisplayName: SlimSCSI
Body: <p>I've been becoming familiar with a lot of streaming protocols in the past few years, but now that I ask myself, I don't know what are the advantages of protocols such as HLS or HDS which chunk the stream compared to a direct-from-memory bytestream like HTTP octet-stream, RTMP or RTSP can do for example.</p>
  
  <p>I would think that the I/O necessary to produce the fragments makes it less efficient and, for HLS, TCP already insures data reliability, so is it not redundant to use an MPEG Transport-Stream over TCP?</p>
  
Tags: <streaming>
Title: Advantage of HLS/HDS over direct bytestream
UserDisplayName: Æðelstan
ThreadText: # Advantage of HLS/HDS over direct bytestream
  
  (Asked by: username_0 on 2015-11-04)
  
  I've been becoming familiar with a lot of streaming protocols in the past few years, but now that I ask myself, I don't know what are the advantages of protocols such as HLS or HDS which chunk the stream compared to a direct-from-memory bytestream like HTTP octet-stream, RTMP or RTSP can do for example.
  
  I would think that the I/O necessary to produce the fragments makes it less efficient and, for HLS, TCP already insures data reliability, so is it not redundant to use an MPEG Transport-Stream over TCP?
  
  **Tags:** streaming
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2015-11-04. Score: 1
  
  CDNs. CDNs make delivering small static HTTP objects much cheeper due caching efficiency, supply and demand, and stateless servers (hence more viewers per server). Second is live video. HTTP does not really work well given a file of infinite length. Hence breaking the stream into segments to make the CDNs job easier.
  
  > **Comments:**
  > **username_0**: interesting comment about caching, but couldn't you theoretically cache fixed-length segments of the bytestream in the RAM of your CDN's proxies or just stream from the streaming server continuously to the proxies and then the proxies would forward the stream to the client? Also, could you explain a little more about why HTTP doesn't work well for live streaming?  
  > **username_1**: Yes, you could do that. But that is a second technology that needs to be developed deployed and maintained. CDNs will charge a premium for that effort. In fact you can get RTMP services from CDNs, but it costs more per bit delivered. HTTP servers work best when they know the length of the asset before it is sent. A live stream has an undefined length. So its more difficult to manage. This is why video are broken into segments of known size.  
  > **username_0**: I see, very interesting, I didnt't know about the costs. Is that the reason why RTMP has basically died in the last 2-3 years? As for HTTP, yes, I was just thinking of a custom client not something generic, you are right. Upvoted your answer, but don't know if you can see it (don't have 15 rep here).  
  > **username_1**: This plus the stateless nature of HTTP makes it easier to achieve higher throughput per physical server.  
  > **username_1**: RTMP is also dying as it is a Flash based technology, and flash does not work on mobile.  
  > **username_0**: true... I was unable to play RTMFP streams for an Android application using Flash 11.1 :(  
  
  ---
  
  