I'm using the Nitrogen6X board but I believe this is a common problem. MFW_isink plugin is not working. When I use it for the first time the is no video played. Second run I get this error bellow. Please not the same file is played with mfw_v4lsink without errros. root@nitrogen6x:~# gst-launch filesrc location=test-mpeg2.mpg typefind=true ! aiurdemux ! vpudec ! mfw_isink set color key MFW_GST_ISINK_PLUGIN 3.0.1 build on Jan 22 2013 19:04:04. Setting pipeline to PAUSED ... [INFO] Product Info: i.MX6Q/D/S vpudec versions :) plugin: 3.0.1 wrapper: 1.0.24(VPUWRAPPER_ARM_LINUX Build on Jan 22 2013 17:24:35) vpulib: 5.4.6 firmware: 2.1.5.32515 Pipeline is PREROLLING ... Aiur: 3.0.1 Core: BLN_MAD-MMLAYER_MPG2PARSER_ARM11_04.03.09 build on Aug 24 2012 10:57:23 mime: video/mpeg, mpegversion=(int)[1,2]; video/mpegts, systemstream=true; video/x-cdxa file: /usr/lib/imx-mm/parser/lib_mpg2_parser_arm11_elinux.so Content Info: URI: file:///home/root/test-mpeg2.mpg Idx File: /home/root/.aiur/.home.root.test-mpeg2.mpg.aidx Seekable : Yes Size(byte): 706564 Mpeg2CreateParser:parser created successfully Movie Info: Seekable : Yes Live : No Duration : 0:00:20.966666000 ReadMode : File programs : 1 Track : 2 Track 00 [video_0000] Enabled Duration: 0:00:20.966666000 Language: Mime: video/mpeg, systemstream=(boolean)false, parsed=(boolean)true, mpegversion=(int) 2, width=(int)160, height=(int)120, framerate=(fraction)30/1, codec_data=(buffer )000001b30a007815ffffe0411011111212121313131314141414141515151515151616161616161 6171717171717171718181819181818191a1a1a1a191b1b1b1b1b1c1c1c1c1e1e1e1f1f21000001b 20087711a81000d810017656e636f64656420627920544d5047456e63206231326a000001b800080 040 Track 01 [audio_0000] Enabled Duration: 0:00:20.736000000 Language: Mime: audio/mpeg, mpegversion=(int)1, parsed=(boolean)true, framed=(boolean)true, chan nels=(int)2, rate=(int)32000, bitrate=(int)64 [INFO] bitstreamMode 1, chromaInterleave 1, mapType 0, tiled2LinearEnable 0 hwbuf allocator zone(32768) created can not create threadmfw_gst_isink_setcaps:1489 Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock VS0 created. in fmt[NV12] win(0,0-160,120:160x120) out win(0,0-1280,1024:1280x1024) set deinterlace mode 0 Can not open dll, libgstfsl-0.10.so: cannot open shared object file: No such file or directory. Caught SIGSEGV accessing address (nil) #0 0x4e7179a4 in ?? () #1 0x4e717994 in ?? () #2 0x4e717994 in ?? () Spinning. Please run 'gdb gst-launch 1665' to continue debugging, Ctrl-C to quit, or Ctrl-\ to dump core. Regards, Tarek
Tarek, I tried to playback a /unit_tests/akiyo.mp4 with gplay commmand and things worked as expected, no errors, just that the frames were not playbacked at its original fps, it played much faster. Can you please the file you used? Leo
Created attachment 1037 [details] File used for testing Hi, I have attached the file I used. Is gplay using mfw_isink for sure?
Created attachment 1054 [details] Pipeline constructe with playbin2
Hi Tarek, either gplay and gst-launch playbin2 uses mfw_v4lsink as video sink; videos plays file in both cases. In case you want to see the constructed pipeline, please see the attachment. I am not sure why mfw_isink raises that signal the second time is run, so the bug is still there; in the other hand, the correct pipeline to playback a video (the long version of course, the short and better would be either with gplay or gst-launch playbin2) gst-launch filesrc location=test-mpeg2.mpg typefind=true ! aiurdemux ! vpudec ! mfw_v4lsink I am not sure if we can close this bug or spend more time finding the isink issue. Let me know your comments.
Mfw_isink need to be fixed as it's an important component for i.MX6. One of the main advantages of using i.MX6 is the IPU scaling capabilities. If isink is not working then it's a major problem! Thanks
(In reply to comment #5) > Mfw_isink need to be fixed as it's an important component for i.MX6. > > One of the main advantages of using i.MX6 is the IPU scaling capabilities. > If isink is not working then it's a major problem! I personally agree with you but please give a try in current master branch as we have updated gstreamer plugin and this might have been fixed there.
> I personally agree with you but please give a try in current master branch as > we have updated gstreamer plugin and this might have been fixed there. Sure I will give it a try. Can you please recommend an image to use?
(In reply to comment #7) > > I personally agree with you but please give a try in current master branch as > we have updated gstreamer plugin and this might have been fixed there. > > Sure I will give it a try. Can you please recommend an image to use? I'd use fsl-image-gui.
Tarek, Did you give it a try?
I pulled the latest build from master but all my application old bb files can't be processed by bitbake. I'm using LTIB at the moment until I fix the OE problems. I will start a new OE build overnight but it's giving me a very hard time! If you have a recent build can you not just run a simple gstreamer command line? gst-launch filesrc location=file.mpg typefind=true ! aiurdemux ! vpudec ! mfw_isink If it works for you more than once then it's fixed. Thanks, Tarek
(In reply to comment #10) > I pulled the latest build from master but all my application old bb files > can't be processed by bitbake. > > I'm using LTIB at the moment until I fix the OE problems. I will start a new > OE build overnight but it's giving me a very hard time! > > If you have a recent build can you not just run a simple gstreamer command > line? > > gst-launch filesrc location=file.mpg typefind=true ! aiurdemux ! vpudec ! > mfw_isink > > If it works for you more than once then it's fixed. > > Thanks, > Tarek Today I will give it a try on a SABRE LITE board. I will let you know my findings. Leo
on this platform, neither mfw_v4lsink not mfw_isink are working! I tried with gplay, gst-launch playbin2 and running the full pipeline (gst-launch filesrc location=/unit_tests/akiyo.mp4 typefind=true ! aiurdemux ! vpudec ! mfw_isink) and not of them worked on SABRE LITE. I am observing lots of (gst-launch-0.10:1971): GStreamer-CRITICAL **: gst_mini_object_unref: assertion `GST_IS_MINI_OBJECT (mini_object)' failed messages. So, playback is not working on this platform.
Hi all, I just ran some tests on the master branch (fsl_image_gui) and found that gplay worked on Tarek's test video and akiyo.mp4, but /unit_tests/akiyo.mp4 was missing from the image. The mfw_isink element was also missing. Was that intentional? As a quick test, I copied libmfw_isink.so from an LTIB 01.01 filesystem I had handy and it was able to play test-mpeg2.mpg once full screen, but died when I tried to get it to display in a window. It also showed the error message 'Can not open dll, libgstfsl-0.10.so'. In a subsequent boot, I was able to repeat that success in my first attempt, but a second attempt failed with no arguments to mfw_isink. I was able to repeat this multiple times, and found that clearing I'll do a fresh build off of danny to see how that changes things.
Hi all, I just ran some tests on the master branch (fsl_image_gui) and found that gplay worked on Tarek's test video and akiyo.mp4, but /unit_tests/akiyo.mp4 was missing from the image. The mfw_isink element was also missing. Was that intentional? As a quick test, I copied libmfw_isink.so from an LTIB 01.01 filesystem I had handy and it was able to play test-mpeg2.mpg once full screen, but died when I tried to get it to display in a window. It also showed the error message 'Can not open dll, libgstfsl-0.10.so'. In a subsequent boot, I was able to repeat that success in my first attempt, but a second attempt failed with no arguments to mfw_isink. I was able to repeat this multiple times, and found that clearing out /dev/shm/ allowed me to run again. i.e. ~/$ rm -f /dev/shm/* ~/$ gst-launch ... Note that for me, mfw_isink appears to be selecting the YUV output channel (/dev/fb1), causing alpha blending of the video with the background X desktop. I'll do a fresh build off of danny to see how that changes things.
(In reply to comment #13) Thanks a lot by looking at the issue. > I just ran some tests on the master branch (fsl_image_gui) and found that > gplay worked on Tarek's test video and akiyo.mp4, but /unit_tests/akiyo.mp4 > was missing from the image. No; it is a bug. I reported it at https://bugzilla.yoctoproject.org/show_bug.cgi?id=4185 > The mfw_isink element was also missing. > > Was that intentional? No, another bug but I think we can track this here and fix it together. > As a quick test, I copied libmfw_isink.so from an LTIB 01.01 filesystem I > had handy and it was able to play test-mpeg2.mpg once full screen, but died > when > I tried to get it to display in a window. > > It also showed the error message 'Can not open dll, libgstfsl-0.10.so'. > > In a subsequent boot, I was able to repeat that success in my first attempt, > but a second attempt failed with no arguments to mfw_isink. > > I was able to repeat this multiple times, and found that clearing Does it works in LTIB image? > I'll do a fresh build off of danny to see how that changes things. Regards,
(In reply to comment #15) > > Does it works in LTIB image? > I tried simply replying to the e-mail but apparently that didn't work... Great question and "I don't know"... I did verify that things work on a Timesys-generated image (no X-Windows, plugin version 3.0.5) but need to shuffle SD cards a bit before getting the other result.
(In reply to comment #16) > (In reply to comment #15) > > > > Does it works in LTIB image? > > > > I tried simply replying to the e-mail but apparently that didn't work... > > Great question and "I don't know"... > Nope. I just tested with LTIB and don't seem to get any output. I can't spend any more time on this today, but will dig further when time permits. I think the answer may lie in the isink sources. I'd be suspicious of any conditional compilation surrounding X. I've seen such things in the v4lsink code, but this was some years ago on i.MX5.
Hi All, I'm debugging this problem using (fsl_image_gui). I understand that on LTIB gstreamer isink is using /dev/fb1 (BG) for the video and any GUI program should use /dev/fb0 (FG) to be laid on top of the video so you can draw icons and mouse cursor. On OE it seams that both the GUI and Gstreamer are using /dev/fb0 which I think is causing the problem. I tried to modify the gst_isink code (mfw_gst_isink.c) to use /dev/fb1 but it worked only once. The video is played for the first time and then I need to reboot. Is it possible to do the opposite? I would like to force the GUI to use /dev/fb1 and see if this fixes the problem. Is there any information on how to do that? T
(In reply to comment #18) > Hi All, > > I'm debugging this problem using (fsl_image_gui). > > I understand that on LTIB gstreamer isink is using /dev/fb1 (BG) for the > video and any GUI program should use /dev/fb0 (FG) to be laid on top of the > video so you can draw icons and mouse cursor. > > > On OE it seams that both the GUI and Gstreamer are using /dev/fb0 which I > think is causing the problem. > > I tried to modify the gst_isink code (mfw_gst_isink.c) to use /dev/fb1 but > it worked only once. The video is played for the first time and then I need > to reboot. > > Is it possible to do the opposite? I would like to force the GUI to use > /dev/fb1 and see if this fixes the problem. > > Is there any information on how to do that? > > > T Hi Tarek, thanks for the investigation of this issue. Let me investigate what you ask and let you know ASAP. Leo
Created attachment 1194 [details] Temporary fix for isink problem Hi All, The isink is forcing Global Alpha in: mfw_gst_isink.c #if 1 struct mxcfb_gbl_alpha g_alpha; g_alpha.alpha = 255; g_alpha.enable = 1; if (ioctl (fb, MXCFB_SET_GBL_ALPHA, &g_alpha) < 0) { g_print ("set color key failed.\n"); ret = FALSE; } #endif It looks like a hack to me! I have attached a patch that disables this code and increase the number of displays. There is no point in limiting the number of displays to 4 at least for my application. Maybe Freescale guys can comment. Thanks
Hi Tarek, Could you please post your result on the community? This way, your question can be route to a Freescale specialist. Honestly, I have no idea what this is hardcore. Leo
(In reply to comment #21) > Hi Tarek, > Could you please post your result on the community? This way, your question > can be route to a Freescale specialist. Honestly, I have no idea what this > is hardcore. Any progress here?
I've just tested the head of branch next (with multimedia package version 3.0.8) and here is the result: * With Matchbox on top of X (no wayland in DISTRO_FEATURES), first playback runs fine. Second try with isink breaks with the message: Can not open dll, libgstfsl-0.10.so: cannot open shared object file: No such file or directory. Caught SIGSEGV accessing address (nil) #0 0x2af6dbf4 in ?? () #1 0x2af6dbe4 in ?? () #2 0x2af6dbe4 in ?? () Spinning. Please run 'gdb gst-launch 548' to continue debugging, Ctrl-C to quit, or Ctrl-\ to dump core. * With console on FB (no X11 and no wayland), the pipeline runs fine everytime. Note: It's also possible to do resize/repositioning with mfw_v4lsink and it gives a better video quality than mfw_isink. AFAIK, main advantage of mfw_isink over mfw_v4lsink would be multiple content on the same screen. If this is not a requirement, I'd suggest using mfw_v4lsink. I'm not saying the mfw_isink issue should not be fixed though...
Hello master+linux-imx and dora+linux-imx fails with this SIGSEGV error here on a iMX6Q Sabre Lite board. Workaround: cd /usr/lib ln -s libgstfsl-0.10.so.0 libgstfsl-0.10.so
(In reply to comment #23) > I've just tested the head of branch next (with multimedia package version > 3.0.8) and here is the result: > > * With Matchbox on top of X (no wayland in DISTRO_FEATURES), first playback > runs fine. Second try with isink breaks with the message: > Can not open dll, libgstfsl-0.10.so: cannot open shared object file: No such > file or directory. > Caught SIGSEGV accessing address (nil) > #0 0x2af6dbf4 in ?? () > #1 0x2af6dbe4 in ?? () > #2 0x2af6dbe4 in ?? () > Spinning. Please run 'gdb gst-launch 548' to continue debugging, Ctrl-C to > quit, or Ctrl-\ to dump core. > > * With console on FB (no X11 and no wayland), the pipeline runs fine > everytime. > > Note: It's also possible to do resize/repositioning with mfw_v4lsink and it > gives a better video quality than mfw_isink. > > AFAIK, main advantage of mfw_isink over mfw_v4lsink would be multiple > content on the same screen. If this is not a requirement, I'd suggest using > mfw_v4lsink. I'm not saying the mfw_isink issue should not be fixed though... Issue is still present on DORA
Yes, i still to workaround with cd /usr/lib ln -s libgstfsl-0.10.so.0 libgstfsl-0.10.so (In reply to comment #25) > (In reply to comment #23) > > I've just tested the head of branch next (with multimedia package version > > 3.0.8) and here is the result: > > > > * With Matchbox on top of X (no wayland in DISTRO_FEATURES), first playback > > runs fine. Second try with isink breaks with the message: > > Can not open dll, libgstfsl-0.10.so: cannot open shared object file: No such > > file or directory. > > Caught SIGSEGV accessing address (nil) > > #0 0x2af6dbf4 in ?? () > > #1 0x2af6dbe4 in ?? () > > #2 0x2af6dbe4 in ?? () > > Spinning. Please run 'gdb gst-launch 548' to continue debugging, Ctrl-C to > > quit, or Ctrl-\ to dump core. > > > > * With console on FB (no X11 and no wayland), the pipeline runs fine > > everytime. > > > > Note: It's also possible to do resize/repositioning with mfw_v4lsink and it > > gives a better video quality than mfw_isink. > > > > AFAIK, main advantage of mfw_isink over mfw_v4lsink would be multiple > > content on the same screen. If this is not a requirement, I'd suggest using > > mfw_v4lsink. I'm not saying the mfw_isink issue should not be fixed though... > > > Issue is still present on DORA
The fix has been applied to: Master: http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?id=d534fa308f2bbe4152495fdfb32b360253ca57a1 Dora: http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/commit/?h=dora&id=57be0a2e41326206d50e27ad4fec2b0beaa862f6