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

[Arpi]

Hi,

> [...]
> > > i could try to implement the aan dct (=ffmpeg c dct) in mmx ... but its
> > > less accurate than the current one
> >
> > 	Nopes..... AAN is much inaccurate for me :)
> really? i know its less accurate, but i didt know its that bad
> btw there was a permutation bug in the c dct, perhaps that was why it looked 
> bad, should be fixed though
> imho if u can see a difference between the c & mmx dct than there is a bug 
> somewhere

hmm. mpeg I-only encoding is somewhat special case, it allows even big
inaccurate things, as it doesn't drift the error, each frame is built from
scratch. probably as a fast mode (some new option or flag) we could try it.

> > 	Yes. But since we use the same core for every coder we don't have much
> > choice. Maybe some of them could be avoided.
What about something like the template stuff in rgb/yuv/postprocess code?
I mean common code like encoder_core_template.c containing all coders with
ifdefs, and including it many times only enabling a single codec.
it could save us from if()'s over the inner loops, while avoid having
redundant source code.

> > 	BTW I'm starting to hack a new bit rate control if you could test
> > libavcodec to see if I ain't broke anything, it seems not but I'm
> > commiting often to avoid getting behind like with the RTP callbacks.
> ill tell u if i notice anything strange, but i only use the decoder part 
> normally so i wont notice any encoder bugs ...
i'm using the mpeg1 I-only encoder, and many users with DVB or DXR3 cards
use it. as cards with basic mpeg decoding abilities are cheap nowdays, many
users need fast mpeg encoders.


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...