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

[Martijn van Beurden]

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?