Gerd, et al., I have been trying to improve the performance of streamer, which is part of the xawtv package. I would like to capture a jpeg encoded QuickTime stream with a resolution of 640x480 pixels and a frame-rate of 25 frames per second. I am the guy that sent you a QuickTime patch for xawtv some time ago. The system I am using is an Athlon 550 Mhz based computer with a 10,000 RPM IBM SCSI hard drive and 96 MB of RAM. I am using the 2.4.3 version of the Linux kernel. My root filesystem is a reiserfs partition. First I have used Corel's cprof to profile streamer, with the following results when capturing a jpeg encoded, 640x480 pixel stream: ... xioctl 1080 28.206 42833 28.206 42833 ng_waiton_video_buf 505 20.146 30593 20.146 30593 forward_DCT 2520000 20.004 30377 31.723 48173 encode_one_block 3780000 12.052 18302 15.085 22908 jpeg_fdct_ifast 3780000 11.719 17796 11.719 17796 emit_bits 14965507 3.033 4605 3.033 4605 quicktime_write_data 9589 1.920 2915 2.096 3182 encode_mcu_huff 630000 1.257 1908 16.342 24816 ... The remaining functions constituted less than 1% of the program's run time. The results of this profiling are what I expected; much of the code's time is spent encoding jpegs. A total of 43% of the program's time is spent in the functions forward_DCT, encode_one_block, and jpeg_fdct_ifast. A few very rough calculations seem to indicate that a performance increase of about 33% from the jpeg code will allow me to capture 25 frames a second at a resolution of 640x480 pixels. I tried plugging in the jpeg-mmx package from mjpeg tools, http://mjpeg.sourceforge.net, but it seems to be optimized only for decompression. I also tried mmxdct, http://homex.coolconnect.com/user/xkwang/mmxdct/mmxdct-1.0.tar.gz, but it actually seems slower than the stock libjpeg DCT code. Optimizing the libjpeg code as recommended by The Athlon Linux Project, http://athlonlinux.org/agcc/about.shtml, seems to give a 15% performance boost. I have also considered trying Justin Schoeman's RTjpeg codec instead of jpeg. However, though it seems a patched streamer will capture an RTjpeg stream, I can't find or patch any players to play it. Anyone have any ideas on how to eek some more performance out of libjpeg? The easiest solution for me would probably be to purchase a faster processor or a capture card which can compress data in hardware. However, I would like to avoid purchasing any more hardware. I also feel that solving this problem in software would be more beneficial to more people than me buying some new toys. On a semi-related note, does anyone have any ideas on how to make streamer a little more resistant to system load? I have tried adding calls which set the sceduling type to SCHED_FIFO to streamer with no positive results. I would like to avoid the need to change to runlevel one to get a good recording. Thank you for any advice! -- W. Michael Petullo :wq
