[Bug 740683] rtspsrc: add retransmission handling for rtp

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Wed Nov 26 16:26:31 PST 2014


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

--- Comment #3 from Matthew Waters <ystreet00 at gmail.com> 2014-11-27 00:26:24 UTC ---
(In reply to comment #2)
> Review of attachment 291452 [details]:
> 
> Good job, I've been wanting this for a while! I wonder if we can set the
> retranmission delay on rtpjitterbuffer based on the rtx-time in the SDP, I
> couldn't find anything obvious.

You'd need to get the jitterbuffer for the rtspstream and then get the rtx-time
attribute from the ptmapitem of the rtx stream and set that on the
jitterbuffer.

> ::: gst/rtsp/gstrtspsrc.c
> @@ +198,3 @@
>  #define DEFAULT_TLS_VALIDATION_FLAGS     G_TLS_CERTIFICATE_VALIDATE_ALL
>  #define DEFAULT_TLS_DATABASE     NULL
> +#define DEFAULT_DO_RETRANSMISSION        FALSE
> 
> Any reason to default to false?

Because we override the request-aux-receiver signal and the application might
want to do its own thing with that signal.

> @@ +3170,3 @@
> +  if (g_signal_lookup ("request-aux-receiver",
> +          G_OBJECT_TYPE (src->manager)) == 0)
> +    return;
> 
> rtspsrc and rtpbin are both in gst-plugins-good, we don't support mixing
> different parts of different versions of the same package.

There's also rdt in -ugly that might be used which doesn't support the
request-aux-receiver signal.

> @@ +3209,3 @@
> +  g_object_set (src->manager, "do-retransmission", TRUE, NULL);
> +
> +  /* enable RFC4588 retransmission handling by setting rtprtxreceive
> 
> Would it make sense to skip this if there are no RTX payloads in the SDP ? (and
> skip the connect too)

Maybe, although even if there are no rtx streams and do-retransmision=true, the
rtxreceive essentially just passes through each rtp buffer.  I'm not sure its
worth the complexity to be honest.

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


More information about the gstreamer-bugs mailing list