[opus] Question about libopusfile downloading the last 64K when duration is not needed

[Ian Reed]

Thanks for the quick response.
That makes sense. I just wanted to make sure it wasn't an easy fix, or 
that I wasn't overlooking something.

My scenario calls for very low latency playback with a user being able 
to jump between many files quickly, or seek quickly.
This means I am priming the pump by downloading the first chunk of many 
files that are likely to be started soon.
I was trying to maximize the number of files that could be primed, while 
keeping the download size as small as I could.
Having seking enabled meant I needed to prime an extra 64K for each 
file, which may end up doubling or tripling the priming size.

I think I will work around this by playing the .opus file with seeking 
disabled, then in the case where the user triggers a seek operation, 
closing and reopening the stream with seeking enabled.
If the file is open for very long at all, I can assume seeking is a 
likely possibility and download the extra 64K along with the other 
chunks of the file I wil inevitably download to keep the file playing.
I retain all the bytes that have already been downloaded, so I think 
closing and reopening the file with seeking enabled, then seeking to the 
right point, should work.

We'll see.

Thanks for your help,
Ian Reed

PS: The link to the opusfile 0.11 windows build on the October 9 news 
announcement is broken.
It points here:
https://archive.mozilla.org/pub/opus/win32/opusfile-0.11-win32.zip


On 11/15/2018 12:16 AM, Timothy B. Terriberry wrote:
> Ian Reed wrote:
>> It explains why libopusfile requires the last 64K to calculate the 
>> duration, but again, I don't need libopusfile to get the duration for 
>> me, I only want it to allow me to seek within parts of the file that 
>> have already been downloaded.
>
> Unfortunately, this is not currently supported.
>
>> Is there a reason libopusfile forces the retrieval of the last 64K of 
>> the file when seeking is enabled, but without ever being asked for 
>> the duration?
>
> It makes the code substantially simpler to be able to enumerate the 
> tracks, chain boundaries, etc., of the file once in advance. All of 
> the seeking code assumes this enumeration has been done. It might be 
> possible to remove this limitation and still enable some functionality 
> that is not available for an unseekable stream, but I have not tried, 
> and I expect it would be a lot of work.