Closed Bug 1029552 Opened 10 years ago Closed 10 years ago

plays only one video on blinkx.com

Categories

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

ARM
Gonk (Firefox OS)
defect

Tracking

()

VERIFIED FIXED
mozilla35
blocking-b2g 2.1+
Tracking Status
firefox33 --- wontfix
firefox34 --- wontfix
firefox35 --- fixed
b2g-v1.4 --- affected
b2g-v2.0 --- affected
b2g-v2.1 --- verified
b2g-v2.2 --- verified

People

(Reporter: hsteen, Assigned: bechen)

References

(Blocks 1 open bug, )

Details

Attachments

(2 files, 1 obsolete file)

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.
See Also: → 888726
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
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
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
not a regression
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
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
(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.
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
Other way to fix the problem is Bug 882993.
(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 =)
See Also: → 936454
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)
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
Oliver, can you request this bug as b2g blocker?
Flags: needinfo?(sotaro.ikeda.g) → needinfo?(oduric)
[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)
blocking-b2g: 2.1? → 2.1+
OS: Other → Gonk (Firefox OS)
Priority: -- → P1
Hardware: Other → ARM
Flags: needinfo?(bbajaj)
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.
Depends on: 882993
Hi Ben,

Can you help this bug?
Thanks.
Flags: needinfo?(bechen)
No longer depends on: 882993
See Also: → 882993
Assignee: nobody → bechen
Flags: needinfo?(bechen)
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?
(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.
Steven, please discuss with Ben to see if anything can be helped for this bug.
Flags: needinfo?(slee)
ni?me for a reminder.
Flags: needinfo?(slee) → needinfo?(kchang)
Flags: needinfo?(slee)
As comment 16, we don't think this bug can be solved before 10/10.
Flags: needinfo?(slee) → needinfo?(bbajaj)
(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?
(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.
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.
Agree. But condisering the blocker and tight schedule, I would prefer a fix that is simple and low-risk.
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+
Blocks: 1081814
r=cpearce
Attachment #8502286 - Attachment is obsolete: true
Attachment #8503898 - Flags: review+
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/9ed77991d70f
Status: NEW → RESOLVED
Closed: 10 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla35
Just verified that this patch works in the master branch.  Are we uplifting it to 2.1 branch?
Benjamin, can you help with the uplift request here? Thanks!
Flags: needinfo?(bbajaj)
Flags: needinfo?(kchang)
Flags: needinfo?(bechen)
Flags: needinfo?(bechen)
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?
Attachment #8505984 - Flags: approval-mozilla-b2g34? → approval-mozilla-b2g34+
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)
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
QA Whiteboard: [QAnalyst-Triage?][lead-review+] → [QAnalyst-Triage+][lead-review+]
Flags: needinfo?(ktucker)
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
QA Whiteboard: [QAnalyst-Triage?][lead-review+] → [QAnalyst-Triage+][lead-review+]
Flags: needinfo?(ktucker)
Blocks: 1079823
You need to log in before you can comment on or make changes to this bug.