Speex crash

[GoogleCodeExporter]

Speex crash. From
https://forja.rediris.es/forum/forum.php?thread_id=5250&forum_id=1624:

I am getting crash when launching pipe with
speexenc!oggmux!oggdemux!speexdec...

I tried it on v0.10.6 winbuild of the gstreamer which seems to be the
latest available at the moment.

Original issue reported on code.google.com by david.g.hoyt on 8 Apr 2010 at 5:19

[GoogleCodeExporter]

I can reproduce it and the backtrace points the libspeex, in the encoder
initialisation. I'll try to provide a more helpful debug info tomorrow, since 
I'm
actually on  Linux

Original comment by ylatuya on 9 Apr 2010 at 12:31

[GoogleCodeExporter]

Any update on this?

Original comment by david.g.hoyt on 1 May 2010 at 7:50

[GoogleCodeExporter]

There is something wrong with pointers to functions.

It crashes in the 'speex_init_header()' function calling:
speex_mode_query(m, SPEEX_MODE_FRAME_SIZE, &header->frame_size);

This function is defined in libspeex/modes.c:
EXPORT int speex_mode_query(const SpeexMode *mode, int request, void *ptr)
{
   return mode->query(mode->mode, request, ptr);
}

And SpeexMode is defined in include/speex/speex.h like:
/** Query function for a mode */
typedef int (*mode_query_func)(const void *mode, int request, void *ptr);

/** Struct defining a Speex mode */ 
typedef struct SpeexMode {
   /** Pointer to the low-level mode data */
   const void *mode;

   /** Pointer to the mode query function */
   mode_query_func query;

I tried to replace the headers initialisation function with a custom one 
replacing
speex_mode_query() but then it crashes somewhere else. 

Original comment by ylatuya on 2 May 2010 at 3:38

[GoogleCodeExporter]

Function pointers in the SpeexMode structure are invalid when libspeex linked 
as dll.
Solution for me was to link it statically to the gstspeex.

Original comment by zyrianov...@gmail.com on 6 May 2010 at 10:09

[GoogleCodeExporter]

Very helpful! 
We'll use static linking in the meanwhile. 
Thanks!

Original comment by ylatuya on 6 May 2010 at 1:27

[GoogleCodeExporter]

I tried with static and at least it's able to initialize properly the encoder 
but 
still crashes encoding the first buffer:

Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstAudioSrcClock
0:00:00.843750000  3676   00B47E40 LOG                 speexenc 
gstspeexenc.c:662:gst_speex_enc_setup:<speexenc0> finding best mode
0:00:00.843750000  3676   00B47E40 LOG                 speexenc 
gstspeexenc.c:669:gst_speex_enc_setup:<speexenc0> selected UWB mode for 
samplerate 
32000
0:00:00.843750000  3676   00B47E40 LOG                 speexenc 
gstspeexenc.c:761:gst_speex_enc_setup:<speexenc0> we have frame size 640, 
lookahead 
349
0:00:00.843750000  3676   00B47E40 LOG                 speexenc 
gstspeexenc.c:780:gst_speex_enc_buffer_from_data:<speexenc0> encoded buffer of 
80 
bytes
0:00:00.843750000  3676   00B47E40 DEBUG               speexenc 
gstspeexenc.c:612:gst_speex_enc_create_metadata_buffer:<speexenc0> upstream 
tags = 
00B0CD20
0:00:00.843750000  3676   00B47E40 DEBUG               speexenc 
gstspeexenc.c:613:gst_speex_enc_create_metadata_buffer:<speexenc0> user-set 
tags = 
00000000
0:00:00.859375000  3676   00B47E40 DEBUG               speexenc 
gstspeexenc.c:622:gst_speex_enc_create_metadata_buffer:<speexenc0> merged   
tags = 
00B39F60
0:00:00.859375000  3676   00B47E40 DEBUG               speexenc 
gstspeexenc.c:995:gst_speex_enc_chain:<speexenc0> here are the caps: 00B0D3E0
0:00:00.859375000  3676   00B47E40 DEBUG               speexenc 
gstspeexenc.c:795:gst_speex_enc_push_buffer:<speexenc0> pushing output buffer 
of size 
80
0:00:00.859375000  3676   00B4B9F8 LOG                 speexenc 
gstspeexenc.c:507:gst_speex_enc_src_query:<speexenc0:src> Upstream latency: 
00B0D620
0:00:00.859375000  3676   00B4B9F8 LOG                 speexenc 
gstspeexenc.c:517:gst_speex_enc_src_query:<speexenc0:src> Adjusted latency: 
00B0D620
0:00:00.875000000  3676   00B47E40 DEBUG               speexenc 
gstspeexenc.c:795:gst_speex_enc_push_buffer:<speexenc0> pushing output buffer 
of size 
40
0:00:00.875000000  3676   00B47E40 DEBUG               speexenc 
gstspeexenc.c:1086:gst_speex_enc_chain:<speexenc0> received buffer of 25600 
bytes
0:00:00.875000000  3676   00B47E40 DEBUG               speexenc 
gstspeexenc.c:902:gst_speex_enc_encode:<speexenc0> encoding 640 samples (2560 
bytes)

Original comment by ylatuya on 7 May 2010 at 8:58

[GoogleCodeExporter]

which version of speex? I have speex-1.2beta3 compiled with vc2008. The test 
pipeline
is audiotestsrc!speexenc!fakesink and it runs fine.

Original comment by zyrianov...@gmail.com on 10 May 2010 at 7:43

[GoogleCodeExporter]

We're using speex 1.2rc1 compiled using gcc 4.4.3.

Original comment by david.g.hoyt on 10 May 2010 at 4:40

[GoogleCodeExporter]

Does audiotestsrc!speexenc!fakesink work with your speex lib?

Original comment by zyrianov...@gmail.com on 10 May 2010 at 7:47

[GoogleCodeExporter]

It doesn't, see comment #6 for the debug output for which I used the same 
pipeline 
(but forgot to mention it in the comment ;))
I think we could temporarily use an MSVC compiled version (as we did in the 
beginning 
with libnice) until we figure out what's going on with the gcc build. 

Original comment by ylatuya on 10 May 2010 at 7:59

[GoogleCodeExporter]

I have this fixed! Basic fix was to use speex_lib_get_mode() instead of 
directly accessing speex_nb_mode, speex_wb_mode, and friends. You'll need my 
new build, however, that is allllmost ready.

Original comment by david.g.hoyt on 22 Sep 2010 at 10:38

[GoogleCodeExporter]

Also had to compile speex with --disable-sse. Presumably there's an issue w/ 
stack alignment in the sse code (specifically filter_mem16_10()) b/t MSVC and 
GCC.

Original comment by david.g.hoyt on 22 Sep 2010 at 10:40

[GoogleCodeExporter]

This has been patched and committed (see r834). Patch was accepted upstream as 
well (see r837).

The plugin does need to be added to the installer again, however, once the fix 
has been confirmed.

Please verify the fix when possible.

Original comment by david.g.hoyt on 23 Sep 2010 at 10:01

• Changed state: Fixed