Closed Bug 1100126 Opened 10 years ago Closed 9 years ago

Flickering green/pink screen while playback video in different devices

Categories

(Firefox for Android Graveyard :: Audio/Video, defect)

36 Branch
Other
Android
defect
Not set
normal

Tracking

(firefox34 wontfix, firefox35 wontfix, firefox36 wontfix, firefox37 verified, firefox38 verified, fennec35+)

VERIFIED FIXED
Firefox 38
Tracking Status
firefox34 --- wontfix
firefox35 --- wontfix
firefox36 --- wontfix
firefox37 --- verified
firefox38 --- verified
fennec 35+ ---

People

(Reporter: rayman-1996, Assigned: snorp, NeedInfo)

References

Details

(Whiteboard: mediacodec)

Attachments

(4 files, 2 obsolete files)

User Agent: Mozilla/5.0 (Android; Tablet; rv:36.0) Gecko/36.0 Firefox/36.0
Build ID: 20141115030205

Steps to reproduce:

Play any HTML5 video on website


Actual results:

Screen is flickering (green color in video frame) while playback video.
There is a green screen (in video frame) when video while pause. After resume video is flickering again. 


Expected results:

Video is not flickering
There is no green screen
*(...) green screen (in video frame) while pause (...)
Can you try Nightly and report back if video is working for you? (http://nightly.mozilla.org)
Flags: needinfo?(rayman-1996)
I described exactly Nightly relase and there is better than in official Firefox 33 where 75% videos don't work whatever if i will not play these in external player (MX Player). 
In Nightly all videos which i tested works (wow! On my Lenovo A3500 4.42 this is sole browser), the only problem is this stupid flickering.
Flags: needinfo?(rayman-1996)
Sorry I missed that it was filed against Nightly. Which device has the flickering? Is it the mentioned Lenovo? Which Android version?
Yes, Lenovo A-3500, Android 4.4.2
In Acer Iconia A1-811 there is a similar problem but instead flickering there are artefacts (horizontal strips like disruptions in old TV). If you want I will add screenshots.
I missed: Acer Iconia A1-811 Android 4.2
Blocks: mediacodec
Status: UNCONFIRMED → NEW
Ever confirmed: true
Yea please attach screenshots.

CC'ing cause YUV stuff
Whiteboard: mediacodec
Let's make a note here to re-test Nightly after bug 1097116 lands
Ok, Firefox Nightly 36.0a1

Acer Iconia A1-811 (Android 4.2)
http://i.imgur.com/BCbUzPf.png
after few seconds horizontal strips http://i.imgur.com/g73LQde.png then again all is normal http://i.imgur.com/XD4XS3k.png few seconds later again strips http://i.imgur.com/jD3gCH8.png etc.
Lenovo A3500 (Android 4.4.2)
http://i.imgur.com/j3aaxUb.png after few seconds http://i.imgur.com/rIsE3vu.png then again all is normal http://i.imgur.com/CPQ0C4W.png then again flickering http://i.imgur.com/rIsE3vu.png etc.

The time betweenoccurrence artifacts is different every time but usually there is no more than 5sec in both cases.
I hope you understand if not i will upload film with this event
I've also gotten an email report that the Micromax AQ4501 (Android 4.4.4) has green flickering problems while playing MP4 video on Nightly.

CC'ing Sudhir
Assignee: nobody → snorp
Status: NEW → ASSIGNED
tracking-fennec: --- → ?
Summary: Flickering green screen while playback video → Flickering green screen while playback video in different devices
Some more information on the same:
Hardware configurations:
Model Number:        Micromax AQ4501
Andorid Version :      4.4.4
Baseband version:    WR8.W1412.MD.WG.GMP.SP.W14.26.P3, 2014/08/15 11:39
Kernal version:         3.4.67 Android-build@kpdm5.cbf.corp.google.com #1
                               wed Aug 20 14:13:29 PDT 2014
Build number:          KPW53
tracking-fennec: ? → 35+
Another affected device, a Mediatek MT6592T on 4.4.2 as per bug 1103609.
Can you re-test on today's Nightly (11/28)?
Flags: needinfo?(rayman-1996)
Sure will do that and update the same
Software version: Android 4.4.4 (pls refer to comment 11 for hardware details)

Tested the following URL:
http://people.mozilla.org/~atrain/mobile/tests/media.html

Media Test - H.264/MP4 (Video) :
Observations:
        Audio: Looks fine
        Video: Flickering decreased considerably, but this time it flickers with pink color background

Media Test - MP4 H.264 High Profile (AVC1.64001E) H.264 High Profile Level 3.0 (Video):
Observations:
       Looks fine

Media Test - MP4 H.264 Baseline Profile (AVC1.42001E) H.264 Baseline Profile Level 3.0 (Video):
Observations:
        Audio: Looks fine
        Video: In seldom it flickers with pink color background

Looks like need to re-fix the bug
So in summary instead of green you now see pink. Awesome.
Yes Aaron! :-)
Summary: Flickering green screen while playback video in different devices → Flickering green/pink screen while playback video in different devices
Is there another dependancy here?
Flags: needinfo?(snorp)
If we have a PowerVR GPU, we will fall back to the old OMX plugin stuff (bug 1104876). So the change in behavior here could be a bug in that backend instead (which is the same behavior you should see in 33).
Flags: needinfo?(snorp)
On my Lenovo S650 phone it is not green but flickering white/black. Chrome + default Android 4.2.2 browser work fine, so their way of working with drivers/codecs is fine, but I do not want to use them and Firefox is generally better.

