[MPlayer-dev-eng] XMAME petition

[Colin Leroy]

On Thu, 6 Jun 2002 13:28:10 -0400 D Richard Felker III <dalias at aerifal.cx>
wrote:

> > By the way,
> > would it be possible to do something like a "-low-quality" flag in
> > mplayer, which would have as effect to get 1/4 of the video data (ie,
> > grouping blocks 4 by 4), in order to have fast decoding in the biggest
> > files ?
>
> You mean for faster colorspace conversion? Or just less copying across
> the bus? You'd have to do really crappy sample-one, skip-three
> scaling; actual proper scaling with averaging would be slower than not
> scaling down at all.

I don't really know which results could this give :) I was thinking of
grouping four blocks into only one before passing it to the video decoder,
although I don't know how blocks are read/passed to decoder yet, it's only
a theorical proposition :) video-decoding seems to be the more
cpu-intensive task on my computers (g3 and athlon), that's why I thought
about having less decoding to be done.

> Also, 4x4 blocks seems a bit drastic. Do you really want 180x120 dvds?
> Scaling to half-size would make more sense.

That's what I meant with "4 by 4" : groups or blocks, ie 2x2, we agree
here :)

> Alternatively it might be good to just do vertical scaling, i.e.
> skipping every other scanline. This would be stupid without hardware
> scaling to get back the original size, so it wouldn't make sense to do
> it to avoid colorspace conversion, but it could cut down on the volume
> of data copied. Anyone else have comments as to whether this would
> perform well? I would think with the codec exporting the image and the
> 'lowquality' filter direct rendering to vo, it could help a lot. If
> mga_vid/vidix are fixed to handle multiple calls to config() properly,
> the filter could even swap back and forth between 'lowquality' based
> on cpuload, ala -autoq.

Seems to be a good idea too ...
-- 
Colin
Random BOFH excuse:
	Daemons did it