Quoting Andreas Rheinhardt (2024-03-23 14:15:06) > Anton Khirnov: > > Skip those side data types that do not make sense as global side data. > > --- > > fftools/ffmpeg_enc.c | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/fftools/ffmpeg_enc.c b/fftools/ffmpeg_enc.c > > index f01be1c22f..6a91fd0398 100644 > > --- a/fftools/ffmpeg_enc.c > > +++ b/fftools/ffmpeg_enc.c > > @@ -247,6 +247,11 @@ int enc_open(void *opaque, const AVFrame *frame) > > enc_ctx->chroma_sample_location = frame->chroma_location; > > > > for (int i = 0; i < frame->nb_side_data; i++) { > > + const AVSideDataDescriptor *desc = > > av_frame_side_data_desc(frame->side_data[i]->type); > > + > > + if (!desc || !(desc->props & AV_SIDE_DATA_PROP_GLOBAL)) > > + continue; > > Why the first check? Is it intended that a defined side data type > doesn't have a descriptor? Because IIRC all side data types that can > occur here are defined and have not been created by letting the user > pass a number via options.
It shouldn't happen, but it's not inconceivable that e.g. a filter could attach side data with an unknown type to a frame. I can remove the check if you prefer it. -- Anton Khirnov _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".