rtspsrc jitterbuffer stats

[Sebastian Dröge]

On Mon, 2016-11-21 at 10:09 -0800, Victor Weinstein wrote:
> 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.

That's not a good idea as rtpjitterbuffer is used inside the rtpbin
inside rtspsrc, and not just for buffering.

> 
> 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?

No, it still does its job. Just without waiting. What you really want
is to get access to the rtpbin and rtpjitterbuffer that are inside
rtspsrc and then implement your stuff on top of that.

> 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?

The number of packets that were considered lost because they didn't
arrive (at all or in time).

>   b) does num-duplicates mean that the last frame sent was duplicated when
> the buffer ran dry?

The number of packets that were received multiple times from the
network.

> 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.

Currently the rtpjitterbuffer has infinite size in packets, but will
not have more than latency amount of time stored (unless downstream
fails to consume packets in real-time).

-- 
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20161123/8650b71a/attachment.sig>