Eyevinn / srt-whep

SRT to WHEP (WebRTC)
Apache License 2.0
80 stars 10 forks source link

Failed to generate WHIP offer for streams generated by ffmpeg #44

Closed Wkkkkk closed 1 year ago

Wkkkkk commented 1 year ago

Sometimes no offer is seen from added WhipSink element and this blocks the pipeline afterwards. As Jonas guesses, it might relate to the time joining the MPEG-TS stream.

It is also strange that it happens more often if SRT stream is generated with ffmpeg (less frequently with gstreamer). Most likely some parameters are not correctly set and need to be fixed.

Wkkkkk commented 1 year ago

Latest commits tried to solve this problem. And it runs well in most cases.

While testing, it is noticed that when we run in caller mode and connect to a FFMpeg souce stream (listener). No offer will be generated. However, this happens on MacOS and Ubuntu but not in Docker container.

Source Mode Pass-Through WHEP
GStreamer Caller X X
GStreamer Listener X X
FFMpeg Caller X -
FFMpeg Listener X X
OBS Caller X -
OBS Listener X X


Wkkkkk commented 1 year ago

One possible fix is to reverse the SRT mode with another pipeline. For example, if our input SRT stream is in listener mode. We connect to it with command:

gst-launch-1.0 srtsrc uri="srt://127.0.0.1:1234?mode=caller" ! queue ! srtsink uri="srt://127.0.0.1:1235?mode=caller" wait-for-connection=false

Then we run our tool as 'listener'

GST_DEBUG=1 cargo run -- -i 127.0.0.1:1235 -o 127.0.0.1:8888 -p 8000 -s listener | bunyan
Wkkkkk commented 1 year ago

After some debugging it turns out that this is due to some queue elements blocking the pipeline. To avoid that, we turned on property can-activate-pull in fakesink (so it actively consumes buffers in the pipeline). In addition, we increased the max size of some queue elements.

After some tests, it works well with all tools and different SRT modes.