broadcasting a vp8 rtp stream from gstreamer

Ohhhhhh

static void
rtp_session_process_pli (RTPSession * sess, guint32 sender_ssrc,
    guint32 media_ssrc, GstClockTime current_time)
{
  RTPSource *src;

  if (!sess->callbacks.request_key_unit)
    return;

  src = find_source (sess, sender_ssrc);
  if (src == NULL)
    return;

  rtp_session_request_local_key_unit (sess, src, media_ssrc, FALSE,
      current_time);
}

That’s indeed wrong. It’s just looking at the sender ssrc.

Ok, if you please can try tomorrow with the change I said and confirm it works, we may just apply it to mediasoup to make it works with “wrong” clients (I assume that setting the sender ssrc to != 0 will not harm other RTP clients such as libwebrtc).

I’m having the same issue.
Looking forward for your kind solution

The solution is already given above. If you can test and confirm it works we’ll commit it to mediasoup.

Confirmed: it works with GStreamer 1.14.1.

Thanks for the confirmation @vpalmisano.

i was talking about a flow in which no rtcp back channel exists

picture-id-mode=1 indeed solved the problem, it worked even without the rtpbin (which is needed for rtcp)

Sender SSRC is now filled with the media SSRC value in FIR and PLI requests.

New version of mediasoup has been released.

What does picture-id-mode=1 exactly mean in GStreamer?

https://tools.ietf.org/html/rfc7741#section-4.2

Question: I know what VP8 picture-id is but, why is it required in GStreamer when no simulcast is used?

I don’t know exactly. Leaving picture-id-mode to the default value doesn’t allow the receiver to consume the produced vp8 flow and the same using vp9. With ffmpeg there is no need to set anything.

Interesting. May it be related to the lack of “extended” bit in the VP8 payload? We rely on it to continue parsing the payload and detect whether it’s a keyframe:

/cc @jmillan