[FFmpeg-devel] lavfi state of affairs 3

[Stefano Sabatini]

On date Thursday 2009-07-02 16:38:18 +0200, Michael Niedermayer encoded:
> On Wed, Jul 01, 2009 at 01:38:49PM -0700, Baptiste Coudurier wrote:
> > Hi Ramiro,
> > 
> > Ramiro Polla wrote:
> > > On Wed, Jul 1, 2009 at 4:06 PM, Baptiste
> > > Coudurier<baptiste.coudurier at gmail.com> wrote:
> > >> Stefano Sabatini wrote:
> > >>> On date Wednesday 2009-07-01 10:22:36 -0700, Baptiste Coudurier encoded:
> > >>>> 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
> > >> Is this mandatory ? Direct rendering is not mandatory IMHO.
> > > 
> > > IMO it is very important. It's very hard to work on embedded systems
> > > with limited memory size and bandwidth when you need to memcpy things
> > > around needlessly. I've also found it hard to implement and even hack
> > > direct rendering into frameworks that weren't designed with it in mind
> > > (like VLC).
> > 
> > I totally agree with you. It's very important, but not _mandatory_ IMHO.
> > What's important is to have an API which will allow _adding_ direct
> > rendering easily, but having it implemented later is possible.
> 
> yes but its just easy on paper to do this, i know from mplayer and mplayer g2
> discussions how tricky direct rendering + slices + reordering can get and
> if one tries to just design a API that in theory can handle it without an
> implementation to test it chances are something will be missed during design
> and make the actual implementation impossible without a redesign
> 
> thats, besides that i think we are more stuck on the design than the
> implementation

Since GSOC is approaching, I'm updating this thread with my current
todo list for lavfi:

* fix rgba scaling in lsws (which affects the scale filter)

* fix the problem with odd slices in lsws. Only the last provided
  slice should have an odd size, this would make the slicing code in
  lavfi much simpler (also would allow the current pad filter
  implementation to pass regtest).

* complete the lavfi test system

* commit the pad filter

* remove all dependancies of lavfi on lavc.

* implement direct rendering

* add support for variable video size

* implement a de-interlace / interlace filter

* ffmpeg / ffplay integration


Other related tasks:

* extend the libswscale interface, so to make possible to set in the
  scale filter all the parameters actually controlled (this may
  require: to move eval+opt code from lavc to lavu, and extend lsws
  interface to manage colorspace filtering stuff).

* implement a vf_lmpc (libmpcodecs) wrapper.

* implement a plugin system for lavfi, it should be ideally possible
  to support filters without to implement them into lavfi.

* port the afilters soc to the libavfilter repo, it is already painful
  to keep two repos synched.

* port/write filters/sources/sink, this is the funny part but it's not
  high priority until we'll have a proper test system

Regards.
-- 
FFmpeg = Funny & Fundamental Maxi Pure Ecstatic Governor