Closed Bug 984834 Opened 7 years ago Closed 7 years ago

Video playback glitch observed when device resumes after suspend

Categories

(Core :: Audio/Video, defect, P2)

30 Branch
ARM
Gonk (Firefox OS)
defect

Tracking

()

RESOLVED FIXED
1.4 S4 (28mar)
blocking-b2g 1.4+
Tracking Status
b2g-v1.4 --- fixed
b2g-v2.0 --- fixed

People

(Reporter: poojas, Assigned: chens)

References

()

Details

(Whiteboard: [caf priority: p2][CR 628056])

Attachments

(6 files)

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?
Flags: needinfo?(poojas)
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
Flags: needinfo?(cku)
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.
Flags: needinfo?(echou)
Blake, please take a first look. Thank you.
Assignee: nobody → bwu
blocking-b2g: --- → 1.4+
gaia: dfae3744607257206e37483dc3f431108baf70fb
gecko: cbfe2d6c71daae6ac97b4681c432e950acf16ac6
Device: QRD8x28
Flags: needinfo?(poojas)
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.
Flags: needinfo?(poojas)
Summary: H.263+WVGA.3gp video playback glitch observed when device resumes after suspend → Video playback glitch observed when device resumes after suspend
Attached video demo.mp4
Attach another .mp4 file.
Attached image no-render.png
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.
Flags: needinfo?(pchang)
Eric,

Do we need anything from QC? Can we have a patch for fix by 3/27?
Flags: needinfo?(echou)
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?
Flags: needinfo?(johu)
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.
Flags: needinfo?(johu)
(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.
Flags: needinfo?(pchang)
(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
Flags: needinfo?(poojas)
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
Flags: needinfo?(echou)
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
Status: NEW → RESOLVED
Closed: 7 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+
Target Milestone: --- → 1.4 S4 (28mar)
v1.4: 3f582170789214e0c1d6524a323233523c50e524
Thanks John for the fix. Video playback is working fine now.
Whiteboard: [CR 628056] → [caf priority: p2][CR 628056]
Flags: in-moztrap?(bzumwalt)
New test case needs to be written to address bug.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Test case has been written and added to moztrap:

https://moztrap.mozilla.org/manage/case/14280/
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Flags: in-moztrap?(bzumwalt)
Flags: in-moztrap+
You need to log in before you can comment on or make changes to this bug.