Closed
Bug 1112519
Opened 10 years ago
Closed 9 years ago
[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.
Categories
(Core :: Audio/Video, defect)
Tracking
()
People
(Reporter: yulan.zhu, Assigned: sotaro)
Details
Attachments
(11 files)
99.84 KB,
text/plain
|
Details | |
2.52 MB,
video/mp4
|
Details | |
90.53 KB,
text/plain
|
Details | |
1.31 MB,
video/mp4
|
Details | |
96.69 KB,
text/plain
|
Details | |
1.91 MB,
video/mp4
|
Details | |
8.58 MB,
application/x-rar
|
Details | |
8.06 MB,
application/x-rar
|
Details | |
904 bytes,
patch
|
cpearce
:
review+
lmandel
:
approval-mozilla-aurora+
bajaj
:
approval-mozilla-b2g34+
|
Details | Diff | Splinter Review |
893 bytes,
patch
|
Details | Diff | Splinter Review | |
2.32 MB,
video/mp4
|
Details |
[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
Reporter | ||
Comment 1•10 years ago
|
||
Reporter | ||
Comment 2•10 years ago
|
||
Reporter | ||
Updated•9 years ago
|
Reporter | ||
Comment 3•9 years ago
|
||
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
Flags: needinfo?(hlu)
Reporter | ||
Comment 4•9 years ago
|
||
Reporter | ||
Comment 5•9 years ago
|
||
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
Flags: needinfo?(hlu) → needinfo?(echang)
Reporter | ||
Comment 6•9 years ago
|
||
Reporter | ||
Comment 7•9 years ago
|
||
Reporter | ||
Comment 8•9 years ago
|
||
Comment 9•9 years ago
|
||
* 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.
blocking-b2g: --- → 2.2?
QA Whiteboard: [COM=Gaia::Video]
Flags: needinfo?(echang) → needinfo?(dflanagan)
Comment 10•9 years ago
|
||
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.
Flags: needinfo?(dflanagan) → needinfo?(rnicoletti)
Comment 11•9 years ago
|
||
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?
Flags: needinfo?(sotaro.ikeda.g)
Assignee | ||
Comment 12•9 years ago
|
||
(In reply to Russ Nicoletti [:russn] from comment #11) > Sotaro, is this something you can investigate? Yes, I can investigate.
Assignee: nobody → sotaro.ikeda.g
Flags: needinfo?(sotaro.ikeda.g)
Updated•9 years ago
|
Flags: needinfo?(rnicoletti)
Assignee | ||
Comment 13•9 years ago
|
||
I confirmed the problem happened on v2.2 flame. I am going to investigate about it.
Assignee | ||
Comment 14•9 years ago
|
||
When the problem happens, MediaDecoderStateMachine holded too much video frame and OMXCodec seems to became out of output port buffer condition.
Assignee | ||
Comment 15•9 years ago
|
||
"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.
Assignee | ||
Comment 16•9 years ago
|
||
By applying the patch, the problem was fixed on my v2.2 flame.
Assignee | ||
Updated•9 years ago
|
Attachment #8558548 -
Flags: review?(cpearce)
Assignee | ||
Comment 17•9 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=b64c157273ff https://tbpl.mozilla.org/?tree=Try&rev=b64c157273ff
Updated•9 years ago
|
Attachment #8558548 -
Flags: review?(cpearce) → review+
Assignee | ||
Comment 18•9 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/e1d579c05f56
Comment 19•9 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/e1d579c05f56
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•9 years ago
|
Component: Gaia::Video → Video/Audio
Product: Firefox OS → Core
Assignee | ||
Comment 20•9 years ago
|
||
[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.
blocking-b2g: 2.2? → 2.1?
Comment 21•9 years ago
|
||
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.
Flags: needinfo?(slee)
Comment 22•9 years ago
|
||
Can you think of what's causing the orange on 37, Sotaro?
Flags: needinfo?(sotaro.ikeda.g)
Comment 23•9 years ago
|
||
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•9 years ago
|
||
Include Blake. Sotaro is at Taipei office as well as Blake. They can work together to figure this out.
Flags: needinfo?(bwu)
Assignee | ||
Comment 25•9 years ago
|
||
(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
Flags: needinfo?(sotaro.ikeda.g)
Comment 26•9 years ago
|
||
Interesting. Maybe it's fixed itself? An example of the failure I saw: https://treeherder.mozilla.org/#/jobs?repo=try&revision=1793a59b5940
Comment 27•9 years ago
|
||
Unfortunately, I can still reproduce: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f072a62c23ff
Flags: needinfo?(sotaro.ikeda.g)
Assignee | ||
Comment 28•9 years ago
|
||
(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
Flags: needinfo?(sotaro.ikeda.g) → needinfo?(giles)
Comment 29•9 years ago
|
||
Ah, you are correct. Thank you, Sotaro.
Flags: needinfo?(slee)
Flags: needinfo?(giles)
Updated•9 years ago
|
status-firefox36:
--- → wontfix
status-firefox37:
--- → affected
status-firefox38:
--- → fixed
Target Milestone: --- → mozilla38
Comment 30•9 years ago
|
||
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.
Attachment #8558548 -
Flags: approval-mozilla-aurora?
Assignee | ||
Comment 31•9 years ago
|
||
(In reply to Ralph Giles (:rillian) from comment #29) > Ah, you are correct. Thank you, Sotaro. no problem :-)
Updated•9 years ago
|
Flags: needinfo?(bwu)
Comment 32•9 years ago
|
||
Tracking MSE related bug.
tracking-firefox37:
--- → +
tracking-firefox38:
--- → +
Comment 33•9 years ago
|
||
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+
Attachment #8558548 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment 35•9 years ago
|
||
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.
Assignee | ||
Comment 36•9 years ago
|
||
Flags: needinfo?(sotaro.ikeda.g)
blocking-b2g: 2.1? → 2.1+
Can you please nom for b2g34? (I think we need to also understand the risks/areas to test)
Flags: needinfo?(sotaro.ikeda.g)
Assignee | ||
Comment 38•9 years ago
|
||
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
Flags: needinfo?(sotaro.ikeda.g)
Attachment #8558548 -
Flags: approval-mozilla-b2g34?
Updated•9 years ago
|
Attachment #8558548 -
Flags: approval-mozilla-b2g34? → approval-mozilla-b2g34+
Comment 40•9 years ago
|
||
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•9 years ago
|
||
Leaving verifyme for verifying firefox37 and firefox38.
QA Whiteboard: [COM=Gaia::Video] → [COM=Gaia::Video][MGSEI-Triage+]
Updated•9 years ago
|
QA Contact: sleedavid
Comment 42•9 years ago
|
||
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
Flags: needinfo?(jmercado)
QA Contact: sleedavid
Updated•9 years ago
|
Status: RESOLVED → VERIFIED
QA Whiteboard: [COM=Gaia::Video][MGSEI-Triage+] → [COM=Gaia::Video][MGSEI-Triage+][Qanalysts-Triage+]
Flags: needinfo?(jmercado)
Keywords: verifyme
You need to log in
before you can comment on or make changes to this bug.
Description
•