Opus inside OggPages, Decoding a live Opus internet stream Options

[thinktink]

I'm currently working on a Winamp input plugin to provide better native support for the Opus codec than the one that dshow could provide linking in the k-lite codec pack. Metadata and whatnot.

Anyways, I'm dynamically linking in the official opusfile-0.1-win32 libraries from the opus-codec site and I have been able to succesfully decode and get Winamp to play a local .opus file. However, I've not been so fortunate with online streams.

I am not familiar at all with any of the internals/packets/pages/whatevers of live streams. I can get my plugin to connect to a server, get the data it's outchucking, parse out the HTTP header, parse the seperate Ogg Pages, get the OpusHead, and get the OpusTags, but that's it. I tried sending, just the Ogg pages, a chain of Ogg pages, individual segments in the pages, to all of the in-memory functions of the libraries but they all either return error code -133 (OP_EBADHEADER), -137 (OP_EBADLINK), or -139 (OP_EBADTIMESTAMP).

I know nothing of "granules", whatever that means.

Can somebody tell me how to decode an Ogg Opus stream with those libraries or if it's not possible to?

C++

tia

This post has been edited by thinktink: Nov 14 2012, 06:19

[nu774]

Made a (quick & dirty) patch for opusfile, which opens http support on win32:
 winsock.patch.gz ( 5.11K ) Number of downloads: 52

This patch is built against the latest commit of the official git repository:

CODE

commit f2e27e4d1aa6e1b12b1af5bce166d1c3b10473dd
Author: Ralph Giles <giles@mozilla.com>
Date:   Wed Nov 14 11:05:32 2012 -0800

I used mingw-w64 toolchain on Linux.

Some tweak might be still needed to take care of OPENSSL_AppLink to get https support working.
In win32, user application of openssl is required to do

CODE

#include <openssl/applink.c>

or something, when openssl is compiled with OPENSSL_USE_APPLINK.
I don't know how it should be taken care of, from the library point of view (it must be done by user of libopusfile, since openssl always searches that function in executable module).

[thinktink]

Made a (quick & dirty) patch for opusfile, which opens http support on win32:
 winsock.patch.gz ( 5.11K ) Number of downloads: 52

This patch is built against the latest commit of the official git repository:

CODE

commit f2e27e4d1aa6e1b12b1af5bce166d1c3b10473dd
Author: Ralph Giles <giles@mozilla.com>
Date:   Wed Nov 14 11:05:32 2012 -0800

I used mingw-w64 toolchain on Linux.

Some tweak might be still needed to take care of OPENSSL_AppLink to get https support working.
In win32, user application of openssl is required to do

CODE

#include <openssl/applink.c>

or something, when openssl is compiled with OPENSSL_USE_APPLINK.
I don't know how it should be taken care of, from the library point of view (it must be done by user of libopusfile, since openssl always searches that function in executable module).

Well rats, that didn't work.

CODE

C:\Program Files\GnuWin32\bin>patch < winsock.patch
can't find file to patch at input line 5
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/Makefile.am b/Makefile.am
|index e572ed8..371d61e 100644
|--- a/Makefile.am
|+++ b/Makefile.am
--------------------------
File to patch: libopusfile-0.dll
patching file libopusfile-0.dll
Hunk #1 FAILED at 12.
1 out of 1 hunk FAILED -- saving rejects to file libopusfile-0.dll.rej
can't find file to patch at input line 23
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|gure.ac b/configure.ac
|index 3133b7f..fe74c3c 100644
|--- a/configure.ac
|+++ b/configure.ac
--------------------------
File to patch:

Just as a side note, I tried using the libogg functions to parse the packets out of the stream instead of finding and parsing them myself. It made it worse! lol When I sent the packets to the decode function sometimes the decode function would throw floating point errors and all the audio data it did return (when it didn't throw exceptions) sounded like uninitialized memory.

[NullC]

Just as a side note, I tried using the libogg functions to parse the packets out of the stream instead of finding and parsing them myself. It made it worse! lol When I sent the packets to the decode function sometimes the decode function would throw floating point errors and all the audio data it did return (when it didn't throw exceptions) sounded like uninitialized memory.

Then you're using them wrong— but I can't tell how because you haven't described what you're doing. This has worked for many other people without issue for Opus and for tens of thousands of developers for other codecs.

You really need to stop trying to parse ogg yourself unless you're willing to sit down, read the docs, read the Ogg RFC, etc. It isn't complicated, but your guesses are guiding you incorrectly: Segments are not packets. You need to pass full packets to libopus, which means that the segments must be reassembled. Libogg does this for the caller.

[thinktink]

...SNIP...
You really need to stop trying to parse ogg yourself unless you're willing to sit down, read the docs, read the Ogg RFC, etc. It isn't complicated, but your guesses are guiding you incorrectly: Segments are not packets. You need to pass full packets to libopus, which means that the segments must be reassembled. Libogg does this for the caller.

Found the Ogg RFC and found the key piece of information that I was missing. I managed to do it half right by arbitrarily considering any segment that was 255 bytes long as incomplete, which was half correct. The other half was segments that are zero bytes, which I didn't realize was legal, to indicate the end of a packet that was exactly modulus(len,255)==0 is actually complete.