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

[Andy Furniss]

Reimar Döffinger wrote:
> 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.

Is the fix OK go in then?