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

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?

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.