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

[Collins, Diarmuid]

Hi Reimar

 I used the -benchmark option and that worked for me. Thanks very much

 According to the man page 
"NOTE: With this option MPlayer will also ignore frame duration when playing only video (you can think of that as infinite fps)."

Is this what is fixing the latency for me? I'm curious as to what the -benchmark does that is correcting the issue

Diarmuid



-----Original Message-----
From: Reimar Döffinger [mailto:Reimar.Doeffinger at gmx.de] 
Sent: 15 October 2013 19:02
To: mplayer-dev-eng at mplayerhq.hu
Subject: Re: [MPlayer-dev-eng] Possible bug when sample rate changes mid-stream

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).

_______________________________________________________________________
This e-mail and any files transmitted with it are proprietary and intended solely for the use of the individual or entity to whom they are addressed. If you have reason to believe that you have received this e-mail in error, please notify the sender and destroy this email and any attached files. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the Curtiss-Wright Corporation or any of its subsidiaries.  Documents attached hereto may contain technology subject to government export regulations. Recipient is solely responsible for ensuring that any re-export, transfer or disclosure of this information is in accordance with applicable government export regulations.  The recipient should check this e-mail and any attachments for the presence of viruses. Curtiss-Wright Corporation and its subsidiaries accept no liability for any damage caused by any virus transmitted by this e-mail.