Using the coda driver with Gstreamer

Using the coda driver with Gstreamer

[Fabio Estevam]

Hi,

I am running linux-next 20141117 on a mx6qsabresd board and trying to
play a mp4 video via Gstreamer 1.4.1, but I am getting the following
error:

root@imx6qsabresd:/mnt/nfs# gst-play-1.0 sample.mp4
Volume: 100%
Now playing /mnt/nfs/sample.mp4
[  506.983809] ------------[ cut here ]------------
[  506.988522] WARNING: CPU: 0 PID: 954 at
drivers/media/v4l2-core/videobuf2-core.c:1781
vb2_start_streaming+0xc4/0x160()
[  506.999301] Modules linked in:
[  507.002489] CPU: 0 PID: 954 Comm: multiqueue0:src Tainted: G
W      3.18.0-rc4-next-20141117-dirty #2044
[  507.012660] Backtrace:
[  507.015253] [<80011f44>] (dump_backtrace) from [<800120e0>]
(show_stack+0x18/0x1c)
[  507.022891]  r6:000006f5 r5:00000000 r4:00000000 r3:00000000
[  507.028707] [<800120c8>] (show_stack) from [<806b730c>]
(dump_stack+0x88/0xa4)
[  507.035954] [<806b7284>] (dump_stack) from [<8002a4dc>]
(warn_slowpath_common+0x80/0xbc)
[  507.044135]  r5:804a80a8 r4:00000000
[  507.047802] [<8002a45c>] (warn_slowpath_common) from [<8002a53c>]
(warn_slowpath_null+0x24/0x2c)
[  507.056605]  r8:00000000 r7:bd71c640 r6:bd614ef0 r5:bd614ee0 r4:ffffffea
[  507.063470] [<8002a518>] (warn_slowpath_null) from [<804a80a8>]
(vb2_start_streaming+0xc4/0x160)
[  507.072293] [<804a7fe4>] (vb2_start_streaming) from [<804a9efc>]
(vb2_internal_streamon+0xfc/0x158)
[  507.081385]  r7:bd71c640 r6:bd6c29ec r5:bd614c00 r4:bd614de0
[  507.087133] [<804a9e00>] (vb2_internal_streamon) from [<804ab0a8>]
(vb2_streamon+0x34/0x58)
[  507.095567]  r5:bd614c00 r4:00000002
[  507.099231] [<804ab074>] (vb2_streamon) from [<804a3b10>]
(v4l2_m2m_streamon+0x28/0x40)
[  507.107287] [<804a3ae8>] (v4l2_m2m_streamon) from [<804a3b40>]
(v4l2_m2m_ioctl_streamon+0x18/0x1c)
[  507.116292]  r5:bd9083c8 r4:40045612
[  507.120016] [<804a3b28>] (v4l2_m2m_ioctl_streamon) from
[<80492e48>] (v4l_streamon+0x20/0x24)
[  507.128693] [<80492e28>] (v4l_streamon) from [<80494dc4>]
(__video_do_ioctl+0x24c/0x2e0)
[  507.136826] [<80494b78>] (__video_do_ioctl) from [<804953a8>]
(video_usercopy+0x118/0x480)
[  507.145133]  r10:00000001 r9:bd6cbe10 r8:74a1164c r7:00000000
r6:00000000 r5:80494b78
[  507.153073]  r4:40045612
[  507.155632] [<80495290>] (video_usercopy) from [<80495724>]
(video_ioctl2+0x14/0x1c)
[  507.163408]  r10:bd8fccb8 r9:74a1164c r8:bd909064 r7:74a1164c
r6:40045612 r5:bd71c640
[  507.171343]  r4:bd9083c8
[  507.173902] [<80495710>] (video_ioctl2) from [<804918f8>]
(v4l2_ioctl+0x104/0x14c)
[  507.181512] [<804917f4>] (v4l2_ioctl) from [<800fc944>]
(do_vfs_ioctl+0x80/0x634)
[  507.189019]  r8:00000009 r7:74a1164c r6:00000009 r5:800fcf34
r4:bd71c640 r3:804917f4
[  507.196870] [<800fc8c4>] (do_vfs_ioctl) from [<800fcf34>]
(SyS_ioctl+0x3c/0x60)
[  507.204203]  r10:00000000 r9:bd6ca000 r8:00000009 r7:74a1164c
r6:40045612 r5:bd71c640
[  507.212159]  r4:bd71c641
[  507.214722] [<800fcef8>] (SyS_ioctl) from [<8000ec60>]
(ret_fast_syscall+0x0/0x48)
[  507.222311]  r8:8000ee24 r7:00000036 r6:73c183a0 r5:754248e0
r4:00000000 r3:00000000
[  507.230168] ---[ end trace c3703a604edaf0d0 ]---
ERROR Failed to connect to X display server for file:///mnt/nfs/sample.mp4
ERROR debug information:
/code/yocto/dizzy/build/tmp/work/cortexa9hf-vfp-neon-mx6qdl-poky-linux-gnueabi/gstreamer1.0-plugins-bad/1.4.1-r0/gst-plugins-bad-1.4.1/ext/gl/gstglimagesink.c(453):
_ensure_gl_setup ():
/GstPlayBin:playbin/GstPlaySink:playsink/GstBin:vbin/GstGLImageSink:glimagesink0
GLib (gthread-posix.c): Unexpected error from C library during
'pthread_mutex_lock': Invalid argument.  Aborting.
Aborted

Any suggestions?

Thanks,

Fabio Estevam

Re: Using the coda driver with Gstreamer

[Nicolas Dufresne]

Note, I'm only commenting about the GStreamer side...

Le 2014-11-17 12:29, Fabio Estevam a écrit :
> Hi,
>
> I am running linux-next 20141117 on a mx6qsabresd board and trying to
> play a mp4 video via Gstreamer 1.4.1, but I am getting the following
> error:
You should update to latest stable version, this is a general rule. Not
keeping track of stable branches is never a good idea. Current stable is
1.4.4.

Note that as of today, there is known issue with supporting this driver
(not that driver itself, I really mean supporting the driver features):

- Need to fix EOS Handling,
https://bugzilla.gnome.org/show_bug.cgi?id=733864
- Output size negotiation https://bugzilla.gnome.org/show_bug.cgi?id=733828
- Output pixel format negotiation
https://bugzilla.gnome.org/show_bug.cgi?id=733827
- Encoding is not yet supported
https://bugzilla.gnome.org/show_bug.cgi?id=728438

First one is the main blocker, but kernel folks will be able to clarify
more. Help is of course appreciated. Note that some of the issues kind
of lack a specification to accomplished. We recently had a meeting in
Dusseldorf to propose solutions.

>
> root@imx6qsabresd:/mnt/nfs# gst-play-1.0 sample.mp4
> Volume: 100%
> Now playing /mnt/nfs/sample.mp4
> [  506.983809] ------------[ cut here ]------------
> [  506.988522] WARNING: CPU: 0 PID: 954 at
> drivers/media/v4l2-core/videobuf2-core.c:1781
> vb2_start_streaming+0xc4/0x160()
> [  506.999301] Modules linked in:
> [  507.002489] CPU: 0 PID: 954 Comm: multiqueue0:src Tainted: G
> W      3.18.0-rc4-next-20141117-dirty #2044
> [  507.012660] Backtrace:
> [  507.015253] [<80011f44>] (dump_backtrace) from [<800120e0>]
> (show_stack+0x18/0x1c)
> [  507.022891]  r6:000006f5 r5:00000000 r4:00000000 r3:00000000
> [  507.028707] [<800120c8>] (show_stack) from [<806b730c>]
> (dump_stack+0x88/0xa4)
> [  507.035954] [<806b7284>] (dump_stack) from [<8002a4dc>]
> (warn_slowpath_common+0x80/0xbc)
> [  507.044135]  r5:804a80a8 r4:00000000
> [  507.047802] [<8002a45c>] (warn_slowpath_common) from [<8002a53c>]
> (warn_slowpath_null+0x24/0x2c)
> [  507.056605]  r8:00000000 r7:bd71c640 r6:bd614ef0 r5:bd614ee0 r4:ffffffea
> [  507.063470] [<8002a518>] (warn_slowpath_null) from [<804a80a8>]
> (vb2_start_streaming+0xc4/0x160)
> [  507.072293] [<804a7fe4>] (vb2_start_streaming) from [<804a9efc>]
> (vb2_internal_streamon+0xfc/0x158)
> [  507.081385]  r7:bd71c640 r6:bd6c29ec r5:bd614c00 r4:bd614de0
> [  507.087133] [<804a9e00>] (vb2_internal_streamon) from [<804ab0a8>]
> (vb2_streamon+0x34/0x58)
> [  507.095567]  r5:bd614c00 r4:00000002
> [  507.099231] [<804ab074>] (vb2_streamon) from [<804a3b10>]
> (v4l2_m2m_streamon+0x28/0x40)
> [  507.107287] [<804a3ae8>] (v4l2_m2m_streamon) from [<804a3b40>]
> (v4l2_m2m_ioctl_streamon+0x18/0x1c)
> [  507.116292]  r5:bd9083c8 r4:40045612
> [  507.120016] [<804a3b28>] (v4l2_m2m_ioctl_streamon) from
> [<80492e48>] (v4l_streamon+0x20/0x24)
> [  507.128693] [<80492e28>] (v4l_streamon) from [<80494dc4>]
> (__video_do_ioctl+0x24c/0x2e0)
> [  507.136826] [<80494b78>] (__video_do_ioctl) from [<804953a8>]
> (video_usercopy+0x118/0x480)
> [  507.145133]  r10:00000001 r9:bd6cbe10 r8:74a1164c r7:00000000
> r6:00000000 r5:80494b78
> [  507.153073]  r4:40045612
> [  507.155632] [<80495290>] (video_usercopy) from [<80495724>]
> (video_ioctl2+0x14/0x1c)
> [  507.163408]  r10:bd8fccb8 r9:74a1164c r8:bd909064 r7:74a1164c
> r6:40045612 r5:bd71c640
> [  507.171343]  r4:bd9083c8
> [  507.173902] [<80495710>] (video_ioctl2) from [<804918f8>]
> (v4l2_ioctl+0x104/0x14c)
> [  507.181512] [<804917f4>] (v4l2_ioctl) from [<800fc944>]
> (do_vfs_ioctl+0x80/0x634)
> [  507.189019]  r8:00000009 r7:74a1164c r6:00000009 r5:800fcf34
> r4:bd71c640 r3:804917f4
> [  507.196870] [<800fc8c4>] (do_vfs_ioctl) from [<800fcf34>]
> (SyS_ioctl+0x3c/0x60)
> [  507.204203]  r10:00000000 r9:bd6ca000 r8:00000009 r7:74a1164c
> r6:40045612 r5:bd71c640
> [  507.212159]  r4:bd71c641
> [  507.214722] [<800fcef8>] (SyS_ioctl) from [<8000ec60>]
> (ret_fast_syscall+0x0/0x48)
> [  507.222311]  r8:8000ee24 r7:00000036 r6:73c183a0 r5:754248e0
> r4:00000000 r3:00000000
> [  507.230168] ---[ end trace c3703a604edaf0d0 ]---
Looks like a backtrace of a warning, though I'm not sure I get what this
warning is about. Maybe you are missing some information, or one need to
look at videobuf2-core.c:178.
> ERROR Failed to connect to X display server for file:///mnt/nfs/sample.mp4
You have built glimagesink (hence libgstgl, part of gst-plugins-bad)
against X11 but you don't have a X11 display running, or DISPLAY
environment isn't set properly.
> ERROR debug information:
> /code/yocto/dizzy/build/tmp/work/cortexa9hf-vfp-neon-mx6qdl-poky-linux-gnueabi/gstreamer1.0-plugins-bad/1.4.1-r0/gst-plugins-bad-1.4.1/ext/gl/gstglimagesink.c(453):
> _ensure_gl_setup ():
> /GstPlayBin:playbin/GstPlaySink:playsink/GstBin:vbin/GstGLImageSink:glimagesink0
> GLib (gthread-posix.c): Unexpected error from C library during
> 'pthread_mutex_lock': Invalid argument.  Aborting.
> Aborted
This is most likely fixed in stable releases. It's probably a bug in an
error path (spurious unlock, or use after free). If not fixed, valgrind
would tell us more.

