Problem with Streaming Video over HTTPS on headless Ubuntu

[CeDoMain]

Hello there,

i have a problem with streaming a webcam over https with VLC (on linux) to an VLC client (on Windows). The whole thing works pretty cool with http but if i use TLS, the client (seems to connect but) do not display any video.

The Server (headless) is under Ubuntu Server 20.04 LTS with VLC 3.0.9.2 installed. X is installed but deactivated in bootloader.
The Client is under Windows 10 with 3.0.10 installed.

This combination works (HTTP):

Code: Select all

On Server: cvlc v4l2:///dev/video0:width=640:height=480:fps=30 --sout '#transcode{vcodec=h264,venc=x264{preset=fast,tune=zerolatency,intra-refresh,lookahead=10,keyint=15},scale=auto,fps=30,acodec=mpga,ab=128}:standard{access=http,mux=ts,dst=:35519}' --network-caching 0 On Client (Interface): Ctrl+N > http://xxx.xxx.xxx.xxx:35519 > play

This combination dont work (HTTPS):

Code: Select all

On Server: cvlc v4l2:///dev/video0:width=640:height=480:fps=30 --sout '#transcode{vcodec=h264,venc=x264{preset=fast,tune=zerolatency,lookahead=10,keyint=15},scale=auto,acodec=mpga,ab=128}:standard{access=https,mux=ts,dst=:35519}' --http-cert /home/cedo/Documents/cedoCert.crt --http-key /home/cedo/Documents/cedoKey.key On Client (Interface): Ctrl+N > https://xxx.xxx.xxx.xxx:35519 > play

You can read the -vvv output of the non working command here: https://pastebin.com/EA4Sc2iU

If I open the URL on client VLC the orange bar on the bottom begins to move left and right forever.
In the same Moment these lines appears in the bash on the server:

Code: Select all

[00007f35240038b0] gnutls tls server debug: TLS handshake: Resource temporarily unavailable, try again. [00007f35240038b0] gnutls tls server debug: TLS handshake: Success. [00007f35240038b0] gnutls tls server debug: - safe renegotiation (RFC5746) enabled [00007f35240038b0] gnutls tls server debug: - extended master secret (RFC7627) enabled

Then I can wait many minutes but no video appears in client window - the bar is moving and moving.
If I press the stop button on client interface this red line appears on server bash:

Code: Select all

[00007f35240038b0] gnutls tls server error: Error in the push function.

I have no iptable rules active. I place two rules to log the traffic on Port 35519 an see that the connection between the server and client is established:

Code: Select all

Jun 6 14:07:53 cedo-serv kernel: [70398.222098] IN=enp0s25 OUT= MAC=xxx SRC=xxx DST=xxx LEN=286 TOS=0x00 PREC=0x00 TTL=120 ID=18657 DF PROTO=TCP SPT=52230 DPT=35519 WINDOW=516 RES=0x00 ACK PSH URGP=0 Jun 6 14:07:53 cedo-serv kernel: [70398.222162] IN= OUT=enp0s25 SRC=xxx DST=xxx LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=42396 DF PROTO=TCP SPT=35519 DPT=52230 WINDOW=501 RES=0x00 ACK URGP=0 Jun 6 14:07:53 cedo-serv kernel: [70398.248022] IN= OUT=enp0s25 SRC=xxx DST=xxx LEN=2242 TOS=0x00 PREC=0x00 TTL=64 ID=42397 DF PROTO=TCP SPT=35519 DPT=52230 WINDOW=501 RES=0x00 ACK PSH URGP=0 Jun 6 14:07:53 cedo-serv kernel: [70398.266643] IN=enp0s25 OUT= MAC=xxx SRC=xxx DST=xxx LEN=40 TOS=0x00 PREC=0x00 TTL=120 ID=18658 DF PROTO=TCP SPT=52230 DPT=35519 WINDOW=516 RES=0x00 ACK URGP=0 Jun 6 14:07:53 cedo-serv kernel: [70398.267929] IN=enp0s25 OUT= MAC=xxx SRC=xxx DST=xxx LEN=166 TOS=0x00 PREC=0x00 TTL=120 ID=18659 DF PROTO=TCP SPT=52230 DPT=35519 WINDOW=516 RES=0x00 ACK PSH URGP=0 Jun 6 14:07:53 cedo-serv kernel: [70398.267952] IN= OUT=enp0s25 SRC=xxx DST=xxx LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=42399 DF PROTO=TCP SPT=35519 DPT=52230 WINDOW=501 RES=0x00 ACK URGP=0 Jun 6 14:07:53 cedo-serv kernel: [70398.267990] IN=enp0s25 OUT= MAC=xxx SRC=xxx DST=xxx LEN=203 TOS=0x00 PREC=0x00 TTL=120 ID=18660 DF PROTO=TCP SPT=52230 DPT=35519 WINDOW=516 RES=0x00 ACK PSH URGP=0 Jun 6 14:07:53 cedo-serv kernel: [70398.268005] IN= OUT=enp0s25 SRC=xxx DST=xxx LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=42400 DF PROTO=TCP SPT=35519 DPT=52230 WINDOW=501 RES=0x00 ACK URGP=0 Jun 6 14:07:53 cedo-serv kernel: [70398.268574] IN= OUT=enp0s25 SRC=xxx DST=xxx LEN=91 TOS=0x00 PREC=0x00 TTL=64 ID=42401 DF PROTO=TCP SPT=35519 DPT=52230 WINDOW=501 RES=0x00 ACK PSH URGP=0 Jun 6 14:07:53 cedo-serv kernel: [70398.328820] IN=enp0s25 OUT= MAC=xxx SRC=xxx DST=xxx LEN=40 TOS=0x00 PREC=0x00 TTL=120 ID=18661 DF PROTO=TCP SPT=52230 DPT=35519 WINDOW=515 RES=0x00 ACK URGP=0

What can I do to get my stream working? What is the problem? I hope you can help me. If you need more Information please tell me.

Thanks,
CeDoMain

[Rémi Denis-Courmont]

This is a bug in the VLC server-side TLS code.

[CeDoMain]

Ohh, this is sad. Is this bug known by the developer team an will be solved in the near future? If not, where can I report this bug? Any workaround to create an encrypted and secured transmission?

Thanks for your fast reply!

[Rémi Denis-Courmont]

Should be fixed in 3.0.11.

[CeDoMain]

Thanks! I found your Ticket in the Bug Tracker.
I found this too: https://trac.videolan.org/vlc/ticket/7528 Possible duplicate?

[georgesovetov]

Hello,

It seems the same problem (HTTP works, HTTPS stucks after a handshake) happened to me.

Rémi Denis-Courmont, thank you for the fix! But the problem can still be reproduced on VLC 3.0.11 and Windows 10. Does that mean that the fix on its way to the next version or it's already in and I'm doing something wrong?

[CeDoMain]

For me this wont work too in 3.0.11 on Linux Ubuntu. As an "workaround" i am using snap and load the beta branch. There the bug seems to be fixed. Hope this can help you on W10 too.

[georgesovetov]

I confirm, the latest nightly build https://artifacts.videolan.org/vlc-3.0/ ... 0708-0643/ works!

Code: Select all

C:\Users\gsovetov\develop\vlc-https>ffprobe https://127.0.0.1:8443/qwe.mpjpeg -hide_banner Input #0, mpjpeg, from 'https://127.0.0.1:8443/qwe.mpjpeg': Duration: N/A, bitrate: N/A Stream #0:0: Video: mjpeg (Baseline), yuvj420p(pc, bt470bg/unknown/unknown), 1920x1080 [SAR 1:1 DAR 16:9], 25 tbr, 25 tbn, 25 tbc

[harmonylan]

Hi


Every body, I'm trying to make an https stream of screen://
For that i'm using C/C++ & the libvlc ...

I'm not sur to be in the good topic, but it seem speak about streaming overt https ...

It seem to be complicated to used the https.
When i'm trying to pass ssl params like ca-cert, i'm getting in the log :

Warning: option --http-ca no longer exists.
Warning: option --http-ca no longer exists.
.....

HTTP/TLS certificate not specified!

This is the same thing if i'm passing directly by the sout like "http{access=https{cert=C:\Sert\cert.pem,key=C:\Sert\ca-key.pem,ca=C:\Sert\ca-req.pem,crl=C:\Sert\ca-cert.srl}"
All the "cert", "key", "crl" appear unknow options ...

After some research on the google engine if found that : https://mailman.videolan.org/pipermail/ ... 26690.html
According to this document, ssl seem deprecated because not used by many people


I'm asking to Videolan community if in 2020, we could alway use https stream output ? And How ?
Thanks you

[Wyk]

On Windows VLC and after much monkeying around trying different versions and parameters, I'm finally able to get my stuff working over https using a legit Let's Encrypt certificate.
In my case I'm transcoding the audio portion of an RTSP feed and making it available as a low-bandwidth (6K per second) mp3 stream.

Critically, the only v3 version that worked for me was the v3 nightly build as of the time of this post - v3.0.11.1 Vetinari found here -> https://artifacts.videolan.org/vlc-3.0/ ... 1104-0620/ . Note: I did not try any version 4 betas just that v3 nightly. Hopefully v4 will have this working code in it too!

Here's was what worked

Code: Select all

vlc rtsp://192.168.0.27 :sout=#transcode{vcodec=none,acodec=mp3,ab=48,channels=1,samplerate=22050}:http{access=https,dst=:108/live.mp3} :sout-keep --http-cert C:\certificate\certificate.crt --http-key C:\certificate\certificate.key