OK... that makes sense. The performance/reliability is potentially better with better DMA hardware. The capture chips are fairly comparable, IIRC. I think the cx88 has a little higher ADC resolution, and an adaptive comb filter vs. the philips one. This also clarifies my question from awhile back on why ivtv can support the 150 but not the blackbird. Basically the 150 still has the cx23416 on the PCI bus... just a combined audio/video chip.... right?OK... so the obvious question is what's the advantage of doing it that way? From your description, it sounds like the blackbird design is very similar to how the pcHDTV-2000 card operates. I'm just curious what the advantages of doing it that way would be..
The saa7134 + saa6752hs combination is also a similar beast (and is also supported in Linux, however there are fewer boards using that configuration).
The advantage of blackbird over directly coupling the cx23416 to the PCI bus is that the cx2388x has very good, rock solid, documented DMA hardware, while the DMA capabilities of the cx23416 is at times somewhat questionable. Also, the cx2388x has pretty good ADCs for the video and audio.
I guess the other question is whether or not a blackbird card is viable with MythTV now then. If so then it does open another realm of relatively inexpensive capture cards.
Is it so that it's possible to get raw uncompressed video from the cx88 chip directly?
Yes, the cx88 + blackbird driver gives you a compressed and an uncompressed video device (the cx88-blackbird just adds a compressed device to the uncompressed device you get from the cx88). As of my last modifications to the driver, there is no locking yet between the shared resources of those two devices (such as scaling and frame rate settings), and I haven't looked yet if the plutohome people addressed that issue either. So in actual use, ymmv with the state of the driver, but the hardware can do it (I've had compressed video recording running fine in parallel with xawtv when I was doing initial development).
It would be nice if the mythtv people would exploit that and create a low-latency live video mode by just showing the uncompressed video (if the frontend and backend are the same machine). Channel surfing would be much better then.I used to care more about that than I do now. Basically, when I brought it up over a year ago I got rather terse and apathetic response, "We don't need that because nobody watches livetv anymore once they get MythTV working." It's true, and I spew the same response now.
That said, it *would* be nice to make that work for low-powered machines. Drawing uncompressed video through an overlay doesn't take much oomph compared to capturing, encoding, and decoding on the fly. I think a nice set of options would be to allow three modes:
- Current mode (encode/decode for livetv)
- Display live with overlay, encode in the background. If livetv is paused, play the encoded file.
- Same as above, but disallow playback from recorded file if CPU is pegged.
Of course, my experience with software-only cards is their capture quality sucks. I've only used bttv ones, but from the datasheets there is no comb filter, so luminance resolution basically gets a big chroma notch taken out of it. That limits the effective capture resolution to about 480x480. The cx88 and its contemporary ilk seem better from the specs, but I haven't played with one.
-Cory
************************************************************************* * Cory Papenfuss * * Electrical Engineering candidate Ph.D. graduate student * * Virginia Polytechnic Institute and State University * *************************************************************************
------------------------------------------------------- This SF.net email is sponsored by Microsoft Mobile & Embedded DevCon 2005 Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows Embedded(r) & Windows Mobile(tm) platforms, applications & content. Register by 3/29 & save $300 http://ads.osdn.com/?ad_id=6883&alloc_id=15149&op=click _______________________________________________ ivtv-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ivtv-devel
