Closed Bug 778682 Opened 7 years ago Closed 7 years ago

drawImage doesn't work on loadeddata event with MediaStream <video/>

Categories

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

x86
macOS
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla18

People

(Reporter: sonny, Assigned: roc)

References

Details

(Whiteboard: [getUserMedia], [blocking-gum+])

Attachments

(3 files)

Attached file testcase
Follow up https://bugzilla.mozilla.org/show_bug.cgi?id=771833#c24.
See testcase, the following error is thrown: 'Component is not available'

Since loadeddata is fired when the first frame of the video is loaded, it should works. AFAIK this testcase only works on listening 'canplay' event (however it might be related to bug 778678) but I believe listening loadeddata event makes more sense for this use case.
Depends on: 778678
Whiteboard: [getUserMedia], [blocking-gum+]
I think the problem is that we advance to HAVE_CURRENT_DATA and fire "loadedata" immediately on setting the stream as the source of the media element. However we don't necessarily have a video frame in the video track yet, so drawImage can fail.

I'm going to address this by adding a new StreamListener notification that fires on a stream when all tracks have data covering the current time. Media elements can listen for that and use it to transition to HAVE_CURRENT_DATA.
Attachment #662032 - Flags: review?(rjesup) → review+
Attachment #662033 - Flags: review?(cpearce) → review+
Keywords: verifyme
https://hg.mozilla.org/mozilla-central/rev/9d5d96d59781
https://hg.mozilla.org/mozilla-central/rev/bd491a087614
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla18
This isn't working with the attached test case on the 9/29. Is there something that needs to be changed to test case? Or is this bug not fixed?
Keywords: verifyme
Whiteboard: [getUserMedia], [blocking-gum+] → [getUserMedia], [blocking-gum+], [qa verification failed]
The testcase doesn't work because it needs to be modified to use .mozSrcObject instead of .src.
Keywords: verifyme
Whiteboard: [getUserMedia], [blocking-gum+], [qa verification failed] → [getUserMedia], [blocking-gum+]
Verified on 10/4 nightly.
Status: RESOLVED → VERIFIED
Keywords: verifyme
I think I'm still having this problem on Nightly 23.0a1. I use getUserMedia to get a webcam feed to a video element, the video fires canplaythrough, its readyState is 4, but passing it to drawImage still throws "Component is not available". The only workaround I've found is to wrap the drawImage in a try/catch. I'm on Windows 8 with a Creative USB WebCam. Should I post a new bug?
(In reply to ashley from comment #9)
> I think I'm still having this problem on Nightly 23.0a1. I use getUserMedia
> to get a webcam feed to a video element, the video fires canplaythrough, its
> readyState is 4, but passing it to drawImage still throws "Component is not
> available". The only workaround I've found is to wrap the drawImage in a
> try/catch. I'm on Windows 8 with a Creative USB WebCam. Should I post a new
> bug?

Can you write a test case and attach it to the bug?
See if bug 854094 covers your current report
Reproduced "component is not available" exception, works every time for me:

http://www.scirra.com/labs/gumbug.html

Not sure if bug 854094 is related; this repros locally without needing a remote stream.
Also reproduces every time on Windows 7 with a "BisonCam, NB Pro". This now repros on two different machines with different versions of Windows and different cameras. I think this bug should be re-opened.
(In reply to ashley from comment #13)
> Also reproduces every time on Windows 7 with a "BisonCam, NB Pro". This now
> repros on two different machines with different versions of Windows and
> different cameras. I think this bug should be re-opened.

There's already bugs open on this. Let's not reopen a bug preferably.
You need to log in before you can comment on or make changes to this bug.