[FFmpeg-devel] [PATCH v5 00/14] encoder AVCodecContext configuration side data
James Almer
jamrial at gmail.com
Fri Dec 8 18:27:06 EET 2023
On 12/8/2023 8:59 AM, Jan Ekström wrote:
> On Sun, Nov 26, 2023 at 9:58 PM Jan Ekström <jeebjp at gmail.com> wrote:
>>
>> Differences to v3:
>> 1. rebased on top of current master
>> 2. moved the addition of multiple side data entries from a generic
>> av_frame_side_data_set_extend to avcodec as per request from James.
>> 4. adopted various things noted by reviews
>>
>> Comparison URL (mostly configure and wrappers, avutil/frame.c):
>> https://github.com/jeeb/ffmpeg/compare/avcodec_cll_mdcv_side_data_v4..avcodec_cll_mdcv_side_data_v5
>>
>> This patch set I've now been working for a while since I felt like it was weird
>> we couldn't pass through information such as static HDR metadata to encoders
>> from decoded input. This initial version adds the necessary framework, as well
>> as adds static HDR metadata support for libsvtav1, libx264 as well as libx265
>> wrappers.
>>
>> An alternative to this would be to make encoders only properly initialize when
>> they receive the first AVFrame, but that seems to be a bigger, nastier change
>> than introducing an AVFrameSideDataSet in avctx as everything seems to
>> presume that extradata etc are available after opening the encoder.
>>
>> Note: Any opinions on whether FFCodec or AVCodec should have
>> handled_side_data list, so that if format specific generic logic is
>> added, it could be checked whether the codec itself handles this side
>> data? This could also be utilized to list handled side data from f.ex.
>> `ffmpeg -h encoder=libsvtav1`.
>>
>> Jan
>
> Ping.
>
> I'd like to understand whether:
>
> * people are fine with the struct which lets you pass things as a
> single argument, or they would like to move all the helper functions
> to counter and pointer.
IMO we should do the same we did for packet side data, so IN/OUT pointer
and size as arguments. It should also match the function signatures as
much as possible. So for example:
> AVFrameSideData *av_frame_side_data_new(AVPacketSideData ***sd, int *nb_sd,
> enum AVFrameSideDataType type,
> size_t size, int flags);
> AVFrameSideData *av_frame_side_data_add(AVFrameSideData ***sd, int *nb_sd,
> enum AVFrameSideDataType type,
> void *data, size_t size, int flags);
> AVFrameSideData *av_packet_side_data_add_from_buf(AVFrameSideData ***sd, int *nb_sd,
> enum AVFrameSideDataType type,
> /* making a new ref, not taking ownership */ AVBufferRef *buf, int flags);
> const AVFrameSideData *av_frame_side_data_get(const AVFrameSideData **sd,
> int nb_sd,
> enum AVFrameSideDataType type);
> void av_frame_side_data_remove(AVFrameSideData ***sd, int *nb_sd,
> enum AVFrameSideDataType type);
> void av_frame_side_data_free(AVFrameSideData ***sd, int *nb_sd);
> const char *av_frame_side_data_name(enum AVFrameSideDataType type);
And since unlike with packet we allow more than one entry per frame side
data type, you could add something like:
> const AVFrameSideData *av_frame_side_data_iterate(const AVFrameSideData **sd,
> int nb_sd,
> enum AVPacketSideDataType type,
> void **opaque);
> * should the avcodec helper take in the struct/{counter,pointer}, or
> should it instead take in a const AVFrame pointer?
The former. There already are helpers for side data in AVFrame, and the
point of this set is to add such side data to AVCodecContext.
>
> as I'd like to start pulling this in, and move towards working on
> implemented side data listing in AVCodecs, as well as adding generic
> implementations for specific codecs (such as H.264/HEVC/AV1 having CBS
> create side data generically, without the need of specific AVCodecs
> implementing things),
>
> Jan
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
More information about the ffmpeg-devel
mailing list