[MPlayer-users] UDP -udp-slave video sync

rob at goto10.org rob at goto10.org
Wed Jun 8 17:58:02 CEST 2011


 On Wed, 8 Jun 2011 17:24:41 +0200, T.Reifenrath wrote:
> I still have the same problem......
>
> I just get the new Version with this Filename: 
> MPlayer-athlon-svn-33488
>
> Tried to play the  4 Videos on a single machine with these 
> batch-files:
>
> Master:
> mplayer -udp-master  -noborder -geometry 0:0 -vf scale=128:72 
> Video1_1.mp4



 hi,
 you need to tell it the broadcast ip of your network (sudo ifconfig 
 will show you this)
 mplayer -udp-ip 192.168.1.255 -udp-master Video1_1.mp4
 HTH
 rob


> Slave1:
> mplayer -udp-slave -noborder -geometry 128:0 -vf scale=128:72 
> Video1_2.mp4
>
> Slave2:
> mplayer -udp-slave -noborder -geometry 256:0 -vf scale=128:72 
> Video1_3.mp4
>
> Slave3:
> mplayer -udp-slave -noborder -geometry 384:0 -vf scale=128:72 
> Video1_4.mp4
>
>
> Videos are running after starting the batch-files ( still get a 
> message
> "unsupported Pixelformat 61" / "unsupported Pixelformat 61" )
> But they don´t sync with the master.
>
> If I just start one of the slaves and after the master, the slave is 
> waiting
> but does nothing. When the master is finished, the slave ends, too.
> But this is only if ONE slave is started. When all slave are started, 
> just
> the first one is waiting while the others are playing.
>
> Can anybody help ???
>
>
> -----Ursprüngliche Nachricht----- From: rob at goto10.org
> Sent: Wednesday, June 08, 2011 3:40 PM
> To: Jason Holt
> Cc: mplayer-users at mplayerhq.hu
> Subject: Re: [MPlayer-users] UDP -udp-slave video sync
>
> On Tue, 7 Jun 2011 18:29:12 -0700, Jason Holt wrote:
>> On Tue, Jun 7, 2011 at 3:16 PM,  wrote:
>>
>>> On Mon, 06 Jun 2011 14:29:12 -0400, Morris Beverly wrote:
>>>
>>>> mplayer -udp-slave myvid.mkv
>>>>
>>>>> then mplayer should apparently freeze on a frame and wait for
>>>>> messages from a  master instance - for me this does not happen
>>>>> - it just plays as normal... i get no error messges about
>>>> -udp-*
>>>>> even with a -v
>>
>> ...
>>> i cc in jholt who i think is the author of the patch - and sorry in
>>> advance if i am missing something obvious
>>
>>  This does indeed appear to be broken.  It kinda works if I start
>> the master first, but not very well.
>>
>> If I start it without a master present, it renders frames as fast as
>> it possibly can, because udp_slave_sync() returns immediately, 
>> causing
>> sleep_until_update() to return immediately.
>>
>> Then, during "normal" playback, once the slave gets synced up with
>> the master and should be playing in lock step, the 
>> udp_master_position
>> ends up == MP_NOPTS_VALUE for about 10 invocations due to the
>> nonblocking get_udp trying to tell it that there aren't any messages
>> yet.  So udp_slave_sync returns immediately, and mplayer plays 
>> frames
>> as fast as it can once again.  When a datagram finally comes in, the
>> slave is way ahead of the master, so it blocks until the master
>> catches up, then runs ahead again.
>>
>> The attached patch makes the slave block if the master isn't up yet,
>> which was the original behavior, and which I think is better than
>> having it play normally in most instances.  (If you gave -udp-sync,
>> you probably want it to wait.)  And it makes udp_master_position
>> static, so that it's only set to MP_NOPTS_VALUE on startup and after
>> blocking get_udp calls.
>
> ok great thank you! - i applied the patch and now it works as 
> expected
> - the only thing i have noticed is that the audio and video go out of
> sync on the slave instance -  its as if the udp packets tell the 
> video
> which frame it should be playing but the audio doesnt jump to keep up
>
> i tried passing mplayer some flags to try and fix it -mc 1 -autosync 
> 1
> etc but none made any difference
>
> any clue how this could be fixed so the audio and video stay in sync 
> on
> the slave instances?
>
> (i know if i were doing a video wall then you could just use the 
> audio
> from one source - but this is not what i am doing)
>
> thanks for the quick reply and patch fix!
>
> rob
>
>
>
>
>
>
> _______________________________________________
> MPlayer-users mailing list
> MPlayer-users at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-users
>
> _______________________________________________
> MPlayer-users mailing list
> MPlayer-users at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-users



More information about the MPlayer-users mailing list