Re: [FFmpeg-devel] [PATCH v2] ogg/vorbis: implement header packet skip in chained ogg bitstreams.

[Romain Beauxis <romain.beauxis@gmail.com>]

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?

You can simply encode two ogg/{vorbis, flac, opus} files and concatenate
them!

I also contributed some short minimal ones to fate, see for instance:
ogg-vorbis/chained-meta.ogg

-- 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".