Flame: while scanning video via moving the progress bar, image flickers

RESOLVED FIXED in Firefox 39

Status

()

defect
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: njpark, Assigned: bwu)

Tracking

({regression})

unspecified
mozilla39
ARM
Gonk (Firefox OS)
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:2.2+, firefox37 wontfix, firefox38 wontfix, firefox39 fixed, b2g-v2.0 affected, b2g-v2.1 affected, b2g-v2.2 fixed, b2g-master fixed)

Details

Attachments

(1 attachment, 1 obsolete attachment)

Reporter

Description

4 years ago
STR:
- Load video that is about 30 seconds in length
- Open video app, select the video
- Tap and hold the progress bar, and slowly move forward and backward
Actual:
Particular frame is keep flickering
Expected:
Shows the snapshot of the frame as the bar is moved

Version Info:
Reproduces in 2.2, does not occur in master
Gaia-Rev        ea64caf6d4ab03fc4472eca9f41f20d651d55fa9
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/78d823f7be4c
Build-ID        20150217002515
Version         37.0a2
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150217.040742
FW-Date         Tue Feb 17 04:07:53 EST 2015
Bootloader      L1TC000118D0

Video link:
https://www.youtube.com/watch?v=rOKejxI5i40
Reporter

Comment 1

4 years ago
Nominating for blocker since this graphics glitch is easy to reproduce and quite prominent.  milan, do you think it is graphics issue?
blocking-b2g: --- → 2.2?
Flags: needinfo?(milan)

Comment 2

4 years ago
Blocking Reason: flickering of video looks pretty bad. 

Thanks
Hema
blocking-b2g: 2.2? → 2.2+
Can't see the video for some reason; is it a 2.2 regression?  Can we get the range if it is?
Flags: needinfo?(milan)
Reporter

Comment 4

4 years ago
I think there was a youtube issue.  Should be viewable now.
This issue occurs on Flame 3.0, Flame 2.1, and Flame 2.0. Image flickers while dragging the progress bar; it looks like it's trying to display a previous frame before displaying the target frame so it appears flickering if previous frame is a lot different than target frame. This issue occurs in Gallery app as well, but less noticeable.

Device: Flame 3.0 Master
BuildID: 20150218002006
Gaia: 82f286f10a41aab84a0796c89fbefe67b179994b
Gecko: 9696d1c4b3ba
Version: 38.0a1 (3.0 Master)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0

Device: Flame 2.1
BuildID: 20150217142614
Gaia: 0d4b3c63d5cfb01f3312675f85c5ee43a0836d6b
Gecko: f61986c6df4d
Version: 34.0 (2.1) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Device: Flame 2.0
BuildID: 20150217055829
Gaia: ecb1bbc3b9c00f82df172427f65d6f67e34ed533
Gecko: 8fbfc80ec260
Version: 32.0 (2.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

-------

This issue does NOT occur on v18D-1 base image. Image does not flicker when dragging the progress bar.

Working on getting the window.
Flags: needinfo?(ktucker)
Keywords: qawantedregression
QA Contact: pcheng
Flags: needinfo?(ktucker)
Based on the video, I wouldn't think graphics, and more consider the seek, but let's see what the regression range says.  Anthony, what do you think?
Flags: needinfo?(ajones)
mozilla-inbound regression window:

Last Working Environmental Variables:
Device: Flame
BuildID: 20141110125450
Gaia: e02facadb0bc3fe32227b52b31ca47822f7f4322
Gecko: 3d15fb5da7ab
Version: 36.0a1 (2.2 Master)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

First Broken Environmental Variables:
Device: Flame
BuildID: 20141110133350
Gaia: e02facadb0bc3fe32227b52b31ca47822f7f4322
Gecko: b1c2305de473
Version: 36.0a1 (2.2 Master)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Gaia is the same so it's a Gecko issue.

Gecko pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=3d15fb5da7ab&tochange=b1c2305de473

Caused by the patch for Bug 1082545.

Note that bug 1082545 comment 40 says the patch was taken from another bug that was used for uplifting to v2.0. That's why this bug affects all branches even though patch for 1082545 was landed to 2.1 onwards.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Blake - looks like this one is yours.
Flags: needinfo?(ajones) → needinfo?(bwu)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Assignee

Comment 9

4 years ago
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #8)
> Blake - looks like this one is yours.
Yeah. :) I will check it.
Assignee: nobody → bwu
Flags: needinfo?(bwu)
Assignee

Comment 10

4 years ago
The rootcause of this problem is the rule[1] of deciding to seek to the next key frame or the previous one is not good which only checks if the seekTime > the last decoded frame. So sometimes it causes wrong directions to seek. That's why we see the flickering.   

