> Kevin Atkinson wrote:
> > 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
I was seeing this with a stock bttv in 2.4.19-pre8 also. I changed
to 0.8.4 and the problem essentially disappeared. Using 16 buffers
or so, plus using the parameters as specifed in script "update" in
the bttv distro. If you have SMP, then I have a patch you must
apply. I sent it to the author as well. I now get about 15 frame
drops near the beginning, and then never again.
The frame drops have nothing to do with disk. I tried recording to
/dev/null and still got frame drops with the older bttv. I would
suggest writing to /dev/null too and see what happens.
The new bttv has a few problems which I need to track down. The
volume is inconsistent and the channels are off by one (us-cable).
> > 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.
I used mjpeg at 29.97. VCD resolution (352 x 240).
> > 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.
I popped for the Plextor SCSI burner...never a problem.
Presumably you don't have the burner and the disk on the same IDE
cable?
> Try make sure that the video display card, video capture card, and HDD
> are all on different IRQs. I have seen poor capture performance when
> IRQs are sahred (especially any of the above 3).
I was sharing and fixed this through the BIOS. No difference.
0.8.4 is what fixed my problems. I'm guessing that the latency
parameter in the 'update' script is responsible for quite a bit of
the improvement. Also, I think I heard that capture is better with
v4l2.
Did you say you have a 440BX? If so, check /proc/ide/piix and see
if UDMA is enabled:
[mike@thedog mike]$ cat /proc/ide/piix
Intel PIIX4 Ultra 33 Chipset.
--------------- Primary Channel ---------------- Secondary Channel ------------- enabled enabled
--------------- drive0 --------- drive1 -------- drive0 ---------- drive1 ------DMA enabled: yes yes no yes
UDMA enabled: yes yes no yes
UDMA enabled: 2 2 X 2
UDMA
DMA
PIO
Mike
