Hi vijay,
 
I mean the adecoder src pad's caps in runtime did not match well with
its template.
It is just my guess, you'd better print out the runtime adecoder src0
caps.
or you can refer the sourcecode in gstcaps.c: gst_caps_is_subset
 

Best Regards
Zhao Liang 
________________________________

From: Vijay [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, April 16, 2008 3:28 PM
To: Stefan Kost
Cc: Zhao Liang-E3423C; gstreamer-embedded@lists.sourceforge.net
Subject: Re: [gst-embedded] GStreamer on TI's embedded platform



Zhao & Stefan,
Thank you both, for your responses.
 
I didnt' quite understand what you meant. As I understand caps
negotiation, there should be no problem with the negotiation process if
the adecoder sink pad (that feeds into the adecoder element) caps has an
overlap with the filesrc src pad (that takes the data read from the
file, by the filesrc element). And since the filesrc src pad is 'ANY',
there should be an overlap always and therefore, there should be no
problem. I'm not sure if that understanding is correct.
 
Here's the entire adecoder caps values (obtained by using the command
"gst-inspect-0.10 adecoder" on the command line) :

Pad Templates:
  SRC template: 'src'
    Availability: Always
    Capabilities:
      audio/x-raw-int
             endianness: 1234
                 signed: true
                  width: 16
                  depth: 16
                   rate: { 8000, 11025, 12000, 16000, 22050, 24000,
32000, 44100, 48000 }
               channels: [ 1, 2 ]
  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 ]
 
Please let me know if my understanding is incorrect or if there could be
some other problem.
 
Thanks.
 
Vijay
 

 
On Mon, Apr 14, 2008 at 1:48 AM, Stefan Kost <[EMAIL PROTECTED]>
wrote:


        Zhao Liang-E3423C schrieb: 


                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.
                


        This is a programming error in TIs elements. The quite likely
set a value in the caps which are not in the template caps.
Unfortunately you did not send those (just as "..."). But there they
quite likely forgot e.g. rate or channels.
        
        Stefan
        


                *Best Regards 

                Zhao Liang*
                
        
------------------------------------------------------------------------
                *From:* Vijay [mailto:[EMAIL PROTECTED]
                *Sent:* Thursday, April 10, 2008 9:38 PM
                *To:* Zhao Liang-E3423C
                *Cc:* gstreamer-embedded@lists.sourceforge.net
                *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
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> 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:*
[EMAIL PROTECTED]
        
<mailto:[EMAIL PROTECTED]>
        
[mailto:[EMAIL PROTECTED]
        
<mailto:[EMAIL PROTECTED]>] *On
                   Behalf Of *Vijay
                   *Sent:* Monday, April 07, 2008 8:32 PM
                   *To:* gstreamer-embedded@lists.sourceforge.net
                
                   <mailto:gstreamer-embedded@lists.sourceforge.net> 

                   *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
                
                
                

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Gstreamer-embedded mailing list
Gstreamer-embedded@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded

Reply via email to