[MPlayer-users] Crash with -ao jack when channel layout changes in a broadcast aac/latm stream

Reimar Döffinger Reimar.Doeffinger at gmx.de
Wed Dec 11 22:11:23 CET 2013


On Wed, Dec 11, 2013 at 09:44:14PM +0100, Ingo Brückl wrote:
> Reimar Döffinger wrote on Wed, 11 Dec 2013 20:41:25 +0100:
> 
> > I am not sure it will fix the reason for the crash (that seems partially
> > unrelated), but below patch seems to avoid the issue by fully rebuilding
> > the filter chain.
> > Unfortunately it means that runtime-changes like volume etc. will
> > get lost every time.
> > Note that there might be an additional issue with FFmpeg not respecting
> > that only 2 channels were requested - I don't know if the AAC decoder
> > is supposed to respect that or not.
> > +++ b/mplayer.c
> > @@ -2218,6 +2218,9 @@ static int fill_audio_out_buffers(void)
> >      }
> >      if (format_change) {
> >          uninit_player(INITIALIZED_AO);
> > +        af_uninit(sh_audio->afilter);
> > +        free(sh_audio->afilter);
> > +        sh_audio->afilter = NULL;
> >          reinit_audio_chain();
> >      }
> >      return 1;
> 
> This may cause trouble with the GUI which will continue using a freed
> afilter. (It will be set for the GUI not until the build_afilter_chain()
> call in reinit_audio_chain().)
> 
> I'd hate to see a 4th GUI_SET_AFILTER call in mplayer.c though.
> 
> On the other hand, I'd rather like to eliminate guiInfo members sh_video and
> afilter anyway, and get them directly from mpcontext when needed.

Changing uninit_player to free the chain when uninitializing the AO
instead of ACODEC might work as well (or maybe more reliable, when
either).
However I don't actually see the issue anyway: the GUI runs in the same
thread, there should be no way the GUI could use its old value before
build_afilter_chain changes it.


More information about the MPlayer-users mailing list