[Bug 743945] rtpjitterbuffer: add "do-deadline" property

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=743945
  GStreamer | gst-plugins-good | 1.4.5

--- Comment #15 from Miguel París Díaz <mparisdiaz at gmail.com> 2015-02-04 23:55:37 UTC ---
"You probably want to put sync=true on the sinks for the outgoing RTP
stream"
  Why do I use sync=false?
   I want that my pipeline adds the less possible latency (a "live pipeline")

"Otherwise, as soon as you have a one lost packet in the input stream,
you will cause a big time gap between of duration "latency" in the output
stream."
  I use retransmissions and if the packet is definitely lost I manage the
situation in a downstream element (e.g.: requesting a key-frame if it is
video).
  Moreover, my jitterbuffer is configured with "rtx-max-retries"=0, so only a
retransmission is requested (if needed) and the delay is incremented basing on
the RTT (if I do not remember bad), so the "gap" is not very high.

"as it will make it more likely to have further
dropped packets on the outgoing stream (as you suddenly increase the packet
rate just when you have a loss potentially caused by congestion."
  You are right, and we assume this situation. Why?
    - Because we want very low latency.
    - Because we use bandwidth estimation and bitrate control. Even if the
bandwidth is not the bottleneck, this does not matter.
    - Because we are implementing another behaviour based on not using the
jitterbuffer, depay, pay, and based on mangling RTP packets.

In conclusion, you are right that in the case that you are exposing the
"do-deadline"=FALSE does not make sense, but in other cases as mine I think
that yes.
I do not know if I have explained properly, if not, I do not mind answering
questions, etc. to clarify my case ;)

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.