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

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.

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