934412 - Nightly Fennec cannot show the content of mp4.

Status: RESOLVED FIXED

(Core :: Audio/Video, defect)

Description

[YueGe]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 (Beta/Release)
Build ID: 20130201190337

Steps to reproduce:

Step 1: Create a page which includes only an element of 'video'.
Step 2: Set the 'source' of  the 'video' element to be a link to local mp4 file.
Step 3: Open the page and it fails to display the image of mp4.


Actual results:

It seems that there is a memleak somewhere.
The info of TextureClient::mBuffer diffs from that of its responding TextureHost::mBuffer.

Comment 1

[Aaron Train [:aaronmt]]

You're going to need to post what device, version of Android, and version of Firefox you are testing with. There is little information in your bug report here.

Comment 2

[YueGe]

Device : HTC one.
Version of Fennec : Nightly build of 2013-11-04.
Version of Android: 4.1

Everything goes well be for the commit : Bug 922007 - Use the new texture clients and hosts on fennec. r=mattwoodrow.
If add "pref("layers.use-deprecated-textures", true);" to mobile/android/app/mobile.js, it can work well.

Comment 3

[Chris Pearce [:cpearce (Not reading bugmail)]]

I can confirm what YueGe found, if I toggle layers.use-deprecated-textures in about:config, H.264 decoding works again on my HTC One. Thanks YueGe!

Comment 4

[Edwin Flores [inactive from 2016-12-01] [:eflores] [:edwin]]

nical ಠ_ಠ

Comment 5

[Nicolas Silva [:nical]]

Seems to work on Galaxy Nexus, what differences are there between HTC One and Galaxy Nexus for H264?
In particular are they both using SharedYCbCrImage/SharedRGBImage?

Comment 6

[Nicolas Silva [:nical]]

I grabbed a nexus 4 and tested with this page: http://ie.microsoft.com/testdrive/graphics/videoformatsupport/default.html

Interestingly, baseline profile works while the high profile one only outputs sound. I put some breakpoints and non of the layers/TextureClient code is called (not even ImageContainer::SetCurrentImageInternal). So I guess it is a different problem.

I see this in the logcat: I/NuCachedSource2(15584): ERROR_END_OF_STREAM

Comment 7

[cajbir (:cajbir)]

Baseline working but high profile not is usually an indicator that the stagefright software decoder is being used instead of the hardware decoder. If you look in the 'adb logcat' output you'll see something like:

10-28 12:33:32.945: I/OmxPlugin(17985): Unknown video color format: 0x7fa30c03
10-28 12:33:32.945: I/OmxPlugin(17985): Falling back to software decoder


If so, this is probably the same as bug 931778 and maybe bug 932699. From comment 3 maybe something in the texture bug changed the video color format being used.

Comment 8

[Edwin Flores [inactive from 2016-12-01] [:eflores] [:edwin]]

Attachment: 934412.patch

Part 1. GetBuffer() wasn't returning the correct offset, so the decoder was walking all over the buffer header. This patch just adds that offset.

With this change, the compositor now actually tries to use the texture. Unfortunately something bad is happening when offscreen format = 24 bit RGB and we try to use the 16-bit image we get from the decoder.

Comment 11

[Edwin Flores [inactive from 2016-12-01] [:eflores] [:edwin]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/bf6688c7464b

Comment 12

[Edwin Flores [inactive from 2016-12-01] [:eflores] [:edwin]]

(In reply to Edwin Flores [:eflores] [:edwin] from comment #8)
> With this change, the compositor now actually tries to use the texture.
> Unfortunately something bad is happening when offscreen format = 24 bit RGB
> and we try to use the 16-bit image we get from the decoder.

nical, I'm having some trouble tracking down the other side of this bug; hoping you can provide some insight here.

It seems that RGB565 textures aren't being drawn [3] properly when offscreen format is 24-bit RGB. I've taken a look but gotten totally lost in layers code.

If you have time to take a look, you can probably [2] reproduce this on Galaxy Nexus by changing the |#ifdef ...| at [1] to |#ifdef 0| and watching a baseline profile video. On some phones, you get no image; on other phones you get crazy-looking noise.

If you're unable to reproduce this, a hint as to where I should start looking would be appreciated.

[1] http://dxr.mozilla.org/mozilla-central/source/media/omx-plugin/OmxPlugin.cpp?from=OmxPlugin.cpp#689
[2] I say `probably' because yay, Android fragmentation.
[3] For some definition of `drawn'. Composited?

Comment 13

[Edwin Flores [inactive from 2016-12-01] [:eflores] [:edwin]]

See above.

Comment 14

[Carsten Book [:Tomcat]]

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

Comment 15

[Nicolas Silva [:nical]]

I am looking at this a bit beside other work so if I am not answering it's just that I haven't found something interesting to say yet. Leaving the needinfo so that bugzilla keeps remind me to look at this stuff.

Comment 16

[Mark Finkle (:mfinkle) (use needinfo?)]

Edwin - Any idea on when we could get this closed?

Comment 17

[Nicolas Silva [:nical]]

Edwin, I haven't been able to reproduce on the android phones I have. If you have a rough idea of where things are going wrong (like, say, on the client side vs on the compositor side) I can probably give you some pointers about what's going on in the code.

Comment 18

[Edwin Flores [inactive from 2016-12-01] [:eflores] [:edwin]]

Attachment: 934412-2.patch

Found it.

Comment 19

[Edwin Flores [inactive from 2016-12-01] [:eflores] [:edwin]]

Attachment: 934412-format.patch

Comment 20

[Nicolas Silva [:nical]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/c8d4a4361516

Comment 21

[Ryan VanderMeulen [:RyanVM]]

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

Comment 22

[Edwin Flores [inactive from 2016-12-01] [:eflores] [:edwin]]

Oops, left a [leave open] here.

Comment 23

[Edwin Flores [inactive from 2016-12-01] [:eflores] [:edwin]]

Comment on attachment 832450 [details] [diff] [review]
934412.patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 922007
User impact if declined: H264 playback on Fennec not working.
Testing completed (on m-c, etc.): Works on all devices I have handy. Existing known issue with high profile videos not playing due to unrelated bug. (bug 866080)
Risk to taking this patch (and alternatives if risky): None.
String or IDL/UUID changes made by this patch: None.

Comment 24

[Edwin Flores [inactive from 2016-12-01] [:eflores] [:edwin]]

Comment on attachment 8345659 [details] [diff] [review]
934412-format.patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 922007
User impact if declined: H264 playback on Fennec not working.
Testing completed (on m-c, etc.): Works on all devices I have handy. Existing known issue with high profile videos not playing due to unrelated bug. (bug 866080)
Risk to taking this patch (and alternatives if risky): None.
String or IDL/UUID changes made by this patch: None.

Comment 25

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 832450 [details] [diff] [review]
934412.patch

Is this one meant to be Beta-only?

Comment 26

[Edwin Flores [inactive from 2016-12-01] [:eflores] [:edwin]]

(In reply to Lukas Blakk [:lsblakk] from comment #25)
> Comment on attachment 832450 [details] [diff] [review]
> 934412.patch
> 
> Is this one meant to be Beta-only?

Yes -- that patch landed on 28.

Comment 27

[Edwin Flores [inactive from 2016-12-01] [:eflores] [:edwin]]

https://hg.mozilla.org/releases/mozilla-beta/rev/d551dd374cfc
https://hg.mozilla.org/releases/mozilla-beta/rev/297a28ff75f8

https://hg.mozilla.org/releases/mozilla-aurora/rev/df7a620de218