On 2015-05-13 11:00, Gary Thomas wrote:
On 2015-05-13 10:16, Gary Thomas wrote:
On 2015-05-13 08:00, Gary Thomas wrote:
On 2015-05-13 07:27, Gary Thomas wrote:
On 2015-05-13 07:07, Otavio Salvador wrote:
On Wed, May 13, 2015 at 9:57 AM, Gary Thomas <[email protected]> wrote:
On 2015-05-12 06:59, Otavio Salvador wrote:
On Tue, May 12, 2015 at 9:53 AM, Gary Thomas <[email protected]> wrote:
On 2015-05-12 06:48, Otavio Salvador wrote:
On Tue, May 12, 2015 at 9:47 AM, Gary Thomas <[email protected]> wrote:
On 2015-05-12 06:43, Otavio Salvador wrote:
On Tue, May 12, 2015 at 9:27 AM, Nikolay Dimitrov <[email protected]>
wrote:
Gstreamer-1.0 freezes instantly with my test video streams. As I've
invested some time in the past to really force gstreamer-0.10 to
work,
I'm quite reluctant to go forward with gstreamer-1.0, especially when
its MPEGTS implementation is, well... half-working. So I'm sticking
with
what I've made to work so far.
Did you try the community plugin? We have been using it with several
customers and in general it is working very well.
Is that not what you would get when running the media player?
Do you have an example pipeline that does work, e.g. play a
complete movie (H264+mp3) in .mp4 container?
gst-play-1.0 works.
Not for me on either of the i.MX6 boards I have here :-( What board(s)
[and kernel] have you tested with?
What did you play? What is your display device? Anything else
you can provide that might help me figure this out...
Did you use the gstreamer1.0-imx? The fsl-image-multimedia works for
many movies.
I found that my kernel was not enabling mxc_v4l2_output. I've enabled this
and now the result is different, but always failing with:
mxc_v4l2_output v4l2_out.32: Bypass IC.
Attempt to unlock mutex that was not locked
Do you have an image where this works correctly? I'd like to try it with
my kernel on my hardware, etc.
http://ci.ossystems.com.br/public/fsl-community-bsp/fido
Thanks. I tried an image for my SabreLite, but it seems to be missing
important bits. This is the image I tried:
http://ci.ossystems.com.br/public/fsl-community-bsp/fido/16/x11/nitrogen6x/fsl-image-multimedia-nitrogen6x.sdcard
It doesn't have gst-play-1.0, nor much of anything as far as I can tell.
X brings up a terminal window, but I don't see how to run anything else,
e.g. chrome?
What am I missing? Perhaps I chose the wrong image? How do I play a movie
using this image (as your comment above says should work)?
Thanks again
I tried a different image that has more tools:
http://ci.ossystems.com.br/public/fsl-community-bsp/fido/16/x11/nitrogen6x/fsl-image-machine-test-nitrogen6x.sdcard
Sadly, it's working the same as the image(s) I build myself:
root@nitrogen6x:~# export DISPLAY=:0.0
root@nitrogen6x:~# gst-play-1.0 Vlad+Louise.mp4
mxc_cam_select_input: input(0) CSI IC MEM
mxc_v4l_open: Mxc Camera no sensor ipu1/csi0
mxc_v4l_open: Mxc Camera no sensor ipu1/csi1
Now playing /home/root/Vlad+Louise.mp4
[INFO]liProduct Info: i.MX6Q/D/S
[INFO] bitstreamMode 1, chromaInterleave 0, mapType 0, tiled2LinearEnable 0
CODEC: BLN_MAD-MMCODECS_AACD_ARM_03.09.00_CORTEX-A8 build on Jun 19 2014
18:30:32.
Attempt to unlock mutex that was not locked
Aborted
Please tell me again how this is working well for your customers?
What am I doing wrong?
Note: I've tried multiple .mp4 files, with the same results.
I've tracked this down to the gst1.0-fsl-plugin package.
Here's a GDB backktrace from the abort:
(gdb) bt
#0 0xb6b109d4 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:55
#1 0xb6b144d4 in __GI_abort () at abort.c:89
#2 0xb6d537e4 in g_mutex_unlock_slowpath (mutex=mutex@entry=0xb39ff460,
prev=<optimized out>)
at
/usr/src/debug/glib-2.0/1_2.44.0-r0/glib-2.44.0/glib/gthread-posix.c:1326
#3 0xb6d542f8 in g_mutex_unlock (mutex=mutex@entry=0xb39ff460)
at
/usr/src/debug/glib-2.0/1_2.44.0-r0/glib-2.44.0/glib/gthread-posix.c:1349
#4 0xb6d5441c in g_cond_wait (cond=0xfffffffe, cond@entry=0xb49085e4,
mutex=0xb39ff460, mutex@entry=0xb49085f0)
at
/usr/src/debug/glib-2.0/1_2.44.0-r0/glib-2.44.0/glib/gthread-posix.c:1394
#5 0xb31d3a98 in compositor_compositing_thread (compositor=0xb49085d0)
at
/usr/src/debug/gst1.0-fsl-plugin/4.0.3-r0/gst1.0-fsl-plugins-4.0.3/plugins/overlay_sink/compositor.c:282
#6 0xb6d34be4 in g_thread_proxy (data=0xb4902a30)
at /usr/src/debug/glib-2.0/1_2.44.0-r0/glib-2.44.0/glib/gthread.c:764
#7 0xb6c27de0 in start_thread (arg=0xb39ff460) at pthread_create.c:338
#8 0xb6bb4fa0 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:89 from
/tmp/p0382_root/lib/libc.so.6
The function in question is:
static gpointer compositor_compositing_thread (gpointer compositor)
{
CompositorHandle *hcompositor = (CompositorHandle*) compositor;
while (hcompositor->running) {
COMPOSITOR_WAIT_SURFACE (hcompositor);
compositor_do_compositing_surface_list (hcompositor);
}
GST_DEBUG ("compositor thread exit");
return;
}
It's failing on the 'COMPOSITOR_WAIT_SURFACE' function, the first time
is is called.
Anyone know why this might be failing? Does someone have a working
example of this code - from either fido or current master?
Thanks
BTW, this patch fixes the problem and I can play my videos with gst-play.
Is it correct?
Index: gst1.0-fsl-plugins-4.0.3/plugins/overlay_sink/compositor.c
===================================================================
--- gst1.0-fsl-plugins-4.0.3.orig/plugins/overlay_sink/compositor.c
+++ gst1.0-fsl-plugins-4.0.3/plugins/overlay_sink/compositor.c
@@ -278,6 +278,7 @@ static gpointer compositor_compositing_t
{
CompositorHandle *hcompositor = (CompositorHandle*) compositor;
+ g_mutex_lock(&hcompositor->lock);
while (hcompositor->running) {
COMPOSITOR_WAIT_SURFACE (hcompositor);
compositor_do_compositing_surface_list (hcompositor);
"Working" was a bit premature :-( gst-play does work when I run it
manually from the command line. When I run it from the window manager
(i.e. click on 'media player'), it tries to run now (as opposed to
quitting immediately), but there is no video shown, only a progress
bar.
Anyone know what might be the difference when running in these two
modes?
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
--
_______________________________________________
meta-freescale mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/meta-freescale
