[FFmpeg-devel] lavfi state of affairs 2
Vitor Sessak
vitor1001
Mon Mar 9 20:10:03 CET 2009
Stefano Sabatini wrote:
> Hi all,
>
> this has to be meant as the follow-up of
> http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/81034/
>
> Since then regressions has been fixed, works on alpha blending support
> has been committed to libswscale (a quite important feature for lavfi
> I think) and VHOOK has been removed from FFmpeg, so people is going fo
> get puzzled since they can't find it anymore, and is starting to use
> lavfi more and more (getting puzzled again for its lack of
> documentation ... :-|).
>
> But this is also a good thing for lavfi since more and more people is
> getting aware of it and starting to use and test it.
>
> 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/
>
> * 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
>
> * 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 SVVN may provide the foundations
> for such a system (I intend to work on this).
>
> * 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.
>
> * 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'd like to add also to add
* Rework ffplay.c patch to be more similar to the ffmpeg.c one, notably
using vf_buffer.c
> So please consider to work on it if you like to see lavfi integrated
> into SVN soon, also many things could be nice qualification tasks for
> GSOC students (for example porting existing filters to lavfi).
Talking about GSoC, what is your opinion about this:
http://wiki.multimedia.cx/index.php?title=Talk:FFmpeg_Summer_Of_Code_2009#Libavfilter_work_.2B_audio_support
?
-Vitor
More information about the ffmpeg-devel
mailing list