On 2016-11-14 6:09 AM, Deepak K wrote:
> I am using Http Progressive download technique to download the opus
> audio in chunks. So I am not sure if the Opusfile seek API will work in
> this case. Please correct me if I am wrong.
If you don't want to use opusfile's http client implementation
(libopusurl) you can still use its seeking implementation. Just provide
the `op_read_func`, `op_seek_func`, and `op_tell_func` callbacks on top
of your current fetch framework. The library will call your seek
implementation with the necessary byte offsets to find and resume
decoding at the requested position when you call op_pcm_seek().
> Is there anyway to get or calculate the byte offset corresponding to the
> PCM time position? Then I can ask the server to serve the file from that
> byte onwards.
Yes, but the process is somewhat indirect. As Philipp said, there's no
seek table in .opus resources, and they're inherently variable bitrate
so you must perform a bisection search based on timestamps. Because of
the minimum reasonable chuck size for http downloads, and the ability to
estimate local bitrates, at most two or three seeks are necessary to
find a particular pcm time position, so it doesn't perform as poorly as
you might expect. On the other hand, it's not trivial to implemen. Many
applications actually seek by byte offset instead, which is an
acceptable user experience is some designs.
If you're going to write this yourself, keep in mind the complications
of decoder preroll (seek to 80 ms before the desired target and decode
from there, discarding the extra output, to give the decoder a chance to
settle) and chain boundaries (if you see an unrecognized Ogg stream
serial number, you'll need to bisect again to find a boundary where the
timestamp origin changes).
Good luck, and let us know how it goes!
-r