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

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.

I've been thinking a while about this, reading some code, and I can't
get my head around it, so I hope I can get some more help and/or
advice.

As an example, take a multiplexed, chained stream, with both links
being a video stream alongside a FLAC audio track. To find the end of
the first link and/or beginning of the second link, we
opportunistically seek forward, ending up in the second link. As a
FLAC page often contains about 0.3 seconds of audio, a 25mbit/s video
stream would have 1MB of pages before a FLAC page turns up, and 1MB
seems a little much to read forward opportunistically. 1MB also seems
the max Opus does while seeking in such a case, but I'm not sure I
correctly understand the code. If the implementation would indeed read
1MB and find nothing FLAC, what should it conclude? As far as I know,
there is no way to find out which logical streams are 'running' after
seeking. The implementation could seek backward after finding nothing,
ending up in the first link in a similar scenario and get stuck.

Any idea how to handle this correctly?