[MPlayer-dev-eng] [PATCH] fix for -srate bug

[Ed Wildgoose]

>>Would a patch to incorporate libsamplerate be acceptable?  We obviously
>>don't want a ton of sample rate convertors, and I would expect it to be
>>tricky to completely integrate libsamplerate (if we need to be able to
>>compile it on funny architectures for example), but I could make it a
>>compile time option to use the internal stuff or libsamplerate?
>>    
>>
>
>why, dont u just use the audio resample code from libavcodec ?
>it can easily be extended to support any linear filter, can compensate for 
>timestamp drift correctly (no ugly sounding duplicated/dropped samples) 
>  
>

Well my goal is very high end audio and video, comparable with 20K 
systems or more....  Libsamplerate seems to be the highest quality 
resampler out there, and most likely somewhat better than the libavcodec 
one (or the mplayer one).  And the CPU requirements are "sufficient" as 
well.  Also it is very nicely contained with a very simple api

I would not have thought that we would need to correct for timestamp 
drift in general if we are clocking video to audio?  What kind of things 
did you have in mind?


>u shouldnt compare against the MPlayer resampler, IIRC it has modulo, divide 
>and gotos in the innermost loop
>  
>

Sure, but isn't that yet another reason to consider a high quality, 
maintained alternative like libsamplerate?  I would suggest 
incorporating the code directly except that I think there is a fair bit 
of assembly and this might become a problem with a portable project like 
mplayer.  It would certainly be beyond my abilities to help porting it 
to all platforms (assuming it isn't supported already)

Just a thought anyway.  Happy to do the legwork on this, it's just that 
I dont think I really understand the mplayer architecture sufficiently 
well to do it completely unaided.

(Oh, and there is a good reason why I have to resample at all...)

Ed W