Closed Bug 984834 Opened 9 years ago Closed 9 years ago
Video playback glitch observed when device resumes after suspend
56 bytes, text/plain
78 bytes, text/plain
3.08 MB, video/mp4
30.34 KB, image/png
29.61 KB, image/png
46 bytes, text/x-github-pull-request
|Details | Review|
Steps to reproduce: 1. Copy any H2.63 video clip (or attachment 1 [details] [diff] [review]) to sdcard 2. Play that clip from video app 3. Suspend device by pressing power button 4. Resume device. Expected behavior: video playback should be in paused state Actual behavior: Glitch is observed in video playback after resume and then it goes to paused state. Please take a look of attachment 2 [details] [diff] [review], recorded video for this scenario
Oops. comment 1 shows wrong links for attachments Test Clip - attachment 8392812 [details] Recorded video - attachment 8392813 [details]
Whiteboard: [CR 628056]
Please provide build ID?
CJ, Can someone in your team help investigate this issue (i don't have anyone right now on media apps who can take this up) thanks! hema
Hi Eric, Looks like it's a playback issue, please checl
Flags: needinfo?(cku) → needinfo?(echou)
(In reply to Preeti Raghunath(:Preeti) from comment #3) > Please provide build ID? Please provide device model as well. Thanks.
Blake, please take a first look. Thank you.
Assignee: nobody → bwu
gaia: dfae3744607257206e37483dc3f431108baf70fb gecko: cbfe2d6c71daae6ac97b4681c432e950acf16ac6 Device: QRD8x28
Component: Gaia::Video → Video/Audio
Product: Firefox OS → Core
Version: unspecified → 30 Branch
I use flame with v1.4 and can see this problem with other videos as well.
It looks when resuming, video tag is loaded and at this time (DecodeMetaData state)the first video frame will be decoded and displayed. Afterwards, it seeks (DecodeSeek) to the previous stop time and then the frame at that time will be displayed. That's why the glitch comes from.But this cannot be found in V1.3. After discussing with John Hu(:johu), there is no APP behavior change between V1.3 and V1.4. I am checking the difference in gecko.
Hi Pooja, Could you try to use some other video formats, like .mp4 or .3gp? I think this problem doesn't only happen on H.263+WVGA, so I changed the title of this bug. At my side, I can repro this problem with .mp4 and .3gp.
Summary: H.263+WVGA.3gp video playback glitch observed when device resumes after suspend → Video playback glitch observed when device resumes after suspend
Attach another .mp4 file.
Hi Peter, Per discussing offline, in V1.3 it looks like the first rendered frame is always black screen. Could you check it? For the attachment 8395573 [details], no matter I render the first frame (video tag loaded) of video or the previously-stopped frame (seek frame), it shows black screen if I render one of them only once. For the attachment 8395574 [details], for your reference it is the case that no frame is rendered.
Eric, Do we need anything from QC? Can we have a patch for fix by 3/27?
One possible and quick solution/workaround is to hide the first frame in this resuming case, even though I think it would be better to find the root cause and then have a long term solution. As discussing with :johu, a quick solution/workaround may be doable in the APP layer. Hi John, Could you help have a try to hide the first frame from APP side if the change is small?
Sure, we are under the way. Please stay tuned. We will provide a workaround patch for this ASAP. But we may need to someone make sure this workaround should be landed.
(In reply to John Hu [:johnhu][:johu][:醬糊小弟] from comment #18) > Sure, we are under the way. Please stay tuned. We will provide a workaround > patch for this ASAP. But we may need to someone make sure this workaround > should be landed. It's good to have gaia quick solution here. I will try to check the gecko behavior about this black frame on gecko 1.3.
(In reply to Blake Wu [:bwu] from comment #11) > Hi Pooja, > > Could you try to use some other video formats, like .mp4 or .3gp? > I think this problem doesn't only happen on H.263+WVGA, so I changed the > title of this bug. > At my side, I can repro this problem with .mp4 and .3gp. Yes. This happens with other formats as well. In this specific video we shared, now I realize background is same from starting to end. So moving from first frame to seeked frame looks like it plays and then pauses, looked little bad than other videos
Hi John and Sherman, Thanks for your great support. Per discussing offline, your patch is simple and good to be the solution. Need your help to land this solution if there is no other concerns. For the further investigation of gecko behavior as comment 18, let's create a follow-up bug to continue to check. Thanks.
Assignee: bwu → shchen
For your information, the follow-up bug is created in bug 987558. Hi Peter, please update your investigation in the follow-up bug. Thanks.
Comment on attachment 8396131 [details] [review] Gaia Workaround Patch Request for gaia workaround patch review
Attachment #8396131 - Flags: review?(johu)
Hi John, Providing Travis status for your reference, https://travis-ci.org/mozilla-b2g/gaia/builds/21495135
Thanks chens, Travis is all green. Merged to master: https://github.com/mozilla-b2g/gaia/commit/1e1086c3a3697f0684b03467c520d6f6f2a8c44b
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Comment on attachment 8396131 [details] [review] Gaia Workaround Patch Sorry, I forgot to press submit for this r+. Thanks for this patch. It does hide the player before onseeked fired. Thanks.
Attachment #8396131 - Flags: review?(johu) → review+
Thanks John for the fix. Video playback is working fine now.
New test case needs to be written to address bug.
QA Whiteboard: [QAnalyst-Triage?]
Test case has been written and added to moztrap: https://moztrap.mozilla.org/manage/case/14280/
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
You need to log in before you can comment on or make changes to this bug.