[MPlayer-dev-eng] [PATCH] Network synchronized playback using UDP

[Jason Holt]

Attached the patch for real this time.

Using a threshold of 0.15 s is a bad choice if you expect keyframes to
> be seconds apart. The threshold should be a value where we expect
> pausing or decoding fast to match seeking as syncing methods, so it
> should be of about the same magnitude as keyframe interval, probably a
> second or a few.


Okay, I think I understand.  If you keep THRESHOLD to be, say, half the
keyframe interval or more, then seeking backward should remain closebehind
and you can "run" to catch up.

If THRESHOLD is too low, say 1s threshold for a 5s keyframe interval, then
if the master is at 10 and seeks to 8, you might end up at 5 and block.
Then you'll seek to 8.1 from 5 and either jump to 10 (and stay there or
maybe flip back and forth between 10 and 5 until the master gets to 9), or
stay at 5 until the master gets to 9.

If THRESHOLD is too high, say, 10s for a 5s keyframe interval, then if the
master seeks forward to 17, you'll "run" to catch up even though you could
have seeked to 15 first.

So if you have videos with varying keyframe intervals, you'd want to leave
it set for the longest interval, which means more running than necessary on
forward seeks in videos with low keyframe intervals.  Don't keyframe
intervals vary for some codecs?  I'm not sure how I'd go about finding out
what the keyframe intervals were for a video file. So that's the big concern
I have with your approach.


 >       if (my_position < udp_master_position + udp_timing_tolerance) {
> >         // play immediately
> >       } else {
> >         float timing_error, absolute_timing_error;
> >         float master_position = wait_for_udp(udp_port);
> >
> >         if (master_position == -1.0) {
> >           // udp timed out.  use the old value
> >         } else {
> >           udp_master_position = master_position;
> >         }
> >
> >         // timing_error < 0 means we're behind the master
> >         timing_error = mpctx->sh_video->pts - udp_master_position;
> >         absolute_timing_error = (timing_error < 0) ? -timing_error:
> > timing_error;
> >
> >         if (absolute_timing_error > udp_timing_tolerance ) {
> >           abs_seek_pos=SEEK_ABSOLUTE;
> >           rel_seek_secs=master_position;
> >         }
> >       }
>
> This looks inferior to my suggestion, as you don't guarantee getting the
> slaves exactly in sync unless you use some infinitesimal
> udp_timing_tolerance, and if you do that then you need to rely more on
> demuxer seek behavior to get sync in practice.


You should think of udp_timing_tolerance as a completely different variable
than THRESHOLD.  THRESHOLD tells your algorithm when to run instead of
seeking.  In my approach, when the master seeks, the slave always seeks, but
is guaranteed to only seek backward once.  So it doesn't have to approximate
what the keyframe interval is.

udp_timing_tolerance is just there for videos with very slightly uneven
frame spacing (less than one frame period).  Let's say master and slave use
videos with exactly lined up pts.  Then you can set udp_timing_tolerance=0
and you'd still be okay.

Let's say the master's pts values vary by a few ms for some reason (does
that actually happen?)  If you had udp_timing_tolerance=0, then when you're
at 10.0s and the master is at 10.002s, it'll try to seek, which isn't
desirable.  So set it to something bigger than the variance (just a few ms)
and smaller than the frame period (generally 20ms or more) and you're fine.

If we go with your algorithm, it'd probably be good to include a similar
kind of "epsilon" value; if the master is at 2.999 and the slave is at
3.000, your algorithm will wait until the master's next frame to advance.
(I always get nervous relying on == with floats).

I suppose my algorithm would have trouble if the master was playing a 10fps
file and the slave was playing a file with 10.1fps frame timestamps.  The
slave would constantly be seeking, trying to get the frames to line up.  In
some of the versions I tried, I used both a seek_threshold variable to
decide when it's worth seeking, and a udp_timing_tolerance to ignore tiny
variations in pts.  So maybe my approach needs to do that, although I don't
think the case of "synchronized video playback on files with different fps"
should be very common.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mplayer-udp-patch-3.diff
Type: text/x-diff
Size: 6408 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20090326/954b1305/attachment.diff>