[opus] Availability of the 1.1.1 stable version
Suresh Thiriveedi
sthiriveedi at gmail.com
Mon Apr 20 04:27:25 PDT 2015
Hi,
We are able to reproduce the issue with the 1.1 opus_demo (sample file). We
captured the frames in our server just before the opus_decode and fed the
file to opus_demo (1.1) and it is crashing. Same file is tested with 1.1.1
and it is fine. So this is in line with our server testing observation and
I think here we can conclude that the 1.1 library is crashing while
handling a specific mode frame as explained in my earlier mail.
Here I'm attaching the captured opus encoded file which is causing the
crash.
Thanks
Suresh
On 17 April 2015 at 02:27, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote:
> To be decodable by opus_demo, you'll have to add the 8-byte "header".
> Just put in the length of the packet followed by "0" for the encoder
> range (0 means "not present").
>
> That being said, from previous experience, the most likely cause of the
> crash is a bug in your software causing a corruption in Opus. So it's
> safe to assume that if you can't reproduce the bug using opus_demo, then
> that's indeed the case.
>
> Cheers,
>
> Jean-Marc
>
> On 16/04/15 08:32 AM, Suresh Thiriveedi wrote:
> > This is observed on a live call between webRTC browser client and
> > another legacy client. Our server is there in between and transcoding
> > from opus to another codec and this is observed while decoding the opus.
> >
> > Anyway, I'll try to capture/dump the packets in the server before
> > feeding to the opus_decode and share with you. But this will not have
> > the first 8 bytes (length+enc range) to directly feed to the sample
> > binary. Please let me know if this is fine.
> >
> > Thanks
> > Suresh
> >
> > On 16 April 2015 at 17:36, Jean-Marc Valin <jmvalin at jmvalin.ca
> > <mailto:jmvalin at jmvalin.ca>> wrote:
> >
> > Please provide the input file that produces this with opus_demo.
> >
> > On 16/04/15 03:24 AM, Suresh Thiriveedi wrote:
> > > Hi Jean-Marc,
> > >
> > > Could you please update if you got a chance to look into. As I
> > > mentioned, I don't see the same issue in 1.1.1, but I don't see any
> > > difference in 1.1.1 other than optimization based on the
> architecture.
> > > This optimization could have fixed some stack overflow issue in
> some
> > > specific cases?
> > >
> > >
> > > Thanks
> > > Suresh
> > >
> > > On 13 April 2015 at 12:39, Suresh Thiriveedi <
> sthiriveedi at gmail.com <mailto:sthiriveedi at gmail.com>
> > > <mailto:sthiriveedi at gmail.com <mailto:sthiriveedi at gmail.com>>>
> wrote:
> > >
> > > Hi Jean-Marc,
> > >
> > > Thanks for your response. Please find the details as below.
> > >
> > > *_Backtrace we got for this crash:_*
> > >
> > > #0 0x0000000000800c54 in opus_decode_frame
> (st=0x38906b8f99d09c5,
> > >
> > > data=0xf0aa10b4ef1008ae <Address 0xf0aa10b4ef1008ae out of
> > > bounds>, len=-188613428, pcm=0x6e80016085efd57,
> > >
> > > frame_size=44037315, decode_fec=58716895) at
> > src/opus_decoder.c:384
> > >
> > >
> > > #1 0x00000000008009c0 in opus_decode_frame (st=0x712357d0,
> > >
> > > data=0x7effff9ab72d
> > >
> > "~▒`\\▒K\005▒▒y▒w+g~▒S2\025▒\036T▒\002x▒▒h!▒▒▒\220\233\066s▒\030#gb
> > > \rn▒rF\005Q▒\213;▒`\207$O▒(m\222=9▒▒/h▒▒t▒▒E묳w▒\237\"\206z\005
> > > \213»u at e", len=88, pcm=0x7effff9a6a80, frame_size=640,
> > decode_fec=0)
> > > at src/opus_decoder.c:319
> > >
> > >
> > > #2 0x0000000000801be1 in opus_decode_native (st=0x712357d0,
> > >
> > > data=0x7effff9ab72d
> > >
> > "~▒`\\▒K\005▒▒y▒w+g~▒S2\025▒\036T▒\002x▒▒h!▒▒▒\220\233\066s▒\030#gb
> > > \rn▒rF\005Q▒\213;▒`\207$O▒(m\222=9▒▒/h▒▒t▒▒E묳w▒\237\"\206z\005
> > > \213»u at e", len=89, pcm=0x7effff9a6a80, frame_size=640,
> > decode_fec=0,
> > > self_delimited=0,
> > >
> > > packet_offset=0x0, soft_clip=1) at src/opus_decoder.c:681
> > >
> > >
> > > #3 0x000000000080226c in opus_decode (st=0x712357d0,
> > >
> > > data=0x7effff9ab72c
> > >
> > "▒~▒`\\▒K\005▒▒y▒w+g~▒S2\025▒\036T▒\002x▒▒h!▒▒▒\220\233\066s▒\030#gb
> > > \rn▒rF\005Q▒\213;▒`\207$O▒(m\222=9▒▒/h▒▒t▒▒E묳w▒\237\"\206z\005
> > > \213»u at e", len=89, pcm=0x71245a60, frame_size=640,
> > decode_fec=0) at
> > > src/opus_decoder.c:867
> > >
> > >
> > > #4 0x00000000004fd6b5 in kn_opus_decode (decHandle=0x712357d0,
> > > decProp=0x1675698, src=0x16756d0, dest=0x71245a60,
> > >
> > > dstLen=0x1673210) at MSTranscodeOPUS.c:100
> > >
> > >
> > >
> > > *_And the code flow what we have observed for this specific
> > incident:_*
> > > *_
> > > _*
> > > *_Called this as mode is CELT_ONLY,_*
> > >
> > > if (data!=NULL && st->prev_mode > 0 && (
> > > (mode == MODE_CELT_ONLY && st->prev_mode !=
> MODE_CELT_ONLY &&
> > > !st->prev_redundancy)
> > > || (mode != MODE_CELT_ONLY && st->prev_mode ==
> MODE_CELT_ONLY) )
> > > )
> > > {
> > > _transition = 1_;
> > > /* Decide where to allocate the stack memory for
> pcm_transition */
> > > if (mode == MODE_CELT_ONLY)
> > > pcm_transition_celt_size = F5*st->channels;
> > > else
> > > pcm_transition_silk_size = F5*st->channels;
> > > }
> > >
> > > *_So transition is made as 1 called this,_*
> > >
> > > if (transition && mode == MODE_CELT_ONLY)
> > > {
> > > pcm_transition = pcm_transition_celt;
> > > opus_decode_frame(st, NULL, 0, pcm_transition, IMIN(F5,
> > > audiosize), 0);
> > > }
> > >
> > > *_In "opus_decode_frame" again, as data is passed as NULL,
> goes to
> > > else part_*
> > >
> > > if (data != NULL)
> > > {
> > > audiosize = st->frame_size;
> > > mode = st->mode;
> > > ec_dec_init(&dec,(unsigned char*)data,len);
> > > } else {
> > > audiosize = frame_size;
> > > mode = st->prev_mode;
> > >
> > > *_As the mode is made as prev mode now, which was a silk, this
> > goes
> > > inside,_*
> > >
> > > /* SILK processing */
> > > if (mode != MODE_CELT_ONLY)
> > > {
> > >
> > > *_Then in this function called this_*,
> > >
> > > silk_ret = silk_Decode( silk_dec, &st->DecControl,
> > > lost_flag, first_frame, &dec,
> > > pcm_ptr, &silk_frame_size );
> > >
> > >
> > > *_And finally, somehow, the "silk_frame_size" is a negative
> > value (
> > > say -1376272 in our case), then in the same function called the
> > > below and this crashes here._*
> > >
> > > pcm_ptr += silk_frame_size * st->channels;
> > >
> > >
> > > Please help.
> > >
> > > Thanks
> > > Suresh
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On 12 April 2015 at 21:23, Jean-Marc Valin <jmvalin at jmvalin.ca
> <mailto:jmvalin at jmvalin.ca>
> > > <mailto:jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca>>>
> wrote:
> > >
> > > Do you have any file that demonstrates the problem with
> either
> > > opus_demo
> > > or opusdec?
> > >
> > > Jean-Marc
> > >
> > > On 09/04/15 04:01 AM, Suresh Thiriveedi wrote:
> > > > Hi,
> > > >
> > > > I'm curious to know when would be the 1.1.1 stable
> version
> > > available.
> > > >
> > > > In 1.1, we are facing crash when opus library is trying
> to
> > > decode the
> > > > CELT-only, full band and 20 ms. So we tried with 1.1.1
> beta
> > > and it looks
> > > > to be fine. Is there any open issue regarding this in
> 1.1 version?
> > > >
> > > > Thanks
> > > > Suresh
> > > >
> > > >
> > > > _______________________________________________
> > > > opus mailing list
> > > > opus at xiph.org <mailto:opus at xiph.org>
> > <mailto:opus at xiph.org <mailto: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/20150420/6b440434/attachment-0001.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: opus_encoded_crash.opus
Type: audio/ogg
Size: 138153 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/opus/attachments/20150420/6b440434/attachment-0001.bin
More information about the opus
mailing list