Re: Buffering in the Helix Client

Mahmoud Hammoud wrote:
> Dear Greg,
>  
> I am writing you directly because I didnt really get meaningful answers 
> the last time I tried the mailing list, and my problem is really 
> urgent, so I appreciate your understanding and you taking time to answer 
> me. I am using the hxclient_1_5_0_cayenne branch (Profile 
> helix-client-all-defines, SYSTEM_ID = win32-i386-vc6), and I am trying 
> to implement a way of controlling the amount of buffering to be done by 
> the client based on external measurements (independent of the state of 
> the player, or the congestion/connection quality it experiences). For 
> example I would like to be able to pass a "prediction" (supposedly 
> obtained from an outside module that interfaces with the Helix core) 
> telling/forcing the core to buffer data for a certain amount of time 
> (say because we will experience bad connection quality soon). After 
> reading the "devdocs" related to buffering in the Helix client, and 
> thoroughly examining the corresponding parts of the code, some of my 
> issues remained unanswered and here is where I need your help:
>  
> 1) Rebuffering seems to be done only for audio streams (when accelerated 
> delivery doesnt make up for the data shortage). Where does the 
> rebuffering of video streams take place? Here I am making reference to 
> HXSource::ReportRebufferStatus which gets exclusively called by audio 
> renderes (so the else clause where DoRebuffer( ) is called for video 
> streams is somehow never executed).

We never rebuffer due to video. The idea is that the audio playback,
what the person is hearing at any given instant, is the master time
line. It drives everything else. So, it is imperative that we never
allow the audio to run dry or otherwise break up. This is why we
rebuffer the audio stream. For video, it is not as important. We have
chosen to go ahead and let the video drop frames (even back to showing
only key frames) as long as we can keep the audio from breaking up.

We could have equally well decided to rebuffer if we are unable to
keep the video playing well. However, given the history of where
and when the media engine was used, that is not a decision we made.

It would not be hard to change this (see client/audiosvc/*) behavior
and have rebuffering caused by video renderers as well. That would be
a valid choice in a lot of scenarios I would guess; where video has
to be shown with all frames or none at all.

> 2) When rebuffering is to be done for an audio stream, accelerated 
> packet delivery is stopped, and the chain DoRebufferIfNeeded( ) - 
> DoRebuffer( ) - ReBuffer( ) - m_pBufferManager->Rebuffer(preroll 
> increment). Is this accurate? Does this mean that rebuffering consists 
> of merely incrementing our preroll by a constant amount of time? Is 
> there some actual buffering of the media packets that I am not seeing 
> here? I appreciate it if you would point it out to me.

If we encounter a rebuffering event we assume that the connection is
not that good and that rebuffering more data will help keep the
amount of rebuffers down. So, that is why you see an increment there.
This increment only goes up to some maximum value. It is easy to
change how much, if any, of an increment you get.

Rebuffering itself is just the act of pausing playback until we have
satisfied all the pre-roll requirements of each renderer in the
playback chain. This includes any *extra* we have added (above).

> 3) If a simple solution to my initial problem description comes to your 
> mind, please be kind to provide me with your valuable thoughts.

If you can somehow detect impending degradation of the connection
ahead of time, then I would just look at accelerating delivery of
the packets from the server. You can ask the server to send you
data at just about any rate. We start off very fast (to fulfill
the pre-roll as fast as we can) and then change it to just about
the clip bit-rate. If the engine senses the data getting low it
will tell the server to increase the rate. This applies only to
client side rate control. If the connection is using server side
rate control then you really can't do anything except maybe lie
to the server about how much data you have.

--greg.

Adding helix-client-dev, please keep all discussion on a helix
list. If you want you can always email and point me to a
discussion, but I don't have that much time right now and emails
directed only to me may not get answered.



>  
> Best Regards,
>  
> Mahmoud Hammoud


_______________________________________________
Helix-client-dev mailing list
[email protected]
http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev