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

[T.Reifenrath]

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

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