[Mesa-dev] [PATCH] st/va: move YUV content to deinterlaced buffer when reallocated for encoder

[Andy Furniss]

Leo Liu wrote:
> 
> 
> On 08/25/2017 03:16 PM, Christian König wrote:
>> Am 25.08.2017 um 17:15 schrieb Leo Liu:
>>>
>>>
>>> On 08/25/2017 10:53 AM, Leo Liu wrote:
>>>>
>>>>
>>>> On 08/25/2017 02:57 AM, Christian König wrote:
>>>>> Am 24.08.2017 um 20:49 schrieb Leo Liu:
>>>>>> v2: use deinterlace common function
>>>>>> v3: make sure deinterlace only
>>>>>>
>>>>>> Signed-off-by: Leo Liu <leo.liu at amd.com>
>>>>>> ---
>>>>>>   src/gallium/state_trackers/va/picture.c | 22 ++++++++++++++++------
>>>>>>   1 file changed, 16 insertions(+), 6 deletions(-)
>>>>>>
>>>>>> diff --git a/src/gallium/state_trackers/va/picture.c 
>>>>>> b/src/gallium/state_trackers/va/picture.c
>>>>>> index 6c3c4fe..aa4062d 100644
>>>>>> --- a/src/gallium/state_trackers/va/picture.c
>>>>>> +++ b/src/gallium/state_trackers/va/picture.c
>>>>>> @@ -613,17 +613,22 @@ vlVaEndPicture(VADriverContextP ctx, 
>>>>>> VAContextID context_id)
>>>>>>      mtx_lock(&drv->mutex);
>>>>>>      surf = handle_table_get(drv->htab, context->target_id);
>>>>>>      context->mpeg4.frame_num++;
>>>>>> -
>>>>>>      screen = context->decoder->context->screen;
>>>>>>      interlaced = screen->get_video_param(screen, 
>>>>>> context->decoder->profile,
>>>>>> context->decoder->entrypoint,
>>>>>> PIPE_VIDEO_CAP_SUPPORTS_INTERLACED);
>>>>>>        if (surf->buffer->interlaced != interlaced) {
>>>>>> -      surf->templat.interlaced = screen->get_video_param(screen, 
>>>>>> context->decoder->profile,
>>>>>> - PIPE_VIDEO_ENTRYPOINT_BITSTREAM,
>>>>>> - PIPE_VIDEO_CAP_PREFERS_INTERLACED);
>>>>>> -      realloc = true;
>>>>>> +      interlaced = screen->get_video_param(screen, 
>>>>>> context->decoder->profile,
>>>>>> + context->decoder->entrypoint,
>>>>>> + PIPE_VIDEO_CAP_PREFERS_INTERLACED);
>>>>>> +      if (!interlaced) {
>>>>>> +         /* The current cases for buffer reallocation are
>>>>>> +            all from the interlaced to the deinterlaced,
>>>>>> +            and there is no case for the other way around */
>>>>>> +         surf->templat.interlaced = false;
>>>>>> +         realloc = true;
>>>>>> +      }
>>>>>
>>>>> Should we bail out with an error here when it's the other way around?
>>>> Although I cannot think of any of case that to get buffer Interlaced 
>>>> now, It's still a good idea to bail out here when it happnens
>>>> Will add it in v4.
>>>
>>> It's not a error when case like buffer is deinterlaced, and 
>>> interlaced result from query. What we need to do is to do nothing, 
>>> just ignores.
>>> I have sent out v4, please ignore it, it won't work.
>>
>> Well that's not correct either.
>>
>> When the buffer is allocated as progressive and the codec doesn't 
>> supports that we should certainly do something.
>>
>> Either bail out as an error when we encode because we can't convert 
>> progressive->interlaced (just the other way around) and/or reallocate 
>> for decoding.
> Here is current situation for  transcode
> 
> Decoder allocate I buffers as preferred, then encoder prefers as P 
> buffers , so re-allocated them to P buffers.
> and then next frame, decoder take P buffer, but not as preferred.
> 
> 3 possible ways for decoder to go:
> 
> 1. ignores the the Preferred, and keep buffer as P, and pipe goes. V3
> 2. go for Preferred, and then do endless alloc/dealloc frame by frame. V2
> 3. Bailout as error, the pipeline stops. V4

Won't have time to test till tomorrow but just getting one of the cases
I thought may work with this, that couldn't work with the env, out.

ffmpeg can (in theory anyway) do -

hwdec -> hw deinterlace -> hw encode.

Possible?