On Mon, Jan 08, 2018 at 01:27:16PM +0100, Carl Eugen Hoyos wrote: > 2018-01-08 11:32 GMT+01:00 Hendrik Leppkes <h.lepp...@gmail.com>: > > On Mon, Jan 8, 2018 at 1:38 AM, Rostislav Pehlivanov > > <atomnu...@gmail.com> wrote: > >> > >> That's okay - for encoding switch the profile depending on both the > >> avctx->profile setting and the samplerate and list all supported > >> samplerates for all profiles in the AVCodec structure. We do something > >> similar in the AAC encoder where we pick different settings depending on > >> the profile and change the profile depending on the settings listed. > >> If there's an overlap, pick a sane default unless the user forces a profile > >> using profile:a. If forced and the samplerate isn't supported - error out > >> and let the user know. > >> For decoding set the profile via the demuxer. There doesn't have to be just > >> one demuxer for a codec. If there are major changes in how you parse > >> profiles go ahead and make a new one which sets the codec ID and the > >> profile. > >> > > > > I don't think there is any precedent for "profile" being mandatory for > > a decoder to work, so that might be iffy. Decoders usually set > > profile, don't require it. > > ie. from the docs: > > * - decoding: Set by libavcodec.
Oh, very true. I guess that settles it for "profile". Public API do not allows using profile to select the appropriate decoder. > > There is plenty precedent for using "codec_tag" however, so that may > > be a better choice - and can hold the tag from the "container" as-is > > as well. > > While I don't understand why even having more than one codec_id for > the same codec (which afaiu isn't the case here) would be an issue, Same for me, I don't understand why adding a codec_id would be an issue. > I don't think we should invent codec_tags unless necessary. I agree. And I don't think there is a container used for aptX or aptX HD in the wild with some kind of codec_tag. So this is probably not an option either. I maintain that using 2 codec IDs is the most appropriate in this specific case. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
