Streams take too long to load in Streaming Plugin

[cabada]

Hello , I have a problem with the Streaming Plugin.

The streams are taking too long to start playing. Sometimes the streams take 45 seconds to load, sometimes even more than a minute. (Counting this seconds after candidate has responded with “completed”) (Once they connect they are flowing smoothly perfectly “forever”)

I’ve tested it in code I’ve made on my own and in the demo that the Janus package makes. Both take a lot of time to load.

I’ll explain my whole setup, I’m using Video Room and Streaming Plugin.

1. I have publishers that are in a Video Room
2. For every publisher I create a Streaming Room, like this
3. Then I forward the publisher’s streams via rtp_forward to this Streaming Room
4. Then viewers should have the stream available using the Streaming Plugin

But that’s where I’m having problems… When someone starts watching the stream, it takes forever for the Stream to arrive, I’ve debugged a lot and here is some info:

• Whenever I request to watch a stream, this warning gets thrown:
  Failed to add some remote candidates (added 0, expected 1) and Failed to add some remote candidates (added 1, expected 2)

• DTLS handshake does completes successfully, I do receive webrtcup and completed candidates. It does it really fast actually. I get printed:
  The DTLS handshake has been completed

• After DTLS handshake I’m getting:
  No candidates not gathered yet for stream??

Also…

One of the things gets my attention, is that when the stream info is received (before it plays), the track arrives “muted”. Which I don’t think this “muted” thing has to do with “audio” (muted - webrtc docs)

But it definitely has nothing to do with “muting the streaming” on purpose, since I have multiple videos opened and I can tell stream is not muted.

After 30-60 seconds the video feed comes to live and stays there “forever”, and I get a log about the track being “unmuted”:

Once it plays, it plays very good. But the amount of time it takes to start the stream seems that something is wrong.

Here is a screenshot of the streaming website logs:

What could be the cause of this delay?

Some other useful information:

• I’m running the 1.1.3 version of Janus Gateway, I cloned the Github and installed it from there 2-3 weeks ago.
• When the streaming starts connecting the N kbits/sec shows activity for like a couple milliseconds, and then it freezes at a X kbits/sec, as soon as the video starts playing it unfreezes and starts displaying good Y kbits/sec.
• I’m running it in full-trickle with personal STUN and TURN servers
• I’ve added the nat_1_1_mapping with the public IP of the server, in case that was the issue

This is how I’m creating the streaming room:

{
    request: "create",
    id,
    name,
    description,
    permanent:false,
    type: "rtp",
    is_private: false,
    media:[
       {type: "video", mid: "v", label: "video", pt: 100, port: 6000, codec:"vp8"},
       {type: "audio", mid: "a", label: "audio", pt: 111, port: 6001, codec:"opus"}
    ]
}

This is how I’m forwarding the streams:

{
	request: "rtp_forward",
	room,
	host,
	host_family: "ipv4"
	publisher_id,
	streams:[
		{ host, pt:111, mid:audiomid, port:audioport },
		{ host, pt:100, mid:videomid, port:videoport }
	]
}

Thanks in advance

[lorenzo (Lorenzo Miniero)]

You need to enable RTCP in the Streaming mountpoint, and configure RTCP in the forwarder accordingly, otherwise any keyframe request by Streaming subscribers won’t be relayed to the VideoRoom publisher via RTCP.

[cabada]

Thanks for the reply. This worked perfectly.

Now streams play practically instantly just after the DTLS handshake

Tyvm