opus - May 2014 - Question about PLC in OPUS

I have a question about PLC used by OPUS.

We are using OPUS for streaming music in some application.

Due to some network problems, we are running into problems related to clock
drifts. This causes jitter buffer underflows at the receiver and hence we need
to rebuffer the jitter buffer periodically. We are looking at the root cause of
this problem (drift), but that's besides the point.

During jitter buffer rebuffering, we are sending null frames to the OPUS decode,
indicating lost frames. My question is - Is this the most effective way of
handling this situation?

Or is it a better to detect such imminent underflow by some means and then
insert "lost" frames in the middle sporadically to avoid the complete
jitter buffer underflow?

Thanks for your help,
Abhijit


-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information.  Any unauthorized review, use, disclosure or
distribution
is prohibited.  If you are not the intended recipient, please contact the sender
by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/opus/attachments/20140529/4b228f90/attachment.htm

You might want to consider using parts of the WebRTC library, instead of
using Opus directly.  In addition to Opus packetization, WebRTC also
includes a component called "NetEQ" that corrects for clock drift by
stretching the decoded audio, without using PLC.


On Thu, May 29, 2014 at 7:13 AM, Abhijit Patait <apatait at nvidia.com>
wrote:
> I have a question about PLC used by OPUS.
>
>
>
> We are using OPUS for streaming music in some application.
>
>
>
> Due to some network problems, we are running into problems related to
> clock drifts. This causes jitter buffer underflows at the receiver and
> hence we need to rebuffer the jitter buffer periodically. We are looking at
> the root cause of this problem (drift), but that?s besides the point.
>
>
>
> During jitter buffer rebuffering, we are sending null frames to the OPUS
> decode, indicating lost frames. My question is ? Is this the most effective
> way of handling this situation?
>
>
>
> Or is it a better to detect such imminent underflow by some means and then
> insert ?lost? frames in the middle sporadically to avoid the complete
> jitter buffer underflow?
>
>
>
> Thanks for your help,
>
> Abhijit
>
>
>  ------------------------------
>  This email message is for the sole use of the intended recipient(s) and
> may contain confidential information.  Any unauthorized review, use,
> disclosure or distribution is prohibited.  If you are not the intended
> recipient, please contact the sender by reply email and destroy all copies
> of the original message.
>  ------------------------------
>
> _______________________________________________
> opus mailing list
> 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/20140529/d86f2b13/attachment.htm