Menu
▾
▴
gstreamer-embedded — GStreamer on embedded platforms
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
(21) |
Mar
(30) |
Apr
(17) |
May
(2) |
Jun
(30) |
Jul
(22) |
Aug
(39) |
Sep
(42) |
Oct
(30) |
Nov
(42) |
Dec
(16) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(31) |
Feb
(44) |
Mar
(33) |
Apr
(26) |
May
(15) |
Jun
(28) |
Jul
(15) |
Aug
(15) |
Sep
|
Oct
(34) |
Nov
(21) |
Dec
(36) |
| 2010 |
Jan
(53) |
Feb
(31) |
Mar
(30) |
Apr
(14) |
May
(12) |
Jun
(6) |
Jul
(5) |
Aug
(9) |
Sep
(10) |
Oct
(3) |
Nov
(1) |
Dec
(16) |
| 2011 |
Jan
(6) |
Feb
(5) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Shenhong W. <qc...@ho...> - 2008-06-18 08:43:33
|
Hi, Zhao Liang: Generally, the aacdec &alsasink will not play out any audio frames(packets) after its source element has a break to send audio frames (packets) to them. It looks the alsasink drops all frames(packets) from the break. The break is needed because we have more video frames and sometime the wireless signal is not good. It looks the aacdec is slower than the expectation from alsasink.If so, how to fix the issue? thanks! best Regards! Shenhong Subject: RE: [gst-embedded] Question on gst_plugin alsasinkDate: Wed, 18 Jun 2008 14:29:27 +0800From: E3...@mo...To: qc...@ho...; gst...@li... Hi Shenhong, Your issue is very similar with the issue I even met. I think it is due to gstbaseaudiosink/gstaudiosink, it will drop the packets by gstringbuffer when read rate is bigger than write rate in ringbuffer, please see gstringbuffer.c gst_ring_buffer_commit_full (). For the rootcause, I think maybe the alsasink audiodevice buffer is too big or your aac decoder is too slow. Best RegardsZhao Liang From: gst...@li... [mailto:gst...@li...] On Behalf Of Shenhong WangSent: Wednesday, June 18, 2008 2:21 PMTo: gst...@li...Subject: [gst-embedded] Question on gst_plugin alsasink Dear all,Now we are using alsasink to play audio on Marvell PXA310 board. The audio is aac format. The audio frames(packets) are frequently sent to the aac decoder & alsasink to play out. Unfortunately only the begining frames can be played out and then nothing is played out. If we save those audio frames into a file, the aac decoder&alsasink can be successfully played out. It means the audio frames are ok. Could anyone tell me what's the difference for alsasink to process audio packets and files? How to fix the above issue? thank you very much! Best Regards!Shenhong WANG Connect to the next generation of MSN Messenger Get it now! _________________________________________________________________ Connect to the next generation of MSN Messenger http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline |
|
From: Zhao Bin-E. <bi...@mo...> - 2008-06-18 08:42:35
|
Why your source element has a break? do you use live source? I suggest you pause the pipleline at the moment. Brad ________________________________ From: Shenhong Wang [mailto:qc...@ho...] Sent: Wednesday, June 18, 2008 4:39 PM To: Zhao Bin-E6223C; gst...@li... Subject: RE: [gst-embedded] Question on gst_plugin alsasink Brad, thanks! At the moment I didn't put any timestamp on the frames(buffer) yet. Generally, the aacdec &alsasink will not play out any audio frames(packets) after its source element has a break to send audio frames (packets) to them. It looks the alsasink drop all frames(packets) from the break. Why? How to fix it? Thanks! Best Regards! Shenhong WANG ________________________________ Subject: RE: [gst-embedded] Question on gst_plugin alsasink Date: Wed, 18 Jun 2008 15:01:06 +0800 From: bi...@mo... To: qc...@ho...; gst...@li... Hi, your issue seems that audio frame is delayed when arrivering alsasink. basesink will drop the delayed buffer and you could'nt hear any sound. Please check your timestamp of buffer. Brad ________________________________ From: gst...@li... [mailto:gst...@li...] On Behalf Of Shenhong Wang Sent: Wednesday, June 18, 2008 2:21 PM To: gst...@li... Subject: [gst-embedded] Question on gst_plugin alsasink Dear all, Now we are using alsasink to play audio on Marvell PXA310 board. The audio is aac format. The audio frames(packets) are frequently sent to the aac decoder & alsasink to play out. Unfortunately only the begining frames can be played out and then nothing is played out. If we save those audio frames into a file, the aac decoder&alsasink can be successfully played out. It means the audio frames are ok. Could anyone tell me what's the difference for alsasink to process audio packets and files? How to fix the above issue? thank you very much! Best Regards! Shenhong WANG ________________________________ Connect to the next generation of MSN Messenger Get it now! <http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&sou rce=wlmailtagline> ________________________________ Explore the seven wonders of the world Learn more! <http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBR E> |
|
From: Shenhong W. <qc...@ho...> - 2008-06-18 08:38:55
|
Brad, thanks! At the moment I didn't put any timestamp on the frames(buffer) yet. Generally, the aacdec &alsasink will not play out any audio frames(packets) after its source element has a break to send audio frames (packets) to them. It looks the alsasink drop all frames(packets) from the break. Why? How to fix it? Thanks! Best Regards! Shenhong WANG Subject: RE: [gst-embedded] Question on gst_plugin alsasinkDate: Wed, 18 Jun 2008 15:01:06 +0800From: bi...@mo...To: qc...@ho...; gst...@li... Hi, your issue seems that audio frame is delayed when arrivering alsasink. basesink will drop the delayed buffer and you could'nt hear any sound. Please check your timestamp of buffer. Brad From: gst...@li... [mailto:gst...@li...] On Behalf Of Shenhong WangSent: Wednesday, June 18, 2008 2:21 PMTo: gst...@li...Subject: [gst-embedded] Question on gst_plugin alsasink Dear all,Now we are using alsasink to play audio on Marvell PXA310 board. The audio is aac format. The audio frames(packets) are frequently sent to the aac decoder & alsasink to play out. Unfortunately only the begining frames can be played out and then nothing is played out. If we save those audio frames into a file, the aac decoder&alsasink can be successfully played out. It means the audio frames are ok. Could anyone tell me what's the difference for alsasink to process audio packets and files? How to fix the above issue? thank you very much! Best Regards!Shenhong WANG Connect to the next generation of MSN Messenger Get it now! _________________________________________________________________ Explore the seven wonders of the world http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE |
|
From: Zhao Bin-E. <bi...@mo...> - 2008-06-18 07:01:08
|
Hi, your issue seems that audio frame is delayed when arrivering alsasink. basesink will drop the delayed buffer and you could'nt hear any sound. Please check your timestamp of buffer. Brad ________________________________ From: gst...@li... [mailto:gst...@li...] On Behalf Of Shenhong Wang Sent: Wednesday, June 18, 2008 2:21 PM To: gst...@li... Subject: [gst-embedded] Question on gst_plugin alsasink Dear all, Now we are using alsasink to play audio on Marvell PXA310 board. The audio is aac format. The audio frames(packets) are frequently sent to the aac decoder & alsasink to play out. Unfortunately only the begining frames can be played out and then nothing is played out. If we save those audio frames into a file, the aac decoder&alsasink can be successfully played out. It means the audio frames are ok. Could anyone tell me what's the difference for alsasink to process audio packets and files? How to fix the above issue? thank you very much! Best Regards! Shenhong WANG ________________________________ Connect to the next generation of MSN Messenger Get it now! <http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&sou rce=wlmailtagline> |
|
From: Zhao Liang-E. <E3...@mo...> - 2008-06-18 06:29:26
|
Hi Shenhong, Your issue is very similar with the issue I even met. I think it is due to gstbaseaudiosink/gstaudiosink, it will drop the packets by gstringbuffer when read rate is bigger than write rate in ringbuffer, please see gstringbuffer.c gst_ring_buffer_commit_full (). For the rootcause, I think maybe the alsasink audiodevice buffer is too big or your aac decoder is too slow. Best Regards Zhao Liang ________________________________ From: gst...@li... [mailto:gst...@li...] On Behalf Of Shenhong Wang Sent: Wednesday, June 18, 2008 2:21 PM To: gst...@li... Subject: [gst-embedded] Question on gst_plugin alsasink Dear all, Now we are using alsasink to play audio on Marvell PXA310 board. The audio is aac format. The audio frames(packets) are frequently sent to the aac decoder & alsasink to play out. Unfortunately only the begining frames can be played out and then nothing is played out. If we save those audio frames into a file, the aac decoder&alsasink can be successfully played out. It means the audio frames are ok. Could anyone tell me what's the difference for alsasink to process audio packets and files? How to fix the above issue? thank you very much! Best Regards! Shenhong WANG ________________________________ Connect to the next generation of MSN Messenger Get it now! <http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&sou rce=wlmailtagline> |
|
From: Shenhong W. <qc...@ho...> - 2008-06-18 06:20:52
|
Dear all, Now we are using alsasink to play audio on Marvell PXA310 board. The audio is aac format. The audio frames(packets) are frequently sent to the aac decoder & alsasink to play out. Unfortunately only the begining frames can be played out and then nothing is played out. If we save those audio frames into a file, the aac decoder&alsasink can be successfully played out. It means the audio frames are ok. Could anyone tell me what's the difference for alsasink to process audio packets and files? How to fix the above issue? thank you very much! Best Regards! Shenhong WANG _________________________________________________________________ Connect to the next generation of MSN Messenger http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline |
|
From: Manish R. <man...@gm...> - 2008-06-13 08:04:38
|
Hi Neeraj, I have done profiling for Gstreamer using gettimeofday call. gprof i tried but was not giving me any results. :( This call will give you the system time you can get the time at the beginning and of function and take the difference. For multiple occurrence you need to keep the diff time as static and add the new result to the new one. Please let me know if you got some better idea. Also if possible please share your timings. All the best. Manish On Tue, Jun 10, 2008 at 2:04 PM, Neeraj Jayaswal <nja...@ta...> wrote: > Hi All, > > I am new to GStreamer concept and I need to profile the performance of > GStreamer on a particular Hardware. > This profiling has to be done at element level. Has anybody dealt with > similar scenario ? If yes, then what is the best approach to be followed ? > I am targeting Chain functions of all the elements that are involved in a > particular case [ For example, Audio Playback - then I can profile the > chain > functions of filesrc, parser, decoder, conv, filesink] . Is this approach > correct for getting the actual performance of GStreamer or am I missing > something ? > > Thanks in advance. > > Regards, > Neeraj Jayaswal > > PS: Please ignore the confidentiality message appended to this mail. > > > The information contained in this electronic message and any attachments to > this message are intended for the exclusive use of the addressee(s) and may > contain proprietary, confidential or privileged information. If you are not > the intended recipient, you should not disseminate, distribute or copy this > e-mail. Please notify the sender immediately and destroy all copies of this > message and any attachments contained in it. > > Contact your Administrator for further information. > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Gstreamer-embedded mailing list > Gst...@li... > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded > |
|
From: Zhao Liang-E. <E3...@mo...> - 2008-06-10 09:22:34
|
Hi Tim, For that case, demuxer should not send ERROR message to bus, just stop streaming task, only decoder does it, right ? Best Regards Zhao Liang -----Original Message----- From: gst...@li... [mailto:gst...@li...] On Behalf Of Tim Müller Sent: Tuesday, June 10, 2008 4:59 PM To: gst...@li... Subject: Re: [gst-embedded] questions on gst_pad_push() to sendaudio/video data to codec On Tue, 2008-06-10 at 09:35 +0800, Zhao Bin-E6223C wrote: > If your audio device is not available or your decoder meet some error, > the data flow will return data_error sometime. Do you handle the error > in demux element? > > It's better to handle the error in the element where happens and do > nothing in demux. Because the occasional data flow error don't effect > the pipline playback. This is not really how it's supposed to work. If a downstream element returns GST_FLOW_ERROR (-5), this indicates a fatal error, and streaming should usually stop. A demuxer that is chain-based should pass GST_FLOW_ERROR back upstream by returning that from its chain function; a demuxer driving the pipeline should stop its streaming task. The downstream element which has returned GST_FLOW_ERROR (which may be the decoder, but it could be any element downstream of that as well) should have posted an error message on the bus (via GST_ELEMENT_ERROR() ususally) with more details. Did you check for error messages on the bus? Cheers -Tim ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Gstreamer-embedded mailing list Gst...@li... https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded |
|
From: Tim M. <tim...@co...> - 2008-06-10 08:59:26
|
On Tue, 2008-06-10 at 09:35 +0800, Zhao Bin-E6223C wrote: > If your audio device is not available or your decoder meet some error, > the data flow will return data_error sometime. Do you handle the error > in demux element? > > It's better to handle the error in the element where happens and do > nothing in demux. Because the occasional data flow error don't effect > the pipline playback. This is not really how it's supposed to work. If a downstream element returns GST_FLOW_ERROR (-5), this indicates a fatal error, and streaming should usually stop. A demuxer that is chain-based should pass GST_FLOW_ERROR back upstream by returning that from its chain function; a demuxer driving the pipeline should stop its streaming task. The downstream element which has returned GST_FLOW_ERROR (which may be the decoder, but it could be any element downstream of that as well) should have posted an error message on the bus (via GST_ELEMENT_ERROR() ususally) with more details. Did you check for error messages on the bus? Cheers -Tim |
|
From: Neeraj J. <nja...@ta...> - 2008-06-10 08:31:42
|
Hi All, I am new to GStreamer concept and I need to profile the performance of GStreamer on a particular Hardware. This profiling has to be done at element level. Has anybody dealt with similar scenario ? If yes, then what is the best approach to be followed ? I am targeting Chain functions of all the elements that are involved in a particular case [ For example, Audio Playback - then I can profile the chain functions of filesrc, parser, decoder, conv, filesink] . Is this approach correct for getting the actual performance of GStreamer or am I missing something ? Thanks in advance. Regards, Neeraj Jayaswal PS: Please ignore the confidentiality message appended to this mail. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments contained in it. Contact your Administrator for further information. |
|
From: Zhao Bin-E. <bi...@mo...> - 2008-06-10 01:35:34
|
I think there is no difference to send out audio or video data to downstream element. If your audio device is not available or your decoder meet some error, the data flow will return data_error sometime. Do you handle the error in demux element? It's better to handle the error in the element where happens and do nothing in demux. Because the occasional data flow error don't effect the pipline playback. Zhao Bin (Brad) ________________________________ From: gst...@li... [mailto:gst...@li...] On Behalf Of Shenhong Wang Sent: Friday, June 06, 2008 6:10 PM To: gst...@li... Subject: [gst-embedded] questions on gst_pad_push() to send audio/video datato codec Dear all, Now we are writing up a media demux element. It contains one sink pad and two source pads (audio & video). The element is expected to contact to next stage element (codec) in PUSH mode. After processing data in chain() function, we call gst_pad_push to send the audio or video to peer pads in codec elements (H.264 video or AAC). a) gst_pad_push returns back with 0 which looks successfully for video data b) gst_pad_push always return back with -5 for audio data. Actually we use same codes (but names) to finish the above actions, however we got different results (o or -5). Would anyone of you tell me what's the difference to send out audio/video data to their codec? Thanks a lot! Best Regards! Shenhong ________________________________ Discover the new Windows Vista Learn more! <http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE> ________________________________ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! Try it! <http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends. aspx&mkt=en-us> |
|
From: Shenhong W. <qc...@ho...> - 2008-06-06 10:11:28
|
Dear all, Now we are writing up a media demux element. It contains one sink pad and two source pads (audio & video). The element is expected to contact to next stage element (codec) in PUSH mode. After processing data in chain() function, we call gst_pad_push to send the audio or video to peer pads in codec elements (H.264 video or AAC). a) gst_pad_push returns back with 0 which looks successfully for video data b) gst_pad_push always return back with -5 for audio data. Actually we use same codes (but names) to finish the above actions, however we got different results (o or -5). Would anyone of you tell me what’s the difference to send out audio/video data to their codec? Thanks a lot! Best Regards! Shenhong Discover the new Windows Vista Learn more! _________________________________________________________________ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us |
|
From: Allen C. <icc...@gm...> - 2008-05-28 11:24:31
|
Hi all, I wanna develop a Gstream plugin and I study "GStreamer Plugin Writer's Guide (0.10.19.1)" . II. Building a Plugin The example code used in this part of the guide can be found in examples/pwg/examplefilter/ in your GStreamer directory. After I checkout the files with module gstreamer from the CVS server. I can't find the files. The pwg directory is empty. Please give me some help. Thank you, icchen. |
|
From: Allen C. <icc...@gm...> - 2008-05-28 11:20:04
|
Hi all, I wanna develop a Gstream plugin and I study "GStreamer Plugin Writer's Guide (0.10.19.1)" . II. Building a Plugin The example code used in this part of the guide can be found in examples/pwg/examplefilter/ in your GStreamer directory. After I checkout the files with module gstreamer from the CVS server. I can't find the files. The pwg directory is empty. Please give me some help. Thank you, icchen. |
|
From: Stefan K. <en...@ho...> - 2008-04-20 18:12:58
|
Hej, Jan Schmidt schrieb: > <quote who="Gireesh Kumar M"> > >> Hi, >> >> I'm running GStreamer, built with CodeSourcery arm toolchain [version: >> (CodeSourcery Sourcery G++ Lite 2007q3-51) 4.2.1], on TI's OMAP board. >> The runtime memory consumption (as reported by 'top' command) is 38% on a >> 128MB RAM (~48MBytes), which is very high. Verifying the memory map log >> (using pmap), I found the presence of some un-named memory blocks of size >> 8188 KBytes which contributes major share to the 38% RAM usage (PMAP log >> attached). Is this a GStreamer bug or a memory leak? Can anyone help me to >> fix this? > > I'd guess they're probably thread stacks. I think the default is 8MB, but > you can make it smaller, possibly by using g_thread_create_full in the right > places in GStreamer core (in gsttask.c somewhere) We're using g_thread_pools for GstTasks and for g_thread_pools you can't change this. Stefan > > J. > >> Currently I'm using the mp3 playback with the following pipeline >> $gst-launch filesrc location=test.mp3 ! queue ! mad ! alsasink >> >> Any help on this is highly appreciated. >> >> Thank you, >> Gireesh >> >> > >> /home/gst-gireesh/gstreamer/bin/gst-launch-0.10(320) >> 00008000 (16 KB) r-xp (00:0d 1669206) /home/gst-gireesh/gstreamer/bin/gst-launch-0.10 >> 00013000 (4 KB) rw-p (00:0d 1669206) /home/gst-gireesh/gstreamer/bin/gst-launch-0.10 >> 00014000 (1452 KB) rwxp (00:00 0) [heap] >> 40000000 (112 KB) r-xp (00:0d 2502123) /lib/ld-2.5.so >> 4001c000 (24 KB) rw-p (00:00 0) >> 40023000 (8 KB) rw-p (00:0d 2502123) /lib/ld-2.5.so >> 40025000 (592 KB) r-xp (00:0d 1102627) /home/gst-gireesh/gstreamer/lib/libgstreamer-0.10.so.0.10.0 >> 400b9000 (32 KB) ---p (00:0d 1102627) /home/gst-gireesh/gstreamer/lib/libgstreamer-0.10.so.0.10.0 >> 400c1000 (12 KB) rw-p (00:0d 1102627) /home/gst-gireesh/gstreamer/lib/libgstreamer-0.10.so.0.10.0 >> 400c4000 (4 KB) rw-p (00:00 0) >> 400c5000 (232 KB) r-xp (00:0d 1102632) /home/gst-gireesh/gstreamer/lib/libgobject-2.0.so.0.1200.4 >> 400ff000 (32 KB) ---p (00:0d 1102632) /home/gst-gireesh/gstreamer/lib/libgobject-2.0.so.0.1200.4 >> 40107000 (4 KB) rw-p (00:0d 1102632) /home/gst-gireesh/gstreamer/lib/libgobject-2.0.so.0.1200.4 >> 40108000 (12 KB) r-xp (00:0d 1685611) /home/gst-gireesh/gstreamer/lib/libgthread-2.0.so.0.1200.4 >> 4010b000 (32 KB) ---p (00:0d 1685611) /home/gst-gireesh/gstreamer/lib/libgthread-2.0.so.0.1200.4 >> 40113000 (4 KB) rw-p (00:0d 1685611) /home/gst-gireesh/gstreamer/lib/libgthread-2.0.so.0.1200.4 >> 40114000 (8 KB) r-xp (00:0d 1685622) /home/gst-gireesh/gstreamer/lib/libgmodule-2.0.so.0.1200.4 >> 40116000 (32 KB) ---p (00:0d 1685622) /home/gst-gireesh/gstreamer/lib/libgmodule-2.0.so.0.1200.4 >> 4011e000 (4 KB) rw-p (00:0d 1685622) /home/gst-gireesh/gstreamer/lib/libgmodule-2.0.so.0.1200.4 >> 4011f000 (8 KB) r-xp (00:0d 2502098) /lib/libdl-2.5.so >> 40121000 (28 KB) ---p (00:0d 2502098) /lib/libdl-2.5.so >> 40128000 (4 KB) r--p (00:0d 2502098) /lib/libdl-2.5.so >> 40129000 (4 KB) rw-p (00:0d 2502098) /lib/libdl-2.5.so >> 4012a000 (596 KB) r-xp (00:0d 1685596) /home/gst-gireesh/gstreamer/lib/libglib-2.0.so.0.1200.4 >> 401bf000 (32 KB) ---p (00:0d 1685596) /home/gst-gireesh/gstreamer/lib/libglib-2.0.so.0.1200.4 >> 401c7000 (4 KB) rw-p (00:0d 1685596) /home/gst-gireesh/gstreamer/lib/libglib-2.0.so.0.1200.4 >> 401c8000 (80 KB) r-xp (00:0d 2502115) /lib/libpthread-2.5.so >> 401dc000 (28 KB) ---p (00:0d 2502115) /lib/libpthread-2.5.so >> 401e3000 (4 KB) r--p (00:0d 2502115) /lib/libpthread-2.5.so >> 401e4000 (4 KB) rw-p (00:0d 2502115) /lib/libpthread-2.5.so >> 401e5000 (8 KB) rw-p (00:00 0) >> 401e7000 (1100 KB) r-xp (00:0d 2502090) /lib/libc-2.5.so >> 402fa000 (32 KB) ---p (00:0d 2502090) /lib/libc-2.5.so >> 40302000 (4 KB) r--p (00:0d 2502090) /lib/libc-2.5.so >> 40303000 (8 KB) rw-p (00:0d 2502090) /lib/libc-2.5.so >> 40305000 (12 KB) rw-p (00:00 0) >> 40308000 (24 KB) r-xp (00:0d 2502114) /lib/librt-2.5.so >> 4030e000 (28 KB) ---p (00:0d 2502114) /lib/librt-2.5.so >> 40315000 (4 KB) r--p (00:0d 2502114) /lib/librt-2.5.so >> 40316000 (4 KB) rw-p (00:0d 2502114) /lib/librt-2.5.so >> 40317000 (1160 KB) r-xp (00:0d 1685687) /home/gst-gireesh/gstreamer/lib/libxml2.so.2.6.26 >> 40439000 (32 KB) ---p (00:0d 1685687) /home/gst-gireesh/gstreamer/lib/libxml2.so.2.6.26 >> 40441000 (20 KB) rw-p (00:0d 1685687) /home/gst-gireesh/gstreamer/lib/libxml2.so.2.6.26 >> 40446000 (4 KB) rw-p (00:00 0) >> 40447000 (888 KB) r-xp (00:0d 1685378) /home/gst-gireesh/gstreamer/lib/libiconv.so.2.4.0 >> 40525000 (28 KB) ---p (00:0d 1685378) /home/gst-gireesh/gstreamer/lib/libiconv.so.2.4.0 >> 4052c000 (4 KB) rw-p (00:0d 1685378) /home/gst-gireesh/gstreamer/lib/libiconv.so.2.4.0 >> 4052d000 (644 KB) r-xp (00:0d 2502092) /lib/libm-2.5.so >> 405ce000 (28 KB) ---p (00:0d 2502092) /lib/libm-2.5.so >> 405d5000 (4 KB) r--p (00:0d 2502092) /lib/libm-2.5.so >> 405d6000 (4 KB) rw-p (00:0d 2502092) /lib/libm-2.5.so >> 405d7000 (44 KB) r-xp (00:0d 2502109) /lib/libgcc_s.so.1 >> 405e2000 (28 KB) ---p (00:0d 2502109) /lib/libgcc_s.so.1 >> 405e9000 (4 KB) rw-p (00:0d 2502109) /lib/libgcc_s.so.1 >> 405ea000 (36 KB) r-xp (00:0d 2502117) /lib/libnss_files-2.5.so >> 405f3000 (28 KB) ---p (00:0d 2502117) /lib/libnss_files-2.5.so >> 405fa000 (4 KB) r--p (00:0d 2502117) /lib/libnss_files-2.5.so >> 405fb000 (4 KB) rw-p (00:0d 2502117) /lib/libnss_files-2.5.so >> 405fc000 (140 KB) r-xp (00:0d 2717769) /home/gst-gireesh/gstreamer/lib/gstreamer-0.10/libgstcoreelements.so >> 4061f000 (28 KB) ---p (00:0d 2717769) /home/gst-gireesh/gstreamer/lib/gstreamer-0.10/libgstcoreelements.so >> 40626000 (8 KB) rw-p (00:0d 2717769) /home/gst-gireesh/gstreamer/lib/gstreamer-0.10/libgstcoreelements.so >> 40628000 (136 KB) r-xp (00:0d 1102629) /home/gst-gireesh/gstreamer/lib/libgstbase-0.10.so.0.10.0 >> 4064a000 (28 KB) ---p (00:0d 1102629) /home/gst-gireesh/gstreamer/lib/libgstbase-0.10.so.0.10.0 >> 40651000 (4 KB) rw-p (00:0d 1102629) /home/gst-gireesh/gstreamer/lib/libgstbase-0.10.so.0.10.0 >> 40652000 (60 KB) r-xp (00:0d 2717682) /home/gst-gireesh/gstreamer/lib/gstreamer-0.10/libgstmad.so >> 40661000 (32 KB) ---p (00:0d 2717682) /home/gst-gireesh/gstreamer/lib/gstreamer-0.10/libgstmad.so >> 40669000 (4 KB) rw-p (00:0d 2717682) /home/gst-gireesh/gstreamer/lib/gstreamer-0.10/libgstmad.so >> 4066a000 (24 KB) r-xp (00:0d 1685581) /home/gst-gireesh/gstreamer/lib/libgsttag-0.10.so.0.8.0 >> 40670000 (28 KB) ---p (00:0d 1685581) /home/gst-gireesh/gstreamer/lib/libgsttag-0.10.so.0.8.0 >> 40677000 (4 KB) rw-p (00:0d 1685581) /home/gst-gireesh/gstreamer/lib/libgsttag-0.10.so.0.8.0 >> 40678000 (84 KB) r-xp (00:0d 1685600) /home/gst-gireesh/gstreamer/lib/libmad.so.0.2.1 >> 4068d000 (28 KB) ---p (00:0d 1685600) /home/gst-gireesh/gstreamer/lib/libmad.so.0.2.1 >> 40694000 (4 KB) rw-p (00:0d 1685600) /home/gst-gireesh/gstreamer/lib/libmad.so.0.2.1 >> 40695000 (112 KB) r-xp (00:0d 1685668) /home/gst-gireesh/gstreamer/lib/libid3tag.so.0.3.0 >> 406b1000 (28 KB) ---p (00:0d 1685668) /home/gst-gireesh/gstreamer/lib/libid3tag.so.0.3.0 >> 406b8000 (8 KB) rw-p (00:0d 1685668) /home/gst-gireesh/gstreamer/lib/libid3tag.so.0.3.0 >> 406ba000 (72 KB) r-xp (00:0d 2717683) /home/gst-gireesh/gstreamer/lib/gstreamer-0.10/libgstalsa.so >> 406cc000 (28 KB) ---p (00:0d 2717683) /home/gst-gireesh/gstreamer/lib/gstreamer-0.10/libgstalsa.so >> 406d3000 (4 KB) rw-p (00:0d 2717683) /home/gst-gireesh/gstreamer/lib/gstreamer-0.10/libgstalsa.so >> 406d4000 (724 KB) r-xp (00:0d 2211260) /home/gst-gireesh/gstreamer/lib/libasound.so.2.0.0 >> 40789000 (32 KB) ---p (00:0d 2211260) /home/gst-gireesh/gstreamer/lib/libasound.so.2.0.0 >> 40791000 (16 KB) rw-p (00:0d 2211260) /home/gst-gireesh/gstreamer/lib/libasound.so.2.0.0 >> 40795000 (28 KB) r-xp (00:0d 1685618) /home/gst-gireesh/gstreamer/lib/libgstinterfaces-0.10.so.0.8.0 >> 4079c000 (28 KB) ---p (00:0d 1685618) /home/gst-gireesh/gstreamer/lib/libgstinterfaces-0.10.so.0.8.0 >> 407a3000 (4 KB) rw-p (00:0d 1685618) /home/gst-gireesh/gstreamer/lib/libgstinterfaces-0.10.so.0.8.0 >> 407a4000 (88 KB) r-xp (00:0d 1685645) /home/gst-gireesh/gstreamer/lib/libgstaudio-0.10.so.0.8.0 >> 407ba000 (32 KB) ---p (00:0d 1685645) /home/gst-gireesh/gstreamer/lib/libgstaudio-0.10.so.0.8.0 >> 407c2000 (4 KB) rw-p (00:0d 1685645) /home/gst-gireesh/gstreamer/lib/libgstaudio-0.10.so.0.8.0 >> 407c3000 (4 KB) ---p (00:00 0) >> 407c4000 (8188 KB) rwxp (00:00 0) >> 40fc3000 (4 KB) ---p (00:00 0) >> 40fc4000 (8188 KB) rwxp (00:00 0) >> 417c3000 (4 KB) ---p (00:00 0) >> 417c4000 (8188 KB) rwxp (00:00 0) >> 41fc3000 (4 KB) ---p (00:00 0) >> 41fc4000 (8188 KB) rwxp (00:00 0) >> 427c3000 (4 KB) ---p (00:00 0) >> 427c4000 (8188 KB) rwxp (00:00 0) >> beeb0000 (84 KB) rwxp (00:00 0) [stack] >> mapped: 50460 KB writable/private: 42684 KB shared: 0 KB > >> ------------------------------------------------------------------------- >> 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 >> Gst...@li... >> https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded > > |
|
From: Michael S. <ms...@xi...> - 2008-04-16 17:11:36
|
On Wed, Apr 16, 2008 at 4:10 AM, Gireesh Kumar M <gir...@gm...> wrote: > > >At a guess, I'd say those are probably thread stacks. > > >You're measuring the wrong thing - the virtual size of the > >application. You don't really need to care about the virtual size - > >these thread stacks don't get faulted into actual physical ram. > > >Mike > Mike, > What I understand from your explanation is > 1. The virtual size shown by 'top' and 'pmap' doesn't mean that my > application is eating up much space in the physical memory. > 2. I can safely ignore this memory usage shown. > Please correct me if I'm wrong. > > Now, how can I confirm this? My point is, is there any utility to measure > the physical ram usage? Top will show that in the "RSS" column (Resident Set Size - this is the amount of memory actually resident in physical memory). Mike |
|
From: Gireesh K. M <gir...@gm...> - 2008-04-16 11:09:55
|
Mike and Jan,
Thanks a lot for your responses!
>Gireesh,
>At a guess, I'd say those are probably thread stacks.
>You're measuring the wrong thing - the virtual size of the
>application. You don't really need to care about the virtual size -
>these thread stacks don't get faulted into actual physical ram.
>Mike
*Mike*,
What I understand from your explanation is
1. The virtual size shown by 'top' and 'pmap' doesn't mean that my
application is eating up much space in the physical memory.
2. I can safely ignore this memory usage shown.
Please correct me if I'm wrong.
Now, how can I confirm this? My point is, is there any utility to measure
the physical ram usage?
>I'd guess they're probably thread stacks. I think the default is 8MB, but
>you can make it smaller, possibly by using g_thread_create_full in the
right
>places in GStreamer core (in gsttask.c somewhere)
>J.
*Jan*,
I could not find a reference to g_thread_create_full anywhere in the
gstreamer core. Instead, it is there in some files in glib source. In all
places, the stack_size is being passed as 0 (highlighted in the below pasted
log).
Can you please tell me if I'm looking at the right places?
thanks again,
gireesh
--------g_thread_create_full--------------
[gireesh@omaplinux3 gstreamer]$ grep g_thread_create_full */*/*
glib-2.12.4/glib/galiasdef.c:#undef g_thread_create_full
glib-2.12.4/glib/galiasdef.c:extern __typeof (g_thread_create_full)
g_thread_create_full __attribute((alias("IA__g_thread_create_full"),
visibility("default")));
glib-2.12.4/glib/galias.h:extern __typeof (g_thread_create_full)
IA__g_thread_create_full __attribute((visibility("hidden")));
glib-2.12.4/glib/galias.h:#define g_thread_create_full
IA__g_thread_create_full
glib-2.12.4/glib/glib.symbols:g_thread_create_full
glib-2.12.4/glib/gthread.c:g_thread_create_full (GThreadFunc
func,
glib-2.12.4/glib/gthread.h: (g_thread_create_full (func, data, 0, joinable,
FALSE, \
glib-2.12.4/glib/gthread.h:GThread* g_thread_create_full
(GThreadFunc func,
glib-2.12.4/tests/slice-test.c: threads[i] = g_thread_create_full
(test_sliced_mem_thread, seedp, 0, TRUE, FALSE, 0, NULL);
glib-2.12.4/tests/slice-test.c: threads[i] = g_thread_create_full
(test_memchunk_thread, seedp, 0, TRUE, FALSE, 0, NULL);
Binary file gstreamer-0.10.11/gst/libgstreamer_0.10_la-gstsystemclock.o
matches
------------------------------------------------------------------------------
|
|
From: Zhao Liang-E. <E3...@mo...> - 2008-04-16 07:57:26
|
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:vij...@gm...]
Sent: Wednesday, April 16, 2008 3:28 PM
To: Stefan Kost
Cc: Zhao Liang-E3423C; gst...@li...
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 <en...@ho...>
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: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... <mailto: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...>
[mailto:gst...@li...
<mailto:gst...@li...>] *On
Behalf Of *Vijay
*Sent:* Monday, April 07, 2008 8:32 PM
*To:* gst...@li...
<mailto: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
|
|
From: Vijay <vij...@gm...> - 2008-04-16 07:27:59
|
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 <en...@ho...>
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: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...<mailto:
> > 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...>
> > [mailto:gst...@li...
> > <mailto:gst...@li...>] *On
> > Behalf Of *Vijay
> > *Sent:* Monday, April 07, 2008 8:32 PM
> > *To:* gst...@li...
> > <mailto: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
> >
> >
> >
|
|
From: Michael S. <ms...@xi...> - 2008-04-14 15:45:48
|
Gireesh, At a guess, I'd say those are probably thread stacks. You're measuring the wrong thing - the virtual size of the application. You don't really need to care about the virtual size - these thread stacks don't get faulted into actual physical ram. Mike On Mon, Apr 14, 2008 at 1:13 AM, Gireesh Kumar M <gir...@gm...> wrote: > Hi, > > I'm running GStreamer, built with CodeSourcery arm toolchain [version: > (CodeSourcery Sourcery G++ Lite 2007q3-51) 4.2.1], on TI's OMAP board. > The runtime memory consumption (as reported by 'top' command) is 38% on a > 128MB RAM (~48MBytes), which is very high. Verifying the memory map log > (using pmap), I found the presence of some un-named memory blocks of size > 8188 KBytes which contributes major share to the 38% RAM usage (PMAP log > attached). Is this a GStreamer bug or a memory leak? Can anyone help me to > fix this? > > Currently I'm using the mp3 playback with the following pipeline > $gst-launch filesrc location=test.mp3 ! queue ! mad ! alsasink > > Any help on this is highly appreciated. > > Thank you, > Gireesh > > > ------------------------------------------------------------------------- > 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 > Gst...@li... > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded > > |
|
From: Jan S. <th...@ma...> - 2008-04-14 10:55:44
|
<quote who="Gireesh Kumar M"> > Hi, > > I'm running GStreamer, built with CodeSourcery arm toolchain [version: > (CodeSourcery Sourcery G++ Lite 2007q3-51) 4.2.1], on TI's OMAP board. > The runtime memory consumption (as reported by 'top' command) is 38% on a > 128MB RAM (~48MBytes), which is very high. Verifying the memory map log > (using pmap), I found the presence of some un-named memory blocks of size > 8188 KBytes which contributes major share to the 38% RAM usage (PMAP log > attached). Is this a GStreamer bug or a memory leak? Can anyone help me to > fix this? I'd guess they're probably thread stacks. I think the default is 8MB, but you can make it smaller, possibly by using g_thread_create_full in the right places in GStreamer core (in gsttask.c somewhere) J. > Currently I'm using the mp3 playback with the following pipeline > $gst-launch filesrc location=test.mp3 ! queue ! mad ! alsasink > > Any help on this is highly appreciated. > > Thank you, > Gireesh > > > /home/gst-gireesh/gstreamer/bin/gst-launch-0.10(320) > 00008000 (16 KB) r-xp (00:0d 1669206) /home/gst-gireesh/gstreamer/bin/gst-launch-0.10 > 00013000 (4 KB) rw-p (00:0d 1669206) /home/gst-gireesh/gstreamer/bin/gst-launch-0.10 > 00014000 (1452 KB) rwxp (00:00 0) [heap] > 40000000 (112 KB) r-xp (00:0d 2502123) /lib/ld-2.5.so > 4001c000 (24 KB) rw-p (00:00 0) > 40023000 (8 KB) rw-p (00:0d 2502123) /lib/ld-2.5.so > 40025000 (592 KB) r-xp (00:0d 1102627) /home/gst-gireesh/gstreamer/lib/libgstreamer-0.10.so.0.10.0 > 400b9000 (32 KB) ---p (00:0d 1102627) /home/gst-gireesh/gstreamer/lib/libgstreamer-0.10.so.0.10.0 > 400c1000 (12 KB) rw-p (00:0d 1102627) /home/gst-gireesh/gstreamer/lib/libgstreamer-0.10.so.0.10.0 > 400c4000 (4 KB) rw-p (00:00 0) > 400c5000 (232 KB) r-xp (00:0d 1102632) /home/gst-gireesh/gstreamer/lib/libgobject-2.0.so.0.1200.4 > 400ff000 (32 KB) ---p (00:0d 1102632) /home/gst-gireesh/gstreamer/lib/libgobject-2.0.so.0.1200.4 > 40107000 (4 KB) rw-p (00:0d 1102632) /home/gst-gireesh/gstreamer/lib/libgobject-2.0.so.0.1200.4 > 40108000 (12 KB) r-xp (00:0d 1685611) /home/gst-gireesh/gstreamer/lib/libgthread-2.0.so.0.1200.4 > 4010b000 (32 KB) ---p (00:0d 1685611) /home/gst-gireesh/gstreamer/lib/libgthread-2.0.so.0.1200.4 > 40113000 (4 KB) rw-p (00:0d 1685611) /home/gst-gireesh/gstreamer/lib/libgthread-2.0.so.0.1200.4 > 40114000 (8 KB) r-xp (00:0d 1685622) /home/gst-gireesh/gstreamer/lib/libgmodule-2.0.so.0.1200.4 > 40116000 (32 KB) ---p (00:0d 1685622) /home/gst-gireesh/gstreamer/lib/libgmodule-2.0.so.0.1200.4 > 4011e000 (4 KB) rw-p (00:0d 1685622) /home/gst-gireesh/gstreamer/lib/libgmodule-2.0.so.0.1200.4 > 4011f000 (8 KB) r-xp (00:0d 2502098) /lib/libdl-2.5.so > 40121000 (28 KB) ---p (00:0d 2502098) /lib/libdl-2.5.so > 40128000 (4 KB) r--p (00:0d 2502098) /lib/libdl-2.5.so > 40129000 (4 KB) rw-p (00:0d 2502098) /lib/libdl-2.5.so > 4012a000 (596 KB) r-xp (00:0d 1685596) /home/gst-gireesh/gstreamer/lib/libglib-2.0.so.0.1200.4 > 401bf000 (32 KB) ---p (00:0d 1685596) /home/gst-gireesh/gstreamer/lib/libglib-2.0.so.0.1200.4 > 401c7000 (4 KB) rw-p (00:0d 1685596) /home/gst-gireesh/gstreamer/lib/libglib-2.0.so.0.1200.4 > 401c8000 (80 KB) r-xp (00:0d 2502115) /lib/libpthread-2.5.so > 401dc000 (28 KB) ---p (00:0d 2502115) /lib/libpthread-2.5.so > 401e3000 (4 KB) r--p (00:0d 2502115) /lib/libpthread-2.5.so > 401e4000 (4 KB) rw-p (00:0d 2502115) /lib/libpthread-2.5.so > 401e5000 (8 KB) rw-p (00:00 0) > 401e7000 (1100 KB) r-xp (00:0d 2502090) /lib/libc-2.5.so > 402fa000 (32 KB) ---p (00:0d 2502090) /lib/libc-2.5.so > 40302000 (4 KB) r--p (00:0d 2502090) /lib/libc-2.5.so > 40303000 (8 KB) rw-p (00:0d 2502090) /lib/libc-2.5.so > 40305000 (12 KB) rw-p (00:00 0) > 40308000 (24 KB) r-xp (00:0d 2502114) /lib/librt-2.5.so > 4030e000 (28 KB) ---p (00:0d 2502114) /lib/librt-2.5.so > 40315000 (4 KB) r--p (00:0d 2502114) /lib/librt-2.5.so > 40316000 (4 KB) rw-p (00:0d 2502114) /lib/librt-2.5.so > 40317000 (1160 KB) r-xp (00:0d 1685687) /home/gst-gireesh/gstreamer/lib/libxml2.so.2.6.26 > 40439000 (32 KB) ---p (00:0d 1685687) /home/gst-gireesh/gstreamer/lib/libxml2.so.2.6.26 > 40441000 (20 KB) rw-p (00:0d 1685687) /home/gst-gireesh/gstreamer/lib/libxml2.so.2.6.26 > 40446000 (4 KB) rw-p (00:00 0) > 40447000 (888 KB) r-xp (00:0d 1685378) /home/gst-gireesh/gstreamer/lib/libiconv.so.2.4.0 > 40525000 (28 KB) ---p (00:0d 1685378) /home/gst-gireesh/gstreamer/lib/libiconv.so.2.4.0 > 4052c000 (4 KB) rw-p (00:0d 1685378) /home/gst-gireesh/gstreamer/lib/libiconv.so.2.4.0 > 4052d000 (644 KB) r-xp (00:0d 2502092) /lib/libm-2.5.so > 405ce000 (28 KB) ---p (00:0d 2502092) /lib/libm-2.5.so > 405d5000 (4 KB) r--p (00:0d 2502092) /lib/libm-2.5.so > 405d6000 (4 KB) rw-p (00:0d 2502092) /lib/libm-2.5.so > 405d7000 (44 KB) r-xp (00:0d 2502109) /lib/libgcc_s.so.1 > 405e2000 (28 KB) ---p (00:0d 2502109) /lib/libgcc_s.so.1 > 405e9000 (4 KB) rw-p (00:0d 2502109) /lib/libgcc_s.so.1 > 405ea000 (36 KB) r-xp (00:0d 2502117) /lib/libnss_files-2.5.so > 405f3000 (28 KB) ---p (00:0d 2502117) /lib/libnss_files-2.5.so > 405fa000 (4 KB) r--p (00:0d 2502117) /lib/libnss_files-2.5.so > 405fb000 (4 KB) rw-p (00:0d 2502117) /lib/libnss_files-2.5.so > 405fc000 (140 KB) r-xp (00:0d 2717769) /home/gst-gireesh/gstreamer/lib/gstreamer-0.10/libgstcoreelements.so > 4061f000 (28 KB) ---p (00:0d 2717769) /home/gst-gireesh/gstreamer/lib/gstreamer-0.10/libgstcoreelements.so > 40626000 (8 KB) rw-p (00:0d 2717769) /home/gst-gireesh/gstreamer/lib/gstreamer-0.10/libgstcoreelements.so > 40628000 (136 KB) r-xp (00:0d 1102629) /home/gst-gireesh/gstreamer/lib/libgstbase-0.10.so.0.10.0 > 4064a000 (28 KB) ---p (00:0d 1102629) /home/gst-gireesh/gstreamer/lib/libgstbase-0.10.so.0.10.0 > 40651000 (4 KB) rw-p (00:0d 1102629) /home/gst-gireesh/gstreamer/lib/libgstbase-0.10.so.0.10.0 > 40652000 (60 KB) r-xp (00:0d 2717682) /home/gst-gireesh/gstreamer/lib/gstreamer-0.10/libgstmad.so > 40661000 (32 KB) ---p (00:0d 2717682) /home/gst-gireesh/gstreamer/lib/gstreamer-0.10/libgstmad.so > 40669000 (4 KB) rw-p (00:0d 2717682) /home/gst-gireesh/gstreamer/lib/gstreamer-0.10/libgstmad.so > 4066a000 (24 KB) r-xp (00:0d 1685581) /home/gst-gireesh/gstreamer/lib/libgsttag-0.10.so.0.8.0 > 40670000 (28 KB) ---p (00:0d 1685581) /home/gst-gireesh/gstreamer/lib/libgsttag-0.10.so.0.8.0 > 40677000 (4 KB) rw-p (00:0d 1685581) /home/gst-gireesh/gstreamer/lib/libgsttag-0.10.so.0.8.0 > 40678000 (84 KB) r-xp (00:0d 1685600) /home/gst-gireesh/gstreamer/lib/libmad.so.0.2.1 > 4068d000 (28 KB) ---p (00:0d 1685600) /home/gst-gireesh/gstreamer/lib/libmad.so.0.2.1 > 40694000 (4 KB) rw-p (00:0d 1685600) /home/gst-gireesh/gstreamer/lib/libmad.so.0.2.1 > 40695000 (112 KB) r-xp (00:0d 1685668) /home/gst-gireesh/gstreamer/lib/libid3tag.so.0.3.0 > 406b1000 (28 KB) ---p (00:0d 1685668) /home/gst-gireesh/gstreamer/lib/libid3tag.so.0.3.0 > 406b8000 (8 KB) rw-p (00:0d 1685668) /home/gst-gireesh/gstreamer/lib/libid3tag.so.0.3.0 > 406ba000 (72 KB) r-xp (00:0d 2717683) /home/gst-gireesh/gstreamer/lib/gstreamer-0.10/libgstalsa.so > 406cc000 (28 KB) ---p (00:0d 2717683) /home/gst-gireesh/gstreamer/lib/gstreamer-0.10/libgstalsa.so > 406d3000 (4 KB) rw-p (00:0d 2717683) /home/gst-gireesh/gstreamer/lib/gstreamer-0.10/libgstalsa.so > 406d4000 (724 KB) r-xp (00:0d 2211260) /home/gst-gireesh/gstreamer/lib/libasound.so.2.0.0 > 40789000 (32 KB) ---p (00:0d 2211260) /home/gst-gireesh/gstreamer/lib/libasound.so.2.0.0 > 40791000 (16 KB) rw-p (00:0d 2211260) /home/gst-gireesh/gstreamer/lib/libasound.so.2.0.0 > 40795000 (28 KB) r-xp (00:0d 1685618) /home/gst-gireesh/gstreamer/lib/libgstinterfaces-0.10.so.0.8.0 > 4079c000 (28 KB) ---p (00:0d 1685618) /home/gst-gireesh/gstreamer/lib/libgstinterfaces-0.10.so.0.8.0 > 407a3000 (4 KB) rw-p (00:0d 1685618) /home/gst-gireesh/gstreamer/lib/libgstinterfaces-0.10.so.0.8.0 > 407a4000 (88 KB) r-xp (00:0d 1685645) /home/gst-gireesh/gstreamer/lib/libgstaudio-0.10.so.0.8.0 > 407ba000 (32 KB) ---p (00:0d 1685645) /home/gst-gireesh/gstreamer/lib/libgstaudio-0.10.so.0.8.0 > 407c2000 (4 KB) rw-p (00:0d 1685645) /home/gst-gireesh/gstreamer/lib/libgstaudio-0.10.so.0.8.0 > 407c3000 (4 KB) ---p (00:00 0) > 407c4000 (8188 KB) rwxp (00:00 0) > 40fc3000 (4 KB) ---p (00:00 0) > 40fc4000 (8188 KB) rwxp (00:00 0) > 417c3000 (4 KB) ---p (00:00 0) > 417c4000 (8188 KB) rwxp (00:00 0) > 41fc3000 (4 KB) ---p (00:00 0) > 41fc4000 (8188 KB) rwxp (00:00 0) > 427c3000 (4 KB) ---p (00:00 0) > 427c4000 (8188 KB) rwxp (00:00 0) > beeb0000 (84 KB) rwxp (00:00 0) [stack] > mapped: 50460 KB writable/private: 42684 KB shared: 0 KB > ------------------------------------------------------------------------- > 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 > Gst...@li... > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded -- Jan Schmidt th...@ma... If Darl McBride had his way, he would have banned marriage too, because it obviously is against the remunerative interests of prostitutes - Bruce Perens |
|
From: Gireesh K. M <gir...@gm...> - 2008-04-14 08:17:47
|
/home/gst-gireesh/gstreamer/bin/gst-launch-0.10(320) 00008000 (16 KB) r-xp (00:0d 1669206) /home/gst-gireesh/gstreamer/bin/gst-launch-0.10 00013000 (4 KB) rw-p (00:0d 1669206) /home/gst-gireesh/gstreamer/bin/gst-launch-0.10 00014000 (1452 KB) rwxp (00:00 0) [heap] 40000000 (112 KB) r-xp (00:0d 2502123) /lib/ld-2.5.so 4001c000 (24 KB) rw-p (00:00 0) 40023000 (8 KB) rw-p (00:0d 2502123) /lib/ld-2.5.so 40025000 (592 KB) r-xp (00:0d 1102627) /home/gst-gireesh/gstreamer/lib/libgstreamer-0.10.so.0.10.0 400b9000 (32 KB) ---p (00:0d 1102627) /home/gst-gireesh/gstreamer/lib/libgstreamer-0.10.so.0.10.0 400c1000 (12 KB) rw-p (00:0d 1102627) /home/gst-gireesh/gstreamer/lib/libgstreamer-0.10.so.0.10.0 400c4000 (4 KB) rw-p (00:00 0) 400c5000 (232 KB) r-xp (00:0d 1102632) /home/gst-gireesh/gstreamer/lib/libgobject-2.0.so.0.1200.4 400ff000 (32 KB) ---p (00:0d 1102632) /home/gst-gireesh/gstreamer/lib/libgobject-2.0.so.0.1200.4 40107000 (4 KB) rw-p (00:0d 1102632) /home/gst-gireesh/gstreamer/lib/libgobject-2.0.so.0.1200.4 40108000 (12 KB) r-xp (00:0d 1685611) /home/gst-gireesh/gstreamer/lib/libgthread-2.0.so.0.1200.4 4010b000 (32 KB) ---p (00:0d 1685611) /home/gst-gireesh/gstreamer/lib/libgthread-2.0.so.0.1200.4 40113000 (4 KB) rw-p (00:0d 1685611) /home/gst-gireesh/gstreamer/lib/libgthread-2.0.so.0.1200.4 40114000 (8 KB) r-xp (00:0d 1685622) /home/gst-gireesh/gstreamer/lib/libgmodule-2.0.so.0.1200.4 40116000 (32 KB) ---p (00:0d 1685622) /home/gst-gireesh/gstreamer/lib/libgmodule-2.0.so.0.1200.4 4011e000 (4 KB) rw-p (00:0d 1685622) /home/gst-gireesh/gstreamer/lib/libgmodule-2.0.so.0.1200.4 4011f000 (8 KB) r-xp (00:0d 2502098) /lib/libdl-2.5.so 40121000 (28 KB) ---p (00:0d 2502098) /lib/libdl-2.5.so 40128000 (4 KB) r--p (00:0d 2502098) /lib/libdl-2.5.so 40129000 (4 KB) rw-p (00:0d 2502098) /lib/libdl-2.5.so 4012a000 (596 KB) r-xp (00:0d 1685596) /home/gst-gireesh/gstreamer/lib/libglib-2.0.so.0.1200.4 401bf000 (32 KB) ---p (00:0d 1685596) /home/gst-gireesh/gstreamer/lib/libglib-2.0.so.0.1200.4 401c7000 (4 KB) rw-p (00:0d 1685596) /home/gst-gireesh/gstreamer/lib/libglib-2.0.so.0.1200.4 401c8000 (80 KB) r-xp (00:0d 2502115) /lib/libpthread-2.5.so 401dc000 (28 KB) ---p (00:0d 2502115) /lib/libpthread-2.5.so 401e3000 (4 KB) r--p (00:0d 2502115) /lib/libpthread-2.5.so 401e4000 (4 KB) rw-p (00:0d 2502115) /lib/libpthread-2.5.so 401e5000 (8 KB) rw-p (00:00 0) 401e7000 (1100 KB) r-xp (00:0d 2502090) /lib/libc-2.5.so 402fa000 (32 KB) ---p (00:0d 2502090) /lib/libc-2.5.so 40302000 (4 KB) r--p (00:0d 2502090) /lib/libc-2.5.so 40303000 (8 KB) rw-p (00:0d 2502090) /lib/libc-2.5.so 40305000 (12 KB) rw-p (00:00 0) 40308000 (24 KB) r-xp (00:0d 2502114) /lib/librt-2.5.so 4030e000 (28 KB) ---p (00:0d 2502114) /lib/librt-2.5.so 40315000 (4 KB) r--p (00:0d 2502114) /lib/librt-2.5.so 40316000 (4 KB) rw-p (00:0d 2502114) /lib/librt-2.5.so 40317000 (1160 KB) r-xp (00:0d 1685687) /home/gst-gireesh/gstreamer/lib/libxml2.so.2.6.26 40439000 (32 KB) ---p (00:0d 1685687) /home/gst-gireesh/gstreamer/lib/libxml2.so.2.6.26 40441000 (20 KB) rw-p (00:0d 1685687) /home/gst-gireesh/gstreamer/lib/libxml2.so.2.6.26 40446000 (4 KB) rw-p (00:00 0) 40447000 (888 KB) r-xp (00:0d 1685378) /home/gst-gireesh/gstreamer/lib/libiconv.so.2.4.0 40525000 (28 KB) ---p (00:0d 1685378) /home/gst-gireesh/gstreamer/lib/libiconv.so.2.4.0 4052c000 (4 KB) rw-p (00:0d 1685378) /home/gst-gireesh/gstreamer/lib/libiconv.so.2.4.0 4052d000 (644 KB) r-xp (00:0d 2502092) /lib/libm-2.5.so 405ce000 (28 KB) ---p (00:0d 2502092) /lib/libm-2.5.so 405d5000 (4 KB) r--p (00:0d 2502092) /lib/libm-2.5.so 405d6000 (4 KB) rw-p (00:0d 2502092) /lib/libm-2.5.so 405d7000 (44 KB) r-xp (00:0d 2502109) /lib/libgcc_s.so.1 405e2000 (28 KB) ---p (00:0d 2502109) /lib/libgcc_s.so.1 405e9000 (4 KB) rw-p (00:0d 2502109) /lib/libgcc_s.so.1 405ea000 (36 KB) r-xp (00:0d 2502117) /lib/libnss_files-2.5.so 405f3000 (28 KB) ---p (00:0d 2502117) /lib/libnss_files-2.5.so 405fa000 (4 KB) r--p (00:0d 2502117) /lib/libnss_files-2.5.so 405fb000 (4 KB) rw-p (00:0d 2502117) /lib/libnss_files-2.5.so 405fc000 (140 KB) r-xp (00:0d 2717769) /home/gst-gireesh/gstreamer/lib/gstreamer-0.10/libgstcoreelements.so 4061f000 (28 KB) ---p (00:0d 2717769) /home/gst-gireesh/gstreamer/lib/gstreamer-0.10/libgstcoreelements.so 40626000 (8 KB) rw-p (00:0d 2717769) /home/gst-gireesh/gstreamer/lib/gstreamer-0.10/libgstcoreelements.so 40628000 (136 KB) r-xp (00:0d 1102629) /home/gst-gireesh/gstreamer/lib/libgstbase-0.10.so.0.10.0 4064a000 (28 KB) ---p (00:0d 1102629) /home/gst-gireesh/gstreamer/lib/libgstbase-0.10.so.0.10.0 40651000 (4 KB) rw-p (00:0d 1102629) /home/gst-gireesh/gstreamer/lib/libgstbase-0.10.so.0.10.0 40652000 (60 KB) r-xp (00:0d 2717682) /home/gst-gireesh/gstreamer/lib/gstreamer-0.10/libgstmad.so 40661000 (32 KB) ---p (00:0d 2717682) /home/gst-gireesh/gstreamer/lib/gstreamer-0.10/libgstmad.so 40669000 (4 KB) rw-p (00:0d 2717682) /home/gst-gireesh/gstreamer/lib/gstreamer-0.10/libgstmad.so 4066a000 (24 KB) r-xp (00:0d 1685581) /home/gst-gireesh/gstreamer/lib/libgsttag-0.10.so.0.8.0 40670000 (28 KB) ---p (00:0d 1685581) /home/gst-gireesh/gstreamer/lib/libgsttag-0.10.so.0.8.0 40677000 (4 KB) rw-p (00:0d 1685581) /home/gst-gireesh/gstreamer/lib/libgsttag-0.10.so.0.8.0 40678000 (84 KB) r-xp (00:0d 1685600) /home/gst-gireesh/gstreamer/lib/libmad.so.0.2.1 4068d000 (28 KB) ---p (00:0d 1685600) /home/gst-gireesh/gstreamer/lib/libmad.so.0.2.1 40694000 (4 KB) rw-p (00:0d 1685600) /home/gst-gireesh/gstreamer/lib/libmad.so.0.2.1 40695000 (112 KB) r-xp (00:0d 1685668) /home/gst-gireesh/gstreamer/lib/libid3tag.so.0.3.0 406b1000 (28 KB) ---p (00:0d 1685668) /home/gst-gireesh/gstreamer/lib/libid3tag.so.0.3.0 406b8000 (8 KB) rw-p (00:0d 1685668) /home/gst-gireesh/gstreamer/lib/libid3tag.so.0.3.0 406ba000 (72 KB) r-xp (00:0d 2717683) /home/gst-gireesh/gstreamer/lib/gstreamer-0.10/libgstalsa.so 406cc000 (28 KB) ---p (00:0d 2717683) /home/gst-gireesh/gstreamer/lib/gstreamer-0.10/libgstalsa.so 406d3000 (4 KB) rw-p (00:0d 2717683) /home/gst-gireesh/gstreamer/lib/gstreamer-0.10/libgstalsa.so 406d4000 (724 KB) r-xp (00:0d 2211260) /home/gst-gireesh/gstreamer/lib/libasound.so.2.0.0 40789000 (32 KB) ---p (00:0d 2211260) /home/gst-gireesh/gstreamer/lib/libasound.so.2.0.0 40791000 (16 KB) rw-p (00:0d 2211260) /home/gst-gireesh/gstreamer/lib/libasound.so.2.0.0 40795000 (28 KB) r-xp (00:0d 1685618) /home/gst-gireesh/gstreamer/lib/libgstinterfaces-0.10.so.0.8.0 4079c000 (28 KB) ---p (00:0d 1685618) /home/gst-gireesh/gstreamer/lib/libgstinterfaces-0.10.so.0.8.0 407a3000 (4 KB) rw-p (00:0d 1685618) /home/gst-gireesh/gstreamer/lib/libgstinterfaces-0.10.so.0.8.0 407a4000 (88 KB) r-xp (00:0d 1685645) /home/gst-gireesh/gstreamer/lib/libgstaudio-0.10.so.0.8.0 407ba000 (32 KB) ---p (00:0d 1685645) /home/gst-gireesh/gstreamer/lib/libgstaudio-0.10.so.0.8.0 407c2000 (4 KB) rw-p (00:0d 1685645) /home/gst-gireesh/gstreamer/lib/libgstaudio-0.10.so.0.8.0 407c3000 (4 KB) ---p (00:00 0) 407c4000 (8188 KB) rwxp (00:00 0) 40fc3000 (4 KB) ---p (00:00 0) 40fc4000 (8188 KB) rwxp (00:00 0) 417c3000 (4 KB) ---p (00:00 0) 417c4000 (8188 KB) rwxp (00:00 0) 41fc3000 (4 KB) ---p (00:00 0) 41fc4000 (8188 KB) rwxp (00:00 0) 427c3000 (4 KB) ---p (00:00 0) 427c4000 (8188 KB) rwxp (00:00 0) beeb0000 (84 KB) rwxp (00:00 0) [stack] mapped: 50460 KB writable/private: 42684 KB shared: 0 KB |
|
From: Stefan K. <en...@ho...> - 2008-04-13 20:18:23
|
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: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...
> <mailto: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...>
> [mailto:gst...@li...
> <mailto:gst...@li...>] *On
> Behalf Of *Vijay
> *Sent:* Monday, April 07, 2008 8:32 PM
> *To:* gst...@li...
> <mailto: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
>
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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
> Gst...@li...
> https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded
|
|
From: Zhao Liang-E. <E3...@mo...> - 2008-04-11 01:39:29
|
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
|
|
From: Vijay <vij...@gm...> - 2008-04-10 13:38:36
|
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
>
|
10 messages has been excluded from this view by a project administrator.
