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

Status: VERIFIED FIXED

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

Description

[Sonny Piers [:sonny]]

Attachment: 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.

Comment 1

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

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.

Comment 2

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

Attachment: Part 1: Add NotifyHasCurrentData callback on StreamListener

Comment 3

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

Attachment: Part 2: Wait for NotifyHasCurrentData(true) callback on the input stream before entering HAVE_CURRENT_DATA for a media element

Comment 4

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

https://hg.mozilla.org/integration/mozilla-inbound/rev/9d5d96d59781
https://hg.mozilla.org/integration/mozilla-inbound/rev/bd491a087614

Comment 5

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/9d5d96d59781
https://hg.mozilla.org/mozilla-central/rev/bd491a087614

Comment 6

[Jason Smith [:jsmith]]

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?

Comment 7

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

The testcase doesn't work because it needs to be modified to use .mozSrcObject instead of .src.

Comment 8

[Jason Smith [:jsmith]]

Verified on 10/4 nightly.

Comment 9

[ashley]

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?

Comment 10

[Sonny Piers [:sonny]]

(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?

Comment 11

[Randell Jesup [:jesup] (needinfo me)]

See if bug 854094 covers your current report

Comment 12

[ashley]

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.

Comment 13

[ashley]

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.

Comment 14

[Jason Smith [:jsmith]]

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