[vlc-devel] Re: recent resamplling changes
damien.fouilleul at laposte.net
Tue Oct 26 11:36:57 CEST 2004
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.
>>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
>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 ;).
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,
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.
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html
More information about the vlc-devel