Nicolas

Re: Using the coda driver with Gstreamer

[Andrey Utkin]

could you give `lspci -v` so that i see what module is a driver for
that component?

Try playing to same device with recent ffmpeg: ffmpeg -i sample.mp4
-codec copy -f v4l2 -y /dev/videoWhatYouHave
and check if you have the same kernel warning.

-- 
Bluecherry developer.

Re: Using the coda driver with Gstreamer

[Fabio Estevam]

Hi Nicolas,

On Mon, Nov 17, 2014 at 3:45 PM, Nicolas Dufresne
<nicolas.dufresne@collabora.com> wrote:
> Note, I'm only commenting about the GStreamer side...
>
> Le 2014-11-17 12:29, Fabio Estevam a écrit :
>> Hi,
>>
>> I am running linux-next 20141117 on a mx6qsabresd board and trying to
>> play a mp4 video via Gstreamer 1.4.1, but I am getting the following
>> error:
> You should update to latest stable version, this is a general rule. Not
> keeping track of stable branches is never a good idea. Current stable is
> 1.4.4.

Ok, let me upgrade Gstreamer to 1.4.4.

>> ERROR Failed to connect to X display server for file:///mnt/nfs/sample.mp4
> You have built glimagesink (hence libgstgl, part of gst-plugins-bad)
> against X11 but you don't have a X11 display running, or DISPLAY
> environment isn't set properly.

Yes, let me fix this first.

Thanks,

Fabio Estevam

Re: Using the coda driver with Gstreamer

[Fabio Estevam]

Hi Andrey,

On Mon, Nov 17, 2014 at 3:48 PM, Andrey Utkin
<andrey.utkin@corp.bluecherry.net> wrote:
> could you give `lspci -v` so that i see what module is a driver for
> that component?

I am using a mx6 processor that has a built-in hardware video
encoder/decoder. The driver is located at drivers/media/platform/coda/

Thanks

Re: Using the coda driver with Gstreamer

[Robert Schwebel]

Hi Fabio,

On Mon, Nov 17, 2014 at 03:29:17PM -0200, Fabio Estevam wrote:
> I am running linux-next 20141117 on a mx6qsabresd board and trying to
> play a mp4 video via Gstreamer 1.4.1, but I am getting the following
> error:
> 
> root@imx6qsabresd:/mnt/nfs# gst-play-1.0 sample.mp4
> Volume: 100%
> Now playing /mnt/nfs/sample.mp4
> [  506.983809] ------------[ cut here ]------------
> [  506.988522] WARNING: CPU: 0 PID: 954 at
> drivers/media/v4l2-core/videobuf2-core.c:1781
> vb2_start_streaming+0xc4/0x160()
> [  506.999301] Modules linked in:
> [  507.002489] CPU: 0 PID: 954 Comm: multiqueue0:src Tainted: G
> W      3.18.0-rc4-next-20141117-dirty #2044
> [  507.012660] Backtrace:
> [  507.015253] [<80011f44>] (dump_backtrace) from [<800120e0>]
> (show_stack+0x18/0x1c)
> [  507.022891]  r6:000006f5 r5:00000000 r4:00000000 r3:00000000
> [  507.028707] [<800120c8>] (show_stack) from [<806b730c>]
> (dump_stack+0x88/0xa4)
> [  507.035954] [<806b7284>] (dump_stack) from [<8002a4dc>]
> (warn_slowpath_common+0x80/0xbc)
> [  507.044135]  r5:804a80a8 r4:00000000
> [  507.047802] [<8002a45c>] (warn_slowpath_common) from [<8002a53c>]
> (warn_slowpath_null+0x24/0x2c)
> [  507.056605]  r8:00000000 r7:bd71c640 r6:bd614ef0 r5:bd614ee0 r4:ffffffea
> [  507.063470] [<8002a518>] (warn_slowpath_null) from [<804a80a8>]
> (vb2_start_streaming+0xc4/0x160)
> [  507.072293] [<804a7fe4>] (vb2_start_streaming) from [<804a9efc>]
> (vb2_internal_streamon+0xfc/0x158)
> [  507.081385]  r7:bd71c640 r6:bd6c29ec r5:bd614c00 r4:bd614de0
> [  507.087133] [<804a9e00>] (vb2_internal_streamon) from [<804ab0a8>]
> (vb2_streamon+0x34/0x58)
> [  507.095567]  r5:bd614c00 r4:00000002
> [  507.099231] [<804ab074>] (vb2_streamon) from [<804a3b10>]
> (v4l2_m2m_streamon+0x28/0x40)
> [  507.107287] [<804a3ae8>] (v4l2_m2m_streamon) from [<804a3b40>]
> (v4l2_m2m_ioctl_streamon+0x18/0x1c)
> [  507.116292]  r5:bd9083c8 r4:40045612
> [  507.120016] [<804a3b28>] (v4l2_m2m_ioctl_streamon) from
> [<80492e48>] (v4l_streamon+0x20/0x24)
> [  507.128693] [<80492e28>] (v4l_streamon) from [<80494dc4>]
> (__video_do_ioctl+0x24c/0x2e0)
> [  507.136826] [<80494b78>] (__video_do_ioctl) from [<804953a8>]
> (video_usercopy+0x118/0x480)
> [  507.145133]  r10:00000001 r9:bd6cbe10 r8:74a1164c r7:00000000
> r6:00000000 r5:80494b78
> [  507.153073]  r4:40045612
> [  507.155632] [<80495290>] (video_usercopy) from [<80495724>]
> (video_ioctl2+0x14/0x1c)
> [  507.163408]  r10:bd8fccb8 r9:74a1164c r8:bd909064 r7:74a1164c
> r6:40045612 r5:bd71c640
> [  507.171343]  r4:bd9083c8
> [  507.173902] [<80495710>] (video_ioctl2) from [<804918f8>]
> (v4l2_ioctl+0x104/0x14c)
> [  507.181512] [<804917f4>] (v4l2_ioctl) from [<800fc944>]
> (do_vfs_ioctl+0x80/0x634)
> [  507.189019]  r8:00000009 r7:74a1164c r6:00000009 r5:800fcf34
> r4:bd71c640 r3:804917f4
> [  507.196870] [<800fc8c4>] (do_vfs_ioctl) from [<800fcf34>]
> (SyS_ioctl+0x3c/0x60)
> [  507.204203]  r10:00000000 r9:bd6ca000 r8:00000009 r7:74a1164c
> r6:40045612 r5:bd71c640
> [  507.212159]  r4:bd71c641
> [  507.214722] [<800fcef8>] (SyS_ioctl) from [<8000ec60>]
> (ret_fast_syscall+0x0/0x48)
> [  507.222311]  r8:8000ee24 r7:00000036 r6:73c183a0 r5:754248e0
> r4:00000000 r3:00000000
> [  507.230168] ---[ end trace c3703a604edaf0d0 ]---
> ERROR Failed to connect to X display server for file:///mnt/nfs/sample.mp4
> ERROR debug information:
> /code/yocto/dizzy/build/tmp/work/cortexa9hf-vfp-neon-mx6qdl-poky-linux-gnueabi/gstreamer1.0-plugins-bad/1.4.1-r0/gst-plugins-bad-1.4.1/ext/gl/gstglimagesink.c(453):
> _ensure_gl_setup ():
> /GstPlayBin:playbin/GstPlaySink:playsink/GstBin:vbin/GstGLImageSink:glimagesink0
> GLib (gthread-posix.c): Unexpected error from C library during
> 'pthread_mutex_lock': Invalid argument.  Aborting.
> Aborted
> 
> Any suggestions?

