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

[Gareth Glaccum]

Don't know where best to respond to this thread, gossamer seems to have split it into 3 already.

I have been thinking about this problem on and off for around a year now. There are, as has already been stated, two distinct problems.
 
1) I am a frontend. What should I be doing?
The 'easiest' solution I could come up with, was a separate menu. On the 'master' front-end, you start a recording, and then pause. Register yourself with the backend that you are a 'viewing master'. Open a local port for followers. A slave frontend polls the backend for a list of masters. One is selected from the list, and a connection is made to the master frontend on the new port. This port shares data between the front-ends as to where they are in the video stream. The 'master' sends stop and start commands. The two negotiate a place in the stream the same way that NTP works. i.e. master sends 'go here, position X', slave goes to position, and after setting position, returns, 'position Y'. Master is now at position Z, so sends back to slave, go to position (Z-Y)*2+Z. This takes into account the time taken for the slave to synchonise to position X, and the data transfer/decode time, and tries to compensate for it. After a few iterations, the video
 would be almost in perfect sync, even on differing capability hardware (to view anyway). The major problem, would be the sound. We can only really see one video at a time, but we can hear two. Thus, a local 'speed' factor, or audio sync adjust kludge would need to be stored for each backend. As most hardware is likely to be of a decent standard to play back SD now anyway, hopefully it should be too bad on lipsync.

2) I am a data-stream (video), how do I get where I am going?
In an ideal world, multicast would be great. 
However, in businesses where there are IT techs paid to set networks up properly, most networks I see are not set up correctly for multicast. A hub would not multicast, it broadcasts multicast streams. A switch set incorrectly will most likely broadcast multicast streams. This means that you could be swamping devices on the network with video data. My TV at home has a 10Mb/s data port, if I broadcast a video stream to it, it is going to be overwhelmed. I suspect there are more home networks that are better set up than office networks, but we must consider the case where multicast does not work, and it is instead broadcast to all devices.
That said, and if we ignore that major downfall for a moment, what would be ideal, is for the recording to be broken into chunks. A chunk is transfered to a machine via multicast, then the next most likely chumk is sent, until the buffer is filled. Therefore, these chunks need to be half the size of the smallest buffer in the group. This would allow the buffer to be around 50% effective, and still allow random controls to be made. When a new frontend joins a group, it needs to report its buffer size, and they all must re-negotiate what size the chunks should be. The position in the stream is calculated by the master frontend as an offset from the start of chunk X.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mythtv.org/pipermail/mythtv-users/attachments/20100105/29ac21c2/attachment.htm>