Added "YieldLessToOthers" preference support.
The default is 0, (thus maximum yielding but heavier use of 
HX_GET_BETTER_TICKCOUNT())
Setting of 1, constrains yielding only to buffering period.

No significant CPU usage difference was observed on windows between two modes.

Milko

----------------

Modified by: milko at real.com
Date: 8:31:06
Project: Atlas

Synopsis: Player core yielding and quick seek performance

Overview:
The change provides logistcal optimizations for management of CPU 
allocation during player execution and data flow management during 
QuickSeek operation.

The change limits the amount of time player spends in ProcessIdle loop to 
the time inerval at which ProcessIdle is scheduled to execute (every 
30ms).  Once ProcessIdle exceeds its allocated slice, it will resume 
processing on the next slice.  The purpose of this is to cooperatively 
share the CPU what top level client and enable events within the core to be 
serviced in more timely manner.  Process idle, however, is always 
guaranteed to advance processing in the media engine regardless of time 
spent.  That is, at least one event will be retrieved from the data source 
and at least one event will be pushed into the renderers as long as this is 
needed.  Thus processing will never halt due to high CPU usage but it will 
slow down.
This logic relies on the proper generation of time-slices for the core 
which should always attempt to be more than 1 slice per 
PlayerUpdateInterval (30ms) irrespective of how long it takes to execute 
the slice.  That is, if current slice takes 30 or more milliseconds to 
execute, the next slice should be given immediately (CPU availability 
contingent).  This insures that media platform is given chance for maximum 
throughput.  On windows time-slice pacing is done automatically by the 
media platform and conforms to the above requirements.  Other platforms 
(especially those that pace the media platform externally via Kick() 
method) will need to be checked to make sure the pacing algorithms exhibit 
the above described behavior.  This will follow this submission.

Current change does not execute yielding in every aspect of media engine 
and there may still be some loops that step over the slice interval 
boundary.  It just addresses the most serious loops and primarily for local 
playback where the abundance of immediately accessible data tends to result 
in high start-up speed but also high CPU usage.

This behavior can be turned off by specifying: 
HELIX_CONFIG_YIELD_LESS_TO_OTHERS

QuickSeek operation has been optimized to complete immediately after the 
absolute minimum number of video packets have been transfered into the 
renderer.  Audio buffering is immediately declared completed in quick seek 
mode and video buffering based on FastStart logic as soon as first frame is 
displayed.  Previous logic had potential for delays due to buffering 
requirements and higher CPU usage due to continued processing after first 
frame displayed.

The computation of "pushdown" frames in video renderer has been corrected 
to account for only those frames that are at or passed the start 
time.  Previous logic resulted in premature fulfillment of video pushdown 
on seek due to post-decode buffer being active with pre-seek point frames 
which are flushed.


Files Modified:
/client/core/hxbsrc.h,v
/client/core/hxflsrc.cpp,v
/client/core/hxflsrc.h,v
/client/core/hxntsrc.cpp,v
/client/core/hxntsrc.h,v
/client/core/hxplay.cpp,v
/client/core/hxsrc.cpp,v
/client/core/srcinfo.cpp,v
/client/core/srcinfo.h,v
/client/core/pub/hxplay.h,v
/datatype/common/vidrend/vidrend.cpp,v

Image Size and Heap Use impact (Client -Only):
next to none

Platforms and Profiles Affected:
all

Distribution Libraries Affected:
none

Distribution library impact and planned action:
n/a

Platforms and Profiles Build Verified:
win32-i386-vc7, helix-client-all-defines

Platforms and Profiles Functionality verified:
win32-i386-vc7, helix-client-all-defines

Branch:
HEAD