Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. ivtv>
  3. users
cx18 video corruption
danimal at agriroots
Sep 30, 2009, 7:33 PM
Post #1 of 4 (2698 views)
Permalink
i have an hvr-1600 that i'm trying to get working with local cable's
free HD channels. it mostly works very nice (thanks andy), but the video
has small corruptions in it. if i look at the dmesg i have errors like:

cx18-0: warning: failed to be awakened upon RPU acknowledgment sending
CX18_CPU_DE_SET_MDL; timed out waiting 14 msecs
cx18-0: warning: failed to be awakened upon RPU acknowledgment sending
CX18_CPU_DE_SET_MDL; timed out waiting 11 msecs
cx18-0: warning: failed to be awakened upon RPU acknowledgment sending
CX18_CPU_DE_SET_MDL; timed out waiting 14 msecs
cx18-0: warning: failed to be awakened upon RPU acknowledgment sending
CX18_CPU_DE_SET_MDL; timed out waiting 15 msecs

i'm running fedora 11 with the latest kernel, i tried updating the
v4l-dvb driver, but the behavior seems the same.

i read a while back about interrupt problems, the interrupt info for my
machine is:

cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
0: 281 111 234 191 IO-APIC-edge
timer
1: 1 1 0 0 IO-APIC-edge
i8042
8: 7 8 16 13 IO-APIC-edge
rtc0
9: 0 0 0 0 IO-APIC-fasteoi
acpi
12: 0 2 2 0 IO-APIC-edge
i8042
16: 220827 129818 98284 46306 IO-APIC-fasteoi
uhci_hcd:usb3, uhci_hcd:usb8, nvidia
17: 2586763 2548712 1974642 1930591 IO-APIC-fasteoi
cx18-0
18: 118657 53841 124164 64003 IO-APIC-fasteoi
ehci_hcd:usb1, uhci_hcd:usb7
19: 0 0 0 0 IO-APIC-fasteoi
uhci_hcd:usb6
20: 1673 241 823 486 IO-APIC-fasteoi
firewire_ohci
21: 0 0 0 0 IO-APIC-fasteoi
uhci_hcd:usb4
22: 20843 5755 23756 7796 IO-APIC-fasteoi HDA
Intel
23: 1594911 1485736 1468820 1426265 IO-APIC-fasteoi
ehci_hcd:usb2, uhci_hcd:usb5
27: 1095 1095 1607156 1306382 PCI-MSI-edge
ahci
28: 60 9700117 54 60 PCI-MSI-edge
eth0
NMI: 0 0 0 0 Non-maskable
interrupts
LOC: 71028778 71198700 68479506 66790971 Local timer
interrupts
SPU: 0 0 0 0 Spurious interrupts
RES: 873725 646350 996161 709235 Rescheduling
interrupts
CAL: 12575 10193 10957 11134 Function call
interrupts
TLB: 691919 910061 754828 948509 TLB shootdowns
TRM: 0 0 0 0 Thermal event
interrupts
THR: 0 0 0 0 Threshold APIC
interrupts
ERR: 0
MIS: 0

it looks to me that the cx18 has it's own interrupt, so i guess that's
not the problem?

also, here's the driver initialization log:

