When I try the gstreamer rtp push by using VP8/Opus encodings (the same as mediasoup-demo/gstreamer.sh at v3 · versatica/mediasoup-demo · GitHub ), not lucky
compare gstreamer with ffmpeg, i guess this gstreamer version is problematic on Mac?
Not weird, I think you’re just sending video that has b-frames, browsers do not support those H264 profiles that have b-frames in WebRTC, so that is an expected behavior (you can lie to the browser about the real profile and it will play the video, but it will be like 1/3 fps of what it should have been). You need “constrained baseline” profile encoding to avoid that issue.
You are right. i add 2 arguments to ffmpeg command line: “-profile baseline -crf 18”, and now the browser-page player plays OK.
But the gstreamer commandline case is still not resolved.
I can’t help every step of the way, but I can assure you, VP8/9, GStreamer and Mediasoup work beautifully in production, there must be something slightly wrong with configuration.
I thought mediasoup may have no problem in server side, but in order to integrate it into a production, the hard part is in usability in client SDK which should be used in custom IoT devices like smart-camera or cloud side container/virtualbox screen capture driver.
Currently there is only a mediasoup-client-aiortc which is based on aiortc (implemented in Python + asyncio), not suitable for high-perf embedded integration case…
since I never got success in using ffmpeg/gstreamer command line RTP push stream,
i hesitate that mediasoup currently force RTCP feedback mode, which is not well supported by ffmpeg/gstreamer?
from log i can see mediasoup server receives PLI request from browser receiver side, but no response from ffmpeg/gstreamer side?
Indeed you must make ffmpeg/gstreamer use same destination RTCP port but you can use different source RTCP port if you set rtcpMux:false in PlainTransport options in mediasoup side. Check the API documentation.