Maire, thanks for the quick answer. I just created the bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1256679 Let me know if there's anything else I can do to help.
Lorenzo 2016-03-15 15:00 GMT+01:00 Maire Reavy <[email protected]>: > Hi Lorenzo, Thanks for your mail. > > The only other thing we need to move forward is a bug ticket. Can you > file a bug for this issue? Just click on this link and fill out the > template: > https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=WebRTC > > Once the info is entered, you'll get a bug number you can follow. I'll > triage the bug, and we can carry on the conversation in the bug as we try > to reproduce it and figure out what's causing this issue. > > Cheers, > -Maire > > > On Tue, Mar 15, 2016 at 7:05 AM, Lorenzo Miniero <[email protected]> > wrote: > >> Hi there, >> >> for some time I've noticed a weird behaviour when using Firefox in my >> tests with my WebRTC gateway. Specifically, if I mute a video >> MediaStreamTrack in a web application, and then after some time unmute it >> again, it comes back delayed. 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. >> >> 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 demo doesn't do any RTP sequence number/timestamp overwriting, so >> what you get back is exactly the same as what you sent, which makes me >> think something goes wrong in how timestamps are computed/written in the >> Firefox WebRTC stack after video transmission is resumed. If I got it >> right, the framerate in the video changes when you disable video (IIRC you >> basically send a black frame at a much lower framerate), which means >> something might be messed up in those transitions. >> >> I've seen the issue around for a few months, and it affected Chrome too >> up to some time ago, so I thought it was something we were doing wrong: >> anyway, I've tried Chrome 50 lately and the issue is gone there, video has >> no delay anymore, which is making me think it might be indeed a bug in >> Firefox. >> >> Is there anything else I can provide to help you look into this? >> >> Thanks, >> Lorenzo >> _______________________________________________ >> dev-media mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-media >> > > > > -- > Maire Reavy > [email protected] > > _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
