[Share]I've successfully find the ffmpeg copy-mode rtp stream publish command

Integration
1

Scenario: ffmpeg publisher → mediasoup SFU server → chrome web page receiver

Previouly i tried the command from RTP (II): Streaming with FFmpeg - Kurento below:

ffmpeg -re \
    -i video.mp4 \
    -an \
    -c:v copy \
    -f rtp \
    -sdp_file video.sdp \
    "rtp://192.168.1.109:5004"

But it does not work, mediasoup server log indicates that it seemed web page receiver send a RTCP PLI for keyframe, but blocked since ffmpeg command line did’t response correctly

But this is NOT the case, i use the new command to do RTP push stream successfully(code in nodejs):

  const callRTPStreamPushCmd = `ffmpeg -re \
  -i ${input_mp4_filepath} \
  -v info \
  -codec copy \
  -bsf:v h264_mp4toannexb -an -deadline realtime \
  -map 0:v:0 \
  -f tee \
  "[select=v:f=rtp:ssrc=${VIDEO_SSRC}:payload_type=${VIDEO_PT}]rtp://127.0.0.1:${videoRtpPort}?rtcpport=${videoRtcpPort}"`

The key point here is: mediasoup server requires SSRC and PayloadType paramters from publisher client, which i really don’t get the reason behind this: because in Janus streaming demo, I only need the videoRtpPort to do RTP streaming push. (SSRC and PayloadType should be bound to rtp port in service-side config, and no need to require client to pass in)

But since mediasoup requires this, the publish url “rtp://…” has to put a […] prefix string which contains the SSRC and PayloadType paramters, and due to this, i have to use the ffmpeg -f tee output format and -f tee further requires a -map 0:v:0 option.

That’s it.

2

When saying copy-mode rtp stream push, i mean publisher client’s input is constrained baseline encoded H264 stream (NALU slices), and so should not needed to do libx264 re-encode…

3

So that’s conclusion is just based on the fact that in Janus you don’t need to specify payload type and ssrc, right? So then how would mediasoup allow simulcast and RTX in PlainTransports? Or should mediasoup not implement them in PlainTransport just because it would be a bit easier to use ffmpeg?

4

Your words mix the basic usage and advanced usage, API design should have a simple way to differentiate them. There are no unsolvable conflicts inherently.

5

You don’t need to pass encodings array in RTP parameters if there is just one. Re-check the “RTP parameters and capabilities” section in the website.