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

Status: RESOLVED FIXED

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

Description

[brian]

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: http://jsbin.com/IzuzemO/2/

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.)

Comment 1

[Adam Ullman]

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.

Comment 2

[Adam Ullman]

I should point out it does for Chrome as well.

Comment 3

[Bill Stinson]

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.

Comment 4

[Adam Ullman]

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:
https://bugzilla.mozilla.org/show_bug.cgi?id=852665

Comment 5

[Ian Lovett]

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

Comment 6

[Ian Lovett]

Nevermind, this still posed issues with getting incorrect widths and heights.  For now I have sadly gone with a timeout of 500 ms.

Comment 7

[Eric Shepherd [:sheppy]]

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 http://jsfiddle.net/codepo8/agaRe 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.

Comment 8

[Marco Castelluccio [:marco]]

We also have a failing example on MDN: https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Taking_still_photos

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Bug 879717 should fix this.

Comment 11

[Andreas Pehrson [:pehrsons]]

Fixed by bug 879717.

Comment 12

[Andreas Pehrson [:pehrsons]]

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!

Comment 13

[Adam Ullman]

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.

Comment 14

[brian]

Yup, this works for me now. Thanks for the fix.

Comment 15

[Eric Shepherd [:sheppy]]

This fix needs to be documented; it improves interoperability enormously!