Srt: Source has to connect first?

Created on 14 Aug 2019  路  18Comments  路  Source: Haivision/srt

I am trying to use SRT to stream from a mobile device to a streaming server using OBS in the Cloud. All works fine when connecting the mobile source first (the machine sending the stream over SRT) and than open the source in OBS. But when the Source is open in OBS, it will crash the code...

````
Media path: 'srt://:1234' --> 'srt://:5678'
Parameters:
mode = 'listener'
Opening SRT source listener on :1234

Binding a server on :1234 ...
listen...

Parameters:
mode = 'listener'
Opening SRT target listener on :5678

Binding a server on :5678 ...
listen...

accept...
connected.

Accepted SRT target connection

ERROR #5004: Operation not supported: Invalid socket ID.

ERROR: error: recvmsg: Operation not supported: Invalid socket ID.
SrtCommon: DESTROYING CONNECTION, closing sockets (rt%1053978103 ls%-1)...

SrtCommon: ... done.

SrtCommon: DESTROYING CONNECTION, closing sockets (rt%-1 ls%1053978105)...

SrtCommon: ... done.

21:21:04.318150!!FATAL!!:SRT.c: CChannel reported ERROR DURING TRANSMISSION - IPE. INTERRUPTING worker anyway.
21:21:04.421479!!FATAL!!:SRT.c: CChannel reported ERROR DURING TRANSMISSION - IPE. INTERRUPTING worker anyway.
````

High Bug [apps]
Source
picture mrsydster

Most helpful comment

Just FYI - I'm working on it. It seems that the application shouldn't have a problem with working with both source and target being SRT listeners, but somehow it doesn't handle this case.

picture ethouris on 8 May 2020
❤3

All 18 comments

A few questions:

  • What do you mean by "OBS in the Cloud"? Is that the name of a service you are using, or is it just an instance of OBS that you are running on your own VPS?
  • So, assuming you're trying to stream from your phone to an instance of OBS on a cloud server -- how are you adding the SRT stream to OBS? What type of source are you using?
  • When you say "it will crash the code", what exactly do you mean? Does OBS itself crash? Or does the streaming client on your mobile device crash? Or something else?
dodgepong picture dodgepong on 15 Aug 2019

A few questions:

  • What do you mean by "OBS in the Cloud"? Is that the name of a service you are using, or is it just an instance of OBS that you are running on your own VPS?
  • So, assuming you're trying to stream from your phone to an instance of OBS on a cloud server -- how are you adding the SRT stream to OBS? What type of source are you using?
  • When you say "it will crash the code", what exactly do you mean? Does OBS itself crash? Or does the streaming client on your mobile device crash? Or something else?

@dodgepong Thanks for helping me out:

I am running an OBS. It actually does not matter weather it runs in the cloud or not for testing.

I am streaming to SRT using my phone (Larix Broadcaster) then catch that stream using a VLC source in OBS.

OBS does not crash when I start the VLC source first. But the 'stransmit -k -v -s:5000 -r:5000 'srt://:1234' 'srt://:5678'' part does as seen above!

mrsydster picture mrsydster on 15 Aug 2019

Does it work when using VLC by itself to play the SRT stream on the same box as OBS?

dodgepong picture dodgepong on 15 Aug 2019

yes it does. Only if i connect the camera first (make sure it is streaming) than the OBS source. If i open obs first, it will crash srt

mrsydster picture mrsydster on 15 Aug 2019

So, to be clear, this is what you have experienced:

  • Start streaming first, then open standalone VLC and connect: works
  • Open standalone VLC and connect first, then start streaming: works
  • Start streaming first, then open OBS with VLC source set to connect: works
  • Open OBS with VLC source set to connect first, then start streaming: server crashes

Is that accurate?

dodgepong picture dodgepong on 15 Aug 2019

Open standalone VLC and connect first, then start streaming: works

This also makes the server crash

mrsydster picture mrsydster on 15 Aug 2019

Open standalone VLC and connect first, then start streaming: works
This also makes the server crash

