1120780 - [Gonk-L-Camera] : Video recording blocking in drawImage

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::Camera, defect)

Description

[becker hsieh{:behsieh}]

because of this commit, makes L branch video blocking inside drawimage 

commit 6b1948cffc043c4a62d34a8598dcb28455957d45
Merge: 9f40063 9f353ff
Author: Wilson Page <[e-mail]>
Date:   Tue Jan 6 10:51:27 2015 +0000

    Merge pull request #26644 from jyavenard/master
    
    Bug 1101230: Properly create camera's preview images.

Comment 1

[Vincent Liu[:vliu]]

Hi :jya

With the patch of Bug 1101230, Camera app can't generate thumbnail after recording in L build. For more detailed information for porting of L build, please see bug 1114477. The root cause would be blocking in CanvasRenderingContext2D::DrawImage(...).

https://dxr.mozilla.org/mozilla-central/source/dom/canvas/CanvasRenderingContext2D.cpp#4304

drawImage never been re-called even it has represented the element is still loading from the last call. Would you please help to figure it out? Thanks

Comment 2

[Jean-Yves Avenard [:jya]]

I'm not the best person to ask for this...

My earlier changes was a trivial change on the javascript side of things that used the wrong event to kick start the capture.

It was working with the dev build at the time (early December)

Comment 3

[becker hsieh{:behsieh}]

Attachment: fix in recording thumbnail created issue

Comment 4

[Vincent Liu[:vliu]]

Assign to :behsieh since he is working on this issue.

Comment 5

[Michael Wu [:mwu]]

Comment on attachment 8549331 [details] [review]
fix in recording thumbnail created issue

Cherry pick sotaro's fix. https://github.com/mozilla-b2g/platform_frameworks_av/commit/6a961033d917805b52c913936d3b9552c0a78f4a

Comment 6

[becker hsieh{:behsieh}]

Hi Michael:
thanks for your information.
the commit you mention already phase in b2g/b2g-5.0.0_r6 as below

commit 16793265f0b6328942ab18f099ba57d036f03887
Author: Sotaro Ikeda <[e-mail]>
Date:   Tue Sep 24 08:09:22 2013 -0700

    Bug 911548 - Add YCbCr_420_SP_TILED's color conversion

and for this fix.
in QCT platfrom , there is a new type of format(HAL_PIXEL_FORMAT_YCbCr_420_SP_VENUS) needs to support in nexus5 , that's why we phase in this code

thanks

Comment 7

[becker hsieh{:behsieh}]

Hi Michael:
depend on comment 6 , please let me know your thought if any.
thank you

Comment 8

[Sotaro Ikeda [:sotaro]]

specification of color format of HAL_PIXEL_FORMAT_YCbCr_420_SP_VENUS is not in public, though source code of converting YCbCr_420_SP_TILED is in public.

Comment 9

[becker hsieh{:behsieh}]

Comment on attachment 8549331 [details] [review]
fix in recording thumbnail created issue

hi sotaro:
can you please help me review this code?
Or you can suggest right person to help review this code.
thanks

Comment 10

[Sotaro Ikeda [:sotaro]]

Comment on attachment 8549331 [details] [review]
fix in recording thumbnail created issue

Looks good.

