[FFmpeg-devel] [PATCH 4/5] aptx: implement the aptX HD bluetooth codec

Hendrik Leppkes h.leppkes at gmail.com
Mon Jan 8 14:37:55 EET 2018


On Mon, Jan 8, 2018 at 1:27 PM, Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
> 2018-01-08 11:32 GMT+01:00 Hendrik Leppkes <h.leppkes at gmail.com>:
>> On Mon, Jan 8, 2018 at 1:38 AM, Rostislav Pehlivanov
>> <atomnuker at 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.

- Hendrik


More information about the ffmpeg-devel mailing list