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

[Uoti Urpala]

On Thu, 2009-03-26 at 22:24 -0700, Jason Holt wrote:
> 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.

I don't think this can be described as "too low"; 1 s should work fine
for such keyframe intervals or longer ones. The slave may spend some
seconds stuck at a keyframe, but 1) this should not be the normal case
after master seeks if the slave has the same video with keyframes at
same positions, and 2) trying to catch up from an earlier position with
fast decoding can actually be an inferior choice unless all the slaves
are fast enough to decode at multiple times realtime speed.

> 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.

I think values from one second to a few should work fine for most
practical setups and videos.


>  >       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.

I did consider it obvious that it's different.

>   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.

You can't completely avoid the choice about whether to seek or not. If
master moves ahead by 0.3 s it may have been a seek or you may have lost
a UDP packet or two. You'll have to decide whether to seek or play back
faster, and IMO seeking would clearly be the wrong choice.

> 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

If the master and slave machines have different architectures then it's
at least possible that they used different precision during some
calculations.

> 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).

Probably yes; I did actually consider adding something like that, but
decided to leave such orthogonal details out of the description of the
sync algorithm itself.