[mythtv-users] Way out idea on watching same thingin multiplerooms

[Simon Hobson]

Gareth Glaccum wrote:

>Chris Pinkham's idea/concept is probably the way that things need to 
>happen. A primary frontend sends commands to the slave frontends. I 
>don't know how far he got, but I think that some way of testing the 
>synchronisation of the streams at the point of output is required 
>(which gets fed back to a stream position fudge factor).

Well I thought the idea of a 'master' frontend logging timestamps of 
some key points (either keyframes, or timestamps in the program 
material) and passing that on seemed like a good idea - sorry, forgot 
who suggested it. NTP will keep clocks synchronised to better 
accuracy than we need, so if there was a way to deterministically 
take key timing info from a program stream, it would be relatively 
easy for a 'slave' frontend to compare it's own list of 
keypoint-timestamp pairs and compare then with those obtained from 
the master. This doesn't have to happen in 'real realtime', as long 
as it happens soon after the key event.

It wouldn't put any constraints on implementation other than the 
ability to a) deterministically select key points, and b) accurately 
determine the time they were displayed (or played in the case of 
sound). The slave frontends can then, after the fact, determine if 
they were on time or not, and adjust their playback accordingly.

One idea that comes to mind for key events would simply to take the 
time offset into the recording, and simply select every n whole 
seconds (whether that's every second, every 10 seconds, 60 or 
whatever). It would be media type agnostic since I imagine there will 
be material types (sound for example) that don't have key frames to 
pick on. So the master frontend would simply timestamp (for example) 
every 10th whole second into the stream and broadcast (or multicast) 
that information to the slaves. The slaves, without there needing to 
be a low latency link from the master, can then adjust their playback 
until their internally logged timestamps match those received (after 
the fact) from the master. Whether the adjustment is by stepping, or 
by adjusting playback speed, or something else, would not need to be 
defined - that could be implementation dependent on each frontend.

Also, it would not constrain the method of distribution - each 
frontend could separately stream the material from the backend, so it 
would be a separate problem to solve than the multicast one. 
Technically, though in practice unlikely, different frontends could 
stream a recording from different backends as long as the recordings 
were identical !



There could be a requirement for the master backend to delay it's 
output in some cases. If a slave determined that it could not advance 
playback any more, yet was still playing late - then you'd either 
have to accept that in some situations you would not achieve perfect 
sync, or you could require the master frontend to have a minimum 
buffering delay, or you could have a dynamic process where a slave 
frontend could ask the master to back off a bit.


As an aside, I've seen something similar used for passive monitoring 
of network performance. Two monitoring boxes (acting as tranparent 
bridges) were inserted into the network at different sites. They 
would pick packets and timestamp them, and then compare timestamps to 
passively determine latency and log the results.

-- 
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.