Philipp is on vacation this week, he can have a look when he is back in
the office next monday.

Just a wild guess - we usually test here with dmabuf capable devices and
without X. As you are using gstglimagesink, the code around
ext/gl/gstglimagesink.c (453) looks like gst_gl_context_create() went
wrong. Does your GL work correctly? Maybe you can test the glimagesink
with a simpler pipeline first.

rsc <- being no gst expert
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: Using the coda driver with Gstreamer

[Fabio Estevam]

Hi Robert,

On Mon, Nov 17, 2014 at 4:55 PM, Robert Schwebel
<r.schwebel@pengutronix.de> wrote:

> Philipp is on vacation this week, he can have a look when he is back in
> the office next monday.

Thanks for letting me know.

> Just a wild guess - we usually test here with dmabuf capable devices and
> without X. As you are using gstglimagesink, the code around
> ext/gl/gstglimagesink.c (453) looks like gst_gl_context_create() went
> wrong. Does your GL work correctly? Maybe you can test the glimagesink
> with a simpler pipeline first.

Yes, maybe it would be better to remove X from my initial tests. I
will give it a try.

Thanks for the suggestions.

Regards,

Fabio Estevam

Re: Using the coda driver with Gstreamer

[Fabio Estevam]

On Mon, Nov 17, 2014 at 5:58 PM, Fabio Estevam <festevam@gmail.com> wrote:

>> Just a wild guess - we usually test here with dmabuf capable devices and
>> without X. As you are using gstglimagesink, the code around
>> ext/gl/gstglimagesink.c (453) looks like gst_gl_context_create() went
>> wrong. Does your GL work correctly? Maybe you can test the glimagesink
>> with a simpler pipeline first.
>
> Yes, maybe it would be better to remove X from my initial tests. I
> will give it a try.

Now I have a rootfs without X:

root@imx6qsabresd:/home# gst-inspect-1.0 | grep v4l2
video4linux2:  v4l2src: Video (video4linux2) Source
video4linux2:  v4l2sink: Video (video4linux2) Sink
video4linux2:  v4l2radio: Radio (video4linux2) Tuner
video4linux2:  v4l2deviceprovider (GstDeviceProviderFactory)
video4linux2:  v4l2video1dec: V4L2 Video Decoder

Basic test works fine:
root@imx6qsabresd:/home# gst-launch-1.0 videotestsrc ! fbdevsink

root@imx6qsabresd:/home# gst-launch-1.0 playbin uri=file:///home/H264_test1_Talk
inghead_mp4_480x360.mp4
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Redistribute latency...
[  138.267329] coda 2040000.vpu: CODA PIC_RUN timeout

I was not able to switch to Gstreamer 1.4.4 yet, so this was on 1.4.1.

Thanks

Re: Using the coda driver with Gstreamer

[Nicolas Dufresne]

Le 2014-11-18 13:08, Fabio Estevam a écrit :
> On Mon, Nov 17, 2014 at 5:58 PM, Fabio Estevam <festevam@gmail.com> wrote:
> 
>>> Just a wild guess - we usually test here with dmabuf capable devices and
>>> without X. As you are using gstglimagesink, the code around
>>> ext/gl/gstglimagesink.c (453) looks like gst_gl_context_create() went
>>> wrong. Does your GL work correctly? Maybe you can test the glimagesink
>>> with a simpler pipeline first.
>>
>> Yes, maybe it would be better to remove X from my initial tests. I
>> will give it a try.
> 
> Now I have a rootfs without X:

Ok, nice, though what is your plan to display the result now ? This is
important information to get any help.

> 
> root@imx6qsabresd:/home# gst-inspect-1.0 | grep v4l2
> video4linux2:  v4l2src: Video (video4linux2) Source
> video4linux2:  v4l2sink: Video (video4linux2) Sink
> video4linux2:  v4l2radio: Radio (video4linux2) Tuner
> video4linux2:  v4l2deviceprovider (GstDeviceProviderFactory)
> video4linux2:  v4l2video1dec: V4L2 Video Decoder
> 
> Basic test works fine:
> root@imx6qsabresd:/home# gst-launch-1.0 videotestsrc ! fbdevsink
> 
> root@imx6qsabresd:/home# gst-launch-1.0 playbin uri=file:///home/H264_test1_Talk
> inghead_mp4_480x360.mp4
> Setting pipeline to PAUSED ...
> Pipeline is PREROLLING ...
> Redistribute latency...
> [  138.267329] coda 2040000.vpu: CODA PIC_RUN timeout
> 
> I was not able to switch to Gstreamer 1.4.4 yet, so this was on 1.4.1.
> 

