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 <lmini...@gmail.com> 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
> dev-media@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-media
>



-- 
Maire Reavy
mre...@mozilla.com
_______________________________________________
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media

Reply via email to