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
-----------------------------------------------------
Encoded: 6.86 seconds
Runtime: 1e-06 seconds
(6.86e+06x realtime)
Wrote: 57354 bytes, 343 packets, 9 pages
Bitrate: 66.0921kbit/s (without overhead)
Rate range: 48.8kbit/s to 110.4kbit/s
(122 to 276 bytes per packet)
Overhead: 1.19% (container+metadata)
More specifically, I am interesting in knowing how should I interpret the
Runtime information '6.86e+06x realtime', the Bitrate detail
'without overhead' and the Overhead figure 1.19%.
I have also a question regarding the delay introduced by OPUS: is the delay from
encoder to decoder equal to the audio packet size (in this case, 20ms)? And,
what is the minimum encoder-decoder delay that can be achieved with OPUS?
Thanks in advance.
Met vriendelijke groeten | Best Regards,
Christian van Bijleveld
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/opus/attachments/20130515/2d719222/attachment.htm
Hallo Christiaan, groeten uit Nederland. Opus info : Frame sizes from 2.5 ms to 60 ms Total algorithmic delay for a codec is the sum of delays that must be incurred in the encoder and the decoder of a live audio stream regardless of processing speed and transmission speed, such as buffering audio samples into blocks or frames, allowing for window overlap and possibly allowing for noise-shaping look-ahead in a decoder and any other forms of look-ahead and Opus permits trading-off quality or bitrate to achieve an even smaller algorithmic delay (5.0 ms minimum).[26] While the default Opus frame is 20 ms long, a further 2.5 ms lookahead is required for window overlap in the CELT layer and noise shaping in the SILK layer, typically giving a delay of 22.5 ms. The SILK layer's minimum is 10 ms frames (12.5 ms delay), while the CELT layer's minimum is 2.5 ms (5.0 ms delay).[27] This is from the wiki page. If you want to out-source some of your work integrating the codec into your product, give me a call. (I am within 30 minutes from your office) Greetings, Edwin van den Oetelaar On Wed, May 15, 2013 at 9:47 AM, van Bijleveld Christian (ST-CO/ENG1.3) <Christian.vanBijleveld at nl.bosch.com> wrote:> 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 > ----------------------------------------------------- > Encoded: 6.86 seconds > Runtime: 1e-06 seconds > (6.86e+06x realtime) > Wrote: 57354 bytes, 343 packets, 9 pages > Bitrate: 66.0921kbit/s (without overhead) > Rate range: 48.8kbit/s to 110.4kbit/s > (122 to 276 bytes per packet) > Overhead: 1.19% (container+metadata) > > More specifically, I am interesting in knowing how should I interpret the > Runtime information ?6.86e+06x realtime?, the Bitrate detail ?without > overhead? and the Overhead figure 1.19%. > I have also a question regarding the delay introduced by OPUS: is the delay > from encoder to decoder equal to the audio packet size (in this case, 20ms)? > And, what is the minimum encoder-decoder delay that can be achieved with > OPUS? > Thanks in advance. > > Met vriendelijke groeten | Best Regards, > Christian van Bijleveld > > > > > _______________________________________________ > opus mailing list > opus at xiph.org > http://lists.xiph.org/mailman/listinfo/opus >
On 13-05-15 12:47 AM, van Bijleveld Christian (ST-CO/ENG1.3) wrote:> More specifically, I am interesting in knowing how should I interpret > the Runtime information ?6.86e+06x realtime?,This is a basic performance benchmark. The measured execution time for the encoder process was 1 microsecond (1e-06 is 1.x10^-6 in scientific exponential notation). Since the encoded audio is 6.86 seconds long that means that the encoder appeared to run at 6.86 million times realtime (6.86e+06 is 6.86x10^6), or it encoded at a rate of 6.86 million seconds of audio per second. In this case the one microsecond measurement is likely very inaccurate because of the short runtime relative to the timer resolution, so I wouldn't trust this number. If you run it on a few minutes of audio you'll get a more reliable runtime measurement.> the Bitrate detail ?without overhead? and the Overhead figure 1.19%.'without overhead' is the the average bitrate of just the compressed Opus packets without any external framing. This is the number which affects audio quality. It will generally be slightly less than the requested bitrate if you supplied one, since opusenc tries to take the container overhead into account. The Overhead figure is the percentage of the actual output file taken up by the containter formatting including framing, tag metadata, and timestamps for seeking. 1% is a normal amount. Hope that helps, -r