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 <jamr...@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.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
