Great detailed description for the changes! Let's thanks for Ravi's great support! If all the items in the change list of opencore2.0 can be explained like this, I think it would be very helpful for the developers. Can we find them or some links, Ravi?
Best Regards, Kevin 2009/6/10 Ravi <yend...@pv.com> > > Inline are some details. I won't be doing this again though. > > On Jun 9, 2:22 pm, crack74 <lee.woo...@gmail.com> wrote: > > Can I get some detailed information about following items? I am > > interested what's the user impact of following items: > > - MP3 Dynamic TOC Construction > Certain MP3 clips do not have any sync samples embedded in them. > Repositioning those clips does not always work well as expected by the > user (e.g., seekto 20 secs might end up being a seekto 30 secs). To > better achieve this, a table of contents (TOC) is constructed that > would contain the file offset and a corresponding duration. > Usefulness (in short): Better repositioning > > > - mp3 parser - duration calculation by walking file in background > There are mp3 clips that do not have a duration value associated with > it in some form of metadata. For such clips, an initial rough estimate > of duration is sent to the application. Thereafter, in the background, > the entire mp3 clip is parsed in the background and the exact duration > is calculated. > Usefulness (in short): Providing more accurate duration > > > - Author Engine Error Handling Robustness > Fixes for situations where the author engine had to be reset under > various error conditions. The goal is to make sure that the author > engine can be reset any time during a capturing session. > Usefulness (in short): Better stability > > > - Player Engine Error Handling Robustness > Fixes for situations where the player engine had to be reset under > various error conditions. > Usefulness (in short): Better stability > > > - Fundamental change in behavior of repositioning during 3GPP > > streaming > During a streaming session, say a user requests the player to do a > seek to 30 secs. However, the server starts streaming data from 20 > secs. Earlier, there was a wait for 10 secs before the playback > resumed. But now, instead of showing a blank screen to the user for > the duration of 10 secss, we will start playing from 20 secs. The main > motivation is that the "source" here will not (more often than not) > feed data faster than real time. > Usefulness (in short) : Better user experience > > > - Local Playback MP3 file does not display attached art work > The player engine was not able to grab the album art for some mp3 > clips. This was fixed. > Usefulness (in short): Better user experience > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "android-framework" group. To post to this group, send email to android-framework@googlegroups.com To unsubscribe from this group, send email to android-framework+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-framework?hl=en -~----------~----~----~----~------~----~------~--~---
