[Libva] [PATCH] mpeg2: fix incorrect slice_vertical_position from codec layers.

[Gwenole Beauchesne]

Hi,

>> > Why is the workaround applied for vpos == last_vpos + 2 ? I think it is
>> > right that vpos = 0, 2, 4, ... for top field and vpos = 1, 3, 5, .. for
>> > bottom field.
>>
>> No, this is wrong, and that was the bug. The codec layer passed wrong
>> info. The bitstream really has linearly increasing
>> slice_vertical_position, and this is what is expected by PVR: the
>> original bitstream info. Of course, we could have fixed PVR, but if
>> this is for all drivers to have the same workaround, that's a bit
>> silly. Let's use the proper way.
>
> I'm a little confused. Do you mean PVR driver can work well without a
> workaround even if the codec layer passed wrong info ?

No, it outputs garbage in this case as it requires this sequence for
either field: 0, 1, 2, 3, ...

>> Besides, some other PVR drivers can't
>> be fixed. Besides, this is extra computation we don't need. The Gen HW
>> also computes the target line correctly, based on TFF and first field.
>>
>> > I still met GPU hang issue when playing some mpeg2 conformance tests
>> > such as sony-ct1.bits.  The root cause is that the codec layers pass
>> > wrong parameters to the driver.  I think a safe way to avoid GPU hang
>> > issue is not to decode the stream.
>>
>> sony-ct1.bits works well, both with mplayer and gstreamer. For the
>> former, you need 2 patches I posted to the ffmpeg/libav dev lists. It
>> seems this also fixes support for DXVA along the way on Windows. :)
>>
>
> The hang issue disappears after applying your patches for FFmpeg. But
> the decoded picture is still wrong at the beginning.

Yes, this is what I am working on. FFmpeg allocates a dummy frame with
nothing decoded into it. It just serves as a forward reference picture
in the case the first I frame is actually the bottom field. Needless
to say, this confuses the generation of reference frames for the HW.
As memory is allocated with whatever initial state in it. There is
also garbage generated on the first 3 frames on PVR due to the same
problem.

This is a combination of FFmpeg and driver bugs. It should be possible
skip this extra dirty reference. We probably should be re-using the
original reference (current, but other field picture), as recommanded
in HW specs.

On the Gst side, there is also a bug because reference frames are
maintained per PTS, whereas I should be using TSN. The former was
wrong anyway. So two fixes are needed on the Gst side: fix sequence
PTS reference when none is valid from demuxer, fix DPB to handle
references per POC/TSN.

I am testing local patches for all of those.

Regards,
Gwenole.