Streaming Demo shows bitrate but no video

[Benjamin Budai]

Hello everybody, I'm trying to get the Janus streaming plugin working, and I started with the streaming demo page. I have Janus running on a Google Compute Engine. I have it set up with NGINX to serve the html, and it has an RTMP server as well, which is what I use to stream to the server from a Raspberry Pi. I can use VLC to watch my raspberry pi's RTMP stream from the server, so I know that part works. I then have FFMPEG on the server transcoding the video to RTP, and passing it to the port where Janus is expecting to find an RTP stream that it can display in the streaming demo. When I start the stream, Janus outputs a line saying "New video stream", and when I try to watch it in the streaming demo it shows a bitrate, so I know some data is getting through at least. However, I can't get it to actually display the video in the browser. I'm using Brave and Chrome to test, with the same results between the two.

Here is my output from Janus: https://pastebin.com/e2KA8ZF1

Here is my output from the Browser console: https://pastebin.com/svEFqAfq

Any help would be very much appreciated. I've spun my wheels on this for a pretty good bit now.

Thanks,

Ben

[Alessandro Toppi]

The connection has been established but the track stays muted.

Probably something is wrong with the bitstream (missing KeyFrame or metadata?). Try to replace your current ffmpeg pipe with a test source to check that everything should work as expected.

[Benjamin Budai]

Ok, I will try that. Thanks for your reply! Sorry I didn't respond for so long.   :)

[Benjamin Budai]

So I've gotten it to kind of work. I changed my ffmpeg command to

ffmpeg -i rtmp://localhost:1935/live/pi -c:v libx264 -preset ultrafast -tune fastdecode -g 1 -f rtp rtp://localhost:8554

I need to learn what the "-g 1" part is for as it works without it, or with different values, but I haven't tested enough yet to see what difference it makes, nor have I read up on what it is supposed to do.

Now I can see my video in the streaming demo. However, after several seconds it always stops working. The client says the track is muted, and on the server side Janus spits out a bunch of the following and then the stream dies:

[WARN] [3352707444203379] ICE failed for component 1 in stream 1, but let's give it some time... (trickle received, answer received, alert not set)

[ERR] [ice.c:janus_ice_outgoing_traffic_handle:4559] [3352707444203379] ... only sent -1 bytes? (was 71)

[ERR] [ice.c:janus_ice_outgoing_traffic_handle:4559] [3352707444203379] ... only sent -1 bytes? (was 1500)

[ERR] [ice.c:janus_ice_outgoing_traffic_handle:4559] [3352707444203379] ... only sent -1 bytes? (was 1500)

[ERR] [ice.c:janus_ice_outgoing_traffic_handle:4559] [3352707444203379] ... only sent -1 bytes? (was 1500)

...

The video disappears from the demo page, but if I stop the stream and then start again, it works for a little while and the cycle repeats. The video glitches some, but that's almost certainly because I have a very poor internet connection, and streaming video out from the pi, in on my computer, plus having multiple ssh windows open is more than it likes to handle. The video also looks more pixelated in the Janus demo than it does when pulling the RTMP stream, which I assume can be fixed by changing how it is transcoded. The main problem is that the stream dies after a short time, so if anyone has any ideas about how to solve that issue I would greatly appreciate it.

[Amnon Israely]

It's GOP size. default value is 250.

GOP size 1 mean all frames is I frame. It's not good idea.

Try to add:

 -profile:v baseline

воскресенье, 28 марта 2021 г. в 04:20:20 UTC+3, benjami...@gmail.com:

[Lorenzo Miniero]

You're sending packets that are too large and exceed the MTU, which means they get discarded. I can't remember the name of the option, but you can tell ffmpeg to stick to lower values (1200 is a good option).

L.

[Amnon Israely]

... -f rtp rtp://localhost:8554?pkt_size=1200

понедельник, 29 марта 2021 г. в 10:17:07 UTC+3, lmin...@gmail.com:

[Benjamin Budai]

Thanks a lot for the input guys! I'll try your suggestions as soon as I get a chance and let you know how it goes. :)

[Benjamin Budai]

