1033931 - Reduce the power consumption of android::MediaCodec by setting OMX_StatePause state to OMX IL component.

Status: RESOLVED INACTIVE

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

Description

[Bruce Sun [:brsun]]

This is a followup bug of bug 904177. Reduce the power consumption of android::MediaCodec in pause state like android::OMXCodec.

Comment 1

[Bruce Sun [:brsun]]

In order to save power, it would be good to set the state of each OMX IL component to OMX_StatePause when there are no data to be decoded.

We can achieve this on OMXCodec by calling OMXCodec::pause().
 - https://bugzilla.mozilla.org/show_bug.cgi?id=919590#c2

But it seems there is no public interface of MediaCodec / ACodec to set OMX_StatePause to the OMX IL component.

mvines: any suggestion?

Comment 2

[Michael Vines [:m1] [:evilmachines]]

Do you know how much power we are consuming here, and in exactly what use cases?

Comment 3

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

FYR. Bug 860760 is for OMXCodec case. 
But I think we should let application directly stop instead of pausing. If user want to resume, just start again and seek to the previous time. In this way, we don't need to add extra complexity to Gecko and can make Gecko more simple.

Comment 4

[Bruce Sun [:brsun]]

mvines: Actually I didn't measure difference of the power consumption. I just noticed that there might be the possibility to reduce the power consumption. The basic idea is to reduce the power consumption when there are no needs to decode data but the instance of MediaCodec should still be held by gecko.

diego: Could you help share your measurement of the power consumption on OMXCodec?

Comment 5

[Bruce Sun [:brsun]]

mvines: Do you think this bug is worth to solve?

Comment 6

[bhargavg1]

(In reply to Bruce Sun [:brsun] from comment #5)
> mvines: Do you think this bug is worth to solve?

I am bit confused on what exactly needs to be measured here?

Comment 7

[Ivan Tsay (:ITsay)]

This is part of 2.1 feature work on Async codec.

Comment 8

[Bruce Sun [:brsun]]

(In reply to bhargavg1 from comment #6)
> (In reply to Bruce Sun [:brsun] from comment #5)
> > mvines: Do you think this bug is worth to solve?
> 
> I am bit confused on what exactly needs to be measured here?

Similar problem of OMXCodec has been resolved on bug 860760, which uses OMXCodec::pause() to set the underlying OMX IL component into OMX_StatePause state to save power consumption:
 - https://www.codeaurora.org/cgit/quic/la/platform/frameworks/av/tree/media/libstagefright/OMXCodec.cpp?h=b2g_jb_3.2#n4967

But since MediaCodec/ACodec doesn't have any method to set OMX_StatePause state, we should find out a way (maybe introducing a new API or something) to set the underlying component into pause state to achieve similar power consumption like OMXCodec.

I am not sure whether this information could ease your confusion a little bit or not.
Kindly let me know if I didn't express the intention of this bug clear enough.

Comment 9

[Bruce Sun [:brsun]]

Hi Marvin, feel free to share your comments. Thanks.

Comment 10

[Marvin Khoo [:Marvin_Khoo]]

Hi Sandip,
as mentioned in email, please help to push if we can get support here, or we will not consider this into upcoming releases. meaning, device may impact power consumption in streaming case.

suggest partner to support this, as this will benefit the product for choosing their solution running Firefox OS

Comment 11

[Marvin Khoo [:Marvin_Khoo]]

this is part of POVB. thus, clear feature-b2g blocker here.

Comment 12

[Marvin Khoo [:Marvin_Khoo]]

Hi Bhargav,

Sum up, fyi.

For the use case, engineer already had feedback in comment 3, in short, it’s relative to reduce power consumption @ pause stage.

For power measurement, the initiative and relative bug is Bug 860760 where Diego raised and claimed the power consumption is the always the same no matter music is playing or at paused stage. believe QC have code check in and fixed. hence, we did not measure anything here.

For the need, this is for video case, we would need a public interface of MediaCodec / ACodec to set OMX_StatePause to the OMX IL component to achieve power reduction.

Comment 13

[Sandip Kamat]

vendor will look into this. clearing NI.

Comment 14

[bhargavg1]

(In reply to Marvin Khoo [:Marvin_Khoo] from comment #12)
> Hi Bhargav,
> 
> Sum up, fyi.
> 
> For the use case, engineer already had feedback in comment 3, in short, it’s
> relative to reduce power consumption @ pause stage.
> 
> For power measurement, the initiative and relative bug is Bug 860760 where
> Diego raised and claimed the power consumption is the always the same no
> matter music is playing or at paused stage. believe QC have code check in
> and fixed. hence, we did not measure anything here.
> 
> For the need, this is for video case, we would need a public interface of
> MediaCodec / ACodec to set OMX_StatePause to the OMX IL component to achieve
> power reduction.

Thanks for clarifying on the requirement. Basically we are looking at the change in bug 86070 and want to know the difference in power delta for video playback/pause case 

Let me get back to you with the results

Comment 15

[bhargavg1]

See the power consumption decreasing similar to stop case for pause case well

Comment 16

[Bruce Sun [:brsun]]

(In reply to bhargavg1 from comment #15)
> See the power consumption decreasing similar to stop case for pause case well

bhargavg1: I guess this is referring to OMXCodec, so probably there are benefits to have a way to switch MediaCodec into the pause state as well, right?

Comment 17

[bhargavg1]

(In reply to Bruce Sun [:brsun] from comment #16)
> (In reply to bhargavg1 from comment #15)
> > See the power consumption decreasing similar to stop case for pause case well
> 
> bhargavg1: I guess this is referring to OMXCodec, so probably there are
> benefits to have a way to switch MediaCodec into the pause state as well,
> right?

Yes the tests are based on v2.1/OMXCodec based. Yes definitely there is a benefit for the same kind of implementation for MediaCodec as well

Comment 18

[Nils Ohlmeier [:drno]]

Mass closing do to inactivity.
Feel free to re-open if still needed.