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

Rostislav Pehlivanov atomnuker at gmail.com
Tue Jan 9 16:21:02 EET 2018


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
>> _______________________________________________
>> ffmpeg-devel mailing list
>> ffmpeg-devel at ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
> I'd be fine with using codec tags, but not with codec IDs.
>

Though for encoding using profiles would be best.


More information about the ffmpeg-devel mailing list