In the past, source code of almost all platforms specific color conversion were exposed in public as part of android::ColorConverter, But on recent androids, sadly, it is only convenient way to do color conversion of a platform specific color :-(

Comment 11

[Michael Wu [:mwu]]

Comment on attachment 8549331 [details] [review]
fix in recording thumbnail created issue

I think this is actually a planar format, so it should be simple to add support.

Isn't this the result of bug 1117662 enabling venus, though? How come that bug affects us but not AOSP? I'm not sure the analysis there is sufficient. It also pulls in a CAF specific repo which is a clear sign something is wrong.

Comment 12

[becker hsieh{:behsieh}]

Hi michael:
in bug 1117662 ,it was a fix which in camera ,camera needs to enable VENUS support to output 1080p.
in QCT platform, image height needs to divisible by 16,but 1080 dosent. enable VENUS could fix divisible issue.
pull code from CAF is because of Camera needs utils.mk to define VENUS, in AOSP there is no such define.
but it just a define. doesn't mean it can fix all of QCT platform depend issue.
the better way to get QCT depend source code is pull all the code from CAF.
but it just only for QCT platform.
AOSP BSP control really needs to plan well, or it will confuse all the function owner.
thanks

Comment 13

[Steven Yang [:styang]]

functionality failure. blocking 2.2+

Comment 14

[becker hsieh{:behsieh}]

hi michael:
since this is 2.2 blocking and code modify inside AOSP stagefright.
what is superreview- means?
what action do I need to take?
thanks

Comment 16

[becker hsieh{:behsieh}]

hi Michael:
for your question
Isn't this the result of bug 1117662 enabling venus, though? 
Ans: this is not because of bug 1117662 regression issue.

How come that bug affects us but not AOSP? 
Ans: this is only happened in Nexus 5 device which we are working on L porting right now.

I'm not sure the analysis there is sufficient. It also pulls in a CAF specific repo which is a clear sign something is wrong.
Ans: since this fix is cherry-pick from flamekk, without this patch , video thumbnail will not generate.

thanks

Comment 17

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

I just built nexus-5-l with:
- gecko master:ba2f5fcd614709cb2ec0a69d685c89bc8d454c9b
- gaia  master:be64e0a1412c1b8c40b7597c77ed16841bdb152f

...and the front and back cameras work (take pictures, record video), although the app interface seems to freeze/become non-responsive when I stop recording. (Switching to the Homescreen and back seems to unstick it.)

Also, the Video apps plays the videos back with a green stripe down the side of the screen, and the Gallery app shows previews for the taken photos, but doesn't seem to be able to display them.

Comment 18

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

Confirmed: the photos are stored correctly, despite not appearing in the Gallery. Also, the recorded videos do contain a green stripe down their sides: on the left for the away-facing camera; on the right for the user-facing camera.

Comment 19

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

More data: the user-facing camera records at 1280x720 (i.e. 720p) rotated 90-degrees clockwise. The width of 720 includes the green stripe of pixels, which I measure to be 32 pixels wide (i.e. the normal part of the video frame is 688 pixels wide).

Comment 20

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

And for the 1920x1080 (i.e. 1080p) away-facing camera, the green stripe is (only) 16 pixels wide.

Comment 21

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

(Note that the green stripes do not appear in the camera viewfinder, only in the recorded video.)

Comment 22

[becker hsieh{:behsieh}]

Attachment: I420colorconvert_0210.patch

hi sotaro:
attached file is my patch which move I420colorconvert to gfx/layer
can you please help me to try it on your environment?
thanks

Comment 23

[Sotaro Ikeda [:sotaro]]

mColorConverter is used in convertQCOMYUV420SemiPlanarVenus(). convertQCOMYUV420SemiPlanarVenus() is not part of GrallocImage instance.

Comment 24

[becker hsieh{:behsieh}]

Attachment: bug-1120780 color conversion in gecko layer

use I420coloeconvert in gecko to do VENUS color convert.

Comment 25

[Sotaro Ikeda [:sotaro]]

Comment on attachment 8562494 [details] [diff] [review]
bug-1120780 color conversion in gecko layer

Review of attachment 8562494 [details] [diff] [review]:
-----------------------------------------------------------------

::: gfx/layers/GrallocImages.cpp
@@ +22,5 @@
>  
>  #define ALIGN(x, align) ((x + align - 1) & ~(align - 1))
>  
> +android::I420ColorConverterHelper mColorConverter;
> +

It causes, I420ColorConverterHelper allocation when content process is created. Then it causes unnecessary memory consumption and library load. We need to limit this only when it is necessary.

Comment 26

[becker hsieh{:behsieh}]

Attachment: bug-1120780 move color conversion into gecko layer.

move I420ColorConverterHelper into convertQCOMYUV420SemiPlanarVenus

Comment 27

[Sotaro Ikeda [:sotaro]]

Comment on attachment 8562533 [details] [diff] [review]
bug-1120780 move color conversion into gecko layer.

Review of attachment 8562533 [details] [diff] [review]:
-----------------------------------------------------------------

::: gfx/layers/GrallocImages.cpp
@@ +273,5 @@
> +static status_t convertYUV420Planar(
> +        const void* src,size_t srcWidth, size_t srcHeight,
> +        ARect src_crop,
> +        const void* dst,size_t dstWidth, size_t dstHeight,
> +        ARect dst_crop)

Can you explain why you need to add this function? Similar capability is already exit in gecko.

@@ +362,5 @@
> +    return OK;
> +}
> +
> +static status_t
> +convertQCOMYUV420SemiPlanarVenus(

It is not good that the function name have qcom and venus. The implementation does not depend on them.

@@ +373,5 @@
> +{
> +    int32_t err;
> +    uint32_t kI420BPP = 2;
> +    void* yuvbuffer;
> +    android::I420ColorConverterHelper mColorConverter;

It cause library's load and unload for every function call. I do not think it is a good idea.

Comment 28

[Sotaro Ikeda [:sotaro]]

To protect I420ColorConverterHelper creation conflict. It seems better to add that mechanism to gfxAndroidPlatform. gfxAndroidPlatform  is derived class of gfxPlatform. That could make implementation simpler.

Comment 29

[Michael Wu [:mwu]]

Comment on attachment 8562533 [details] [diff] [review]
bug-1120780 move color conversion into gecko layer.

Review of attachment 8562533 [details] [diff] [review]:
-----------------------------------------------------------------

This is not actually address any of my objections earlier.

Comment 30

[Sotaro Ikeda [:sotaro]]

(In reply to Michael Wu [:mwu] from comment #11)
> Comment on attachment 8549331 [details] [review]
> fix in recording thumbnail created issue
> 
> I think this is actually a planar format, so it should be simple to add
> support.
> 
> Isn't this the result of bug 1117662 enabling venus, though? How come that
> bug affects us but not AOSP? I'm not sure the analysis there is sufficient.
> It also pulls in a CAF specific repo which is a clear sign something is
> wrong.

It is not a result of bug 1117662. codeauroa uses VENUS color format for nexus-5's video decoding. codeaurora always use proprietary color format for hw video decodeing to improve the performance.

Comment 31

[Sotaro Ikeda [:sotaro]]

By the way, I found the explanation of venus color format. It is in thefollowing.

https://www.codeaurora.org/cgit/quic/la/platform/hardware/qcom/msm8x74/tree/kernel-headers/media/msm_media_info.h?h=aosp-new/master

Comment 32

[becker hsieh{:behsieh}]

hi michael:
do you have any suggest?
Do you want me to remove commit from bug 1117662 and do color convert in grallocimages?

Comment 33

[becker hsieh{:behsieh}]

hi michael:
do you have any suggest?
Do you want me to remove commit from bug 1117662 and do color convert in grallocimages?

Comment 34

[Michael Wu [:mwu]]

(In reply to becker hsieh{:behsieh} from comment #32)
> hi michael:
> do you have any suggest?
> Do you want me to remove commit from bug 1117662 and do color convert in
> grallocimages?

If we can fix bug 1117662 differently, we should revert the change in bug 1117662.

Color conversion in the stagefright side is preferred. Refer to the code in comment 31. This is just a planar format with different padding/alignment requirements.

Comment 35

[becker hsieh{:behsieh}]

Attachment: Do color convert in stagefright

Comment 36

[Hermes Cheng (inactive after July 27, 2015)]

Michael, could you help Becker review attachment 8568372 [details] [review]?

Comment 38

[becker hsieh{:behsieh}]

per discussion with sku. mwu wants to take this bug.

Comment 39

[Michael Wu [:mwu]]

Attachment: Add support for venus in lock_ycbcr

Comment 40

[Michael Wu [:mwu]]

Attachment: Switch N5 to fork of hardware/qcom/display

Comment 41

[Michael Wu [:mwu]]

Attachment: Remove special handling for venus

This puts our conversion code on the generic path for venus so it can use the lock_ycbcr path.

Comment 42

[Michael Wu [:mwu]]

Just updated the lock_ycbcr PR - I had the U and V planes swapped.

Comment 43

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

Comment on attachment 8577838 [details] [review]
Switch N5 to fork of hardware/qcom/display

FYI, you can specify the URL's content type as 'text/x-github-pull-request' and get an automatic redirect.

Comment 44

[Sotaro Ikeda [:sotaro]]

Comment on attachment 8577836 [details] [review]
Add support for venus in lock_ycbcr

I also confirmed the patch work on nexus-5-l.

Comment 45

[Michael Wu [:mwu]]

https://github.com/mozilla-b2g/hardware_qcom_display/commit/c43952000d57f08b93a0e4fb77052871ce587976
https://github.com/mozilla-b2g/b2g-manifest/commit/2e213a891bacab7fa75ee2d190942e302e3bae25

Comment 46

[Michael Wu [:mwu]]

https://hg.mozilla.org/integration/b2g-inbound/rev/e86c7b372d7a

Comment 48

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/e86c7b372d7a

Comment 49

[Ryan VanderMeulen [:RyanVM]]

Please request b2g37 on this when you get a chance.

Comment 50

[Sotaro Ikeda [:sotaro]]

attachment 8577840 [details] [diff] [review] seem to cause Bug 1144224. I am confirming it.

Comment 51

[Sotaro Ikeda [:sotaro]]

(In reply to Sotaro Ikeda [:sotaro] from comment #50)
> attachment 8577840 [details] [diff] [review] seem to cause Bug 1144224. I am
> confirming it.

I confirmed that attachment 8577840 [details] [diff] [review] causes the regression. I forgot that flame uses  HAL_PIXEL_FORMAT_YCbCr_420_SP_VENUS during the review:-(

Comment 52

[Sotaro Ikeda [:sotaro]]

(In reply to Carsten Book [:Tomcat] from comment #48)
> https://hg.mozilla.org/mozilla-central/rev/e86c7b372d7a

Ryan, can you backout the commit from m-c? This regression blocks a lot of b2g video's test :(

Comment 53

[Michael Vines [:m1] [:evilmachines]]

Attachment 8577840 [details] [diff] causes a corrupt preview of the "big buck bunny" video in the Video app.

The matching code for attachment 8577836 [details] [review] in our tree is here [1].  Slightly different, but if I make the what's on CAF match attachment 8577836 [details] [review] then I see more misalignment of the preview.

Let's not uplift this to b2g37 until this potential regression is better understood please.  There's devices with :sku that you could try this patch on.

[1] https://www.codeaurora.org/cgit/quic/la/platform/hardware/qcom/display/tree/libgralloc/alloc_controller.cpp?h=LA.BR.1.2.3#n572

Comment 54

[Michael Vines [:m1] [:evilmachines]]

Attachment 8577840 [details] [diff] causes a corrupt preview of the "big buck bunny" video in the Video app.

The matching code for attachment 8577836 [details] [review] in our tree is here [1].  Slightly different, but if I make the what's on CAF match attachment 8577836 [details] [review] then I see more misalignment of the preview.

Let's not uplift this to b2g37 until this potential regression is better understood please.  There's devices with :sku that you could try this patch on.

[1] https://www.codeaurora.org/cgit/quic/la/platform/hardware/qcom/display/tree/libgralloc/alloc_controller.cpp?h=LA.BR.1.2.3#n572

Comment 55

[Ryan VanderMeulen [:RyanVM]]

Backed out.
https://hg.mozilla.org/integration/mozilla-inbound/rev/2fb7a59b725e

Comment 56

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Infrastructure failures with hg.mozilla.org stopped me from merging this over to m-c in time for the 4pm nightlies. (Though I guess the hg.m.o issues would likely break the nightlies entirely, so no still-broken nightlies would be pushed out.)

Comment 57

[Sotaro Ikeda [:sotaro]]

(In reply to Michael Vines [:m1] [:evilmachines] from comment #53)
> Attachment 8577840 [details] [diff] causes a corrupt preview of the "big
> buck bunny" video in the Video app.
> 
> The matching code for attachment 8577836 [details] [review] in our tree is here [1]. 
> Slightly different, but if I make the what's on CAF match attachment 8577836 [details] [review]
> [details] then I see more misalignment of the preview.
> 
> Let's not uplift this to b2g37 until this potential regression is better
> understood please.  There's devices with :sku that you could try this patch
> on.

It might be caused by stride problem.

Comment 58

[Michael Vines [:m1] [:evilmachines]]

Yeah it was definitely a stride problem introduced by that patch.

Comment 59

[Michael Wu [:mwu]]

Attachment: Fallback on lock_ycbcr conversion

This lets us fallback on lock_ycbcr when android::ColorConverter doesn't work. This avoids lock_ycbcr on devices where it isn't implemented or isn't implemented correctly.

Comment 60

[Sotaro Ikeda [:sotaro]]

Comment on attachment 8579102 [details] [diff] [review]
Fallback on lock_ycbcr conversion

Review of attachment 8579102 [details] [diff] [review]:
-----------------------------------------------------------------

The implementation looks good. But I confirmed that the patch caused the crash on master flame-kk. The crash stack was the following. On master flame-kk, mAllocMod->lock_ycbcr was nulptr. Then it caused the crash.


(gdb) info stack
#0  0x00000000 in ?? ()
#1  0xb4baf7e6 in android::GraphicBufferMapper::lockYCbCr (this=0xb21be9c8, handle=0xb0641110, usage=usage@entry=3, bounds=..., 
    ycbcr=ycbcr@entry=0xbefc883c) at frameworks/native/libs/ui/GraphicBufferMapper.cpp:95
#2  0xb4bae9ce in android::GraphicBuffer::lockYCbCr (this=0xb283b080, usage=usage@entry=3, rect=..., ycbcr=ycbcr@entry=0xbefc883c)
    at frameworks/native/libs/ui/GraphicBuffer.cpp:222
#3  0xb4bae9f4 in android::GraphicBuffer::lockYCbCr (this=<optimized out>, usage=usage@entry=3, ycbcr=ycbcr@entry=0xbefc883c)
    at frameworks/native/libs/ui/GraphicBuffer.cpp:208
#4  0xb54a960e in ConvertVendorYUVFormatToRGB565 (aMappedSurface=0xbefc882c, aSurface=0xb36ba170, aBuffer=...)
    at ../../../gecko/gfx/layers/GrallocImages.cpp:229
#5  mozilla::layers::GrallocImage::GetAsSourceSurface (this=0xafef2500) at ../../../gecko/gfx/layers/GrallocImages.cpp:411
#6  0xb54a0704 in mozilla::layers::ImageContainer::LockCurrentAsSourceSurface (this=0xb0dff140, aSize=aSize@entry=0xbefc8938, 
    aCurrentImage=aCurrentImage@entry=0xbefc8934) at ../../../gecko/gfx/layers/ImageContainer.cpp:293
#7  0xb54a6b0c in AutoLockImage (aSurface=0xbefc8924, aContainer=<optimized out>, this=0xbefc8930)
    at ../../../gecko/gfx/layers/ImageContainer.h:599
#8  mozilla::layers::BasicImageLayer::Paint (this=0xb2140000, aDT=0xb09d81e0, aDeviceOffset=..., aMaskLayer=0x0)
    at ../../../gecko/gfx/layers/basic/BasicImageLayer.cpp:76
#9  0xb54c0044 in mozilla::layers::BasicLayerManager::PaintSelfOrChildren (this=this@entry=0xafef2d20, aPaintContext=..., 
    aGroupTarget=aGroupTarget@entry=0xb09d8240) at ../../../gecko/gfx/layers/basic/BasicLayerManager.cpp:807
#10 0xb54c028c in mozilla::layers::BasicLayerManager::PaintLayer (this=this@entry=0xafef2d20, aTarget=aTarget@entry=0xb09d8240, 
    aLayer=0xb2140000, aCallback=<optimized out>, aCallbackData=0xbefc9778)

Comment 61

[Michael Wu [:mwu]]

Hmm, I can't reproduce a crash with my new patch. What test video are you using? When I record a video with the new patch, there's no crash. But if I force the code to take the lock_ycbcr path by removing the venus entry from the GrallocImage::sColorIdMap table, it crashes. AFAICT, the patch works as expected on flame kk..

Comment 62

[Michael Wu [:mwu]]

This patch replaces the old one, so make sure you have the venus entry in sColorIdMap.

Comment 63

[Michael Vines [:m1] [:evilmachines]]

(FWIW, pulling in just attachment 8579102 [details] [diff] [review] didn't reproduce the issue I noted in comment 54 on devices here)

Comment 64

[Sotaro Ikeda [:sotaro]]

(In reply to Michael Wu [:mwu] from comment #61)
> Hmm, I can't reproduce a crash with my new patch. What test video are you
> using? When I record a video with the new patch, there's no crash. But if I
> force the code to take the lock_ycbcr path by removing the venus entry from
> the GrallocImage::sColorIdMap table, it crashes. AFAICT, the patch works as
> expected on flame kk..

Sorry, somehow, applying the patch failed to update the ROM on my environment :-( After removing the all intermediate files and build, the crash did not happen.

Comment 65

[cafbot (PoC: ggrisco)]

Observed on: 

Device: msm8909
Gonk Version: AU_LINUX_GECKO_LF.BR.1.2.3.00.00.00.000.086
Moz BuildID: 20150225002505
Manifest: https://www.codeaurora.org/cgit/quic/lf/b2g/manifest/tree/caf_AU_LINUX_GECKO_LF.BR.1.2.3.00.00.00.000.086.xml?h=release
Gecko Version: 37.0
Gaia:  http://git.mozilla.org/?p=releases/gaia.git;a=commit;h=ca64f2fe145909f31af266b1730874051ba76c78
Gecko: http://git.mozilla.org/?p=releases/gecko.git;a=commit;h=fe489912aac2f83b14e7286b8f92443f6c6b64a7
Patches: bug 1067629, bug 1133147, bug 1139469, bug 1142770, bug 1053634

Comment 66

[cafbot (PoC: ggrisco)]

Attachment: EXTRA file attachment - AU_LINUX_GECKO_LF.BR.1.2.3.00.00.00.000.086

Comment 67

[cafbot (PoC: ggrisco)]

Attachment: decoded minidump - AU_LINUX_GECKO_LF.BR.1.2.3.00.00.00.000.086

Comment 68

[Michael Wu [:mwu]]

https://hg.mozilla.org/integration/b2g-inbound/rev/8368cc78389e

Comment 69

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/8368cc78389e

Comment 70

[Hermes Cheng (inactive after July 27, 2015)]

please uplift to 2.2 since it is a 2.2 blocker. Thanks

NI myself for following verification.

Comment 71

[Hermes Cheng (inactive after July 27, 2015)]

Use below build to verify this bug. After recording, the thumbnail was created correctly and Video app can show thumbnail of each video file. Michael, could you please uplift to 2.2? Thanks.

* Env info:
Build ID               20150322160204
Gaia Revision          9b6f3024e4d0e62dd057231f4b14abe1782932ab
Gaia Date              2015-03-22 10:09:18
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/e730012260a4
Gecko Version          39.0a1
Device Name            hammerhead
Firmware(Release)      5.0
Firmware(Incremental)  eng.cltbld.20150322.191717
Firmware Date          Sun Mar 22 19:17:33 EDT 2015
Bootloader             HHZ12d

Comment 72

[Hermes Cheng (inactive after July 27, 2015)]

(In reply to Hermes Cheng[:hermescheng] from comment #70)
> please uplift to 2.2 since it is a 2.2 blocker. Thanks
> 
> NI myself for following verification.

Micahel, could you help uplift?

Comment 73

[Michael Wu [:mwu]]

A sheriff will uplift once there is approval.

Comment 74

[Michael Wu [:mwu]]

Comment on attachment 8577838 [details] [review]
Switch N5 to fork of hardware/qcom/display

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Not a regression.
User impact if declined: No thumbnails on videos in the video app on the N5 L port.
Testing completed: Verified on master.
Risk to taking this patch (and alternatives if risky): Low.
String or UUID changes made by this patch: None.

Comment 75

[Michael Wu [:mwu]]

Comment on attachment 8579102 [details] [diff] [review]
Fallback on lock_ycbcr conversion

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Not a regression.
User impact if declined: No thumbnails on videos in the video app on the N5 L port.
Testing completed: Verified on master. Tested on Flame and N5, and m1 has also tested it on his device.
Risk to taking this patch (and alternatives if risky): Devices without an implementation of lock_ycbcr may crash. This crash indicates a real bug that needs to be fixed regardless though, so that's actually a good thing.
String or UUID changes made by this patch: None.

Comment 76

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/7efb777629fd

v2.2: https://github.com/mozilla-b2g/b2g-manifest/commit/7f607b7c1b535bd969d59d4828e4c3a1629b3045

Comment 77

[Hermes Cheng (inactive after July 27, 2015)]

NI myself for 2.2 verification. It seems not included in today's pvt build.

Comment 78

[Hermes Cheng (inactive after July 27, 2015)]

2.2 verified:

Build ID               20150326164141
Gaia Revision          6d0174e28576f2f93e696a43d1ac3b03340117f6
Gaia Date              2015-03-26 21:47:33
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/820c2f2e817a
Gecko Version          37.0
Device Name            hammerhead
Firmware(Release)      5.0
Firmware(Incremental)  eng.cltbld.20150326.200911
Firmware Date          Thu Mar 26 20:09:35 EDT 2015
Bootloader             HHZ12d