Closed Bug 1169093 Opened 9 years ago Closed 9 years ago

sometimes in landscape bottom of video corrupts with control bar

Categories

(Core :: Graphics, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla41
blocking-b2g 2.2+
Tracking Status
firefox39 --- wontfix
firefox40 --- wontfix
firefox41 --- fixed
b2g-v2.1 --- unaffected
b2g-v2.2 --- verified
b2g-master --- verified

People

(Reporter: Jamie_, Assigned: sotaro)

References

Details

(Keywords: regression, verifyme)

Attachments

(4 files, 1 obsolete file)

      No description provided.
while attempting to watch video the progress bar and video control bar will corrupt the bottom part of the video till its collapsed.

str:
1) navigate to video
2) put deice in landscape
3) open to view video
4) start video in full screen
5) observe the bottom of the screen where the bar is

actual results:
The area where the bar is, is partially corrupt until you tap to minimize the bar

expected results:
video plays fine and when the bar is up there is no corrupted portion of view on the video

notes: This is not 100 percent repro rate

environmental notes:
device: flame 3.0
build ID: 20150527225444
Version: 41.0a1 (3.0)
Firmware Version: v18D_nightly_v2
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0
Note:
STR 1 should be: open browser and go to youtube.com.

QAwanted to figure out if there's a more consistent way of reproducing the issue, add a video demonstrating the issue, and branch checking.
Keywords: qawanted
QA Contact: pcheng
Video demonstrating the issue:
https://www.youtube.com/watch?v=7_ShET_IdhM

More refined STR:
1) Plug in the phone (charging) and connect to Wifi
2) Open browser, and access http://youtu.be/rqkPe-F9q60
3) Tap to play the video (no HD)
4) Once it's playing, tap on video and make the video full screen
5) Once in full screen, put the phone in landscape
6) Tap on screen to bring up the video controls; do this several times over the course of 2 minutes

Actual: Starting at around 1min 15sec into the video, tapping on screen to show controls will make the bottom portion of video appear corrupt. See video above.

Expected: No video corruption.

Repro rate: 5 out of 5 with this refined STR on multiple devices, regardless of memory settings.

---------

This issue is also reproducible on Flame 2.2.

Device: Flame 2.2
BuildID: 20150527002504
Gaia: 8084264c4d1e28bc33220bc7443c7425bb76dbcc
Gecko: 19fcc06fb7ab
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

------

This issue does NOT occur on Flame 2.1. Following STR, no video corruption was observed.

Device: Flame 2.1
BuildID: 20150527001205
Gaia: 2304a1f6327c2ccf35d6995ee16f2231ed1f22a3
Gecko: cc064744135f
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 34.0 (2.1) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: qawantedregression
Bad user experience. This could affect many end users so nominating 2.2?
blocking-b2g: --- → 2.2?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
QA Contact: pcheng
Assignee: nobody → jthomas
Assignee: jthomas → nobody
QA Contact: jthomas
Mozilla Inbound Regression Window

Last Working 
Environmental Variables:
Device: Flame 3.0
BuildID: 20150514061055
Gaia: 338f66e6a96491d2f5854b188c6b141ceb690d97
Gecko: 1189f6ffc65e
Version: 41.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0


