From: Romain Beauxis <romain.beauxis@gmail.com>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Cc: Marvin Scholz <epirat07@gmail.com>, Lynne <dev@lynne.ee>,
Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Subject: Re: [FFmpeg-devel] [PATCH v2] ogg/vorbis: implement header packet skip in chained ogg bitstreams.
Date: Wed, 13 Aug 2025 08:44:43 -0500
Message-ID: <CABWZ6OSeDY7KA7inOoE76eN-DxHchqMOSQLzoPgFPv90oyEP-g@mail.gmail.com> (raw)
In-Reply-To: <CABWZ6OQd9CksiE5fh44q=v+LMJUF8tYx84k1BZTTEO55Q4AXpw@mail.gmail.com>
Le mar. 12 août 2025 à 14:49, Romain Beauxis
<romain.beauxis@gmail.com> a écrit :
>
> Hi!
>
> Le mar. 12 août 2025 à 11:33, Yalda <marth64@proxyid.net> a écrit :
> >
> > Romain Beauxis:
> >
> > Thank you, Romain, for the clarity.
> >
> > I have some follow up questions just to solidify my understanding.
> > I think this is a good match since this sounds like a segment joining
> > problem which is ironically what I have been doing in principle
> > with my other contributions.
>
> Nice!
>
> > 1) Can core stream parameters (channels, sample rate) change mid-flight?
>
> In theory, yes. The two streams do not have to have anything in common.
>
> In practice, most of the situations where this happens are because the encoder wants to insert an in-band metadata so it's pretty reasonable to assume that encoding parameters are unlikely to change between streams, at least as a first approach.
>
> > 2) Why are the header packets emitted to begin with?
> > Are they necessary for the audible bitstream or preamble metadata?
> > Alternatively, a link to external reading is fine by me!
>
> You got the link I see :-)
>
> In ogg, there's usually at least 2 to 3 packets:
> 1. "hello" packet to detect the logical stream content. All first packets of all multiplexed streams are placed inside an initial page.
> 2. One metadata packet
> 3. Optionally: one or more codec specific packets
>
> (Similarly to considering theora as deprecated, I would also ignore the multiplexing aspect of the problem, at least in a first approach. Ogg streams with audio/video content are also pretty rare these days.)
>
> The codec specific packets can contain data required for the decoder.
>
> In practice, it seems that in ffmpeg, with ogg/flac and ogg/opus, the decoders are pretty happy continuing their decoding without having to process any new header packet.
>
> For opus, there does not seem to be any codec-specific header: https://wiki.xiph.org/OggOpus
>
> For flac, the spec says one or more metadata packets and no codec-specific packet: https://xiph.org/flac/ogg_mapping.html
>
> For those two codecs, the current libavcodec decoders are pretty happy without those mid-stream headers.
>
> With vorbis, the stream has one metadata packet and one codec specific packet that seems required to continue decoding.
>
> Thus, the current libavcodec vorbis decoder has to receive and process mid-stream headers, which is why suppressing those from the demuxer output was a trickier task and why this current patch is a hold-out.
>
> > 3) Is it possible that doing the stream copy is a front-line goal in actuality?
> > In other words, by solving 1/2/3, we are actually wanting to solve 4?
> > (If this thought makes sense)
>
> The most pressing user-facing features are: supporting in-band metadata and copy streams.
>
> In-band metadata is just a few commits behind the current pending one. I was looking at them yesterday, they are really super simple.
>
> These changes are blocked by the completion of the proper handling of header packets since metadata are passed through them.
>
> Supporting copy streams is more tricky as it will require fixing DTS and handling new ogg headers when generating the output streams.
>
> I do have most of this sketched out in my local FFmpeg repo.
>
> > 4) Is there a sample command to spawn such a source stream, or is setting
> > up Icecast with defaults enough and play segments to simulate the conditions?
Sorry I'm realizing you meant a live stream here.
You can use liquidsoap, which should be easily installable via the
binary packages here:
https://github.com/savonet/liquidsoap/releases/tag/v2.3.3
Or using `opam`:
https://www.liquidsoap.info/doc-2.3.3/install.html#install-using-opam
(make sure to install the vorbis package and also ffmpeg for decoding!)
A simple script could be:
```shell
% cat icecast-stream.liq
s = playlist("/path/to/directory")
output.icecast(
fallible=true,
host="...", # defaults to localhost
port=..., # default to 8000
mount="...", # mandatory
password="...", # defaults to hackme
%ffmpeg(%codec("libmp3lame")),
s
)
% liquidsoap ./icecast-stream.liq
```
Alternatively you could pick any of the ogg/{opus, flac, vorbis}
stream in the xiph directory: https://dir.xiph.org/codecs/Vorbis
Thanks,
-- 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-08-13 13:45 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-04 16:58 Romain Beauxis
2025-06-10 18:04 ` Romain Beauxis
2025-06-12 11:35 ` Michael Niedermayer
2025-06-14 10:39 ` Romain Beauxis
2025-06-14 22:57 ` Michael Niedermayer
2025-06-21 8:45 ` Romain Beauxis
2025-06-21 21:59 ` Michael Niedermayer
2025-07-23 19:06 ` Romain Beauxis
2025-07-28 0:22 ` Michael Niedermayer
2025-07-28 21:12 ` Romain Beauxis
2025-08-03 21:36 ` Michael Niedermayer
2025-08-03 22:50 ` Romain Beauxis
2025-08-04 0:11 ` Michael Niedermayer
2025-08-04 0:19 ` Kieran Kunhya via ffmpeg-devel
2025-08-04 10:53 ` Nicolas George
2025-08-04 8:21 ` Michael Niedermayer
2025-08-04 15:59 ` Romain Beauxis
2025-08-11 22:31 ` Yalda
2025-08-12 0:21 ` Romain Beauxis
2025-08-12 0:23 ` Romain Beauxis
2025-08-12 16:33 ` Yalda
2025-08-12 16:38 ` Yalda
2025-08-12 19:49 ` Romain Beauxis
2025-08-13 13:44 ` Romain Beauxis [this message]
2025-08-13 13:46 ` 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=CABWZ6OSeDY7KA7inOoE76eN-DxHchqMOSQLzoPgFPv90oyEP-g@mail.gmail.com \
--to=romain.beauxis@gmail.com \
--cc=andreas.rheinhardt@outlook.com \
--cc=dev@lynne.ee \
--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