mediatrack enabled

[Emanuele Bizzarri]

Hi,
I notice a strange behaviour when I try to disable and re-enable the video track of a stream using videoTracks[0].enabled=enabled;
On the receiver side I see that googCurrentDelayMs, googTargetDelayMs and googJitterBufferMs increase and the rendered image has a delay.
I have done this test adding a toggle button into content/peerconnection/pc1/ example of webrct samples.
Using this example on my machine, initially googCurrentDelayMs  and googTargetDelayMs have the same value of about 50ms and
googJitterBufferMs is about 5ms. The bitrate is about 2M.

When I disable the video the bitrate goes to 50k, the delays reach 80ms and the jitter 20ms.
The if I re-enable the video the delays and the jitter go to 400ms. And then they try to decrease very slowly.

I cannot reproduce sistematically.
There are sometimes that the trasmitted and received video are always in sync, other times the receiver video has a delay.
It seems that if I start the peerconnection with the video disabled, the problem can be reproduced easily.
If I wait that the delay comes back to its original value, then I'm not able to reproduce, I have to refresh the page and retest.

On internet this behaviour happens more frequently. But if I don't touch the enable button the delay and the jitter are always low also on internet.

Maybe I'm missing something and I have to do something else in order to implement correctly the video enable feature.

Below you can see the graph.

Can you help me please?

Thank you

Emanuele

[Vikas]

Thanks for sharing the details, not sure why the jitter suddenly goes that high. I can also try recreate it but if you can file an issue in webrtc tracker and share rtp dump that would be useful.

/Vikas

[emanuele bizzarri]

Done.

https://code.google.com/p/webrtc/issues/detail?id=4355

Let me know if you find that I'm using it in the wrong way.

Thank you

 

[Lorenzo Miniero]

Any update on this? This still seems very much an issue.

I opened a bug for Firefox some time ago, and they got it fixed since (not reproducible in Firefox 49 anymore). You can find more info on both the post I opened at the time, and the related issue I opened on their bug tracker:

https://groups.google.com/forum/#!topic/mozilla.dev.media/2Gq_QVc9Sps

https://bugzilla.mozilla.org/show_bug.cgi?id=1256679

This still happens with Chrome, instead. Apparently the cause is googJitterBufferMs that is bumped for some reason to about 300/500ms, to only decrease after some minutes. I initially thought some broken RTCP management could be blamed on my end, but I double checked and everything seems fine there. As I wrote on the Firefox-related posts, it seems to happen more evidently when the bitrate of the video is low, while it's barely noticeable for higher bitrates for some reason, although it might or might not be related.

I'll post some of the details again here. It is easily reproduceable, if you want to check it yourself: 

1. open https://janus.conf.meetecho.com/echotest (simple gateway demo that just sends you back whatever you send to it) 
2. use the "bandwidth" control to cap it to 128kbps (as anticipated, it seems more evident at lower bitrates: that control forces REMB feedback at 128000) 
3. mute the local video track: echotest.webrtcStuff.myStream.getVideoTracks()[0].enabled=false 
4. wait some time and unmute it again: echotest.webrtcStuff.myStream.getVideoTracks()[0].enabled=true 
5. you'll see that video is now delayed, while audio is still ok.

The problem is not in how we send the stream we receive, as everything is correct in the RTP timestamps: I verified this with Wireshark. Besides, I also did more tests by forwarding the incoming RTP (unencrypted) to a gstreamer script, and by doing the same test in a SFU scenario with users joining *after* the unmute happened, and so that didn't witness the mute/unmute: in all of those cases, the stream was in realtime, and not delayed at all, while it was delayed for those who were in when the unmute happened. This means that the issue only happens for the receiver that gets a stream being muted, which is then unmuted again.

My guess is that this is related to the different framerate that occurs when doing the mute/unmute, that eventually confuses the receiver. Not sure why this is more evident at lower bitrates, maybe it's just because packets are sent less frequently or less data is involved.

Anything I can provide to have this looked into and, in case the issue is in Chrome, fixed?

Thanks,

Lorenzo