helix buffering

We're being pushed to give details on helix buffering
schemes by one of 
our customers.

I guess the answer is complicated and will depend on various
options - 
helix feature defines,  server type, protocol etc.

I think they basically want to know this sort of thing:
. how much gets buffered at start of stream
. what happens when it rebuffers - does it try to buffer
more this time

Is there an existing doc that explains this ? If not could
someone give 
some info.

We'd also like to know if there are any HELIX_FEATURES that
can be used 
to adjust the buffering behaviour.

John












_______________________________________________
Helix-client-dev mailing list
Helix-client-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinf
o/helix-client-dev

John Stirling wrote:
> We're being pushed to give details on helix buffering
schemes by one of 
> our customers.
> 
> I guess the answer is complicated and will depend on
various options - 
> helix feature defines,  server type, protocol etc.
> 
> I think they basically want to know this sort of
thing:
> . how much gets buffered at start of stream
> . what happens when it rebuffers - does it try to
buffer more this time
> 
> Is there an existing doc that explains this ? If not
could someone give 
> some info.
> 
> We'd also like to know if there are any HELIX_FEATURES
that can be used 
> to adjust the buffering behaviour.

John, let me know if you have any questions after reading
this:

https://client.helixcommunity.org/2006/devdocs/buffering


--greg.


> 
> John
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Helix-client-dev mailing list
> Helix-client-devhelixcommunity.org
> http://lists.helixcommunity.org/mailman/listinf
o/helix-client-dev


_______________________________________________
Helix-client-dev mailing list
Helix-client-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinf
o/helix-client-dev

Thanks, that explains most of it.

Some questions:

Miscrosoft servers have support for accelerated buffering at
the start of a stream where they send out about 12 seconds
worth of 
data immediately before streaming at normal speed. Is there
an equivalent scheme for Real servers ? If so, how much data
is 
available ? I suspect there must be something along these
lines as most Real streams do tend to start up pretty
quickly for us.

The example for initial buffering says that it buffers about
4 seconds before starting playback. Then each time it
rebuffers it will 
add an extra second up to a limit of 10 seconds. Is there
any way to adjust the initial buffering amount via a
preference ? If so, 
how would that affect real initial buffering time.

Assuming the core runs out of data and it needs to rebuffer
(say 5 seconds worth of data), will this always take at
least 5 seconds 
? Or is there some sort of accelerated rebuffering scheme ?

