GStreamer on TI's embedded platform

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Vijay,
 
I think maybe you miss a mp3demuxe between filesrc and adecoder.
and the command shall be 
gst-launch-0.10 filesrc location=$1 ! mp3demux ! adecoder Codec=3 !
osssink
TI adecoder element may not accept the filesrc RAW caps.

Best Regards
Zhao Liang 


________________________________

From: gstreamer-embedded-bounces at lists.sourceforge.net
[mailto:gstreamer-embedded-bounces at lists.sourceforge.net] On Behalf Of
Vijay
Sent: Monday, April 07, 2008 8:32 PM
To: gstreamer-embedded at lists.sourceforge.net
Subject: GStreamer on TI's embedded platform


Hi,
I received TI's port of gstreamer to it's DaVinci processors from
http://focus.ti.com/dsp/docs/dspsplash.tsp?contentId=3100
 
I've tried to run the example (scripts) provided by TI and I've faced
what seem to be two separate issues.
I've copied the stdout log below:
 
<linux prompt>:/opt/system_files_gstreamer# ./test_MP3.sh MP3_file.mp3
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
(gst-launch-0.10:1204): GStreamer-WARNING **: pad adecoder0:src returned
caps which are not a real subset of its template caps
(gst-launch-0.10:1204): GStreamer-CRITICAL **: gst_caps_get_structure:
assertion `index < caps->structs->len' failed
(gst-launch-0.10:1204): GStreamer-CRITICAL **: gst_structure_get_int:
assertion `structure != NULL' failed

[program hangs here]
 
For most of you, who don't know about this script: All it does is after
setting the gstreamer, plugin and library paths, it runs gst-launch with
a pipeline, thus: gst-launch-0.10 filesrc location=$1 ! adecoder Codec=3
! osssink

The two issues I'm facing:
(a) The *last* element in the gstreamer pipeline does not reply with a
message to the app saying it has paused (This is ascertained with debug
prints that I inserted in gst-launch.c. It's possible that for some
reason, the element does not pause. I've faced this same issue with
pipelines which have no decode/render elements as well.) Actually, I'm
not sure if (a) it doesn't pause because it doesn't finish preroll or
(b) it says it hasn't finished preroll because it doesn't send a pause
signal! (I'm not sure which is the cause and which is the effect).

(b) The critical errors printed (seen above. I guess these are caused
because of TI's mp3 decoder element plugin.) Could the adecoder
capabilities be incompatible? Seems unlikely, since TI would have tested
this first.


Would anyone know what the issue might be? Has anyone seen a similar
issue with gstreamer?
I'd greatly appreciate any help.
Thanks.


Vijay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-embedded/attachments/20080408/50af515b/attachment.htm>


[Index of Archives]     [Linux Embedded]     [Linux ARM Kernel]     [Linux for ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux Media]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux