i.MX ProcessorsのトピックRe: GStreamer crashing on i.MX6 (Boundary Devices Nitrogen6x)

GStreamer crashing on i.MX6 (Boundary Devices Nitrogen6x)

jimheath — Wed, 20 Feb 2013 23:54:24 GMT

Hi Everyone,

I've been developing an application for the new Boundary Devices Nitrogen6x board running an i.MX6Q processor. I'm using the Timesys BSP, kernel version: 3.0.35-ts-armv7l-2026-geaaf30e (LinuxLink Development Center for Boundary Devices Nitrogen6X | Timesys Embedded Linux). The application relies on GStreamer 0.10.36 and gst-fsl-plugin for playing MPEG-2 transport stream files that are H.264 encoded.

I ran into a problem playing back files that are around 2GB or larger. If I use playbin2 for the GStreamer pipeline and specify a large video file, the pipeline transitions to the preroll state and appears to identify the elements needed to play the video, but then it just sits there. I don't see any video output, not even the first frame of the video and within 30 seconds the program crashes stating it ran out of memory. This happens regardless of whether I use my program or use the gst-launch command.

On the other hand, if I construct the following pipeline, the video plays fine:

gst-launch filesrc location=video.ts ! tsdemux name=demux demux. ! queue max-size-buffers=0 max-size-time=0 ! vpudec ! mfw_v4lsink demux. ! queue max-size-buffers=0 max-size-time=0 ! mfw_mp3decoder ! audioconvert ! 'audio/x-raw-int,channels=2' ! alsasink

The problem is, I would rather use playbin2 because it offers more flexibility. I have encountered certain video files that will not play back using the pipeline above, but will with playbin2. I have compared a video that does playback and one that does not using gst-discoverer and see no difference; both are transport streams and both are H.264 encoded.

Can anyone offer any suggestions on how to get playbin2 to play these large video files?

Thanks,

Jim

Re: GStreamer crashing on i.MX6 (Boundary Devices Nitrogen6x)

LeonardoSandova — Thu, 28 Feb 2013 19:56:58 GMT

Hi jimheath

I understand your situation. Your problem has been posted in an internal Freescale group, meaning that it will end up in a specialist which can provide the proper solution. In the other hand, I will try to reproduce the issue you are facing but this can take me some time to have the setup ready.

Leo

Re: GStreamer crashing on i.MX6 (Boundary Devices Nitrogen6x)

jimheath — Fri, 01 Mar 2013 02:52:11 GMT

Hi Leo,

Thanks for your response, it's good to hear a specialist will be helping me out.

I think I can offer some more information on this problem. I've been trying everything I can think of to determine the root cause of the problem. From some tests I've been running yesterday and today, I believe the segmentation faults are linked to me performing a seek operation on the transport stream video when using the aiurdemux element. I'm using the GStreamer C function: gst_element_seek_simple. This is an intermittent problem so it sometimes happens upon playing the first video or 1 to 10+ minutes of looping through the various videos. If I disable my application from performing a seek and always start the video from the beginning, I'm not seeing it crash.

If I use the tsdemux element from the gst-bad-plugins, I can perform seeks on the same set of videos without any segmentation faults. I've run this test for over an hour without any problems. I'm using a little test application written using Qt 4.8.3 that just continuously cycles through a playlist of transport stream videos. It selects a random position in the video to begin playing and plays it for 20 seconds then moves on to the next video.

I would use the tsdemux element because it handles the large videos (+2GB files) but for some videos I get a generic "stream error" message and it won't play it. But these videos that won't play with tsdemux WILL play with aiurdemux as long as they are under 2GB. All videos have the same encoding (h.264) so I'm not sure why tsdemux can't deal with them.

With both transport stream demuxers, I still see kernel error messages every once in awhile which I attached in case these were lost from my original posts. These don't stop the execution of the program, in fact, once the program moves on to the next video, video playback continues and everything appears normal.

Here's a backtrace on the core dump when using aiurdemux:

#0 0x2bbd17f4 in memcpy () from /home/jim/timesys/nitrogen6x/toolchain/lib/libc.so.6

#1 0x2c26d340 in MPEG2FindH264Frames ()