[MPlayer-dev-eng] video filter layer
Michael Niedermayer
michaelni at gmx.at
Wed Apr 25 02:09:24 CEST 2007
Hi
On Tue, Apr 24, 2007 at 04:22:23PM -0400, Rich Felker wrote:
> On Sat, Apr 21, 2007 at 01:19:39PM +0200, Michael Niedermayer wrote:
> > Hi
> >
> > On Sat, Apr 21, 2007 at 09:54:29AM +0200, Reimar Döffinger wrote:
> > [...]
> > > There are also things like having both MP_IMGFLAG_READABLE
> > > MP_IMGFLAG_PRESERVE, seems somewhat questionable to me whether one makes
> > > sense without the other...
> >
> > IIRC the original idea was that a buffer could be in video memory (preserved
> > but slow as hell to read)
> >
> > and conditional replenish based codecs just update some pixels but leave the
> > remainder unchanged, they also dont read from the buffer so they would
> > theoretically benefit from such buffers
> >
> > but IMHO its an obscure feature which is pretty unimportant
>
> this actually offers a large performance boost to slow machines
> playing low quality 'divx' files, iirc..
how? I/P frames must be read and must be preserved so
MP_IMGFLAG_READABLE != MP_IMGFLAG_PRESERVE has no effect
and b frames dont need to be preserved so i dont see how
MP_IMGFLAG_READABLE != MP_IMGFLAG_PRESERVE could help here
maybe a decoder which needs to read the frame during decoding and the
memory isnt cached and ...
could ask for MP_IMGFLAG_READABLE=1 / MP_IMGFLAG_PRESERVE=0 for b frames
but this is getting fairly hypothetical, also i dont see what the problem
would be with just asking for MP_IMGFLAG_READABLE=1 / MP_IMGFLAG_PRESERVE=1
in that case ...
either way iam against making such obscure features a central
requirement of the new API, if we can easily support such things
and i guess we will good if not good too
[...]
--
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/mplayer-dev-eng/attachments/20070425/296c9375/attachment.pgp>
More information about the MPlayer-dev-eng
mailing list