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

[Timothy B. Terriberry]

Martijn van Beurden wrote:
> 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.

Correct, that is how opusfile works. op_lookup_serialno() is the 
function which determines if a serial number is in the list for the 
current link. When it finds where the current link ends and a new link 
starts, op_fetch_headers() builds a new list of serial numbers from the 
BOS pages of all streams (which are all required to be together at the 
start of the link):

https://gitlab.xiph.org/xiph/opusfile/-/blob/master/src/opusfile.c#L484

> 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.

Not sure where you got 1 MB. Different maximums are used in different 
places, but for link enumeration:

https://gitlab.xiph.org/xiph/opusfile/-/blob/master/src/opusfile.c#L1202
     last=op_get_next_page(_of,&og,_sr[nsr-1].offset);

The limit for reading forward, sr[nsr-1].offset, is the start of the 
last seek record, which corresponds to the earliest page found so far 
from a different link (i.e., there is essentially no limit). I suppose 
you can argue about whether or not that is a good idea.