[MPlayer-dev-eng] [RFC][PATCH]Workaround to play PAFF samples

[Uoti Urpala]

On Tue, 2009-08-18 at 20:18 +0200, Michael Niedermayer wrote:
> besides as iam already here, could someone summarize what the PAFF
> issue in mplayer was exactly in fine technical detail.

There are currently two problems. First, timestamps for raw h264 from
both the internal demuxer and lavf are broken. Second, even if the pts
timestamps were accurate, the current timing code wouldn't work well
with the interlaced-h264 behavior where the libavcodec decoder will take
two timestamped packets for every frame it outputs. As a result of those
problems timing is inaccurate, and in some cases MPlayer lost the
overall A/V sync when timestamps frequently moved backward. The overall
sync loss should be fixed in git, but it's still not quite accurate -
you can only do so much with broken timestamps without actually fixing
them.

I tried writing a new timing mode that would avoid the MPlayer-side
problem with the decoder only outputting a frame for every two input
packets, but the lavf timestamps were broken enough that it was no
improvement. I tested both pts and dts modes (a pts mode using
reordered_opaque and a natural dts mode) but both timestamps were too
broken for MPlayer-side changes to give any improvement.

Those tests were a while ago so if there have been recent changes that
should have improved lavf timestamps then it could be worth trying
again.

By the way, reordered_opaque doesn't seem to work when using VDPAU
(because it doesn't have the output frames the current implementation is
based on I guess). That'd also need to be fixed for pts timing using it.


> Iam asking because i remember it only halfway ATM and maybe we could
> find some solution if we spell out and read what exactly is the problem

If lavf timestamps worked - at least one of pts and dts - then it could
be fixed.


> from lavf side, h264 timestamps still are not always guranteed to
> be correct, i had no luck convincing people to implement all cases
> of the spec ... but thats not PAFF specific ...

In the PAFF case it looked significantly worse than just "not always
guaranteed to be correct", at least when I last tested. Dts going
backwards for a significant portion of the packets etc. I'm not sure
exactly which portion of cases was affected (I haven't tested a lot of
mpeg container stuff) and if it was exactly just PAFF samples, but I
think that's the problem people most often encounter anyway.