[jordanbaucke]

@zbobet2012 makes sense, certainly, you can shrink the chunk-size down to 2 seconds, I wonder if it's not practical to do though wouldn't the practicality of setting up a setup > teardown of a new HTTP connection, fetching the next chunk, etc. cause inconsistency in completing this procedure by the time a 2 second chunk has played out.

I believe people have used WebSockets to push these segments? Since once you have established one TCP socket connection you don't have to setup a new "session" for each discrete segment?

[zbobet2012]

We (Comcast/NBC) run 2s segments for our video streaming service which is... substantially larger than this. High latency mobile networks on clients which don't do keep alive can be _somewhat_ problematic. The best fix for that is just to have a very fast/close CDN edge node.

[r1ch]

HTTP keepalives prevent the excessive connection requests. The main issue with HLS distribution is TCP sucks over high latency links, so you have to have edges near your users.

[jordanbaucke]

Gotcha! I've also heard of people using WebRTC to reduce latency by setting up a direct-to-user link between the ingest server and the end-user? Any idea how this helps?

[r1ch]

Beam (recently acquired by Microsoft) does very similar to this. Rather than wait for the whole X second segment to be built and distributed, they apparently stream MPEG atoms through websockets which are them reassembled in JS and presented via media source extensions. At this point you may as well have re-invented RTMP, minus the Flash dependency :).

[zbobet2012]

Yep^^

In addition there is a major encoding downside to this. If your encoder can grab a whole 2-10s chunk of video it can produce a better quality stream. This is actually _super_ important for producing good video quality (especially on things like sports streams).