[MPlayer-dev-eng] video filter layer

Rich Felker dalias at aerifal.cx
Sat Apr 28 16:24:57 CEST 2007


On Wed, Apr 25, 2007 at 02:09:24AM +0200, Michael Niedermayer wrote:
> 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

think of the decoder (possibly via a filter) writing to both the
readable buffer (to use for prediction) and the display buffer at the
same time... this is roughly how the bad slices api works now, but it
could be done much better.

rich



More information about the MPlayer-dev-eng mailing list