awalls at radix
Nov 14, 2008, 7:21 AM
Post #2 of 3
(1045 views)
Permalink
|
|
Re: Dual HVR-1600, jumps every 67 frames with S-video input MPEG
[In reply to]
|
|
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
ivtv-users [at] ivtvdriver
http://ivtvdriver.org/mailman/listinfo/ivtv-users
|
