Aspect ratio changed on hold/resume

NEW
Unassigned

Status

()

Core
WebRTC: Audio/Video
P3
normal
Rank:
25
2 years ago
4 months ago

People

(Reporter: Alexander Kozlov, Unassigned, NeedInfo)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: needinfo 2016/06/02 to reporter)

Attachments

(2 attachments)

2.47 KB, text/html
Details
24.16 KB, application/x-zip-compressed
Details
(Reporter)

Description

2 years ago
User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160502172042

Steps to reproduce:

1. Establish WebRTC call (for example with chrome) with 16:9 video constrain 
2. Put call on HOLD for several seconds
3. Resume call



Actual results:

FF send video in 4:3 aspect ratio for 10-20 seconds after resume, and then switches to 16:9 (looks like bandwidth adaptation cause decreasing of video resolution, but FF choose wrong aspect ratio in that case)


Expected results:

FF should keep requested aspect ration even in resolution should be decreased for some reason
Component: Audio/Video → WebRTC: Audio/Video
Which webrtc service do you use?
Flags: needinfo?(kozlovalexandr)
Whiteboard: needinfo 2016/05/30 to reporter
(Reporter)

Comment 2

2 years ago
I'm using http://testwebrtc.avistar.com/webrtc/ 
To make call between 2 clients please press Shift+Alt+R and fill form for registration on any your SIP server.
Whiteboard: needinfo 2016/05/30 to reporter
(In reply to Alexander Kozlov from comment #2)
> I'm using http://testwebrtc.avistar.com/webrtc/ 
> To make call between 2 clients please press Shift+Alt+R and fill form for
> registration on any your SIP server.

What systems are you using to test with?  Mac?  Windows?  laptop cameras (laptop model?), or external USB (model)?

Updated

2 years ago
Rank: 25
Priority: -- → P2
Whiteboard: needinfo 2016/06/02 to reporter
confirming since this seems real; haven't tested

logs (NSPR_LOG_MODULES=signaling:4,MediaManager:4,GetUserMedia:4 NSPR_LOG_FILE=whatever) would be helpful
Status: UNCONFIRMED → NEW
Ever confirmed: true
Created attachment 8790332 [details]
reset_video.html

I have encountered similar problems.
video size become 352x288(11:9) when renegotiate.

[Affected versions]:
51.0a1 (2016-09-12) (64-bit)

[Steps to reproduce]:
1. start a call with sending video.
2. signaling become stable
3. renegotiate by remote offer

[Expected result]:
FF keep aspect ratio. if the condition allow, keep video size.

[Actual result]:
FF send video with 352x288. aspect is 11:9

attached file for reproduce.
- when click offer button, then pc(peer connection) A is created and sending offer.
- when click answer button, then other pc B is created. completion to negotiate pc A and B. displaying the video that pc B has received.
- when click renegotiate, then video become 352x288.

I think that stream is reset by PeerConnectionMedia::UpdateMediaPipelines.

Thanks!
Kaneshige: Could you get logs from your testcase?

Use:
NSPR_LOG_MODULES=signaling:4,MediaManager:4,GetUserMedia:4,webrtc_trace:65535 WEBRTC_TRACE_FILE=nspr NSPR_LOG_FILE=whatever

Note the file will be large, so keep the call short, and compress the log for upload.  If it's still too big, use dropbox/etc.

Thanks!
Flags: needinfo?(ykaneshige)
Created attachment 8790876 [details]
ff.zip

attached log file.
Flags: needinfo?(ykaneshige)
Mass change P2->P3 to align with new Mozilla triage process.
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.