SRT passphrase and latency parameters

Nicolas Dufresne nicolas at ndufresne.ca
Mon Apr 23 16:25:33 UTC 2018


Le lundi 23 avril 2018 à 11:53 +0000, Marcus Pennington a écrit :
> Hi all,
> 
> We've been playing with the new SRT plugins as part of gst-plugins-
> bad and all seems well apart from a couple of features.
> 
> Using it like so on the client (sender):
> ... srtclientsink passphrase=eb55dec3c22f4e0879baadfe2fd50151
> uri=srt://10.10.10.10:6000...
> 
> And on the server (listener):
> ... srtserversrc passphrase=eb55dec3c22f4e0879baadfe2fd50151
> uri=srt://:6000...
> 
> The first one being the passphrase parameter. At first, I assumed it
> was working fine and the stream was encrypted, but after accidentally
> setting the wrong password on the srtserversrc, to my surprise, the
> stream sill worked. After some investigation, it seems that it works
> with or without a passphrase, even if the passphrase is set on the
> srtclientsink.

Could you open a ticket on bugs.gnome.org, this is possibly miss-
implemented in the GStreamer wrapper.

> 
> I've tried everything it feels like to try and get this to work, this
> includes:
> - Setting the key-length to 16 even though that's the default
> - Trying the other key-lengths
> - Wrapping the passphrase in "quotes"
> - Using different passphrases with different lengths
> - Using only integers for the passphrase instead
> ... all on both sides of the pipeline.
> 
> However, it always seems that the stream is being sent unencrypted.
> Even with debug level set on both plugins, there are no complaints or
> logs to suggest anything is wrong.
> I've scoured the web for examples but none can be found where the
> passphrase is being used. So I'm now thinking there is either a bug
> or we are doing something incorrectly here.
> If we are doing something wrong, then I would have thought that
> something should at least error or give a warning, rather than allow
> the stream to go through unencrypted...
> 
> Another thing I'd like some clarification on is the latency
> parameter. In the documentation for the SRT plugins, it's described
> as:
> 
> Minimum latency (milliseconds)
> 
> Is this correct? I would have thought it would be Maximum latency
> like it is described here:
> https://github.com/Haivision/srt/blob/master/docs/stransmit.md

It is set to what we call min latency inside GStreamer. In GStreamer,
maximum latency is local, it's the duration of data an element can
queue before dropping or blocking. Just set the same on both side,
that's what matter. Due to a limitation in GStreamer wrapper, always
add a queue downstream the srt sources.

> 
> If there is anyone would be able to help or could just point in the
> direction of some examples, that would be fantastic!
> 
> Many thanks,
> Marcus Pennington
> -- 
> Marcus Pennington
> Developer
> Sohonet 
> 5 Soho St, London
> W1D 3DG
> +44 7930 853 530
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20180423/caecf832/attachment.sig>


More information about the gstreamer-devel mailing list