cx18: Start initialization, version 1.2.0
cx18-0: Initializing card 0
cx18-0: Autodetected Hauppauge card
cx18-0: info: base addr: 0xf4000000
cx18-0: info: Enabling pci device
cx18 0000:01:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
cx18-0: info: cx23418 (rev 0) at 01:00.0, irq: 17, latency: 64, memory: 0xf4000000
cx18-0: info: attempting ioremap at 0xf4000000 len 0x04000000
cx18-0: cx23418 revision 01010000 (B)
cx18-0: info: GPIO initial dir: 0000ffff/0000ffff out: 00000000/00000000
cx18-0: info: activating i2c...
cx18-0: Autodetected Hauppauge HVR-1600
cx18-0: info: NTSC tuner detected
cx18-0: Simultaneous Digital and Analog TV capture supported
IRQ 17/cx18-0: IRQF_DISABLED is not guaranteed on shared IRQs
tuner 2-0061: chip found @ 0xc2 (cx18 i2c driver #0-1)
cs5345 1-004c: chip found @ 0x98 (cx18 i2c driver #0-0)
cx18-0: info: Allocate encoder MPEG stream: 64 x 32768 buffers (2048kB total)
cx18-0: info: Allocate TS stream: 32 x 32768 buffers (1024kB total)
cx18-0: info: Allocate encoder YUV stream: 16 x 131072 buffers (2048kB total)
cx18-0: info: Allocate encoder VBI stream: 20 x 51984 buffers (1015kB total)
cx18-0: info: Allocate encoder PCM audio stream: 256 x 4096 buffers (1024kB total)
cx18-0: info: Allocate encoder IDX stream: 32 x 32768 buffers (1024kB total)
cx18-0: Registered device video0 for encoder MPEG (64 x 32 kB)
DVB: registering new adapter (cx18)
cx18-0: DVB Frontend registered
cx18-0: Registered DVB adapter0 for TS (32 x 32 kB)
cx18-0: Registered device video32 for encoder YUV (16 x 128 kB)
cx18-0: Registered device vbi0 for encoder VBI (20 x 51984 bytes)
cx18-0: Registered device video24 for encoder PCM audio (256 x 4 kB)
cx18-0: Initialized card: Hauppauge HVR-1600
cx18: End initialization
cx18 0000:01:00.0: firmware: requesting v4l-cx23418-cpu.fw
cx18-0: loaded v4l-cx23418-cpu.fw firmware (158332 bytes)
cx18 0000:01:00.0: firmware: requesting v4l-cx23418-apu.fw
cx18-0: info: load segment a00000-a07fff
cx18-0: info: load segment ae0000-ae00ff
cx18-0: info: load segment b00000-b1a65f
cx18-0: loaded v4l-cx23418-apu.fw firmware V00120000 (141200 bytes)
cx18-0: info: 1 MiniMe Encoder Firmware 0.0.74.0 (Release 2007/03/12)
cx18-0: FW version: 0.0.74.0 (Release 2007/03/12)
cx18 0000:01:00.0: firmware: requesting v4l-cx23418-cpu.fw
cx18 0000:01:00.0: firmware: requesting v4l-cx23418-apu.fw
cx18-0: info: load segment a00000-a07fff
cx18-0: info: load segment ae0000-ae00ff
cx18-0: info: load segment b00000-b1a65f
cx18-0: info: 1 MiniMe Encoder Firmware 0.0.74.0 (Release 2007/03/12)
cx18 0000:01:00.0: firmware: requesting v4l-cx23418-dig.fw
cx18-0 843: loaded v4l-cx23418-dig.fw firmware (16382 bytes)
cx18-0 843: verified load of v4l-cx23418-dig.fw firmware (16382 bytes)
cx18-0: info: Changing input from 1 to 0
cx18-0: info: Mute
cx18-0 843: info: decoder set video input 7, audio input 8
cx18-0 843: info: decoder set video input 7, audio input 8
cx18-0: info: Unmute
cx18-0: info: Switching standard to 1000.
cx18-0 843: info: changing video std to fmt 1
cx18-0 843: info: PLL regs = int: 15, frac: 2876158, post: 4
cx18-0 843: info: Video PLL = 107.999999 MHz
cx18-0 843: info: Pixel rate = 13.499999 Mpixel/sec
cx18-0 843: info: ADC XTAL/pixel clock decimation ratio = 2.121
cx18-0 843: info: Chroma sub-carrier initial freq = 3.579545 MHz
cx18-0 843: info: hblank 122, hactive 720, vblank 26, vactive 481, vblank656 38, src_dec 543, burst 0x5a, luma_lpf 1, uv_lpf 1, comb 0x66, sc 0x087c00


was wondering what else i can do to fix or help fix the problem, the
jitter can get annoying and sometimes mplayer crashes with corrupted
video and/or audio packets from the capture file.

thanks for any help,
dan

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: cx18 video corruption [ In reply to ]
awalls at radix
Oct 1, 2009, 3:51 AM
Post #2 of 4 (2590 views)
Permalink
Dan,

On Wed, 2009-09-30 at 22:33 -0400, Daniel Flesner wrote:
> i have an hvr-1600 that i'm trying to get working with local cable's
> free HD channels. it mostly works very nice (thanks andy), but the video
> has small corruptions in it. if i look at the dmesg i have errors like:
>
> cx18-0: warning: failed to be awakened upon RPU acknowledgment sending
> CX18_CPU_DE_SET_MDL; timed out waiting 14 msecs
> cx18-0: warning: failed to be awakened upon RPU acknowledgment sending
> CX18_CPU_DE_SET_MDL; timed out waiting 11 msecs
> cx18-0: warning: failed to be awakened upon RPU acknowledgment sending
> CX18_CPU_DE_SET_MDL; timed out waiting 14 msecs
> cx18-0: warning: failed to be awakened upon RPU acknowledgment sending
> CX18_CPU_DE_SET_MDL; timed out waiting 15 msecs

Those are actually harmless. Those are outgoing empty buffers being
handed back to the CX23418 firmware. They are taking a long time to get
acknowledged which happens because:

1. The CX23418 didn't immediately acknowledge the buffer handover.
That's normal, and in practice, I've found it doesn't happen frequently,

and

2. When the cx-18-0-out/n thread goes to sleep waiting on the
acknowledgment from the firmware, and the firmware causes the IRQ
handler to send a wake-up, the linux *scheduler* takes a long time to
put cx18-0-out/n back into a running state.


What has normally happened is that the CX23418 firmware actually has
acknowledeged the bufffer handover, but the cx18-0-out/n thread didn't
get notified until much later.

So unless you get a solid stream of these messages, this warning message
is harmless in terms of cx18. What it does indicate is that at least
one of your CPU cores (the one running the cx18-0-out/n thread in
question) is very busy and/or the scheduler isn't doing a very good job.
15 ms is kinda of long to be asleep, but I've seen 10 ms many times
before with my Fedora 10 setup.


Please turn on debug info warn and mailbox in the cx18 driver and note
how often you get the "Possibly falling behind" warning. That's the one
that's indicative of potential incoming video processing delays by your
system.


> i'm running fedora 11 with the latest kernel, i tried updating the
> v4l-dvb driver, but the behavior seems the same.

Indicative of a system level issue vs. a driver level one.


> i read a while back about interrupt problems, the interrupt info for my
> machine is:
>
> cat /proc/interrupts
> CPU0 CPU1 CPU2 CPU3
> 0: 281 111 234 191 IO-APIC-edge
> timer
> 1: 1 1 0 0 IO-APIC-edge
> i8042
> 8: 7 8 16 13 IO-APIC-edge
> rtc0
> 9: 0 0 0 0 IO-APIC-fasteoi
> acpi
> 12: 0 2 2 0 IO-APIC-edge
> i8042
> 16: 220827 129818 98284 46306 IO-APIC-fasteoi
> uhci_hcd:usb3, uhci_hcd:usb8, nvidia
> 17: 2586763 2548712 1974642 1930591 IO-APIC-fasteoi
> cx18-0
> 18: 118657 53841 124164 64003 IO-APIC-fasteoi
> ehci_hcd:usb1, uhci_hcd:usb7
> 19: 0 0 0 0 IO-APIC-fasteoi
> uhci_hcd:usb6
> 20: 1673 241 823 486 IO-APIC-fasteoi
> firewire_ohci
> 21: 0 0 0 0 IO-APIC-fasteoi
> uhci_hcd:usb4
> 22: 20843 5755 23756 7796 IO-APIC-fasteoi HDA
> Intel
> 23: 1594911 1485736 1468820 1426265 IO-APIC-fasteoi
> ehci_hcd:usb2, uhci_hcd:usb5
> 27: 1095 1095 1607156 1306382 PCI-MSI-edge
> ahci
> 28: 60 9700117 54 60 PCI-MSI-edge
> eth0
> NMI: 0 0 0 0 Non-maskable
> interrupts
> LOC: 71028778 71198700 68479506 66790971 Local timer
> interrupts
> SPU: 0 0 0 0 Spurious interrupts
> RES: 873725 646350 996161 709235 Rescheduling
> interrupts
> CAL: 12575 10193 10957 11134 Function call
> interrupts
> TLB: 691919 910061 754828 948509 TLB shootdowns
> TRM: 0 0 0 0 Thermal event
> interrupts
> THR: 0 0 0 0 Threshold APIC
> interrupts
> ERR: 0
> MIS: 0
>
> it looks to me that the cx18 has it's own interrupt, so i guess that's
> not the problem?

That's correct in that no other linux driver in particular is directly
to blame.

I notice that your interrupts are generally balanced, but there is an
assymetry between CPU0/1 and CPU2/3 (execpt for a different assymetry
with the USB hubs).

That might explain why the cx18-0-out/n thread is held off for a "long"
time at times, but again, that's nothing to worry about.


> also, here's the driver initialization log:
>
> cx18: Start initialization, version 1.2.0
> cx18-0: Initializing card 0
> cx18-0: Autodetected Hauppauge card
> cx18-0: info: base addr: 0xf4000000
> cx18-0: info: Enabling pci device
> cx18 0000:01:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
> cx18-0: info: cx23418 (rev 0) at 01:00.0, irq: 17, latency: 64, memory: 0xf4000000
> cx18-0: info: attempting ioremap at 0xf4000000 len 0x04000000
> cx18-0: cx23418 revision 01010000 (B)
> cx18-0: info: GPIO initial dir: 0000ffff/0000ffff out: 00000000/00000000
> cx18-0: info: activating i2c...
> cx18-0: Autodetected Hauppauge HVR-1600
> cx18-0: info: NTSC tuner detected
> cx18-0: Simultaneous Digital and Analog TV capture supported
> IRQ 17/cx18-0: IRQF_DISABLED is not guaranteed on shared IRQs
> tuner 2-0061: chip found @ 0xc2 (cx18 i2c driver #0-1)
> cs5345 1-004c: chip found @ 0x98 (cx18 i2c driver #0-0)
> cx18-0: info: Allocate encoder MPEG stream: 64 x 32768 buffers (2048kB total)
> cx18-0: info: Allocate TS stream: 32 x 32768 buffers (1024kB total)
> cx18-0: info: Allocate encoder YUV stream: 16 x 131072 buffers (2048kB total)
> cx18-0: info: Allocate encoder VBI stream: 20 x 51984 buffers (1015kB total)
> cx18-0: info: Allocate encoder PCM audio stream: 256 x 4096 buffers (1024kB total)
> cx18-0: info: Allocate encoder IDX stream: 32 x 32768 buffers (1024kB total)
> cx18-0: Registered device video0 for encoder MPEG (64 x 32 kB)
> DVB: registering new adapter (cx18)
> cx18-0: DVB Frontend registered
> cx18-0: Registered DVB adapter0 for TS (32 x 32 kB)
> cx18-0: Registered device video32 for encoder YUV (16 x 128 kB)
> cx18-0: Registered device vbi0 for encoder VBI (20 x 51984 bytes)
> cx18-0: Registered device video24 for encoder PCM audio (256 x 4 kB)
> cx18-0: Initialized card: Hauppauge HVR-1600
> cx18: End initialization
> cx18 0000:01:00.0: firmware: requesting v4l-cx23418-cpu.fw
> cx18-0: loaded v4l-cx23418-cpu.fw firmware (158332 bytes)
> cx18 0000:01:00.0: firmware: requesting v4l-cx23418-apu.fw
> cx18-0: info: load segment a00000-a07fff
> cx18-0: info: load segment ae0000-ae00ff
> cx18-0: info: load segment b00000-b1a65f
> cx18-0: loaded v4l-cx23418-apu.fw firmware V00120000 (141200 bytes)
> cx18-0: info: 1 MiniMe Encoder Firmware 0.0.74.0 (Release 2007/03/12)
> cx18-0: FW version: 0.0.74.0 (Release 2007/03/12)
> cx18 0000:01:00.0: firmware: requesting v4l-cx23418-cpu.fw
> cx18 0000:01:00.0: firmware: requesting v4l-cx23418-apu.fw
> cx18-0: info: load segment a00000-a07fff
> cx18-0: info: load segment ae0000-ae00ff
> cx18-0: info: load segment b00000-b1a65f
> cx18-0: info: 1 MiniMe Encoder Firmware 0.0.74.0 (Release 2007/03/12)
> cx18 0000:01:00.0: firmware: requesting v4l-cx23418-dig.fw
> cx18-0 843: loaded v4l-cx23418-dig.fw firmware (16382 bytes)
> cx18-0 843: verified load of v4l-cx23418-dig.fw firmware (16382 bytes)
> cx18-0: info: Changing input from 1 to 0
> cx18-0: info: Mute
> cx18-0 843: info: decoder set video input 7, audio input 8
> cx18-0 843: info: decoder set video input 7, audio input 8
> cx18-0: info: Unmute
> cx18-0: info: Switching standard to 1000.
> cx18-0 843: info: changing video std to fmt 1
> cx18-0 843: info: PLL regs = int: 15, frac: 2876158, post: 4
> cx18-0 843: info: Video PLL = 107.999999 MHz
> cx18-0 843: info: Pixel rate = 13.499999 Mpixel/sec
> cx18-0 843: info: ADC XTAL/pixel clock decimation ratio = 2.121
> cx18-0 843: info: Chroma sub-carrier initial freq = 3.579545 MHz
> cx18-0 843: info: hblank 122, hactive 720, vblank 26, vactive 481, vblank656 38, src_dec 543, burst 0x5a, luma_lpf 1, uv_lpf 1, comb 0x66, sc 0x087c00
>
>
> was wondering what else i can do to fix or help fix the problem, the
> jitter can get annoying and sometimes mplayer crashes with corrupted
> video and/or audio packets from the capture file.


This sounds like a cable signal level problem. When capturing, please
run femon in a terminal window and look for periods where the
uncorrectable block count increases. If you get those, and the
correspond roughly to when the artifacts occur, then cable TV signal is
the problem.

You should also be using the "-cache 8192" option with mplayer to
mitigate the effects of any buffer delivery jitter or TS stream
corruption.

BTW, MythTV is very good at smoothing over the rough spots on which
mplayer chokes.

Regards,
Andy

> thanks for any help,
> dan



_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: cx18 video corruption [ In reply to ]
danimal at agriroots
Oct 1, 2009, 8:20 PM
Post #3 of 4 (2584 views)
Permalink
Andy Walls <awalls@radix.net> writes:

> Dan,
>
> On Wed, 2009-09-30 at 22:33 -0400, Daniel Flesner wrote:
>> i have an hvr-1600 that i'm trying to get working with local cable's
>> free HD channels. it mostly works very nice (thanks andy), but the video
>> has small corruptions in it. if i look at the dmesg i have errors like:
>>
>> cx18-0: warning: failed to be awakened upon RPU acknowledgment sending
>> CX18_CPU_DE_SET_MDL; timed out waiting 14 msecs
>> cx18-0: warning: failed to be awakened upon RPU acknowledgment sending
>> CX18_CPU_DE_SET_MDL; timed out waiting 11 msecs
>> cx18-0: warning: failed to be awakened upon RPU acknowledgment sending
>> CX18_CPU_DE_SET_MDL; timed out waiting 14 msecs
>> cx18-0: warning: failed to be awakened upon RPU acknowledgment sending
>> CX18_CPU_DE_SET_MDL; timed out waiting 15 msecs
>
> Those are actually harmless. Those are outgoing empty buffers being
> handed back to the CX23418 firmware. They are taking a long time to get
> acknowledged which happens because:
>
> 1. The CX23418 didn't immediately acknowledge the buffer handover.
> That's normal, and in practice, I've found it doesn't happen frequently,
>
> and
>
> 2. When the cx-18-0-out/n thread goes to sleep waiting on the
> acknowledgment from the firmware, and the firmware causes the IRQ
> handler to send a wake-up, the linux *scheduler* takes a long time to
> put cx18-0-out/n back into a running state.
>
>
> What has normally happened is that the CX23418 firmware actually has
> acknowledeged the bufffer handover, but the cx18-0-out/n thread didn't
> get notified until much later.
>
> So unless you get a solid stream of these messages, this warning message
> is harmless in terms of cx18. What it does indicate is that at least
> one of your CPU cores (the one running the cx18-0-out/n thread in
> question) is very busy and/or the scheduler isn't doing a very good job.
> 15 ms is kinda of long to be asleep, but I've seen 10 ms many times
> before with my Fedora 10 setup.
>
>
> Please turn on debug info warn and mailbox in the cx18 driver and note
> how often you get the "Possibly falling behind" warning. That's the one
> that's indicative of potential incoming video processing delays by your
> system.

i turned on more debug info and only got a single warning on the
recording tonight.

>
>
>> i'm running fedora 11 with the latest kernel, i tried updating the
>> v4l-dvb driver, but the behavior seems the same.
>
> Indicative of a system level issue vs. a driver level one.
>
>
>> i read a while back about interrupt problems, the interrupt info for my
>> machine is:
>>
>> cat /proc/interrupts
>> CPU0 CPU1 CPU2 CPU3
>> 0: 281 111 234 191 IO-APIC-edge
>> timer
>> 1: 1 1 0 0 IO-APIC-edge
>> i8042
>> 8: 7 8 16 13 IO-APIC-edge
>> rtc0
>> 9: 0 0 0 0 IO-APIC-fasteoi
>> acpi
>> 12: 0 2 2 0 IO-APIC-edge
>> i8042
>> 16: 220827 129818 98284 46306 IO-APIC-fasteoi
>> uhci_hcd:usb3, uhci_hcd:usb8, nvidia
>> 17: 2586763 2548712 1974642 1930591 IO-APIC-fasteoi
>> cx18-0
>> 18: 118657 53841 124164 64003 IO-APIC-fasteoi
>> ehci_hcd:usb1, uhci_hcd:usb7
>> 19: 0 0 0 0 IO-APIC-fasteoi
>> uhci_hcd:usb6
>> 20: 1673 241 823 486 IO-APIC-fasteoi
>> firewire_ohci
>> 21: 0 0 0 0 IO-APIC-fasteoi
>> uhci_hcd:usb4
>> 22: 20843 5755 23756 7796 IO-APIC-fasteoi HDA
>> Intel
>> 23: 1594911 1485736 1468820 1426265 IO-APIC-fasteoi
>> ehci_hcd:usb2, uhci_hcd:usb5
>> 27: 1095 1095 1607156 1306382 PCI-MSI-edge
>> ahci
>> 28: 60 9700117 54 60 PCI-MSI-edge
>> eth0
>> NMI: 0 0 0 0 Non-maskable
>> interrupts
>> LOC: 71028778 71198700 68479506 66790971 Local timer
>> interrupts
>> SPU: 0 0 0 0 Spurious interrupts
>> RES: 873725 646350 996161 709235 Rescheduling
>> interrupts
>> CAL: 12575 10193 10957 11134 Function call
>> interrupts
>> TLB: 691919 910061 754828 948509 TLB shootdowns
>> TRM: 0 0 0 0 Thermal event
>> interrupts
>> THR: 0 0 0 0 Threshold APIC
>> interrupts
>> ERR: 0
>> MIS: 0
>>
>> it looks to me that the cx18 has it's own interrupt, so i guess that's
>> not the problem?
>
> That's correct in that no other linux driver in particular is directly
> to blame.
>
> I notice that your interrupts are generally balanced, but there is an
> assymetry between CPU0/1 and CPU2/3 (execpt for a different assymetry
> with the USB hubs).
>
> That might explain why the cx18-0-out/n thread is held off for a "long"
> time at times, but again, that's nothing to worry about.
>
>
>> also, here's the driver initialization log:
>>
>> cx18: Start initialization, version 1.2.0
>> cx18-0: Initializing card 0
>> cx18-0: Autodetected Hauppauge card
>> cx18-0: info: base addr: 0xf4000000
>> cx18-0: info: Enabling pci device
>> cx18 0000:01:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
>> cx18-0: info: cx23418 (rev 0) at 01:00.0, irq: 17, latency: 64, memory: 0xf4000000
>> cx18-0: info: attempting ioremap at 0xf4000000 len 0x04000000
>> cx18-0: cx23418 revision 01010000 (B)
>> cx18-0: info: GPIO initial dir: 0000ffff/0000ffff out: 00000000/00000000
>> cx18-0: info: activating i2c...
>> cx18-0: Autodetected Hauppauge HVR-1600
>> cx18-0: info: NTSC tuner detected
>> cx18-0: Simultaneous Digital and Analog TV capture supported
>> IRQ 17/cx18-0: IRQF_DISABLED is not guaranteed on shared IRQs
>> tuner 2-0061: chip found @ 0xc2 (cx18 i2c driver #0-1)
>> cs5345 1-004c: chip found @ 0x98 (cx18 i2c driver #0-0)
>> cx18-0: info: Allocate encoder MPEG stream: 64 x 32768 buffers (2048kB total)
>> cx18-0: info: Allocate TS stream: 32 x 32768 buffers (1024kB total)
>> cx18-0: info: Allocate encoder YUV stream: 16 x 131072 buffers (2048kB total)
>> cx18-0: info: Allocate encoder VBI stream: 20 x 51984 buffers (1015kB total)
>> cx18-0: info: Allocate encoder PCM audio stream: 256 x 4096 buffers (1024kB total)
>> cx18-0: info: Allocate encoder IDX stream: 32 x 32768 buffers (1024kB total)
>> cx18-0: Registered device video0 for encoder MPEG (64 x 32 kB)
>> DVB: registering new adapter (cx18)
>> cx18-0: DVB Frontend registered
>> cx18-0: Registered DVB adapter0 for TS (32 x 32 kB)
>> cx18-0: Registered device video32 for encoder YUV (16 x 128 kB)
>> cx18-0: Registered device vbi0 for encoder VBI (20 x 51984 bytes)
>> cx18-0: Registered device video24 for encoder PCM audio (256 x 4 kB)
>> cx18-0: Initialized card: Hauppauge HVR-1600
>> cx18: End initialization
>> cx18 0000:01:00.0: firmware: requesting v4l-cx23418-cpu.fw
>> cx18-0: loaded v4l-cx23418-cpu.fw firmware (158332 bytes)
>> cx18 0000:01:00.0: firmware: requesting v4l-cx23418-apu.fw
>> cx18-0: info: load segment a00000-a07fff
>> cx18-0: info: load segment ae0000-ae00ff
>> cx18-0: info: load segment b00000-b1a65f
>> cx18-0: loaded v4l-cx23418-apu.fw firmware V00120000 (141200 bytes)
>> cx18-0: info: 1 MiniMe Encoder Firmware 0.0.74.0 (Release 2007/03/12)
>> cx18-0: FW version: 0.0.74.0 (Release 2007/03/12)
>> cx18 0000:01:00.0: firmware: requesting v4l-cx23418-cpu.fw
>> cx18 0000:01:00.0: firmware: requesting v4l-cx23418-apu.fw
>> cx18-0: info: load segment a00000-a07fff
>> cx18-0: info: load segment ae0000-ae00ff
>> cx18-0: info: load segment b00000-b1a65f
>> cx18-0: info: 1 MiniMe Encoder Firmware 0.0.74.0 (Release 2007/03/12)
>> cx18 0000:01:00.0: firmware: requesting v4l-cx23418-dig.fw
>> cx18-0 843: loaded v4l-cx23418-dig.fw firmware (16382 bytes)
>> cx18-0 843: verified load of v4l-cx23418-dig.fw firmware (16382 bytes)
>> cx18-0: info: Changing input from 1 to 0
>> cx18-0: info: Mute
>> cx18-0 843: info: decoder set video input 7, audio input 8
>> cx18-0 843: info: decoder set video input 7, audio input 8
>> cx18-0: info: Unmute
>> cx18-0: info: Switching standard to 1000.
>> cx18-0 843: info: changing video std to fmt 1
>> cx18-0 843: info: PLL regs = int: 15, frac: 2876158, post: 4
>> cx18-0 843: info: Video PLL = 107.999999 MHz
>> cx18-0 843: info: Pixel rate = 13.499999 Mpixel/sec
>> cx18-0 843: info: ADC XTAL/pixel clock decimation ratio = 2.121
>> cx18-0 843: info: Chroma sub-carrier initial freq = 3.579545 MHz
>> cx18-0 843: info: hblank 122, hactive 720, vblank 26, vactive 481, vblank656 38, src_dec 543, burst 0x5a, luma_lpf 1, uv_lpf 1, comb 0x66, sc 0x087c00
>>
>>
>> was wondering what else i can do to fix or help fix the problem, the
>> jitter can get annoying and sometimes mplayer crashes with corrupted
>> video and/or audio packets from the capture file.
>
>
> This sounds like a cable signal level problem. When capturing, please
> run femon in a terminal window and look for periods where the
> uncorrectable block count increases. If you get those, and the
> correspond roughly to when the artifacts occur, then cable TV signal is
> the problem.

i ran femon during the capture tonight and did get what looks like some
bit errors. it ran predominately with the ber 0's messages, but once in
a while with the ber set to a non 0 value as below:

status 1f | signal 013a | snr 0138 | ber 00000000 | unc 00000000 |
FE_HAS_LOCK
status 1f | signal 013a | snr 013a | ber 00000000 | unc 00000000 |
FE_HAS_LOCK
status 1f | signal 0138 | snr 0138 | ber 00000000 | unc 00000000 |
FE_HAS_LOCK
status 1f | signal 013a | snr 013a | ber 00000276 | unc 00000276 |
FE_HAS_LOCK

so it appears it is a signal quality issue. i need an external amplifier
then i suppose? i did add a splitter and an extra line for the digital
input when i got the hvr1600 so maybe that is the issue. the splitter is
rated to 2300Mhz so that is fine right? what are acceptable values for
the signal and/or snr above?

>
> You should also be using the "-cache 8192" option with mplayer to
> mitigate the effects of any buffer delivery jitter or TS stream
> corruption.

i do run mplayer with the cache flag.

>
> BTW, MythTV is very good at smoothing over the rough spots on which
> mplayer chokes.
>
> Regards,
> Andy
>
>> thanks for any help,
>> dan
>

thanks again,
dan

>
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users
>

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: cx18 video corruption [ In reply to ]
awalls at radix
Oct 2, 2009, 5:11 PM
Post #4 of 4 (2588 views)
Permalink
Dan,

On Thu, 2009-10-01 at 23:20 -0400, Daniel Flesner wrote:
> Andy Walls <awalls@radix.net> writes:
.

> i turned on more debug info and only got a single warning on the
> recording tonight.

OK. CPU and interrupt performance are not your problem.


> >>
> >> was wondering what else i can do to fix or help fix the problem, the
> >> jitter can get annoying and sometimes mplayer crashes with corrupted
> >> video and/or audio packets from the capture file.
> >
> >
> > This sounds like a cable signal level problem. When capturing, please
> > run femon in a terminal window and look for periods where the
> > uncorrectable block count increases. If you get those, and the
> > correspond roughly to when the artifacts occur, then cable TV signal is
> > the problem.
>
> i ran femon during the capture tonight and did get what looks like some
> bit errors. it ran predominately with the ber 0's messages, but once in
> a while with the ber set to a non 0 value as below:
>
> status 1f | signal 013a | snr 0138 | ber 00000000 | unc 00000000 |
> FE_HAS_LOCK
> status 1f | signal 013a | snr 013a | ber 00000000 | unc 00000000 |
> FE_HAS_LOCK
> status 1f | signal 0138 | snr 0138 | ber 00000000 | unc 00000000 |
> FE_HAS_LOCK
> status 1f | signal 013a | snr 013a | ber 00000276 | unc 00000276 |
> FE_HAS_LOCK
>
> so it appears it is a signal quality issue.

Yup. Granted the mxl5005s tuner driver needs some tweaking (it's got 3
dB of loss for cable that we could probably get back, if I had access to
MaxLinear datasheets and programming manuals), but there are other steps
to take.

BTW, the s5h1409 driver shouldn't be erasing the unc block count back to
0 after every read. If it is, I'll have to fix it.


> i need an external amplifier
> then i suppose? i did add a splitter and an extra line for the digital
> input when i got the hvr1600 so maybe that is the issue. the splitter is
> rated to 2300Mhz so that is fine right?

Please read:

http://www.ivtvdriver.org/index.php?title=Howto:Improve_signal_quality&action=history

and remember that overdriving the tuner's front end with too much
amplification can also degrade reception.


2.3 GHz should be fine (above L-band for sure, into S-band (?)). I
don't know what your cable company uses for channel allocation, but I
doubt they go that high.


> what are acceptable values for
> the signal and/or snr above?

It depends. First I have to see what the values the mxl5005s and the
s5h1409 driver are putting out mean, then I'll have to look up the
theoretical SNR for QAM-256 an quasi-error free reception (BER < 10^-12)
at various data rates. It may take me a few days.

> >
> > You should also be using the "-cache 8192" option with mplayer to
> > mitigate the effects of any buffer delivery jitter or TS stream
> > corruption.
>
> i do run mplayer with the cache flag.

OK. You simply have a signal quality problem that results in corrupt
packets that mplayer chokes on.


> thanks again,
> dan


You're welcome.

Andy



_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal