Yes, if only from the power saving perspective, we can even put omx in IDLE or LOADED state not only after EOS, but also when user pauses playback:) I just think it's not worthy because app developers is supposed to release player after usage:)
On Mon, Feb 9, 2009 at 11:00 AM, hdandroid <[email protected]> wrote: > > HW continues to cosume power from the time the component is put to > PAUSE to the time finalize() is called. This duration could be > significant and result in unnecessary power consumption. (if you are > lukcy the app might get killed - otherwise HW continues to consume > power) > > Even if the component is moved to OMX IDLE state, user interface can > show that player is PAUSED. There is no change in UI behavior with > this approach. > > On Feb 8, 6:33 pm, Freepine <[email protected]> wrote: > > I think Ravi has made a good point and as far as I know staying in PAUSED > > state after EOS is a common practice for various players. > > > > As a well-educated programmer, I don't think releasing acquired resources > > after its usage is that difficult:) And even you don't call release() > > manually, mediaplayer class's finalize() will be called eventually when > it's > > garbage collected and release the player. > > > > I guess the main concern we have is that it lacks of robustness for not > > well-written applications, especially considering the reality of that > > applications might get randomly killed due to memory shortage. I did a > > simply test to kill the test app while playback is ongoing and found that > > music stopped immediately. So it seems binder driver did a good job to > > decrease the reference count of player object when client app is killed. > > -Freepine > > > > > > > > On Mon, Feb 9, 2009 at 4:57 AM, 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 > it > > > > when starting playback again somewhere in the same clip. > > > > > > On Feb 6, 8:54 am, hdandroid <[email protected]> wrote: > > > > > > > You would expect a well written app to issue release(). There is no > > > > > way to enforce this on all apps that run on the platform. > > > > > There will always be an app that is not well written which would > not > > > > > call release(). > > > > > > > From a platform perspective, android platform can allow lower power > > > > > consumption with both types of apps. This would require Opencore to > > > > > move the component to Idle or loaded state at the end of playaback. > I > > > > > agree that this would result in additional buffer exchange as you > > > > > mentioned. It is really small amount of work and it does not result > in > > > > > noticable delays and it is not perceivable by human ears (while > > > > > playing the same clip again, user would experience the same delay > that > > > > > would result when he/she moves to the next song - this change is > not > > > > > perceivable) > > > > > > > Another case is music player app is put to background in PAUSE > state > > > > > (at the end of playback) and HW continues to consume power. In this > > > > > case, well written app would call release() before going to > > > > > background. Some apps (not well written) apps may not perform this > > > > > operation. > > > > > > > I suggest that Opencore make this change (move to IDLE or LOADED at > > > > > the end of playback) allowing underlying OMX Codecs to stay power > > > > > friendly. This would allow the Android platform to stay power > friendly > > > > > for both types of Apps (well written and not well written ones) > > > > > > > On Feb 5, 10:55 pm, rktb <[email protected]> wrote: > > > > > > > > I see what you are referring to. But, I think moving the > component to > > > > > > PAUSE state might be preferable. > > > > > > > > First of all, where does this "Pause" come from? The > PVPlayerEngine, > > > > > > at the end of a playback of content, drives the engine to a > Paused > > > > > > state. This reduces the start up time if a same clip is being > played > > > > > > in a loop. With this objective, let us evaluate the possible > states. > > > > > > > > By moving the component to IDLE state, the buffers have to be > > > returned > > > > > > to the node. When the playback restarts for the same clip, the > > > buffers > > > > > > have to be resend to the component. This seems to be a waste. > > > > > > > > By moving the component to LOADED state, all the buffers would > have > > > to > > > > > > be freed. So, restarting the clip would mean re-allocating > > > > > > buffers...which again seems to be a waste. > > > > > > > > If the application doesn't really want to consume any resources > or > > > > > > wants to reduce power consumption, it should not wait at the end > of > > > > > > the clip and should call mediaplayer->release(). > > > > > > > > -Ravi > > > > > > > > On Feb 5, 10:25 pm, hdandroid <[email protected]> wrote: > > > > > > > > > Can someone point me to the document? Is is somewhere on PV > website > > > or > > > > > > > can I get it from git? > > > > > > > I am pretty sure OpenCore is not tearing down the playback > session > > > - > > > > > > > it continues to keep the component in PAUSE after the end of > > > playback. > > > > > > > > > On Feb 5, 6:24 pm, Dave Sparks <[email protected]> > wrote: > > > > > > > > > > When the app calls release, ultimately it will flow down to > > > through > > > > > > > > the framework to tear down the playback session. As Freepine > > > points > > > > > > > > out, the OMX decoder node in OpenCore is responsible > > > > ... > > > > 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 -~----------~----~----~----~------~----~------~--~---
