Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
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".

  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