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

[Reimar Döffinger]

On 23.07.2013, at 13:19, Thomas Orgis <thomas-forum at orgis.org> wrote:
> Am Wed, 17 Jul 2013 20:33:55 +0200
> schrieb Reimar Döffinger <Reimar.Doeffinger at gmx.de>: 
> 
>> Since there is no logic to try and open it again,
>> its only effect will be that MPlayer is permanently
>> stuck in an error state.
>> With some libmpg123 versions it even seems to cause a
>> crash, see bugzilla #2149.
> 
> 
> The mpg123 console app can change output format on-the-fly; I guess
> MPlayer doesn't want to enter that territory? Especially considering
> that in reality, we are talking about damaged streams as I don't see
> folks putting mixed sampling rate material into one (video) stream on
> purpose, except just to mess things up.

First, it is not that uncommon for people to just concatenate mp3 files, so it's not in fact necessarily an error if sample rate changes.
Second, MPlayer has no problem with sample rate changing, I don't remember the details but it should work fine when e.g. using FFmpeg decoders.
This all is quite independent of the pure code logic issue: nothing good can come of just closing the input and then continue to try to decode stuff.
Now the right solution would be to just call resync to make it reopen again, however since resync calls decode without special hacks I didn't feel like implementing this can result in an endless loop, which would be making things worse.