[MPlayer-dev-eng] [PATCH] autoq support for control()

Arpi arpi at thot.banki.hu
Sat Feb 9 17:41:21 CET 2002


Hi,

> > > You might be right, I just assumed it would be faster... Although lower
> > qscale just affects output bitrate, not the speed
> > 
> > > res would need a swscale which I find unlikely would speedup playback,
> > > or?
> > swscale is a lot faster than mpeg encoding
> > 
> 
> Maybe I could use the autoq variable to compute a res by dividing the
> original res by something? Any ideas on this?

you shoud NOT use the autoq value at all.
it is for decoders. for slow machines (where downscaling may help) it's
always 0.

anyway, value of autoq depends on a-v desync and idle cpu time. and for
hardware decoders (or -benchmark...), they are unpredictable...

autoq will increase postprocess filter level if there is idle cpu (up to
the value specified with -autoq <n>) and will decrease down to 1 if no
idle cpu left. it will disable all postproc (q=0) when a-v gets desyncing.

> btw, I wonder how the em8300 would handle an mpeg stream of varying res
> ;)
try it.


A'rpi / Astral & ESP-team

--
"I don't RTFM? Wow. What's the meaning of this? It's new for me."
	-- Martin Baum, a tipical MPlayer user...



More information about the MPlayer-dev-eng mailing list