[FFmpeg-devel] [PATCH 1/7 v4] avcodec: add an Immersive Audio Model and Formats frame split bsf
Andreas Rheinhardt
andreas.rheinhardt at outlook.com
Mon Feb 12 19:28:14 EET 2024
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 at 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
More information about the ffmpeg-devel
mailing list