[MPlayer-dev-eng] New patches coming

[Dan Oscarsson]

On 2010-05-14 at 16:48 +0300 Uoti Urpala wrote:

> > The major parts include new more stable audio pts generation, new video
> > frame scheduling taking into account spacing between vsyncs and time of
> > vsyncs (Uoti have something like that in git implemented in vdpau. My
> > implementation is in mplayer and could work with other video drivers
> > then vdpau, though I have currently only modified vdpau to give needed
> > information), and matching playback speed to display refresh rate.
> 
> What I have already implemented for vsync-aware frame timing has more
> functionality than your version.

Compared to my implementation of a year ago. My current implementation
is in mplayer.c where it schedules frame display to nearest vsync to
time it is intended to be displayed. Something like your version, but
mine is in mplayer.c and can be applied to other video out drivers.

Though I have compared my original in vdpau, yours and my new one, and
my old one in vdpau was quite good despite being very simple.

>  Basing playback speed on display
> refreshes is a feature that could be useful for some use cases, but at
> least your previous implementation of it had significant problems.

My current implementation is very much different with all logic in
mplayer.c.


> 
> >  - Fix so pts reordering works even after a seek returns first
> >    frame with undefined pts
> 
> Would probably be more important to fix the demuxer in question so that
> it doesn't return video frames without pts like that...

Agreed, but as long as they are not fixed in demuxer I think it is
better to handle that case instead of playing a video incorrectly.
The case I have seen is the normal mpeg-ts demuxer that does it wrong.
It works in lavf mpeg-ts demuxer but that one returns worse audio pts.


> >  - Get time in 64 bit quantities so it does not wrap
> 
> This does not improve anything by itself, since wrapping doesn't
> currently cause problems.

Cannot use wrapping time in my scheduling code.

> 
> >  - Much more stable audio pts values (for example mp3 pts generation
> >    varies around correct value in normal mplayer)
> 
> This doesn't sound like you'd have made any real improvement in the
> area. The mp3 variation you mention is not due to any general audio pts
> handling issue but due to specific issues with the particular decoder
> (and in some case less than perfect video files). If you needed to add a
> stabilizing "post-processing" layer - which is about the only "general
> audio pts" change you could have done for stabilization - then I'd guess
> that's because of problems you caused yourself with the "A-V sync based
> on pts timing" change below.

The most common problem I have found is demuxing audio streams with
variable bit rate that are often not giving correct pts. It is not just
mp3. The code I have added let pts follow the decoded stream which have
a constant bitrate. And yes, if you use pts based timing and scheduling
you want the pts values to be correct.
 
> 
> >  - Vdpau enhancements, vsync interval detection, vsync time detection,
> >    drop frames if too far off, fixes to reduce flashing
> > 
> >  - A-V sync based on pts timing, frame scheduling taking into account
> >    time between vsyncs and time of vsyncs to display frames at best
> >    moment
> 
> The VDPAU/vsync part sounds like a (much) more limited version of the
> functionality already in git.

The vdapu vsync part is because in cases with high cpu load, system load
or other cases, so sleeps and timers goes wrong so even the best
scheduling of frame display goes wrong.  This code will, as a fall back,
handle this to avoid frames being display to far off from intended time.

My code corresponding more or less to your code in your git, is in my
code in mplayer.c. I use svn version of mplayer.

> 
> If the "A-V sync based on pts timing" is similar to your earlier
> patches, it doesn't give much benefit by itself while it does have new
> problem cases.

Yes, it introduces new problem cases, and it reveals problems in other
parts of mplayer. But it facilitates scheduling of frames, a future
where several frames may be decoded in advance, no need for autosync or
-mc options, starting video before audio. And probably more things I do
not remember just now.


> 
> >  - Sync audio and video after a pause so it starts in sync
> 
> You mean with audio outputs that can't pause the playback and don't keep
> track of audio lost either? Otherwise pause shouldn't cause loss of
> sync.

The oss driver flushes all audio data on pause so it starts out of sync
when resumed. Also pulseaudio have problems after pause.

> 
> >  - changing speed keeps a-v in sync
> 
> I doubt you've actually managed to implement this fully, considering how
> tricky some of the issues are. Anyway small temporary sync loss doesn't
> matter much unless you try to change it automatically, so I guess
> usefulness of improvements depends on whether your speed sync change is
> usable.

While maybe not perfectly, but much better than before.
You may not view moves in 24 hz on a lcd tv with motion interpolation
but I do. And then every time mplayer have to resync audio and video
results in movie getting disrupting jumps or visually disturbing images.

> 
> >  - start audio before video, if audio stream starts before video.
> >    start video before audio, if audio stream starts after video.
> 
> This is related to the "sync after seek" behavior (at least it'll be
> inconsistent if it's implemented separately and seeking back to the
> start doesn't produce the same behavior - which btw causes some issues
> if trying to do this when there's audio but no video).

It is related.

   Dan