SRT passphrase and latency parameters

[Marcus Pennington]

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.

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

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

--

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

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
> [phone]
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel