<div>Zhao & Stefan,</div> <div>Thank you both, for your responses.</div> <div> </div> <div>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.</div> <div> </div> <div>Here's the entire adecoder caps values (obtained by using the command "gst-inspect-0.10 adecoder" on the command line) :</div> <div><br>Pad Templates:<br>  SRC template: 'src'<br>    Availability: Always<br>    Capabilities:<br>      audio/x-raw-int<br>             endianness: 1234<br>                 signed: true<br>                  width: 16<br>                   depth: 16<br>                   rate: { 8000, 11025, 12000, 16000, 22050, 24000, 32000, 44100, 48000 }<br>               channels: [ 1, 2 ]</div> <div>  SINK template: 'sink'<br>    Availability: Always<br>    Capabilities:<br>      audio/mpeg<br>            mpegversion: { 1, 2, 4 }<br>                  layer: { 1, 2, 3 }<br>      audio/x-wma<br>             wmaversion: { 1, 2, 3 }<br>                    rate: { 8000, 11025, 12000, 16000, 22050, 24000, 32000, 44100, 48000 }<br>               channels: [ 1, 2 ]</div> <div> </div> <div>Please let me know if my understanding is incorrect or if there could be some other problem.</div> <div> </div> <div>Thanks.</div> <div> </div> <div>Vijay</div> <div> </div> <div><br> </div> <div class="gmail_quote">On Mon, Apr 14, 2008 at 1:48 AM, Stefan Kost <<a href="mailto:ensonic@hora-obscura.de">ensonic@hora-obscura.de</a>> wrote:<br> <blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Zhao Liang-E3423C schrieb: <div class="Ih2E3d"><br> <blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px; BORDER-LEFT: #ccc 1px solid">Vijay,<br> I think you can open the log for more information,<br>export GST_DEBUG=GST_CAPS:5<br> 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.<br> </blockquote><br></div>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.<br> <br>Stefan<br> <blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px; BORDER-LEFT: #ccc 1px solid"> <br>*Best Regards <div> <div></div> <div class="Wj3C7c"><br>Zhao Liang*<br><br>------------------------------------------------------------------------<br>*From:* Vijay [mailto:<a href="mailto:vijay.linux.mail@gmail.com" target="_blank">vijay.linux.mail@gmail.com</a>]<br> *Sent:* Thursday, April 10, 2008 9:38 PM<br>*To:* Zhao Liang-E3423C<br>*Cc:* <a href="mailto:gstreamer-embedded@lists.sourceforge.net" target="_blank">gstreamer-embedded@lists.sourceforge.net</a><br>*Subject:* Re: [gst-embedded] GStreamer on TI's embedded platform<br> <br>Thanks for your response, Zhao. I really appreciate it. I didn't get a chance to respond to your mail until now.<br> I don't think I'm missing a mp3 demux element. Here's why:<br> - 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)<br>  - It has no ID3 or other tags (I removed all such MP3 headers and trailers in the file, myself)<br> - It has only an elementary stream that contains only MP3 frames (each frame starting with "0xFF 0xFB"), all of the same length.<br> 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.<br>Plus, this pipeline comes from Texas Instruments, and they must have tested this before they put it on their website (hopefully)!<br>  Coming back to the problem I was facing:<br>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.<br>Here's what gst-inspect says about TI's adecoder plugin:<br> <br>Pad Templates:<br> SRC template: 'src'<br>   Availability: Always<br>   Capabilities:<br>     audio/x-raw-int<br>            ...<br>            ...<br>            ...<br> SINK template: 'sink'<br>   Availability: Always<br>    Capabilities:<br>     audio/mpeg<br>           mpegversion: { 1, 2, 4 }<br>                 layer: { 1, 2, 3 }<br>     audio/x-wma<br>            wmaversion: { 1, 2, 3 }<br>                  rate: { 8000, 11025, 12000, 16000, 22050, 24000, 32000, 44100, 48000 }<br>               channels: [ 1, 2 ]<br> 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.<br>  Thanks.<br> Vijay<br><br></div></div> <div class="Ih2E3d">On Tue, Apr 8, 2008 at 8:20 AM, Zhao Liang-E3423C <<a href="mailto:E3423C@motorola.com" target="_blank">E3423C@motorola.com</a> <mailto:<a href="mailto:E3423C@motorola.com" target="_blank">E3423C@motorola.com</a>>> wrote:<br> <br>   Vijay,<br>       I think maybe you miss a mp3demuxe between filesrc and adecoder.<br>   and the command shall be<br>   gst-launch-0.10 filesrc location=$1 ! mp3demux ! adecoder Codec=3 !<br>   osssink<br>   TI adecoder element may not accept the filesrc RAW caps.<br> <br>   *Best Regards<br>   Zhao Liang *<br><br>   ------------------------------------------------------------------------<br>   *From:* <a href="mailto:gstreamer-embedded-bounces@lists.sourceforge.net" target="_blank">gstreamer-embedded-bounces@lists.sourceforge.net</a><br>    <mailto:<a href="mailto:gstreamer-embedded-bounces@lists.sourceforge.net" target="_blank">gstreamer-embedded-bounces@lists.sourceforge.net</a>><br>   [mailto:<a href="mailto:gstreamer-embedded-bounces@lists.sourceforge.net" target="_blank">gstreamer-embedded-bounces@lists.sourceforge.net</a><br>    <mailto:<a href="mailto:gstreamer-embedded-bounces@lists.sourceforge.net" target="_blank">gstreamer-embedded-bounces@lists.sourceforge.net</a>>] *On<br>   Behalf Of *Vijay<br>   *Sent:* Monday, April 07, 2008 8:32 PM<br>    *To:* <a href="mailto:gstreamer-embedded@lists.sourceforge.net" target="_blank">gstreamer-embedded@lists.sourceforge.net</a><br></div>   <mailto:<a href="mailto:gstreamer-embedded@lists.sourceforge.net" target="_blank">gstreamer-embedded@lists.sourceforge.net</a>> <div> <div></div> <div class="Wj3C7c"><br>   *Subject:* [gst-embedded] GStreamer on TI's embedded platform<br><br>   Hi,<br>   I received TI's port of gstreamer to it's DaVinci processors from<br>   <a href="http://focus.ti.com/dsp/docs/dspsplash.tsp?contentId=3100" target="_blank">http://focus.ti.com/dsp/docs/dspsplash.tsp?contentId=3100</a><br>        I've tried to run the example (scripts) provided by TI and I've<br>   faced what seem to be two separate issues.<br>   I've copied the stdout log below:<br>       <linux prompt>:/opt/system_files_gstreamer# ./test_MP3.sh MP3_file.mp3<br>    Setting pipeline to PAUSED ...<br>   Pipeline is PREROLLING ...<br>   (gst-launch-0.10:1204): GStreamer-WARNING **: pad adecoder0:src<br>   returned caps which are not a real subset of its template caps<br>   (gst-launch-0.10:1204): GStreamer-CRITICAL **:<br>    gst_caps_get_structure: assertion `index < caps->structs->len' failed<br>   (gst-launch-0.10:1204): GStreamer-CRITICAL **:<br>   gst_structure_get_int: assertion `structure != NULL' failed<br><br>   [program hangs here]<br>        For most of you, who don't know about this script: All it does is<br>   after setting the gstreamer, plugin and library paths, it runs<br>   gst-launch with a pipeline, thus: gst-launch-0.10 filesrc<br>   location=$1 ! adecoder Codec=3 ! osssink<br> <br>   The two issues I'm facing:<br>   (a) The *last* element in the gstreamer pipeline does not reply with<br>   a message to the app saying it has paused (This is ascertained with<br>   debug prints that I inserted in gst-launch.c. It's possible that for<br>    some reason, the element does not pause. I've faced this same issue<br>   with pipelines which have no decode/render elements as well.)<br>   Actually, I'm not sure if (a) it doesn't pause because it doesn't<br>    finish preroll or (b) it says it hasn't finished preroll because it<br>   doesn't send a pause signal! (I'm not sure which is the cause and<br>   which is the effect).<br><br>   (b) The critical errors printed (seen above. I guess these are<br>    caused because of TI's mp3 decoder element plugin.) Could the<br>   adecoder capabilities be incompatible? Seems unlikely, since TI<br>   would have tested this first.<br><br><br>   Would anyone know what the issue might be? Has anyone seen a similar<br>    issue with gstreamer?<br>   I'd greatly appreciate any help.<br>   Thanks.<br><br><br>   Vijay<br><br><br></div></div></blockquote></blockquote></div>