I posted this about two weeks ago and didn't get any response. So I thought I would try again. I would really appreciate some help on these issues. If this is not the best place to post them then could some one redirect me to a better list. Thanks. --- http://kevin.atkinson.dhs.org ---------- Forwarded message ---------- Date: Thu, 16 May 2002 04:28:23 -0400 (EDT) From: Kevin Atkinson <kevin@xxxxxxxxxxxxxxxx> To: video4linux-list@xxxxxxxxxx Subject: Lavrec & Streamer Problems I have been having continuing problems on my system with Lavrec (from mjpeg-tools), Streamer (from xawtv), and also with the SCSI Emulation. Lavrec and Streamer refuse to record a smooth video and my system becomes unusable when reading or writing cds though SCSI emulation. I original reported the lavrec problems to mjpeg-users but Ronald Bultje, one of the primary mjpeg authors basically gave up. The only reason I am reporting the SCSI problem is because I think it might be related. *** Basic system info ************************************************* Linux 2.4.18, 2.4.19-pre*, 2.4.19-pre*-ac*, as in I have the same problem with all these kernel versions. 256 mpeg, 1 gig swap, Pentium III at 500 mhz, GA-BX2000 Intel 440BX AGP Motherboard, Western Digital IDE Hard drive- 120 gigs, model WD1200JB. Using the bttv, video, and audio drivers with the kernel for all tests. Hard drive write performance: $ time dd bs=1024 count=262144 if=/dev/zero of=./junk 0.43user 11.17system 0:13.33elapsed 86%CPU Which means my hard drive can write about 19.2 megs/s. Someone also noted how the CPU usage is rather high, as if it was doing programed i/o. UDMA is ON I made sure of that. This is using ReiserFS. When writing to /tmp which uses the /tmpfs the CPU usage is lower and it is slightly faster. 0.16user 2.76system 0:10.76elapsed 27%CPU It has to use the harddrive at least somewhat. As I only have 256 megs of ram, but to make dam sure: $ time dd bs=1024 count=500000 if=/dev/zero of=./junk 0.41user 5.07system 0:25.28elapsed 21%CPU I also noted that when monitoring a long recursive copy cp also takes up about 85% CPU. Is this right? More harddrive info: hdparm -tT Timing buffer-cache reads: 128 MB in 1.13 seconds =113.27 MB/sec Timing buffered disk reads: 64 MB in 2.34 seconds = 27.35 MB/sec hdparm -i /dev/hda /dev/hda: Model=WDC WD1200JB-75CRA0, FwRev=16.06V16, SerialNo=WD-WMA8C1900150 Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq } RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=40 BuffType=DualPortCache, BuffSize=8192kB, MaxMultSect=16, MultSect=16 CurCHS=4047/16/255, CurSects=16511760, LBA=yes, LBAsects=234375000 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio1 pio2 pio3 pio4 DMA modes: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4 udma5 AdvancedPM=no WriteCache=enabled Drive Supports : Reserved : ATA-1 ATA-2 ATA-3 ATA-4 ATA-5 hdparm /dev/hda /dev/hda: multcount = 16 (on) I/O support = 0 (default 16-bit) unmaskirq = 0 (off) using_dma = 1 (on) keepsettings = 0 (off) nowerr = 0 (off) readonly = 0 (off) readahead = 8 (on) geometry = 14589/255/63, sectors = 234375000, start = 0 busstate = 1 (on) *** Lavrec Problems ***************************************************** I am having problems getting lavrec working properly using software encoding with version 0.6.0. It can record just find but the resulting picture is very jerky. It seams to happen every time there is a disk write but this is not the only time it skips frames. It works slightly better over NFS or on the tmpfs but it still has problems. I am using: lavrec -q 85 -g 320x240 -R l --software-encoding sample.avi with a stock Linux kernel 2.4.18. When recording for 18 seconds to my local hard drive I get 2 inserted frames (no del.) when using --file-flush 0, 14 with --file-flush 1 and 29 with no file-flush. Over NFS I get 1, 3, 1 respectfully. When using tmpfs I get 1,1,1 respectfully. Note that mp1e records with very little lost frames no matter what I do, even when I do other things like browse the web. With lavrec I got tons of interested frames when I go off and do something else. Also note that I am able to record raw 320x240 yuv2 39.96 fps just fine with VirtualDub using crappy Win98. Ronald Bultje original thought this was due to my mother board. However, I think this is due to a kernel or lavrec bug or incompatibility with my system. *** Streamer Problems ***************************************************** For the life in me I can't get streamer to record anything without getting tons of "queueing frame twice". As a result the resting video is very jerky. I also get "v4l: waiting for a free buffer". Unless I increase gbuffers. With buffers at the default: $ streamer -t 0:05 -s 352x240 -r 29.97 -o video.yuv -O audio.wav raw / video: 12 bit YUV 4:2:0 (planar) / audio: 8bit mono rate: queueing frame twice (2) rate: queueing frame twice (1) video: -0.000s [repeated about 15 times] rate: queueing frame twice (2) video: -0.000s v4l: waiting for a free buffer video: -0.000s rate: queueing frame twice (8) rate: queueing frame twice (8) video: -0.000s [repeated about 15 times] v4l: waiting for a free buffer video: -0.000s rate: queueing frame twice (12) rate: queueing frame twice (12) video: -0.000s [repeated about 15 times] v4l: waiting for a free buffer video: -0.000s rate: queueing frame twice (17) rate: queueing frame twice (17) video: -0.000s [repeated about 15 times] v4l: waiting for a free buffer video: -0.000s rate: queueing frame twice (21) rate: queueing frame twice (21) video: -0.000s [repeated about 15 times] v4l: waiting for a free buffer video: -0.000s rate: queueing frame twice (25) rate: queueing frame twice (24) video: -0.000s [repeated about 15 times] When setting gbuffers to 8 (4 is still to low) I get rid of the "v4l: waiting for a free buffer" but I still gets lots of duplicated frames: streamer -t 0:05 -s 352x240 -r 29.97 -o video.yuv -O audio.wav raw / video: 12 bit YUV 4:2:0 (planar) / audio: 8bit mono rate: queueing frame twice (2) rate: queueing frame twice (2) video: -0.003s [repeated 3 times] rate: queueing frame twice (2) video: -0.002s [repeated around 80 times] rate: queueing frame twice (3) video: -0.002s Using tmpfs doesn't help. Nor does using mjpeg compression when the frame rate is 29.97. However mjpeg is ok when using the default frame rate at 10. These tests were done using 2.4.19-pre8-ac4 with out any additional patches or external modules. As I said before I can record 240x240 yuv2 29.97 fps with at a single lost frame using VirtualDub on crappy Win98 so I know my system can handle it. *** SCSI Problems ***************************************************** Well when using SCSI emulation I have problems when reading/writing cds. Using dd or cat to dump a cds iso image works find but when I use readcd i can barley move the mouse let alone do something else while readcd is working. I have a similar problem when burnings cds at full speed (24x) but my system is responsive enough to at least browse the web. Could these problems be related? I am fairly sure the SCSI emulation problems are due to a kernel bug but I don't know who to ask about it. Any suggestions? *** Conclusion ******************************************************** Help! ;(. Does anyone have any idea what is going on. Could these 3 problems be related. Thanks in advance. --- http://kevin.atkinson.dhs.org
