[FFmpeg-devel] lavfi state of affairs 3

[Stefano Sabatini]

On date Wednesday 2009-07-01 10:22:36 -0700, Baptiste Coudurier encoded:
> Hi Michael,
> 
> Michael Niedermayer wrote:
[...]
> > note, before you waste more of our both time, acceptable patches are either
> > 1. mechanical updates that is application of changes from ffmpeg svn that
> >    are not in soc yet.
> > 2. clean patches passing the full set of rules about clean patches 
> > 
> > In that sense i like to again mention, that lavfi should be moved into ffmpeg
> > svn quickly because it does become more painfull with time (now a merge
> > _requires_ support for changing width/height as well, a short while ago it
> > didnt but now it would be a feature regression)
> 
> Can you or someone else please state what needs to be done to finallly
> move lavfi into ffmpeg svn ? Maybe it would be possible to help.

Well, I tried to address some of the points listed here:
http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/85905

I'll try to resume here the main current issues.

|* Expand filter missing.
|
|  There is the need for an expand filter with "direct rendering", that
|  is which doens't require memcpy of any sort, this maybe requires API
|  extension:
|  http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/85015
|
|  MPlayer already has such a thing, so it may be worthwhile check that
|  code, in general is a good idea to check out all the filters in
|  MPlayer/libmpcodecs in order to avoid to waste time reinventing the
|  wheel.
|
|  Same considerations apply for the syntax, when possible is a good
|  idea to keep the same syntax (when sane) of the corresponding
|  MPlayer filters.
|
|  An implementation of an expand/pad filters has been already posted
|  on the soc ML:
|  http://thread.gmane.org/gmane.comp.video.ffmpeg.soc/2779/

I worked out a framework for argument passing to filters, and I
currently have a working implementation for such a pad filter:
http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/89945

The patch proposes a change in how the buffers are requested, they are
requested to the terminating filter, and allows direct rendering but
still doesn't implement it. Ideally the decoder should request a
buffer from the chain and write to it, rather than memcpy the buffered
frame to the buffer provided by the filterchain.

So the thread revealed this other two missing points:

* missing direct rendering

* need for a regression test covering some of the most common use case
  (cropping + padding + scaling). I posted an embryonal regression
  test for lavfi here:
  http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/92792 

  which is more a proof of concept, than I made some changes to the
  main repo regression tests and wanted to update the lavfi repo, and
  got stucked there.

|* vf_scale filter missing
|  This has to have the same features as the MPlayer's one, this should
|  be trivial.
|  See again:
|  http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/85015

I posted a patch for this, trying to implement all the libmpcodecs scale
filter features as requested by Michael, then we got stucked and I
focused on other problems:
http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/89378

|* A more powerful system for dealing with image formats is needed to
|  avoid bad code duplication. I mean some system to tell if a format
|  is for example packed, planar, the number of channels/planes and so
|  on, as discussed here:
|  http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/83733
|
|  and creates corresponding AVFilterFormats lists.
|
|  pixdesc.[ch] already committed in SVN may provide the foundations
|  for such a system (I intend to work on this).

The foundations of such a system (pixdesc.{h,c}) is already committed
in the main repo, altough disabled, some nice features of it (for
example av_get_bits_per_pixel()) should simplify writing filters.

|* Maybe a one-pixel colorspace transform, as discussed here:
|  http://thread.gmane.org/gmane.comp.video.ffmpeg.soc/5727/focus=5739
|
|  may avoid code duplication for all that filters that need to execute
|  YUV <-> RGB or some other transformation just for one color.
|
|  I'm not sure what's the better place for it, but lsws seems the
|  obvious choice.

There is some code for that already committed in
libavfilter/parseutils.c, but I don't believe this feature is anyway
blocking, after all whenever I needed to implement such a one pixel
transform I used the macros in libavcodec/colorspace.h, also the
libswscale soc taks may help here.

|* More documentation for the various filters, so that people don't
|  need for example to read the code in order to understand how to use
|  the various filters. Ideally the filters should be auto-documented,
|  (for example they should support an help options), but for starting
|  a simple texinfo page for them may be sufficient.

I think this is addressed, now that we have doc/vfilters.texi.

Another important point is:

* missing variable frame size/pixel format support, that should be
  managed by lavfi, currently this feature is implemented in ffmpeg.c,
  I posted a very rudimental patch for that much time ago:
  http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/78477

Any help is very appreciated, libavfi looks like an impressive
addition to FFmpeg, also it should allow to significantly reduce the
clutter in the apps.

Regards.
-- 
FFmpeg = Faithless & Foolish Mastodontic Practical Extroverse Gadget