Hey, I like the table idea alot :) I also insist on changing the name of this element since it really IS NOT a jitter buffer :) it's a queuing, reordering, dropping, timestamp setting buffer. But we are hoping to get rid of the thread one day and the jitter control is mostly done by the sink. It's good to be coherent with the usage of names.
I suggest some name with playout buffer, or queue. Laterz Burger On Wed, 21 Dec 2005 22:11:24 +0200 (EET) Kai Vehmanen <[EMAIL PROTECTED]> wrote: > On Wed, 21 Dec 2005, Zeeshan Ali wrote: > > > 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. > > This problem was further discussed at #farsight today, and the conclusion > was that we need to provide this information already at rtprecv. > > Currently, information available from RTP headers (timestamp, > payload-type, etc) is parsed by gstrtpbuffer.h and stored for each buffer. > But some information needed in processing RTP packets cannot be found out > from the headers. > > This information includes: > - mapping of payload-types (RTP-header field) to codecs (note: the > fixed PTs 0-95 in RFC3551 are an exception) > - clock rate and channel count > - codec parameters > > Some of this information can be collected at depay/decoding time, but not > in all cases. For example, for L8, there are no limits for clock-rate, nor > channel count, nor payload-type. This information is however needed by > numerous gst elements: rtpjitterbuf (clock-rate), depay/decoder (codec > params), and the sink (clock/sample-rate). > > So the consensus was (me, rob, zeeshan), that application should provide a > "pt<->caps" table to rtpbin (and to rtprecv), which allows rtprecv to > attach this out-of-band agreed information to buffers it pushes out. > > Notes: > - spec for how to pass this information in caps: > gst-plugins-good-cvs/gst/rtp/README > > Open issues: > - how to manage conflicts - clock-rate set by the app to 44100, > but pipeline has elements which are fixed to 8000... what > happens? > > PS Yep, once the ticket system is back up, this has to be added there... > > -- > under work: Sofia-SIP at http://sofia-sip.sf.net > > > ------------------------------------------------------- > 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_id=7637&alloc_id=16865&op=click > _______________________________________________ > Farsight-devel mailing list > Farsight-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/farsight-devel ------------------------------------------------------- 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_id=7637&alloc_id=16865&op=click _______________________________________________ Farsight-devel mailing list Farsight-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/farsight-devel
