984834 - Video playback glitch observed when device resumes after suspend

Status: RESOLVED FIXED

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

Description

[Pooja]

Attachment: H.263+WVGA video test clip

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

Comment 1

[Pooja]

Attachment: Glitch observed in H.263+WVGA playback after device resume

Comment 2

[Pooja]

Oops. comment 1 shows wrong links for attachments
Test Clip - attachment 8392812 [details]
Recorded video - attachment 8392813 [details]

Comment 3

[Preeti Raghunath(:Preeti)]

Please provide build ID?

Comment 4

[Hema Koka [:hema]]

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

Comment 5

[u459114]

Hi Eric,
Looks like it's a playback issue, please checl

Comment 6

[Eric Chou [:ericchou] [:echou]]

(In reply to Preeti Raghunath(:Preeti) from comment #3)
> Please provide build ID?

Please provide device model as well. Thanks.

Comment 7

[Eric Chou [:ericchou] [:echou]]

Blake, please take a first look. Thank you.

Comment 8

[Inder]

gaia: dfae3744607257206e37483dc3f431108baf70fb
gecko: cbfe2d6c71daae6ac97b4681c432e950acf16ac6
Device: QRD8x28

Comment 9

[Blake Wu [:bwu][:blakewu]]

I use flame with v1.4 and can see this problem with other videos as well.

Comment 10

[Blake Wu [:bwu][:blakewu]]

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.

Comment 11

[Blake Wu [:bwu][:blakewu]]

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.

Comment 12

[Blake Wu [:bwu][:blakewu]]

Attachment: demo.mp4

Attach another .mp4 file.

Comment 13

[Blake Wu [:bwu][:blakewu]]

Attachment: render-once.png

Comment 14

[Blake Wu [:bwu][:blakewu]]

Attachment: no-render.png

Comment 15

[Blake Wu [:bwu][:blakewu]]

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.

Comment 16

[Preeti Raghunath(:Preeti)]

Eric,

Do we need anything from QC? Can we have a patch for fix by 3/27?

Comment 17

[Blake Wu [:bwu][:blakewu]]

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?

Comment 18

[John Hu [:johnhu][: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.

Comment 19

[Sherman Chen [:chens] (inactive)]

Attachment: Gaia Workaround Patch

Comment 20

[Peter Chang[:pchang]]

(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.

Comment 21

[Pooja]

(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

Comment 22

[Blake Wu [:bwu][:blakewu]]

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.

Comment 23

[Blake Wu [:bwu][:blakewu]]

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 24

[Sherman Chen [:chens] (inactive)]

Comment on attachment 8396131 [details] [review]
Gaia Workaround Patch

Request for gaia workaround patch review

Comment 25

[Sherman Chen [:chens] (inactive)]

Hi John, 

Providing Travis status for your reference,  
https://travis-ci.org/mozilla-b2g/gaia/builds/21495135

Comment 26

[John Hu [:johnhu][:johu][:醬糊小弟]]

Thanks chens,

Travis is all green.

Merged to master:
https://github.com/mozilla-b2g/gaia/commit/1e1086c3a3697f0684b03467c520d6f6f2a8c44b

Comment 27

[John Hu [:johnhu][:johu][:醬糊小弟]]

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.

Comment 28

[Ryan VanderMeulen [:RyanVM]]

v1.4: 3f582170789214e0c1d6524a323233523c50e524

Comment 29

[Pooja]

Thanks John for the fix. Video playback is working fine now.

Comment 30

[Brogan Zumwalt [Inactive]]

New test case needs to be written to address bug.

Comment 31

[KTucker [:KTucker][Inactive 3/4/2016]]

Test case has been written and added to moztrap:

https://moztrap.mozilla.org/manage/case/14280/