1098682 - [Midori 2.0][Power consumption][Video Player] Clicking power key to pause video player and standby current is 34mA.

Status: RESOLVED WONTFIX

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

Description

[sync-1]

FireFox OS v2.0
 
 mozilla build id:20141019000201
 
 DEFECT DESCRIPTION:
  Clicking power key to pause video player and standby current is 34mA. 
 
  REPRODUCING PROCEDURES:
  1. Enter "video player",select a video to play;
  2. Click power key and video will be paused, take standby current, it is 34mA;--KO
 
  EXPECTED BEHAVIOUR:
  Standby current is <5mA.
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:

Comment 1

[hanp]

[Blocking Requested - why for this release]:
Power consumption problem is a serious problem, please support. thanks

Comment 2

[Shine(Leave from Mozilla)]

Please add logcat and the information of “this is reproducible in 1.3 SW or not” for this issue.

Comment 3

[Wesly Huang (EPM)]

Hi Danny, seems this is a different scenario then before, is it possible for you to use Flame to test as well? latest m/c is priority and 2.0 result is good to have, too. Thank you.

Comment 4

[Danny Liang [:dliang]]

This is issue can be reproduced on flame v2.0 pvt build, the standby current is ~30mA. This issue could be recovered by suspend/resume again. It looks like some components can not be closed in time.

Gaia      086a668942292168f312b3bb53e275fa0886fab1
Gecko     https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/a57b299c5cf2
BuildID   20141116160206
Version   32.0
ro.build.version.incremental=eng.cltbld.20141116.193949
ro.build.date=Sun Nov 16 19:40:03 EST 2014

Comment 5

[Blake Wu [:bwu][:blakewu]]

Maybe video codec is not released.

Comment 6

[Blake Wu [:bwu][:blakewu]]

You can check if the following function is called or not. 
OmxDecoder::ReleaseMediaResources()

Comment 7

[Sotaro Ikeda [:sotaro]]

On caf OMXCodec, when OMXCodec::pause() is called, hw codec should reduce power consumption. If it does not reduce the power consumption, it seems better to ask to codeaurora.

OMXCodec::pause() is called from OmxDecoder::Pause().
http://dxr.mozilla.org/mozilla-central/source/dom/media/omx/OmxDecoder.cpp#785

Comment 8

[Sotaro Ikeda [:sotaro]]

