[MPlayer-dev-eng] [PATCH] Do not close feed in the middle of decoding.

[Reimar Döffinger]

On Thu, Jul 25, 2013 at 12:30:29PM +0200, Thomas Orgis wrote:
> Am Thu, 25 Jul 2013 08:33:01 +0200
> schrieb Reimar Döffinger <Reimar.Doeffinger at gmx.de>: 
> 
> > On 25.07.2013, at 01:16, Thomas Orgis <thomas-forum at orgis.org> wrote:
> > > just change
> > > sh->samplerate and sh->channels accordingly, right during decoding?
> > 
> > I think so, but look at ad_ffmpeg if it does something special like calling a reinit function.
> > Video decoders need to do that, but I think for audio it is all automatic.
> 
> Funny that this indeed works for a quickly hacked ad_mpg123 using
> http://mpg123.org/test/44and22.mp3 and it does _not_ work with
> ad_ffmpeg, apparently (-ac ffmp3), like I mentioned on bugzilla #2149.

That is kind of intentional, but I'd need to check the history.
Basically the issue is that there are quite a few files where the
container (e.g. mov) and the audio stream inside have a sample,
and they differ. In that case the container one should be used
- at least in most cases.
Now, for raw MP3 that doesn't make sense since there is no
"container", this probably was broken when the MP3 demuxer
started exporting a sample rate on its own.
I'm not sure what the right solution is, earlier I think the
code tried to use the container rate, but only until a sample
rate change, but this obviously was broken for some case and
the code was changed to what it is now because of that...

> When my question about how to deal with exceptional error
> situations (see the bug comment) is answered, I'll submit a proper
> patch.

Well, ideally you'd move handling them all into the init function.
That means that MPlayer can even fall back to a different decoder
in that case.
But assuming it works, I guess setting stream EOF is ok as well,
if it's sure we'll not get any useful output anymore.