Redirecting the RTP stream via webrtc is unchanged.

Hello, everyone. I’ve been going through the past FEC discussions. I realized that you are waiting for FlexFEC. It is already approved RFC 8627 - RTP Payload Format for Flexible Forward Error Correction (FEC). But my question is not about that. I have an RTP video stream with ulpfec encoding. For example gst-launch-1.0 videotestsrc ! x264enc ! video/x-h264, profile=baseline ! rtph264pay pt=96 ! rtpulpfecenc percentage=100 pt=122 ! udpsink port=8888. If I use mediasoup to transfer this encoded RTP video stream over webrtc to a web browser client (only one client per stream).
Questions:

  1. Can I add the necessary parameters a=rtpmap:116 red/90000 a=rtpmap:117 ulpfec/90000 to the SDP file so that the browser understands how to decode it?
  2. Will the web browser client get the same stream with ulpfec encoded packets? In other words, will this scheme work or will the server reject the encoded packets?

Assuming you lie mediasoup by calling transport.produce() with a supported video codec but then you send RTP with encoded ULPFEC payload, then it happens that mediasoup knows about VP8, VP9, H264 and H264_SVC codecs, and if the RTP payloads don’t contain those expected encodings, result can only be wrong, specially if simulcast or SVC are enabled. But probably also in single stream without termporal layers. Honestly I cannot say exactly what it would happen because I should check too much code. But in summary: no, it won’t work.

And in client side, mediasoup-client won’t generate remote SDPs with ULPFEC support.

Okay, thanks for the answer. Do you have any plans to implement flexfec in the near future? You talked about these plans a few years ago.

I’ve created the task but no immediate plans at all. Too busy.

1 Like