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

[Hendrik Leppkes]

On Tue, Jan 9, 2018 at 9:33 AM, Hendrik Leppkes <h.leppkes at gmail.com> wrote:
> On Tue, Jan 9, 2018 at 5:07 AM, Rostislav Pehlivanov
> <atomnuker at gmail.com> wrote:
>>
>>> Anyway, all this discussion is moot as Hendrik pointed out that profile
>>> can't be set outside of lavc to determine a decoder behavior.
>>>
>>
>> What, based on a comment in lavc? Comments there describe the api but they
>> rarely define it. We're free to adjust them if need be and in this case,
>> since the codec profile may not be set, the API user is forced to deal with
>> the lack of such set. Hence, we can clarify that it may be set by lavf as
>> well as lavc as well as not being set at all. And the decoder may use it.
>> I maintain that adding a new codec ID for this is unacceptable.
>>
>
> We already have established methods to select codec sub-variants, we
> don't need to invent a new one just because you feel like it.
>

On that note, we also have cases where the same codec has different
codec ids based on popular known names.
For example wmv3/vc1 - wmv3 is simple/main profile, vc1 is advanced
profile, different codec ids, same implementation.

Re-defining public API is what is unacceptable, it requires every
caller of lavc to suddenly start handling one more field for no real
reason.
Either use a separate codec ID if there is sufficient reason for that
(mostly driven by external factors, if its handled as different codecs
everywhere else, not only in marketing but actual (reference)
implementations), or use a codec_tag if one is available (the codec id
field from a2dp for example)

- Hendrik