Can you give some details on what happens during http://
streaming (I presume the example given is for Real Audio via
rtsp://)

John



----- Original Message ----- 
From: "Greg Wright" <gwrightreal.com>
To: "John Stirling" <jsreciva.com>
Cc: <helix-client-devhelixcommunity.org>
Sent: Monday, October 29, 2007 6:47 PM
Subject: Re: [Helix-client-dev] helix buffering


> John Stirling wrote:
>> We're being pushed to give details on helix
buffering schemes by one of our customers.
>>
>> I guess the answer is complicated and will depend
on various options - helix feature defines,  server type,
protocol etc.
>>
>> I think they basically want to know this sort of
thing:
>> . how much gets buffered at start of stream
>> . what happens when it rebuffers - does it try to
buffer more this time
>>
>> Is there an existing doc that explains this ? If
not could someone give some info.
>>
>> We'd also like to know if there are any
HELIX_FEATURES that can be used to adjust the buffering
behaviour.
>
> John, let me know if you have any questions after
reading
> this:
>
> https://client.helixcommunity.org/2006/devdocs/buffering

>
> --greg.
>
>
>>
>> John
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Helix-client-dev mailing list
>> Helix-client-devhelixcommunity.org
>> http://lists.helixcommunity.org/mailman/listinf
o/helix-client-dev
>
> 


_______________________________________________
Helix-client-dev mailing list
Helix-client-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinf
o/helix-client-dev

jsreciva.com wrote:
> Thanks, that explains most of it.
> 
> Some questions:
> 
> Miscrosoft servers have support for accelerated
buffering at the start 
> of a stream where they send out about 12 seconds worth
of data 
> immediately before streaming at normal speed. Is there
an equivalent 
> scheme for Real servers ? If so, how much data is
available ? I suspect 
> there must be something along these lines as most Real
streams do tend 
> to start up pretty quickly for us.

TurboPlay is what we call it. We try to get the 'preroll'
data just
as fast as the connection will allow it. It is controlled
via the
'TurboPlay' preference. You will also see it referred to
sometimes
as quickstart or faststart in the code. If you are seeing
slow starts
make sure you don't have it turned off in a mobile profile
or something.



> 
> The example for initial buffering says that it buffers
about 4 seconds 
> before starting playback. Then each time it rebuffers
it will add an 
> extra second up to a limit of 10 seconds. Is there any
way to adjust the 
> initial buffering amount via a preference ? If so, how
would that affect 
> real initial buffering time.

That must be an old document then. Well, it still applies to
all
branches except 150Cay, HEAD and 310Atlas. Those 3 branches
are
new and we made lots of changes to reduce the amount of
buffering
done. We only buffer the minimum data now needed to start
playback.
We also do not increase the buffering by 1 sec each time a
rebuffer
happens (I am pretty sure thats gone, I will go check).

> 
> Assuming the core runs out of data and it needs to
rebuffer (say 5 
> seconds worth of data), will this always take at least
5 seconds ? Or is 
> there some sort of accelerated rebuffering scheme ?

With turboplay we will get that data just as fast as we can.
So,
the time it takes to get 5 seconds of data depends on the
combination of the connection bandwidth, clip bit-rate and
quality
of the connection(lost packets, etc). Sometimes turboplay
can
be turned off if really poor conditions are detected. You
should
check this if you see slow rebuffers. The idea behind
turning it
off is that it may be what is causing the quality issues.
However,
I have found that those tend to be transitory and turning
off
turboplay due to rebuffers is kind of a pain. Although, I
have not
tried to check in changes to change that.

> 
> Can you give some details on what happens during
http:// streaming (I 
> presume the example given is for Real Audio via
rtsp://)

HTTP is just TCP download and play. So TCP will control the
rate of delivery
of the bits. TCP will do it just as fast as it can.

--greg.


> 
> John
> 
> 
> 
> ----- Original Message ----- From: "Greg
Wright" <gwrightreal.com>
> To: "John Stirling" <jsreciva.com>
> Cc: <helix-client-devhelixcommunity.org>
> Sent: Monday, October 29, 2007 6:47 PM
> Subject: Re: [Helix-client-dev] helix buffering
> 
> 
>> John Stirling wrote:
>>> We're being pushed to give details on helix
buffering schemes by one 
>>> of our customers.
>>>
>>> I guess the answer is complicated and will
depend on various options 
>>> - helix feature defines,  server type, protocol
etc.
>>>
>>> I think they basically want to know this sort
of thing:
>>> . how much gets buffered at start of stream
>>> . what happens when it rebuffers - does it try
to buffer more this time
>>>
>>> Is there an existing doc that explains this ?
If not could someone 
>>> give some info.
>>>
>>> We'd also like to know if there are any
HELIX_FEATURES that can be 
>>> used to adjust the buffering behaviour.
>>
>> John, let me know if you have any questions after
reading
>> this:
>>
>> https://client.helixcommunity.org/2006/devdocs/buffering

>>
>> --greg.

_______________________________________________
Helix-client-dev mailing list
Helix-client-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinf
o/helix-client-dev

Greg Wright wrote:

> jsreciva.com wrote:
>
>> Thanks, that explains most of it.
>>
>> Some questions:
>>
>> Miscrosoft servers have support for accelerated
buffering at the 
>> start of a stream where they send out about 12
seconds worth of data 
>> immediately before streaming at normal speed. Is
there an equivalent 
>> scheme for Real servers ? If so, how much data is
available ? I 
>> suspect there must be something along these lines
as most Real 
>> streams do tend to start up pretty quickly for us.
>
>
> TurboPlay is what we call it. We try to get the
'preroll' data just
> as fast as the connection will allow it. It is
controlled via the
> 'TurboPlay' preference. You will also see it referred
to sometimes
> as quickstart or faststart in the code. If you are
seeing slow starts
> make sure you don't have it turned off in a mobile
profile or something.

I'm pretty sure that is turned on as most real streams start
very 
quickly (2-3 seconds).

Is there any preference to request more than the preroll
data ? eg 
always get 15 seconds worth of data before starting
playback. It would 
be nice to experiment with this sort of thing to see if it
improves things.

As far as I can tell we'd expect to see our device perform
as well as 
Real Player on a windows machine in terms of initial 
buffering/rebuffering etc. Is that what you'd expect ? We're
running 
cayenne_1_5_0 - what version of PC real player does that
correspond to ?

>
>
>
>>
>> The example for initial buffering says that it
buffers about 4 
>> seconds before starting playback. Then each time it
rebuffers it will 
>> add an extra second up to a limit of 10 seconds. Is
there any way to 
>> adjust the initial buffering amount via a
preference ? If so, how 
>> would that affect real initial buffering time.
>
>
> That must be an old document then. Well, it still
applies to all
> branches except 150Cay, HEAD and 310Atlas. Those 3
branches are
> new and we made lots of changes to reduce the amount of
buffering
> done. We only buffer the minimum data now needed to
start playback.
> We also do not increase the buffering by 1 sec each
time a rebuffer
> happens (I am pretty sure thats gone, I will go
check).
>
>>
>> Assuming the core runs out of data and it needs to
rebuffer (say 5 
>> seconds worth of data), will this always take at
least 5 seconds ? Or 
>> is there some sort of accelerated rebuffering
scheme ?
>
>
> With turboplay we will get that data just as fast as we
can. So,
> the time it takes to get 5 seconds of data depends on
the
> combination of the connection bandwidth, clip bit-rate
and quality
> of the connection(lost packets, etc). Sometimes
turboplay can
> be turned off if really poor conditions are detected.
You should
> check this if you see slow rebuffers. The idea behind
turning it
> off is that it may be what is causing the quality
issues. However,
> I have found that those tend to be transitory and
turning off
> turboplay due to rebuffers is kind of a pain. Although,
I have not
> tried to check in changes to change that.
>
>>
>> Can you give some details on what happens during
http:// streaming (I 
>> presume the example given is for Real Audio via
rtsp://)
>
>
> HTTP is just TCP download and play. So TCP will control
the rate of 
> delivery
> of the bits. TCP will do it just as fast as it can.
>
> --greg.
>
>
>>
>> John
>>
>>
>>
>> ----- Original Message ----- From: "Greg
Wright" <gwrightreal.com>
>> To: "John Stirling" <jsreciva.com>
>> Cc: <helix-client-devhelixcommunity.org>
>> Sent: Monday, October 29, 2007 6:47 PM
>> Subject: Re: [Helix-client-dev] helix buffering
>>
>>
>>> John Stirling wrote:
>>>
>>>> We're being pushed to give details on helix
buffering schemes by 
>>>> one of our customers.
>>>>
>>>> I guess the answer is complicated and will
depend on various 
>>>> options - helix feature defines,  server
type, protocol etc.
>>>>
>>>> I think they basically want to know this
sort of thing:
>>>> . how much gets buffered at start of
stream
>>>> . what happens when it rebuffers - does it
try to buffer more this 
>>>> time
>>>>
>>>> Is there an existing doc that explains this
? If not could someone 
>>>> give some info.
>>>>
>>>> We'd also like to know if there are any
HELIX_FEATURES that can be 
>>>> used to adjust the buffering behaviour.
>>>
>>>
>>> John, let me know if you have any questions
after reading
>>> this:
>>>
>>> https://client.helixcommunity.org/2006/devdocs/buffering

>>>
>>> --greg.
>>


_______________________________________________
Helix-client-dev mailing list
Helix-client-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinf
o/helix-client-dev

John Stirling wrote:
> Greg Wright wrote:
> 
>> jsreciva.com wrote:
>>
>>> Thanks, that explains most of it.
>>>
>>> Some questions:
>>>
>>> Miscrosoft servers have support for accelerated
buffering at the 
>>> start of a stream where they send out about 12
seconds worth of data 
>>> immediately before streaming at normal speed.
Is there an equivalent 
>>> scheme for Real servers ? If so, how much data
is available ? I 
>>> suspect there must be something along these
lines as most Real 
>>> streams do tend to start up pretty quickly for
us.
>>
>>
>> TurboPlay is what we call it. We try to get the
'preroll' data just
>> as fast as the connection will allow it. It is
controlled via the
>> 'TurboPlay' preference. You will also see it
referred to sometimes
>> as quickstart or faststart in the code. If you are
seeing slow starts
>> make sure you don't have it turned off in a mobile
profile or something.
> 
> I'm pretty sure that is turned on as most real streams
start very 
> quickly (2-3 seconds).

The way to make sure it to capture the RTSP chat and see if
the
SetDeliveryBandwidth option is about 4x the clips bitrate.
You
can do that via tcpdump or breakpoints or whatever.

> 
> Is there any preference to request more than the
preroll data ? eg 
> always get 15 seconds worth of data before starting
playback. It would 
> be nice to experiment with this sort of thing to see if
it improves things.

Take a look in client/audiosvc/hxaudses.cpp:

         ReadPrefUINT32(m_pPreferences,
"TargetAudioPushdown", m_ulTargetPushdown);
	ReadPrefUINT32(m_pPreferences,
"MinimumAudioPushdown", m_ulMinimumPushdown);
         ReadPrefUINT32(m_pPreferences,
"MinimumAudioStartupPushdown",
m_ulMinimumStartupPushdown);
	ReadPrefUINT32(m_pPreferences,
"MaxBlocksToPlayPerGranule",
m_ulMaxBlocksToPlayPerGranule);
         ReadPrefUINT32(m_pPreferences,
"CheckAudioPct", m_nPercentage);

You can play with those. Inspect that one file (and .h) to
see how
they are used. Also, look at the comment in the .h:

// These defines control how much audio PCM data we push
down into the
// audio device. MINIMUM_AUDIO_STARTUP_PUSHDOWN determines
how much we
// push before calling Resume() on the device (and starting
playback)
// and MINIMUM_AUDIO_PUSHDOWN determines how much PCM data
we push
// down during steady state playback. It is also important
that the
// granularity be less then or equal to
MINIMUM_AUDIO_PUSHDOWN/2. If
// not, underflows could result because only 1 block will be
in the
// audio device at any given time. Currently
MINIMUM_AUDIO_GRANULARITY
// is not used. In CHXAudioPlayer::Setup() hardcodes this:
//
//     m_ulGranularity = MAXIMUM_AUDIO_GRANULARITY;
//
// The CHECK_AUDIO_INTERVAL define tells the audio session
how often
// to check how much data we have pushed down in the audio
device.
// for min heap builds it is more important to check often
because we
// have very few blocks pushed down at any one time. The
value for
// this define is a percentage (0-100) of the granularity
in
// milliseconds. IE, 40 means 40% of whatever granulatiry is
in use.
//
#ifdef HELIX_CONFIG_MIN_PCM_PUSHDOWN_BYTES
#  define MINIMUM_AUDIO_GRANULARITY       50
#  define MAXIMUM_AUDIO_GRANULARITY      
MINIMUM_AUDIO_GRANULARITY
#  define TARGET_AUDIO_PUSHDOWN           200
#  define MINIMUM_AUDIO_STARTUP_PUSHDOWN  150
#  define MINIMUM_AUDIO_PUSHDOWN          100
#  define CHECK_AUDIO_INTERVAL            40	// percentage
of granularity
#else
#  define MINIMUM_AUDIO_GRANULARITY       50
#  define MAXIMUM_AUDIO_GRANULARITY       50
#  define TARGET_AUDIO_PUSHDOWN           1000
#  define MINIMUM_AUDIO_STARTUP_PUSHDOWN  150
#  define MINIMUM_AUDIO_PUSHDOWN          100
#  define CHECK_AUDIO_INTERVAL            60	// percentage
of granularity
#endif

