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 v4 3/6] Pass secondary ogg/opus chained streams metadata.
Date: Sun, 16 Feb 2025 15:03:54 -0600
Message-ID: <CABWZ6OSZ9AU5dXgSEvMq=GQfPcQHvs-0WirPjee5NYfW_kCR9g@mail.gmail.com> (raw)
In-Reply-To: <CABWZ6OTdQDVPNZ2z96_MfeL_kWRXuFzhXNkPStjxMEGqUv2GqQ@mail.gmail.com>

Le dim. 16 févr. 2025 à 15:02, Romain Beauxis <romain.beauxis@gmail.com> a
écrit :
>
> Hi again,
>
>
> Le ven. 14 févr. 2025 à 12:08, Romain Beauxis
> <romain.beauxis@gmail.com> a écrit :
> >
> > Le ven. 14 févr. 2025 à 11:55, Lynne <dev@lynne.ee> a écrit :
> > > Swallow the extra/metadata. Do not let OpusHead or their equivalents
in
> > > other codecs inside packets.
> > > Emit AV_PKT_DATA_NEW_EXTRADATA from the demuxer instead with the new
> > > data, which would contain the OpusHead unit (extradata).
> > > In the codec, if a packet contains AV_PKT_DATA_NEW_EXTRADATA, reinit
the
> > > decoder with it (we should do this in decode.c, but for now, doing it
in
> > > opusdec.c would be good enough).
> > >
> > > In the muxer, if a packet contains AV_PKT_DATA_NEW_EXTRADATA, write it
> > > to the bitstream.
> > >
> > > This also removes the need to cache metadata updates. If a packet
> > > contains metadata, simply pass that into the AVFrame->metadata once
the
> > > frame leaves the decoder in decode.c. The packet is not dereferenced
> > > yet, so you don't even need to cache it while the packet is being
decoded.
> >
> > This sounds like a plan, thanks I'll get to it.
>
> I'm looking into this again. Here are some notes:
>
> * Frames can potentially span several ogg packets so metadata should
> be cached in case a packet does not immediately return a decoded frame
> * The problem is extra header packets in the demuxed bitstream is
> orthogonal to the problem is passing new metadata
> * It seems more clear to use AV_PKT_DATA_METADATA_UPDATE to pass
> metadata updates and AV_PKT_DATA_NEW_EXTRADATA to pass new header
> packets
>
> Thus, I would like to divide up the work in the following order:
> 1. First a patcheset that adds a generic method to insert new metadata
> to decoded frames using AV_PKT_DATA_NEW_EXTRADATA. These changes
> wouldn't change the demuxing logic currently in place.

Sorry I meant AV_PKT_DATA_METADATA_UPDATE in the above.

> 2. Then a patchset to start adding ogg packet headers from secondary
> chained streams as AV_PKT_DATA_NEW_EXTRADATA and suppress them from
> the bitstream
>
> #2 might need some iterations, maybe one series that stash the header
> packets and hides them from the demuxer and another one that starts
> dumping them into the bitstream in the muxer. The reason being that,
> in order to be able to dump them in the muxer, we will also need to
> revise the PTS/DTS logic and that seems like a lot of work for one
> single patch series.
>
> How does the plan feel for you?
> -- Romain
_______________________________________________
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-02-16 21:04 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-10 19:25 [FFmpeg-devel] [PATCH v4 0/5] Properly decode ogg metadata in ogg/flac and ogg/opus chained bitstreams Romain Beauxis
2025-02-10 19:25 ` [FFmpeg-devel] [PATCH v4 1/6] Pass ogg/opus secondary header packets to the Romain Beauxis
2025-02-10 19:25 ` [FFmpeg-devel] [PATCH v4 2/6] tests: Add stream dump test API util Romain Beauxis
2025-02-10 19:25 ` [FFmpeg-devel] [PATCH v4 3/6] Pass secondary ogg/opus chained streams metadata Romain Beauxis
2025-02-13 21:53   ` Lynne
2025-02-13 23:27     ` Romain Beauxis
2025-02-13 23:37       ` Lynne
2025-02-14 15:48         ` Romain Beauxis
2025-02-14 16:18           ` Lynne
2025-02-14 16:50             ` Romain Beauxis
2025-02-14 17:55               ` Lynne
2025-02-14 18:08                 ` Romain Beauxis
2025-02-16 21:02                   ` Romain Beauxis
2025-02-16 21:03                     ` Romain Beauxis [this message]
2025-02-10 19:25 ` [FFmpeg-devel] [PATCH v4 4/6] tests: Add chained ogg/opus stream dump test Romain Beauxis
2025-02-10 19:25 ` [FFmpeg-devel] [PATCH v4 5/6] Parse secondary chained ogg/flac stream comments Romain Beauxis
2025-02-10 19:26 ` [FFmpeg-devel] [PATCH v4 6/6] tests: Add chained ogg/flac stream dump test 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='CABWZ6OSZ9AU5dXgSEvMq=GQfPcQHvs-0WirPjee5NYfW_kCR9g@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