[1]https://dxr.mozilla.org/mozilla-central/source/dom/media/omx/OmxDecoder.cpp?from=OmxDecoder.cpp&case=true#567

Will change this rule and submit a patch.

Updated

4 years ago
Component: Gaia::Video → Video/Audio
Product: Firefox OS → Core
Assignee

Comment 11

4 years ago
The original seeking decision rule is not robust. When the timestamp of last decoded frame is bigger than the seek time, it will be regarded as a SEEK_PREVIOUS although we do seek forward on UI. It is because that timestamp resulting from the last seek goes to a far keyframe and the second seek time is still smaller than that timestamp of keyframe. And a wrong decision is made. 

Test it on my Flame and it works well.
Assignee

Comment 12

4 years ago
njpark, 
Could you help to verify attachment 8568355 [details] [diff] [review] to see if what you saw is fixed?
Thanks!
Flags: needinfo?(npark)
Reporter

Comment 13

4 years ago
(In reply to Blake Wu [:bwu][:blakewu] from comment #12)
> njpark, 
> Could you help to verify attachment 8568355 [details] [diff] [review] to see
> if what you saw is fixed?
> Thanks!

Hi Blake, the image flicker is now gone, but when I try it on Gallery app using the video taken from the phone, the Gallery app crashes while seeking back and forth.  the crash signature is:
https://crash-stats.mozilla.com/report/index/9ac02c02-bdde-4aac-810f-1d2b32150224
Flags: needinfo?(npark)
Reporter

Comment 14

4 years ago
If the crash is not caused by your code, let me know and i'll file a new bug once it hits the nightly build.
Assignee

Comment 15

4 years ago
(In reply to No-Jun Park [:njpark] from comment #13)
> (In reply to Blake Wu [:bwu][:blakewu] from comment #12)
> > njpark, 
> > Could you help to verify attachment 8568355 [details] [diff] [review] to see
> > if what you saw is fixed?
> > Thanks!
> 
> Hi Blake, the image flicker is now gone, but when I try it on Gallery app
> using the video taken from the phone, the Gallery app crashes while seeking
> back and forth.  the crash signature is:
> https://crash-stats.mozilla.com/report/index/9ac02c02-bdde-4aac-810f-
> 1d2b32150224
Thanks for your help. 
After checking stack, that crash looks the same in bug 1099356 comment 11. I think it is not caused by this patch.
Assignee

Comment 16

4 years ago
Comment on attachment 8568355 [details] [diff] [review]
Bug-1133955-Record-the-last-seek-time-to-decide-to-s.patch

RootCause is described as comment 11.
Solution is to record the last seektime to do a comparison with the current seek and decided to seek to next keyframe or previous one.
Attachment #8568355 - Flags: review?(sotaro.ikeda.g)
Attachment #8568355 - Flags: review?(sotaro.ikeda.g) → review+
Assignee

Comment 17

4 years ago
Carry r+ from sotaro.
Attachment #8568355 - Attachment is obsolete: true
Attachment #8569578 - Flags: review+
Assignee

Comment 19

4 years ago
(In reply to Blake Wu [:bwu][:blakewu] from comment #18)
> Try server:
> https://treeherder.mozilla.org/#/jobs?repo=try&revision=bbfa8f0ed9d0
Test results look good.
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/7cea68e38d3f
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
Assignee

Comment 22

4 years ago
Comment on attachment 8569578 [details] [diff] [review]
Bug-1133955-Record-the-last-seek-time-to-decide-to-seek-hg.patch

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 #): 
Bug 1082545
User impact if declined:
while seeking video via moving the progress bar, image may flicker 
Testing completed: 
https://treeherder.mozilla.org/#/jobs?repo=try&revision=72eea3011586
Risk to taking this patch (and alternatives if risky):
Low. 
String or UUID changes made by this patch:
NA
Attachment #8569578 - Flags: approval-mozilla-b2g37?
Attachment #8569578 - Flags: approval-mozilla-b2g37? → approval-mozilla-b2g37+
This issue has failed verification on Flame 3.0 and 2.2. See bug 1147241 for new bug behavior.

Device: Flame 3.0 (319MB full flash KK)
BuildID: 20150324010202
Gaia: efebbafd12fc42ddcd378948b683a51106517660
Gecko: 840cfd5bc971
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 39.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0

Device: Flame 2.2 (319MB full flash KK)
BuildID: 20150324002504
Gaia: 014d38f7ad3912b8b33cb08ce7535a5dc5aced59
Gecko: 7a9f2a248e57
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 37.0 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?][failed-verification]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?][failed-verification] → [QAnalyst-Triage+][failed-verification]
Flags: needinfo?(ktucker)
You need to log in before you can comment on or make changes to this bug.