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
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?
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?
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.
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?
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?]
Blake - looks like this one is yours.
Flags: needinfo?(ajones) → needinfo?(bwu)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
(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
The rootcause of this problem is the rule 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. 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.
Component: Gaia::Video → Video/Audio
Product: Firefox OS → Core
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.
njpark, Could you help to verify attachment 8568355 [details] [diff] [review] to see if what you saw is fixed? Thanks!
(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
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.
(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.
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+
Carry r+ from sotaro.
(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.
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]
QA Whiteboard: [QAnalyst-Triage?][failed-verification] → [QAnalyst-Triage+][failed-verification]
You need to log in before you can comment on or make changes to this bug.