@mrsydster So, in this very case you use the following pipeline, right?
[UDP stream] ---UDP--> srt-live-transmit --(SRT)--> VLC ---> Playback

maxsharabayko picture maxsharabayko on 16 Aug 2019

@mrsydster So, in this very case you use the following pipeline, right?
[UDP stream] ---UDP--> srt-live-transmit --(SRT)--> VLC ---> Playback

[SRT stream using Larix Broadcaster] ---(SRT)--> srt-live-transmit --(SRT)--> OBS---> Playback using VLC Source in OBS

mrsydster picture mrsydster on 18 Aug 2019

Just for getting more information, please try to use srt-test-live in this configuration instead with the same parameter list. To make it compiled with the library, you need an extra --enable-testing option (-DENABLE_TESTING=ON in cmake). If it also fails the same way, then please compile also with --enable-heavy-logging option and then use -ll:debug option additionally for the application with redirecting 2 (stderr) to a file (or specify a logfile using -lf option).

ethouris picture ethouris on 19 Sep 2019

I'm also having this same issue. Steps I'm taking in my case:

  1. Start SRT with: srt-live-transmit -s 100 -v -f srt://:4000 srt://:9000.
  2. Connect via VLC using Open Network Stream -> srt://hostname:9000.

If I start the source first (I'm using ffmpeg in my case) the srt-live-transmit works successfully and I see video as expected in VLC. I can connect and disconnect VLC multiple times, and srt-live-transmit doesn't crash.

SRT version: 1.4.1 running on Arch Linux. VLC version: 3.0.8 on Windows.

Console log looks like this:

$ srt-live-transmit -s 100 -v -f srt://:4000 srt://:9000
Media path: 'srt://:4000' --> 'srt://:9000'
Opening SRT source listener on :4000
Binding a server on :4000 ...
 listen...
Opening SRT target listener on :9000
Binding a server on :9000 ...
 listen...
 accept...
 connected.
Accepted SRT target connection
ERROR: error: recvmsg: Operation not supported: Invalid socket ID
SrtCommon: DESTROYING CONNECTION, closing sockets (rt%873748243 ls%-1)...
SrtCommon: ... done.
SrtCommon: DESTROYING CONNECTION, closing sockets (rt%-1 ls%873748245)...
SrtCommon: ... done.

Attempting to run srt-test-live -s 100 -v -f srt://:4000 srt://:9000 prints the usage, running it with only the -v options appears to run fine, but VLC seems unable to connect, repeating the following in the logs:
access_srt debug: Schedule SRT connect (dest addresss: hostname, port: 9001).

console output from srt-test-live:

$ srt-test-live -v srt://:4000 srt://:9000
Opening SRT source listener(blocking) on :4000
Binding a server on :4000 ...
 listen...  accept...  accept...
dfloer picture dfloer on 22 Feb 2020

I've also had the same issue with a VLC video source in OBS and using ffmpeg to connect to srt-live-transmit when there is no source connected. I'm trying to use srt-live-transmit to accept a connection from a remote client and have OBS connect, but needing the source to connect or else it crashes isn't going to work.

Here's what srt-live-transmit -v -ll:debug srt://:4000 srt://:9000 reports when I connect VLC to it with heavy logging enabled in cmake (VLC client, no source):
10:55:42.401382/srt-live-transm D:SRT.c: ... not waiting longer - timeout 10:55:42.401398/srt-live-transm D:SRT.c: CEPoll::wait: START for eid=1 10:55:42.401403/srt-live-transm D:SRT.c: CEPoll::wait: REPORTED 0/0 10:55:42.401411/srt-live-transm D:SRT.c: CEPoll::wait: LINUX: picking up 0 ready fds. 10:55:42.401417/srt-live-transm D:SRT.c: CEPoll::wait: Total of 0 READY SOCKETS 10:55:42.411513/srt-live-transm D:SRT.c: CEPoll::wait: EVENT WAITING: CHECKPOINT 10:55:42.411525/srt-live-transm D:SRT.c: CEPoll::wait: REPORTED 0/0 10:55:42.411531/srt-live-transm D:SRT.c: CEPoll::wait: LINUX: picking up 0 ready fds. 10:55:42.411538/srt-live-transm D:SRT.c: CEPoll::wait: Total of 0 READY SOCKETS 10:55:42.417026/SRT:RcvQ:worker D:SRT.c: INCOMING PACKET: BOUND=0.0.0.0:9000 TARGET=0 CONTROL: handshake size=48 10:55:42.417076/SRT:RcvQ:worker D:SRT.c: Got sockID=0 from 192.168.0.150:52649 - trying to resolve it as a connection request... 10:55:42.417087/SRT:RcvQ:worker.N:SRT.c: PASSING request from: 192.168.0.150:52649 to agent:944145809 10:55:42.417103/SRT:RcvQ:worker D:SRT.c: processConnectRequest: received a connection request 10:55:42.417116/SRT:RcvQ:worker D:SRT.c: processConnectRequest: new cookie: c1208dd1 10:55:42.417123/SRT:RcvQ:worker D:SRT.c: processConnectRequest: received type=induction, sending back with cookie+socket 10:55:42.417129/SRT:RcvQ:worker D:SRT.c: processConnectRequest: NOT Advertising PBKEYLEN - value = 0 10:55:42.417137/SRT:RcvQ:worker D:SRT.c: CChannel::sendto: SENDING NOW DST=192.168.0.150:52649 target=@482228532 size=48 pkt.ts=16:00:06.387267 type=CONTROL cmd=handshake arg=0 10:55:42.417163/SRT:RcvQ:worker.N:SRT.c: Listener managed the connection request from: 192.168.0.150:52649 result:waveahand 10:55:42.417172/SRT:RcvQ:worker D:SRT.c: worker: result for the unit: INDUCED/CONCLUDING 10:55:42.417179/SRT:RcvQ:worker D:SRT.c: worker: RECEIVED PACKET --> updateConnStatus. cst=INDUCED/CONCLUDING id=0 pkt-payload-size=48 10:55:42.418957/SRT:RcvQ:worker D:SRT.c: INCOMING PACKET: BOUND=0.0.0.0:9000 TARGET=0 CONTROL: handshake size=48 10:55:42.418967/SRT:RcvQ:worker D:SRT.c: Got sockID=0 from 192.168.0.150:52649 - trying to resolve it as a connection request... 10:55:42.418976/SRT:RcvQ:worker.N:SRT.c: PASSING request from: 192.168.0.150:52649 to agent:944145809 10:55:42.418983/SRT:RcvQ:worker D:SRT.c: processConnectRequest: received a connection request 10:55:42.418991/SRT:RcvQ:worker D:SRT.c: processConnectRequest: new cookie: c1208dd1 10:55:42.418996/SRT:RcvQ:worker D:SRT.c: processConnectRequest: received type=conclusion - checking cookie... 10:55:42.419001/SRT:RcvQ:worker D:SRT.c: processConnectRequest: ... correct (ORIGINAL) cookie. Proceeding. 10:55:42.419021/SRT:RcvQ:worker D:SRT.c: newConnection: generated socket id 944145808 10:55:42.419027/SRT:RcvQ:worker D:SRT.c: newConnection: incoming 192.168.0.150:52649, mapping socket 944145808 10:55:42.419037/SRT:RcvQ:worker D:SRT.c: clearData: PAYLOAD SIZE: 1456 10:55:42.419043/SRT:RcvQ:worker D:SRT.c: updateMux: reusing multiplexer for port 9000 10:55:42.419049/SRT:RcvQ:worker D:SRT.c: acceptAndRespond: setting up data according to handshake 10:55:42.419055/SRT:RcvQ:worker D:SRT.c: acceptAndRespond: PAYLOAD SIZE: 1456 10:55:42.419360/SRT:RcvQ:worker D:SRT.c: createCrypter: setting RCV/SND KeyLen=0 10:55:42.419368/SRT:RcvQ:worker D:SRT.c: CCryptoControl::init: HS SIDE:INITIATOR DIRECTION:SENDER 10:55:42.419374/SRT:RcvQ:worker D:SRT.c: CCryptoControl::init: CAN'T CREATE crypto: key length for SND = 0 10:55:42.419394/SRT:RcvQ:worker D:SRT.cc: Creating LiveCC: bw=125000000 avgplsize=1456 10:55:42.419402/SRT:RcvQ:worker D:SRT.cc: LiveCC: sending period updated: 12 (pktsize=1500, bw=125000000 10:55:42.419422/SRT:RcvQ:worker D:SRT.c: setupCC: setting parameters: mss=1500 maxCWNDSize/FlowWindowSize=8192 rcvrate=16p/s (23296B/S) rtt=100000 bw=1 10:55:42.419427/SRT:RcvQ:worker D:SRT.c: updateCC: EVENT:init 10:55:42.419430/SRT:RcvQ:worker D:SRT.cc: LiveCC: sending period updated: 12 (pktsize=1500, bw=125000000 10:55:42.419437/SRT:RcvQ:worker D:SRT.c: updateCC/TEV_INIT: updating BW=-1 (UNCHANGED) 10:55:42.419442/SRT:RcvQ:worker D:SRT.c: udpateCC: emitting signal for EVENT:init 10:55:42.419446/SRT:RcvQ:worker D:SRT.c: updateCC: updated values from congctl: interval=12tk (12us) cgwindow=8.19e+03 10:55:42.419452/SRT:RcvQ:worker D:SRT.c: udpateCC: finished handling for EVENT:init 10:55:42.419456/SRT:RcvQ:worker D:SRT.c: @944145808:setting socket PENDING FOR CONNECTION 10:55:42.419466/SRT:RcvQ:worker D:SRT.c: acceptAndRespond: creating CONCLUSION response (HSv5: with HSRSP/KMRSP) buffer size=1456 10:55:42.419471/SRT:RcvQ:worker D:SRT.c: createSrtHandshake: buf size=1456 hsx=EXT:hsrsp kmx=EXT:kmrsp kmdata_wordsize=0 version=4 10:55:42.419476/SRT:RcvQ:worker D:SRT.c: createSrtHandshake: (no ext) size=48 data: version=4 type=2 ISN=8651016 MSS=1500 FLW=8192 reqtype=conclusion srcID=944145808 cookie=c1208dd1 srcIP=192.168.0.150.0.0.0.0.0.0.0.0.0.0.0.0. 10:55:42.419483/SRT:RcvQ:worker D:SRT.c: %944145808:acceptAndRespond: sending HS to peer, reqtype=conclusion version=4 (connreq:waveahand), target_socket=482228532, my_socket=944145808 10:55:42.419489/SRT:RcvQ:worker D:SRT.c: CChannel::sendto: SENDING NOW DST=192.168.0.150:52649 target=@482228532 size=48 pkt.ts=16:00:00.000000 type=CONTROL cmd=handshake arg=0 10:55:42.419510/SRT:RcvQ:worker D:SRT.c: newConnection: mapping peer 482228532 to that socket (944145808) 10:55:42.419521/SRT:RcvQ:worker.N:SRT.c: listen ret: -1 - conclusion 10:55:42.419526/SRT:RcvQ:worker.N:SRT.c: Listener managed the connection request from: 192.168.0.150:52649 result:waveahand 10:55:42.419532/SRT:RcvQ:worker D:SRT.c: worker: result for the unit: INDUCED/CONCLUDING 10:55:42.419529/srt-live-transm D:SRT.c: CEPoll::wait: EVENT WAITING: TRIGGERED 10:55:42.419537/SRT:RcvQ:worker D:SRT.c: worker: RECEIVED PACKET --> updateConnStatus. cst=INDUCED/CONCLUDING id=0 pkt-payload-size=48 10:55:42.419563/SRT:RcvQ:worker D:SRT.c: @944145808: SOCKET pending for connection - ADDING TO RCV QUEUE/MAP 10:55:42.419552/srt-live-transm D:SRT.c: CEPoll::wait: REPORTED 2/1 944145809:RW 10:55:42.419595/srt-live-transm D:SRT.c: CEPoll::wait: LINUX: picking up 0 ready fds. 10:55:42.419604/srt-live-transm D:SRT.c: CEPoll::wait: Total of 2 READY SOCKETS accept... 10:55:42.419635/srt-live-transm D:SRT.c: %944145809: CLOSE. Acquiring control lock 10:55:42.419646/srt-live-transm D:SRT.c: %944145809: CLOSING (removing from listening, closing CUDT) 10:55:42.419655/srt-live-transm D:SRT.c: %944145809: CLOSING (removing listener immediately) 10:55:42.419678/srt-live-transm D:SRT.c: %944145809: GLOBAL: CLOSING DONE 10:55:42.419686/srt-live-transm D:SRT.c: @944145809 GLOBAL CLOSING: sync-waiting for releasing sender resources... 10:55:42.419692/srt-live-transm D:SRT.c: @944145809 GLOBAL CLOSING: sending buffer disconnected. Allowed to close. connected. Accepted SRT target connection ERROR: error: recvmsg: Operation not supported: Invalid socket ID SrtCommon: DESTROYING CONNECTION, closing sockets (rt%944145808 ls%-1)... 10:55:42.419768/srt-live-transm D:SRT.c: %944145808: CLOSE. Acquiring control lock 10:55:42.419773/srt-live-transm D:SRT.c: %944145808: CLOSING (removing from listening, closing CUDT) 10:55:42.419793/srt-live-transm D:SRT.c: %944145808: - closing socket: 10:55:42.419801/srt-live-transm D:SRT.c: %944145808:CLOSING STATE. Acquiring connection lock 10:55:42.419809/srt-live-transm D:SRT.c: %944145808:CLOSING, removing from listener/connector 10:55:42.419816/srt-live-transm D:SRT.c: %944145808:CLOSING - sending SHUTDOWN to the peer 10:55:42.419837/srt-live-transm D:SRT.c: CChannel::sendto: SENDING NOW DST=192.168.0.150:52649 target=@482228532 size=4 pkt.ts=16:00:00.000782 type=CONTROL cmd=shutdown arg=0 10:55:42.419869/srt-live-transm D:SRT.c: CLOSING, joining send/receive threads 10:55:42.419877/srt-live-transm D:SRT.c: @944145808U::close done. GLOBAL CLOSE: %944145808:. Acquiring GLOBAL control lock 10:55:42.419900/srt-live-transm D:SRT.c: @944145808U::close: Socket MOVED TO CLOSED for collecting later. 10:55:42.419909/srt-live-transm D:SRT.c: %944145808: GLOBAL: CLOSING DONE SrtCommon: ... done. SrtCommon: DESTROYING CONNECTION, closing sockets (rt%-1 ls%944145810)... 10:55:42.419958/srt-live-transm D:SRT.c: %944145810: CLOSE. Acquiring control lock 10:55:42.419967/srt-live-transm D:SRT.c: %944145810: CLOSING (removing from listening, closing CUDT) 10:55:42.419974/srt-live-transm D:SRT.c: %944145810: CLOSING (removing listener immediately) 10:55:42.419982/srt-live-transm D:SRT.c: %944145810: GLOBAL: CLOSING DONE 10:55:42.419999/srt-live-transm D:SRT.c: @944145810 GLOBAL CLOSING: sync-waiting for releasing sender resources... 10:55:42.420007/srt-live-transm D:SRT.c: @944145810 GLOBAL CLOSING: sending buffer disconnected. Allowed to close. SrtCommon: ... done. 10:55:42.420033/SRT:GC D:SRT.c: GC: GLOBAL EXIT - releasing all pending sockets. Acquring control lock... 10:55:42.420047/SRT:GC D:SRT.c: %944145809: - closing socket: 10:55:42.420054/SRT:GC D:SRT.c: %944145809:CLOSING STATE. Acquiring connection lock 10:55:42.420059/SRT:GC D:SRT.c: %944145809:CLOSING, removing from listener/connector 10:55:42.420063/SRT:GC D:SRT.c: CLOSING, joining send/receive threads 10:55:42.420068/SRT:GC D:SRT.c: %944145810: - closing socket: 10:55:42.420073/SRT:GC D:SRT.c: %944145810:CLOSING STATE. Acquiring connection lock 10:55:42.420077/SRT:GC D:SRT.c: %944145810:CLOSING, removing from listener/connector 10:55:42.420082/SRT:GC D:SRT.c: CLOSING, joining send/receive threads 10:55:42.420086/SRT:GC D:SRT.c: GC: GLOBAL EXIT - releasing all CLOSED sockets. 10:55:42.420093/SRT:GC D:SRT.c: GC/removeSocket: closing associated UDT %944145809 10:55:42.420098/SRT:GC D:SRT.c: GC/removeSocket: DELETING SOCKET %944145809 10:55:42.420106/SRT:GC D:SRT.c: GC/removeSocket: closing associated UDT %944145810 10:55:42.420110/SRT:GC D:SRT.c: GC/removeSocket: DELETING SOCKET %944145810 10:55:42.420115/SRT:GC D:SRT.c: MUXER id=944145810 lost last socket %944145810 - deleting muxer bound to port 4000 10:55:42.421307/SRT:RcvQ:worker D:SRT.c: INCOMING PACKET: BOUND=0.0.0.0:9000 TARGET=0 CONTROL: handshake size=48 10:55:42.421324/SRT:RcvQ:worker D:SRT.c: Got sockID=0 from 192.168.0.150:52650 - trying to resolve it as a connection request... 10:55:42.421331/SRT:RcvQ:worker D:SRT.c: AsyncOrRND: no sockets expect connection from 192.168.0.150:52650 - POSSIBLE ATTACK, ignore packet 10:55:42.421338/SRT:RcvQ:worker D:SRT.c: worker: result for the unit: AGAIN 10:55:42.421342/SRT:RcvQ:worker D:SRT.c: worker: packet not dispatched, continuing reading. 10:55:42.432745/SRT:RcvQ:worker D:SRT.c: @944145808: SOCKET broken, REMOVING FROM RCV QUEUE/MAP. 10:55:42.432781/SRT:GC D:SRT.c: GC/removeSocket: closing associated UDT %944145808 10:55:42.432790/SRT:GC D:SRT.c: GC/removeSocket: DELETING SOCKET %944145808 10:55:42.432852/SRT:GC D:SRT.c: MUXER id=944145809 lost last socket %944145808 - deleting muxer bound to port 9000
@maxsharabayko @ethouris Just pinging you to make sure you've seen this.

dfloer picture dfloer on 26 Feb 2020
👍2

BUMP: Getting the same output including errors as mentioned above by @dfloer

mrsydster picture mrsydster on 1 Mar 2020

Same here - It would be really nice to have this work for situations where Rendezvous isn't feasible.

AngusF22 picture AngusF22 on 5 May 2020

Just FYI - I'm working on it. It seems that the application shouldn't have a problem with working with both source and target being SRT listeners, but somehow it doesn't handle this case.

ethouris picture ethouris on 8 May 2020
❤3

The issue has been fixed in the PR #1278. If this problem still occurs on anybody's side, please let us know and do not hesitate to reopen the issue.

mbakholdina picture mbakholdina on 11 May 2020
👍2

Thanks! I quickly tested srt-live-transmit built from master and this appears to have fixed the problem for me.

dfloer picture dfloer on 15 May 2020
👍1

Issue has been resolved for me as well! Thanks

mrsydster picture mrsydster on 15 May 2020
👍1

@dfloer @mrsydster Thanks for confirming!

maxsharabayko picture maxsharabayko on 15 May 2020
Was this page helpful?
0 / 5 - 0 ratings

Related issues

oviano picture oviano  路  6Comments
alexpokotilo picture alexpokotilo  路  3Comments
DmytroIatskyi picture DmytroIatskyi  路  10Comments
Svyatk0 picture Svyatk0  路  5Comments
vandanachadha picture vandanachadha  路  6Comments