[Mesa-dev] [PATCH] vl/mpeg12: implement inverse scan/quantization steps

[Ilia Mirkin]

On Wed, Jun 26, 2013 at 4:33 AM, Christian König
<deathsimple at vodafone.de> wrote:
> Am 26.06.2013 05:29, schrieb Ilia Mirkin:
>
>> On Mon, Jun 24, 2013 at 2:13 PM, Christian König
>> <deathsimple at vodafone.de> wrote:
>>>
>>> Am 24.06.2013 18:39, schrieb Ilia Mirkin:
>>>
>>>> On Mon, Jun 24, 2013 at 4:48 AM, Christian König
>>>> <deathsimple at vodafone.de> wrote:
>>>>>
>>>>> Am 23.06.2013 18:59, schrieb Ilia Mirkin:
>>>>>
>>>>>> Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
>>>>>> ---
>>>>>>
>>>>>> These changes make MPEG2 I-frames generate the correct macroblock data
>>>>>> (as
>>>>>> compared to mplayer via xvmc). Other MPEG2 frames are still misparsed,
>>>>>> and
>>>>>> MPEG1 I-frames have some errors (but largely match up).
>>>>>
>>>>>
>>>>> NAK, zscan and mismatch handling are handled in vl/vl_zscan.c.
>>>>>
>>>>> Please use/fix that one instead of adding another implementation.
>>>>
>>>> Yes, I noticed these after Andy pointed out that my patch broke things
>>>> for him. Here's my situation, perhaps you can advise on how to
>>>> proceed:
>>>>
>>>> NVIDIA VP2 hardware (NV84-NV96, NVA0) doesn't do bitstream parsing,
>>>> but it can take the macroblocks and render them. When I use my
>>>> implementation with xvmc, everything works fine. If I try to use vdpau
>>>> by using vl_mpeg12_bitstream to parse the bitstream, the data comes
>>>> out all wrong. It appears that decode_macroblock is called with data
>>>> before inverse z-scan and quantization, while mplayer pushes data to
>>>> xvmc after those steps. So should I basically have a bit of logic in
>>>> my decode_macroblock impl that says "if using mpeg12_bitstream then do
>>>> some more work on this data"? Or what data should decode_macroblock
>>>> expect to receive?
>>>
>>>
>>> Yes exactly, for the bitstream case decode_macroblock gets the blocks in
>>> original zscan order without mismatch correction or quantification.
>>>
>>> You can either do the missing steps on the gpu with shaders or on the cpu
>>> while uploading the data and use the entrypoint member on the decoder to
>>> distinct between the different usecases.
>>
>> That sounds reasonable. But I'm looking at the MPEG-2 spec, and it
>> goes something like (7.4.5):
>>
>> if ( macroblock_intra ) {
>>    F’’[v][u] = ( QF[v][u] * W[w][v][u] * quantiser_scale * 2 ) / 32;
>> } else {
>>    F’’[v][u] = ( ( ( QF[v][u] * 2 ) + Sign(QF[v][u]) ) * W[w][v][u] *
>> quantiser_scale ) / 32;
>> }
>
>
> Only the multiplication with W[w][v][u] (and IIRC the divide with 32) isn't
> done in decode_dct, since everything else depends on the bitstream context.

I must be totally blind. Can you point out exactly where

( QF[v][u] * 2 ) + Sign(QF[v][u])

is being done for the non-intra case in decode_dct? I'm only seeing
QF[v][u] * quantiser_scale, never the + Sign() part.