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:02:12 -0600
Message-ID: <CABWZ6OTdQDVPNZ2z96_MfeL_kWRXuFzhXNkPStjxMEGqUv2GqQ@mail.gmail.com> (raw)
In-Reply-To: <CABWZ6OTgGm=C9x6P3B5x+NdBjNShDiVxcRMQN+i8VRvRd2J3ZQ@mail.gmail.com>
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.
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 them 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".
next prev parent reply other threads:[~2025-02-16 21:02 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 [this message]
2025-02-16 21:03 ` Romain Beauxis
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=CABWZ6OTdQDVPNZ2z96_MfeL_kWRXuFzhXNkPStjxMEGqUv2GqQ@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