Thanks for your response, Tyler. I haven't had the chance to try out your last two suggestions yet. I will do so and let you know what I find.
If I've understood you correctly, you said that because caps negotiation faced a problem, it could not preroll (get a buffer upto the last element) so the last element did not pause. I see that this could be right. I had mentioned earlier, that I've also seen this problem (of not being able to preroll) in another pipeline. I managed to solve those problems. Here is that other troublesome pipeline (in the form of the gst-launch execution call): gst-launch-0.10 -m -v filesrc location=<avi-file> ! tidemux_avi name=t ! filesink location=<media-file> t. ! filesink location=<media-file> I fixed this by changing the pipeline. I tried two pipelines that worked: (1) single sink: gst-launch-0.10 filesrc location=<avi-file> ! tidemux_avi name=t ! filesink location=<media-file> t. (2) two sinks but with queues in between some elements: gst-launch-0.10 -m -v filesrc location=<avi-file> ! tidemux_avi name=t t. ! queue max-size-buffers=60 ! filesink location=<media-file> t. ! queue max-size-buffers=180 ! filesink location=<media-file> I understand (from gstreamer's user manual) that in the second working pipeline (in (2), above), the added queues forced the remainder of each end of the pipeline in a different thread. But, I don't know how this made it work. Could you explain that? The mp3 audio file I tried: I'm quite sure the file is good because: - This has worked with every decoder I've tried, and I've tried many decoders :-) - 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. So I think my best bet would be to debug this issue further. Thanks, again. Vijay On Tue, Apr 8, 2008 at 1:51 AM, Tyler Nielsen <[EMAIL PROTECTED]> wrote: > Hello, > > There are a few things that I can comment on that may be of help. First, > it actually does pause, or at least that isn't your problem. For most > plugins (adecoder falls into this category) pause and play are identical. > It appears that the problem is with the way the plugin is passing along the > capabilities to the osssink. > > Here are a few things you can try. First, have you tried multiple files? > Or is it just one mp3 that causes problems? If you can post the mp3 file > somewhere I can try playing it. Second, there is a plugin called mp3parse. > You probably have to install it by downloading gst-plugins-ugly. If I don't > use this, I get audio corruption when playing an mp3 stream, but it might > help with what your seeing. You would use it like this "gst-launch-0.10 > filesrc location=$1 ! mp3parse ! adecoder Codec=3 ! ossink". The last thing > you can do is try to start debugging the issue. If I had to guess, it looks > like gst_caps_copy is returning NULL in gst_adecoder_src_getcaps in > adecoder.c. That might be a good place to start. Additionally, you can try > compiling the version of gstreamer I just sent out. Then run: > > GST_DEBUG=adecoder:5 ./test_MP3.sh MP3_file.mp3 > > That should dump log information that may help debug. It doesn't have > much debug about caps negotiation though. > > Good luck, > Tyler > > > > 2008/4/7 Vijay <[EMAIL PROTECTED]>: > > > Hi all, > > I've noticed that the last element in the pipeline consistently fails to > > pause. 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). (Also, I'm not the only one facing this problem - see the mail > > below) > > > > Would anyone know what the problem might be? Any help would be greatly > > appreciated! > > > > > > > > On Tue, Mar 25, 2008 at 4:39 PM, Vijay <[EMAIL PROTECTED]> > > wrote: > > > > > 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) > > > > > > The two issues: > > > (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 issue with pipelines which > > > have > > > no decode/render elements as well.) *** 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! *** > > > (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. > > > > > > > > > Would anyone know what the issue might be? Has anyone seen a similar > > > issue with TI's gstreamer examples? > > > I'd greatly appreciate any help. > > > > > > > > > Vijay > > > > > > > > > > > > > > > > > > > > > > > Date: Mon, 7 Apr 2008 13:53:46 +0800 > > > > From: "Hans Kuo" <[EMAIL PROTECTED]> > > > > Subject: Question about GStreamer Demo > > > > To: <[email protected]> > > > > Message-ID: <[EMAIL PROTECTED]> > > > > Content-Type: text/plain; charset="big5" > > > > > > > > Hi, I have the same problem when trying to run Run the Demo on the > > Target On the Davinci Board :1. Copy the davincieffect.aac ( > > from dvevm_1_20/data ) to the system_fileS_gstreamer directory2. Run > > the ./start_demo.sh file3. Run the following shell to play an AAC > > file#./test_AAC.sh davincieffect.aac The following message is displayed > > :=======gdbcoder:gst_gdecoder_get_codec_type > > Beginegdbcoder:gst_gdecoder_get_codec_type > > Endgdbcoder:gst_gdecoder_get_codec_type > > Beginegdbcoder:gst_gdecoder_get_codec_type End Setting pipeline to > > PAUSEDPipeline is PREROLLING ¡K¡K. ( It has been staying in this state all > > the time )======= Question : Is it correct ? I am unable to be heard > > any sound by the loudspeakerAny idea how to solve this problem? > > Regards,clara Hsieh. > > > > _______________________________________________ > > Davinci-linux-open-source mailing list > > [email protected] > > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > > > > >
_______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
