Hi all, 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. Any thoughts would be appreciated. Thanks, Felicia -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20160531/1045ee29/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Extend-support-for-120-ms.patch Type: text/x-patch Size: 11669 bytes Desc: not available URL: <http://lists.xiph.org/pipermail/opus/attachments/20160531/1045ee29/attachment-0002.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Refactor-code-for-subframe-encoding-and-repacketizat.patch Type: text/x-patch Size: 7759 bytes Desc: not available URL: <http://lists.xiph.org/pipermail/opus/attachments/20160531/1045ee29/attachment-0003.bin>
Hi all, 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. Thanks, Felicia On Tue, May 31, 2016 at 7:05 PM Felicia Lim <flim at google.com> wrote:> Hi all, > > 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. > > Any thoughts would be appreciated. > > Thanks, > Felicia >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20160601/0a401c07/attachment.html> -------------- next part --------------
Hi Felicia, I still don't quite understand why you need to make 120 ms a special case, rather than extend the code that already handles 40 ms and 60 ms. Cheers, Jean-Marc On 06/01/2016 12:58 PM, Felicia Lim wrote:> Hi all, > > 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. > > Thanks, > Felicia > > > > On Tue, May 31, 2016 at 7:05 PM Felicia Lim <flim at google.com > <mailto:flim at google.com>> wrote: > > Hi all, > > 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. > > Any thoughts would be appreciated. > > Thanks, > Felicia > > > > _______________________________________________ > opus mailing list > opus at xiph.org > http://lists.xiph.org/mailman/listinfo/opus >