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

Rich Felker dalias
Tue Mar 27 22:11:33 CEST 2007


On Tue, Mar 27, 2007 at 08:10:01PM +0200, Michael Niedermayer wrote:
> > 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

I actually agree that Michael that it's reasonable to add optional
support for libmpcodecs to ffmpeg, if it can be cleaned up enough to
interface it with a non-MPlayer program. However, libmpcodecs should
not be considered a "development direction". It's a deadend. Most of
the most useful filters could be replaced with just a few lines of
code with the proper abstractions.

> even if we write our own better filter system libmpcodecs support is
> absolutely wanted simply because of the many filters mplayer has

Hopefully what I just said ameliorates this issue a bit.

> also its much more realistic to take an existing system and improve it
> than to rewrite it from scratch, rewrites almost always fail

I'm torn as to whether this is true or not. If you're going to work
from an existing system rather than rewrite, then IMO the main effort
needs to be on removing what sucks and simplifying, rather than
extending. BusyBox is one AMAZING example of a project that's made
great things out of crappy legacy sources, both increasing
functionality and decreasing bloat and (more importantly) complexity
with each successive commit/release. On the other hand, gcc and glibc
are horrible examples of what can go wrong when you keep building on a
fundamentally broken foundation. There will never be a good compiler
based on gcc unless someone forks it and strips it down to bare
bones..

> 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

I won't block efforts to support libmpcodecs. But if there's a SoC
project I wish it could lead in a new direction.. Maybe that's just
wishful thinking. I will not be around to aid in SoC mentoring but I
could write up and leave my notes for others to examine.

> 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

If you just avoid most of the fancy negotiations and performance
enhancements (i.e. always refuse DR and slices) then it should not
crash or exhibit bugs, but it'll be somewhat slower.

Rich




More information about the ffmpeg-devel mailing list