flac dev - Sep 2024 - Feedback on implementation of decoding of chained streams

Op di 3 sep 2024 om 16:10 schreef Timothy B. Terriberry <tterribe at
xiph.org>:
>
> Martijn van Beurden wrote:
> > As far as I know, please correct if wrong, neither libopusfile nor
> > libvorbisfile provide this functionality either. In neither I could
> > find a function to find the total number of samples over all links.
> > Opus has a fixed samplerate so there is no changing, but libvorbisfile
> > doesn't provide a way to query it on any data about the links it
might
> > have stored.
>
> For opusfile:
>
>
https://opus-codec.org/docs/opusfile_api-0.12/group__stream__info.html#ga8c228c3d95f2c903ad6cfd2b78d8dad6
>
> [...]
>
Thanks, I misread a lot of information there it seems.
>
> It is a bit of a challenge because of the need to support unseekable
> streams (for, e.g., internet radio, your original use-case), but also
> not make chained streams _too_ much more of a burden to support than a
> stream with a single link in the seekable case. The vorbisfile API at
> least has a long history of use in a lot of applications, so it should
> not be too terrible a guide.
>
I agree, although the libvorbis and libFLAC API are very different.
Moreover, the FLAC and the libogg API are designed very differently
(pushing vs pulling), making it hard to 'combine' them, and libFLAC
also works without Ogg of course. Also, I'd like to leave room for
handling of Matroska FLAC streams in the future, which has its own way
of chaining.
> Probably the most difficult piece to implement is doing link enumeration
> in an efficient way. You want to be doing some sort of bisection search
> to locate link boundaries, re-using previous results for subsequent
> links, if possible.
There are still a lot of things that can be improved in libFLAC, so I
think I'll leave it be for a while when this works. I agree it is not
efficient, but for now, chained ogg is a niche use case for FLAC. I'd
think metadata writing to Ogg FLAC is more important for example, that
is something libFLAC still can't do.

Anyway, thanks for the provided insights. I'll work on those.

Kind regards, Martijn van Beurden

Martijn van Beurden wrote:
> There are still a lot of things that can be improved in libFLAC, so I
> think I'll leave it be for a while when this works. I agree it is not
> efficient, but for now, chained ogg is a niche use case for FLAC. I'd
Incremental steps are usually best. I think mostly you want to avoid 
painting yourself into a corner API-wise. I haven't thought deeply about 
whether your current proposal does that, but at least considering how 
you would extend it to support the things I described should help 
identify blockers and whether you will need additional ABI breaks, etc. 
It's worth at least reading through the code I pointed to with those 
things in mind.