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. 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.