<div dir="ltr"><div>Hi all, </div><div><br></div><div>I've just realized that there's a better and simpler way of doing this which ensures that analysis and selection of the mode/bandwidth etc is done on the whole 120 ms frame. I believe that the logic and threshold values for making these decisions are still valid for 120 ms, but I might be missing something? Please find my updated patches attached. </div><div><br></div><div>Thanks, </div><div>Felicia</div><div><br></div><div><br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, May 31, 2016 at 7:05 PM Felicia Lim <<a href="mailto:flim@google.com">flim@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi all,</div><div><br></div><div>We (WebRTC/Google) would like to extend Opus to natively support 120 ms encoding instead of relying on repacketization as a post processing step. This is to ensure that a valid 120 ms packet is always available. I've attached a couple of patches to add this to opus_encoder(), based on the internal repacketization process carried out by 60 ms CELT. We intend to extend this later for the multistream encoder as well. The first patch refactors out the internal subframe encoding and repacketizing, and the second patch actually adds the 120 ms support.</div><div><br></div><div>Any thoughts would be appreciated.</div><div><br></div><div>Thanks,</div><div>Felicia</div></div></blockquote></div></div>