[Ffmpeg-devel] Port MPlayer's vf to FFMpeg (was [PATCH] enable libswscale)

[Michael Niedermayer]

Hi

On Thu, Sep 14, 2006 at 11:38:44AM -0400, Rich Felker wrote:
> On Thu, Sep 14, 2006 at 04:49:01PM +0200, Michael Niedermayer wrote:
> > Hi
> > 
> > On Thu, Sep 14, 2006 at 04:22:35PM +0200, Diego Biurrun wrote:
> > > On Thu, Sep 14, 2006 at 04:18:33PM +0200, Michael Niedermayer wrote:
> > > > 
> > > > On Thu, Sep 14, 2006 at 02:06:32PM +0200, V?ctor Paesa wrote:
> > > > > 
> > > > > >>
> > > > > >> well, my idea was to change the vfilter realated files from libmpcodecs
> > > > > >>so
> > > > > >> they can be compiled as an independant lib to which then mplayer and
> > > > > >> ffmpeg
> > > > > >> could link, ripping all the vf* out and dropping them (with
> > > > > >modifictaions)
> > > > > >> in ffmpeg would be less optimal as someone would have to maintain,
> > > > > >update,
> > > > > >> ...
> > > > > >> this libmpcodecs fork for "eternity"
> > > > > >
> > > > > 
> > > > > > Why?  MPlayer could use it from FFmpeg then, couldn't it?
> > > > 
> > > > iam against moving libmpcodecs into ffmpeg svn
> > > 
> > > Why?  Due to Subversion technical shortcomings or other reasons?
> > 
> > well there are many reasons
> > * there are surely the technical issues with SVN
> > * libmpcodecs are (audio, video) X (filters, decoders, encoders)
> >   in many cases these are wrapers for mplayer they belong to mplayer and
> >   not ffmpeg, so ill assume that this disscussion is just about the video
> >   filters
> > * rich wanted to design a better filter system for ffmpeg ...
> >   whats the staus of that?
> > * whats the oppinion of the other mplayer developers about that?
> 
> Regardless of whether I or someone else designs a better system, the
> MPlayer vf system is so bad that it absolutely does not belong in the
> ffmpeg framework. It would just make the code horribly
> ugly/broken/unmaintainable. 

well, if noone designs a better system then the mplayer vf system is
still pretty useable and i think that its more likely that the mplayer
vf system will be improved (by uoti maybe?) instead that someone will
write a better one for ffmpeg from scratch
and thinking about it, we can always replace the vf system later by
a better system if someone does design it
that said, supporting mplayer vf and moving it into ffmpeg are 2
seperate things


> Not to mention the vf system does not
> support lavc's idea of buffer handling whatsoever, 

the only thing here which doesnt work is direct rendering with h264 style
IPB reordering, IMO this is of no relevance at all, just disable direct
rendering for h264 and if anyone cares he can fix the buffer handling
to support arbitrary frame reorderings
IMO features are more important then speed and optimizations


> and presently the
> pts support is highly lacking.

the vf system supports it IIRC, its just that not all filters set the pts


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is