Closed Wkkkkk closed 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 |
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
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.
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.