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
