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(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
- -
- Blessed are the peacekeepers...for they shall be shot at -
- from both sides. --A.M. Greeley -
----------------------------------------------------------------------