search for: codecdelay

...xtensions. I'll have a look whether disabling prediction will help with the transitioning phase, but I think the way I'm implementing it right now it probably won't. So here is what I was going to write originally: When I wrote the question, I wasn't really aware of the pre-skip (CodecDelay in WebM) and DiscardPadding [1]. However, these properties can only be set on a per-stream basis, and not on independent sequences of WebM packets. As a consequence of my ignorance regarding pre-skip, I also didn't append an additional frame to the audio such that 6.5ms lost due to the pre-skip...

...will help with the >> transitioning phase, but I think the way I'm implementing it right now >> it probably won't. >> >> So here is what I was going to write originally: >> >> When I wrote the question, I wasn't really aware of the pre-skip >> (CodecDelay in WebM) and DiscardPadding [1]. However, these properties >> can only be set on a per-stream basis, and not on independent >> sequences of WebM packets. As a consequence of my ignorance regarding >> pre-skip, I also didn't append an additional frame to the audio such >>...

...will help with the >> transitioning phase, but I think the way I'm implementing it right now >> it probably won't. >> >> So here is what I was going to write originally: >> >> When I wrote the question, I wasn't really aware of the pre-skip >> (CodecDelay in WebM) and DiscardPadding [1]. However, these properties >> can only be set on a per-stream basis, and not on independent >> sequences of WebM packets. As a consequence of my ignorance regarding >> pre-skip, I also didn't append an additional frame to the audio such >>...

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.

...ether disabling prediction will help with the > transitioning phase, but I think the way I'm implementing it right now > it probably won't. > > So here is what I was going to write originally: > > When I wrote the question, I wasn't really aware of the pre-skip > (CodecDelay in WebM) and DiscardPadding [1]. However, these properties > can only be set on a per-stream basis, and not on independent > sequences of WebM packets. As a consequence of my ignorance regarding > pre-skip, I also didn't append an additional frame to the audio such > that 6.5ms lost...

..., but I think the way I'm implementing it right now >>>> it probably won't. >>>> >>>> So here is what I was going to write originally: >>>> >>>> When I wrote the question, I wasn't really aware of the pre-skip >>>> (CodecDelay in WebM) and DiscardPadding [1]. However, these properties >>>> can only be set on a per-stream basis, and not on independent >>>> sequences of WebM packets. As a consequence of my ignorance regarding >>>> pre-skip, I also didn't append an additional frame to...

...> transitioning phase, but I think the way I'm implementing it right now >>> it probably won't. >>> >>> So here is what I was going to write originally: >>> >>> When I wrote the question, I wasn't really aware of the pre-skip >>> (CodecDelay in WebM) and DiscardPadding [1]. However, these properties >>> can only be set on a per-stream basis, and not on independent >>> sequences of WebM packets. As a consequence of my ignorance regarding >>> pre-skip, I also didn't append an additional frame to the audio s...

...> transitioning phase, but I think the way I'm implementing it right now >>> it probably won't. >>> >>> So here is what I was going to write originally: >>> >>> When I wrote the question, I wasn't really aware of the pre-skip >>> (CodecDelay in WebM) and DiscardPadding [1]. However, these properties >>> can only be set on a per-stream basis, and not on independent >>> sequences of WebM packets. As a consequence of my ignorance regarding >>> pre-skip, I also didn't append an additional frame to the audio s...

...njamin Schwartz wrote: > Yes, it's basically an intrinsic aspect of the mathematics. If you seek into the middle of an Opus stream, that's about how long it takes before the audio converges to be correct. I see. Thanks for the info. Any idea about the other Matroska tags? I guess CodecDelay will be the value you get from OPUS_GET_LOOKAHEAD() converted to nanoseconds? DiscardPadding seems to assume that you might top off an opus frame with empty samples when the frame would spill onto the next matroska timestamp. So rather than have continuous opus that could be decoded one after an...

Hi! Short version of my question: How to produce Opus frames which can be safely concatenated and how to embed them into a WebM file? Long version: I'm currently implementing a web-based audio player which streams audio as opus/WebM using the HTML5 media source extensions. Currently, the server decodes a set of input files to a fixed RAW audio format (stereo, 48000 kHz) and encodes the

...right, but I'd love for someone more knowledgeable about Opus or WebM to take a look. The closest thing to a standards document for putting Opus into WebM is here: http://wiki.xiph.org/MatroskaOpus The muxing library I'm using (libwebm) doesn't seem to let me set these SeekPreRoll, CodecDelay, and DiscardPadding fields. Are these related to Opus' pre-skip field? SeekPreRoll is supposed to be standard, but there's no way to force the encoder to use a certain pre-skip, is there? While granulepos in the Ogg container gives you the actual number of PCM samples (including the pre...

Yes, it's basically an intrinsic aspect of the mathematics. If you seek into the middle of an Opus stream, that's about how long it takes before the audio converges to be correct. On Jan 17, 2014 2:13 PM, "Brendan Bolles" <brendan at fnordware.com> wrote: > On Jan 7, 2014, at 11:11 AM, Brendan Bolles wrote: > > > The closest thing to a standards document for