Would it help to install the latest alpha for testing purpose? If yes, where from? I can record screen as the phone has root access, so it might help you better on debugging.
Attached video Last beta test record
Just updated Firefox Beta and the bug is still there on my phone. I also found something interesting: on pause, tapping on the outside of video canvas triggers flickering. See the last part of my movie.
Attaching and detaching the SurfaceTexture doesn't work well on PowerVR, and results in a corrupted image (fencing issue?). Disable detach on those devices.
Attachment #8554629 - Flags: review?(jgilbert)
Copying the SurfaceTexture on PowerVR is super slow, so just don't do it. The result will be slightly out of sync audio/video, but it's better than nothing.
Attachment #8554630 - Flags: review?(jgilbert)
Blocks: 1125619
I wonder (please don't take it as an offence, it is not my intention, but it could help, so please do not throw stones): wouldn't it be a good idea to see how Chrome or default Android player or MX Player do this stuff and replicate the codec? I guess at least one of them is open source so it could be freely used for inspiration.
Since we never detach the surface on PowerVR, we'll fail to attach to it when trying to blit it for GLImage::GetAsSourceSurface(). This fixes that so it fails properly.
Attachment #8555935 - Flags: review?(jgilbert)
Attachment #8554629 - Flags: review?(jgilbert) → review+
Comment on attachment 8554630 [details] [diff] [review]
Enable the AndroidDecoderModule on PowerVR, but don't copy the SurfaceTexture

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

::: dom/media/fmp4/MP4Decoder.cpp
@@ +201,5 @@
>  #ifndef MOZ_WIDGET_ANDROID
>    return false;
>  #else
> +  // // PowerVR is very slow at texture allocation for some reason, which causes poor performance.
> +  // nsCOMPtr<nsIGfxInfo> gfxInfo = do_GetService("@mozilla.org/gfx/info;1");

Why is this all commented?

::: dom/media/fmp4/android/AndroidDecoderModule.cpp
@@ +74,1 @@
>      if (!EnsureGLContext()) {

It's very weird that WantCopy() contains EnsureGLContext(). This should be moved elsewhere, if possible.

@@ +135,5 @@
> +        eglSync = sEGLLibrary.fCreateSync(EGL_DISPLAY(),
> +                                          LOCAL_EGL_SYNC_FENCE,
> +                                          nullptr);
> +        if (eglSync) {
> +            mGLContext->fFlush();

Bad indentation
Attachment #8555935 - Flags: review?(jgilbert) → review+
(In reply to Jeff Gilbert [:jgilbert] from comment #31)
> Comment on attachment 8554630 [details] [diff] [review]
> Enable the AndroidDecoderModule on PowerVR, but don't copy the SurfaceTexture
> 
> Review of attachment 8554630 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: dom/media/fmp4/MP4Decoder.cpp
> @@ +201,5 @@
> >  #ifndef MOZ_WIDGET_ANDROID
> >    return false;
> >  #else
> > +  // // PowerVR is very slow at texture allocation for some reason, which causes poor performance.
> > +  // nsCOMPtr<nsIGfxInfo> gfxInfo = do_GetService("@mozilla.org/gfx/info;1");
> 
> Why is this all commented?

Oops, cruft. Deleted.

> 
> ::: dom/media/fmp4/android/AndroidDecoderModule.cpp
> @@ +74,1 @@
> >      if (!EnsureGLContext()) {
> 
> It's very weird that WantCopy() contains EnsureGLContext(). This should be
> moved elsewhere, if possible.

Well it uses the GLContext. I guess I can move it to the caller.

> 
> @@ +135,5 @@
> > +        eglSync = sEGLLibrary.fCreateSync(EGL_DISPLAY(),
> > +                                          LOCAL_EGL_SYNC_FENCE,
> > +                                          nullptr);
> > +        if (eglSync) {
> > +            mGLContext->fFlush();
> 
> Bad indentation

Fixed
Attachment #8554630 - Attachment is obsolete: true
Attachment #8554630 - Flags: review?(jgilbert)
Attachment #8558107 - Flags: review?(jgilbert)
Comment on attachment 8558107 [details] [diff] [review]
Enable the AndroidDecoderModule on PowerVR, but don't copy the SurfaceTexture

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

::: dom/media/fmp4/android/AndroidDecoderModule.cpp
@@ +130,5 @@
> +        MOZ_ASSERT(mGLContext->IsCurrent());
> +        eglSync = sEGLLibrary.fCreateSync(EGL_DISPLAY(),
> +                                          LOCAL_EGL_SYNC_FENCE,
> +                                          nullptr);
> +        if (eglSync) {

You might want to just assert this is true, or at least also warn when we fail to create a sync object.
Attachment #8558107 - Flags: review?(jgilbert) → review+
https://hg.mozilla.org/mozilla-central/rev/232d59a35db8
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 38
One question: Should the Nightly build work fine, as it seems to be v38+? :)
(In reply to florin arjocu from comment #41)
> One question: Should the Nightly build work fine, as it seems to be v38+? :)

It should, yes. If it doesn't we may need to open another bug.
At least my Lenovo s650 still has a black scree on running the HTML5 player for this film: http://superweb.rol.ro/video/2d46a4cee81f1ebdd40ea85ba2ba0696.html (don't mind the popups, just close them and chose the HTML5 Player to test on your phone). How can I help you to debug, and in the end find a fix? Thanks.
How about uplift to Aurora and Beta?
Flags: needinfo?(snorp)
Flags: needinfo?(jgilbert)
Depends on: 1130996
(In reply to florin arjocu from comment #43)
> At least my Lenovo s650 still has a black scree on running the HTML5 player
> for this film:
> http://superweb.rol.ro/video/2d46a4cee81f1ebdd40ea85ba2ba0696.html (don't
> mind the popups, just close them and chose the HTML5 Player to test on your
> phone). How can I help you to debug, and in the end find a fix? Thanks.

Do the H264 videos here play at all? http://people.mozilla.org/~atrain/mobile/tests/media.html
Flags: needinfo?(snorp)
Flags: needinfo?(jgilbert)
Flags: needinfo?(florin.arjocu)
Comment on attachment 8559151 [details] [diff] [review]
Enable the AndroidDecoderModule on PowerVR, but don't copy the SurfaceTexture r=jgilbert

Approval Request Comment
[Feature/regressing bug #]: bug 1097116
[User impact if declined]: problems playing mp4 videos on devices with Mediatek chips
[Describe test coverage new/current, TreeHerder]: nightly
[Risks and why]: relatively low, have seen no issues with nightly
[String/UUID change made/needed]: none

We would need to uplift all three patches on this bug
Attachment #8559151 - Flags: approval-mozilla-beta?
Attachment #8559151 - Flags: approval-mozilla-aurora?
@James Willcox - on my device (Lenovo s650), with latest Nighly build (last request to be updated was today), I see no difference since some weeks ago: the movies only play the sound and the screen is completely black. Not even mp3 plays on Mozilla media page (no sound on the mp3 player over there).
Flags: needinfo?(florin.arjocu)
(In reply to florin arjocu from comment #47)
> @James Willcox - on my device (Lenovo s650), with latest Nighly build (last
> request to be updated was today), I see no difference since some weeks ago:
> the movies only play the sound and the screen is completely black. Not even
> mp3 plays on Mozilla media page (no sound on the mp3 player over there).

It sounds like we may need to get one of these devices to figure out what's going on. The MediaTek-based tablet I have here is working fine, at least, so might be something specific to that phone. I filed bug 1131793 to track this issue.
(In reply to florin arjocu from comment #47)
> @James Willcox - on my device (Lenovo s650), with latest Nighly build (last
> request to be updated was today), I see no difference since some weeks ago:
> the movies only play the sound and the screen is completely black. Not even
> mp3 plays on Mozilla media page (no sound on the mp3 player over there).

Just to rule things out, are you running Android 4.2+ and is it the original ROM on the device or are you running a custom ROM?
@Aaron Train - yes, factory Android 4.2.2.
Attachment #8559151 - Flags: approval-mozilla-beta?
Attachment #8559151 - Flags: approval-mozilla-beta+
Attachment #8559151 - Flags: approval-mozilla-aurora?
Attachment #8559151 - Flags: approval-mozilla-aurora+
Attachment #8555935 - Flags: approval-mozilla-beta+
Attachment #8555935 - Flags: approval-mozilla-aurora+
Attachment #8554629 - Flags: approval-mozilla-beta+
Attachment #8554629 - Flags: approval-mozilla-aurora+
This is going to need rebasing for the beta uplift.
Flags: needinfo?(snorp)
I turns out I'm not very comfortable with the amount of churn necessary to land this stuff on Beta. I think we should just let it ride in 37.
Flags: needinfo?(snorp)
Verified as fixed in builds:
- 37 Beta 7;
- 38.0a2 2015-03-20;
Device: Lenovo Yoga Tab 10 (Android 4.4.2).
Status: RESOLVED → VERIFIED
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: