993753 - [B2G][Video] Videos will not play again after first playthrough

Status: RESOLVED FIXED

(Core :: Audio/Video, defect)

Description

[Brogan Zumwalt [Inactive]]

Attachment: Logcat

Description:
After watching a video once in Video app, pressing play to watch a second time results in a static image with audio only. Video is not replayed. Videos in library are all 3GP files and were recorded with device.

Repro Steps:
1) Updated Buri to BuildID: 20140408040204
2) Launch Video app
3) Select video and watch
4) Once video playback is complete, press play button to watch again

Actual:
Static image with audio is shown on second playthrough in video app.

Expected:
User can watch and rewatch videos with no issues encountered.

Environmental Variables:
Device: Buri Master M-C Mozilla RIL
BuildID: 20140408040204
Gaia: 1958454595b1fa0e061f0652ae965629993f5708
Gecko: 8883360b1edb
Version: 31.0a1
Firmware Version: v1.2-device.cfg

Notes:
Repro frequency: 3/3, 100%
See attached: Youtube video clip & logcat

Comment 1

[Brogan Zumwalt [Inactive]]

Youtube link: http://youtu.be/fj3ux-NdS1k

Note: If video app is closed via card view, user can watch video again by reopening video app. After watching it again however, this issue reoccurs.

Comment 2

[Jason Smith [:jsmith]]

Can we confirm this isn't happening on 1.4?

Comment 3

[Josh Schmitt [Joshs]]

(In reply to Jason Smith [:jsmith] from comment #2)
> Can we confirm this isn't happening on 1.4?

Following the repro steps, I was unable to repro on the latest 1.4 Buri build

1.4 Environmental Variables:
Device: Buri 1.4 MOZ
BuildID: 20140409000202
Gaia: 26983f356ecb1bcf30e862d334b5de790071803e
Gecko: e450e07e3a58
Version: 30.0a2
Firmware Version: v1.2-device.cfg

Comment 4

[Harvey]

Mozilla Inbound Regression Window:

Last Working
Device: Buri 1.5 MOZ
BuildID: 20140331115051
Gaia: 26839cb46f856d610b192f5655a8c38a6bfe0829
Gecko: abebf45061a9
Version: 31.0a1
Firmware Version: v1.2-device.cfg

First Broken
Device: Buri 1.5 MOZ
BuildID: 20140331232935
Gaia: 874fe42b82e8d819d592690e74db91c07179e68c
Gecko: ba93b2f34a3f
Version: 31.0a1
Firmware Version: v1.2-device.cfg

First Broken Gaia Last Working Gecko: Issue Doesn't reproduce
Gaia: 874fe42b82e8d819d592690e74db91c07179e68c
Gecko: abebf45061a9

Last Working Gaia First Broken Gecko: Issue Does reproduce
Gaia: 26839cb46f856d610b192f5655a8c38a6bfe0829
Gecko: ba93b2f34a3f

Gecko Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=abebf45061a9&tochange=ba93b2f34a3f

Comment 5

[Jason Smith [:jsmith]]

The window here is incorrect. There should be only a couple changesets present in the push log if this was done correctly.

Comment 6

[Harvey]

Revised Mozilla Inbound Regression:

Last Working
Device: Buri 1.5 MOZ
BuildID: 20140331200633
Gaia: eee8caa81a368f0feace718201ed15a423812c18
Gecko: d313210d2619
Version: 31.0a1
Firmware Version: v1.2-device.cfg

First Broken 
Device: Buri 1.5 MOZ
BuildID: 20140331204432
Gaia: eee8caa81a368f0feace718201ed15a423812c18
Gecko: 35180f110e44
Version: 31.0a1
Firmware Version: v1.2-device.cfg

Gaia did not change between builds so this seems to be a Gecko issue

Gecko Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=d313210d2619&tochange=35180f110e44

Comment 7

[Jason Smith [:jsmith]]

Either bug 778077 or bug 631058 broke this.

Chris - Do you know?

Comment 8

[Chris Pearce [:cpearce (Not reading bugmail)]]

I can reproduce this bug on Otoro with B2G Master with m-c tip, but B2G Master with Gecko revisions 9c0afbe41ce8 (bug 778077) and 35180f110e44 (bug 631058) do not reproduce this bug. Are you sure that regression window is correct?

Comment 9

[Chris Pearce [:cpearce (Not reading bugmail)]]

I'm wrong. This *is* a regression from bug 631058, this bug does not occur with only bug 778077 landed.

Comment 10

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: Patch

The problem is that we're setting the decoder to idle once we pause in order to seek, and then when we decode in DecodeToTarget() the decode fails.

So don't set the reader idle when we're seeking. And add assertions in debug builds to ensure we don't break this again.

Comment 11

[Chris Pearce [:cpearce (Not reading bugmail)]]

Landed for Gecko 31:
https://hg.mozilla.org/integration/mozilla-inbound/rev/6cc06a35f253

Thanks for catching/reporting this guys.

Comment 12

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/6cc06a35f253

Comment 13

[JW Wang [:jwwang] [:jw_wang]]

(In reply to Chris Pearce (:cpearce) from comment #10)
> Created attachment 8406569 [details] [diff] [review]
> Patch
> 
> The problem is that we're setting the decoder to idle once we pause in order
> to seek, and then when we decode in DecodeToTarget() the decode fails.
> 
> So don't set the reader idle when we're seeking. And add assertions in debug
> builds to ensure we don't break this again.

MediaDecoderStateMachine::DecodeSeek calls EnsureActive before calling mReader->Seek or mReader->DecodeToTarget to ensure the reader is active. It looks like EnsureActive didn't work for Bug 1000841.