Hi, I am a bit confused by this element. I though we where going to move all of this into RTPRECV? You also say that the depayloader base class doesn't do ordering, but it actually does (it dosen't remove duplicates though). So are we moving all of this to RTPRECV or making a new element? I vote for putting it in RTPRECV like we agreed. Let me know so I can update the Ticket.
Laterz, Burger On Mon, 12 Dec 2005 14:32:31 +0200 (EET) Kai Vehmanen <[EMAIL PROTECTED]> wrote: > Hello all, > > based on last week's discussions on #farsight, I've written down some > improvement items for the gst RTP support. Here's the first one. The items > are divided into urgent items (something we must have), and more long-term > stuff (which would be nice to have already now, but without which one can > still build VoIP/conferencing apps). > > For background, see: > http://gstreamer.freedesktop.org/documentation/rtp.html > http://bugzilla.gnome.org/show_bug.cgi?id=323017 > > Please comment either on the list, or IRC (I'll comment and summarize the > feedback). > > Codec independent playout buffer element (prio:urgent) > ------------------------------------------------------ > > A gstreamer element that takes in application/x-rtp buffers and stores > them in a playout (jitter) buffer. The buffer will contain the packets > sorted by RTP-timestamp and RTP-seqno, with duplicates removed. This > is essentially the functionality that is not provided by > gst-plugins-base-0.10/gst-libs/gst/rtp/gstbasertpdepayload.c > > The element will have a separate thread that schedules out packets for > playout at the pipeline sink. The element will monitor the frequency of > incoming packets, and use this information to select a proper sleep > interval. > > The element should be able to detect overrun and underrun situations > caused by clock-drift between the sender and the receiver (sink in > the pipeline the playout buffer is part) > > Rationale: > - Separate element is used instead of gstbasertpdepayload.c > because the codec might change mid-stream and so the > playout buffer should be able to contain packets > for multiple codecs at the same time. > - A separate thread is needed to ensure packets are > scheduled even in the case no packets are > received from the network (pause of X msecs is fatal if X > is larger than the size of sink element buffers). > > -- > 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
