Re: Is anyone else running a CX18 in 64bit OS?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 2008-05-10 at 09:09 -0400, Brandon Jenkins wrote:
> On Fri, May 9, 2008 at 9:48 PM, Andy Walls <awalls@xxxxxxxxx> wrote:
> > On Fri, 2008-05-09 at 21:10 -0400, Brandon Jenkins wrote:
> >> On Fri, May 9, 2008 at 8:14 PM, Andy Walls <awalls@xxxxxxxxx> wrote:
> >> > On Fri, 2008-05-09 at 15:55 -0400, Brandon Jenkins wrote:
> >> >
> >> > Brandon,
> >> >
> >> > Yes I'm running the cx18 driver with an HVR-1600 on a 64 bit OS.
> >> >
> >> >> I have noticed an appreciable difference in video capture quality.
> >> >
> >> > The first analog capture after a modprobe of the cx18 is usually
> >> > terrible and unwatchable due to apparently lost frames or no initial
> >> > audio followed by audio and lost frames.  The work around is to stop the
> >> > analog capture and restart.
> >> >
> >> > Would you characterize the analog capture quality problems as being only
> >> > on weak channels or strong channels as well?
> >> >
> >> >>  The
> >> >> timeline for the change is exactly the same time that development
> >> >> ceased on the IVTV version of CX18 and moved to V4L.
> >> >
> >> > I'm not clear on exactly what versions you mean.  Do you have hg
> >> > repository names and change ID's?
> >> >
> >> >
> >> >>  I see heavy
> >> >> pixelation in analog capture and the dvb tuner module returns far
> >> >> fewer channels on a scan than before. I would like to troubleshoot,
> >> >> please let me know what is needed.
> >> >
> >> >
> >> > Since you have the two particular source trees at hand, could you do a
> >> > recursive diff so we can see the changes?  That hopefully will narrow
> >> > the search for potential causes.
> >> >
> >> > Regards,
> >> > Andy
> >> >
> >> >> I am attaching dmesg/channel.conf/channel scan output for v4l drivers
> >> >> comparing the results from a cx18 and a cx23885 card. (hvr-1600 and
> >> >> hvr-1800) If I switch back to the older ivtv and mxl500s dvb tuner all
> >> >> works fine.
> >> >>
> >> >> Thanks in advance
> >> >>
> >> >> Brandon
> >> >
> >> >
> >> >
> >> Andy,
> >>
> >> Thanks for the response.
> >>
> >> I am running the following command in rc.local to start a capture and
> >> then kill it.
> >>
> >> cat /dev/video3 > /dev/null & sleep 8 && kill $!
> >>
> >> Is that sufficient for an initial capture?
> >
> > Without testing it, I'm going to say, I imagine it would be from the
> > look of it.
> >
> >
> >> I am recording via svideo from a DirecTV signal. All signal levels are
> >> consistent.
> >
> > OK.  I looked at the cx28885 channels.conf, after I sent the questions,
> > and noticed you didn't have terrestrial over the air source.  I saw you
> > have the same local channels on QAM that I get over 8-VSB: WETA-HD,
> > WUSA-HD, 9-Radar, CW50, etc.
> >
> >> The driver base which works for me is cx18-8788bde67f6c it is the
> >> older cx18-ivtv branch
> >
> > This is precisely the version (with a small change for auto chroma
> > subcarrier locking) that I use when I need to leave my machine with a
> > reliable cx18 driver with digital capability for use with MythTV.
> > ("General Hospital" *must* be recorded properly daily!)
> >
> >
> >> The version I am having issues with was built from a v4l-dvb pull this morning.
> >>
> >> I did not mention this in my email but it was in the log files; I am
> >> scanning QAM for DVB. With the mxl500x.ko frontend everything works
> >> well. With mxl5005s.ko in the new v4l-dvb scanning is broken.
> >
> > OK.  Steve just introduced that mxl5005s driver from a separate code
> > base.  I've copied him on this e-mail to let him know of the problem.
> >
> > I'll have to do the pull and test scanning my 8VSB stations.

