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

[Ulrich Windl]

Hi!

I have no deep insights on Opus source, but I got the impression that reading the last 64kB is just to get the duration (to aviod seeking past the end, I guess).
So obviously there would be two possible hacks:
1) Kind of automatically add silence past the end of the stream (in favor of crashing or outputting terrible noise), or stop playback if seek lands there. (Meaning do not read the last 64k)

2) Implement an extra unsafe_seek() that does not read the last 64k and relies on the user to specify only valid positions. Still playback has to stop past the end of the stream somehow.

Regards,
Ulrich



>>> Ian Reed <info at blindaudiogames.com> schrieb am 15.11.2018 um 08:55 in Nachricht
<f7df44d8-6198-61df-f525-af4b0904dc8e at blindaudiogames.com>:
> 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.
> 
> _______________________________________________
> opus mailing list
> opus at xiph.org 
> http://lists.xiph.org/mailman/listinfo/opus