Gstreamer not working second time

gonfer · ‎03-20-2014

Hi all,

I've been following this thread gstreamer: video fails to play when opened for second time but as I'm not sure if my problem is the same I'm opening a new one.

My problem is in a iMX28 custom board, and the code I'm running in my application is really trivial:

gst_init (NULL, NULL);

/* Build the pipeline */

pipeline = gst_parse_launch ("playbin2 uri=file:///mnt/gonzalo/Copreci-heart_x264_200x120_12000_15fps_320_22050.mp4", NULL);

/* Start playing */

gst_element_set_state (pipeline, GST_STATE_PLAYING);

/* Wait until error or EOS */

bus = gst_element_get_bus (pipeline);

msg = gst_bus_timed_pop_filtered (bus, GST_CLOCK_TIME_NONE, GST_MESSAGE_ERROR | GST_MESSAGE_EOS);

/* Free resources */

if (msg != NULL)

gst_message_unref(msg);

gst_object_unref(bus);

gst_element_set_state(pipeline, GST_STATE_NULL);

gst_object_unref(pipeline);

gst_deinit();

First time I run this code in my application everything goes fine, the video is played nicely. Here is the log:

Aiur: 3.0.6

Core: MPEG4PARSER_06.04.27 build on Dec 20 2012 16:48:05

mime: video/quicktime; audio/x-m4a; application/x-3gp

file: /usr/lib/imx-mm/parser/lib_mp4_parser_arm9_elinux.so.3.1

Content Info:

URI:

file:///mnt/gonzalo/Copreci-heart_x264_200x120_12000_15fps_320_22050.mp4

Idx File:

/root/.aiur/.mnt.gonzalo.Copreci-heart_x264_200x120_12000_15fps_320_22050.mp4.ai

dx

Seekable : Yes

Size(byte): 18666817

Movie Info:

Seekable : Yes

Live : No

Duration : 0:01:41.000000000

ReadMode : File

Track : 2

Track 00 [video_000000] Enabled

Duration: 0:01:41.000000000

Language: eng

Mime:

video/x-h264, parsed=(boolean)true, width=(int)200, height=(int)120, framerate=(

fraction)15/1, codec_data=(buffer)000000016742c00ddb0d11e59610000003001000000301

e0f142ae0000000168ca8cb2

H264D_ARM9_02.06.01 build on Jul 12 2011 14:01:56.

MFW_GST_H264_DECODER_PLUGIN 3.0.6 build on Feb 5 2014 15:30:55.

Track 01 [audio_000000] Enabled

Duration: 0:01:40.850000000

Language: eng

Mime:

audio/mpeg, mpegversion=(int)1, framed=(boolean)true, channels=(int)2, rate=(int

)22050, bitrate=(int)160013

MFW_GST_V4LSINK_PLUGIN 3.0.6 build on Feb 5 2014 15:30:44.

Beep: 3.0.6

Core: MP3 decoder Wrapper build on Jan 16 2013 16:21:07

mime: audio/mpeg, mpegversion = (int)1

file: /usr/lib/imx-mm/audio-codec/wrap/lib_mp3d_wrap_arm9_elinux.so

CODEC: BLN_MAD-MMCODECS_MP3D_ARM_02.13.00_ARM9 build on Dec 5 2012 09:44:32.

>>V4L_SINK: Actually buffer status:

hardware buffer : 21

software buffer : 0

full screen size:480x272

[V4L Update Display]: left=0, top=0, width=480, height=272

Running time 0:01:40.940589569 render fps 14.157

Total rendered:1429

