Nightly Fennec cannot show the content of mp4.

RESOLVED FIXED in Firefox 27

Status

()

defect
--
major
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: yuege513, Assigned: eflores)

Tracking

({regression, reproducible})

Trunk
mozilla29
ARM
Android
Points:
---

Firefox Tracking Flags

(firefox26 unaffected, firefox27+ fixed, firefox28+ fixed, firefox29 fixed, fennec27+)

Details

Attachments

(2 attachments, 1 obsolete attachment)

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.
OS: Linux → Android
Hardware: x86_64 → ARM
Component: Graphics, Panning and Zooming → Video/Audio
Product: Firefox for Android → Core
Version: Trunk → Other Branch
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.
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.
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!
nical ಠ_ಠ
Flags: needinfo?(nical.bugzilla)
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?
Flags: needinfo?(nical.bugzilla)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: Other Branch → Trunk
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
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.
Assignee: nobody → edwin
Status: NEW → ASSIGNED
Posted patch 934412.patchSplinter Review
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.
Attachment #832450 - Flags: review?(nical.bugzilla)
Attachment #832450 - Flags: review?(nical.bugzilla) → review+
Duplicate of this bug: 933325
Duplicate of this bug: 940891
tracking-fennec: --- → ?
Severity: normal → major
(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?
See above.
Flags: needinfo?(nical.bugzilla)
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.
Edwin - Any idea on when we could get this closed?
tracking-fennec: ? → 27+
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.
Flags: needinfo?(nical.bugzilla)
Posted patch 934412-2.patch (obsolete) — Splinter Review
Found it.
Attachment #8345557 - Flags: review?(nical.bugzilla)
Attachment #8345557 - Attachment is obsolete: true
Attachment #8345557 - Flags: review?(nical.bugzilla)
Attachment #8345659 - Flags: review?(nical.bugzilla)
Attachment #8345659 - Flags: review?(nical.bugzilla) → review+
Oops, left a [leave open] here.
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Whiteboard: [leave open]
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.
Attachment #832450 - Flags: approval-mozilla-beta?
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.
Attachment #8345659 - Flags: approval-mozilla-beta?
Attachment #8345659 - Flags: approval-mozilla-aurora?
Target Milestone: --- → mozilla29
Attachment #8345659 - Flags: approval-mozilla-beta?
Attachment #8345659 - Flags: approval-mozilla-beta+
Attachment #8345659 - Flags: approval-mozilla-aurora?
Attachment #8345659 - Flags: approval-mozilla-aurora+
Comment on attachment 832450 [details] [diff] [review]
934412.patch

Is this one meant to be Beta-only?
Attachment #832450 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
(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.
You need to log in before you can comment on or make changes to this bug.