2018-01-08 13:37 GMT+01:00 Hendrik Leppkes <h.lepp...@gmail.com>: > On Mon, Jan 8, 2018 at 1:27 PM, Carl Eugen Hoyos <ceffm...@gmail.com> 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. >>> >>> 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, I >> don't think we should invent codec_tags unless necessary. >> > > We're not inventing them if they are a copy from the container > bitstream tag field.
I completely agree! Is there a container bitstream tag field in this case? Carl Eugen _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel