ogg dev - Nov 2016 - Help with Opus Streaming

On 2016-11-08 1:59 AM, Philipp Schafft wrote:
> Some notes:
>       * libvorbisfile has a nice implementation of that, it also takes
>         care of matching the signal at the very point of the jump.
I would recommend the opusfile library, which implements seeking
specifically for Opus streams.

https://archive.mozilla.org/pub/opus/opusfile-0.8.zip
https://mf4.xiph.org/jenkins/view/opus/job/opusfile-unix/ws/doc/html/group__stream__seeking.html

 -r


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.xiph.org/pipermail/ogg-dev/attachments/20161108/d781d6b6/attachment.sig>

Hi Ralph,

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.

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.

Regards,
Deepak.

On Tue, Nov 8, 2016 at 11:33 PM, Ralph Giles <giles at thaumas.net> wrote:
> On 2016-11-08 1:59 AM, Philipp Schafft wrote:
>
> > Some notes:
> >       * libvorbisfile has a nice implementation of that, it also takes
> >         care of matching the signal at the very point of the jump.
>
> I would recommend the opusfile library, which implements seeking
> specifically for Opus streams.
>
> https://archive.mozilla.org/pub/opus/opusfile-0.8.zip
> https://mf4.xiph.org/jenkins/view/opus/job/opusfile-unix/
> ws/doc/html/group__stream__seeking.html
>
>  -r
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/ogg-dev/attachments/20161114/d00296d4/attachment.html>

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