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.
_______________________________________________
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
