gumstix

On 03/24/2011 03:43 PM, Peter Nemeth wrote:
> Dear All,
>
> I now have a stable running system - Gumstix Fire + E-con camera /
> Tobi expansion board / Debian. I have already managed to compile the
> DSP bridge module, and it can be inserted to the kernel without any
> problems. What other steps need to be taken for gstreamer to work with
> the DSP properly? Is there any step-by-step installation thread
> available somewhere? I haven't seen any good documentation for this
> before, just understood some fragments as I might need cmem module,
> and adjusting memory usage at U-boot. What exactly needs to be done?

I haven't found any good docs about the whole dsp+gst stack. And things 
seems to be changing quite frequently so the docs would be at least 
partly obsoleted soon. I got my stuff working thanks to Felipe 
Contreras, the author of e.g. gst-dsp, who helped me quite a bit.

There's no need to limit the kernel memory usage with the "mem" bootarg, 
haven't been for a couple of years anymore. At least so I'm told.

You need to get the DSP binaries from 
http://code.google.com/p/gst-dsp/downloads/list and extract the binaries 
to "/lib/dsp". To my understanding the licence allows redistribution of 
those files but companies are afraid of patents (e.g. related to h264) 
so those files won't be easily integrated to repositories.

I don't have "cmem" module loaded.

Loading bridgedriver in my environment loads "mailbox" driver 
automatically but not "mailbox_mach" which is also needed.

I created "/etc/modprobe.d/bridgedriver.conf" with the following lines:
--- clip ---
softdep bridgedriver pre: mailbox_mach
options bridgedriver base_img=/lib/dsp/baseimage.dof
--- clip ---

But it seems that the modprobe in my MeeGo environment doesn't 
understand the "softdep" so I manually load the "mailbox_mach" module in 
the startup scripts.

The code.google.com url includes also "dsp-tools" package that can be 
nicely cross compiled without any ARM rootfs so the tools in there can 
be used for first DSP tests. At least "dsp-test" should pass OK.

For the video encoding I use the gst-dsp. MeeGo provides a bit older(?) 
version of the gst-dsp than Felipe on that google code site. I would 
guess that the newer versions would work at least as well as the MeeGo 
version but I don't know if your Debian environment has new enough 
GStreamer for gst-dsp. Propably, if you are using Squeeze.

I guess this is the simplest GST DSP test case:

gst-launch-0.10 -v videotestsrc ! dspdummy ! fakesink

This would test mp4 encoding and decoding:

gst-launch-0.10 -v videotestsrc ! dspmp4venc ! dspvdec ! fakesink


