On Fri, 2008-11-14 at 01:17 -0700, Bill McWilliams wrote: > I am building a new box for use at my school as an event recorder and > > video server. I used two HVR-1600 cards. The system is Knoppmyth R5.5. > The installation went fine and I downloaded the latest ivtv driver and > cx18 firmware.
I assume you mean *cx18* driver and cx18 firmware. :) > I had to boost the vmalloc to 256mb for both cards (4gb total in system.) vmalloc address space used for the CX23418's 64 MB I/O mappings is different than real physical memory allocation. You're only allocating the virtual memory page table entries (which are rather small and waiting to be used) to access the CX23418's memory and registers that exist across the PCI bus from your CPU, an not allocating actual 64 MB chunks of system RAM. Other things that use vmalloc address space *can* consume system RAM: the machine code for loadable modules (e.g. cx18.ko) and DMA buffers (e.g. the default ~2 MB of MPEG buffers used to transfer video from the CX23418) > I am only using the S-video input so far. I can view and record on both > cards. > > Problem is that when recording or watching live TV through the s-video > port, every 67 frames, it jumps ahead the equivalent of one to two > frames. It isn't dropped frames, it is a jump forward - it is like the > 67 frames are recording a smidge too slow, and at the 67th frame it > jumps 2/30ths of a second to catch up (not sure that's what is > happening, but that describes it.) It is noticeable watching live TV, > and it is on the recordings. It jumps every 67 frames like clockwork (I > ran through recordings frame by frame.) Thanks for the investigation. BTW, what tools are you using to analyze the video? > It affects both cards on S-video. Don't know if it applies to over the > air because I have no over the air inputs yet - will work on it > tomorrow. Can't tell if it is the card, or the software. I know what it is. It's the driver. The cx18 driver falls behind in processing the mailbox command from the Encoder. The problem is the current driver doesn't bother to check that the encoder has timed out a mailbox that the encoder tried to send to the driver. So sometimes the encoder has moved on and is changing the mailbox it sends to us, at the same time we're trying to process the mailbox. This causes us to sometimes miss buffers the encoder tried to send to the driver. Ooops... :P The frequency of the problem really gets exacerbated by simultaneous analog & digital capture. I know what has to be done. I'm working the problem. I'll announce when I have something worth testing. > If I run "cat /dev/video0 | mplayer -" it sends the output directly to > the screen with no other processing, but it is so choppy I can't tell if > the problem is present without Myth or not. For unbuffered playback, the MPEG TS (as opposed to the default MPEG PS) for analog capture is a little smoother for me: $ v4l2-ctl -d /dev/video0 -c stream_type=1 Mplayer can do buffered playback, so presentation is smoother: $ mplayer /dev/video0 -cache 8192 MythTV always does buffered playback. Regards, Andy > -B _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
