Hi! Le mar. 12 août 2025 à 11:33, Yalda <mart...@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-requ...@ffmpeg.org with subject "unsubscribe".
