[FFmpeg-devel] lavfi state of affairs 3

[Michael Niedermayer]

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

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf
-------------- 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/20090702/23da74c3/attachment.pgp>