OK.  I did a scan this morning with the old cx18-mxl500x driver
combination.  After numerous household obligations, I finally built the
latest v4l-dvb (twice, the first time I forgot to make distclean and
didn't have the mxl5005s) and did another scan.

The result: the diff shows three less 8VSB channels/streams showing up
with the new driver, but there all on the same frequency for WUSA 9 in
Washington, D.C.  I've attached the scans.  Here's a short excerpt from
the diff:

-dumping lists (18 services)
+dumping lists (15 services)
 Done.
 WFDC DT:479028615:8VSB:49:52:3
 MHz1:569028615:8VSB:49:52:1
@@ -1531,9 +1545,6 @@
 MHz5:569028615:8VSB:113:116:5
 WHUT-DT:587028615:8VSB:17:20:1
 WHUT-TV:587028615:8VSB:0:0:65535
-WUSA-HD:593028615:8VSB:49:52:1
-9-Radar:593028615:8VSB:65:68:2
-WUSA-TV:593028615:8VSB:0:0:65535
 WDCA DT:599028615:8VSB:49:52:3
 WTTG DT:605028615:8VSB:49:52:3
 WJLA-HD:623028615:8VSB:49:52:3

The really funny thing is that WUSA is typically a strong analog signal
and I believe the strongest digital signal I receive.  (I wonder if my
broadband TV amplifier's gain is set too high?)

According to the digital diagnostics on my Sony big screen right now, TV
channel 9.1 is at 593000 kHz with a SNR of 24 dB (signal power is 250
times that of the noise power!) and the tuner's AGC is at 23%.


> > -Andy
> >
> >> rdiff -r cx18-8788bde67f6c v4l-dvb output attached.
> >>
> >> Brandon
> >
> >
> Andy,
> 
> I can also switch over to my roof antenna and scan. I'll do that
> today. Are you doing any analog capture and are you seeing any
> pixelation/blocking? 

Nope, none.  I used:

 $ mplayer -cache 16384 /dev/video1

On strong and weak channels with no difference and no artifacts.  If I
use -cache 8192, mplayer gripes a little about my system not being able
to keep up, but the up arrow resyncs everything.

For reference,  v4l-ctl -d /dev/video1 --log-status shows:

   cx18-0: Video:  720x480, 30 fps
   cx18-0: Video:  MPEG-2, 4x3, Variable Bitrate, 6000000, Peak 8000000
   cx18-0: Video:  GOP Size 15, 2 B-Frames, GOP Closure
   cx18-0: Audio:  48 kHz, Layer II, 224 kbps, Stereo, No Emphasis, No CRC
   cx18-0: Spatial Filter:  Manual, Luma 1D Horizontal, Chroma 1D Horizontal, 0
   cx18-0: Temporal Filter: Manual, 8
   cx18-0: Median Filter:   Off, Luma [0, 255], Chroma [0, 255]

If the encoder made any blocks at all with no scaling (720x480) and a
peak rate of 8 Mbps, I'd be surprised.

> I have a 46MB/60sec sample capture that
> demonstrates it if interested.
> 
> The pixelation/blocking is not present in the older cx18-8788bde67f6c build.

Hmmm.  What is your analog source?  If it's the tuner, can you
qualitatively describe the elements of the scene (people, sports, news,
high movement, low movement, etc.) and the SNR (strong, weak, really
crappy).

Does the blocking happen with the line in (use a DVD player or VCR)?

What are the image size and bit-rate you have set?

I'll pass on the file download.  My 56 kbps modem isn't the straw I'd
really like to suck 46 MB through if I don't have too. ;)



By the way, despite not being able to scan the channel:

 $ mplayer dvb://9-Radar

Works just fine using my old channels.conf and so does

 $ mplayer dvb://WUSA-HD -vf scale=960:540

(I don't have a screen large enough for the full 1920x1080 to display
properly)


Regards,
Andy

> Regards,
> 
> Brandon

Attachment: cx18-mxl500-scans.tar.bz2
Description: application/bzip-compressed-tar

_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[Index of Archives]     [Linux Media]     [Video 4 Linux]     [Asterisk]     [Samba]     [Xorg]     [Xfree86]     [Linux USB]

  Powered by Linux