[opus] Question about libopusfile downloading the last 64K when duration is not needed
info at blindaudiogames.com
Thu Nov 15 07:55:37 UTC 2018
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.
Thanks for your help,
PS: The link to the opusfile 0.11 windows build on the October 9 news
announcement is broken.
It points here:
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.
More information about the opus