And this is what I use for sending the encoded stream from my Overo to 
my PC over WLAN (it's not supposed to take everything out of the DSP):

gst-launch-0.10 -v v4l2src  ! "video/x-raw-yuv, width=(int)352, 
height=(int)288, framerate=(fraction)10/1" ! ffmpegcolorspace ! 
dsph263enc mode=1 ! rtph263pay ! udpsink sync=false host=XXX.XXX.X.X 
port=12345

The exact resolutions and the framerate is a bit related to the 
capabilities of the camera. It seems that my cheap webcam is quite picky 
about the combinations of those. And I guess the ffmpegcolorspace 
conversion is not necessarily needed, if the camera happens to provide 
the same raw YUV format than what the dsph263enc needs.

-- 
Tuomas

This has already been explained on this forum. All the packages you need are
already in the tree. Can't give you a step by step but search the forum for
gst packages, gstreamer-ti, and ti-dsplink-module. You need at least
dsplinkk and lpm_omap3530 drivers. Also, google gstreamer ti pluggins. 

Neno


Peter Nemeth wrote:
> 
> Dear All,
> 
> I now have a stable running system - Gumstix Fire + E-con camera /
> Tobi expansion board / Debian. I have already managed to compile the
> DSP bridge module, and it can be inserted to the kernel without any
> problems. What other steps need to be taken for gstreamer to work with
> the DSP properly? Is there any step-by-step installation thread
> available somewhere? I haven't seen any good documentation for this
> before, just understood some fragments as I might need cmem module,
> and adjusting memory usage at U-boot. What exactly needs to be done?
> 
> Thank you,
> 
> Peter
> 

-- 
View this message in context: http://old.nabble.com/Setting-up-DSP-gstreamer-on-Gumstix-Fire---Debian--tp31229025p31239833.html
Sent from the Gumstix mailing list archive at Nabble.com.

On 25.3.2011 18:49, neno wrote:
>
> This has already been explained on this forum. All the packages you need are
> already in the tree. Can't give you a step by step but search the forum for
> gst packages, gstreamer-ti, and ti-dsplink-module. You need at least
> dsplinkk and lpm_omap3530 drivers. Also, google gstreamer ti pluggins.

Well, he was talking about the DSP bridge not the DSP link but I guess 
the difference could have been stated in the first place.

TI provides two different DSP implementations. One is DSP bridge and one 
is DSP link. E.g. OpenEmbedded uses the DSP link and I guess because of 
that it seems to be more used in the open source communities. I've got 
used to DSP bridge at work and that's why I'm using it (and e.g. n900 
uses it). Also I think the DSP brigde has OpenMAX implementation and DSP 
link does not (at least it didn't used to have it).

And he's talking about Debian. What tree provides DSP link for Debian?

Thanks,
-- 
Tuomas

I was talking about overo angstrom build tree. 

I assumed Debian was his desktop distribution so he didn't need DSPlink for
it.



 
-- 
View this message in context: http://old.nabble.com/Setting-up-DSP-gstreamer-on-Gumstix-Fire---Debian--tp31229025p31240532.html
Sent from the Gumstix mailing list archive at Nabble.com.

Dear Tuomas,

What are you using on the host PC side to open the video stream? If gstream
as well, could you let me know the parameters you're using it with? If any
other software then what? I've been trying several players and parameters,
but did not manage to open the stream sent from the Gumstix.

Thanks,

Peter

On Fri, Mar 25, 2011 at 7:09 PM, neno <neno@...> wrote:

>
> I was talking about overo angstrom build tree.
>
> I assumed Debian was his desktop distribution so he didn't need DSPlink for
> it.
>
>
>
>
> --
> View this message in context:
> http://old.nabble.com/Setting-up-DSP-gstreamer-on-Gumstix-Fire---Debian--tp31229025p31240532.html
> Sent from the Gumstix mailing list archive at Nabble.com.
>
>
>
> ------------------------------------------------------------------------------
> Enable your software for Intel(R) Active Management Technology to meet the
> growing manageability and security demands of your customers. Businesses
> are taking advantage of Intel(R) vPro (TM) technology - will your software
> be a part of the solution? Download the Intel(R) Manageability Checker
> today! http://p.sf.net/sfu/intel-dev2devmar
> _______________________________________________
> gumstix-users mailing list
> gumstix-users@...
> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>

On 03/29/2011 05:05 PM, Peter Nemeth wrote:
> Dear Tuomas,
>
> What are you using on the host PC side to open the video stream? If gstream
> as well, could you let me know the parameters you're using it with? If any
> other software then what? I've been trying several players and parameters,
> but did not manage to open the stream sent from the Gumstix.

In my project the applications are written in Qt and I use the GStreamer 
API directly from there in both ends. I have my own UDP protocol and the 
GStreamer RTP stream is transferred there as one type of a payload.

Here are the gst-launch commands I've used for testing:

gst-launch-0.10 -v v4l2src  ! "video/x-raw-yuv, width=(int)352, 
height=(int)288, framerate=(fraction)10/1" ! ffmpegcolorspace ! 
dsph263enc mode=1 ! rtph263pay ! udpsink sync=false host=192.168.XXX.XXX 
port=12345

gst-launch-0.10 -v udpsrc port=12345 ! capsfilter 
caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, 
encoding-name=(string)H263, payload=(int)96, framerate=(fraction)10/1" ! 
rtph263depay ! ffdec_h263 ! xvimagesink sync=false


-- 
Tuomas

Strangely, but this doesnt work for me. The Gumstix seems to be sending the
data, and the host PC finds the stream, and identifies it correctly, but no
windows pop up with the video and "nothing" happens. Any ideas why this
could be? Is there an even simpler test case to try it with?

Thanks a lot,

Peter

On Tue, Mar 29, 2011 at 4:14 PM, Tuomas Kulve <tuomas@...> wrote:

> On 03/29/2011 05:05 PM, Peter Nemeth wrote:
>
>> Dear Tuomas,
>>
>> What are you using on the host PC side to open the video stream? If
>> gstream
>> as well, could you let me know the parameters you're using it with? If any
>> other software then what? I've been trying several players and parameters,
>> but did not manage to open the stream sent from the Gumstix.
>>
>
> In my project the applications are written in Qt and I use the GStreamer
> API directly from there in both ends. I have my own UDP protocol and the
> GStreamer RTP stream is transferred there as one type of a payload.
>
> Here are the gst-launch commands I've used for testing:
>
> gst-launch-0.10 -v v4l2src  ! "video/x-raw-yuv, width=(int)352,
> height=(int)288, framerate=(fraction)10/1" ! ffmpegcolorspace ! dsph263enc
> mode=1 ! rtph263pay ! udpsink sync=false host=192.168.XXX.XXX port=12345
>
> gst-launch-0.10 -v udpsrc port=12345 ! capsfilter caps="application/x-rtp,
> media=(string)video, clock-rate=(int)90000, encoding-name=(string)H263,
> payload=(int)96, framerate=(fraction)10/1" ! rtph263depay ! ffdec_h263 !
> xvimagesink sync=false
>
>
> --
> Tuomas
>

On 03/29/2011 06:37 PM, Peter Nemeth wrote:
> Strangely, but this doesnt work for me. The Gumstix seems to be sending the
> data, and the host PC finds the stream, and identifies it correctly, but no
> windows pop up with the video and "nothing" happens. Any ideas why this
> could be? Is there an even simpler test case to try it with?

I had a similar problem which I managed to solve by switching from 
autovideosink to xvimagesink and passing the sync=false option to it. 
But that's already in that gst-launch sequence I sent.

You can try "videotestsrc" instead of the v4l2src but that's not that 
different or simpler use case..


-- 
Tuomas

No matter how I modify it, the stream doesnt open (I'm using
ximagesink btw, xvimagesink doesnt work for me). However, I can use a
filesink for some reason and save the stream.

Also, dspjpegenc doesnt work at all, keeps giving

"create_node: dsp node create failed
sink_setcaps: dsp node creation failed
ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
Internal data flow error"

two of the gst lines i used were:

gst-launch-0.10 -v v4l2src  ! "video/x-raw-yuv, width=(int)640,
height=(int)480, framerate=(fraction)10/1" ! ffmpegcolorspace !
dspjpegenc mode=1 !  filesink location=file1.jpg
gst-launch-0.10 -v v4l2src  ! "video/x-raw-yuv, width=(int)640,
height=(int)480, framerate=(fraction)10/1" ! dspjpegenc ! filesink
location=file1.jpg

caps are okay, i can use this setting to save video with dspmp4venc.

Any ideas?

Thanks,

Peter


On Tue, Mar 29, 2011 at 5:46 PM, Tuomas Kulve <tuomas@...> wrote:
> On 03/29/2011 06:37 PM, Peter Nemeth wrote:
>>
>> Strangely, but this doesnt work for me. The Gumstix seems to be sending
>> the
>> data, and the host PC finds the stream, and identifies it correctly, but
>> no
>> windows pop up with the video and "nothing" happens. Any ideas why this
>> could be? Is there an even simpler test case to try it with?
>
> I had a similar problem which I managed to solve by switching from
> autovideosink to xvimagesink and passing the sync=false option to it. But
> that's already in that gst-launch sequence I sent.
>
> You can try "videotestsrc" instead of the v4l2src but that's not that
> different or simpler use case..
>
>
> --
> Tuomas
>

On 04/01/2011 03:38 PM, Peter Nemeth wrote:
> No matter how I modify it, the stream doesnt open (I'm using
> ximagesink btw, xvimagesink doesnt work for me). However, I can use a
> filesink for some reason and save the stream.

I actually remembered my problems a bit wrong. The sync thing was about 
the dropped frames, not the missing window and I can't remember what I 
did to fix/workaround that one.

Somebody on the list was complaining about similar issue when opening 
first the sender and later the receiver and for him it worked when he 
tried in another order. I assume you have tried that one already. For me 
currently both orders work.

Why the xvimagesink is not working, what's the actual error? You don't 
have an XV capable environment?

-- 
Tuomas

Yeah, I believe so, but I'm not sure. Where do I see that?

And gst-inspect does not show xvimagesink, even though all plugins are
installed (not from source, but through aptitude).


On Fri, Apr 1, 2011 at 11:19 PM, Tuomas Kulve <tuomas@...> wrote:
> On 04/01/2011 03:38 PM, Peter Nemeth wrote:
>>
>> No matter how I modify it, the stream doesnt open (I'm using
>> ximagesink btw, xvimagesink doesnt work for me). However, I can use a
>> filesink for some reason and save the stream.
>
> I actually remembered my problems a bit wrong. The sync thing was about the
> dropped frames, not the missing window and I can't remember what I did to
> fix/workaround that one.
>
> Somebody on the list was complaining about similar issue when opening first
> the sender and later the receiver and for him it worked when he tried in
> another order. I assume you have tried that one already. For me currently
> both orders work.
>
> Why the xvimagesink is not working, what's the actual error? You don't have
> an XV capable environment?
>
> --
> Tuomas
>

In Debian, the GStreamer's xvimagesink plugin is provided in a package 
called gstreamer0.10-x and it's there even in the armel distro:

http://packages.debian.org/squeeze/armel/gstreamer0.10-x/filelist

Are you actually running that on the ARM device or on a PC? On PC you 
should have that but on ARM you need to have XV capable X.Org driver 
(like omapfb). On my PC, e.g. "xvinfo" shows that I have XV capable 
X.Org running:

~$ xvinfo
X-Video Extension version 2.2
screen #0
   Adaptor #0: "NV17 Video Texture"


GStreamer maintains a registry file in ~/.gstreamer-0.10/. You can 
delete that, run gst-inspect without parameters and try to see if it 
complains something about the xvimagesink.


-- 
Tuomas

I only need it on the desktop PC which is running Ubuntu 10.10. The
Gumstix board doesnt have a screen attached, so I guess omapfb is
redundant.

I have the same output for xvinfo as you, and the gstreamer0.10-x
installed, yet I only have ximagesink and no xvimagesink.

Tried deleting the registry file, but didnt make a difference.

Any other ideas?

Thanks,

Peter

On Mon, Apr 4, 2011 at 7:12 PM, Tuomas Kulve <tuomas@...> wrote:
>
> In Debian, the GStreamer's xvimagesink plugin is provided in a package
> called gstreamer0.10-x and it's there even in the armel distro:
>
> http://packages.debian.org/squeeze/armel/gstreamer0.10-x/filelist
>
> Are you actually running that on the ARM device or on a PC? On PC you should
> have that but on ARM you need to have XV capable X.Org driver (like omapfb).
> On my PC, e.g. "xvinfo" shows that I have XV capable X.Org running:
>
> ~$ xvinfo
> X-Video Extension version 2.2
> screen #0
>  Adaptor #0: "NV17 Video Texture"
>
>
> GStreamer maintains a registry file in ~/.gstreamer-0.10/. You can delete
> that, run gst-inspect without parameters and try to see if it complains
> something about the xvimagesink.
>
>
> --
> Tuomas
>

On 04/05/2011 11:14 AM, Peter Nemeth wrote:
> Any other ideas?

It might not help at all to debug the xvimagesink issue because that 
might not have anything to do with your actual problem but for that one 
I don't have any more hints.

Do you have /usr/lib/gstreamer-0.10/libgstxvimagesink.so in your Ubuntu 
10.10? I'm running that as well and "gst-launch videotestsrc ! 
xvimagesink" is probably to easiest way to test the XV.

gst-inspect can also tell something by giving the plugin name directly:

gst-inspect-0.10 /usr/lib/gstreamer-0.10/libgstxvimagesink.so

-- 
Tuomas

Well might not, but it would be cool to see one less problem :)

I actually have the file /usr/lib/gstreamer-0.10/libgstxvimagesink.so . However,

$ gst-launch videotestsrc ! xvimagesink
WARNING: erroneous pipeline: no element "xvimagesink"
$ gst-inspect | grep xvimagesink
$
$ gst-inspect /usr/lib/gstreamer-0.10/libgstxvimagesink.so
Plugin Details:
  Name:			xvimagesink
  Description:		XFree86 video output plugin using Xv extension
  Filename:		/usr/lib/gstreamer-0.10/libgstxvimagesink.so
  Version:		0.10.30
  License:		LGPL
  Source module:	gst-plugins-base
  Binary package:	GStreamer Base Plugins (Ubuntu)
  Origin URL:		https://launchpad.net/distros/ubuntu/+source/gst-plugins-base0.10

  xvimagesink: Video sink

  1 features:
  +-- 1 element


So it seems it's there and recognized, yet I cannot use it as a sink,
and not shown by gst-inspect either. Why could this be?

Thanks,

Peter


On Tue, Apr 5, 2011 at 10:39 AM, Tuomas Kulve <tuomas@...> wrote:
> On 04/05/2011 11:14 AM, Peter Nemeth wrote:
>>
>> Any other ideas?
>
> It might not help at all to debug the xvimagesink issue because that might
> not have anything to do with your actual problem but for that one I don't
> have any more hints.
>
> Do you have /usr/lib/gstreamer-0.10/libgstxvimagesink.so in your Ubuntu
> 10.10? I'm running that as well and "gst-launch videotestsrc ! xvimagesink"
> is probably to easiest way to test the XV.
>
> gst-inspect can also tell something by giving the plugin name directly:
>
> gst-inspect-0.10 /usr/lib/gstreamer-0.10/libgstxvimagesink.so
>
> --
> Tuomas
>

On 04/05/2011 02:55 PM, Peter Nemeth wrote:

> So it seems it's there and recognized, yet I cannot use it as a sink,
> and not shown by gst-inspect either. Why could this be?

It's ignored for some reason. When destroying the 
$(HOME)/.gstreamer-0.10/registry.x86_64.bin file from the right user and 
running just "gst-inspect" it should print warnings or errors when 
finding issues with some plugins. The errors could be there in between 
the plugins list, so be careful when reading the output through.

I removed one dependency library and this is what I get before the long 
list of plugins:

(gst-plugin-scanner:11415): GStreamer-WARNING **: Failed to load plugin 
'/usr/lib/gstreamer-0.10/libgstxvimagesink.so': libXv.so.1: cannot open 
shared object file: No such file or directory

If it really doesn't complain anything about the plugin then I don't 
know why it's not shown in the list. If there's something wrong with the 
XV support, then it should so in the list but fail when used.

-- 
Tuomas