Hi all,

Actually, with the bif branch hxclient_1_5_0_cayennes and the profile
helix-client-all-defines (with target splay or filesystem_httplite), we have
a one time progressive download. It uses filesystem/http.
It isn't possible to get filesystem/httplite to make permanent progressive
download?
Thanks,

Jérémie

-----Message d'origine-----
De : helix-client-dev-bounces at helixcommunity.org
[mailto:helix-client-dev-bounces at helixcommunity.org] De la part de Milko
Boic
Envoyé : jeudi 7 septembre 2006 09:56
À : helix-client-dev at helixcommunity.org
Objet : [Helix-client-dev] CR-Client: Start-up performance 2 

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

Synopsis: Player core start-up performance2

Overview:
---> In order to speed up the start-up, a much more aggressive approach is 
employed:
1.) As soon as video stream pushdown is met (FastStart enabled), the 
buffering for that stream is stopped.  The source (sourceInfo) is now 
change not to retrieve events from the streams that fulfilled the 
buffering.  This saves CPU from processing (decoding) video after the 
initial frame has been decoded and allows audio to queue faster.

2.) The above change often results in playback resuming with truly the 
minimum data present in audio/video devices.  In order to prevent immediate 
DryNotifications from the audio sessions, an additional level of audio 
queuing in audio session is defined for start-up:
m_ulMinBlocksToBeQueued         (new in meaning but not in name)
m_ulMinBlocksToBeQueuedAtStart  (used to be same as m_ulMinBlocksToBeQueued)
m_ulTargetBlocksToBeQueued      (used to be confusingly named 
m_ulMinBlocksToBeQueued)

The new meaning of theses variables is as follows:
m_ulMinBlocksToBeQueued - the minimum number of audio blocks that must be 
present in audio device at any given time or time-line will halt (rebuffer)
m_ulMinBlocksToBeQueuedAtStart - the minimum number of audio blocks that 
must be present in audio device for playback to start
m_ulTargetBlocksToBeQueued - number of audio blocks in audio device that is 
desirable to build up

These values ae computed based on the following pushdown setting in 
milliseconds:
MinimumPushdown			- normally set to 100ms
MimimumStartupPushdown		- normally set to 150ms
TargetPushdown			- normally set to >=200ms (1000ms on non
MIN_HEAP builds)

The following preferences can override the pushdown values:
"MinimumAudioPushdown"
"MinimumAudioStartupPushdown"
"TargetAudioPushdown"

3.) In order to prevent CPU spiking immediately after fulfilling 
MimimumStartupPushdown in attempt to fill up to the TargetPushdown, the 
filling of audio device is restricted by m_ulMaxBlocksToPlayPerGranule.  It 
is set to 2 which means that audio buffer will build in audio device about 
twice as fast as playback time.  This is further increased by 
over-scheduling (already implemented) the servicing of audio device by 40 - 
60%.

m_ulMaxBlocksToPlayPerGranule can be overridden by 
"MaxBlocksToPlayPerGranule" preference.

4.) Note: splay spends significant time printing file and stream 
headers.  Depending on content, delays of 450ms have been observed.  As 
this is done of the platform scheduler, this action starves any scheduled 
processed in the engine (e.g. servicing of audio device).  Since above 
change starts playback at only about 150ms in the audio device, break-ups 
in audio can be encountered.  The issues is splay code.  It has to be 
changed to not block the scheduler for such extensive period of time.


---> This change also includes a correction to dtdriver audio resampler 
output buffer reduction computation when there isn't enough data to fill 
the entire output buffer. 	


---> This change also includes previously submitted "Player core yielding 
and quick seek performance":

That change streamlines thread-hopping the core performs on start-up for 
the purpose of having various actions performed on different threads 
(AudioPlayer setup on interrupt thread, audio device resumption on system 
thread).

When a need for hop to a different thread is detected, player main loop 
(ProcessIdle) is immediately rescheduled to an appropriate thread.  Other 
threads are not scheduled.

This also includes a correction in file source which registers the source 
that is added on the fly.  Previously, local file source were not 
registered which resulted in non-functional fast start and failure to 
account for used bandwidth.


Files Modified:
/client/audiosvc/hxaudses.cpp,v
/client/audiosvc/pub/hxaudses.h,v
/client/core/basgroup.cpp,v
/client/core/hxflsrc.cpp,v
/client/core/hxplay.cpp,v
/client/core/hxsrc.cpp,v
/client/core/hxstrm.cpp,v
/client/core/srcinfo.cpp,v
/client/core/pub/hxplay.h,v
/client/core/pub/hxstrm.h,v
/datatype/tools/dtdriver/decoder/audio/amixer.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