gst-dsp problems on BeagleBoard xM with Ubuntu 11.10

[Andrey]

Hi,

I've installed Ubuntu Oneiric 11.10 on my BeagleBoard xM as described here: http://elinux.org/BeagleBoardUbuntu (using NetIinstall method if it is matter). In addition, I've installed gst-dsp also as described on the same page. Everything seams to work fine:
$ uname -a
Linux t3 3.2.3-x4 #1 SMP Sat Feb 4 10:33:25 UTC 2012 armv7l armv7l
armv7l GNU/Linux
$ sudo dsp-test
copied 1000 times successfully

However, attempt to use dsph264enc leads to the following problems:

GST_DEBUG=2 gst-launch v4l2src !
video/x-raw-yuv,width=320,

height=240,framerate=25/1 ! ffmpegcolorspace
! video/x-raw-yuv,format=\(fourcc\)UYVY ! dsph264enc ! avimux !
filesink location="ttt.avi"
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
create_node: dsp node allocate failed
0:00:01.412139893  1671   0x115fb8 ERROR                    dsp
gstdspvenc.c:142:create_node:<dsph264enc0> dsp node allocate failed
sink_setcaps: dsp node creation failed
0:00:01.414367676  1671   0x115fb8 ERROR                    dsp
gstdspvenc.c:399:sink_setcaps:<dsph264enc0> dsp node creation failed
0:00:01.415283203  1671   0x115fb8 WARN                 basesrc
gstbasesrc.c:2582:gst_base_src_loop:<v4l2src0> error: Internal data
flow error.
0:00:01.416625977  1671   0x115fb8 WARN                 basesrc
gstbasesrc.c:2582:gst_base_src_loop:<v4l2src0> error: streaming task
paused, reason not-negotiated (-4)
ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
Internal data flow error.
Additional debug info:
gstbasesrc.c(2582): gst_base_src_loop ():
/GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
streaming task paused, reason not-negotiated (-4)
Execution ended after 420501710 ns.
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

Looking at dmesg, I can see the following relevant messages:
[ 4955.190002] cod_open: error status 0xfffffff7, sz_coff_path:
/lib/dsp/h264venc_sn.dll64P flags: 0x0
[ 4955.302520] procwrap_detach: deprecated dspbridge ioctl

and there is in fact no h264venc_sn.dll64P in /lib/dsp/. I found out that this file is not freely available because of license restrictions but I have n900 phone and copy this file from it to my BeagleBoard. It does not helps either (I can provide the error message if someone interested).

I did not want to give up after the first problem :-) and decide to try dspmp4venc instead of dsph264enc. Unfortunately it also does not work. The pipeline runs for several seconds producing correct video file, but then just stopped on it's own. The following is the complete output:

GST_DEBUG=2 gst-launch v4l2src do-timestamp=true always-copy=FALSE !
video/x-raw-yuv,width=320,height=240,framerate=25/1 ! ffmpegcolorspace
! video/x-raw-yuv,format=\(fourcc\)UYVY ! dspmp4venc ! avimux !
filesink location="ttt.avi"
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
0:00:01.380645752  1693  0x1285d50 WARN                     bin
gstbin.c:2380:gst_bin_do_latency_func:<pipeline0> did not really
configure latency of 0:00:00.000000000
dsp_thread: failed waiting for events: 5
0:00:08.119049071  1693  0x1267ba8 ERROR                    dsp
gstdspbase.c:645:dsp_thread:<dspmp4venc0> failed waiting for events: 5
gstdsp_got_error: unable to get event
0:00:08.121093749  1693  0x1267ba8 ERROR                    dsp
gstdspbase.c:614:gstdsp_got_error:<dspmp4venc0> unable to get event
ERROR: from element /GstPipeline:pipeline0/GstDspMp4VEnc:dspmp4venc0:
unable to get event
Execution ended after 7152709961 ns.
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

In the dmesg I can see the following:
[ 5298.419525] omap-dsp omap-dsp: bridge_deh_notify: DSP_MMUFAULT,
addr=0x21f3e000
[ 5298.486724] omap-dsp omap-dsp: ERR: clock id 2 already disabled
[ 5298.602966] proc_load: Processor Loaded /lib/dsp/baseimage.dof
[ 5298.615417] proc_start: dsp in running state

So here again I would kindly appreciate any hints how to fix or debug the problem. I would prefer to use h264 for my project, but can also leave with mp4 and will appreciate any help.

Thank you,
Andrey.

[Andrey]

Sorry guys for duplicated posts. I did not realize that each post should be approved by moderator and decide to resend.

[Víctor M. Jáquez L.]

The script [1] is a bit obsolete: it's using master and the executed
compilation is for release 0.9. It doesn't work for 0.10.x

