[MPlayer-dev-eng] demux_pva fixes

[Matteo Giani]

Hi and thanks for taking the time to review!

On Thu, Oct 13, 2011 at 7:03 PM, Reimar Döffinger
<Reimar.Doeffinger at gmx.de>wrote:

> Why did you leave the DEMUX_PVA_MULTIDEC_HACK one in?


In the current form it effectively remains a "hack" so I did not want it to
get forgotten, but happy to take out the #ifdef and comment appropriately.
Libavformat actually works around this issue in a more elegant way (making
use of length fields within the PES headers) which, for the sake of having
tidier code, I will look into replicating here when I resubmit.


> Could you be specific? The http://samples.mplayerhq.hu/PVA/PVA_test.pva
> one at least seems to work fine, raising the suspicion that the
> failing files might be special, broken or the demuxing is failing
> in other ways for them.
>

There were two separate issues that showed up:
* PVA_DeejayTV_*.pva would play without audio. I came to believe the reason
for this was that the first audio packet in the file did not correspond to
the start of a mpeg audio frame. The decoder complained about missing frame
headers but without the needs_parsing flag set would not "skip" to the next
frame and thus would not start decoding.
* PVA_FashionTV* and PVA_VideoItalia* would either fail playing, or start
and then fail, due to a glitch that caused the demuxer to fail returning
data if it encountered an audio PES header without a PTS field (due to an
erroneous "break" statement, line 338 of current svn demux_pva.c)
* PVA_test had none of these two and as such played fine


> > After looking into it, I realised the demuxer did not set the
> "needs_parsing" flags inside the audio and video sh structures, which in
> particular for audio caused the mentioned breakage.
>
> I don't think that flag has any relevance for video so far.
>

Understood, thanks.

I will resubmit as separate patches against current svn as per Dominik's
request as soon as I get the chance, hopefully over the weekend.

Regards,

Matteo