1112519 - [Flame][Video]The message "Cannot play video: Another app is currently using the video player" pops up after user drag progess bar to end and then back to beginning twice and tap to play.

Status: VERIFIED FIXED

(Core :: Audio/Video, defect)

Description

[Lancy(Leave from Mozilla)]

[1.Description]:
[Flame][v2.1][Video]Play a video and drag progress bar to the end and then drag back to beginning for twice. Then play the video again,  a message "Cannot play video: Another app is currently using the video player" will pop up.
Attach logcat:logcat.txt.
Occurrence time:11:03.

[2.Testing Steps]: 
Premise:There are some videos in SD card.

1.Launch Video.
2.Tap one video to play.
3.Drag progress bar to the end and drag back to beginning twice.
4.Tap to play the video.

[3.Expected Result]: 
4.The video should be played normally.

[4.Actual Result]: 
4.A message  "Cannot play video: Another app is currently using the video player" will pops up.

[5.Reproduction build]: 
Gaia-Rev        79286eafe67707d1330966c1b1413b2d0de595d9
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/222a62b532db
Build-ID        20141216001202
Version         34.0

[6.Reproduction Frequency]: 
occasionally Recurrence,4/10
TCID: Free Test

Comment 1

[Lancy(Leave from Mozilla)]

Attachment: logcat.txt

Comment 2

[Lancy(Leave from Mozilla)]

Attachment: Video.MP4

Comment 3

[Lancy(Leave from Mozilla)]

Attachment: Verify1_1112549_logcat.txt

Hi Hubert,
This bug can be repro on Flame 2.1 & 2.2,
Could you help with this bug?
Thank you.

See the attachments: Verify1_1112549_logcat.txt & Verify1_1112519_video.MP4
Occurrence time:01:14
Occurrence rate:4/10

Flame 2.1 version:
Gaia-Rev        73be51f998031f06db0cd660c0e388fa621c9f4c
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/05dd053f1d90
Build-ID        20150104001209
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150104.034656
FW-Date         Sun Jan  4 03:47:06 EST 2015
Bootloader      L1TC000118D0

Flame 2.2 version:
Gaia-Rev        c2bf20d23851d5fda9f8f0ef0267db5f49152376
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/55f3224d7513
Build-ID        20150104010206
Version         37.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150104.043402
FW-Date         Sun Jan  4 04:34:12 EST 2015
Bootloader      L1TC000118D0

Comment 4

[Lancy(Leave from Mozilla)]

Attachment: Verify1_1112519_video.MP4

Comment 5

[Lancy(Leave from Mozilla)]

Attachment: Verify2_1112519_logcat.txt

Hi Eric,
This bug can be repro on Flame 2.1 & 2.2 latest build,
Could you help with this bug?
Thank you.

See the attachments: Verify2_1112519_logcat.txt & Verify2_1112519_video.mp4 & test video.zip.
Occurrence time:18:44
Occurrence rate:10/10

Flame 2.1 build:
Gaia-Rev        6957ac8a322234ec99c8abb7cc18dc6a2e0176db
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/6600eba54256
Build-ID        20150113161204
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150113.192836
FW-Date         Tue Jan 13 19:28:47 EST 2015
Bootloader      L1TC000118D0

Flame 2.2 build:
Gaia-Rev        7c5b27cad370db377b18a742d3f3fdb0070e899f
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/748b20315f75
Build-ID        20150113162504
Version         37.0a2
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150113.194114
FW-Date         Tue Jan 13 19:41:25 EST 2015
Bootloader      L1TC000118D0

Comment 6

[Lancy(Leave from Mozilla)]

Attachment: Verify2_1112519_video.MP4

Comment 7

[Lancy(Leave from Mozilla)]

Attachment: test video.part1.rar

Comment 8

[Lancy(Leave from Mozilla)]

Attachment: test video.part2.rar

Comment 9

[Eric Chang [:ericcc] [:echang]]

* Legacy bug, edge case.
* Error page pops up, no button to dismiss, but entering task switcher and going back resolves this.
* Sugguest to backlog this.
ni David for comment.

Comment 10

[David Flanagan [:djf]]

