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

[Andreas Rheinhardt]

James Almer:
> On 2/12/2024 3:24 PM, Andreas Rheinhardt wrote:
>> James Almer:
>>> On 2/12/2024 2:28 PM, Andreas Rheinhardt wrote:
>>>> 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.
>>>
>>> Buffered where? Internally in the demuxer?
>>>
>>
>> That's it: We add a new function (may be an inline wrapper for
>> avpriv_packet_list_put()) for demuxers to append multiple packets to the
>> raw_packet_buffer queue in a single read_packet call. That way the
>> ordinary (already existing) logic in ff_read_frame() will take care of
>> everything.
> 
> ff_read_packet() fills some fields on the AVPackets returned by
> iformat->read_packet() before buffering them in raw_packet_buffer.
> Doesn't look like the demuxer should be put things in raw_packet_buffer
> on its own.

Yes, I noticed that a bit after writing my mail. It means this thing
will not be inline. (And as long as it is done by an explicit function
in demux.[ch], it is not the demuxer who does this on its own.)

- Andreas