[Ffmpeg-devel] Embedded preview vhook/voutfb.so /dev/fb

mmh mmh
Tue Mar 27 20:45:45 CEST 2007


Michael Niedermayer writes:
 > Hi
 > 
 > On Tue, Mar 27, 2007 at 06:38:55PM +0100, Men out.  This seems like a reasonable path to me which leverages a
 > > >> lot of mature (reasonably) technology.
 > > >
 > > > LMAO... You can construct filter chains which simply crash, or which
 > > > output the wrong thing based on adjacent filters' presence or
 > > > absence... It's just that most of the common cases work well enough
 > > > that no one notices..
 > > >
 > > > I'm one of the main people who wrote (and enhanced existing) filters
 > > > for it way back, so I have good reason to believe it sucks.. :)
 > > 
 > > I'm with Rich on this one.  It's a waste of time to replace the vhooks
 > > with something else that doesn't work properly and which we'll want to
 > > replace again anyway.
 > 
 > its not a waste of time to replace something mostly NOT WORKING with something
 > that works very well in practice and has a huge heap of existing filters
 > 
 > even if we write our own better filter system libmpcodecs support is
 > absolutely wanted simply because of the many filters mplayer has
 > 
 > also its much more realistic to take an existing system and improve it
 > than to rewrite it from scratch, rewrites almost always fail
 > 
 > and most important we played this rewrite the filter system from scratch
 > game since _YEARS_ both in ffmpeg and mplayer with not a single line of
 > code coming out of it. its time for thouse who want their supperior
 > filter system to start coding instead of blocking efforts to improve
 > the situation with unspecific claims that it could be done better
 > 
 > iam sure the crashes in libmpcodecs can be fixed, iam sure its trivial
 > to write a simplified 1-in-1-out and local style filter wrapers on top
 > of libmpcodes as proposed so wheres the advantage of not using libmpcodecs
 > and how can that advantage actually be reached that is without inroducing
 > a heap of other problems
 > 

I have to agree Mike, software rewrites typically never results in the
way you would have liked. You see we can all go and write the best
piece of code that we think is a replacement for mpcodecs and in our
mind it would be awesome and cool. However, it will have other
problems which we don't know right now.  So in my opinion we should
dig in and make the thing you/we think is broken work
better. Leveraging existing work and making it better, is what we
should be doing not re creating the wheel.

I have looked a little at that mpcodecs and its not that bad actually
its truly amazing how much detail it has.

Marc




More information about the ffmpeg-devel mailing list