search for: felicia

...ph and Jean-Marc. Please find attached the amended patch: - decodes a sequence of input packets rather than just one (I'm planning on using the Opus test vectors as the seed corpus) - decides on decoder setup and FEC independently of the packet data - uses Opus functions to parse ToC Cheers, Felicia On Sun, Jan 29, 2017 at 9:48 PM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi Felicia, > > Here's a few comments/questions on your patch: > > > static void ParseToc(const uint8_t toc, TocInfo *const info) { > > Any particular reason you don't use the Op...

Hi, I wondered if are there any further thoughts on these patches? Thanks, Felicia On Thu, Jun 2, 2016 at 2:13 PM Felicia Lim <flim at google.com> wrote: > OK, I've amended the second patch and also added 80 and 100 ms. > > Thanks, > Felicia > > > On Thu, Jun 2, 2016 at 7:20 AM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > >> On...

On 06/01/2016 02:06 PM, Felicia Lim wrote: > That was my intention with refactoring out the subframe encoding and > repacketizing bit. Or do you mean I should merge the explicit check for > 120 ms frame and the existing checks for 40/60 ms wideband? What I mean is that this line in opus_encoder.c: if (frame_size >...

Attached is the amended second patch. It now extends the multistream API as well to 80/100/120 ms and incorporates changes based on Mark's comments. Thanks, Felicia On Mon, Jun 13, 2016 at 4:21 PM Felicia Lim <flim at google.com> wrote: > Hi Mark, Jean-Marc, > > Thanks for your comments. > > On Sun, Jun 12, 2016 at 6:34 AM Mark Harris <mark.hsj at gmail.com> wrote: > >> Hi Felicia, >> >> A few comments: >&gt...

..._rate/50; > -- > > I wonder whether it wouldn't be better style to convert argv[ args + 1 ] > to a number once and then use a switch/case statements to test for > individual numbers. Or is it expected to be non-numerical once? > > Regards, > Ulrich > > >>> Felicia Lim <flim at google.com> schrieb am 27.06.2016 um 15:05 in > Nachricht > <CAJ0LFHW97AJ0J4EsaV2yO+EjJKnz8F47w1Te6_0y4tLA6xAmsw at mail.gmail.com>: > > Attached is the amended second patch. It now extends the multistream API > as > > well to 80/100/120 ms and incorpor...

Hi Felicia, A few comments: > - /* CELT can only support up to 20 ms */ > subframe_size = st->Fs/50; > - nb_subframes = frame_size > st->Fs/25 ? 3 : 2; > + nb_subframes = frame_size/subframe_size; This will use six 20ms frames to make a 120ms packet, even for...

Hi, Attached is a patch with arm neon optimizations for silk_warped_autocorrelation_FIX(). Please review. Thanks, Felicia -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20170131/9a912bb4/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Optimize-silk_warped_autocorrelati...

...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 Ty...

...;)==0) + frame_size = 6*sampling_rate/50; -- I wonder whether it wouldn't be better style to convert argv[ args + 1 ] to a number once and then use a switch/case statements to test for individual numbers. Or is it expected to be non-numerical once? Regards, Ulrich >>> Felicia Lim <flim at google.com> schrieb am 27.06.2016 um 15:05 in Nachricht <CAJ0LFHW97AJ0J4EsaV2yO+EjJKnz8F47w1Te6_0y4tLA6xAmsw at mail.gmail.com>: > Attached is the amended second patch. It now extends the multistream API as > well to 80/100/120 ms and incorporates changes based on Mar...

Hi all, I'm working on fuzzing Opus with OSS-Fuzz and have started with the decoder. Attached is a patch to add the corresponding fuzz target. Please let me know if there are any concerns? Thanks, Felicia -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20170127/f69951aa/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-decoder-fuzz-target.patch Type...

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 w...

...frames is on bandwidth limited links having a gross (physical) bit rates of 10kbps per channel. Decades ago I calculated with figure (for AMR-NB but the same holds for Opus). https://www.tkn.tu-berlin.de/fileadmin/fg112/Hard_Software_Components/Software/hoene_07_2004_paper.pdf Von: Felicia Lim [mailto:flim at google.com] Gesendet: Freitag, 10. Juni 2016 16:59 An: Christian Hoene <christian.hoene at symonics.com> Betreff: Re: [opus] Patches for adding 120 ms encoding Yes, that's right. In that case, a longer frame size means that we can reduce header overhead. On Fr...

Hi Felicia, I still need to look very carefully, which will take some time. That being said, some comments I can already make: 1) You need to also update the multi-stream API. 2) You might want to check that CBR works for >60 ms encoding Cheers, Jean-Marc On 06/10/2016 10:19 AM, Felicia Lim wrote: &g...

Hi Felicia, Overall the patch looks good to me and it's a pretty reasonable starting points. Some minor comments below. On 10/02/17 02:44 PM, Felicia Lim wrote: > - decodes a sequence of input packets rather than just one (I'm planning > on using the Opus test vectors as the seed corpus) I re...

Hi Mark, Jean-Marc, Thanks for your comments. On Sun, Jun 12, 2016 at 6:34 AM Mark Harris <mark.hsj at gmail.com> wrote: > Hi Felicia, > > A few comments: > > > - /* CELT can only support up to 20 ms */ > > subframe_size = st->Fs/50; > > - nb_subframes = frame_size > st->Fs/25 ? 3 : 2; > > + nb_subframes = frame_size/subframe_size; > > This will use six 20m...

Hi, Please find attached a patch to fix alignment exceptions. Without this change, we were seeing occasional alignment faults when using this with clang. Thanks, Felicia -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20170818/e0d6bb06/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: e5c277c.diff Type: text/x-patch Size: 916 by...

...re seeing? > (One issue might be that clang’s address sanitizer isn’t smart enough to > know that PMOVSXWD only loads 8 bytes, despite _mm_cvtepi16_epi32’s > argument being an __mm128i; I’ve seen it trigger incorrect out-of-bounds > read errors.) > > On Aug 18, 2017, at 12:34 PM, Felicia Lim <flim at google.com> wrote: > > Hi, > > Please find attached a patch to fix alignment exceptions. Without this > change, we were seeing occasional alignment faults when using this with > clang. > > Thanks, > Felicia > > <e5c277c.diff>________________...

...i movdqa %xmm2, %xmm3 pmullw %xmm1, %xmm2 --- 73,80 ---- cmpl $4, %eax jl .LBB0_8 # BB#7: ! movq (%edx,%edi,2), %xmm2 # xmm2 = mem[0],zero ! movq (%esi,%edi,2), %xmm1 # xmm1 = mem[0],zero addl $4, %edi movdqa %xmm2, %xmm3 pmullw %xmm1, %xmm2 On Fri, Aug 18, 2017 at 12:11 PM, Felicia Lim <flim at google.com> wrote: > We see the MOVQ instruction but this patch deliberately uses it rather > than MOVQDA (load 128-bits aligned). We were seeing that with the trace > below, the final invocation is not 128-bit aligned but MOVQDA insists on it > (the calling function...

...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...

Hi Felicia, Thanks for the patch. Can you give more details on what checks/tests you've done so far on this patch? Thanks, Jean-Marc On 31/01/17 12:30 PM, Felicia Lim wrote: > Hi, > > Attached is a patch with arm neon optimizations for > silk_warped_autocorrelation_FIX(). Please review....