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

[Juan J. Sierralta P.]

On Sat, 2002-02-09 at 13:16, Arpi wrote:

> qscale just affects output bitrate, not the speed

juanjo at balrog:~/devel/ffmpeg$ ./ffmpeg -s 320x240 -r 30 -i
~/Tesis/videos/pp.yuv -f h263 -vcodec h263p -g 300 -qscale 3 -y
-benchmark pp.263
libavcodec: CPU flags: mmx mmxext sse
Input #0, rawvideo, from '/home/juanjo/Tesis/videos/pp.yuv':
  Stream #0.0: Video: rawvideo, yuv420p, 320x240, 30.00 fps
Output #0, h263, to 'pp.263':
  Stream #0.0: Video: h263p, 320x240, 30.00 fps, 200 kb/s
Stream mapping:
  Stream #0.0 -> #0.0
Press [q] to stop encoding
frame=  900 q= 3 size=    2614kB time=30.0 bitrate= 713.9kbits/s    
bench: utime=7.420s


juanjo at balrog:~/devel/ffmpeg$ ./ffmpeg -s 320x240 -r 30 -i
~/Tesis/videos/pp.yuv -f h263 -vcodec h263p -g 300 -qscale 6 -y
-benchmark pp.263
libavcodec: CPU flags: mmx mmxext sse
Input #0, rawvideo, from '/home/juanjo/Tesis/videos/pp.yuv':
  Stream #0.0: Video: rawvideo, yuv420p, 320x240, 30.00 fps
Output #0, h263, to 'pp.263':
  Stream #0.0: Video: h263p, 320x240, 30.00 fps, 200 kb/s
Stream mapping:
  Stream #0.0 -> #0.0
Press [q] to stop encoding
frame=  900 q= 6 size=     832kB time=30.0 bitrate= 227.3kbits/s    
bench: utime=6.880s


juanjo at balrog:~/devel/ffmpeg$ ./ffmpeg -s 320x240 -r 30 -i
~/Tesis/videos/pp.yuv -f h263 -vcodec h263p -g 300 -qscale 9 -y
-benchmark pp.263
libavcodec: CPU flags: mmx mmxext sse
Input #0, rawvideo, from '/home/juanjo/Tesis/videos/pp.yuv':
  Stream #0.0: Video: rawvideo, yuv420p, 320x240, 30.00 fps
Output #0, h263, to 'pp.263':
  Stream #0.0: Video: h263p, 320x240, 30.00 fps, 200 kb/s
Stream mapping:
  Stream #0.0 -> #0.0
Press [q] to stop encoding
frame=  900 q= 9 size=     511kB time=30.0 bitrate= 139.5kbits/s    
bench: utime=6.570s


	Probably the diference comes because lower qscales means more data to
move/write in the bitstream writer. Someday we should take a look to the
bitstream writer, maybe Michael could do that since he improved the
bitstream reader.

> anyway, imho libavcodec could be even faster... at least compared to mp1e it
> is still ~50% slower, at least on my system.

	With P frames ?
	Is mp1e based on ffmpeg ? At least freshmeat says that.
	Also a lot of overhead could reduced if you concentrate on MPEG1 only
:(

> i've noticed that mp1e uses 2 nasty tricks: aligned globals, even for dct
> temp blocks and so on - it may save one register and extra indexing so it
> may speed up things. the other trick is cache optimization, similar to
> libmpeg2's slices, so instead of doing various steps (like dct coding,
> huffman coding etc) on small macroblocks, it group things, like dct for
> while slice, then huffman for whole slice etc.

	I should see the cache trick, maybe there are others; because %50
faster is a lot !


-- 
Juanjo sin .sig :(