Re: trying mp_image -> get/release_buffer migration...

    Hi, D Richard Felker III!

Sometime (on Wednesday, May 28 at 23:17) I've received something...
>>     Another question is if we will allow mixing video. It will be very
>> big advantage to have more that one input stream for filter. So I think
>> while you already will change vf_instance_t then you can add some new
>> function vf_reopen_filter(). I'll try to describe it. If filter can have
>> _only_ one input stream then all is as it is now and vf->prev contains
>> previous vf and vf_reopen_filter() will work exactly as vf_open_filter().
>> If filter can support more than one input stream then it on open() will
>> remove vf->prev into internal structure and set vf->prev to NULL. Then
>> next call of function vf_reopen_filter() will check it and return error
>> if that pointer is no-NULL. So for filter with only one input stream that
>> vf_reopen_filter() will call vf->open() only once and for filter with
>> more streams it may be called as much as filter allows. I hope that
>> solution is good and fully compatible with all current implementation.
>> That have also another advantage - it allows as to build concurrent OSD
>> just as filter module not another layer that will mix video and OSD
>> inputs. :)

>That's a slow and nonsensical way to do OSD... Yes, we want
>multi-input support, but I don't think multiple opens makes any sense.
>If anything, multiple config, once for each source, but open should be
>called only once.

    I've proposed it to avoid changes as much as possible. Another way
will bring changes in vf_instance_t structure. Beside of that, even multi
vf->open() call are good if it's documented well. Don't forget that some
GUI may want add input stream in already created chain (so vf->open() was
already called) instead of saving parameters, destroying all chain and
recreating it with new source for that filter.
    Anyway, if you have another solution - please, give it to us here. :)

    With best wishes.
    Andriy.