question about RTP_FORWARD from video room to streaming plugin. No video sometimes. Race condition?

[Kaplan]

Hi Janusers,

I am running into a rare issue sometimes which I think might be a race condition. 

1) I am creating a video room and joining as a publisher

2) when I get the "joined" event, I start rtp_forwarding the publisher id from this room to another Janus server. This is before the getUserMedia completes.

3) from the success callback of the rtp_forward command, I issue a create stream on the remote Janus.

Most of the time, video flows fine to the streaming plugin. but sometimes I get no video. I wonder if I am doing things out of order....

I am under the impression that you start forwarding video from a publisher even before you complete the media handshake.  May be the create stream command should happen BEFORE we start rtp forwarding??

Any help appreciated...

[Lorenzo Miniero]

As far as I know, there's no race condition possible in those cases. RTP forwarders are simply "used": if one is available when a packet arrives, then the packet is sent there too. Have you checked whether or not the creation simply fails in some cases and the error is not handled?

Lorenzo

[Kaplan]

Yeah, the streams got created OK (got the notification from Janus).

Will it make a difference if I create the streaming plugin's stream 1st, then start the rtp_fwd to it in ters of users being able to watch the forwarded video? 

What I am seeing is that the video resolution for viewers say width: 2, height: 2  when connecting to the streaming plugin on the remote Janus server. 

When it works (most of the time), the resolution comes in correctly (say w:2560. h:1440). this is a screenshare being rtp_forwarded from the video room to the streaming plug in...

[Kaplan]

What I mean is that I have a "playing" event fired from the html video element (which is wirted to the streaming plugin stream).

When it does "not work", we see a width: 2, height:2 reported from the playing event. I.e. something does play, but I guess is 2x2 :)

So may be the streaming plugin missed the keyframe?  The room has a FIR rate of 5...

[Lorenzo Miniero]

It doesn't matter if you create the streaming mountpoint after forwarding, packets are sent anyway, they're just dropped until there's someone listening in case. Of course viewers will need a keyframe before they can see something: you can try using the bufferkf setting in streaming mountpoints to have it store the latest keyframe for new users (will result in a static image until the actual keyframe arrives). As to the 2x2 thing, not sure what causes that, as we don't touch the frames: maybe there's something else sending data to the same mountpoint?

L.

[Kaplan]

It turned out that the issue was that the presenter's connection never got the "webrtcState" ON from Janus, so I guess the handshake never completed...

It seems to happen when we share a large screen, say w:2560. h:1440..  For now I fixed it by adding a timer to check for webrtcState to be on after the screenshare started, say 7 seocnds into it. And if it we don't get the message from Janus regarding webrtcState being "on", we alert the presenter and stop the share.

I am trying to figure out 

1) Why the webrtcState fails to complete (stopping and starting the screenshare  fixes it)

2) is there a way to "retry" the connection for the screenshare video room, without having the user to manually click on the Chrome extension's "share" button?  

(i.e. I tried to resend the sendOffer, but that brings up the Chrome extension dialog...)

Is there a point further in the handshake that I can retry to have the webrtcState to be ON?  may be "configure" ?

[Lorenzo Miniero]

You may want to look at Admin API and or events from handlers to see why it's happening from the Janus perspective. It might be either a problem with ICE or DTLS.

L.

[Kaplan]

cool, will do, thanks...

What about auto-retrying? is there a point in the handshake from the javascript side of the screenshare demo where I can retry the whole thing automatically?

i.e.  repeat the createOffer, or the "publish" message or the configure message on the same janus handle?  the handle connects fine in these cases, it just the peerconnection that seems to fail...

[Lorenzo Miniero]

You can pulish/unpublish multiple times on the same handle, as long as it's a new peerconnection for each publish (so for each configure+SDP). The only way to avoid the screen/desktop selection from appearing again is having control of the MediaStream, and passing that one to the new PeerConnection: if you're using janus.js, this means doing the getUserMedia on your own and passing the stream to the createOffer/createAnswer instead of having janus.js do the getUserMedia itself. This is needed because, if janus.js does getUserMedia, it will destroy the MediaStream when the PC is closed.

L.

[Kaplan]

Thanks Lorenzo!