Closed
Bug 1029552
Opened 10 years ago
Closed 10 years ago
plays only one video on blinkx.com
Categories
(Core :: Audio/Video, defect, P1)
Tracking
()
People
(Reporter: hsteen, Assigned: bechen)
References
(Blocks 1 open bug, )
Details
Attachments
(2 files, 1 obsolete file)
(deleted),
patch
|
bechen
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
bajaj
:
approval-mozilla-b2g34+
|
Details | Diff | Splinter Review |
The first video typically plays fine on the Flame (it typically doesn't on Tarako..) but trying to play another video won't work. It takes a reload before you can watch something else.
I've cooked up a small demo here:
http://hallvord.com/temp/moz/bug/blinkx.htm
It just sets innerHTML on an element to create a video player, calls load() and play() to play one video, repeats when the first one ends. Note how you only see the poster of the second. Even if you try starting it manually, it won't actually play.
Reporter | ||
Updated•10 years ago
|
Comment 1•10 years ago
|
||
QA Wanted to see if someone else can confirm on 2.0.
blocking-b2g: --- → backlog
Component: Gaia::Browser → Video/Audio
Keywords: qawanted
Product: Firefox OS → Core
Comment 2•10 years ago
|
||
This issue DOES reproduce on Flame 2.0, Flame 2.1, Flame 1.4, Open C 2.1, Open C 2.0, and Open C 1.4
The video plays on blinkx.com/http://hallvord.com/temp/moz/bug/blinkx.htm on the first try, but if the user plays another video afterwards the video does not play.
Flame 2.0
Environmental Variables:
Device: Flame 2.0
Build ID: 20140627000201
Gaia: 8df02268fcd7e80c5fab8c1ec099772e37f8659d
Gecko: 731a5e8831e6
Version: 32.0a2 (2.0)
Firmware Version: v122
User Agent for Flame 2.0: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Flame 2.1
Environmental Variables:
Device: Flame Master
Build ID: 20140627040205
Gaia: b8f36518696f3191a56e4f33447ee9d6ec820da1
Gecko: 9290d7995f98
Version: 33.0a1 (Master)
Firmware Version: v122
User Agent for Flame 2.0: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Open_C 2.1
Environmental Variables:
Device: Open_C Master
Build ID: 20140627040205
Gaia: b8f36518696f3191a56e4f33447ee9d6ec820da1
Gecko: 9290d7995f98
Version: 33.0a1 (Master)
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent for Flame 2.0: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Open_C 2.0
Environmental Variables:
Device: Open_C 2.0
Build ID: 20140625000201
Gaia: de77f794db22a45f9d575de2c6e266a30a50de3b
Gecko: 79712bd7b60d
Version: 32.0a2 (2.0)
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent for Flame 2.0: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Flame 1.4
Environmental Variables:
Device: Flame 1.4
Build ID: 20140627000201
Gaia: 76e669c6fa387f97bcaaaee5d179ee4a9dcca986
Gecko: d956b3a3e921
Version: 30.0 (1.4)
Firmware Version: v122
User Agent for Flame 2.0: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Open_C 1.4
Environmental Variables:
Device: Open_C 1.4
Build ID: 20140627000201
Gaia: 76e669c6fa387f97bcaaaee5d179ee4a9dcca986
Gecko: d956b3a3e921
Version: 30.0 (1.4)
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent for Flame 2.0: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
____________________________________________________________________________________
This issue does NOT reproduce on Buri 2.1, Buri 2.0, Buri 1.4
When the user plays a video on blinkx.com/http://hallvord.com/temp/moz/bug/blinkx.htm, the video does not load/play because the file is corrupt. There seems to be a resolution issue with the Buri
Buri 2.1
Environmental Variables:
Device: Buri Master
Build ID: 20140627040205
Gaia: b8f36518696f3191a56e4f33447ee9d6ec820da1
Gecko: 9290d7995f98
Version: 33.0a1 (Master) MOZ
Firmware Version: v1.2device.cfg
User Agent for Flame 2.0: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Buri 2.0
Environmental Variables:
Device: Buri 2.0
Build ID: 20140625000201
Gaia: de77f794db22a45f9d575de2c6e266a30a50de3b
Gecko: 79712bd7b60d
Version: 32.0a2 (2.0) MOZ
Firmware Version: v1.2device.cfg
User Agent for Flame 2.0: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Buri 1.4
Environmental Variables:
Device: Buri 1.4
Build ID: 20140627000201
Gaia: 76e669c6fa387f97bcaaaee5d179ee4a9dcca986
Gecko: d956b3a3e921
Version: 30.0 (1.4) MOZ
Firmware Version: v1.2device.cfg
User Agent for Flame 2.0: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Comment 3•10 years ago
|
||
not a regression
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
status-b2g-v1.4:
--- → affected
status-b2g-v2.0:
--- → affected
status-b2g-v2.1:
--- → affected
Flags: needinfo?(jmitchell)
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
Comment 4•10 years ago
|
||
Hi all,
Just did some investigation,
It seems that the 2nd video resource [1] is not found due to the return at [2], so that further A/V decode won't be triggered.
I've tried using Flame's browser to open [1] directly, and browser just kept loading. But the 1st video [3] could be loaded and played correctly.
I'll try to dig deeper.
Hope these information could help.
[1] http://cdn.blinkx.com/stream/b/98/StupidVideos/20140622/1880720341/1880720341_dpmp4hd4_0.mp4
[2] http://dxr.mozilla.org/mozilla-central/source/content/media/omx/mediaresourcemanager/MediaResourceManagerService.cpp#142
[3] http://cdn.blinkx.com/stream/b/98/FoxSports/20140623/1880722827/1880722827_dpmp4hd4_0.mp4
Comment 5•10 years ago
|
||
(In reply to Kilik Kuo [:kilikkuo] from comment #4)
> I've tried using Flame's browser to open [1] directly, and browser just kept
> loading. But the 1st video [3] could be loaded and played correctly.
Sorry, please ignore above statements, these 2 videos can be loaded and played on flame's browser via entering URL on awesome bar.
Comment 6•10 years ago
|
||
Update,
I'm still trying to get more familiar with these OMX related codes. The following corollary might be incorrect, please don't hesitate to make comments :)
The reason why we can't get hardware resource for 2nd video is because we define the maximum number of HW resources available is 1 [1] and the only HW resource was still occupied by the 1st video even it's done playing, so that NAME_NOT_FOUND is returned [2].
(The 1st video element becomes unreachable when the 2nd video element is assigned to |document.getElementById('playwrap').innerHTML|, and the destructor of the 1st video element won't be called until it gets GCed.)
The following is the HTML of the demo website [3].
==========================================================
<body>
<div id="playwrap"></div>
<script>
var videos = ['<video id="v-0" controls="controls" poster="http://cdn.blinkx.com/stream/b/98/StupidVideos/20140622/1880720341/1880720341_img480_0.jpg" src="http://cdn.blinkx.com/stream/b/98/StupidVideos/20140622/1880720341/1880720341_dpmp4hd4_0.mp4">Your browser does not support the video tag.</video>', '<video id="v-1" controls="controls" poster="http://cdn.blinkx.com/stream/b/98/FoxSports/20140623/1880722827/1880722827_img480_0.jpg" src="http://cdn.blinkx.com/stream/b/98/FoxSports/20140623/1880722827/1880722827_dpmp4hd4_0.mp4">Your browser does not support the video tag.</video>'];
function nextVideo(){
if(videos.length===0)return;
document.getElementById('playwrap').innerHTML = videos.pop();
var elm = document.getElementsByTagName('video')[0];
elm.addEventListener('ended', nextVideo, false);
elm.load();
elm.play();
}
nextVideo();
</script>
</body>
==========================================================
It seems that we're not able to dynamically adjust the maximum number of available HW resources by platform yet. Even we are, we are not solving this issue by modifying the number.
My next step is to make a test to see if video resource could be released by calling video.removeAttribute('src') in HTML. But I am still thinking if there's a better way to get this fixed w/o bothering web programmer.
Any suggestions would be greatly appreciated :)
[1] http://dxr.mozilla.org/mozilla-central/source/content/media/omx/mediaresourcemanager/MediaResourceManagerService.h#35
[2] http://dxr.mozilla.org/mozilla-central/source/content/media/omx/mediaresourcemanager/MediaResourceManagerService.cpp#212
[3] http://hallvord.com/temp/moz/bug/blinkx.htm
Comment 7•10 years ago
|
||
Other way to fix the problem is Bug 882993.
Comment 8•10 years ago
|
||
(In reply to Sotaro Ikeda [:sotaro] from comment #7)
> Other way to fix the problem is Bug 882993.
Thanks for the comment, Ikeda.
The solution looks cool ! It widens my horizon =)
Reporter | ||
Updated•10 years ago
|
Reporter | ||
Comment 9•10 years ago
|
||
Ping - is there hope for this bug? We have compatibility problems on several websites that try to play an advertisment first, then a feature video - and only the former plays.
Flags: needinfo?(sotaro.ikeda.g)
Comment 10•10 years ago
|
||
I have a large news partner in Germany m.focus.de who also that problem with the video in their attempt to build their app for FxOS. It would be great if this could move forward.
Thanks, Oliver
Comment 11•10 years ago
|
||
Oliver, can you request this bug as b2g blocker?
Flags: needinfo?(sotaro.ikeda.g) → needinfo?(oduric)
Comment 12•10 years ago
|
||
[Blocking Requested - why for this release]:
Hi Bhavana, Apps Partner Engineering would like to nominate this as a 2.1 blocker. This bug prevents us from bringing important partners like m.focus.de and blinkx into our ecosystem and onto our phones. Given the lead time to get versions of Firefox OS into the field, we really hope this can be addressed in 2.1 so we can bring these partners into Firefox Marketplace as soon as possible.
blocking-b2g: backlog → 2.1?
Flags: needinfo?(oduric) → needinfo?(bbajaj)
Updated•10 years ago
|
blocking-b2g: 2.1? → 2.1+
OS: Other → Gonk (Firefox OS)
Priority: -- → P1
Hardware: Other → ARM
Updated•10 years ago
|
Flags: needinfo?(bbajaj)
Comment 13•10 years ago
|
||
In the past, I implemented to similar capability in Bug 882993. media playback framework becomes very different since then. But how to fix the problem could be same.
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → bechen
Flags: needinfo?(bechen)
Comment 15•10 years ago
|
||
Benjamin, I know you just got this bug on 10/6. But, sadly, it is a 2.1+ bug. Is it possible for you to fix it before 10/10?
Assignee | ||
Comment 16•10 years ago
|
||
(In reply to Ken Chang[:ken] from comment #15)
> Benjamin, I know you just got this bug on 10/6. But, sadly, it is a 2.1+
> bug. Is it possible for you to fix it before 10/10?
No, I don't think I can fix it before 10/10.
Now I'm studying the patch in bug 882993 to understanding what the patch doing. Then, to know why it can fix the bug. Finally to port the patch to current code base and do some tests.
And during the progress, any bugs be found caused by the patch or something wrong will delay the schedule.
Comment 17•10 years ago
|
||
Steven, please discuss with Ben to see if anything can be helped for this bug.
Flags: needinfo?(slee)
Updated•10 years ago
|
Flags: needinfo?(slee)
Comment 19•10 years ago
|
||
As comment 16, we don't think this bug can be solved before 10/10.
Flags: needinfo?(slee) → needinfo?(bbajaj)
Comment 20•10 years ago
|
||
(In reply to Sotaro Ikeda [:sotaro] from comment #13)
> In the past, I implemented to similar capability in Bug 882993. media
> playback framework becomes very different since then. But how to fix the
> problem could be same.
How about doing something more aggressive than pause() in HTMLMediaElement::UnbindFromTree(), like entering dormant state?
Assignee | ||
Comment 21•10 years ago
|
||
(In reply to JW Wang [:jwwang] from comment #20)
> (In reply to Sotaro Ikeda [:sotaro] from comment #13)
> > In the past, I implemented to similar capability in Bug 882993. media
> > playback framework becomes very different since then. But how to fix the
> > problem could be same.
>
> How about doing something more aggressive than pause() in
> HTMLMediaElement::UnbindFromTree(), like entering dormant state?
It's a good idea and the fix is simple.
Just enter/exit dormant state at HTMLMediaElement::UnbindFromTree/HTMLMediaElement::BindToTree.
But the solution only fix
http://hallvord.com/temp/moz/bug/blinkx.htm , only one MediaElement inside like comment 6.
Comment 22•10 years ago
|
||
current gecko has some hw video codec users like webrtc, it might be better to think about how to handle this situation within a design.
Comment 23•10 years ago
|
||
Agree. But condisering the blocker and tight schedule, I would prefer a fix that is simple and low-risk.
Assignee | ||
Comment 24•10 years ago
|
||
Attachment #8502286 -
Flags: review?(cpearce)
Comment 25•10 years ago
|
||
Comment on attachment 8502286 [details] [diff] [review]
bug-1029522.v01.patch
Review of attachment 8502286 [details] [diff] [review]:
-----------------------------------------------------------------
We should add a regression mochitest for this case. Can do in follow up.
Attachment #8502286 -
Flags: review?(cpearce) → review+
Assignee | ||
Comment 26•10 years ago
|
||
r=cpearce
Attachment #8502286 -
Attachment is obsolete: true
Attachment #8503898 -
Flags: review+
Assignee | ||
Updated•10 years ago
|
Keywords: checkin-needed
Comment 27•10 years ago
|
||
Status: NEW → RESOLVED
Closed: 10 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla35
Comment 28•10 years ago
|
||
Just verified that this patch works in the master branch. Are we uplifting it to 2.1 branch?
Comment 29•10 years ago
|
||
Benjamin, can you help with the uplift request here? Thanks!
Flags: needinfo?(bbajaj)
Updated•10 years ago
|
Flags: needinfo?(kchang)
Updated•10 years ago
|
Flags: needinfo?(bechen)
Assignee | ||
Comment 30•10 years ago
|
||
Flags: needinfo?(bechen)
Assignee | ||
Comment 31•10 years ago
|
||
Comment on attachment 8505984 [details] [diff] [review]
bug-1029552.b2g34v2.1.patch
uplift the patch to v2.1.
[Approval Request Comment]
Bug caused by (feature/regressing bug #): 1029552
User impact if declined: bug 1029552 comment 6, under the script, the second video can't be played on B2G device.
Testing completed: manual test on m-c, bug 1029552 comment 28.
Risk to taking this patch (and alternatives if risky): low
String or UUID changes made by this patch: none
Attachment #8505984 -
Flags: approval-mozilla-b2g34?
Updated•10 years ago
|
Attachment #8505984 -
Flags: approval-mozilla-b2g34? → approval-mozilla-b2g34+
Comment 32•10 years ago
|
||
status-b2g-v2.2:
--- → fixed
status-firefox33:
--- → wontfix
status-firefox34:
--- → wontfix
status-firefox35:
--- → fixed
Comment 33•10 years ago
|
||
This issue is verified fixed on Flame 2.2 and 2.1.
Multiple video files can be played consecutively on blinkx.com
Flame 2.2
Device: Flame 2.2 Master (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141021040206
Gaia: 457a54fc3200b80e4f5e1cd3acaa062309230732
Gecko: 29fbfc1b31aa
Gonk: 05aa7b98d3f891b334031dc710d48d0d6b82ec1d
Version: 36.0a1 (2.2 Master)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
Flame 2.1
Device: Flame 2.1 (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141021001201
Gaia: e458f5804c0851eb4e93c9eb143fe044988cecda
Gecko: ee86921a986f
Gonk: 05aa7b98d3f891b334031dc710d48d0d6b82ec1d
Version: 34.0 (2.1)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Status: RESOLVED → VERIFIED
Flags: needinfo?(ktucker)
Comment 34•10 years ago
|
||
This issue still reproduces on Flame 2.0.
Leaving verifyme keyword for 2.0/1.4 uplift.
Flame 2.0
Environmental Variables:
Device: Flame 2.0 (319mb)(Kitkat Base)(Full Flash)
Build ID: 20141021000201
Gaia: 63b56a7a7453726b9e12ad1afe02c68c83c5aeca
Gecko: 40584eecdc75
Version: 32.0 (2.0)
Firmware Version: v188
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage+][lead-review+] → [QAnalyst-Triage?][lead-review+]
Keywords: verifyme
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?][lead-review+] → [QAnalyst-Triage+][lead-review+]
Flags: needinfo?(ktucker)
Comment 35•10 years ago
|
||
Removing verifyme keyword since it's fixed on 2.1 & mater, and not a 2.0 blocker.
QA Whiteboard: [QAnalyst-Triage+][lead-review+] → [QAnalyst-Triage?][lead-review+]
Flags: needinfo?(ktucker)
Keywords: verifyme
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?][lead-review+] → [QAnalyst-Triage+][lead-review+]
Flags: needinfo?(ktucker)
You need to log in
before you can comment on or make changes to this bug.
Description
•