[opus] Opus for ASR - update and questions

[Young, Milan]

Thank you Benjamin, a few follow-up question please:


*       Is "packet" the right word to be using in these discussions?  Perhaps I'm wrong, but I always thought of a packet as a bundle of information on the wire.  If so, a copy of the previous packet in the current might contain many "segments" of audio (because the previous packet itself may have contained redundancy).  If there is a better term (eg "segments"), please let me know.  If not I'll continue using "packet".

*       Is the decision to copy information from N-1 into N binary?  In other words, is it ever the case that a partial copy occurs, or is it all or nothing decision?

*       Does packet N ever contain information from more than one previous packets (eg N-2), or is it always a single?

*       What is the limit of the redundancy provided by this feature?  Is it simply that every packet contains the previous packet's data, or does it go further than this by sending duplicate copies of each individual packet (which themselves contain the previous packet data).

*       Continuing on the above, how does one trigger that maximum mode.  Perhaps one should set expect-loss to 100%, but that has some odd implications.  If all packets will be dropped, the situation seems hopeless :).

*       When setting these parameters, any advice for Ethernet frame sizes?  I'm not much of a networking guy, but it seems that the risk of failure would climb dramatically if a packet spanned multiple frames.

Regards


From: Benjamin Schwartz [mailto:benjamin.m.schwartz at gmail.com]
Sent: Friday, November 30, 2012 8:41 AM
To: Young, Milan
Cc: opus at xiph.org
Subject: Re: [opus] Opus for ASR - update and questions

The Low Bit-Rate Redundancy (LBRR) feature works by sometimes adding another copy of packet N-1 onto packet N.  This means that a traditional decoder that wishes to use the LBRR info must increase its jitter buffer depth, and hence latency, by one packet, so that if packet K is dropped, there is time to receive and decode packet K+1.  However, in the case of ASR I think this logic does not apply, and the latency penalty must only be paid in the rare case when the last packet before a data return event is dropped.

Expect-loss is not a simulation of loss.  It is a way to tell the encoder "I expect that my network will drop X% of packets".  The higher the value of X, the more the encoder will spend bits to avoid depending on previous packets that may not have arrived.  This means increasing the use of LBRR, decreasing the use of sensitive long-term filters, and many other changes in encoding strategy.

On Wed, Nov 28, 2012 at 3:50 PM, Young, Milan <Milan.Young at nuance.com<mailto:Milan.Young at nuance.com>> wrote:
For the last couple months, Nuance has performed extensive testing on how the Opus codec performs in the speech recognition task.  I'm hoping to publish a full report in the coming months, but until then all I have is a teaser.  Opus performed within about 1% of the WER (Word Error Rate) of unencoded audio.  This is compared to about 5% for Speex, which was the previous codec of choice.  Well done to you all!

As Nuance considers migrating to Opus, we'd like to consider the topic of transport.  Traditionally we've relied on TCP for reasons of reliability.  Opus, with its packet redundancy features, offers an attractive real-time alternative that we will soon be testing.  But in order to apply an apples-apples comparison we need to model both data rates and latency in real world scenarios.

For UDP, I'm assuming that the redundancy feature adds no additional latency.  Correct?  On the data rate question, I see that the Opusenc tool provides an "expec-loss" parameter with the value expressed as a percentage.  Could someone please describe how this is implemented?  Are you simply removing some percentage of packets from the result, or is there a more complex model underpinning the exercise?

Modeling TCP data rates and latency in similarly losssy scenarios seems much more difficult since dropped packets have cascading effects.  Has anyone on this list considered this class of comparison?  Any suggestions for modeling software that could aid my search?

Thank you


_______________________________________________
opus mailing list
opus at xiph.org<mailto:opus at xiph.org>
http://lists.xiph.org/mailman/listinfo/opus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/opus/attachments/20121130/55ff7ce5/attachment-0001.htm