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