Closed Bug 1303279 Opened 3 years ago Closed 3 years ago

Resolution for outbound video stream drops to 352x288 on replacing video track during webrtc call.

Categories

(Core :: WebRTC: Audio/Video, defect, P1)

49 Branch
defect

Tracking

()

VERIFIED FIXED
mozilla52
Tracking Status
firefox49 --- wontfix
firefox-esr45 --- unaffected
firefox50 --- verified
firefox51 --- verified
firefox52 --- verified

People

(Reporter: prerak, Assigned: jesup, NeedInfo)

References

()

Details

(Keywords: regression)

Attachments

(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36

Steps to reproduce:

1. Start a webrtc call on FF.
2. During the call change the video track on peer connection object using replaceTrack(). In this case I started a new capture on a new video device during the call and replaced the old video track with new one.
3. All the video stream are captured at 1280x720


Actual results:

The repalceTrack call was successful and FF started sending the video from the new source. But in Firefox v 49 and above, as soon the track is replaced the outbound video stream resolution drops to 352x288 and does not ramp up during the call. 

Note - The stream is captured at 1280x720 and there are no network losses.


Expected results:

The outbound video stream resolution should not have dropped to 352x288. It tried it in Firefox 48, the resolution does not drops on replacing the tracks. I have started seeing the problem Firefox 49 and onwards.
OS: Unspecified → Mac OS X
Priority: -- → P3
Hardware: Unspecified → x86_64
Do you have any testcase to reproduce the issue?
Component: Untriaged → WebRTC: Audio/Video
Flags: needinfo?(jainprerak)
Product: Firefox → Core
(In reply to Loic from comment #1)
> Do you have any testcase to reproduce the issue?

Steps to reproduce the issue.

1. Attach an external camera to laptop.
2. Join a webrtc call using the inbuilt camera.(start video capture only on in built camera only at 1280x720)
3. In between the call, start capturing the video from the external camera at 1280x720.
4. Once the capture is started, replace the inbuilt camera video track in the peer connection object with the external one using rtcRtpSender.replaceTrack()and stop/kill the in-built camera stream.
5. Once the track is replaced successfully, firefox starts sending the outbound video at 352x288. (I have verified that camera capture is done at 1280x720)
6. This issues is reproducible 90% of times. Keep switching the camera during the call if for the first time resolution is not dropped.
A similar problem exists after ICE restart. You can repro by following the link and executing the example: https://webrtc.github.io/samples/src/content/peerconnection/restart-ice/

On the console before and after the re-negotiation you will see:
Before: Remote video size changed to 640x480
After: Remote video size changed to 352x288

SDPs before and after restart are the same.

Note that according to the spec replaceTrack might require re-negotiation as well.
Also see the URL for a simple way to reproduce this.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(jainprerak)
I can confirm that this doesn't happen in 48.0.2.
Rank: 13
Keywords: regression
OS: Mac OS X → All
Priority: P3 → P1
Hardware: x86_64 → All
Assignee: nobody → rjesup
This was caused by some change in the MediaPipelineFactory probably, perhaps to ensure we switch mode if you replace a video feed with a screenshare feed.
byron - just NIing you as an FYI, since this was fallout of some change in 49 to how ReplaceTrack works in PCMedia It hink, or maybe to MediaPipelineFactory.
Flags: needinfo?(docfaraday)
Attachment #8796784 - Flags: review?(pkerr) → review+
Pushed by rjesup@wgate.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/3649c55173d2
reset codec resolution to last frame when reconfiguring in webrtc r=pkerr
https://hg.mozilla.org/mozilla-central/rev/3649c55173d2
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla52
Randell - Is this fix going to be available for firefox beta or it will only be part of mozilla52 only ?
I plan to ask for uplift to 51 and 50
It would be nice, and fairly simple, to have a mochitest for this.
Comment on attachment 8796784 [details] [diff] [review]
reset codec resolution to last frame when reconfiguring in webrtc

Approval Request Comment
[Feature/regressing bug #]: Signaling change landed in 49

[User impact if declined]: An important usage pattern for webrtc will result in degraded image quality (highly so in the case of screenshares or HD captures

[Describe test coverage new/current, TreeHerder]: Manual testing.  This could be tested; I'll look to add this to the ReplaceTrack test

[Risks and why]: no risk - just ensures that the channel's current resolution and framerate aren't ignored on replaceTrack.

[String/UUID change made/needed]: none
Attachment #8796784 - Flags: approval-mozilla-beta?
Attachment #8796784 - Flags: approval-mozilla-aurora?
Flags: needinfo?(docfaraday)
Hi Prerak, could you please verify this issue is fixed as expected on a latest Nightly build? Thanks!
Flags: needinfo?(prerak)
Comment on attachment 8796784 [details] [diff] [review]
reset codec resolution to last frame when reconfiguring in webrtc

Fixes a recent regression, Aurora51+, Beta50+
Attachment #8796784 - Flags: approval-mozilla-beta?
Attachment #8796784 - Flags: approval-mozilla-beta+
Attachment #8796784 - Flags: approval-mozilla-aurora?
Attachment #8796784 - Flags: approval-mozilla-aurora+
Flags: qe-verify+
Randell - I have observed the issue again if you try to replace the stream more than once in call, for the first time resolution is unchanged but second time when you do it, the resolution drops back to 352x288.I tested in on 52.0a1.

Check https://jsfiddle.net/erxqr3qp/3/, hit the replace button twice you will observe the issue again.

I observed similar behaviour while during re-ice, if you do re-ice twice during a call the resolution is dropped to 352x288 during the second re-ice attempt.
Confirmed; the mSendingWidth is reset later in that call, so calling it again will assume it's a 'new' conduit.  Very simple fix, will file a followup
Blocks: 1307507
Reproduced the initial issue on Firefox 49, build ID 20160916101415.

Confirming this is fixed on:
* Fx 50 RC, build ID 20161101104304,
* Latest 51.0a2 Aurora, build ID 20161102004003,
* Latest 52.0a1 Nightly, build ID 20161102030205.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
QA Contact: cornel.ionce
You need to log in before you can comment on or make changes to this bug.