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
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.
Thanks,
Marton
_______________________________________________
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".
