[FFmpeg-devel] libavfilter-soc: select and snapshot filters

Michael Niedermayer michaelni
Fri May 29 00:27:02 CEST 2009


On Thu, May 28, 2009 at 07:13:43PM +0200, Vitor Sessak wrote:
> Michael Niedermayer wrote:
>> On Thu, May 28, 2009 at 01:07:45AM +0200, Stefano Sabatini wrote:
>>> Hi,
>>> both as a backup and for fostering comments.
>>>
>>> Use them for example with:
>>>
>>> ffplay in.avi  -vfilters "split [out] [select], [select] 
>>> select='eq(mod(N, 10), 0)', snapshot=snap%03d.png"
>>>
>>> This patch requires the avfilter_graph_config_links() patch which I
>>> posted yesterday.
>>>
>>> BTW, I don't think it is a good idea to commit to the SVN soc all
>>> these filters, API will likely still change and we should avoid to
>>> complicate the integration, but I believe it would be useful to start
>>> to collect the interesting filters somewhere (in the wiki?).
>> did it maybe cross your mind that it would make sense to try to get
>> filters into ffmpeg svn?
>
> At least for me it is a great idea, but quoting what you said in the thread 
> "[PATCH] Add vf_scale.c filter"
>
>> first quick question
>> does
>> crop, expand and slices work? (a single pix_fmt working is enough)
>
> If you do not accept vf_scale.c without an expand filter been done first, I 
> concluded that you won't accept _any_ filter for main SVN before that.

i think the expand filter is critical, and i ATM dont understand what the
problem is with implementing it
The one in mplayer is less than 500 lines


>
> If it is acceptable, it would be great having all those filters users are 
> submitting (vf_overlay.c improvements, alpha channel filling, applyfn, etc) 
> all been reviewed ASAP to main SVN while their original author is still 
> around.

Iam very much affraid that we would end with a worse mess quicker than
libmpcodecs

I think the highest priority currently goes to the memcpy less expand,
immedeatly after that the next highest priority goes to a regression test
that tests each filter with all kinds of buffer types. One of the big
failures of libmpcodecs is that there are corner cases that fail and
to avoid that from the start we absolutely need a fast and complete self
test.
the 3rd, or maybe its the 1st :) point is documentation, the API must be
documented much more verbosely, which filter when does call what, how
do the buffers permissions, direct rendering slices and all that interact
at a high level, ...

After these we can start adding filters.
Thats of course not some cast in stone set of rules now, its just a
suggested roadmap for the near future of libavfilter.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
-------------- 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-devel/attachments/20090529/8f3d2ec4/attachment.pgp>



More information about the ffmpeg-devel mailing list