[prev in list] [next in list] [prev in thread] [next in thread]
List: helix-filesystem-dev
Subject: [Filesystem-dev] RE: [Client-dev] CR needed: Symbian 420Brizo/HEAD
From: <Junhong.Liu () nokia ! com>
Date: 2010-09-27 15:03:28
Message-ID: 673F5EF8B307EB4488DDABBBD521B3270164B7 () 008-AM1MPN1-003 ! mgdnok ! nokia ! com
[Download RAW message or body]
Checked in to 420Brizo and HEAD.
Thanks,
Junhong
-----Original Message-----
From: ext Sheldon Fu [mailto:sfu@real.com]
Sent: Friday, September 24, 2010 9:12 PM
To: Liu Junhong (Nokia-MS/Dallas)
Cc: client-dev@lists.helixcommunity.org; filesystem-dev@helixcommunity.org
Subject: Re: [Client-dev] CR needed: Symbian 420Brizo/HEAD : Constant reloading for \
high frame rate clips
Looks good.
Thanks for the research done on this. This would be very useful when we try to fix \
the problem for other platforms.
fxd
Junhong.Liu@nokia.com wrote:
> Hi, Sheldon:
>
> Please see the new diff as below. I used Symbian flag on the async PacketReady \
> callback. I will modify my synopsis to "move these 5 packets to Renderer in the \
> next HXPlayer::ProcessIdle" when I check in.
> Thanks,
>
> Junhong
>
>
> ===================================================================
> RCS file: /cvsroot/client/core/hxflsrc.cpp,v
> retrieving revision 1.138.12.1.2.2
> diff -u -b -r1.138.12.1.2.2 hxflsrc.cpp
> --- hxflsrc.cpp 5 Mar 2010 13:18:41 -0000 1.138.12.1.2.2
> +++ hxflsrc.cpp 25 Sep 2010 00:33:23 -0000
> @@ -109,6 +109,13 @@
> #define SOURCE_TIMELINE_TOL 500
> #define LOCALSOURCE_FAST_START_BW_CAPACITY_THRESHOLD 150 // A percentage o
>
> +#ifdef _SYMBIAN
> +#define MAX_NUM_EVENTS 5
> +#else
> +#define MAX_NUM_EVENTS 0
> +#endif
> +
> +
> HXFileSource::HXFileSource()
> > m_lRefCount(0)
> , m_ulLastBufferingReturned(0)
> @@ -2804,8 +2811,17 @@
>
> if(!m_bInFillMode)
> {
> +#ifdef _SYMBIAN
> + if (lEventList->GetNumEvents() <= MAX_NUM_EVENTS)
> + {
> FillBuffers(HX_GET_BETTERTICKCOUNT());
> }
> + else
> + {
> + m_pSourceInfo->ScheduleProcessCallback();
> + }
> +#endif
> + }
>
> if (!theErr)
> {
> @@ -3423,7 +3439,7 @@
>
> if (!lpStreamInfo->m_bSrcStreamDone)
> {
> - if (lpStreamInfo->m_EventList.GetNumEvents() == 0)
> + if (lpStreamInfo->m_EventList.GetNumEvents() <=
> + MAX_NUM_EVENTS)
> {
> bHasUnfilledStreams = TRUE;
>
> @@ -3439,7 +3455,7 @@
>
> if (!lpStreamInfo->m_bPacketRequested)
> {
> - if (lpStreamInfo->m_EventList.GetNumEvents() == 0)
> + if (lpStreamInfo->m_EventList.GetNumEvents() <=
> + MAX_NUM_EVENTS)
> {
> lpStreamInfoOut = lpStreamInfo;
> bSelectedStream = TRUE;
>
> -----Original Message-----
> From: ext Sheldon Fu [mailto:sfu@real.com]
> Sent: Friday, September 24, 2010 3:57 PM
> To: Liu Junhong (Nokia-MS/Dallas)
> Cc: client-dev@lists.helixcommunity.org;
> filesystem-dev@helixcommunity.org
> Subject: Re: [Client-dev] CR needed: Symbian 420Brizo/HEAD : Constant
> reloading for high frame rate clips
>
> This looks fine for Symbian, but on other platforms, the following
> code
>
> if(!m_bInFillMode)
> {
> + if (lEventList->GetNumEvents() <= MAX_NUM_EVENTS)
> + {
> FillBuffers(HX_GET_BETTERTICKCOUNT());
> }
> + else
> + {
> + m_pSourceInfo->ScheduleProcessCallback();
> + }
> + }
>
> will result in m_pSourceInfo->ScheduleProcessCallback() being called for each \
> PacketReady() callback, while the old code only calls FillBuffers (which will be a \
> no-op because of the queue deep limitation in FillBuffers). Is this intentional(for \
> other platforms that is)? It might be better to limit the change to Symbian only if \
> you don't intend to test other platforms.
> Also, I don't think it matters much for your purpose but SourceInfo's ProcessIdle \
> doesn't really move the packets to Renderer, HXPlay's ProcessIdle does with its \
> SendPacket method.
> fxd
>
>
> Junhong.Liu@nokia.com wrote:
>
> > Modified by: Junhong.liu@nokia.com
> > Reviewed by: Ashish.As.Gupta@nokia.com
> > Date: 09/23/2010
> > Project: symbian_client_apps
> > ErrorId: ou1cimx1#562804
> > Synopsis: Constant reloading for high frame rate clips
> > Overview:
> > For Brizo420 and HEAD branches, we are experiencing long start-up
> > time, constant reloading, and less CPU idle time on Power Save mode.
> > This was introduced by the change
> > _http://lists.helixcommunity.org/pipermail/helix-client-dev/2006-Augu
> > s t/004927.html_ on FillBuffers() logic. On asynchronous file i/o,
> > each
> > HXPlayer::ProcessIdle() (30ms interval) can only read one packet at
> > most. This was the root cause of all these problems.
> > This CR is to issue another FillBuffers() in PacketReady callback
> > until 5 packets are received. After that, schedule an immediate
> > SourceInfo callback to move these 5 packets to Renderer. The reason
> > of choosing 5 as max is because : 1) if the number is too big, then
> > we fill data too far ahead and load too much data to RAM. 2) If we
> > can read 5 packets in 30ms interval, prerolling 1 second of 30fps
> > clip will take 180ms. This is good enough for us.
> > Together with this CR, I also removed the 15 ms (1/64 second)
> > restriction on Rtimer's resolution because it has been changed to 1ms
> > since EKA2 Files Added:
> > None.
> > Files Modified:
> > client/core/hxflsrc.cpp
> > common/system/platform/symbian/symbianthreads.cpp
> > Image Size and Heap Use impact: minor Module Release testing (STIF) :
> > ongoing Test case(s) Added : No.
> > Memory leak check performed : Yes. No new leaks introduced Platforms
> > and Profiles Build Verified:
> > helix-client-symbian-4
> > Platforms and Profiles Functionality verified: armv5, winscw
> > Branch: 420Brizo, HEAD
> >
> > Thanks,
> >
> > Junhong
> >
> >
> > ===================================================================
> > RCS file: /cvsroot/client/core/hxflsrc.cpp,v
> > retrieving revision 1.138.12.1.2.2
> > diff -w -u -r1.138.12.1.2.2 hxflsrc.cpp
> > --- hxflsrc.cpp 5 Mar 2010 13:18:41 -0000 1.138.12.1.2.2
> > +++ hxflsrc.cpp 23 Sep 2010 14:34:09 -0000
> > @@ -109,6 +109,13 @@
> > #define SOURCE_TIMELINE_TOL 500
> > #define LOCALSOURCE_FAST_START_BW_CAPACITY_THRESHOLD 150 // A
> > percentage of source bitrate
> >
> > +#ifdef _SYMBIAN
> > +#define MAX_NUM_EVENTS 5
> > +#else
> > +#define MAX_NUM_EVENTS 0
> > +#endif
> > +
> > +
> > HXFileSource::HXFileSource()
> > > m_lRefCount(0)
> > , m_ulLastBufferingReturned(0)
> > @@ -2804,8 +2811,15 @@
> >
> > if(!m_bInFillMode)
> > {
> > + if (lEventList->GetNumEvents() <= MAX_NUM_EVENTS)
> > + {
> > FillBuffers(HX_GET_BETTERTICKCOUNT());
> > }
> > + else
> > + {
> > + m_pSourceInfo->ScheduleProcessCallback();
> > + }
> > + }
> >
> > if (!theErr)
> > {
> > @@ -3423,7 +3437,7 @@
> >
> > if (!lpStreamInfo->m_bSrcStreamDone)
> > {
> > - if (lpStreamInfo->m_EventList.GetNumEvents() == 0)
> > + if (lpStreamInfo->m_EventList.GetNumEvents() <=
> > MAX_NUM_EVENTS)
> > {
> > bHasUnfilledStreams = TRUE;
> >
> > @@ -3439,7 +3453,7 @@
> >
> > if (!lpStreamInfo->m_bPacketRequested)
> > {
> > - if (lpStreamInfo->m_EventList.GetNumEvents() == 0)
> > + if (lpStreamInfo->m_EventList.GetNumEvents() <=
> > MAX_NUM_EVENTS)
> > {
> > lpStreamInfoOut = lpStreamInfo;
> > bSelectedStream = TRUE;
> >
> >
> > Index: symbianthreads.cpp
> > ===================================================================
> > RCS file:
> > /cvsroot/common/system/platform/symbian/symbianthreads.cpp,v
> > retrieving revision 1.22.10.1
> > diff -w -u -r1.22.10.1 symbianthreads.cpp
> > --- symbianthreads.cpp 26 Feb 2010 21:15:12 -0000 1.22.10.1
> > +++ symbianthreads.cpp 23 Sep 2010 15:39:18 -0000
> > @@ -963,10 +963,6 @@
> > HX_ASSERT( pTimer != NULL );
> > if( pTimer != NULL )
> > {
> > - //Make sure the timeout is an even multiple of our
> > - //system tick. 15ms for Symbian phones we have ported
> > - //to so far. XXXgfw get this from a Symbian call.
> > - ulTimeOut = ulTimeOut/15*15;
> > pTimer->Init(ulTimeOut, pReceivingThread );
> >
> > //Add new timer to map.
> > @@ -1007,7 +1003,6 @@
> > HX_ASSERT( pTimer != NULL );
> > if( pTimer != NULL )
> > {
> > - ulTimeOut = ulTimeOut/15*15;
> > pTimer->Init(ulTimeOut, pfExecFunc );
> >
> > //Add new timer to map.
> >
> >
> >
>
> .
>
>
_______________________________________________
Filesystem-dev mailing list
Filesystem-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/filesystem-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic