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

Thomas Orgis thomas-forum at orgis.org
Thu Jul 25 01:16:07 CEST 2013


Am Wed, 24 Jul 2013 22:33:56 +0200
schrieb Reimar Döffinger <Reimar.Doeffinger at gmx.de>: 

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

Because of that, mpg123 itself plays that as well;-)

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

So, if I interpret that correctly, we can skip fixing the possible
output format (rate, channels, etc) in ad_mpg123 and just change
sh->samplerate and sh->channels accordingly, right during decoding?
That simplifies things, even.

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

Right, that's why I thought MPlayer would stop decoding on getting the
error message, or try a fresh init of ad_mpg123.

> Now the right solution would be to just call resync to make it reopen again

With format changes allowed, libmpg123 will just continue on its own
without reopening. I'll sometime implement the fix to discard frames
with disallowed format to begin with in libmpg123, but first will fix
ad_mpg123 to handle mp3s with changing format.

Thanks for clearing that up ... and please tell me quickly if I'm wrong
about indicating format changes in decode_audio().


Alrighty then,

Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20130725/79c03ebd/attachment.asc>


More information about the MPlayer-dev-eng mailing list