Recompile gst-dsp with the variable DSP_API set to 1 (look at the configure script
in the gst-dsp code). By default DSP_API is set to 2, but it doesn't work, at
least for me, and I see the same errors as you [2].

vmjl

1. https://raw.github.com/RobertCNelson/stable-kernel/master/create_dsp_package.sh
2. https://groups.google.com/group/gst-dsp/browse_thread/thread/aaaa225d114c069d

[Andrey]

Thanks Víctor for the explanations!

> Recompile gst-dsp with the variable DSP_API set to 1 (look at the configure script

As I understand from the thread you referenced, it will disable DMA.
Will it than also have a performance impact? If yes, could you roughly
estimate it?

Thanks!
Andrey.

[Felipe Contreras]

On Sun, Feb 5, 2012 at 11:32 PM, Andrey <andre...@googlemail.com> wrote:
> Sorry guys for duplicated posts. I did not realize that each post should be
> approved by moderator and decide to resend.

Not if you subscribe.

--
Felipe Contreras

[Felipe Contreras]

No, the DMA operations are the same, the only difference is that in
newer versions of the kernel driver new ioctls were added to be more
proper, and the old ones are mere wrappers with a hack to allow them
to run.

Cheers.

--
Felipe Contreras

[Felipe Contreras]

Can you try this?

--- a/dmm_buffer.h
+++ b/dmm_buffer.h
@@ -91,9 +91,9 @@ dmm_buffer_begin(dmm_buffer_t *b,
if (b->dma_len == (size_t) -1)
return;
if (dsp_begin_dma(b->handle, b->proc, b->data, len, b->dir))
- b->dma_len = (size_t) -1;
- else
b->dma_len = len;
+ else
+ b->dma_len = (size_t) -1;
#endif
}

--
Felipe Contreras

[Víctor M. Jáquez L.]

On Wed, Feb 08, 2012 at 01:25:44PM +0200, Felipe Contreras wrote:
> On Mon, Feb 6, 2012 at 2:21 PM, Felipe Contreras
> <felipe.c...@gmail.com> wrote:
> > On Mon, Feb 6, 2012 at 10:43 AM, Andrey <andre...@googlemail.com> wrote:
> >>

> >> Thanks V�ctor for the explanations!

> >>
> >>
> >>> Recompile gst-dsp with the variable DSP_API set to 1 (look at the configure script
> >>
> >> As I understand from the thread you referenced, it will disable DMA.
> >> Will it than also have a performance impact? If yes, could you roughly
> >> estimate it?
> >
> > No, the DMA operations are the same, the only difference is that in
> > newer versions of the kernel driver new ioctls were added to be more
> > proper, and the old ones are mere wrappers with a hack to allow them
> > to run.
>
> Can you try this?
>
> --- a/dmm_buffer.h
> +++ b/dmm_buffer.h
> @@ -91,9 +91,9 @@ dmm_buffer_begin(dmm_buffer_t *b,
> if (b->dma_len == (size_t) -1)
> return;
> if (dsp_begin_dma(b->handle, b->proc, b->data, len, b->dir))
> - b->dma_len = (size_t) -1;
> - else
> b->dma_len = len;
> + else
> + b->dma_len = (size_t) -1;
> #endif
> }

gggrrr... I'll almost nailed it last night! Just I was too tired I went to
bed. Well, at least I learned how to use the debugfs and the dynamic debug.

Tonight I'll test this patch...

vmjl

[Víctor M. Jáquez L.]

On Wed, Feb 08, 2012 at 01:25:44PM +0200, Felipe Contreras wrote:
> On Mon, Feb 6, 2012 at 2:21 PM, Felipe Contreras
> <felipe.c...@gmail.com> wrote:
> > On Mon, Feb 6, 2012 at 10:43 AM, Andrey <andre...@googlemail.com> wrote:
> >>

> >> Thanks V�ctor for the explanations!

> >>
> >>
> >>> Recompile gst-dsp with the variable DSP_API set to 1 (look at the configure script
> >>
> >> As I understand from the thread you referenced, it will disable DMA.
> >> Will it than also have a performance impact? If yes, could you roughly
> >> estimate it?
> >
> > No, the DMA operations are the same, the only difference is that in
> > newer versions of the kernel driver new ioctls were added to be more
> > proper, and the old ones are mere wrappers with a hack to allow them
> > to run.
>
> Can you try this?
>
> --- a/dmm_buffer.h
> +++ b/dmm_buffer.h
> @@ -91,9 +91,9 @@ dmm_buffer_begin(dmm_buffer_t *b,
> if (b->dma_len == (size_t) -1)
> return;
> if (dsp_begin_dma(b->handle, b->proc, b->data, len, b->dir))
> - b->dma_len = (size_t) -1;
> - else
> b->dma_len = len;
> + else
> + b->dma_len = (size_t) -1;
> #endif
> }

Yep. Now it works in my simple tests.

vmjl