i.MX 6Quad - gstreamer crashes on playing ogg file.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX 6Quad - gstreamer crashes on playing ogg file.

2,167 Views
pavelbilenko
Contributor II

Hi,

 

I am working with multimedia platform based on iMX 6Quad.

 

For some unclear reason when I try to play ogg file (which contains some meta data - attached) using gstreamer (gst-launch), it crashes (SIGSEGV) immediately with following backtrace:

#0  0x2b3e21e0 in decodePacket () from ./usr/lib/imx-mm/audio-codec/lib_oggvorbis_dec_arm11_elinux.so.2

#1  0x2b3de7e4 in OggVorbisDecode () from ./usr/lib/imx-mm/audio-codec/lib_oggvorbis_dec_arm11_elinux.so.2

#2  0x2b3c7c40 in VORBISDecFrameDecode () from ./usr/lib/imx-mm/audio-codec/wrap/lib_vorbisd_wrap_arm12_elinux.so

#3  0x2ab6de6c in gst_beepdec_chain () from ./usr/lib/gstreamer-0.10/libmfw_gst_beep.so

#4  0x2abf2504 in ?? () from ./usr/lib/libgstreamer-0.10.so.0

#5  0x2abf2504 in ?? () from ./usr/lib/libgstreamer-0.10.so.0

 

If metadata is removed from that ogg file, gstreamer plays it without any problem.

 

I searched the Internet but couldn't find debug version of lib_oggvorbis_dec_arm11_elinux.so library or its sources.

I didn't find any problems or clues in Gstreamer log (attached GST_DEBUG=3,beepdec:9,mfw_vorbisdecoder:9).

 

Some additional info on my system:

kernel version - 3.0.35

gst-launch-0.10 version 0.10.35

GStreamer version 0.10.35

beep.imx plugin version - 3.0.7

vorbisdec.imx plugin version - 3.0.5

 

Any help on this issue will be really appreciated.

 

Best regards,

Pavel

Original Attachment has been moved to: ogg_crash_gst.log.zip

Tags (2)
6 Replies

1,745 Views
fabio_estevam
NXP Employee
NXP Employee

Could you try a more recent BSP version?

I have tried the lastest stable Yocto fido branch and did not see the crash.

Regards,

Fabio Estevam

0 Kudos

1,745 Views
pavelbilenko
Contributor II

Thank you for the prompt response.

The platform is already more than a year at car production and such major change is problematic at this stage of the project.

And will require a very long overall QA cycle of the system and may lead to many new bugs.

Is it possible to try some other minor, bug oriented changes?

Is there is someone, that have access to source code of lib_oggvorbis_dec_arm11_elinux.so.2, that can tell the root cause of this bug?

Using disassemble it seams that crash happens at the beginning of the function (maybe because of wrong/unexpected function argument).

Can I find somewhere different (maybe more recent)  version of lib_oggvorbis_dec_arm11_elinux.so.2, that will work with my current environment?

Best regards,

Pavel

0 Kudos

1,745 Views
fabio_estevam
NXP Employee
NXP Employee

Hi Pavel,

Maybe you can try the library from the latest BSP.

Regards,

Fabio Estevam

1,745 Views
gusarambula
NXP TechSupport
NXP TechSupport

Thank you, Fabio, for the help!

Pavel Bilenko, did this helped?

0 Kudos

1,745 Views
pavelbilenko
Contributor II

Hi Fabio,

I have tried 3.0.7 version of vorbis decoder library, but the result was the same (crash at the same place).

As far as I understand newer versions of this library are build for newer kernel version and use gstreamer v1.0, so they doesn't suit my environment.

I have found that the problem coming from the embedded artwork.

It seems that the problem is at vorbis decoder (lib_oggvorbis_dec_arm11_elinux.so.2) which fails to handle "large packet" resulted from large embedded artwork.

According to Vorbis documentation (https://wiki.xiph.org/VorbisComment):

"Failure to decode a picture block should not prevent playback of the file (failure to deal with the particularly large packet required by the comment header is a separate problem with the player implementation)."

"Embedding a picture into the file might break playback of existing players (especially hardware players, software players could be updated easily)."

If I replace artwork with smaller one (45x45) the problem doesn't happen.

Because I don't have access to the source code of the vorbis decoder I cannot verify my conclusion or fix it?

Are there some fixes related to the embedded artwork or packet size that was done since 3.0.5?

Is there is some way at some place to open bug on this issue?

Best regards,

Pavel

0 Kudos

1,745 Views
pavelbilenko
Contributor II

No this didn't help.

Unfortunately for some unclear reason, detailed answer was rejected by moderator.

I am still pending for its approval to be able to continue the thread.

P.S: I really hope that this message will not be also rejected by moderator.

Best regards,

Pavel

0 Kudos