First Broken 
Environmental Variables:
Device: Flame 3.0`
BuildID: 20150514090744
Gaia: 338f66e6a96491d2f5854b188c6b141ceb690d97
Gecko: fde31eaa2638
Version: 41.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0



Last Working gaia / First Broken gecko - This issue DOES occur with broken Gecko.
Gaia: 338f66e6a96491d2f5854b188c6b141ceb690d97
Gecko: fde31eaa2638

First Broken gaia / Last Working gecko - This issue does NOT occur with working Gecko.
Gaia: 338f66e6a96491d2f5854b188c6b141ceb690d97
Gecko: 1189f6ffc65e

Mozilla Inbound Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1189f6ffc65e&tochange=fde31eaa2638


I think the Issue appears to occur due to changes made in Bug 1152461
Blocks: 1152461
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Markus, can you look at this please? We double checked this window and it appears to be correct. This is confusing since no bug in the push log looks like it was uplifted to 2.2 and this issue affects 2.2. We are guessing bug 1152461 here but we really have no idea what caused this.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker) → needinfo?(markus)
Flags: needinfo?(markus) → needinfo?(mstange)
This is pure speculation, but maybe something like this happened:
 - Bug 1148022 landed on April 2nd, causing tiled layers to be used for the video controls.
 - Between April 2nd and May 14th, some change was made to ContentClientSingleBuffered that caused this
   bug, and this change was also uplifted to 2.2.
 - Bug 1152461 landed on May 14th, causing us to stop using tiles and exposing the
   ContentClientSingleBuffered bug.

Does anything come to mind, nical?
Flags: needinfo?(mstange) → needinfo?(nical.bugzilla)
I'll start debugging it anyway.
Assignee: nobody → mstange
Status: NEW → ASSIGNED
In the meantime, can somebody find a 2.2 regression range?
Flags: needinfo?(ktucker)
(In reply to Markus Stange [:mstange] from comment #7)
> 
> Does anything come to mind, nical?

nothing off the top of my head, sorry
Flags: needinfo?(nical.bugzilla)
Let's find the window on 2.2.
QA Whiteboard: [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Mozilla-b2g37_v2_2flame-kk-eng Regression Window

Last Working 
Environmental Variables:
Device: Flame 2.2
BuildID: 20150319061538
Gaia: 539844a978acf7a32d4e8be49a2c5503c189fdae
Gecko: a1e053c6af5b
Version: 37.0 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0


First Broken 
Environmental Variables:
Device: Flame 2.2
BuildID: 20150319064642
Gaia: 3c5565bcdf0045261e0fd76e700eb32c4bbf3dc0
Gecko: d8dbb33fa801
Version: 37.0 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Last Working gaia / First Broken gecko - This issue DOES occur with broken Gecko
Gaia: 539844a978acf7a32d4e8be49a2c5503c189fdae
Gecko: d8dbb33fa801

First Broken gaia / Last Working gecko - This issue does NOT occur with working Gecko
Gaia: 3c5565bcdf0045261e0fd76e700eb32c4bbf3dc0
Gecko: a1e053c6af5b

Mozilla-b2g37_v2_2flame-kk-eng Pushlog:
http://hg.mozilla.org/releases/mozilla-b2g37_v2_2/pushloghtml?fromchange=a1e053c6af5b&tochange=d8dbb33fa801


Issue appears to occur due to changes made in 1139464
Blocks: 1139464
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
I am going to analyze it from hwc hal's point of view.
Layout occlusion culling removed a shape from the video's visible region that increased its complexity to 8 rects.
Attached file not a testcase
I was hoping this testcase would reproduce the problem, but it doesn't.
I think this is a HWC bug; reassigning to Sotaro.
Assignee: mstange → sotaro.ikeda.g
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
user facing regression.
blocking-b2g: 2.2? → 2.2+
When the problem happened, "adb shell dmesg" log had the following messages. It say, requested blit request exceeded the hardware's limit.

<3>[  184.043035] mdp3_ppp_verify_scale: y req scale factor beyond capability
<3>[  184.048612] mdp3_ppp_blit: invalid image!
<3>[  184.109404] mdp3_ppp_verify_scale: y req scale factor beyond capability
<3>[  184.115069] mdp3_ppp_blit: invalid image!
<3>[  184.158696] mdp3_ppp_verify_scale: y req scale factor beyond capability
<3>[  184.164479] mdp3_ppp_blit: invalid image!
<3>[  184.283166] mdp3_ppp_verify_scale: y req scale factor beyond capability
When the driver's error happened, requested region's size was the following. Height's scaling exceeded the hardware's limit.

  > src(w=23,h=1) dst(w=62,h=5)
The following is a one layer's regions' dump just before requesting blit. '5' seems the above problematic region.

06-02 16:15:42.333   211   884 E qdcopybit: 0: src={w=864, h=480, f=28, rect={62,375,11,5}}
06-02 16:15:42.333   211   884 E qdcopybit:     dst={w=480, h=864, f=13, rect={100,62,5,11}}
06-02 16:15:42.333   211   884 E qdcopybit:     flags=00041004
06-02 16:15:42.333   211   884 E qdcopybit: 1: src={w=864, h=480, f=28, rect={58,380,15,7}}
06-02 16:15:42.333   211   884 E qdcopybit:     dst={w=480, h=864, f=13, rect={93,58,7,15}}
06-02 16:15:42.333   211   884 E qdcopybit:     flags=00041004
06-02 16:15:42.333   211   884 E qdcopybit: 2: src={w=864, h=480, f=28, rect={62,387,11,6}}
06-02 16:15:42.333   211   884 E qdcopybit:     dst={w=480, h=864, f=13, rect={87,62,6,11}}
06-02 16:15:42.333   211   884 E qdcopybit:     flags=00041004
06-02 16:15:42.333   211   884 E qdcopybit: 3: src={w=480, h=864, f=13, rect={0,0,480,854}}
06-02 16:15:42.333   211   884 E qdcopybit:     dst={w=480, h=864, f=13, rect={0,0,480,854}}
06-02 16:15:42.333   211   884 E qdcopybit:     flags=00061020
06-02 16:15:42.333   211   884 E qdcopybit: 4: src={w=320, h=180, f=6, rect={0,0,320,140}}
06-02 16:15:42.333   211   884 E qdcopybit:     dst={w=480, h=864, f=13, rect={105,0,375,854}}
06-02 16:15:42.333   211   884 E qdcopybit:     flags=00001004
06-02 16:15:42.333   211   884 E qdcopybit: 5: src={w=320, h=180, f=6, rect={0,140,23,1}}
06-02 16:15:42.333   211   884 E qdcopybit:     dst={w=480, h=864, f=13, rect={100,0,5,62}}
06-02 16:15:42.333   211   884 E qdcopybit:     flags=00001004
06-02 16:15:42.333   211   884 E qdcopybit: 6: src={w=320, h=180, f=6, rect={27,140,292,1}}
06-02 16:15:42.333   211   884 E qdcopybit:     dst={w=480, h=864, f=13, rect={100,73,5,781}}
06-02 16:15:42.333   211   884 E qdcopybit:     flags=00001004
06-02 16:15:42.333   211   884 E qdcopybit: 7: src={w=320, h=180, f=6, rect={0,142,21,2}}
06-02 16:15:42.333   211   884 E qdcopybit:     dst={w=480, h=864, f=13, rect={93,0,7,58}}
06-02 16:15:42.333   211   884 E qdcopybit:     flags=00001004
06-02 16:15:42.333   211   884 E qdcopybit: 8: src={w=320, h=180, f=6, rect={27,142,292,2}}
06-02 16:15:42.333   211   884 E qdcopybit:     dst={w=480, h=864, f=13, rect={93,73,7,781}}
06-02 16:15:42.333   211   884 E qdcopybit:     flags=00001004
06-02 16:15:42.333   211   884 E qdcopybit: 9: src={w=320, h=180, f=6, rect={0,145,23,2}}
06-02 16:15:42.333   211   884 E qdcopybit:     dst={w=480, h=864, f=13, rect={87,0,6,62}}
06-02 16:15:42.333   211   884 E qdcopybit:     flags=00001004
It seems that the above '5' region's height scaling becomes 5 because of rounding error. It seems to exceeded the hw max. Although layer's scaling is not exceeded the hw max.
Component: Video/Audio → Graphics
hwc api uses "int type" for the region size. Therefore, width=1 or height=1 could cause a rounding error easily if there is a scaling.

The problem could becomes simpler if HwcComposer2D rejects a region that has src region of "width=1 or height=1". Out main hwc usage use cases does no have such region. Therefore it should be OK.
I confirmed the patch fixed the problem.
Attachment #8614331 - Flags: review?(matt.woodrow)
If we want to fix this problem ideally, hwc hal's code seems ideal place. But we could not expect all hwc hals fix this problem. Therefore HwcUtils::PrepareVisibleRegion() was chosen to detect it.
Attachment #8614331 - Flags: review?(matt.woodrow) → review+
Update comments. Carry "r=mattwoodrow".
Attachment #8614331 - Attachment is obsolete: true
Attachment #8615296 - Flags: review+
https://hg.mozilla.org/mozilla-central/rev/96c7f8482029
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
Hi Sotaro, could you uplift to v2.2 since it is a 2.2 blocker?
Flags: needinfo?(sotaro.ikeda.g)
Comment on attachment 8615296 [details] [diff] [review]
patch - Do not use HWC when a region of layer is too small

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 #): none
User impact if declined: User see partially rendered video in some cases.
Testing completed: locally tested.
Risk to taking this patch (and alternatives if risky): low risk
String or UUID changes made by this patch: none
Flags: needinfo?(sotaro.ikeda.g)
Attachment #8615296 - Flags: approval-mozilla-b2g37?
Attachment #8615296 - Flags: approval-mozilla-b2g37? → approval-mozilla-b2g37+
Keywords: verifyme
Pi Wei, could you please help verify?
Flags: needinfo?(pcheng)
qawanted to verify this issue. note that 2.2 has just been uplifted so we'll need tomorrow's nightly for 2.2 verification.
Flags: needinfo?(pcheng)
Keywords: qawanted
This issue is verified fixed on Flame 3.0. Following STR on comment 3, no video corruption occurs.

Device: Flame (319MB, KK, full flashed)
BuildID: 20150608010204
Gaia: 1d62b32408567f9f7cf1c71c1e5a0c6593be757b
Gecko: 7d4ab4a9febd
Gonk: 040bb1e9ac8a5b6dd756fdd696aa37a8868b5c67
Version: 41.0a1 (3.0 Master)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0

Leaving verifyme keyword for v2.2 verification on tomorrow's nightly.
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
This bug has been verified as "pass" on latest Nightly build of Flame v2.2 by the STR in Comment 3.

Actual results: Video plays fine and when the bar is up there is no corrupted portion of view on the video.
See attachment: verified_v2.2.mp4
Reproduce rate: 0/10


Device: Flame v2.2 build(Pass)
Build ID               20150609081832
Gaia Revision          06edb0f8db7c2f45cde54401a8593663059861a4
Gaia Date              2015-06-08 14:29:09
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/239c59921129
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150609.122002
Firmware Date          Tue Jun  9 12:20:13 EDT 2015
Bootloader             L1TC000118D0
Attached video verified_v2.2.mp4
Leaving verifyme keyword for firefox41 verification.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][MGSEI-Triage+]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: