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

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?

Okay, I just came up with a possible solution. In the case of
multiplexed streams, FLAC could not just keep track of its own serial
number in that link, but also of the serial numbers of other streams
in that link. That way, it could easily determine whether it is still
in the current link, as any page will either have a known or unknown
serial number. Is that also how opusfile works? I can't seem to find
any reference to such a thing in the code.

Op vr 13 sep 2024 om 10:14 schreef Martijn van Beurden <mvanb1 at
gmail.com>:
>
> 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?