#ifdef HELIX_CONFIG_SYMBIAN_PCM_PUSHDOWN_BYTES
#  define MINIMUM_AUDIO_PUSHDOWN  200
#endif

> 
> As far as I can tell we'd expect to see our device
perform as well as 
> Real Player on a windows machine in terms of initial 
> buffering/rebuffering etc. Is that what you'd expect ?
We're running 
> cayenne_1_5_0 - what version of PC real player does
that correspond to ?

The latest RP11 beta that is out uses 150Cay. It is the
first RP to
use that branch.

I would fully expect your player and RP11 to have the same
startup performance given the same CPU and internet
connection.

--greg.

> 
>>
>>
>>
>>>
>>> The example for initial buffering says that it
buffers about 4 
>>> seconds before starting playback. Then each
time it rebuffers it will 
>>> add an extra second up to a limit of 10
seconds. Is there any way to 
>>> adjust the initial buffering amount via a
preference ? If so, how 
>>> would that affect real initial buffering time.
>>
>>
>> That must be an old document then. Well, it still
applies to all
>> branches except 150Cay, HEAD and 310Atlas. Those 3
branches are
>> new and we made lots of changes to reduce the
amount of buffering
>> done. We only buffer the minimum data now needed to
start playback.
>> We also do not increase the buffering by 1 sec each
time a rebuffer
>> happens (I am pretty sure thats gone, I will go
check).
>>
>>>
>>> Assuming the core runs out of data and it needs
to rebuffer (say 5 
>>> seconds worth of data), will this always take
at least 5 seconds ? Or 
>>> is there some sort of accelerated rebuffering
scheme ?
>>
>>
>> With turboplay we will get that data just as fast
as we can. So,
>> the time it takes to get 5 seconds of data depends
on the
>> combination of the connection bandwidth, clip
bit-rate and quality
>> of the connection(lost packets, etc). Sometimes
turboplay can
>> be turned off if really poor conditions are
detected. You should
>> check this if you see slow rebuffers. The idea
behind turning it
>> off is that it may be what is causing the quality
issues. However,
>> I have found that those tend to be transitory and
turning off
>> turboplay due to rebuffers is kind of a pain.
Although, I have not
>> tried to check in changes to change that.
>>
>>>
>>> Can you give some details on what happens
during http:// streaming (I 
>>> presume the example given is for Real Audio via
rtsp://)
>>
>>
>> HTTP is just TCP download and play. So TCP will
control the rate of 
>> delivery
>> of the bits. TCP will do it just as fast as it
can.
>>
>> --greg.
>>
>>
>>>
>>> John
>>>
>>>
>>>
>>> ----- Original Message ----- From: "Greg
Wright" <gwrightreal.com>
>>> To: "John Stirling" <jsreciva.com>
>>> Cc: <helix-client-devhelixcommunity.org>
>>> Sent: Monday, October 29, 2007 6:47 PM
>>> Subject: Re: [Helix-client-dev] helix
buffering
>>>
>>>
>>>> John Stirling wrote:
>>>>
>>>>> We're being pushed to give details on
helix buffering schemes by 
>>>>> one of our customers.
>>>>>
>>>>> I guess the answer is complicated and
will depend on various 
>>>>> options - helix feature defines, 
server type, protocol etc.
>>>>>
>>>>> I think they basically want to know
this sort of thing:
>>>>> . how much gets buffered at start of
stream
>>>>> . what happens when it rebuffers - does
it try to buffer more this 
>>>>> time
>>>>>
>>>>> Is there an existing doc that explains
this ? If not could someone 
>>>>> give some info.
>>>>>
>>>>> We'd also like to know if there are any
HELIX_FEATURES that can be 
>>>>> used to adjust the buffering
behaviour.
>>>>
>>>>
>>>> John, let me know if you have any questions
after reading
>>>> this:
>>>>
>>>> https://client.helixcommunity.org/2006/devdocs/buffering

>>>>
>>>> --greg.
>>>
> 


_______________________________________________
Helix-client-dev mailing list
Helix-client-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinf
o/helix-client-dev

>
>
>>
>> As far as I can tell we'd expect to see our device
perform as well as 
>> Real Player on a windows machine in terms of
initial 
>> buffering/rebuffering etc. Is that what you'd
expect ? We're running 
>> cayenne_1_5_0 - what version of PC real player does
that correspond to ?
>
>
> The latest RP11 beta that is out uses 150Cay. It is the
first RP to
> use that branch.
>
> I would fully expect your player and RP11 to have the
same
> startup performance given the same CPU and internet
connection.
>
> --greg.
>

We're mainly interested in arm-linux
(hxclient-client-audio-all-fixpt). 
Is there anything in there that would make us perform worse
than Real 
Player on Windows ?

We haven't done any side by side comparisons yet - just
getting some 
general feedback (which could be bogus) that our
buffering/rebuffering 
performance is worse than on a PC.




_______________________________________________
Helix-client-dev mailing list
Helix-client-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinf
o/helix-client-dev