[MPlayer-dev-eng] [PATCH] New slave command for loading video filters at runtime

Jehan Pagès jehan.marmottard at gmail.com
Sat Apr 3 20:32:07 CEST 2010


Hi,

On Sun, Apr 4, 2010 at 2:51 AM, Reimar Döffinger
<Reimar.Doeffinger at gmx.de> wrote:
> I think that generally just can't work, at least not as simple as that.
> The problem is the buffer management: Any filter might allocate a buffer
> on its own, it might pass on a internal buffer to the following filter
> or it might just pass through a buffer that comes from a filter after
> it or even from the VO (e.g. video RAM), it might add its own restrictions
> (e.g. no following filter including the VO may modify it).

Yet my few tests worked. Or do you mean that it may work or not work
depending on the filter and how each one of them manages its buffer?
So I just got lucky to test with the right (or the wrong, depends on
how you see it ;-) ) filters?

Would you have a filter on your mind with such a buffer management
that you think my patch would fail with, so that I can test this?
Because really I didn't try on a lot of filter for now indeed, but my
different tests worked (in fact I have a case of failure because there
are two ways of passing arguments. Apparently some video filters needs
it the _oldargs_ way, only one I have implemented right now, and some
need another processing... but this is a different issue and I was
going to work on it).

> I think the only thing you can do is to destroy the whole filter chain
> completely and build a new on from scratch, similar to what happens
> on resolution changes.
> Note that in some ways this may be better for audio as well, since af_add
> e.g. has a known issue that it might end up doing needless format
> conversions since an already loaded filter can not switch to processing
> a different audio format.

I may try to find the code of resolution change to try and copy it
then. But I will wait for your answer to my above questions first.
Because I prefer to be sure that my current simple code is really
indeed wrong in the general case before going into a more complicated
and deeper solution.
Bye.

Jehan



More information about the MPlayer-dev-eng mailing list