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

[Christian König]

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.
>>>
>>>
>>>
>>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-st-va-make-sure-that-we-call-begin_frame-only-once-v.patch
Type: text/x-patch
Size: 2529 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170123/0ebc46a9/attachment.bin>