[Mesa-dev] [PATCH] st/va: delay calling begin_frame until we have all parameters

[Nayan Deshmukh]

The patch is Reviewed-by: Nayan Deshmukh <nayan26deshmukh at gmail.com>



On Mon, Jan 23, 2017 at 7:01 PM, Christian König
<deathsimple at vodafone.de> wrote:
> Ah, yes of course. If we delay creating the decoder we need to call
> begin_frame() again as well.
>
> Please review and/or test the attached patch. Andy I did understand you
> right that this is already a Tested-by from your side, isn't it?
>
>> I am wondering if calling decode_bitstream one at a time for each
>> buffer is similar to
>> calling it with all buffers at once?
>
> Yes, that is correct. It's just not as efficient.
>
> One problem with VA-API is that it doesn't seem to guarantee that buffers
> stays around after handing them of to the decoder (the ownership handling of
> buffers and surfaces is a totally mess).
>
> So we would need to make a copy of the buffer content to submit it again all
> at once.
>
> Regards,
> Christian.
>
>
> Am 21.01.2017 um 20:46 schrieb Andy Furniss:
>>
>> Nayan Deshmukh wrote:
>>>
>>> Hi Christian,
>>>
>>> The new patch leads to seg fault on my system. You forgot to set the
>>> needs_begin_frame to true when the decoder is created. Here's diff for
>>> reference:
>>
>>
>> Setting true there seems to fix, though only a quick test.
>>
>> The patch below sets false :-)
>>
>>> --------------------------------
>>> diff --git a/src/gallium/state_trackers/va/picture.c
>>> b/src/gallium/state_trackers/va/picture.c
>>> index e75006d..a51e482 100644
>>> --- a/src/gallium/state_trackers/va/picture.c
>>> +++ b/src/gallium/state_trackers/va/picture.c
>>> @@ -178,6 +178,8 @@ handlePictureParameterBuffer(vlVaDriver *drv,
>>> vlVaContext *context, vlVaBuffer *
>>>
>>>         if (!context->decoder)
>>>            return VA_STATUS_ERROR_ALLOCATION_FAILED;
>>> +
>>> +      context->needs_begin_frame = false;
>>>      }
>>>
>>>      return vaStatus;
>>> ----------------------------------
>>>
>>> I am wondering if calling decode_bitstream one at a time for each
>>> buffer is similar to
>>> calling it with all buffers at once?
>>>
>>> Cheers,
>>> Nayan
>>>
>>> On Thu, Jan 19, 2017 at 8:36 PM, Andy Furniss <adf.lists at gmail.com>
>>> wrote:
>>>>
>>>> Andy Furniss wrote:
>>>>>
>>>>>
>>>>> Christian König wrote:
>>>>>>
>>>>>>
>>>>>> Hi Andy,
>>>>>>
>>>>>> Am 19.01.2017 um 11:46 schrieb Andy Furniss:
>>>>>>>
>>>>>>>
>>>>>>> I think you are right about the slices, the failing vids are
>>>>>>> blu-ray/tv.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> https://drive.google.com/file/d/0BxP5-S1t9VEEZlozcjVUZ1lDbWM/view?usp=sharing
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Thanks for the link, if you have time please give the attached patch a
>>>>>> try.
>>>>>>
>>>>>> It should fix the issue, but I currently don't have a test system for
>>>>>> VAAPI ready so I can't confirm it of hand.
>>>>>
>>>>>
>>>>>
>>>>> It doesn't fix properly. The vid will play normally after a second,
>>>>> but during that second I get to see many flash frames of gpu mem.
>>>>>
>>>>> Lucky I chose this sample out of several as the patch does seem to
>>>>> fix a couple of other previously failing vids.
>>>>
>>>>
>>>>
>>>> Though more testing shows it also regresses previously working vids,
>>>> some as
>>>> above, but one never "starts" and is total junk.
>>>>
>>>>
>>>>
>>>
>>
>