similar to: preskip and seeking suing Opus

Yes, that's a start. Ultimately, though, I'm hoping to reduce the 80ms requirement, and am trying to get a handle on what state in the decoder must converge and what complications I might be up against. I'm also only considering CELT-based encodings if that simplifies things. I know that Opus can do inter-frame energy envelope prediction, but that dependency can be eliminated by

On 13-08-14 10:09 PM, Bob Estes wrote: > I've been studying the Opus code and documentation for a while and have > seen it mentioned several times that Opus uses pre-skip to allow the > codec to converge. What convergence are they referring to? Rate > control? Energy envelope prediction after seeking? Not rate control, but there are a number of predictors running in the

I am a software developer myself. We develop a Radio Automation System/Broadcasting. Hence we are using the reference encoders. For OGG there is LUCKILY still the admin interface working to update meta data mid-stream. That is why my post is related to the other ogg based formats: FLAC and OPUS! Tractor Pro is btw not supporting FLAC or OPUS and alao uses the admin update interface! As such

Hello, We have a use case where we want to record an opus RTP stream to a .opus file. We want to fill in any gaps in the stream, and we also want to take advantage of inband FEC whenever possible. The ogg/opus draft describes[1] how to fill in gaps by generating zero-byte frames, but I do not understand how (and if) FEC can be used. Is this possible, and if so, what is the recommended way of

Hi all, I finally understand how lipopusenc is capable of producing chainable Opus files (in contrast to my program), and I managed to successfully implement the method [1]. Essentially, the last frame of a file is marked as a "keyframe" by disabling prediction for this frame in libopus. This encoded keyframe frame is then copied in verbatim to the next file, with the pre-skip set to

It does not; Vorbis needs only lap consecutive frames, and the timing was constructed so that the 'timestamp' of a vorbis frame actually points to the middle of the frame data. When you combine a starting frame with the subsequent frame, the data you get back is from the starting timestamp forward. Because Opus needs to preroll a larger amount, that trick wouldn't work with Opus.

Hello!, i've just compared the 1.0.3 release with the master branch on a BeagleBone Black (AM335x 1GHz ARM Cortex-A8 with NEON floating-point accelerator) and Arch Linux ARM. At the moment I dont no why, but I see that 1.1 is much slower in encoding. Are there any default changes, that I missed and could explain this? Normaly I suggested a better performance with 1.1 and the ARM

David Flynn has proposed a new Ogg Dirac mapping. The draft is here: http://davidf.woaf.net/dirac-mapping-ogg.pdf This is a much bigger break from other codecs than my draft (at http://wiki.xiph.org/index.php/OggDirac). We talked a bit about it on IRC today. Below is my summary; hopefully David can correct anything I got wrong or misleading. Comments? There are two main differences

(Cross posted to theora-dev@xiph.org and ffmpeg-devel@mplayerhq.hu) I am working towards adding Theora encoding support to libavcodec in FFmpeg. I am doing this by simply calling libtheora from libavcodec. I am at the point where I can execute: "./ffmpeg -v 100 -i test.wmv -f avi -an -vcodec theora -b 1000000 -y test.avi" I get some whirring and an output file written. My calls to

Hi Jean-Mark, thank you for your answer! Yes, you understood my question correctly. I was just about to compose a reply to my original question, where I described how I solved my problem. As you've already suggested, I've switched to Ogg/Opus, which is better supported, but does not work with the Media Source Extensions. I'll have a look whether disabling prediction will help with

Hi All, First time poster to this group, please ignore my ignorance? I?m trying to use Opus 1.1 on a 400MHz MIPS 24k CPU (AR9331, specifically, like in the Arduino Yun). I?ve successfully built (I think) opus-1.1 and opus-tools-1.8 and they run, but are dog slow. opus-1.1 does have the ?enable-fixed-point option set, as this chip only has soft-float. My short test file (less than one

Looking at the Opus comparison page[1], I can't figure out whether the Opus/AAC/Vorbis/MP3 lines are meant to imply a mono or stereo encoding. Could someone please update the caption to clarify this? The single dot for G.711 is clearly mono, but for stereo music, are the codecs at the top meant to converge near 128 kbps, or 256 kbps? [1] http://opus-codec.org/comparison/

But is there any sound player for windows that plays speex in an ogg container? One more question, besides the source code found in the speex site (like speexenc.c) can you tell me where to find source code developed in C++ (using object oriented programing) that makes it easier to write ogg files with speex content? Miguel Gomes -----Mensagem original----- De:

L'octidi 18 pluviôse, an CCXXV, Miscellaneous a écrit : > > The RLP draft mentioned on the libvorbis docs page, are there sample > > implementations (in C) of this yet anywhere?  > Sorry that should say RTP, not RLP I am not sure I understand exactly what you are asking, but libavformat has a RTP packetizer that works for both Vorbis and Theora, implemented in rtpenc_xiph.c.

Hi! Playing with Opus 1.3 I converted a tone sweep with a sample rate of 96kHz (just for fun). Before I had converted that from WAV to FLAC, and to Vorbis without problems. With Opus I noticed that the file size for 48kHz and 48 kbps compared to 96kHz Vorbis at 31kbps is about double the size and it sounds even worse (than Vorbis) (there is a lot of noise in the lower frequencies when a low

Hello, I am testing the command line based opus encoder/decoder tools and I have some questions regarding the information given by the encoder (see below as an example). Encoding using libopus 1.0.2 (audio) ----------------------------------------------------- Input: 48kHz 1 channel Output: 1 channel (1 uncoupled) 20ms packets, 64kbit/sec VBR Preskip: 312 Encoding complete

Hi, I'm playing around using Opus in a 'chunked' streaming context, where chunks of media are served in separate HTTP responses. I am trying to hunt down the source of some clicks-and-pops during playback, and while it is very likely that these glitches are due to the low quality of my code, I wanted to ask if the admonition in the API docs[1] that "encoder state *must*

Hi. I assume that I am deeply stupid and have missed something obvious, but why does this bare-bones code not generate a valid (If trivial) opus file? Running opusinfo I ge the following which I interpret this to mean that not even the first packet gets a pass: New logical stream (#1, serial: 1f0cce42): type opus WARNING: Could not decode Opus header packet 0 - invalid Opus stream (1) WARNING:

Hi Jean-Marc (and everyone else who replied), > Considering you're switching to Ogg, I think you should give libopusenc> a try. It does a really good job at getting rid of *all* discontinuities> -- to the point where you can chop a song into files less than one> millisecond each and it still sounds good. It's also pretty simple to> use. You just feed it audio and tell it

Thomas, Thank you for your interest in this, you description is as accurate as I can see. > From my perspective your challenges will be to get the containers right. > WebM for audio+video > Ogg for audio > > Also (I'm not that familiar with webRTC) you might need to reencode > to Opus and VP8 in some cases? here is the great news