Ok, let us know when the switch is made. Assuming your goal is to get
the HW decoder working, you should test with simpler pipeline. In your
specific case, you should try and get this pipeline to preroll:

gst-launch-1.0 \
  filesrc location=/home/H264_test1_Talk inghead_mp4_480x360.mp4 \
  ! qtdemux ! h264parse ! v4l2video1dec ! fakesink

If that pipeline does not reach PLAYING state, it means the decoder
never produced any output. You should also learn to use the tracing
system in GStreamer and make sure you have the source code next to you.
I would also suggest to try your best to sort as much as you can, make
sure you understand what you are trying to achieve and then come back
with questions.

http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/gst-running.html

Re: Using the coda driver with Gstreamer

[Fabio Estevam]

On Tue, Nov 18, 2014 at 4:41 PM, Nicolas Dufresne
<nicolas.dufresne@collabora.com> wrote:

> Ok, let us know when the switch is made. Assuming your goal is to get
> the HW decoder working, you should test with simpler pipeline. In your
> specific case, you should try and get this pipeline to preroll:
>
> gst-launch-1.0 \
>   filesrc location=/home/H264_test1_Talk inghead_mp4_480x360.mp4 \
>   ! qtdemux ! h264parse ! v4l2video1dec ! fakesink

After applying Philipp's dts patch:
http://www.spinics.net/lists/arm-kernel/msg382314.html

,I am able to play the video clip with the following Gstreamer pipeline:

gst-launch-1.0 filesrc
location=/home/H264_test1_Talkinghead_mp4_480x360.mp4 ! qtdemux !
h264parse ! v4l2video1dec ! videoconvert ! fbdevsink

(Still on Gstreamer 1.4.1 version though, as I was not able to upgrade it yet).

Regards,

Fabio Estevam

Re: Using the coda driver with Gstreamer

[Zahari Doychev]

Hi Fabio,

On Mon, Dec 01, 2014 at 05:17:40PM -0200, Fabio Estevam wrote:
> On Tue, Nov 18, 2014 at 4:41 PM, Nicolas Dufresne
> <nicolas.dufresne@collabora.com> wrote:
> 
> > Ok, let us know when the switch is made. Assuming your goal is to get
> > the HW decoder working, you should test with simpler pipeline. In your
> > specific case, you should try and get this pipeline to preroll:
> >
> > gst-launch-1.0 \
> >   filesrc location=/home/H264_test1_Talk inghead_mp4_480x360.mp4 \
> >   ! qtdemux ! h264parse ! v4l2video1dec ! fakesink
> 
> After applying Philipp's dts patch:
> http://www.spinics.net/lists/arm-kernel/msg382314.html
> 
> ,I am able to play the video clip with the following Gstreamer pipeline:
> 
> gst-launch-1.0 filesrc
> location=/home/H264_test1_Talkinghead_mp4_480x360.mp4 ! qtdemux !
> h264parse ! v4l2video1dec ! videoconvert ! fbdevsink

I am using this pipeline with gstreamer 1.4.5 and current media branch but I am
getting very poor performance 1-2 fps when playing 800x400 video. Is it possible
that fbdevsink is too slow for that? Does anyone know what is going wrong?

Regards,

Zahari

Video Type:

root@imx6q-dmo-edm-qmx6:/# gst-discoverer-1.0 linux_800x480.mov -v
Analyzing file:///DemoVideos/linux_800x480.mov
Done discovering file:///DemoVideos/linux_800x480.mov
Missing plugins
 (gstreamer|1.0|gst-discoverer-1.0|MPEG-4 AAC decoder|decoder-audio/mpeg, mpegversion=(int)4, framed=(boolean)true, stream-format=(string)raw, level=(string)2, base-profile=(string)lc, profile=(string)lc)

Topology:
  container: video/quicktime
    audio: audio/mpeg, mpegversion=(int)4, framed=(boolean)true, stream-format=(string)raw, level=(string)2, base-profile=(string)lc, profile=(string)lc, codec_data=(buffer)120856e500, rate=(int)44100, channels=(int)1
      Codec:
        audio/mpeg, mpegversion=(int)4, framed=(boolean)true, stream-format=(string)raw, level=(string)2, base-profile=(string)lc, profile=(string)lc, codec_data=(buffer)120856e500, rate=(int)44100, channels=(int)1
      Additional info:
        None
      Stream ID: (null)
      Language: <unknown>
      Channels: 1
      Sample rate: 44100
      Depth: 0
      Bitrate: 0
      Max bitrate: 0
      Tags:
        None
      
    video: video/x-h264, stream-format=(string)avc, alignment=(string)au, level=(string)3.1, profile=(string)high, codec_data=(buffer)0164001fffe100176764001facd940c83da100000303e90000ea600f18319601000668ebe3cb22c0, width=(int)800, height=(int)480, framerate=(fraction)30000/1001, pixel-aspect-ratio=(fraction)1/1
      Codec:
        video/x-h264, stream-format=(string)avc, alignment=(string)au, level=(string)3.1, profile=(string)high, codec_data=(buffer)0164001fffe100176764001facd940c83da100000303e90000ea600f18319601000668ebe3cb22c0, width=(int)800, height=(int)480, framerate=(fraction)30000/1001, pixel-aspect-ratio=(fraction)1/1
      Additional info:
        None
      Stream ID: 0b5ab36c52878431d95e588951bfa2cf80c530ad5deda45bf3f9fdd5a4d4a48f/001
      Width: 800
      Height: 480
      Depth: 24
      Frame rate: 30000/1001
      Pixel aspect ratio: 1/1
      Interlaced: false
      Bitrate: 496256
      Max bitrate: 10069
      Tags:
        taglist, application-name=(string)Lavf55.7.100, container-format=(string)Quicktime, video-codec=(string)H.264, language-code=(string)en, bitrate=(uint)496256, minimum-bitrate=(uint)10069, maximum-bitrate=(uint)10069;
      