Russ: would you take this bug to investigate and fix, please?  (Let me know if you're tied up with other bugs)  

My first guess was that we were calling ensureVideoLoads() on the rewound video and were failing because the metadata was already loaded, so we were never getting the event. But now I think it is more likely that the double rewind is making us call ensureVideoPlays() twice without a cancelEnsureVideoPlays() between them. That would mean there would be two timeouts, and only one of those timeouts would be cancelled when playback starts.

If that is what is going on, then we could fix it, I think, by calling cancelEnsureVideoPlays() as the first line of ensureVideoPlays(). That would mean we'd have only one timeout running at a time.

Comment 11

[Russ Nicoletti [:russn]]

After investigating, ensureVideoPlays is not getting called twice without a cancelEnsureVideoPlays call in between. cancleEnsureVideoPlays is called when the slider is dragged to the end of the video. ensureVideoPlays is only called when the play button is pressed, which is only once in this scenario. 

In any event, this problem is happening because the video app is not getting the 'timeupdate' event when the 'play' button is pressed. From my investigation, what sometimes happens is the video does not get seeked in response to dragging the slider and the next time 'play' is pressed the 'timeupdate' event will not be sent. Regardless of whether there is an issue seeking, this issue occurs because in some cases there is no 'timeupdate' event within 1500ms. When I increased the timeout to 3500ms, still I was able to reproduce the lack of 'timeupdate' event. When it is sent, it is within ~200ms. When it is not sent, it seems it will never be sent.

Also, it appears the issue is related to certain videos. I was not able to reproduce with videos I recorded on my flame but I was able to reproduce with the 'lonely' video (attached to this bug) and with 'meet-the-cubs'.

Sotaro, is this something you can investigate?

Comment 12

[Sotaro Ikeda [:sotaro]]

(In reply to Russ Nicoletti [:russn] from comment #11)
> Sotaro, is this something you can investigate?

Yes, I can investigate.

Comment 13

[Sotaro Ikeda [:sotaro]]

I confirmed the problem happened on v2.2 flame. I am going to investigate about it.

Comment 14

[Sotaro Ikeda [:sotaro]]

When the problem happens, MediaDecoderStateMachine holded too much video frame and OMXCodec seems to became out of output port buffer condition.

Comment 15

[Sotaro Ikeda [:sotaro]]

"No time change seek" increase VideoQueue() size. When it happens, MediaDecoderStateMachine::DecodeSeek() complete seek. But it caused to trigger additional video decoding by mDropVideoUntilNextDiscontinuity flag. The flag is set in the DecodeSeek().

https://dxr.mozilla.org/mozilla-central/source/dom/media/MediaDecoderStateMachine.cpp#2506

If several consective "No time change seek" happen, each seek increase VideoQueue() size. And at last, it cause out of output port video frame at OMXCodec.

Comment 16

[Sotaro Ikeda [:sotaro]]

Attachment: patch - Clear mDropVideoUntilNextDiscontinuity when we do not seek

By applying the patch, the problem was fixed on my v2.2 flame.

Comment 17

[Sotaro Ikeda [:sotaro]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=b64c157273ff
https://tbpl.mozilla.org/?tree=Try&rev=b64c157273ff

Comment 18

[Sotaro Ikeda [:sotaro]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/e1d579c05f56

Comment 19

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/e1d579c05f56

Comment 20

[Sotaro Ikeda [:sotaro]]

[Blocking Requested - why for this release]: From comment 1, the problem happens on b2g v2.1. If it happens, video playback does not resume until video is reloaded.

Comment 21

[Ralph Giles (:rillian)]

This seemingly small change causes a crash in a MediaRecorder test file, dom/media/test/test_bug1113600.html, when I uplift to Aurora. I can't reproduce locally, but do get a leak on that test.

Steven, does this sound familiar to to you or anyone on your team? This is blocking a lot of MSE changes we need to uplift to gecko 37.

Comment 22

[Ralph Giles (:rillian)]

Can you think of what's causing the orange on 37, Sotaro?

Comment 23

[StevenLee[:slee]]

Hi rillian,

Can you provide more information about the crash? 
1. The patches have you updated
2. It happens on what platforms
Then we could have more clues for the problem. Thanks.

Comment 24

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

Include Blake.

Sotaro is at Taipei office as well as Blake. They can work together to figure this out.

Comment 25

[Sotaro Ikeda [:sotaro]]

(In reply to Ralph Giles (:rillian) from comment #21)
> This seemingly small change causes a crash in a MediaRecorder test file,
> dom/media/test/test_bug1113600.html, when I uplift to Aurora. I can't
> reproduce locally, but do get a leak on that test.
> 
> Steven, does this sound familiar to to you or anyone on your team? This is
> blocking a lot of MSE changes we need to uplift to gecko 37.

Ralph, can you provide a link to the test failure?

I did the following for aurora branch, but I did not see the /test/test_bug1113600.html failure.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=959378b080c2
 https://tbpl.mozilla.org/?tree=Try&rev=959378b080c2

Comment 26

[Ralph Giles (:rillian)]

Interesting. Maybe it's fixed itself? An example of the failure I saw:

  https://treeherder.mozilla.org/#/jobs?repo=try&revision=1793a59b5940

Comment 27

[Ralph Giles (:rillian)]

Unfortunately, I can still reproduce:

 https://treeherder.mozilla.org/#/jobs?repo=try&revision=f072a62c23ff

Comment 28

[Sotaro Ikeda [:sotaro]]

(In reply to Ralph Giles (:rillian) from comment #27)
> Unfortunately, I can still reproduce:
> 
>  https://treeherder.mozilla.org/#/jobs?repo=try&revision=f072a62c23ff

Ralph, in your link, you seems always add patches of bug 1112519 and bug 1128411. Isn't it caused by bug 1128411? The followings tryserver result seems to say, bug  1128411 fix causes the test failure.


https://treeherder.mozilla.org/#/jobs?repo=try&revision=0527fc73d163

https://treeherder.mozilla.org/#/jobs?repo=try&revision=030a49f0899e

Comment 29

[Ralph Giles (:rillian)]

Ah, you are correct. Thank you, Sotaro.

Comment 30

[Ralph Giles (:rillian)]

Comment on attachment 8558548 [details] [diff] [review]
patch - Clear mDropVideoUntilNextDiscontinuity when we do not seek

Approval Request Comment
[Feature/regressing bug #]: MSE
[User impact if declined]: Less consistent testing, harder to backport later changes.
[Describe test coverage new/current, TreeHerder]: Landed on m-c. Aurora push green on try.
[Risks and why]: Risk is low. This is an isolated and straightforward change.
[String/UUID change made/needed]: None.

Comment 31

[Sotaro Ikeda [:sotaro]]

(In reply to Ralph Giles (:rillian) from comment #29)
> Ah, you are correct. Thank you, Sotaro.

no problem :-)

Comment 32

[Lawrence Mandel [:lmandel] (use needinfo)]

Tracking MSE related bug.

Comment 33

[Lawrence Mandel [:lmandel] (use needinfo)]

Comment on attachment 8558548 [details] [diff] [review]
patch - Clear mDropVideoUntilNextDiscontinuity when we do not seek

Taking this MSE change in order to get better testing and reduce issues with uplifts as this feature is now targeting 37. Aurora+

Comment 34

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/d28a934ef786

Comment 35

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/d28a934ef786

Please nominate the patch for b2g34 if you want it to land on v2.1 as well.

Comment 36

[Sotaro Ikeda [:sotaro]]

Attachment: patch for b2g v2.1 - Clear mDropVideoUntilNextDiscontinuity when we do not seek

Comment 37

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Can you please nom for b2g34?  (I think we need to also understand the risks/areas to test)

Comment 38

[Sotaro Ikeda [:sotaro]]

Comment on attachment 8558548 [details] [diff] [review]
patch - Clear mDropVideoUntilNextDiscontinuity when we do not seek

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 979104
User impact if declined:  If it happens, video playback does not resume until video is reloaded.
Testing completed: locally tested.
Risk to taking this patch (and alternatives if risky): low risk.
String or UUID changes made by this patch: none

Comment 39

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/b9f62a3087b2

Comment 40

[Sue]

Attachment: verify_video.MP4

This issue has been verified successfully on Flame 2.1/2.2/3.0, drag progress bar to the end and drag back to beginning twice and then tap to play the video, the video can be play normally.
See attachment:verify_video.MP4
Rate:0/5

Flame 2.1 build:
Build ID               20150226161203
Gaia Revision          5d3479fdd438412adee4452720856b6b771fe5cd
Gaia Date              2015-02-25 18:20:09
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/0390c73a827b
Gecko Version          34.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150226.194129
Firmware Date          Thu Feb 26 19:41:40 EST 2015
Bootloader             L1TC000118D0

Flame 2.2 build:
Build ID               20150226162510
Gaia Revision          eb6a5ac9081d3962198e0f4520b0743d716d7a27
Gaia Date              2015-02-26 17:25:22
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/1be266320634
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150226.195624
Firmware Date          Thu Feb 26 19:56:35 EST 2015
Bootloader             L1TC000118D0

Flame 3.0 build:
Build ID               20150226010233
Gaia Revision          7894b929f1b0394f3c997f72a6482bc7813e758d
Gaia Date              2015-02-25 20:50:05
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/dd6353d61993
Gecko Version          39.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150226.043500
Firmware Date          Thu Feb 26 04:35:10 EST 2015
Bootloader             L1TC000118D0

Comment 41

[Sue]

Leaving verifyme for verifying firefox37 and firefox38.

Comment 42

[Sxean Lee-David [:sxean]]

No Repro per build listed below when following the repro steps.  

Environmental Variables:
Device: Aries 2.5
BuildID: 20150923113746
Gaia: aad942e6960cdd6b2d09900b157b16f4ddb9423c
Gecko: abe43c30d78d7546ed7c622c5cf62d265709cdfd
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 44.0a1 (2.5) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0