From: Peter N. <pet...@df...> - 2011-03-24 13:44:23
|
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 |
From: Tuomas K. <tu...@ku...> - 2011-03-24 17:21:28
|
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 |
From: neno <ne...@ne...> - 2011-03-25 16:49:55
|
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. |
From: Tuomas K. <tu...@ku...> - 2011-03-25 17:29:19
|
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 |
From: neno <ne...@ne...> - 2011-03-25 18:09:43
|
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. |
From: Peter N. <pet...@df...> - 2011-03-29 14:06:02
|
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 <ne...@ne...> 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 > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Tuomas K. <tu...@ku...> - 2011-03-29 14:15:01
|
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 |
From: Peter N. <pet...@df...> - 2011-03-29 15:38:30
|
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 <tu...@ku...> 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 > |
From: Tuomas K. <tu...@ku...> - 2011-03-29 15:46:14
|
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 |
From: Peter N. <pet...@df...> - 2011-04-01 12:38:40
|
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 <tu...@ku...> 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 > |
From: Tuomas K. <tu...@ku...> - 2011-04-01 21:20:21
|
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 |
From: Peter N. <pet...@df...> - 2011-04-04 16:10:56
|
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 <tu...@ku...> 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 > |
From: Tuomas K. <tu...@ku...> - 2011-04-04 17:13:09
|
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 |
From: Peter N. <pet...@df...> - 2011-04-05 08:14:46
|
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 <tu...@ku...> 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 > |
From: Tuomas K. <tu...@ku...> - 2011-04-05 08:39:36
|
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 |
From: Peter N. <pet...@df...> - 2011-04-05 11:55:40
|
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 <tu...@ku...> 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 > |
From: Tuomas K. <tu...@ku...> - 2011-04-05 12:33:26
|
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 |