[MPlayer-dev-eng] New patches coming

[Uoti Urpala]

On Fri, 2010-05-14 at 10:30 +0200, Dan Oscarsson wrote:
> I plan do do a little cleaning and removing unneeded debug code before
> publishing. I have split my enhancements into six small independent
> patches and seven bigger patches that must be done in order. Hopefully
> that is more acceptable for you? I have also added a special option to

Of course it's hard to comment without seeing the patches, but at least
your previous versions had problems unrelated to to any superficial
issues like splitting. So changing just that is unlikely to make them
significantly more acceptable.

> The major parts are in mplayer.c, libmpcodecs/dec_audio.c and
> libvo/vo_vdpau.c. Last year you did not want to change vdpau.c - I hope
> you are willing to change vdpau now? My changes will not work without
> changing vdpau.

That sounds like you think there was resistance for reasons like "don't
change vo_vdpau but changes to any other area would be fine". I don't
think that was the case.

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


> Summary of the most important parts of what my patches do
> 
>  - Avoid hanging waiting for pulseaudio to finish playing on exit

Bugfix?

>  - Adjust latency in pulseaudio to avoid unstable pts calculations
>    giving unstable playback

Fix something? Or add "post-processing" workarounds similar to autosync?

> 
>  - Fix so LATM is recognised better and handled better with faad
> 
>  - Reduce time to change speed with lavcresample by half

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

>  - Fix so mp_msg messages do not overwrite status line

Message output together with status line could be improved.

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

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

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

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.

>  - Make it possible to sync playback speed to display refresh rate

As said earlier, a potentially useful feature but at least your previous
implementations of it had severe problems.

>  - Sync audio and video after a seek so it starts in sync

This is something I'll implement myself at some point even if your patch
isn't applied.

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

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

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