> From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of > Marton Balint > Sent: Saturday, May 16, 2020 21:52 > To: ffmpeg-devel@ffmpeg.org > Subject: [FFmpeg-devel] [RFC] encoder profile validation > > Hi, > > As you may know, a recent patchset enabled AVCodecContext->profile > constants to reside in encoders. > > In order to make a full transition to avctx->profile even in existing > encoders which might use a private profile setting, we have to make sure > only supported avctx->profile values are passed to encoders. > > The fact that avctx->profile is not validated is already an issue, and > assertions/segmentation faults can already happen in existing encoders > (e.g.: aac, mpeg) if unsupported values are passed. > > AVCodec have a .profiles attribute which supposed to contain the list of > supported profiles. However this is problematic because > - AVCodecContext->profile is not validated against this list > - not all encoders define the list > - even if there is a list it might be defined as NULL_IF_CONFIG_SMALL > - some encoders support more or less than its currently defined list > - AVCodec->profiles contains AVProfiles which supposed to have a textual > representation of each profile, which can cause profile name > duplications/inconsistencies against libavcodec/profiles.c if the list > is different to the one in codecs profile list. > > So I'd rather not user AVCodec->profiles for this validation. I am
The validation would help from my perspective. Meanwhile got some questions: IIRC, AVCodec->profiles probably didn't cover the HW specific profiles for encoders Like nvenc/qsv/amfenc. Are you intending to add them in this profile list and keep Them in common or did the map/verify internally in specific hw encoder? > thinking about two possible solutions: > > 1) Add a new AVCodec->supported_profiles attribute which is a simple > integer list and validate against this list > > or > > 2) Introdce a new OPT type, AV_OPT_TYPE_ENUM which validates against > the > values of its named constants. This has the benefit that the supported > profiles only appear once in the AVClass option list, but it also > means that encoders might not share the supported profiles list via a > #define in libavcodec/profile.h, because they might support different > profiles. > > I like the second approach better, but let me know what you think. > Regardless of the validation itself, as to " make a full transition to avctx->profile", do we still need to add a prefix like "-profile:v h264_main " in your designs? (I'd prefer a more natural usage) - Linjie _______________________________________________ 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".