[FFmpeg-soc] libavfilter review
Michael Niedermayer
michaelni at gmx.at
Sun Aug 19 21:08:51 CEST 2007
Hi
On Sun, Aug 19, 2007 at 12:36:15PM -0400, Bobby Bingham wrote:
> On Sat, 18 Aug 2007 19:22:38 +0200
> Michael Niedermayer <michaelni at gmx.at> wrote:
>
> > 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 <michaelni at gmx.at> 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)
> >
>
> Unfortunately, I thought of a case. The filtergraph filter, being
> simply a composite of various subfilters, may legitimately have inputs
> with multiple colorspaces. And doing so may optimize the number of
> conversions.
>
> I'm afraid the more I look at the problem, the more I realize it's not
> something I can come up with a good solution to by Monday. I think
> I'll add support for autoconversion to the current system so that it at
> least works in all cases, and I'll have to work on a better system
> after the end of summer of code, because there are enough other areas I
> can actually make improvements on before the deadline if I don't get
> hung up on this one thing.
ok
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Democracy is the form of government in which you can choose your dictator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/attachments/20070819/557a967b/attachment.pgp>
More information about the FFmpeg-soc
mailing list