knetic / jopus Goto Github PK

Opus supports some great seeking capabilities, but none of that is yet exposed. It would be best if this library were to support queries to "op_seekable", and "op_pcm_seek".Opus supports some great seeking capabilities, but none of that is yet exposed. It would be best if this library were to support queries to "op_seekable", and "op_pcm_seek".

Currently, the build process creates "libopus", "libopusfile" and "libjopus". jopus relies on the other two, but the other two are not used by anything else. Worse, the Android NDK process requires that shared libraries be built from very specific sources by the Android tool, so having three shared libraries is impractical at best.

Instead, the build process ought to create a single "libjopus", which includes all the code from opusfile and opus.

libopusfile (which this library depends heavily upon) supports "op_open_http", which reads compressed Opus data from an abstract HTTP/1.1+ URL. This allows really cool cases where an HTTP stream is downloaded and decoded on-the-fly, rather than requiring it be on file.

This library ought to have an interface "OpusSource" defined, which specifies an "open", "read", "getFormat", "getSamples", and "close" methods. JOpusFile ought to implement that interface, and so too should another implementation which uses op_open_http.

libopusfile (which this library depends heavily upon) supports "op_open_memory", which reads compressed Opus data directly from a memory stream. This allows much greater flexibility for downstream caching or live-consumption.

This library ought to have an interface "OpusSource" defined, which specifies an "open", "read", "getFormat", "getSamples", and "close" methods. JOpusFile ought to implement that interface, and so too should another implementation which uses op_open_memory.

Hi!

I am receiving an Opus stream on a Java server (through a WebSocket) and I want do decode it in realtime.

So can I just subclass OpusDecodable and implement read() and close()? It seems like it to me but I'm not sure about things like wrapperPointer.

Thanks for advice

Edit: Oh, seems I completely misunderstood the read() method. I thought it gets a byte from a stream but it does something else completely...

Right now, only POSIX-compliant systems can build this package. That's fine for most applications, but if someone really wants to ship to clients, Windows support is a must.

Add in steps to compile via mingw gcc and dllwrap.

This library pulls some information from OpusHead for use in constructing an AudioFormat object that describes the Opus stream. But there is other information which is useful to consumers, notably "version", and "stream_count".

It's also advisable to expose wrapper methods for the following native functions (see this link)

"op_raw_total"
"op_pcm_total"
"op_bitrate" / "op_bitrate_instant"

Opus files can have metadata tags associated with them - typically for purposes like tagging track #, artist, genre, album, cover art, etc. opusfile supports reading this data, but this library doesn't yet wrap that functionality.