[ogg-dev] Help with Opus Streaming

Deepak K appdevwiz at gmail.com
Wed Nov 16 06:49:41 UTC 2016


Thanks for your response.

Unfortunately I am still in the dark. Can you kindly clarify the following:

Suppose I have a 6MB opus audio file that has an audio length of 48 minutes
on the server. My client application will request this opus file (via web
service) in chunks of say 512 bytes in a loop. Something like:

byte[] getFileChunk(int byteOffset, int length)

As the opus file is downloading, if the user wants to start listening to
the audio from 10th minute, he will move the audio slider accordingly. Now,
the client app will send this information to the server. Something like:

int getOpusAudioFileByteOffset(long audioPositionMilliseconds)

Now on the server (in my web service API getOpusAudioFileByteOffset), how
can I get\calculate this raw byte offset of the opus file corresponding to
this time?

If on the server I can calculate and provide this, the client can then
again request file download from that byte. Same as above i.e.:

byte[] getFileChunk(int byteOffset, int length)



On Tue, Nov 15, 2016 at 12:15 AM, Ralph Giles <giles at thaumas.net> wrote:

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/ogg-dev/attachments/20161116/3eb7707c/attachment.html>

More information about the ogg-dev mailing list