787812 - Unable to copy video frames from Camera to Canvas

Status: RESOLVED FIXED

(Firefox OS Graveyard :: General, defect)

Description

[:gerard-majax]

Trying to make a Gaia app that performs roughly what's described in https://developer.mozilla.org/en-US/docs/Manipulating_video_using_canvas, I'm getting this JavaScript error:
JavaScript Error: "NS_ERROR_NOT_AVAILABLE: Component is not available"
Right when performing the ctx1.drawImage() call.

If my <video> is fed from a local file, not the Nexus S camera, then it works.

Comment 1

[:gerard-majax]

Maybe a dupe of bug 778682 ?

Comment 2

[Jason Smith [:jsmith]]

(In reply to Alexandre LISSY from comment #1)
> Maybe a dupe of bug 778682 ?

Possibly, although that's related to WebRTC MediaStreams. Is this a problem in the general case? Mike - Thoughts?

Comment 3

[Mike Habicher [:mikeh] (high bugzilla latency)]

(In reply to Jason Smith [:jsmith] from comment #2)
> (In reply to Alexandre LISSY from comment #1)
> > Maybe a dupe of bug 778682 ?
> 
> Possibly, although that's related to WebRTC MediaStreams. Is this a problem
> in the general case? Mike - Thoughts?

Sorry, jsmith--this is outside my realm of knowledge.

Comment 4

[Andrew Overholt [:overholt]]

Jonas suggests this isn't a common enough use case to block basecamp.  As always, if someone disagrees, please re-nom.

Comment 5

[:gerard-majax]

Since the blocker landed, I'll retest as soon as my gecko is rebuilt.

Comment 6

[:gerard-majax]

My gecko has commit cc33c225c154762e4a036ead13957ffdad4461cb, which is bug 794061, but I'm still getting the issue :(

This is on a Nexus S, if it has a link somehow ...

Comment 7

[Sotaro Ikeda [:sotaro]]

bug 794061 only add support of qualcomm's some color formats. Nexus S uses Samsung Exynos processor, it seem that it is necessary to add color format support for Exynos. But I do not know about Exynos...

http://en.wikipedia.org/wiki/Nexus_S

Comment 8

[:gerard-majax]

Attachment: Making Nexus S video frame copiable.

I've been able to successfully add the missing bits for GonkIOSurfaceImage to be able to convert a frame: adding printf_stderr() debug, I can reach the 'return imageSurface.forget()' statement. This is the (trivial) patch attached.

However I'm still getting an error "NS_ERROR_NOT_AVAILABLE: Component is not available".

Comment 9

[JP Rosevear [:jpr]]

Comment on attachment 673675 [details] [diff] [review]
Making Nexus S video frame copiable.

Trying cjones for review

Comment 10

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Comment on attachment 673675 [details] [diff] [review]
Making Nexus S video frame copiable.

Sorry, this got lost in a tab earlier today :(.

We don't need the comment here, you can drop that.

Looks fine to me, but I'd like Kan-Ru to take a look.

Comment 11

[:gerard-majax]

Attachment: Patch ready to be checked in

Removing comments, as suggested.

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/604634b91270

Comment 13

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/604634b91270

Comment 14

[:gerard-majax]

This is not fixed, even if the patch adding colors for Nexus S was needed.

Comment 15

[Jason Smith [:jsmith]]

(In reply to Alexandre LISSY :gerard-majax from comment #14)
> This is not fixed, even if the patch adding colors for Nexus S was needed.

Please file a followup bug and link it as a dependency.

Comment 16

[:gerard-majax]

It's strange, I don't see this on b2g-18 tree, confere https://github.com/mozilla/mozilla-central/blob/b2g18/gfx/layers/GonkIOSurfaceImage.cpp

Comment 17

[:gerard-majax]

After ensuring this patch is here, and with bug 832745, I still have endianess isues when copying the frame to canvas: red and blue are inverted (on Nexus S at least).

Comment 18

[:gerard-majax]

Can someone explain me why the fix that has been landed does not appear in b2g-18 ? It landed before the branch got created.

Comment 19

[Jason Smith [:jsmith]]

Fixing flags. Set the status flags when this happens...

Comment 20

[Ryan VanderMeulen [:RyanVM]]

b2g18 was branched in the first week of October IIRC. AFAICT, this never had bb+ or approval to uplift and hence never was. At this point, you'll need to request approval for uplift to the affected branches.

Comment 21

[:gerard-majax]

Okay, thanks for this clarification, I was convinced branching got performed much more later, and I have of knowledge of those processes. I'll see with paul and julien, regarding bug 832745, since this bug might be a blocker.

Comment 22

[:gerard-majax]

It's now available on http://lissyx.github.com/heart-rate/

Comment 23

[Ryan VanderMeulen [:RyanVM]]

I'm sorry, I wasn't very clear in my last reply. b2g18 was branched off mozilla-beta last month, however, Gecko 18 was branched off m-c to aurora in October, which is when additional uplifting would have begun. Since this landed on m-c in November, it landed on what is now Gecko 19 and never got uplifted to an 18 branch.

Comment 24

[Lukas Blakk [:lsblakk] use ?needinfo]

Batch edit: Bugs still affected on b2g18 after 2/13 merge to v1.0.1 branch are affected on v1.0.1 branch.

Comment 25

[Julien Wajsberg [:julienw]]

Comment on attachment 676944 [details] [diff] [review]
Patch ready to be checked in



This is a very low risk patch as this only introduces a new mapping.

Comment 26

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g18/rev/0056bd28c485