Hey guys!
   As most of you know that i have already started the attempt to
implement some of the ideas of Kai, which he has put as tickets on
http://projects.collabora.co.uk/farsight/ . I have stared with
ticekt#5 (Codec independent playout buffer element) or rtpjitterbuffer
(a name me and Kai agreed on). This element is mostly about moving the
jitter-buffer from the basertpdepayload into a new element with some
'codec independent' functionalities added.

   While writing the element, i came accross a problem:
basertpdepayload uses a variable 'clock-rate' for deciding the amount
of time a packet remains in the buffer/queue. This variable is
codec-dependent and it's value is provided by the elements inheriting
from basertpdepayload.

    I discussed with burger about this issue and we decided that we
need to have a number of sources (not in the sense of gstreamer) for
this value:

1. From caps set on the sink or src pad (we shouldn't care which
direction it came from)

2. From a static table, mapping payload-types to value of clock-rate.
This won't work for most of the codecs as they dont work on fixed
clock-rate.

3. From a property, so the pipeline owner (most likely the app.
developer) can do the magic for us.

   I have already implemented all three mentioned above, haven't
built/tested it though. Kai pointed out that an event might be a
better idea than #1 above. Can anyone (burger?) comment on this
possibility?

--
Regards,

Zeeshan Ali


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Farsight-devel mailing list
Farsight-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/farsight-devel

Reply via email to