There's a new demo image + kernel available from http://angstrom-distribution.org/demo/beagleboard/
It now includes *all* the things needed to get gstreamer to use the
DSP for decoding audio and video using the infrastructure from
gstreamer.ti.com.
As you can see in http://www.youtube.com/watch?v=pcdaosTiWPI there is
a TI watermark in the video, this is because only evaluation codecs
can be distributed, but nothing is stopping you from using the
production codecs from the dvsdk.
regards,
Koen
I showed this to a coworker and he said "It's just like a tiny Linux box!"
...yes, it is.
Beautiful package Koen.
Thanks,
- dan
Indeed - Nice work - I unfortunately can't make the gstreamer DSP link
working => It's hard to see the great improvement - I hope somebody can help
me forward :-)
I'm unfortunately still pretty new to gstreamer and Linux multimedia in
general...
In order for anybody to tell me what I'm doing wrong, I will therefore here
try to sketch what I did:
1) Download the binaries from:
http://angstrom-distribution.org/demo/beagleboard/
2) Copy u-boot, MLO and uImage to the MMC FAT partition
3) Extract the file system image to the EXT partition
4) Boot into uboot and set environment using the serial connection like:
a) setenv bootargs 'console=ttyS2,115200n8 console=tty0 root=/dev/mmcblk0p2
rw rootfstype=ext3 rootwait omapfb.video_mode=640x480MR-16@60 mem=104M'
b) setenv bootcmd 'mmcinit; fatload mmc 0 0x80300000 uImage; bootm
0x80300000'
c) saveenv
5) Restart board and connect HUB with mouse and keyboard
6) Boot into the X-environment - Shows nicely over DVI
7) Start a terminal and enter the following:
a) su
b) modprobe cmemk phys_start=0x88000000 phys_end=0x89000000
pools=20x4096,8x131072,5x1048576,1x1429440,1x256000,1x5250000,3x829440
c) modprobe dsplinkk
d) modprobe lpm_omap3530
e) cd /usr/share/ti-codec-combos
8) Try to playback the BigBuckBunny.m4v file like:
a) gst-launch filesrc location=/data/movies/BigBuckBunny_640x360.m4v !
qtdemux name=demux demux.video_00 ! TIViddec2 ! xvimagesink
=>
The gstreamer complains about:
"Failed to load plugin ... libstrsubparse.so"
and stops with the comment
"Pipeline is PREROLLING ..."
I can stop(kill gstreamer by pressing CTRL+C and I get the same result even
though I run it several times. Anybody having any idea, what I'm doing
wrong? Or anybody having any ideas of what to try? Or what worked for them?
Any kind of link will be highly appreciated :-)
Best regards and thanks in advance
Søren
PS: I'm running on a B5 board, but I don't think that's important...
Could you try:
env | grep DISPLAY
to see if the DISPLAY var is set? It should be :0 (that's not a
smiley, but a colon and a zero)
regards,
Koen
Forgot to mention in my previous post:
Step 7f) export DISPLAY=:0
- Display variable was/is therefore set
/ Søren
Forgot to mention in my previous post:
Step 7f) export DISPLAY=:0
- Display variable was/is therefore set
/ Søren
I just gave it another try, with nearly identical result, although new a little different:
1) Boot the system as described in previous post
2) gst-launch -v videotestsrc ! xvimagesink
Output: “X Error of failed request: BadAtom (invalid Atom parameter)”
3) gst-launch -v videotestsrc ! xvimagesink
Output: This time the color bar test image is output on the DVI display as expected
4) gst-launch filesrc location=/test/BigBuckBunny_640x360.m4v ! qtdemux name=demux.video_00 ! TIViddec2 ! xvimagesink
Output:
(gst-launch-0.10:1756): GStreamer-WARNING **: Failed to load plugin '/usr/lib/gstreamer-0.10/libgstsubparse.so': /usr/lib/gstreamer-0.10/libgstsubparse.so: undefined symbol: parse_sami
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Unhandled fault: external abort on non-linefetch (0x1818) at 0x43274000
Bus error
5) gst-launch filesrc location=/test/BigBuckBunny_640x360.m4v ! qtdemux name=demux.video_00 ! TIViddec2 ! xvimagesink
Output:
(gst-launch-0.10:1767): GStreamer-WARNING **: Failed to load plugin '/usr/lib/gstreamer-0.10/libgstsubparse.so': /usr/lib/gstreamer-0.10/libgstsubparse.so: undefined symbol: parse_sami
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 53253178 ns.
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
FREEING pipeline ...
6) gst-launch filesrc location=/test/BigBuckBunny_640x360.m4v ! qtdemux name=demux.video_00 ! TIViddec2 ! xvimagesink
Output:
(gst-launch-0.10:1767): GStreamer-WARNING **: Failed to load plugin '/usr/lib/gstreamer-0.10/libgstsubparse.so': /usr/lib/gstreamer-0.10/libgstsubparse.so: undefined symbol: parse_sami
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
HANGING, but can be canceled by hitting CTRL+C
Steps 6 repeats over and over again in case the commend is tried again
I have no problem playing the file using mplayer, so the file is definitely OK.
Does the above log ring any bells at anyone?
Is the GStreamer-WARNING also “supposed” to occur when the playback is working?
Best regards and thanks again
Søren
> After taking a closer look, the phys_start address in my original command
> was 0x88000000, which is the exact end of the SDRAM - This new value is
this one works only on 256MB revC
> within the 128MB limit:-)... That being said, I tried to change the limit to
> 104M (by setting phys_start=0x86800000, phys_end=0x87800000 and changing
> mem=104M in bootargs) - This however didn't seem to work - Is this as
> expected?
Yes, there is not only CMEM but also CE that needs some memory up there,
so you cannot move CMEM without reducing the CE mem.
We downloaded the demo image and kernel (2.6.28-r17) from the URL
below. We are able to decode video, but it only runs for 5-10 seconds
before we get kernel panics. Sometimes we are seeing reports of MMC
card errors (transfer data errors, etc.).
We might have some bad cards, so we're going to get new ones.
We have tried a 2.6.27-20 we built with the dsplink from codec engine
2.21. We are also seeing video playback for 5-10 seconds before
kernel panics in MMC. Same as with the above.
We also used CIFS with our 2.6.27-20 kernel to mount files over the
network and play, but then we saw kernel panics in the kernel power
management driver (omap3_pm_idle function).
Any thoughts?
Regards,
Peter
P.S. Youtube is blocked again over here in China, so we aren't able to
see your video :( But we believe it can work!
Hi Oscar,
I think I ran into this problems as well - You need to cd into the TI codec
catalog
"cd /usr/share/ti-codec-combos" before trying to play the video (i.e. as
step 5½)
Other than that I think you have all the details I needed to get it up
running...
Best regards - Good luck
Søren
>
>
That should be fixed with the current gstreamer plugins in the
angstrom feeds (opkg update ; opkg install gstreamer-ti). The patch
that was used for that: http://patchwork.openembedded.org/patch/263/
regards,
Koen
I didn't have any more time for debugging it, and since I basically only
needed the graphics for fun (wanted to see the great work Koen and all the
others did in order to get this running), I didn't care that much. I think I
read on the mailing list somewhere that there were some MMC patches fixing
this issue, but I didn't try them myself - yet.
Hopefully somebody else on the list can comment
Søren
The patch I was thinking about was the one for the MMC -110 error.
I don't know if the errors are related and/or if this patch fixes the -84
problems as well, but in case you haven't it included already I would
recommend you to give it a try - See as well the discussion on the list of
SDHC errors from the 8th of April...
Best regards - See you
Søren
I do unfortunately not remember what we discussed in this thread, but all my
testing with respect to this have for sure been done on a rev B5 board =>
It's possible :-)
Good luck
Søren
Yes, I am getting the same with the latest image. It appears that the
problem is related to network load - ie if I try to download say a
movie file or do a git update then the Ethernet connection will likely
die very quickly (within minutes). But If I bring up the network but
don't specifically use any userland apps that would tax the network,
the Ethernet will stay up for hours before failing.
Ifconfig or /etc/init.d/networking stop, start doesn't resolve the
problem but a reset without physically removing the power will make
the problem go away again for a time.
I'm also seeing a kernel hang when plugging in the DVI lead while the
OS is running, and a problem whereby USB hot-plug doesn't work (only
usb devices seen at power on are fully initialised / work - unplugging
and then plugging the device in again results in a device that isn't
fully recognised / re-initialised). Finally, there appears to be a
memory leak in my OS that causes the beagleboard to run out of memory
after a few days. I don't think any of these are related to the
Ethernet problem - just mentioning them in case others are
experiencing any of the same.
--
Michael