[MPlayer-dev-eng] Possible bug when sample rate changes mid-stream

[Reimar Döffinger]

On Tue, Oct 15, 2013 at 01:21:44PM +0200, Paul Kelly wrote:
> Hello again,
> 
> Paul Kelly wrote:
> >Hello mplayer developers,
> >I am experiencing a problem with mplayer when playing MP3 audio in which
> >the sample rate changes during playback. The problem shows itself in
> >particular with some internet radio stations which change from 22050 Hz
> >to 44100 Hz mid-stream without any interruption - mplayer will play such
> >a stream at half speed after the change.
> 
> A week later and no replies; I am assuming that this is some old can
> of worms-type bug that nobody really wants to look at.

Well, it's rather that I have been on holiday.

> The log message for that commit is:
> > Trust the demuxer instead of the decoder for samplerate detection.
> > Fixes the ffmp3_bad_rate_detection.avi sample.
> > patch by qwen dux qwendu__at__gmail__.__com
> which sounds quite suspicious to me. Why should we trust the demuxer
> over the decoder? It seems rather an arbitrary decision.

Not really, the demuxer generally is more reliable, which is related
to the fact that the container sample rate is much easier to adjust
by end-users, and some audio codecs officially only support a few
select sample rates, so to use them for different sample rates the
container must be able to override the codec value.
Where the problem for MP3 came in is when the MP3 demuxer was changed
to export the sample rate of basically the first few frames as
the "container" sample rate, which is kind of nonsense but gives
nicer -identify printout.
There is actually a tried solution to this issue in vd_ffmpeg
for handling aspect changes: Use the container value first,
but if there is a change switch to the code value.
This works for both cases (though it might not work 100%
with seeking, so it kind of might be useful if the demuxer
marked if its sample rate value is reliable or not, in case
of the MP3 demuxer it most certainly is not).