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

[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.