Closed Bug 926753 Opened 11 years ago Closed 9 years ago

videoWidth and videoHeight should be set in loadedmetadata for getUserMedia & PeerConnection-connected video elements


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

27 Branch





(Reporter: brian, Unassigned, NeedInfo)



(Keywords: dev-doc-needed, testcase)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release)
Build ID: 20130922091347

Steps to reproduce:

in javascript:
1) Create a video element
2) call getUserMedia
3) set event listener to loadedmetadata, which logs videoWidth and videoHeight to console
3) assign live video stream to src of video, check console for results

Actual results:

Here is a working example:

In the example, just to be thorough, I log readyState and videoWidth to the console in loademetadata and a few other events, as well as after a timeout. The bug is somewhat intermittent, but most of the time, the videoWidth is 0 after all the events, except sometimes after a timeout of about 10 seconds.

Expected results:

videoWidth should show a positive integer, depending on the resolution of the camera. On my system, in Chrome, I get 640.

(This seems similar to #466410, but this is just for getUserMedia.)
Component: Untriaged → Video/Audio
Keywords: testcase
Product: Firefox → Core
This is also an issue on the receiving side of a WebRTC stream using PeerConnection. I would like "loadedmetadata" to fire after the videoWidth and videoHeight properties are defined in this case too.
I should point out it does for Chrome as well.
I reproduced this bug.  The "loadedmetadata" callback works fine on Chrome, but returns with zero values for videoHeight and videoWidth in Firefox.  I explored the other callbacks, but nothing else worked.  Is there a fix or a known workaround?  Thanks.
Component: Video/Audio → WebRTC: Audio/Video
Ever confirmed: true
Summary: videoWidth and videoHeight should be set in loadedmetadata for getUserMedia videos → videoWidth and videoHeight should be set in loadedmetadata for getUserMedia & PeerConnection-connected video elements
In the case of PeerConnection-connected video elements ideally this event wouldn't fire until the connection has successfully established. We use this event in Chrome to detect PeerConnection failure by timing out waiting for "loadedmetadata".

As far as I know there is no other way to detect PeerConnection failure until this ticket is resolved:
Priority: -- → P3
Target Milestone: --- → mozilla33
I've also run into this issue... my work around is to have the video visible, but offscreen (EG: fixed: -1024px;)

apply no styles to the video so it takes up 100% of its dims, then instead of using this.videoHeight or this.videoWidth use this.clientHeight or this.clientWidth... or $.height() or $.width()... once the dimensions are stored you can hide the video element
Nevermind, this still posed issues with getting incorrect widths and heights.  For now I have sadly gone with a timeout of 500 ms.
Target Milestone: mozilla33 → mozilla35
This is breaking examples we have that have previously supposedly worked correctly on Firefox but currently work on Chrome, and is affecting attempts to write sample code for our WebRTC docs, fwiw.

See for example, which is referenced from a past Hacks blog post and existing WebRTC documentation, which implies that it worked at one point but no longer does, due to videoWidth and videoHeight being 0 when the "canplay" event is fired.

I also tried changing it to check those values when "loadedmetadata" is fired, but no go.
Fixed by bug 879717.
Closed: 9 years ago
Resolution: --- → FIXED
Brian, Adam, Bill, Ian,

It'd be great if you could verify that this is working for your use cases now in latest nightly and/or aurora. Thanks!
Flags: needinfo?(i.c.lovett)
Flags: needinfo?(brian)
Flags: needinfo?(bill.stinson)
Flags: needinfo?(adam)
Yep, it's working in Nightly for me. Specifically when loadedmetadata fires on a video attached to a remote stream the videoWidth and videoHeight are populated.
Flags: needinfo?(adam)
Flags: needinfo?(i.c.lovett)
Target Milestone: mozilla35 → mozilla38
Yup, this works for me now. Thanks for the fix.
Flags: needinfo?(brian)
This fix needs to be documented; it improves interoperability enormously!
Keywords: dev-doc-needed
Blocks: 1050930
You need to log in before you can comment on or make changes to this bug.