<html>
<head>
<base href="https://wiki.asterisk.org/wiki">
<link rel="stylesheet" href="/wiki/s/2036/1/7/_/styles/combined.css?spaceKey=TOP&forWysiwyg=true" type="text/css">
</head>
<body style="background: white;" bgcolor="white" class="email-body">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
<h2><a href="https://wiki.asterisk.org/wiki/display/TOP/Desirable+Codecs%2C+Audio+and+Video?focusedCommentId=11337805#comment-11337805">Desirable Codecs, Audio and Video</a></h2>
<h4>Page
<b>comment added</b> by <a href="https://wiki.asterisk.org/wiki/display/~kpfleming">Kevin P. Fleming</a>
</h4>
<br/>
<div class="notificationGreySide">
<p>Actually, any codec with a decent PLC implementation can result in a one-packet-in and multiple-frames-out scenario, and even just basic jitter buffering of formats that don't have native PLC can cause this as well. As Tim says, any well-designed packet-oriented codec will have this behavior.</p>
</div>
<div style="border-bottom: 1px solid #ddd; padding: 10px 20px 7px 20px;">
<strong>In reply to a comment by <a href="/wiki/display/~tpanton"
class="url fn confluence-userlink" data-username="tpanton"
>Tim Panton</a>:</strong><br/>
<p>SILK isn't totally closed source, the source is freely available for evaluation, just not commercial use - for that a license is required.</p>
<p>SILK is interesting as it places some requirements on the way a network stack is built. Ideally the encoder will have parameters tweaked in realtime <em>during</em> a call <br/>
based on the reported network statistics (especially packet loss) from the far end.</p>
<p>So the received RTCP values for packetloss would be fed to the encoder to shape outgoing packet bandwidth usage and level of redundant info</p>
<p>Also the plc code uses the next available packet to extract redundant data which is used to reconstitute the missing packet. This impacts the way that decoders work, in that you can sometimes get 2 frames out for one packet in.</p>
<p>These may seem like oddities, but they represent internet (dynamic) thinking as opposed to TDM (static) allocation of bandwidth. </p>
<p>I think early support for SILK and SILK-like codecs is essential to future-proof ASCF</p>
</div>
<div id="commentsSection" class="wiki-content pageSection">
<div style="float: right;">
<a href="https://wiki.asterisk.org/wiki/users/viewnotifications.action" class="grey">Change Notification Preferences</a>
</div>
<a href="https://wiki.asterisk.org/wiki/display/TOP/Desirable+Codecs%2C+Audio+and+Video?focusedCommentId=11337805#comment-11337805">View Online</a>
|
<a id="reply-11337805" href="https://wiki.asterisk.org/wiki/display/TOP/Desirable+Codecs%2C+Audio+and+Video?replyToComment=11337805#comment-11337805">Reply To This</a>
</div>
</div>
</div>
</div>
</div>
</body>
</html>