Greg, Anymore thoughts on how to move forward? At the end of playback, do you prefer to move the component to unloaded state so that it benefits all kinds of OMX components?
On Feb 9, 8:51 am, hdandroid <[email protected]> wrote: > Regarding compoentns that handle their own power savings: > > I think this requires complex implementation. Releasing HW in > Pause state can result in loss of already queued input and already > decoder output buffers (which may be owned by HW in pause state). > Before releasing HW, SW needs to force HW consume all input buffers > and deliver all output buffers that have data (better to not do this > in > pause state - HW may not do this once it is in Pause state). > > PAUSE after EOS is a special case. In this case, it might be safe > to assume that no input was queued to HW and output buffers owned > by HW do not have any valid data. Even in this case, SW needs to > force > HW to release all output buffers owned and may be give those back if > user issues a rewind (or repeats the playback of same song). > > Also, components needs to decide how long to wait in pause state > before > deciding to release HW. > > It looks like moving the component to idle or unloaded state at the > end of eos > seems like a much simpler change that complicating the component. > > I agree that moving to unloaded state probably be the only approach > that can > help all types of components. > > On Feb 9, 6:18 am, GregS <[email protected]> wrote: > > > > > Several comments: > > > 1. There could be other possibilities than the 3 types of components > > you mention. For example: > > i. Components that handle their own power savings even in paused > > state (i.e., no state transition required) - D > > ii. Components that must be completely UNLOADED for power savings - > > E > > > The point is that the OpenMAX spec leaves this aspect of the behavior > > completely unknown. So if we're going to make a change that improves > > on power savings, I'd like to at least be sure that change has actual > > benefits in majority of cases, which means auditing what actual > > implementations are doing. > > > Also, I don't think you addressed my point that a well-written OpenMAX > > component should really fall into category D and handle its own power > > savings in paused state and not rely on the OpenMAX client (similar > > logic to why the app should not be responsible). If a vast majority > > of implementations require being completely unloaded, then I don't > > think it's worth making a change to only drive the state back to > > idle. This is something I'll investigate for OpenMAX core > > implementations being integrated, but I'd also be interested in seeing > > any information on specific implementations that anyone wants to > > provide. > > > 2. Regarding the startup latencies, I'm not sure the spec is clear > > that the state transitions should be done in 20msec. It does > > recommend that the OMX_SendCommand is done in 5 msec, but that is > > simply to validate the parameters of call. The actual state > > transition is typically performed outside the call context. The 20 > > msec timeout mentioned at the start of section 3.2 is for commands > > that require buffer processing. I just think the spec is not clear on > > the expected latency since this is an asynchronous command. > > > 3. I realize not all formats will need codec configuration data at the > > beginning, but any solution introduced at OpenMAX decoder node should > > be general and handle the case where the configuration is needed. I > > don't think it is valid for the OpenMAX component to cache > > configuration data if it is driven back to IDLE and the OpenMAX IL > > client certainly could not be written to rely on this behavior. Also > > the problem I mentioned about the codec config isn't about how to > > signal the data between the OpenMAX client and component (there's no > > problem using the OMX_BUFFERFLAG_CODECCONFIG flag on a buffer). The > > point is that new logic would need to be added to cache the data in > > the OpenMAX decoder node because the source node (file parser, > > streaming demux, etc) isn't going to resend it in this scenario. > > > Anyway, I agree it's worth further investigation and consideration, > > but I'm not convinced that driving the OpenMAX component to IDLE is > > the right solution yet. Again more data points on the behavior of > > actual implementations is needed. > > > On Feb 8, 2:57 pm, hdandroid <[email protected]> wrote: > > > > Let's take 3 types of components > > > > 1) Component must be moved to LOADED state for power savings - A > > > 2) Component can achieve power savings when moved to IDLE or LOADED > > > state - B > > > 3) Component cannot achieve power savings in any state - C > > > > Component A requires a well written App to call release() upon screen > > > timeout. > > > With a well writeen app, both component A and component B can benefit. > > > There is nothing much we can do for component C in any case. > > > With a not well written app (which does not call release()), platform > > > can help take advantage of capabilities of component B. > > > > Question is can the platform framework help very well written > > > component B when it is driven by not so well writeen App. > > > > Right now my component is see as the culprit as the platform continues > > > to consume power even when > > > playback has ended. The bad one here is really the app which was not > > > well written to call release() > > > upon idle screen timeout.I can save upto siginificant amount of power > > > (in the range of 50 -100mA depending > > > on the component). > > > > Startup latencies are not significantly variable. If a compoent > > > impementation strictly adheres to the specs recommendation, state > > > transitions should complete within a short amount of time (20ms > > > recommended by the spec when transition invloves buffer exchange - Sec > > > 3.2 of OMX IL 1.1.2). > > > > I don't think we are violating hardware abstraction here. Implicitly, > > > it is better to build the platform to help well written component B do > > > its best. Whether an IL client moves the component to IDLE or PAUSE > > > should not matter much if the component implementation is compliant > > > with the spec. Component A and C should continue to function even if > > > IL client moves them to IDLE instead of PAUSE. State transition delays > > > will be in the order of few milliseconds not noticable (I don't think > > > there is noticable delay in skipping from end of one song to the next > > > song with PV SW codecs on G1 - In this case, framwork is doing a > > > complete unload and reload of of potentially the same component) > > > > Sending codec config upon reinitalizing (idle to executing > > > transition): > > > This is not needed for all types of media formats (for example for AAC > > > ADTS and MP3). > > > Formats which need this would use OMX_BUFFERFLAG_CODECCONFIG to signal > > > config data. > > > This is an implementation issue in IL client and OMX component. This > > > is not an issue if both are spec compliant. > > > My component would anyway cache configuration data the first time it > > > is provided. If IL client does not provide it at the time of > > > idle->executing transition, it would reuse the configuration information > > > > provided at the very beginning. i.e., it would assume that there is no > > > configuration change. At this time I am playing with an MP3 component > > > which does not really require reconfiguration. > > > > Sec 3.2 > > > The standards body identified the 20-millisecond timeout to be a > > > reasonable > > > response time for commands that may require buffer processing to be > > > completed; > > > the assumption here is that the longest buffer processing would be > > > less than > > > 30 milliseconds, which corresponds to 30-frames per second video. > > > > Sec 2.1.4 > > > EXECUTING enables buffer processing to resume where the component left > > > off. > > > Transitioning from EXECUTING or PAUSED to IDLE will cause the context > > > in which > > > buffers were processed to be lost, which requires the start of a > > > stream to be > > > reintroduced. Transitioning from IDLE to LOADED will cause operational > > > resources > > > such as communication buffers to be lost. > > > > On Feb 8, 11:26 am, GregS <[email protected]> wrote: > > > > > Efficient power consumption is definitely worth pursuing. > > > > Unfortunately, to my knowledge, the OpenMAX IL spec does not give any > > > > guidelines on the expected power consumption in different states. > > > > Therefore there may be some OpenMAX components that might even need to > > > > be unloaded before there is any power consumption savings, others may > > > > have saving when driven to idle, or maybe for some it doesn't matter > > > > what state they are in (i.e., no power savings). Remember we're > > > > trying to create something that works across many different hardware > > > > platforms with different OpenMAX component implementations. Using > > > > similar logic to what you describe, it could be argued that the > > > > OpenMAX component implementation itself should handle the issues of > > > > power efficiency when paused rather than requiring every OpenMAX IL > > > > client that is interfacing with it to know the details of the power > > > > consumption in different modes as well the start-up latencies so > > > > proper tradeoffs could be made. The point of the OpenMAX IL interface > > > > is to abstract hardware details. > > > > > Of course all of this is a purely abstract discussion so far and I > > > > realize we have to deal with non-ideal implementations. So in order > > > > to assess the tradeoffs of changing the logic, it would be helpful to > > > > understand if you have specific OpenMAX implementations of concern. > > > > If so can you provide numbers on the power consumption of different > > > > states? Part of the challenge of transitioning the component to the > > > > idle state is that the codec configuration data would need to be > > > > cached (not done today) so it could be used to reinitialize the state > > > > of the OpenMAX component. In pause state the component keeps all the > > > > configuration and state information so it isn't necessary to resend > > ... > > read more »- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "android-framework" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-framework?hl=en -~----------~----~----~----~------~----~------~--~---
