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

[Hendrik Leppkes]

On Tue, Jan 9, 2018 at 3:21 PM, Rostislav Pehlivanov
<atomnuker at gmail.com> wrote:
> On 9 January 2018 at 14:07, Rostislav Pehlivanov <atomnuker at gmail.com>
> wrote:
>
>>
>>
>> On 9 January 2018 at 09:00, Hendrik Leppkes <h.leppkes at gmail.com> wrote:
>>
>>> 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.
>>>
>>
>> Then its a good thing I suggested something that doesn't involve having
>> every caller of lavc to handle another field.
>>
>>
>>
>>> 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
>>
>> I'd be fine with using codec tags, but not with codec IDs.
>>
>
> Though for encoding using profiles would be best.

For encoding, profiles is perfectly normal and expected, and used by
many other codecs as well. Just for decoding that field is not defined
to be required to be set externally to even make decoding of a certain
stream possible.

- Hendrik