1116412 - [Flame&dolphin][FFOS7715 v2.1][video] Playing video in File manager app, video sometimes pop-up "cannot play " dialog.

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Video, defect, P2)

Description

[[e-mail]]

DEFECT DESCRIPTION:
  From File manager app to open video to play, pop-up “cannot playing“ dialog.

Steps to reproduce:
----------------------------------------------------
Step 1: Download File Manager app from Marketplace.(App Version :- 1.0)
Step 2: Launch File Manager app.
Step 3: Select any video to play.
Step 4: video shows the improper pop up "Another app is currently using the video player" while launching any video in File Manager app.

Additional info:
--------------------------------------
Reproduce rate: 
  dolphin: 4/5
  Flame  : 1/5

Comment 1

[[e-mail]]

I have captured a video about frame.

Please go to the following address to download:
  http://pan.baidu.com/s/1dDcUMmH

Dear Vchen:
  I find the root cause, because the video_loading_checker.js in video app have js code like this:

>ensureVideoLoads: function vpc_ensureVideoLoads(callback) {
>     var self = this;
>     var videoLoadedTimeoutId = setTimeout(showOverlay.bind(null, this), 1000);
>     this.player.addEventListener('loadedmetadata', handleLoadedMetadata);

>ensureVideoPlays: function() {
>      this.playingTimeout = setTimeout(showOverlay.bind(null, this), 1000);
>     this.playingListener = this.cancelEnsureVideoPlays.bind(this);
>     this.player.addEventListener('timeupdate', this.playingListener);

after 1s, the gaia not received the loadedmetadata event,the call showOverlay and pop that gialog.
if we change the
>     var videoLoadedTimeoutId = setTimeout(showOverlay.bind(null, this), 1000); 
to 
>     var videoLoadedTimeoutId = setTimeout(showOverlay.bind(null, this), 2000);
video app do not pop-up this most of time(The extreme case will pop up too), I think this is a workaround, but our leader think it's a better way to send an another event to show the "hardware in using" overlay, not using a timeout, this is to solve the problems in essence.
 
So please help to check this issue.

Thank you!

Comment 2

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Hi Gary -

Not sure if this fall into your category...could you shed some lights or refer us to the correct owner of Video app?

Thanks

Vance

Comment 3

[GaryChen [:GaryChen][:PYChen][:gchen][:陳柏宇]]

Hi all,
   'loadedmetadata' event come from gecko, so it should be gecko performance issue. 
   Of course you can change 1000 to 2000 on below code, but ideally we should investigate why gecko need take more 1s for firing 'loadedmetadata', I think it might make bad user experience.
   >     var videoLoadedTimeoutId = setTimeout(showOverlay.bind(null, this), 1000);  
   >     var videoLoadedTimeoutId = setTimeout(showOverlay.bind(null, this), 2000);

Comment 4

[[e-mail]]

(In reply to GaryChen [:GaryChen][:PYChen][:陳柏宇] from comment #3)
> Hi all,
>    'loadedmetadata' event come from gecko, so it should be gecko performance
> issue. 
>    Of course you can change 1000 to 2000 on below code, but ideally we
> should investigate why gecko need take more 1s for firing 'loadedmetadata',
> I think it might make bad user experience.
>    >     var videoLoadedTimeoutId = setTimeout(showOverlay.bind(null, this),
> 1000);  
>    >     var videoLoadedTimeoutId = setTimeout(showOverlay.bind(null, this),
> 2000);

When change 1000->2000ms, in some extreme case it will pop-up too, so this issue still exit.

Our point of view is that when hardware being use, gecko also firing an another event and send to gaia, then gaia showOverlay, not a timeout about 1000ms, could we achieve this way to better fix this siiue?

Thanks for your help.

Comment 5

[[e-mail]]

Dear Vchen：
According to Comment 1 and Comment 4, please help to find a better way to fix this issue, Because this issue also happened in flame.

Thank you.

Comment 6

[[e-mail]]

Dear David:

According to bug 1079519, we added video_loading_checker.js file in video app, but using the SetTimeout to displaying the codec being use is unreasonable，and cause this issue, so could you help to check this issue?

Thanks a lot.

Comment 7

[David Flanagan [:djf]]

Setting needinfo for Russ because he was involved with video_loading_checker.js and should be aware of this timing issue.

The video_loading_checker.js hack is terrible, but it is the only way we could come up with the resolve bug 1079519. Gecko does not provide us any other way to tell when the video decoding hardware is already in use.

I think that the best we can do here is to just change the timeout value to be longer. 2000ms sounds good to me. In extreme cases the warning will still be incorrectly displayed, but it will go away as soon as the video loads. In the case of bug 1079519 when the warning does need to be displayed we don't want to make the delay too long before the user sees the message.

Comment 8

[Russ Nicoletti [:russn]]

First, I'd like to reiterate David's comment about the video_loading_checker being an undesirable solution to the problem of contention for the video hardware. It's undesirable but the best available solution.

For reference, there are two better solutions that have been discussed and for which bugs have been created: the video element indicates when it can't play because hardware is in use [1], gecko to utilize multiple video codec instances when possible [2]. Of course, combining these two would be best since depending on the hardware there may be only one video codec instance and even if there are multiple there still can be contention.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1108477
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1093283

I will experiment with using the File Manager app to play videos on a dolphin and see about increasing the timeout.

Comment 9

[Russ Nicoletti [:russn]]

I'm not able to recreate the problem on the flame. I thought I had a dolphin but I now recall that I no longer have it. Also, I'm unable to play the video from comment 1, there appears to be an error. In any event, I am attaching a patch that increases the timeout from 1000 to 2000ms. I am also requesting qawanted to help determine the reproducibility of this issue on flame and dolphin. If it can be reproduced reliably, the patch can be applied to see if increasing the timeout to 2000ms solves the problem.

Comment 10

[Russ Nicoletti [:russn]]

Attachment: increase timeout to 2s

Comment 11

[Pi Wei Cheng [:piwei] (inactive)]

I was able to download the issue demonstration video at comment 1 and I've re-uploaded the video to youtube:

http://youtu.be/oyqw0iCVIZE

----

The repro rate is low on the Flame. I had it repro'ed 1 out of 10 attempts. Using videos taken by Flame device.
The issue seems more likely to repro on the first attempt within the same session, or by locking/unlocking the phone while in the File Manager app watching a video.

Tested on:
Device: Flame 2.1 (shallow flash, 319MB mem)
BuildID: 20150114175730
Gaia: 8d4846d7bec777046dc5e3d2b8005adb1370f1f7
Gecko: 8eb9bc3a945a
Version: 34.0 (2.1)
Firmware: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

-----

We don't have a Dolphin device in QAnalysts, but I think I've fulfilled the qawanted request so removing keyword.

Comment 12

[Russ Nicoletti [:russn]]

I am able to consistently reproduce when my flame is configured to use 319mb RAM and when loading a 40mb video. When increasing the timeout to 1500ms, I am not able to reproduce. I will create a PR to increase the timeout to 1500ms.

Comment 13

[Russ Nicoletti [:russn]]

Attachment: Link to github PR

Comment 14

[David Flanagan [:djf]]

Comment on attachment 8552813 [details] [review]
Link to github PR

Looks good to me. This is a trivial change to two timeout intervals and is practically risk-free for uplift to whatever branches need it.

Comment 15

[Russ Nicoletti [:russn]]

Master: 

https://github.com/mozilla-b2g/gaia/commit/cfa82773c75bf72c2603438a537e2add87a0e6b1