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

[Marc Hoffman]

Michael Niedermayer writes:
 > Hi
 > 
 > On Tue, Mar 27, 2007 at 02:15:10AM -0500, Rich Felker wrote:
 > > On Tue, Mar 27, 2007 at 08:50:29AM +0200, V?ctor Paesa wrote:
 > > > Hi,
 > > > 
 > > > > Michael Niedermayer writes:
 > > > >  > Hi
 > > > >  >
 > > > >  > On Sun, Mar 25, 2007 at 12:54:54PM -0400, Marc Hoffman wrote:
 > > > >  > >
 > > > >  > > How would one go about including this type of video hook into the
 > > > >  > > mainline ffmpeg tree?  This is slightly off the beaten path however
 > > > >  >
 > > > >  > vhook is deprecated, port libmpcodecs or a better filter system to
 > > > > ffmpeg
 > > > >  > and implement your filter in that
 > > > >  >
 > > > >
 > > > > ok I can look at that if it helps the group. Are we trying to migrate
 > > > > the best parts of mplayer into ffmpeg? I guess I don't understand the
 > > > > big picture if this is posted and I should have read something please
 > > > > pardon my ignorance and just put me in the right direction.
 > > > 
 > > > Here is a good description of the intended libmpcodecs port:
 > > > http://article.gmane.org/gmane.comp.video.ffmpeg.devel/39130
 > > 
 > > I'd like to see something much more radical. libmpcodecs is very very
 > > poorly designed and not a good direction for a filter layer. The worst
 > > part is that every single filter duplicates tons of 'infrastructure'
 > > code which tends to lock you into the bad design. If we could nail
 > > down the ideal abstraction and api for the actual filters, simple
 > > filters would become just a few lines of code, and in complex ones at
 > > least all the complexity would be in the actual behavior rather than
 > > the ugly interaction with a poorly designed and inflexible filter
 > > framework...
 > 
 > well, the choice we have is
 > A. keep current vhook
 >     very very crappy
 > B. switch to an existing filter API like libmpcodecs 
 >     much better than vhook
 >     easy
 >     not perfect, we can point at many things which could be done better
 > C. design a new filter system
 >     many people tried and failed (=no patch came out until now)
 >     might or might not be better than existing APIs, we cant be sure before
 >     we actually see the code ...
 > 
 > 
 > considering these A is of course a bad choice, and we where "waiting" for C
 > to happen since years (at least since mplayer g2) so B is the way to go.
 > The people who wish to write a better filter system had enough time to do so
 > and they still now and even after libmpcodecs support can write and propose
 > another filter system, i just dont accept to not switch to a much better
 > filter system than the current vhook because some people think a better
 > system could be designed though theres no one actually implementing it,
 > thats no argument.
 > 

I was looking at libmpcodecs that is one awsome piece of software,
which has probably been around a while so most of the bugs have been
shaken out.  This seems like a reasonable path to me which leverages a
lot of mature (reasonably) technology.

Marc