[FFmpeg-devel] lavfi state of affairs 3

Baptiste Coudurier baptiste.coudurier
Wed Jul 1 22:38:49 CEST 2009

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.

Croping and scaling weren't using direct rendering before.

Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org

More information about the ffmpeg-devel mailing list