rtspsrc jitterbuffer stats

Victor Weinstein victor.weinstein at qsc.com
Mon Nov 21 18:09:06 UTC 2016


I would like to be able to tune my pipeline which uses an rtspsrc element to
smooth out frame delivery and to add latency to prevent duplicate or missed
frames.  The rtspsrc element implements buffering with configurable latency,
buffer-mode, and drop-on-latency parameters.  However, in order to read back
buffering, it appears that I need to disable buffering in the rtspsrc by
setting latency to 0 and adding an rtpjitterbuffer element immediately after
the rtspsrc, i.e.

Change 
rtspsrc location=rtsp://... latency=50 ! ... 
to
rtspsrc location=rtsp://... latency=0 ! rtpjitterbuffer latency=50 ! ...

I am able to read back the percent property of the rtpjitterbuffer in this
way, as well as the stats property of the rtpjitterbuffer.

The stats are quite limited however, there is a recent commit that provides
better statistics, see  rtpjitterbuffer: Add and expose more stats and
increase testing of it
<https://cgit.freedesktop.org/gstreamer/gst-plugins-good/commit/?id=1b868cc9b18cb9b51c6fcbd67ccaf12f4a7cc8ca>  

The commit message states:
Add num-pushed and num-lost. Expose num-late, num-duplicates and avg-jitter.

My questions are these:

1) Does setting the latency to 0 in the rtspsrc element effectively disable
buffering or is there some additional overhead associated with having two
jitter buffers in the pipeline if I add the rtpjitterbuffer element
immediately downstream of the rtspsrc?

2) What are the meanings of the statistics available?
  a) does num-lost = the number of packets dropped because the buffer was
full or the latency was too high?
  b) does num-duplicates mean that the last frame sent was duplicated when
the buffer ran dry?

The behavior I'm looking for is for the buffer to never exceed a certain
depth and for the last frame to be resent if the buffer runs empty or hits
its minimum depth.  I would like to know how many frames were dropped due to
the buffer reaching its size limit and the number of frames that were resent
due to the buffer running empty.  It seems like in order to do this, I need
to use the rtpjitterbuffer element and apply the commit to my gstreamer
source tree (assuming that those updated stats provide the dropped and
resent information I'm looking for).  It would also be highly desirable to
resend the same frame when the buffer runs empty or hits its minimum depth.

Thanks for your help, feel free to let me know if I'm barking up the wrong
tree,
Victor



--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/rtspsrc-jitterbuffer-stats-tp4680812.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.


More information about the gstreamer-devel mailing list