Streaming plugin + VP8/Opus + modified html is not working for few people

[Ad Au]

Hi !

First, I want to congratulate you and thank you for your amazing software. As far as I know, there is no such browserless-webrtc endpoint around but Janus gateway, and it seems very well written and robust. Keep up the good work !

I try to setup a rebound server for videogame streaming on my dedicated server: the host sends a rtmp stream to nginx-rtmp which:
1/ sends the stream as it is received to Twitch, Youtube Gaming, Hitbox and Dailymotion
2/ executes a ffmpeg instance which live transcode the stream to VP8/Opus and sends it to Janus' streaming plugin

I use a custom html webpage that automatically launches the stream.

It works very well for me: no flash player, very low latency (~1 second from the hoster), no codec installation, no client but the browser...
It works for me in many differents configurations: Windows, OSX, Linux with Chrome, Firefox...

Unfortunately, very few people told me that the get either no sound and video, or no video (just sound). Someone told me that sound was working well, but got a full of artefact-black video.

I have no personal contact with these users, and I cannot extend the test very far to understand the problem. As far as I know, they were using up-to-date Chrome.

2 users successfully tried the streaming plugin test from Meetecho website, so I guess it's more a codec trouble than ISP/ICE/Stun/whatever. For information, here is the complete ffmpeg command launched by nginx-rtmp (there are a low and a high quality versions):

ffmpeg -re -i rtmp://localhost/app/$name -c:v libvpx -deadline realtime -cpu-used 15 -b:v 1536k -vf scale=-1:720 -an -f rtp rtp://127.0.0.1:5004 -c:a libopus -ac 2 -b:a 192k -ar 48000 -vn -f rtp rtp://127.0.0.1:5002 -c:v libvpx -deadline realtime -cpu-used 15 -b:v 256k -vf scale=-1:360 -an -f rtp rtp://127.0.0.1:5008 -c:a libopus -ac 2 -b:a 64k -ar 48000 -vn -f rtp rtp://127.0.0.1:5006

I tried with "-deadline good" and "-cpu-used 0", without any improvements.

As I don't really know where to begin with to tackle this problem, I would need someone to point me toward the right direction, or to propose some insights and ideas to test.

Thank you veyr much,

Cordially,
Adrienj

[Lorenzo Miniero]

Not an expert on transcoding, sorry, although I'm sure others will be able to be of more help with your pipeline.

The only suggestion I can give you is to look into the keyframe frequency: if it's too wide (e.g., a keyframe every 30 seconds), users getting on the stream may have to wait any time between 1 and 30 seconds before being able to see something. The recent videobufferkf addition to the streaming plugin helps there, but it would only show a freezed frame instead of a black box until a keyframe is received. If that's the case (that is, users should just wait a bit before receiving the video) try making keyframes more frequent.

Apart from that, the cause might also be an excessively high bitrate that some users might not be able to receive or handle, either because of limited bandwidth or because of excessive packet loss. If that's the case, try adding additional mountpoints with lower bandwidth requirements and allow users to choose (or handle an automatic switch somehow when things seem to go south).

L.

[Амнон Исраэли]

i suggest to add -error-resilient 1

and remove -re option it's usable for file source

with live streams may do problems

What version ffmpeg you using?

вторник, 1 марта 2016 г., 13:47:05 UTC+2 пользователь Lorenzo Miniero написал:

[Ad Au]

Ok, I will remove the "-re" flag, set the maximum keyframe interval to 2 secs (-g 60) and serve a "very low bitrate" version of the stream for testing purpose. When I read you, I remembered someone saying that he was able to watch the "low bitrate" version but not the "high" version. Maybe it'll help.

I will set the error-resilient mode to 1, although I don't really know what it implies.

ffmpeg version is on the server is: 2.8.4-1~bpo8+1 (from Debian Jessie 2 weeks ago).
I've just upgraded it to 2.8.6-1~bpo8+1 (from current Debian Jessie).

I'll keep you aware of any improvements from these changes.

I really thank you both for your help.

Cordially,
Adrien

PS: Here's the link of the project (still in developpment): http://tv.jeuxonline.info/
As people didn't like Twitch for its delay (HLS) and Hitbox for its flash player, I used Janus to provide a full-html5 player with even lower delay than Hitbox :)

[Ad Au]

The changes didn't really helped.

However, I tested my setup at a friend's house, and I got the exact feedbacks I was told.

Unfortunately, I didn't know where to look at. The only see that I noticed is that there were a lot of packet losses (few thousands per minutes) according to Chrome. This massive packet losses is only seen on the video feed (VP8), there was no packet losses on the audio feed (Opus). My friends got a 100/100 mbits/s connection, and is computer is connected with an ethernet cable.

This packet loss doesn't allow the browser to display any picture with a high bitrate feed. With a low bitrate feed, sometime it displays some nonsense.

The server where Janus is installed is a dedicated server with is own IPv4. So I didn't installed or configured anything related to Stun/Turn.

Well, I don't think it comes from the transcoded feed anymore. But I don't know where to look at to understand such behaviour with packet losses for some viewers.

Thank you very much,

Adrien

[Ad Au]

By the way, the behaviour is the same for Firefox and for Chrome.

[Амнон Исраэли]

in my setup i go some viewers could not see nothing.

The solution was to add rtp://IP:PORT?pkt_size=1316

and for some viewers solution was to do DTLS cert 1024bit

[Lorenzo Miniero]

The packet size can definitely help (I'd set it even lower than 1300, maybe 1200), as if they exceed the MTU they'll be dropped.

L.

[Ad Au]

Yeah, I just test with ?pkt_size=1316, and it worked well at my friend now.

I'll use a 2014bits cert now.

I really thank you for your help Амнон, you were very helpful.

Lorenzo, any idea why it's working well with 80% of users without the packet size set ? I just want to understand. Thank you :)

Adrien

[Lorenzo Miniero]

I guess some users or the path towards them has a slightly lower MTU than others.

We had to fix the DTLS handshake for the same reason some months ago.

L.

[Ad Au]

Sorry for the typo, I will generate 1024 bits certificate.