Which TV capture card to buy?

[John-Mark Gurney]

Dieter wrote this message on Fri, Jun 01, 2007 at 12:19 +0100:
> > > > The driver for the cx2388x appears to work,
> > > 
> > > Cool, so you have NTSC working?  Is the driver available for beta testing?
> > 
> > With all the programming here available over ATSC (and it looks and
> > sounds SOOOO much better than NTSC), I haven't even bothered/attempted
> > to do NTSC...
> 
> Some PBS stations have different programming on NTSC and ATSC, so
> we need both.

Ours too, but if you have a pvr (I have my own working backend), you
can get the same programming at another time in digital...

> Some stations compress the ATSC subchannels so much that NTSC
> has more resolution/detail.  There are only enough bits for one
> HD or 2 SD, but some stations have 1 HD plus 2 or 3 SD, or
> no HD and 4-6 SD.  :-(

Yep, the ABC and NBC now broadcast a very low bitrate weather/traffic
channel, though KQED (PBS) is the only one that attempts to broadcast
three full SD along w/ their HD broadcast...  I do make use of ABC's
rebroadcasting World News while HD Jeopardy is showing...  One card,
two programs.. :)

I can see how NTSC could be better than some of the SD addon broadcast,
but my analog reception is poor enough that even the low bitrate is
better than the snow and regular interference...

> > > > but the people over at
> > > > linux-dvb don't seem to know anyone to help figure out why my ATI HDTV
> > > > Wonder doesn't work very well..
> > > 
> > > Is it the ATSC demodulator chip that isn't working?
> > 
> > Yes, and I'm not sure why... I am able to get a trickle of data out
> > of the card, and it is valid, in that I get the TVCT table that has
> > data, but when I do, I only get about 100kB/sec, definately not the
> > 2.5MB/sec I'm suppose to...
> 
> Could it be that the ATSC demodulator chip is filtering out some of
> the PIDs?

Lets see:
-bash-2.05b$ ./capapp.py -c 29 -o /b/work/bleh.ts
Tuned to channel: 29
load: 0.69  cmd: python 44679 [runnable] 0.02u 2.34s 7% 5068k
Bytes written: 1.32 MB
^CTotal bytes written: 1.93 MB
Capture time: 9.939
-bash-2.05b$ ../bktrauinfo/mpegts.py -l /b/work/bleh.ts 
5.1     KPIX-HD 52      49
-bash-2.05b$ ../bktrauinfo/mpegts.py -b /b/work/bleh.ts
   0    8        0.08
  48    9        0.09
  49    9584    93.59
  52    225      2.20
7424    3        0.03
7426    1        0.01
7680    1        0.01
7682    1        0.01
8187    12       0.12
8191    396      3.87

So, I'm getting data from the PAT, the PMT and both the video and audio
streams, along w/ padding packets (8191), and the TVCT (8187)..  So, if
it's doing any filtering, it's doing statistical filtering which isn't
very useful...

Less than 2 megs in almost 10 seconds is clearly not ATSC's 19.39Mbps..

The high system time of capapp.py is not due to capture, but due to the
ammount of work necessary to program the microcontroller of the
demodulator...  I have to load a 9KB firmware image over the i2c bus,
and am using the iicbb interface that is TERRIBLY cpu wasting w/ DELAYs...

> > The Linux driver also has a bug in that they don't consistantly keep
> > two registers that control serial or parallel mode for the digital
> > video input, and the linux-dvb list completely ignored the report...
> 
> Perhaps the Linux driver for a different card with the same chip
> would have different bugs?

The ATI HDTV Wonder card is the only cx2388x one that has the nxt200x
demodulator on it..  Anyways, the tuner/demodulator takes a lot longer
to tune/sync than the LGDT3303...  The only reason that I started work
w/ this card is that I had it laying around from when I started playing
w/ HDTV a couple years back...  As ATI/AMD isn't interested in supporting
it (they've closed their developer program, not like they accepted my
aplication the three or four times I applied when it was open, though
only as ATI), it's pretty much a dead card...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."