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 <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.
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 _______________________________________________ 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".
