[opus] Availability of the 1.1.1 stable version

Jean-Marc Valin jmvalin at jmvalin.ca
Mon Apr 20 19:15:47 PDT 2015


I just tried decoding with v1.1:
./opus_demo -d 48000 2 opus_encoded_crash.opus out.pcm

and I see no issue (including with valgrind). Does the same command-line
create problems for you? What compile flags did you use? fixed-point or
float, any assembly, ...? Could be assembly here, or even a compiler bug
wouldn't be unheard of.

Cheers,

	Jean-Marc


On 20/04/15 07:27 AM, Suresh Thiriveedi wrote:
> 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
> <mailto: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>
>     > <mailto: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>>
>     >     > <mailto: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>>
>     >     >     <mailto: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>>
>     >     <mailto: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
>     >     >         >
>     >     >
>     >     >
>     >     >
>     >
>     >
> 
> 


More information about the opus mailing list