Hi On Sat, Aug 18, 2007 at 12:12:08PM -0400, Bobby Bingham wrote: > 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.
its probably ok (i cant think of a case where a filter would want 2 inputs with differing colorspace) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable
signature.asc
Description: Digital signature
_______________________________________________ FFmpeg-soc mailing list [email protected] http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
