Re: [gst-embedded] GStreamer on TI's embedded platform

[Zhao Liang-E. <E3...@mo...>]

Vijay,
 
I think you can open the log for more information,
export GST_DEBUG=GST_CAPS:5
 
Seems actual adecoder src0 caps is not a subset of src template caps,
maybe the src rate, channels, or depth is not suitable for template
caps.
 

Best Regards
Zhao Liang


________________________________

From: Vijay [mailto:vij...@gm...] 
Sent: Thursday, April 10, 2008 9:38 PM
To: Zhao Liang-E3423C
Cc: gst...@li...
Subject: Re: [gst-embedded] GStreamer on TI's embedded platform


Thanks for your response, Zhao. I really appreciate it. I didn't get a
chance to respond to your mail until now.
 
I don't think I'm missing a mp3 demux element. Here's why:

 - This file has worked with every decoder I've tried, without any
demuxing or parsing of container format (and I've tried a lot of
decoders on a lot of systems! - all without any demuxing)
 - It has no ID3 or other tags (I removed all such MP3 headers and
trailers in the file, myself)
 - It has only an elementary stream that contains only MP3 frames (each
frame starting with "0xFF 0xFB"), all of the same length.
That means, this file should not require a MP3 parser and any MP3
decoder should be able to decode the contents of the file directly.
Plus, this pipeline comes from Texas Instruments, and they must have
tested this before they put it on their website (hopefully)!
 
Coming back to the problem I was facing:
I was wrong about one thing. These are not two problems - it's probably
one problem. It can't pause because it probably cannot negotiate caps.
Here's what gst-inspect says about TI's adecoder plugin:

Pad Templates:
  SRC template: 'src'
    Availability: Always
    Capabilities:
      audio/x-raw-int
             ...
             ...
             ...
  SINK template: 'sink'
    Availability: Always
    Capabilities:
      audio/mpeg
            mpegversion: { 1, 2, 4 }
                  layer: { 1, 2, 3 }
      audio/x-wma
             wmaversion: { 1, 2, 3 }
                   rate: { 8000, 11025, 12000, 16000, 22050, 24000,
32000, 44100, 48000 }
               channels: [ 1, 2 ]
 
If I understand this correctly, it means that it takes mp3 or wma audio
data as input and gives raw pcm samples as output. Since the filesrc
element can output "any" data type, they should match and it should not
be a problem. So I'm still stuck and I don't have a clue as to what the
problem could be. Please, let me know if you have any idea about this
problem. I'd appreciate any help.
 
Thanks.
 
Vijay


On Tue, Apr 8, 2008 at 8:20 AM, Zhao Liang-E3423C <E3...@mo...>
wrote:


	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: gst...@li...
[mailto:gst...@li...] On Behalf Of
Vijay
	Sent: Monday, April 07, 2008 8:32 PM
	To: gst...@li...
	Subject: [gst-embedded] 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