Ian Reed
2018-Nov-15 06:59 UTC
[opus] 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
Timothy B. Terriberry
2018-Nov-15 07:16 UTC
[opus] Question about libopusfile downloading the last 64K when duration is not needed
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.
Ian Reed
2018-Nov-15 07:55 UTC
[opus] Question about libopusfile downloading the last 64K when duration is not needed
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.
Possibly Parallel Threads
- Question about libopusfile downloading the last 64K when duration is not needed
- Question about libopusfile downloading the last 64K when duration is not needed
- How to identify packets to input to opus_decode()
- [libopusfile PATCH] build: implement autotools build system for libopusfile. (v4)
- [PATCH] Support for Ambisonics and Projection API.