[vlc-devel] Re: recent resamplling changes

[Damien Fouilleul]

Gildas Bazin wrote:

>On Sunday 24 October 2004 23:33, Derk-Jan Hartman wrote:
>  
>
>>The recent changes to resampling are turning out to have some serious 
>>downsides. Especially mms, shoutcast and aacplus http streams seem to 
>>have serious audio drift and later on PTS out of range issues. 
>>Sometimes it catches up, sometimes not.
>>
>>http://somafm.com/aac/
>>
>>I suggest to go somewhere between the test1 and svn treshold of the 
>>resampling, because this is a bit over the top.
>>
>>    
>>
>
>The problem with the aac stream isn't related to resampling.
>
>The problem happened just after the change that considered shoutcast streams 
>as non-pace controlable (which should be the case as these streams are live 
>streams).
>However shoutcast servers don't seem to really send the stream in real-time 
>(at least not at the beginning). They seem to be caching about 5 seconds of 
>audio before starting streaming and will send these 5 seconds as fast as 
>the client can read them and only when the buffer is empty they'll send the 
>data at real-time rate.
>
>This does screw up the clock adjustment algo in VLC quite badly.
>So if anybody has a solution for this, I'm a taker (not involving rewriting 
>the whole clock algo just before the 0.8.0 release of course ;).
>
>--
>Gildas
>
>  
>
Gildas,

my 2 cents worth,

I think you should revert the last change you've made to 
audio_output/input.c (the one regarding clearing the buffer when the 
drift is too important)
IMHO, the player was working reasonnably OK before that change (mmsh, 
shoutcast, etc...).
I 've set the access_mms/http buffer to 5000 ms, and this seems to get 
around most of the problems you've described, maybe you should set this 
value as default for 0.8.0.

Damien


-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html