2008/1/20, Burkhard Plaum <[EMAIL PROTECTED]>: > The main weakness of the frei0r and other filter APIs is, that they > are strictly synchronous i.e. one frame in, one frame out. > > This brings 2 important restrictions: > > - It's impossible to convert frames in-place
This would be trivial to add, it's mostly a matter of adding another flag and one more update prototype, or just reusing an existing prototype. btw. do you have any code readily available that would justify such an extension of the spec. I think that the spec should only be extended when there is actual code that would benefit from that feature IMMEDIATLY. But as always, this is only my opinion. :-) > - It's impossible to write filters, which convert the framerate > (e.g. like a framerate doubling deinterlacer would do) Indeed, and there are a couple of other deficiencies that I know of, for example it is not possible to have a different input format and output format, for example: I would like to send a 32bit per pixel image to the filter and get an 8bit per pixel luminance map back. Or I would like to have an arbitrary number of input channels and output channels. but this is all not in the specification. It doesn't matter that much however, because even without those features, frei0r serves a PURPOSE. And in my opinion an important one. It is EASY to add support for frei0r to an application. And it is EASY to write frei0r plugins. Frei0r is a playground that is fun to play on, because the barrier to entry is so low. If a plugin spec would require me to change my application, than it would have to provide much more value and much cooler plugins for me to consider its adoption. There would be the alternative to provide specs to profiles, or subsets of frei0r that are easy to implement, and then say: "If you only implement frei0r subset XYZ, you can get away with coding only very little". But I think that would "dilute" the Frei0r Brand (haha, I am using marketing talk here ;-) ) that says "Frei0r is easy". ;-) Anyways, I think it is easier to communicate TWO (or eventually more) different "Brands" of plugins, one for the easy stuff and the lazy hackers that just want something that works, and another one for those that want the features-galore, ahm, I mean for the _serious_ stuff. ;-) I was thinking about creating "Float0r", as a reference to Frei0r, and while hinting on the possiblity of operating on Float-based colorspaces, but it could also be Gmerlin Plugins or something else. Btw. there have been a number of attempts of creating a floss video plugin standard, with, well, varying scope and success. Cheers -Richard _______________________________________________ Cinelerra mailing list [email protected] https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
