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

RESOLVED WONTFIX

Status

P2
normal
RESOLVED WONTFIX
4 years ago
6 months ago

People

(Reporter: sync-1, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
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

4 years ago
[Blocking Requested - why for this release]:
Power consumption problem is a serious problem, please support. thanks
blocking-b2g: --- → 2.0?
Flags: needinfo?(wehuang)
Please add logcat and the information of “this is reproducible in 1.3 SW or not” for this issue.
Flags: needinfo?(sync-1)

Comment 3

4 years ago
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.
Flags: needinfo?(wehuang) → needinfo?(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
Flags: needinfo?(dliang)
Maybe video codec is not released.
You can check if the following function is called or not. 
OmxDecoder::ReleaseMediaResources()
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
(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.
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

4 years ago
[Blocking Requested - why for this release]:

[Triage] Per current discussion above this tends to be valid issue and nom. to 2.1 for consideration.
blocking-b2g: 2.0? → 2.1?

Comment 11

4 years ago
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?
Flags: needinfo?(sync-1)
(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.
(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
(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.
(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.
Flags: needinfo?(ikumar)
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.
Flags: needinfo?(sync-1)
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

4 years ago
hi, david
I checked our code and found we haven't integrate the patches in bug 1082563 and bug 1085212
Flags: needinfo?(sync-1)

Updated

4 years ago
blocking-b2g: 2.1? → ---
Hoping after integration of these patches the issue is fixed, feel free to renom if you need to otherwise.

Comment 20

4 years ago
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!

Updated

3 years ago
Flags: needinfo?(ikumar)

Updated

2 years ago
Blocks: 1258639

Comment 21

6 months ago
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: 6 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.