Properties:
  Duration: 0:03:12.006000000
  Seekable: yes
  Tags: 
      application name: Lavf55.7.100
      container format: Quicktime
      video codec: H.264
      language code: en
      bitrate: 496256
      minimum bitrate: 10069
      maximum bitrate: 10069

Re: Using the coda driver with Gstreamer

[Nicolas Dufresne]

Le 2015-02-18 03:42, Zahari Doychev a écrit :
>> gst-launch-1.0 filesrc
>> >location=/home/H264_test1_Talkinghead_mp4_480x360.mp4 ! qtdemux !
>> >h264parse ! v4l2video1dec ! videoconvert ! fbdevsink
> I am using this pipeline with gstreamer 1.4.5 and current media branch but I am
> getting very poor performance 1-2 fps when playing 800x400 video. Is it possible
> that fbdevsink is too slow for that? Does anyone know what is going wrong?
In this context, you most likely have a conversion happening in 
videoconvert followed by a copy at fbdevsink. Framebuffer device is not 
a very good solution if performance matter (no possible zero-copy). 
Specially if the selected framebuffer color format does not match the 
decoded format.

Nicolas

Re: Using the coda driver with Gstreamer

[Zahari Doychev]

On Wed, Feb 18, 2015 at 08:34:43AM -0500, Nicolas Dufresne wrote:
> 
> Le 2015-02-18 03:42, Zahari Doychev a écrit :
> >>gst-launch-1.0 filesrc
> >>>location=/home/H264_test1_Talkinghead_mp4_480x360.mp4 ! qtdemux !
> >>>h264parse ! v4l2video1dec ! videoconvert ! fbdevsink
> >I am using this pipeline with gstreamer 1.4.5 and current media branch but I am
> >getting very poor performance 1-2 fps when playing 800x400 video. Is it possible
> >that fbdevsink is too slow for that? Does anyone know what is going wrong?
> In this context, you most likely have a conversion happening in videoconvert
> followed by a copy at fbdevsink. Framebuffer device is not a very good
> solution if performance matter (no possible zero-copy). Specially if the
> selected framebuffer color format does not match the decoded format.

So can you tell me if there are some drivers and plugins that can do this
in efficient way. Is there some work going on in this directions. I suppose
glimagesink maybe will be a good way to go.

Regards,

Zahari

Re: Using the coda driver with Gstreamer

[Nicolas Dufresne]

Le 2015-02-19 02:24, Zahari Doychev a écrit :
> So can you tell me if there are some drivers and plugins that can do this
> in efficient way. Is there some work going on in this directions. I suppose
> glimagesink maybe will be a good way to go.

There is a lot of work happening, you should notice by searching this 
mailing list archive. The most promising seems to be the one targeting 
Wayland and DMABUF. On the GST side, there is experimental patches to 
handle DMABUF import and render queue, these are not yet fully merged 
into Wayland protocol and Weston. Weston can import DMABUF of various 
format and do the colorspace conversion using shaders. This can 
compensate the lack of hw color converter if your GPU is fast and 
precise enough.

Nicolas

Re: Using the coda driver with Gstreamer

[Peter Seiderer]

Hello Fabio,

maybe trying to increase the following kernel option helps (for the v4l2 kernel
driver failure message, not for the followup gstraemer errors):

CONFIG_CMA_SIZE_MBYTES=256

Regards,
Peter
---
Sorry for loosing the CC list, reading the mailing list by web browser...

