[flac-dev] Feedback on implementation of decoding of chained streams

[Martijn van Beurden]

Op ma 2 sep 2024 om 22:40 schreef Timothy B. Terriberry <tterribe at xiph.org>:
>
> Martijn van Beurden wrote:
> >> Since chained streams can have different sample rates, how would one go
> >> about seeking to a specific _time_?
> >
> > I assume one would first use the sample rate of the first link to
> > guess the sample number, seek to that point, correct if it turns out
> > one of the links that passed has a different sample rate, seek again
> > etc.
>
> The use case I am thinking of here is a standard media player with a
> scrubber that shows the current playback position and can be dragged by
> the user to seek. I don't know how many would use libFLAC for this
> directly (maybe VLC?) instead of some other media framework, but it at
> least seems like a common use case.
>
> >> Am I reading the seeking implementation correctly that the only way to
> >> seek to a future link is to scan forward through all of the file data?
> >
> > Yes, that is correct.
>
> So, to implement the above scrubber, you would have to read the entire
> file before being able to begin playback, plus maintain a bunch of
> custom code to enumerate and store the list of link durations and sample
> rates to do the conversion between sample number and time. I do not
> think a lot of people would be willing to enable chained stream support
> if that is the cost.

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.

I could expand the provided functionality in a number of ways
- Provide a function that does the scrubbing (I call it indexing in
the code) and return the total number of samples and link details
- and/or provide a way to skip over a current link (instead of decoding it)
- and/or provide a way to seek to a certain link by its serial number
(instead of decoding all links before it)
- and/or provide a way to seek to a certain link by its "number" (i.e.
go to the fourth link)
- and/or provide a way to seek to a certain timestamp instead of a
certain sample
- and/or provide a way to seek to a certain sample within a certain link

I'm not sure what would be most useful, and I am reluctant to
implement them all.

Please let me know what you think.

Kind regards, Martijn van Beurden