[gst-devel] How to determine buffer size arriving at the sink

[Tiago Katcipis]

i found out that i was misunderstanding the progressreport and actually the
blocksize was working, and now i understand a little better my problem. When
i use an audioparse on my plugin the blocksize parameter is ignored on
filesrc and gnomevfssrc, i used identity + -v and already made a
debu=filesrc:5 and when there is a audioparse on the pipe the size read by
the sources seens to always be 4096. Is there an explanation for this?

best regards,
Katcipis

On Fri, Aug 7, 2009 at 12:01 PM, Tiago Katcipis <katcipis at inf.ufsc.br>wrote:

> My problem seens to be simple but im having some problem on resolving it.
> Im streaming audio but when i use an alaw decoder the size of the audio
> packets that arrive at my appsink are enormous (something like 10k each
> buffer) and this is giving me some problems, i want to determine the size of
> the buffers that arrives at appsink, but appsink blocksize property seens to
> be completely useless, and the filesrc / gnomevfssrc blocksize seens to be
> useless to, the size os my buffers dont change when i use blocksize. It is
> interesting that when i use decodebin on adpcm ima the size of the buffers
> are small (great for me), it seens that someone on decodebin for ima adpcm
> does this for me, but i cant do it on alaw decoding.
>
> i started to try some things and i noticed this:
>
> gst-launch audiotestsrc ! progressreport ! appsink
>
> this launch will report 5 seconds each, but if i run this
>
> gst-launch audiotestsrc ! progressreport ! appsink sync=false
>
> it will report thousands of seconds each buffer. It has something to do
> with the clock but im not being able to control it. can someone give me a
> lead on the best way to determine the size of the arriving buffer on my
> appsink ?
>
> best regards
> Katcipis
>
> --
> "it might be a profitable thing to learn Java, but it has no intellectual
> value whatsoever" Alexander Stepanov
>



-- 
"it might be a profitable thing to learn Java, but it has no intellectual
value whatsoever" Alexander Stepanov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20090811/c42fdebf/attachment.htm>