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

[Michael Niedermayer]

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.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070327/3986c433/attachment.pgp>