(In reply to Blake Wu [:bwu][:blakewu] from comment #6)
> You can check if the following function is called or not. 
> OmxDecoder::ReleaseMediaResources()

I do not think the hw video codec is released in this use case in current firefox os.

Comment 9

[Blake Wu [:bwu][:blakewu]]

I just have a quick check. My Flame with FFOS 2.0 build shown below will call OmxDecoder::ReleaseMediaResources() after I push power key during video is playing. 
Gaia-Rev        086a668942292168f312b3bb53e275fa0886fab1
Gecko-Rev       5d6c6a4ece4c85bd18ae6a5d25c3b0d6125659ac
Build-ID        20141117151853
Version         32.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141116.193949
FW-Date         Sun Nov 16 19:40:03 EST 2014
Bootloader      L1TC00011880

IMHO, we should not use pause to save power since that only works for one platform and MediaCodecReader (Bug 1033931) could not support that either. We should apply the dormant mechanism for any cases if possible to save power.

Comment 10

[Wesly Huang (EPM)]

[Blocking Requested - why for this release]:

[Triage] Per current discussion above this tends to be valid issue and nom. to 2.1 for consideration.

Comment 11

[hanp]

sirs, on midori 1.3, after music paused, the power consumption will reduce from 34 to 2.5mA

Could you please tell us how to "apply the dormant mechanism" as blake said in comment #9?

Comment 12

[Sotaro Ikeda [:sotaro]]

(In reply to Blake Wu [:bwu][:blakewu] from comment #9)
> IMHO, we should not use pause to save power since that only works for one
> platform and MediaCodecReader (Bug 1033931) could not support that either.
> We should apply the dormant mechanism for any cases if possible to save
> power.

It is implemented to reduce power consumption during audio playback pausing. When OMXCodec is instantiated, it was the only way to reduce the power consumption on caf.

Comment 13

[Blake Wu [:bwu][:blakewu]]

(In reply to hanp from comment #11)
> sirs, on midori 1.3, after music paused, the power consumption will reduce
> from 34 to 2.5mA
> 
> Could you please tell us how to "apply the dormant mechanism" as blake said
> in comment #9?
AFAIK, the dormant mechanism is to release codec resource to save power. 
You can refer to [1][2] for more information.

[1]http://dxr.mozilla.org/mozilla-central/source/dom/media/MediaDecoderStateMachine.cpp#1340
[2]http://dxr.mozilla.org/mozilla-central/source/dom/media/omx/MediaOmxReader.cpp#212

Comment 14

[Blake Wu [:bwu][:blakewu]]

(In reply to Sotaro Ikeda [:sotaro] from comment #12)
> (In reply to Blake Wu [:bwu][:blakewu] from comment #9)
> > IMHO, we should not use pause to save power since that only works for one
> > platform and MediaCodecReader (Bug 1033931) could not support that either.
> > We should apply the dormant mechanism for any cases if possible to save
> > power.
> 
> It is implemented to reduce power consumption during audio playback pausing.
> When OMXCodec is instantiated, it was the only way to reduce the power
> consumption on caf.
Understood. 
Maybe we could apply dormant to this use case. But may need to check how quickly it can resume from pause state.

Comment 15

[bhavana bajaj [:bajaj]]

(In reply to Sotaro Ikeda [:sotaro] from comment #7)
> On caf OMXCodec, when OMXCodec::pause() is called, hw codec should reduce
> power consumption. If it does not reduce the power consumption, it seems
> better to ask to codeaurora.
> 
> OMXCodec::pause() is called from OmxDecoder::Pause().
> http://dxr.mozilla.org/mozilla-central/source/dom/media/omx/OmxDecoder.
> cpp#785

NI inder here to see if he can get any feedback from CAF.

Comment 16

[David Flanagan [:djf]]

Triage: we need more info before deciding whether to block on this. In this bug, does current draw remain at 34mA forever, or does it the phone actually sleep at some point after the screen blanks?  If current draw remains high forever, then this would be an obvious blocker. But if it is just a transient thing where current just doens't drop quickly enough, then maybe we don't need to block.

Also: does this bug go away if you revert the patch from bug 1082563? Before we landed that bug, the Video app would fully release the <video> element when it went to the background by setting the src attribute to the empty string. But it took a while to restore the video when the phone woke up, and bug 1082563 was 2.1+ because of that. With 1082563, we rely on gecko to free resources when the app goes to the background.

Comment 17

[David Flanagan [:djf]]

Note that you probably won't be able to revert just bug 1082563 and will probably first have to revert bug 1085212. If reverting 1082563 fixes this bug, then we'll need to create a new version of the patch for 1085212 and apply that after reverting 1082563.

Comment 18

[hanp]

hi, david
I checked our code and found we haven't integrate the patches in bug 1082563 and bug 1085212

Comment 19

[bhavana bajaj [:bajaj]]

Hoping after integration of these patches the issue is fixed, feel free to renom if you need to otherwise.

Comment 20

[Jack Liu]

Dear Mozillian,

Per comment#18, it doesn't caused by the patches.

There is a clue for your reference, please help to check whether it's mozilla issue or platform specific:

gecko/content/media/omx/AudioOutput.cpp 

void AudioOutput::Stop()
{
  AUDIO_OFFLOAD_LOG(PR_LOG_DEBUG, ("%s", __PRETTY_FUNCTION__));
  if (mTrack.get()) {
    mTrack->stop();  //this has been called normally but the audio resource won't be released
  }
}

Thanks!

Comment 21

[BMO Automation]

Firefox OS is not being worked on