[ivtv-users] cx18 video corruption

[Andy Walls]

Dan,

On Thu, 2009-10-01 at 23:20 -0400, Daniel Flesner wrote:
> Andy Walls <awalls at 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