[mythtv-users] Way out idea on watching same thing in multiplerooms
nick.rout at gmail.com
Mon Jan 4 21:47:52 UTC 2010
On Mon, Jan 4, 2010 at 10:24 PM, Tortise <tortise at paradise.net.nz> wrote:
> ----- Original Message ----- From: "Nick Rout" <nick.rout at gmail.com>
> To: "Discussion about mythtv" <mythtv-users at mythtv.org>
> Sent: Monday, January 04, 2010 9:03 PM
> Subject: Re: [mythtv-users] Way out idea on watching same thing in
> On Mon, Jan 4, 2010 at 5:04 PM, Christopher X. Candreva
> <chris at westnet.com> wrote:
>> On Mon, 4 Jan 2010, tortise at paradise.net.nz wrote:
>>> this might work. I think the elegant and proper answer lies in multicast
>>> streams, either from the FE or perhaps preferably the BE. Using multicast
>>> quite simply avoids any sync issues. Nick Rout made a suggestion that
>> I don't think so. Think of two playback units with different sized
>> Without sync data they can be at different points in the multicast stream.
>> The stream starts comming in at the same time, but a system waiting for a
>> (say) 20 meg buffer to fill will start after one waiting for a 10meg
>> to fill. Then when the master pauses, will simple tell the others
>> to pause too ?
> In my case, Yes!
> If the master decides to rewind to hear the last line again,
>> will the other follow ?
> In my case, Yes!
> If the clients are not synchronised all the time, then there would be no
> point in using multicast. I was seeking all clients synchronised, which is
> one reason I see multicast as a good option.
>> Multicast solves a different problem, not sending the same data over the
>> network two or three times. Perhaps for a situation where you had 20 or
>> screens to sync (like a mall I was in recently with monitors showing the
>> same cartoons everywhere) that might be usefull. I don't think the average
>> 100mbit home network is going to be overloaded by 2 or 3 machines watching
>> at once.
>> Again thinking broadly, and I know I'm going to mix metaphores here, what
>> I'm suggesting should be possible by piping something like the regular
>> standard out text stream of mplayer into the telnet interface of a myth
>> frontend. All it has to say is play this, and this is where in the media
>> want to be.
>> How to access it -- NFS, SMB, multicast stream, or even a copy of the same
>> file on a local disk -- is a separate problem.
>> I entirely agree with you, my contribution to tortise's other thread
> was to point out how multicast might be achieved, I never claimed it
> would produce in sync video in every room. Such is hard to achieve.
> There are two open source projects that I know of that have achieved
>> 1. squeezebox .....
>> 2. linuxmce .....
>> The code base of these two projects may provide good clues on how to
> get what you desire. After all the GPL allows this!
> 3. VLC.
Where is this functionality in vlc? And don't tell me it can
multicast, I know that. multicasting, as explained many times before,
does not result in precise synchronisation over any number of
different clients with different latencies.
> I have already had VLC streaming via multicast. (Tested independent
> of Mythtv) Its easy to do and works well - I tested one VLC server and at
> least two clients using H.264 files and I think I did mpeg2 from memory
> also. What I've next to do is add this into myth in some rough fashion.
> (Shame I can't use VLC (just set it that is, presumably it could be coded
> in however I am not up to that at the moment...) as the player for recorded
> files - it could stream multicast as well)
> There are various user models here.
> Having multiple front ends start synchronised but maintain individual
> control with pause fast forward etc was not what I was seeking. This seems
> to me to be closer to what we already enjoy, (and possibly more what ChrisXC
> is seeking?) with multiple independent frontends now able to function
> independently, the main issue in that case seems to be starting at the
> appropriate bookmark / place holder etc.
> In more detail I am after a fully synchronised stream that the same thing
> happens to on all clients simultaneously, that seems functionally the same
> as Chris Pinkham's description, just it seems achieved different ways. (Of
> course other frontends would also function independently while this is all
> happening) In my case I could see one master and maybe four "followers" /
> slave clients which seems a lot of replicated LAN traffic. Multicast seems
> to me more efficient - and scaleable. I was just looking for that
> synchronisation for a start however remote control is the next issue, I was
> expecting that any remote control linked into that server would control
> things - e.g. pause would pause all the clients of that stream. (It seems
> that might be relatively easy to do by telnetting into the master FE - and
> may be similar to the "switch" command suggested by Chris P?) The ultimate
> RC I had in mind was a WiFi Cell Phone running a browser control app that
> could control the multicast server FE - from all rooms.
And who gets the control? You? The kids? I'd be mighty peeved off if I
had to accept a pause in a show because someone at the other end of
the house needed a pee or received a phone call.
> The slave clients do
> not need to be mythTV, they can be VLC, or as Nick has already pointed out,
> the slave clients could be mplayer using vdpau. Of course in the long run
> full integration within mythtv seems the preferable solution, I appreciate
> there may be quite a lot of patching to achieve that though. I am just
> seeking to get a working model as a start.
> Its also probably relevant to note that Chris Pinkham is very likely to be
> in a better position to advise the better method to achieve all this,
> however from his comments its not clear to me how much he considered
> multicast against the alternative outline he made. Can you comment further
> Chris P?
More information about the mythtv-users