opus - Nov 2018 - Question about libopusfile downloading the last 64K when duration is not needed

I am writing a program that retrieves and plays .opus files over the 
network.
I am using the C# PInvoke wrapper OpusFileSharp, which calls into 
libopusfile and passes callbacks for read, seek, and tell.
I want to enable seeking via the seek callback by not returning -1, but 
I find that as soon as I do libopusfile requests the last 64K of the 
.opus file, probably so it can calculate the duration.
My program already knows the duration of each .opus file, so I would 
rather not have libopusfile download an extra 64K of every .opus file to 
discover it.

I've read your FAQ here:
https://wiki.xiph.org/index.php?title=OpusFAQ&mobileaction=toggle_view_desktop
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.

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?

Thanks,
Ian Reed

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.

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.