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".
next prev parent 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