[FFmpeg-devel] [PATCH 2/5] vulkan_decode: use the new AVHWFramesContext.opaque field

[Lynne]

Jun 13, 2023, 14:29 by anton at khirnov.net:

> Quoting Lynne (2023-06-13 06:19:34)
>
>> This depends on the previous patch, and allows moving the codec
>> profile to the new AVHWFramesContext.opaque field.
>>
>> Patch attached.
>>
>>
>> From f992905250062711fab7522906a573ff8ab5f716 Mon Sep 17 00:00:00 2001
>> From: Lynne <dev at lynne.ee>
>> Date: Tue, 13 Jun 2023 06:10:20 +0200
>> Subject: [PATCH 2/5] vulkan_decode: use the new AVHWFramesContext.opaque field
>>
>> ---
>>  libavcodec/vulkan_decode.c | 56 +++++++++++++++++++++++---------------
>>  libavcodec/vulkan_decode.h |  6 ++--
>>  2 files changed, 37 insertions(+), 25 deletions(-)
>>
>
> This will not work, because the callers are not required to call
> avcodec_get_hw_frames_parameters() and can create the frames context
> themselves.
>

Indeed they are. This commit doesn't break this.


> The decoder is then not allowed to make any assumptions about the opaque
> field.
>

Exactly. This is just for the case that the user calls avcodec_get_hw_frames_parameters.
Then, we need somewhere to put the profile.
The opaque field is only set, it is never read in this particular case.
Since it's libavcodec creating the frames context in this case, and since the user
explicitly asked for frames parameters to be set, I don't think it's a problem
to set a public field, much the same way the width, height and sw_format
values are set.

If the user doesn't call avcodec_get_hw_frames_parameters, the rest
of the code wouldn't notice. The rest of the decoder code gets the profile
via the create_pnext chain (where the pointers to the profile structs must be).
So users can attach their own profile, and store it wherever, including
the opaque field.

This commit also fixes the situation where a users calls
avcodec_get_hw_frames_parameters, gets a frame parameters.
destroys the decode context, and uses the same frames context
which was created for another decoder.