[MPlayer-dev-eng] [PATCH] New commands for loading/unloading audio filters at runtime

[Jehan Pagès]

Hi again,

2010/4/11 Jehan Pagès <jehan.marmottard at gmail.com>:
> Hi,
>
> On Sun, Apr 11, 2010 at 8:54 PM, Reimar Döffinger
> <Reimar.Doeffinger at gmx.de> wrote:
>>> Index: libaf/af.c
>>> ===================================================================
>>> --- libaf/af.c        (révision 31027)
>>> +++ libaf/af.c        (copie de travail)
>>> @@ -537,8 +537,9 @@
>>>    // Reinitalize the filter list
>>>    if(AF_OK != af_reinit(s, s->first) ||
>>>       AF_OK != fixup_output_format(s)){
>>> -    free(new);
>>> -    return NULL;
>>> +      mp_msg(MSGT_AFILTER, MSGL_WARN, "[libaf] Adding filter %s failed.\n", new->info->name);
>>> +      af_remove(s, new); // no need to free new, af_remove takes care of this.
>>> +      return NULL;
>>
>> The previous reinit or fixup_output_format may have broken some things,
>> I'd expect you'd have to run them once more (though I haven't checked the
>> code).
>
> I guess you are right, at least in the general case (in a simple run
> test, I did not see obvious issue).
>
> But what should be the reaction if while running it again, it fails
> (though I guess it shouldn't considering we have put this back to
> normal, let's not make assumptions into what could possibly go wrong)?
> Should we deactivate the sound? I am not sure how to do such a thing
> from inside this function. We can completely uninit the whole filter
> chain — which implies freeing it from all its filters — then reinit
> it. Yet except from this, as we don't have access to the mplayer
> context from the libaf library, I don't see how to deactivate sound.
> What do you think?
>
> Jehan
>

I made it this way then. So after removing the filter, I run again the
filter list's initialization, and output format initialization
functions, and if it fails again (though this time, it should not), I
init a brand new filter list with a warning.
Is that ok?

Jehan