> Hi,
>
> I am running linux-next 20141117 on a mx6qsabresd board and trying to
> play a mp4 video via Gstreamer 1.4.1, but I am getting the following
> error:
>
> root@imx6qsabresd:/mnt/nfs# gst-play-1.0 sample.mp4
> Volume: 100%
> Now playing /mnt/nfs/sample.mp4
> [  506.983809] ------------[ cut here ]------------
> [  506.988522] WARNING: CPU: 0 PID: 954 at
> drivers/media/v4l2-core/videobuf2-core.c:1781
> vb2_start_streaming+0xc4/0x160()
> [  506.999301] Modules linked in:
> [  507.002489] CPU: 0 PID: 954 Comm: multiqueue0:src Tainted: G
> W      3.18.0-rc4-next-20141117-dirty #2044
> [  507.012660] Backtrace:
> [  507.015253] [<80011f44>] (dump_backtrace) from [<800120e0>]
> (show_stack+0x18/0x1c)
> [  507.022891]  r6:000006f5 r5:00000000 r4:00000000 r3:00000000
> [  507.028707] [<800120c8>] (show_stack) from [<806b730c>]
> (dump_stack+0x88/0xa4)
> [  507.035954] [<806b7284>] (dump_stack) from [<8002a4dc>]
> (warn_slowpath_common+0x80/0xbc)
> [  507.044135]  r5:804a80a8 r4:00000000
> [  507.047802] [<8002a45c>] (warn_slowpath_common) from [<8002a53c>]
> (warn_slowpath_null+0x24/0x2c)
> [  507.056605]  r8:00000000 r7:bd71c640 r6:bd614ef0 r5:bd614ee0 r4:ffffffea
> [  507.063470] [<8002a518>] (warn_slowpath_null) from [<804a80a8>]
> (vb2_start_streaming+0xc4/0x160)
> [  507.072293] [<804a7fe4>] (vb2_start_streaming) from [<804a9efc>]
> (vb2_internal_streamon+0xfc/0x158)
> [  507.081385]  r7:bd71c640 r6:bd6c29ec r5:bd614c00 r4:bd614de0
> [  507.087133] [<804a9e00>] (vb2_internal_streamon) from [<804ab0a8>]
> (vb2_streamon+0x34/0x58)
> [  507.095567]  r5:bd614c00 r4:00000002
> [  507.099231] [<804ab074>] (vb2_streamon) from [<804a3b10>]
> (v4l2_m2m_streamon+0x28/0x40)
> [  507.107287] [<804a3ae8>] (v4l2_m2m_streamon) from [<804a3b40>]
> (v4l2_m2m_ioctl_streamon+0x18/0x1c)
> [  507.116292]  r5:bd9083c8 r4:40045612
> [  507.120016] [<804a3b28>] (v4l2_m2m_ioctl_streamon) from
> [<80492e48>] (v4l_streamon+0x20/0x24)
> [  507.128693] [<80492e28>] (v4l_streamon) from [<80494dc4>]
> (__video_do_ioctl+0x24c/0x2e0)
> [  507.136826] [<80494b78>] (__video_do_ioctl) from [<804953a8>]
> (video_usercopy+0x118/0x480)
> [  507.145133]  r10:00000001 r9:bd6cbe10 r8:74a1164c r7:00000000
> r6:00000000 r5:80494b78
> [  507.153073]  r4:40045612
> [  507.155632] [<80495290>] (video_usercopy) from [<80495724>]
> (video_ioctl2+0x14/0x1c)
> [  507.163408]  r10:bd8fccb8 r9:74a1164c r8:bd909064 r7:74a1164c
> r6:40045612 r5:bd71c640
> [  507.171343]  r4:bd9083c8
> [  507.173902] [<80495710>] (video_ioctl2) from [<804918f8>]
> (v4l2_ioctl+0x104/0x14c)
> [  507.181512] [<804917f4>] (v4l2_ioctl) from [<800fc944>]
> (do_vfs_ioctl+0x80/0x634)
> [  507.189019]  r8:00000009 r7:74a1164c r6:00000009 r5:800fcf34
> r4:bd71c640 r3:804917f4
> [  507.196870] [<800fc8c4>] (do_vfs_ioctl) from [<800fcf34>]
> (SyS_ioctl+0x3c/0x60)
> [  507.204203]  r10:00000000 r9:bd6ca000 r8:00000009 r7:74a1164c
> r6:40045612 r5:bd71c640
> [  507.212159]  r4:bd71c641
> [  507.214722] [<800fcef8>] (SyS_ioctl) from [<8000ec60>]
> (ret_fast_syscall+0x0/0x48)
> [  507.222311]  r8:8000ee24 r7:00000036 r6:73c183a0 r5:754248e0
> r4:00000000 r3:00000000
> [  507.230168] ---[ end trace c3703a604edaf0d0 ]---
> ERROR Failed to connect to X display server for file:///mnt/nfs/sample.mp4
> ERROR debug information:
> /code/yocto/dizzy/build/tmp/work/cortexa9hf-vfp-neon-mx6qdl-poky-linux-gnueabi/gstreamer1.0-plugins-bad/1.4.1-r0/gst-plugins-bad-1.4.1/ext/gl/gstglimagesink.c(453):
> _ensure_gl_setup ():
> /GstPlayBin:playbin/GstPlaySink:playsink/GstBin:vbin/GstGLImageSink:glimagesink0
> GLib (gthread-posix.c): Unexpected error from C library during
> 'pthread_mutex_lock': Invalid argument.  Aborting.
> Aborted
>
> Any suggestions?
>
> Thanks,
>
> Fabio Estevam
>