Re: [FFmpeg-devel] [PATCH 1/7 v4] avcodec: add an Immersive Audio Model and Formats frame split bsf

[Andreas Rheinhardt <andreas.rheinhardt@outlook.com>]

James Almer:
> 
> 
> On 2/12/2024 2:04 PM, Andreas Rheinhardt wrote:
>> James Almer:
>>> On 2/12/2024 1:40 PM, Andreas Rheinhardt wrote:
>>>> James Almer:
>>>>> On 2/6/2024 10:05 AM, James Almer wrote:
>>>>>> Signed-off-by: James Almer <jamrial@gmail.com>
>>>>>> ---
>>>>>> Now reading decriptors from extradata, plus a setting to ensure any
>>>>>> descriptors
>>>>>> present inband are omitted has been added.
>>>>>>
>>>>>>     doc/bitstream_filters.texi            |  16 +
>>>>>>     libavcodec/bitstream_filters.c        |   1 +
>>>>>>     libavcodec/bsf/Makefile               |   1 +
>>>>>>     libavcodec/bsf/iamf_frame_split_bsf.c | 887
>>>>>> ++++++++++++++++++++++++++
>>>>>>     4 files changed, 905 insertions(+)
>>>>>>     create mode 100644 libavcodec/bsf/iamf_frame_split_bsf.c
>>>>>
>>>>> Will apply the set soon if there are no objections.
>>>>
>>>> I still object to the BSF in #1 existing as it just duplicates parsing
>>>> code into lavc and lavf. And the issue with creating new framings for
>>>> stuff for which no framing except raw data can't exist is still there.
>>>
>>> I insist on using the split bsf, but i can try to remove the merge one
>>> and do that within lavf, to avoid creating packets with OBU framing.
>>
>> Why is splitting not simply done inside lavf (and inside the demuxer,
>> not the generic code in demux.c)? What is the advantage of that?
> 
> Not making a mess in mov.c's read_packet() from reiterated calls because
> one Track Sample has packets for several AVStreams.

Mess? All you would need to do is add a check at the beginning of
read_packet whether there are any more packets buffered. If so, return
them, if not, read new data.
(I consider adding bsfs to the demuxing code to be at least a bit messy
and not worth it unless there were several users of this.)

> 
>  Do such
>> packets as the split bsf expects exist somewhere in the wild outside of
>> isobmff files?
> 
> Sure, it's raw iamf. Other containers may also support it in the future,
> like Matroska, mpegs and the like.
> 

I don't see any reason why we should any of this framing outside of lavf
(i.e. it should be treated like e.g. Matroska's wavpack framing and
repacked inside the (de)muxer).

- Andreas

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".