From: Romain Beauxis <romain.beauxis@gmail.com> To: ffmpeg-devel@ffmpeg.org Cc: epirat07@gmail.com, Romain Beauxis <romain.beauxis@gmail.com> Subject: [FFmpeg-devel] [PATCH v2 0/3] Properly decode ogg metadata in ogg/flac chained bitstreams Date: Tue, 4 Feb 2025 06:15:18 -0500 Message-ID: <20250204111521.48785-1-romain.beauxis@gmail.com> (raw) This is a series of 3 patches to allow proper decoding of ogg metadata in chained ogg/flac streams. ogg/flac streams are pretty important because there are perhaps the only combination of lossless audio codec and open-source container that allows for proper transmittion of lossless audio data accross systems such as Icecast, browser media tags and more. In the context of long-running audio streams, the ogg bitstream specs[1] have historically been very badly implemented. For each new track and each new metadata, the specs require the logical bitstream to come to a full EOF and then start with a full new logical stream. These specs have often been confused with a gobal EOF by most implementations. Furtunately, FFmpeg is a little better at that in that it is capable to parsing chained logical ogg bitstreams and properly output either encoded ogg packets or decoded audio. Chained bitstreams with more than one underlying type of content (audio+video, etc) is not yet supported though this is a much less needed feature. The purpose of these changes is to also allow proper decoding of metadata associated with subsequent streams in chained ogg/flac bitstream. This is done by simply intercepting ogg packets with comments in the flac decoded, parsing the comment block and retaining it to be attached with the next decoded audio frame. Along with the changes is a new FATE test validating the implementation. This solution keeps a proper separation of concerns: ogg packets are sill output by the demuxer (as shown in the test) but consumer of decoded data see decoded metadata in the decoded frames. Only drawback is that this adds a dependency on libavformat to libavcodec. I have looked at moving the vorbis metadata parsing to libavutil but a lot of definitions and utilities related to metadata are in fact located in libavformat so perhaps this makes sense. Follow-up work not addressed in this series of patch: * Ensure valid PTS in decoded frames of subsequent streams? * Generalize this approach to other chained ogg codec. Thanks, -- Romain Romain Beauxis (3): libavformat/oggdec: Allow first parameter in ff_vorbis_comment to be a generic AVClass struct libavcodec/flacdec: parse vorbis metadata from ogg packets, add them to the next decoded frame. Add stream dump test with test for ogg/flac. libavcodec/flacdec.c | 12 +- libavformat/oggdec.h | 5 +- libavformat/oggparsevorbis.c | 4 +- tests/Makefile | 2 + tests/api/Makefile | 2 +- tests/api/api-dump-stream-meta-test.c | 169 ++++++++++++++++++++++++++ tests/fate/api.mak | 5 + tests/fate/ogg-flac.mak | 11 ++ 8 files changed, 205 insertions(+), 5 deletions(-) create mode 100644 tests/api/api-dump-stream-meta-test.c create mode 100644 tests/fate/ogg-flac.mak -- 2.39.5 (Apple Git-154) _______________________________________________ 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 reply other threads:[~2025-02-04 11:15 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2025-02-04 11:15 Romain Beauxis [this message] 2025-02-04 11:15 ` [FFmpeg-devel] [PATCH v2 1/3] libavformat/oggdec: Allow first parameter in ff_vorbis_comment to be a generic AVClass struct Romain Beauxis 2025-02-04 11:15 ` [FFmpeg-devel] [PATCH v2 2/3] libavcodec/flacdec: parse vorbis metadata from ogg packets, add them to the next decoded frame Romain Beauxis 2025-02-04 11:15 ` [FFmpeg-devel] [PATCH v2 3/3] Add stream dump test with test for ogg/flac Romain Beauxis 2025-02-04 12:19 ` [FFmpeg-devel] [PATCH v2 0/3] Properly decode ogg metadata in ogg/flac 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=20250204111521.48785-1-romain.beauxis@gmail.com \ --to=romain.beauxis@gmail.com \ --cc=epirat07@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