From: Romain Beauxis <romain.beauxis@gmail.com> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Subject: Re: [FFmpeg-devel] [PATCH v12 1/8] libavcodec/decode.c: intercept `AV_PKT_DATA_METADATA_UPDATE` packet extra data, attach them to the next decoded frame. Date: Mon, 21 Apr 2025 08:47:19 -0500 Message-ID: <CABWZ6ORORbx3HyaZW0x9TehX63cA-7bRbGiyVuqzVzzqydDWNw@mail.gmail.com> (raw) In-Reply-To: <20250420200822.GF4991@pb2> Le dim. 20 avr. 2025 à 15:08, Michael Niedermayer <michael@niedermayer.cc> a écrit : > > On Tue, Apr 15, 2025 at 05:22:29PM -0500, Romain Beauxis wrote: > > --- > > libavcodec/decode.c | 19 +++++++++++++++++++ > > 1 file changed, 19 insertions(+) > > > > diff --git a/libavcodec/decode.c b/libavcodec/decode.c > > index fca0c7ff58..06d899a9dd 100644 > > --- a/libavcodec/decode.c > > +++ b/libavcodec/decode.c > > @@ -97,6 +97,8 @@ typedef struct DecodeContext { > > int lcevc_frame; > > int width; > > int height; > > + > > + AVDictionary *pending_metadata; > > } DecodeContext; > > > > static DecodeContext *decode_ctx(AVCodecInternal *avci) > > @@ -702,6 +704,8 @@ int attribute_align_arg avcodec_send_packet(AVCodecContext *avctx, const AVPacke > > { > > AVCodecInternal *avci = avctx->internal; > > DecodeContext *dc = decode_ctx(avci); > > + const uint8_t *side_metadata; > > + size_t size; > > int ret; > > > > if (!avcodec_is_open(avctx) || !av_codec_is_decoder(avctx->codec)) > > @@ -719,6 +723,14 @@ int attribute_align_arg avcodec_send_packet(AVCodecContext *avctx, const AVPacke > > ret = av_packet_ref(avci->buffer_pkt, avpkt); > > if (ret < 0) > > return ret; > > + > > + side_metadata = av_packet_get_side_data(avpkt, AV_PKT_DATA_METADATA_UPDATE, &size); > > + if (side_metadata) { > > + av_dict_free(&dc->pending_metadata); > > + ret = av_packet_unpack_dictionary(side_metadata, size, &dc->pending_metadata); > > + if (ret < 0) > > + return ret; > > + } > > } else > > dc->draining_started = 1; > > > > @@ -788,6 +800,7 @@ fail: > > int ff_decode_receive_frame(AVCodecContext *avctx, AVFrame *frame) > > { > > AVCodecInternal *avci = avctx->internal; > > + DecodeContext *dc = decode_ctx(avci); > > int ret; > > > > if (avci->buffer_frame->buf[0]) { > > @@ -810,6 +823,11 @@ int ff_decode_receive_frame(AVCodecContext *avctx, AVFrame *frame) > > > > avctx->frame_num++; > > > > + if (dc->pending_metadata) { > > + av_dict_copy(&frame->metadata, dc->pending_metadata, AV_DICT_APPEND); > > + av_dict_free(&dc->pending_metadata); > > + } > > + > > return 0; > > fail: > > av_frame_unref(frame); > > @@ -2220,4 +2238,5 @@ void ff_decode_internal_uninit(AVCodecContext *avctx) > > DecodeContext *dc = decode_ctx(avci); > > > > av_refstruct_unref(&dc->lcevc); > > + av_dict_free(&dc->pending_metadata); > > } > > -- > > 2.39.5 (Apple Git-154) > > My issue with this is the same as it was previously > Please correct me if iam wrong (it is very possible that iam wrong on > some assumtations here) > > the decoder is variable delay (exact delay depends on cpu cores and luck) > on the input we have some side data from an AVPacket > then some packets will result in nothing to come out (because maybe they are damaged > or the users asked non key frames to be skiped or whatever) > some packets will decode into AVFrames in one of several threads > and these AVFrames then come back out > > how can code that seems to ignore this be correct ? > > Shouldnt the data be associated with the packet go through the > decoder with it ? > Or is this data not associated with the packet in that sense ? Yeah that makes sense. How about the following: * Keep metadata's associated PTS * Only attach a metadata to an outgoing frame with the same PTS * Keep the latest pair of PTS/metadata in the decoder, erasing existing one when a new one comes through. This is a step closer to the previous tree implementation but prevents issues with accumulating metadata. > thx > > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > The educated differ from the uneducated as much as the living from the > dead. -- Aristotle > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
next prev parent reply other threads:[~2025-04-21 13:47 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2025-04-15 22:22 [FFmpeg-devel] [PATCH v12 0/8] Properly decode ogg metadata in ogg/{vorbis, flac, opus} chained bitstreams Romain Beauxis 2025-04-15 22:22 ` [FFmpeg-devel] [PATCH v12 1/8] libavcodec/decode.c: intercept `AV_PKT_DATA_METADATA_UPDATE` packet extra data, attach them to the next decoded frame Romain Beauxis 2025-04-20 20:08 ` Michael Niedermayer 2025-04-21 13:47 ` Romain Beauxis [this message] 2025-04-15 22:22 ` [FFmpeg-devel] [PATCH v12 2/8] tests: Add stream dump test API util Romain Beauxis 2025-04-15 22:22 ` [FFmpeg-devel] [PATCH v12 3/8] tests: Add chained ogg/vorbis stream dump test Romain Beauxis 2025-04-15 22:22 ` [FFmpeg-devel] [PATCH v12 4/8] libavformat/oggdec.h, libavformat/oggparsevorbis.c: Factor out vorbis metadata update mechanism Romain Beauxis 2025-04-15 22:22 ` [FFmpeg-devel] [PATCH v12 5/8] libavformat/oggparseflac.c: Parse ogg/flac comments in new ogg packets, add them to ogg stream new_metadata Romain Beauxis 2025-04-15 22:22 ` [FFmpeg-devel] [PATCH v12 6/8] tests: Add chained ogg/flac stream dump test Romain Beauxis 2025-04-15 22:22 ` [FFmpeg-devel] [PATCH v12 7/8] libavformat/oggparseopus.c: Parse comments from secondary chained streams header packet Romain Beauxis 2025-04-15 22:22 ` [FFmpeg-devel] [PATCH v12 8/8] tests: Add chained ogg/opus stream dump test Romain Beauxis 2025-04-20 14:52 ` [FFmpeg-devel] [PATCH v12 0/8] Properly decode ogg metadata in ogg/{vorbis, flac, opus} chained bitstreams Romain Beauxis
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CABWZ6ORORbx3HyaZW0x9TehX63cA-7bRbGiyVuqzVzzqydDWNw@mail.gmail.com \ --to=romain.beauxis@gmail.com \ --cc=ffmpeg-devel@ffmpeg.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel This inbox may be cloned and mirrored by anyone: git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \ ffmpegdev@gitmailbox.com public-inbox-index ffmpegdev Example config snippet for mirrors. AGPL code for this site: git clone https://public-inbox.org/public-inbox.git