I removed the -g 1 option to let it just use the default. I tried different packet size values and saw very similar durations for how long the video would work before dropping off. If I went too high on the packet size the video would be almost completely green, and if I went too low it would be dropping out a ton. Other than that, any values from around 128 up to around 1200 gave the same results. Oddly enough, I saw basically the same working duration when changing the resolution of the video as well, and when I was in a zoom meeting too. So it seems like it's not my network connection causing it, or the changed resolution would make a difference, as would using my network for something else at the same time. Any ideas what else might be causing this? I'm consistently seeing about 45 to 50 seconds before it fails as described before. Notably, I get the same results when changing the packet size on the raspberry pi end, or on the server end, or both, regardless of whether the values are the same on both ends.

[Benjamin Budai]

I also tried adding "-profile:v baseline" to the ffmpeg command on the server and it appeared not to make any difference.

[Benjamin Budai]

One more post and then I'll try to stop bugging you guys for a while. :)

I enabled one of the sample stream configs, and the amount of time that it would stream successfully was the same as my video feed. So it can't be something to do with the raspberry pi, or with the ffmpeg on the server converting to RTP, at least I'm not sure how it could be, since the file based stream also drops off after the same amount of time, with the same error messages.

This is the sample stream that I enabled:

file-live-sample: {

        type = "live"

        id = 2

        description = "a-law file source (radio broadcast)"

        filename = "/opt/janus/share/janus/streams/radio.alaw"

        audio = true

        video = false

        secret = "adminpwd"

}

Also, I tried opening three windows and starting the stream in all three of them, offset a little bit. The first one that I started died, but the other two kept working. Then the second died while the third kept working, and lastly the third one died. So they each died basically (I didn't time them each separately) the same amount of time after they started, but the video was clearly still working. I also tried starting each one again after it died before the others died, and they worked, so I was able to see that the video was streaming fine the whole time, but the connections or something to do with them were dying. I still don't know what to do with this information, but it's progress I guess!

[Lorenzo Miniero]

If even those static audio only samples interrupt after a while, then you have a connectivity issue. Check logs and Admin API for ICE or DTLS failures. Or maybe signalling? You may not be keeping the session alive (e.g., using websockets but not sending keepalive messages); sessions will timeout if you don't send messages for ~60s.

L.

[Benjamin Budai]

I'm not using web sockets. I found a comment in the Janus.jcfg file above the nat section (also commented out). The comment said

"You can also configure whether to use connectivity checks as keep-alives, which might help detecting when a peer is no longer available (notice that current libnice master is breaking connections after 50 seconds when keepalive-conncheck is being used, so if you want to use it, better sticking to 0.1.18 until the issue is addressed upstream)."

The whole section was commented out already, so I tried uncommenting it and setting ice_keepalive_conncheck to false or true, and neither worked. Oddly enough, when I did that, it said that I didn't have a stun server defined, even though I had stun_server and stun_port specified in the section. I also tried setting the timeout to a different value by running Janus with the -s option and giving it a higher number like 3000, but it still always cut the connections off at the same ~50 second time frame. So it looks like maybe I need to re-compile Janus using a different version of libnice? If it was because of the keep-alive it would have lasted longer when I set the timeout to a greater value, right?

As far as the ICE and DTLS failures goes, this is what Janus spits out when a connection dies:

[WARN] [302383686464060] ICE failed for component 1 in stream 1, but let's give it some time... (trickle received, answer received, alert not set)

[ERR] [ice.c:janus_ice_outgoing_traffic_handle:4559] [302383686464060] ... only sent -1 bytes? (was 200)

... (a few hundred more lines of the same [ERR]) ...

[ERR] [ice.c:janus_ice_check_failed:1829] [302383686464060] ICE failed for component 1 in stream 1...

[ERR] [dtls-bio.c:janus_dtls_bio_agent_write:157] [302383686464060] Error sending DTLS message on component 1 of stream 1 (-1)

[Benjamin Budai]

Well, I think I fixed it. First off, I had the "nat" section in my config file twice (yeah I know I'm stupid) so none of my config changes were actually changing anything. Once I fixed that, I tried setting ice_keepalive_conncheck to true, and now it stays connected. I had it connected for over 10 minutes before I killed it myself. This seems backwards from what the comments in the config file (and a warning when running Janus with ice_keepalive_conncheck enabled) say, but hey - it's working. Now I just need to improve the quality of the video and I'll be set. I think that is probably largely dependent on my internet connection, which isn't very good. With a resolution of 240x135 it's pretty stable and smooth, with under a second of latency, although fuzzy of course. I will plan on experimenting to see how high of a resolution I can get through reliably.

[Lorenzo Miniero]

You're probably not on master: we fixed the fact that property was read in reverse already.

L.