[--->FINALIZE aiurdemux

Second time my application runs the same code I get the following error:

(<unknown>:4591): GStreamer-CRITICAL **: gst_element_set_state: assertion `GST_IS_ELEMENT (element)' failed

(<unknown>:4591): GStreamer-CRITICAL **: gst_element_get_bus: assertion `GST_IS_ELEMENT (element)' failed

(<unknown>:4591): GStreamer-CRITICAL **: gst_bus_timed_pop_filtered: assertion `GST_IS_BUS (bus)' failed

(<unknown>:4591): GStreamer-CRITICAL **: gst_object_unref: assertion `object != NULL' failed

(<unknown>:4591): GStreamer-CRITICAL **: gst_element_set_state: assertion `GST_IS_ELEMENT (element)' failed

(<unknown>:4591): GStreamer-CRITICAL **: gst_object_unref: assertion `object != NULL' failed

If I restart my application, the previous code runs fine but once again, only the first time. I've also tried running the same code from a CHILD process. Doing it this way, the code DOESN'T FAIL, so looks something is not de-initializing properly. But in my application I don't want to run it in a child process, and would like to know what's wrong in this code.

Can someone help me?

Thanks in advance,

Gonzalo.

PeterChan · ‎08-19-2014

Hi Gonzalo,

I have attached the libmfw_gst_v4lsink.so extracted from the MM codec package 3.0.11. Please use this library file to replace the one in your rootfs. After the change, the repeat mode can work for your H.264 test vectors.

Thanks,

Peter

在原帖中查看解决方案

gonfer · ‎04-03-2014

I've done an additional test, changing the video sink element from “mfw_v4lsink” to “fakesink”

- vdsink = gst_element_factory_make ("mfw_v4lsink", "video-sink");

+ vdsink = gst_element_factory_make ("fakesink", "video-sink");

Of course, I don't see any video at all but the code runs flawlessly playing the audio stream (now for more than one hour).

It looks the problem is inside mfw_v4lsink.

Regards,

Gonzalo.

LeonardoSandova · ‎04-03-2014

Hi Gonzalo,

Which builder are you using? Yocto or ltib? You may be hitting a bug, where the object holding the video device is not being dereference, then the object count is never zero so never destroyed. GObject is based on this reference count to keep track of live objects.

1. if you run twice this line, do you observe the same behavior?

gst-launch playbin2 location=file://<your media file>

2. if you eliminate your while(1) statement, and run twice the app, do you observe the same behavior?

gonfer · ‎04-03-2014

Hi Leonardo,

I'm using LTIB, BSP 2.6.35_1.1.0 and FSL codecs 3.06.

Yes, I know about the ref counting, and as I've read gstreamer is heavily threaded I even added a large sleep in my while(1), just to allow any thread to finish, but with no success.

1. Running twice (I've done it 5 times actually) gst-launch playbin2 uri=file:///mnt/gonzalo/Copreci-heart_x264_200x120_12000_15fps_320_22050.mp4 everything works fine (only once I've got a lot of dropped buffers). I keep my printks in mxs_pxp.c so I can see how the PXP is open and closed and the number of users. Every time the video finishes, the driver is closed. Here is the log for 2 consecutive runs:

root@freescale ~$

root@freescale ~$ gst-launch playbin2 uri=file:///mnt/gonzalo/Copreci-heart_x264_200x120_12000_15fps_320_22050.mp4

Setting pipeline to PAUSED ...

Aiur: 3.0.6

Core: MPEG4PARSER_06.04.27 build on Dec 20 2012 16:48:05

mime: video/quicktime; audio/x-m4a; application/x-3gp

file: /usr/lib/imx-mm/parser/lib_mp4_parser_arm9_elinux.so.3.1

Pipeline is PREROLLING ...

Content Info:

URI:

file:///mnt/gonzalo/Copreci-heart_x264_200x120_12000_15fps_320_22050.mp4

Idx File:

/root/.aiur/.mnt.gonzalo.Copreci-heart_x264_200x120_12000_15fps_320_22050.mp4.ai

dx

Seekable : Yes

Size(byte): 18666817

Movie Info:

Seekable : Yes

Live : No

Duration : 0:01:41.000000000

ReadMode : File

Track : 2

Track 00 [video_000000] Enabled

Duration: 0:01:41.000000000

Language: eng

Mime:

video/x-h264, parsed=(boolean)true, width=(int)200, height=(int)120, framerate=(

fraction)15/1, codec_data=(buffer)000000016742c00ddb0d11e59610000003001000000301

e0f142ae0000000168ca8cb2

H264D_ARM9_02.06.01 build on Jul 12 2011 14:01:56.

MFW_GST_H264_DECODER_PLUGIN 3.0.6 build on Feb 5 2014 15:30:55.

Track 01 [audio_000000] Enabled

Duration: 0:01:40.850000000

Language: eng

Mime:

audio/mpeg, mpegversion=(int)1, framed=(boolean)true, channels=(int)2, rate=(int

)22050, bitrate=(int)160013

[ 444.470000][pxp_open] pxp->users = 0

[ 444.480000][pxp_close] pxp->users = 1

MFW_GST_V4LSINK_PLUGIN 3.0.6 build on Feb 5 2014 15:30:44.

Beep: 3.0.6

Core: MP3 decoder Wrapper build on Jan 16 2013 16:21:07

mime: audio/mpeg, mpegversion = (int)1

file: /usr/lib/imx-mm/audio-codec/wrap/lib_mp3d_wrap_arm9_elinux.so

CODEC: BLN_MAD-MMCODECS_MP3D_ARM_02.13.00_ARM9 build on Dec 5 2012 09:

[ 445.720000] [pxp_open] pxp->users = 0

44:32.

>>V4L_SINK: Actually buffer status:

hardware buffer : 21

software buffer : 0

Pipeline is PREROLLED ...

Setting pipeline to PLAYING ...

full screen size:480x272

[V4L Update Display]: left=0, top=0, width=480, height=272

New clock: GstAudioSinkClock

Got EOS from element "playbin20".

Execution ended after 100569875001 ns.

Setting pipeline to PAUSED ...

Running time 0:01:40.939682539 render fps 14.207

Setting pipeline to READY ...

Total rendered:1434

Setting pipeline to NULL ...

[--->FINALIZE aiurdemux

Freeing pipeline ...

[ 547.090000] [pxp_close] pxp->users = 1

root@freescale ~$

root@freescale ~$ gst-launch playbin2 uri=file:///mnt/gonzalo/Copreci-heart_x264_200x120_12000_15fps_320_22050.mp4

Setting pipeline to PAUSED ...

Pipeline is PREROLLING ...

Aiur: 3.0.6

Core: MPEG4PARSER_06.04.27 build on Dec 20 2012 16:48:05

mime: video/quicktime; audio/x-m4a; application/x-3gp

file: /usr/lib/imx-mm/parser/lib_mp4_parser_arm9_elinux.so.3.1

Content Info:

URI:

file:///mnt/gonzalo/Copreci-heart_x264_200x120_12000_15fps_320_22050.mp4

Idx File:

/root/.aiur/.mnt.gonzalo.Copreci-heart_x264_200x120_12000_15fps_320_22050.mp4.ai

dx

Seekable : Yes

Size(byte): 18666817

Movie Info:

Seekable : Yes

Live : No

Duration : 0:01:41.000000000

ReadMode : File

Track : 2

Track 00 [video_000000] Enabled

Duration: 0:01:41.000000000

Language: eng

Mime:

video/x-h264, parsed=(boolean)true, width=(int)200, height=(int)120, framerate=(

fraction)15/1, codec_data=(buffer)000000016742c00ddb0d11e59610000003001000000301

e0f142ae0000000168ca8cb2

H264D_ARM9_02.06.01 build on Jul 12 2011 14:01:56.

MFW_GST_H264_DECODER_PLUGIN 3.0.6 build on Feb 5 2014 15:30:55.

Track 01 [audio_000000] Enabled

Duration: 0:01:40.850000000

Language: eng

Mime:

audio/mpeg, mpegversion=(int)1, framed=(boolean)true, channels=(int)2, rate=(int

)22050, bitrate=(int)160013

[ 562.510000][pxp_open] pxp->users = 0

[ 562.520000][pxp_close] pxp->users = 1

MFW_GST_V4LSINK_PLUGIN 3.0.6 build on Feb 5 2014 15:30:44.

Beep: 3.0.6

Core: MP3 decoder Wrapper build on Jan 16 2013 16:21:07

mime: audio/mpeg, mpegversion = (int)1

file: /usr/lib/imx-mm/audio-codec/wrap/lib_mp3d_wrap_arm9_elinux.so

CODEC: BLN_MAD-MMCODECS_MP3D_ARM_02.13.00_ARM9 build on Dec 5 2012 09:44:32.

[ 563.370000][pxp_open] pxp->users = 0

>>V4L_SINK: Actually buffer status:

hardware buffer : 21

software buffer : 0

Pipeline is PREROLLED ...

Setting pipeline to PLAYING ...

full screen size:480x272

[V4L Update Display]: left=0, top=0, width=480, height=272

New clock: GstAudioSinkClock

WARNING: from element /GstPlayBin2:playbin20/GstPlaySink:playsink0/GstBin:vbin/GstAutoVideoSink:videosink/MFW_GST_V4LSINK_INFO_T:videosink-actual-sink-mfw_v4l: A lot of buffers.

Additional debug info:

gstbasesink.c(2866): gst_base_sink_is_too_late (): /GstPlayBin2:playbin20/GstPlaySink:playsink0/GstBin:vbin/GstAutoVideoSink:videosink/MFW_GST_V4LSINK_INFO_T:videosink-actual-s:

There may be a timestamping problem, or this computer is too slow.

Got EOS from element "playbin20".

Execution ended after 100570866301 ns.

Setting pipeline to PAUSED ...

Running time 0:01:40.974835432 render fps 14.496

Setting pipeline to READY ...

Total rendered:1429

Setting pipeline to NULL ...

[--->FINALIZE aiurdemux

Freeing pipeline ...

[ 675.810000][pxp_close] pxp->users = 1

root@freescale ~$

2. If I eliminate the while(1) statement, I can run my app for unlimited times and the video plays fine. The log is similar to the previous one and I can see the PXP driver being closed at the end of the video.

If inside the while(1) statement I fork and run the video_play function in the child process, the behaviour is also good - video is played again and again, and the driver is properly closed at the end of each play.

Regards,

Gonzalo.

gonfer · ‎04-28-2014

Please, could someone help me on this issue?

Thanks,

Gonzalo

LeonardoSandova · ‎04-28-2014

Gonzalo, Not sure what is going on. Can you take a look at the gplay source code? It is also a player based on gstreamer.

gonfer · ‎04-28-2014

Hi Leonardo,

I've already taken a look at gplay, and it also fails !!!

To reproduce the problem:

1- Run gplay

2- While gplay is running, in the console press 'r'

3- and then press '2'

This should repeat the current movie, but the second time it fails. The problem is the same I'm facing - the PXP driver is not closed after first play, so fails when trying to open it the second time.

Although I'm short of time and Yocto is too hard for me, I've already tried it but when I try to run gstreamer I get "Invalid Instruction".

Thanks,

Gonzalo.

PeterChan · ‎05-15-2014

Gonzalo,

The gplay repeat mode 2 fails because this is a software bug in the gplay application. You can make the below change to resolve this problem.

=================================================================

diff --git a/mfw_gplay.c b/mfw_gplay.c

index 04d2e74..1dc8a1f 100755

--- a/mfw_gplay.c

+++ b/mfw_gplay.c

@@ -153,6 +153,7 @@ PlayItem * playlist_next(fsl_player_handle handle, options* opt)

{

pplayer->klass->stop(pplayer);

//pplayer->klass->set_media_location(pplayer, opt->current->name, &drm_format);

+ next = current;

pplayer->klass->play(pplayer);

break;

}

=================================================================

I have also tried the LTIB, BSP 2.6.35_1.1.0 pre-built image but I can't reproduce the original problem you mentioned at the top of this thread. Video can repeatedly play. Have you applied any other patches to 2.6.35_1.1.0?

When the video stream end, the v4l_sink finalize function (mfw_gst_v4lsink_finalize) will be called and the PXP will be released after the call. Did you see this function being called? Below is my log when video stream ends.

fsl_player_play()

[Playing (Current Repeated)][Vol=01][00:01:30/00:01:33][fps:12]FOUND GST_MESSAGE_TAG!

minimum bitrate: 7962

EOS Found!

FSL_PLAYER_UI_MSG_EOS

Running time 0:04:36.236190476 render fps 4.105

Total rendered:1134

fsl_player_stop()

[--->FINALIZE v4l_sink

[--->FINALIZE aiurdemux

Thanks,

Peter

YixingKong · ‎06-24-2014

Peter

Could you please follow the issue and try to close it as soon as possible.

Thanks,

Yixing

WilliamTse

YixingKong · ‎06-16-2014

PeterChan, could you keep following the customer's issue please?

Thanks,

Yixing

gonfer · ‎05-16-2014

Peter, thanks for looking at this !!

Yes, my FAE told me about that finding. He also sent me another patch to trace this issue:

---------------------------------------------------------------------------------------------------------------------------------------

diff --git a/drivers/media/video/mxs_pxp.c b/drivers/media/video/mxs_pxp.c

index 93549ff..394ae7c 100644

--- a/drivers/media/video/mxs_pxp.c

+++ b/drivers/media/video/mxs_pxp.c

@@ -1011,6 +1011,7 @@ void pxp_release(struct video_device *vfd)

struct pxps *pxp = video_get_drvdata(vfd);

spin_lock(&pxp->lock);

+dump_stack();

video_device_release(vfd);

spin_unlock(&pxp->lock);

}

@@ -1077,7 +1078,8 @@ static int pxp_open(struct file *file)

mutex_lock(&pxp->mutex);

pxp->users++;

-

+printk(KERN_INFO "%s=%p, users=%d\n", __FUNCTION__, pxp_open, pxp->users);

+dump_stack();

if (pxp->users > 1) {

pxp->users--;

ret = -EBUSY;

@@ -1117,6 +1119,8 @@ static int pxp_close(struct file *file)

mutex_lock(&pxp->mutex);

pxp->users--;

+printk(KERN_INFO "%s=%p,users=%d\n", __FUNCTION__, pxp_close, pxp->users);

+dump_stack();

mutex_unlock(&pxp->mutex);

return 0;

diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c

index 0ca7ec9..8609ea7 100644

--- a/drivers/media/video/v4l2-dev.c

+++ b/drivers/media/video/v4l2-dev.c

@@ -283,6 +283,8 @@ static int v4l2_open(struct inode *inode, struct file *filp)

/* and increase the device refcount */

video_get(vdev);

mutex_unlock(&videodev_lock);

+

+printk(KERN_INFO "%s:vdev->fops->open=%p\n", __FUNCTION__, vdev->fops->open);

if (vdev->fops->open)

ret = vdev->fops->open(filp);

@@ -298,6 +300,7 @@ static int v4l2_release(struct inode *inode, struct file *filp)

struct video_device *vdev = video_devdata(filp);

int ret = 0;

+printk(KERN_INFO "%s:vdev->fops->release=%p\n", __FUNCTION__, vdev->fops->release);

if (vdev->fops->release)

vdev->fops->release(filp);

---------------------------------------------------------------------------------------------------------------------------------------

Using the previous patch, and modifying mfw_gplay.c acording to your post, this was my yesterday answer to my FAE:

Hi Luis,

I've patched gplay but, unfortunatelly, the problem persists.

With gplay patched the behaviour is a bit different:

- Now, gplay can play the file non stop

- I can see video only the first time; in the next replays I can only "hear" the music, no video at all.

The problem regarding pxp->users is still there:

---------------------------------------------------------------------------------------------------------------------------------

[ 658.560000] v4l2_open:vdev->fops->open=c02cbac0
[ 658.580000] pxp_open=c02cbac0, users=2
[ 658.580000] Backtrace:
[ 658.580000] [<c004accc>] (dump_backtrace+0x0/0x110) from [<c03cbfdc>] (dump_stack+0x18/0x1c)
Beep: 3.0.6
Core: MP3 decoder Wrap[ 658.600000] r6:c3cfa824per build on Jan 16 201 r5:c3ce7e083 16:21:07
   mime: audi r4:c3cfa800o/mpeg, mpegversion = (int)1
   file: /usr/lib/imx-mm/audio-codec/wrap/lib_mp3d_wrap_arm9_elinux.so
CODEC: BLN_MAD-M r3:00000000MCODECS_MP3D_ARM_02.13.0
0_ARM9 build on Dec 5 [ 658.620000] [<c03cbfc4>] (dump_stack+0x0/0x1c) from [<c02cbb0c>] (pxp_open+0x4c/0xe4)
2012 09:44:32.
FOUND GST_MESSAGE_TAG!
minimum bitrate: 127706
maximum bitrate: 127706
FOUND GST_MESSAGE_TAG!
maximum bitrate: 191712
[ 658.650000] [<c02cbac0>] (pxp_open+0x0/0xe4) from [<c02c3298>] (v4l2_open+0x84/0xa8)
FOUND GST_MESSAGE_TAG!
minimum bitrate: 95856
[ 658.670000] r6:c3ca1a80 r5:c3ce7e08 r4:c02cbac0
[ 658.670000] [<c02c3214>] (v4l2_open+0x0/0xa8) from [<c00d3e58>] (chrdev_open+0x17c/0x1a4)
[ 658.690000] r6:c3ce8f80 r5:c3ca1a80 r4:c3f401e8 r3:c02c3214
[ 658.690000] [<c00d3cdc>] (chrdev_open+0x0/0x1a4) from [<c00ce980>] (__dentry_open+0x134/0x23c)
[ 658.710000] r8:c00d3cdc r7:c3f401e8 r6:c3ca1a80 r5:c3897a80 r4:c3eed080
[ 658.710000] [<c00ce84c>] (__dentry_open+0x0/0x23c) from [<c00cfab8>] (nameidata_to_filp+0x4c/0x64)
FOUND GST_MESSAGE_TAG!
number of channels: 2
         bitrate: 32000
sampling frequency (Hz): 44100
     audio codec: MPEG-1 Layer 3
[ 658.740000] [<c00cfa6c>] (nameidata_to_filp+0x0/0x64) from [<c00dc49c>] (do_last.isra.50+0x4ac/0x604)
[ 658.780000] r4:c3f79ed0
[ 658.780000] [<c00dbff0>] (do_last.isra.50+0x0/0x604) from [<c00dc764>] (do_filp_open+0x170/0x4e4)
[ 658.810000] [<c00dc5f4>] (do_filp_open+0x0/0x4e4) from [<c00cfb34>] (do_sys_open+0x64/0xec)
[ 658.810000] [<c00cfad0>] (do_sys_open+0x0/0xec) from [<c00cfbe4>] (sys_open+0x28/0x2c)
[ 658.840000] [<c00cfbbc>] (sys_open+0x0/0x2c) from [<c00478c0>] (ret_fast_syscall+0x0/0x2c)
VIDIOC_S_FMT output overlay: Bad file descriptor
---------------------------------------------------------------------------------------------------------------------------------

Attached you can find the complete log of this run (gplay_log2.txt).

Please, remember that my problem is not gplay (see my post in the iMX community).

gplay is just the simplest way to reproduce my problem.

Peter, I'm also attaching the complete log here (gplay_log2.txt) so you can see it. In my log there is no [--->FINALIZE v4l_sink

My main concern is that I'm able to reproduce this issue quite easily on an iMX28evk.

1- I've burned a SD with L2.6.35_1.1.0_130130_images_MX28 from Freescale's website.

2- then, I edited /etc/rc.d/rc.conf

-   all_services="mount-proc-sys mdev udev hostname devfsd depmod modules filesystems syslog network inetd portmap dropbear sshd boa smb dhcpd settime fslgnome watchdog bluetooth gtk2 pango"
+ all_services="mount-proc-sys mdev udev hostname devfsd depmod modules filesystems syslog network inetd watchdog"
-   all_services_r="pango gtk2 bluetooth watchdog fslgnome settime dhcpd smb boa sshd dropbear portmap inetd network syslog filesystems modules depmod devfsd hostname udev mdev mount-proc-sys"
+ all_services_r="watchdog inetd network syslog filesystems modules depmod devfsd hostname udev mdev mount-proc-sys"

-   cfg_services="mount-proc-sys udev hostname depmod modules filesystems   inetd dropbear      fslgnome   gtk2 pango"
+ cfg_services="mount-proc-sys udev hostname depmod modules filesystems   inetd"

-   cfg_services_r="pango gtk2   fslgnome      dropbear inetd   filesystems modules depmod hostname udev mount-proc-sys"
+ cfg_services_r="inetd   filesystems modules depmod hostname udev mount-proc-sys"
3- and finally I added Kaleidoscope_h264_qvga_387kbps_30fps_mp3_48kHz_128kbps_131sec.mp4 to /home/user/videos

and the log of playing the file for the second time with [gplay r 2] shows again the problem:

FOUND GST_MESSAGE_TAG!
           codec: H.264/AVC
   language code: und
FOUND GST_MESSAGE_TAG!
container format: MOV/MP4/3GP
         encoder: mp4creator 1.4.4
FOUND GST_MESSAGE_TAG!
           codec: MP3
   language code: und
         bitrate: 122074
MFW_GST_V4LSINK_PLUGIN 3.0.6 build on Jan 31 2013 11:00:33.
VIDIOC_S_FMT output overlay: Bad file descriptor
>>V4L_SINK: Actually buffer status:
         hardware buffer : 12
         software buffer : 0
FOUND GST_MESSAGE_TAG!
     audio codec: MPEG 1 Audio, Layer 3 (MP3)
nominal bitrate: 32000
Beep: 3.0.6

I'm also attaching the complete log of this run (minicom_gstreamer.txt).

At this moment I'm stuck, as I'm not able to find a working point to begin working with it.

Regards,

Gonzalo.

EDIT:

OK, now I understand that in L2.6.35_1.1.0_130130_images_MX28 gplay is buggy, so I really don't know if the problem in the test with the "fresh image" is gplay or something else.

I'm going to burn a new SD with L2.6.35_1.1.0_130130_images_MX28 but this time instead of using gplay I will use my own code based on a loop around gst_launch. I'll come back with the log of this test. If some kind of debug level in gstreamer could help to undertand this issue, please, let me know.

YixingKong · ‎06-16-2014

Gonzalo

Had your issue got resolved? If yes, we are going to close the discussion in 3 days. If you still need help, please feel free to reply with an update to this discussion.

Thanks,

Yixing

gonfer · ‎06-16-2014

Hi Yixing,

no, the issue is still open for me. I'm able to reproduce this problem on the iMX28evk and on my custom hardware. I don't know the root cause but the PXP driver is not closed properly.

Regards,

Gonzalo.

PeterChan · ‎06-25-2014

Hi Gonzalo,

I downloaded the L2.6.35_1.1.0_130130_images_MX28.tar.gz and did exactly the change at /etc/rc.d/rc.conf you mentioned. An additional change is to replace the /usr/bin/gplay by the attached one to fix the repeat mode "2" issue. However, I cannot reproduce this problem.

What's more is the Kaleidoscope_h264_qvga_387kbps_30fps_mp3_48kHz_128kbps_131sec-GONZALO.mp4 does not play at all on i.MX28 EVK and I use my own MP4 test vector to test. I just use "gplay Kaleidoscope_h264_qvga_387kbps_30fps_mp3_48kHz_128kbps_131sec-GONZALO.mp4" to play this video. It is interesting to find out why the video can be played on your side.

Are you using our i.MX28 Seiko 4.3" WVGA daughter card as well?

Thanks,

Peter

gonfer · ‎07-03-2014

Hi Peter,

and sorry for the delay in my answer - I've been on holidays and have returned yesterday.

Regarding this issue, I've burned again a new SD with L2.6.35_1.1.0_130130_images_MX28. Then I've edited /etc/rc.d/rc.conf, deleted /usr/bin/gplay and saved gplay (from your previous post) and Kaleidoscope_h264_qvga_387kbps_30fps_mp3_48kHz_128kbps_131sec.mp4 to /home/user/video.

Then, I've rebooted the board, moved to /home/user/video and run ./gplay Kaleidoscope_h264_qvga_387kbps_30fps_mp3_48kHz_128kbps_131sec.mp4 and pressed 'r' and '2' to repeat the movie.

The error VIDIOC_S_FMT output overlay: Bad file descriptor is still there, in every repetition.

The complete log is attached.

About Kaleidoscope_h264_qvga_387kbps_30fps_mp3_48kHz_128kbps_131sec.mp4, I got this file from my FAE. It doesn't play very smoothly (some times I get a lot of dropped frames), but it runs in my i.MX28 EVK. I'm also attachinf it.

And yes, I'm using the Seiko 4.3" WVGA daughter card.

Thanks for your support,

Gonzalo.

YixingKong · ‎06-16-2014

Gonzalo

Let see if I can find an AE to help you.

Thanks,

Yixing

gonfer · ‎04-03-2014

Another test:

in the video side instead of -> queue -> mfw_v4lsink, this time using -> ffmpegcolorspace -> fbdevsink

- vdqueue = gst_element_factory_make ("queue", "video-queue");

- vdsink = gst_element_factory_make ("mfw_v4lsink", "video-sink");

+ vdqueue = gst_element_factory_make ("ffmpegcolorspace", "video-queue");

+ vdsink = gst_element_factory_make ("fbdevsink", "video-sink");

Now video and sound run OK for unlimited times (but the CPU load is almost 100%).

Regards,

Gonzalo.

LeonardoSandova · ‎04-03-2014

correct, the problem is that the fd is not being close on the first run.