search for: discardpad

...e 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 couldn't be recover...

...> 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...

...> 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...

...on 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 cou...

...#39;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 >>...

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

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

..., 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....

..., 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....

.... 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 another, you'd have to jump over these little gaps? The document says it would be useful...

...;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-skip), WebM use...

Brendan Bolles wrote: > 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 another, you'd have to jump over these > little gaps? The intent was n...