On 12/18/18 12:11 PM, Samuel Sieb wrote: > On 12/17/18 5:13 PM, Rick Stevens wrote: >> Most streaming platforms now use quasi-HTTP connections to packetize the >> stream content (HLS, HDS, MPEG-Dash, et al.). As clients connect, >> they're given a "playlist" of these packets. Depending on the server and >> how it's set up, the server may have "n" "current" chunks, passes "n-1" >> chunks in a playlist, and expect the player to request another playlist >> when the last chunk starts playing. The gotcha here is that each client >> will get a slightly different playlist. Synchronization between multiple >> clients is almost impossible in this scenario if the current chunk list >> is more than one. One can try to mitigate it by making the current >> chunklist and the playlist exactly the same length, but that's not >> always possible. > > What is needed in this case is an external synchronization to tell the > players where they should be in the stream. However, in almost all > internet streaming applications synchronization is irrelevant. > >> Older technologies such as Icy (Shoutcast/Icecast) and RTSP (the old >> RealNetworks protocol) do support client synchronization (sorta), but >> due to the inherent latencies in decoding the data, absolute >> synchronization is also difficult (you'll hear the differences). >> >> As long as the data is packetized, seamless synchronizing among multiple >> clients is almost impossible IMHO. There's almost always a lag of some >> sort. It's not like broadcast radio or TV. Even digitized TV signals >> will display differently on different TVs in the same room due to signal >> reflections, hardware differences in the decoders, software, etc. > > LMS has very tight synchronization. I have a client playing on the > stereo and one on my laptop. If I stand between the rooms, there is no > perceptible difference in the timing. Are you speaking of Logitech Media Server? > It uses its own protocol and I > assume there is some timing information involved. Remember that the > original question was for an internal LAN, not over the internet. Yes, it uses its own protocol, which means the clients must grok it and that will restrict its use. In a LAN environment, where you have very tight control over which clients you use, yes, it may be a valid option. Note that the "standard" packetizing protocols will exhibit these synchronization issues even on a LAN because you have no control over the clients' playlist request timings due to the inherent asynchronous, transaction-oriented nature of the connections. If you could control that, then things would be different and it would require some sort of out-of-band signalling. The downside to the older, connection-oriented protocols like RTSP is that any given server could easily be saturated with connections. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@xxxxxxxxxxxxxx - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - Blessed are the peacekeepers...for they shall be shot at - - from both sides. --A.M. Greeley - ---------------------------------------------------------------------- _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
