Le mer. 20 août 2025 à 15:25, Yalda via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> a écrit : > Thanks Romain. I am experimenting with this and trying the patches.
Awesome. Thanks so much for your time! I have rebased the vorbis header PR against the latest `master` (would love to call it main). I have also pushed the next patches to enable proper metadata parsing so you can see how it would work: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20327 Let me know what you think! -- Romain > On Wed, Aug 13, 2025 at 8:46 AM Romain Beauxis <romain.beau...@gmail.com> > wrote: > > > > Le mer. 13 août 2025 à 08:44, Romain Beauxis > > <romain.beau...@gmail.com> a écrit : > > > > > > Le mar. 12 août 2025 à 14:49, Romain Beauxis > > > <romain.beau...@gmail.com> a écrit : > > > > > > > > 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? > > > > > > 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: > > > > Huh, sorry: > > ```shell > > % cal icecast-playlist.liq > > > > 18h 36m 5s 08:45:37 > > s = playlist("~/sources/test-stream/audio") > > > > output.icecast( > > fallible=true, > > mount="test", > > %vorbis, > > s > > ) > > > > % liquidsoap ./icecast-playlist.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-requ...@ffmpeg.org with subject "unsubscribe". > _______________________________________________ > 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". _______________________________________________ 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".
