On Fri, 17 Aug 2007 21:10:15 +0200 Michael Niedermayer <[EMAIL PROTECTED]> wrote:
> the query_formats system is very flexible, it takes a AVFilterLink > so a filter could have a fixed list of supported input pix_fmts and > make the output query_formats depend on the input pix_fmt or the > other was around well i dont think the other way around would work > but how should the user know that? > and whats the sense of this overly flexible system if it doesnt work > with anything but the obvious simple supported output pix_fmt depends > upon input formats, it would be alot clearer if query_formats would > take a list/array of input pix_fmts as argument (or a array or > pix_fmt, flags pairs) where the flags could indicate if the pix_fmt > can be provided without colorspace conversation, but maybe thats not > really usefull and a simpler prefer first possible format in the list > system would work equally well > > > also what happens in the following case: > src -> filter -> destination > > src supports formats A and C > destination supports formats B anc C > and the filter supports A,B,C inputs and output=input > > if i understood the code correctly this would fail > I think I've got an idea which will be less absurdly flexible, and will support graphs like your example without requiring conversion. The only thing is that I might need to set the restriction that all the inputs of a filter must always be operating on the same colorspace, and similar for outputs. This of course doesn't affect all those filters with only simple inputs and outputs. And I expect most filter authors would only support this case anyway. But before I start coding it, I want to check if such a restriction would be acceptable. -- Bobby Bingham Never trust atoms. Or anything made of atoms. このメールは再利用されたバイトでできている。 _______________________________________________ FFmpeg-soc mailing list [email protected] http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
