SAA7135 ADC vs YUV and RGB color, and Dscaler vertical capture size.

[eluniqo]

CAN MOD MOVE THREAD TO PROGRAMMING-DEVELOPMENT if possible? SORRY!

Thank you for this forum and welcoming me here. Great information from very intelligent community!

Recently ordered SAA7135 based capture card for PC. I find it interesting it only has 9 bit ADC. Why only 9 bits after more than six years evolving?! That is only one bit more than really old bt8x8!

My question. Does it matter if I capture to RGB 4:4:4 24-bit or YV12 12-bit? Is it redundant because ADC is only 9-bits? Does chroma sampling relate to ADC at all? Does the ADC always output RGB 4:4:4 24-bits? I looked in some datasheets and they imply multiple formats supported (including RGB). Maybe the ADC is 9bit because of its ADC accuracy but I don't know.

I'm looking forward to the saa7135. According to abstract it has 3D comb filter for CVBS. I'm hoping it works with Dscaler and Linux with ways to disable AGC and enlarge capture window size without scaling.

When I receive the card (if I do and if it works when I do :) ) I want to run some tests and hope to share my results with all of you!

Thank you

[TheSkiller]

Does it matter if I capture to RGB 4:4:4 24-bit or YV12 12-bit?It matters in the sense that RGB is never the native format of an analogue capture (well, there is analogue RGB via Scart but hardly any capture card supports it and most likely you intend to capture CVBS and S-Video signals, right?). All analogue signal formats except RGB handle luminance and chrominance independently, hence the most natual thing to sample from such a signal is a digital equivalent of it.

The ADC's native format should be YUY2 or some relative of it (like UYVY). If you request anything else during capture the color space will simply get converted after ADC which is not recommendable.

The ADC will sample the signal to 9 bits per channel internally and then downsample it in some way to output regular 8 bits per channel video. You cannot capture those 9 bits but that doesn't mean the video will be like that from a native 8 bit ADC like the old bt8x8.


By the way, when it comes to RGB do not let yourself get confused by it's 24 bits. It's actually 8 bit per channel; 3 times 8 equals 24. ;)

[eluniqo]

So the card does sample to RGB internally? 27 bit RGB to be precise (because of the 9bit adc, and I'll try not to let that 8bit per channel fool me :) )? I always thought ADC bits described precision of sampling analog to digital before it even gets demodulated into pixels (I'm thinking like 27mhz or something like that).

I'm just a bit worried because I have right now a pvr-150 and it produces YV12 (actually a bit flipped version of yv12 aka HM12). It has two chips: cx25843 and cx2416. CX25843 uses 10-bit adc's for video; can use one for luminance and the other for chrominance selectively, or one for both. It also produces 4:2:2, and it oversamples before conversion to theoretically prevent loss from subsampling. But I believe the 4:2:2 pixels are passed to the cx2416 for even further subsampling to 4:2:0 hm12 (yv12 with bit flipped), to be compliant with DVD before encoding to mpeg2; because at the very end you only get HM12 4:2:0 lossless, and mpeg2.

The pvr-150 may be interesting to some folks and maybe the info may be useful to some, but it bugs me that it subsamples twice down to 4:2:0. It's also very hard to convert HM12 to yv12 under Windows (still haven't found the ffdshow codec with HM12 support; maybe it's gone?); it's much more doable and preferable in Linux, but you must like the command line :) . It has all the registers accessible in Linux too, so agc can be disabled, vblank adjusted, and literally everything on the cx25843 (it has a 2D 5 line comb filter with several registers to play with). But at the very end you end up with 4:2:0 samples, and it does look good. The svideo quality is very sharp and there's no filters or anything; you can actually disable all filters and shutdown the encoder and other stuff in Linux. But like I said the card doesn't seem very flexible with chroma sampling, and I'm stuck with a horizontal width of 720 pixels.

I'm hoping the saa7135 will alleviate the 4:2:0 with the pvr-150. I think the pvr-150 is very good, but it subsamples to 4:2:0, and I'm stuck at 720 horizontal pixels.

Will the saa7135 allow me register access like the pvr-150? I can't have AGC (or any other like chroma agc), and I must have manual adjustment to all gains. I hate AGC...

Really grateful for the help!

[TheSkiller]

So the card does sample to RGB internally?No, it does not. Like I've said the analogue input signal consists of the luminance (think of it like a black and white picture) and the chrominance (the layer of colors to be overlaid on the black and white picture to make it a color picture). Digital formats like YUY2 and YV12 also do that, RGB does not. So the analogue signal gets translated intro a YCbCr based format, usually YUY2 (4:2:2 color subsampling), because that's what the analogue signal is most similar with.
In other words, the signal cannot even be translated into RGB before sampling it in a YCbCr based format.

With the PVR-150 you get YV12 because of it's built-in hardware MPEG2 encoder.


I always thought ADC bits described precision of sampling analog to digital before it even gets demodulated into pixelsWhenever bits are involved you already have pixels. The bits of an ADC define the gradation between the lowest signal amplitude (say, a black picture) and the highest (say, a white picture). With 9 bits there is a maximum of 512 steps (per channel) to store the gradation.


and I'm stuck with a horizontal width of 720 pixelsThis is the maximum horizontal resolution you will get from any ADC capturing an analogue SD signal. It's what you get from the standard 13.5 MHz (and multiples of it) sampling of the signal.

[eluniqo]

Okay so it does keep luminance and chrominance native internally. And it should give me better quality since it doesn't subsample beyond 4:2:2, and perhaps even better if the datasheet abstract is accurate. It even has the 3D comb filter.

My only thing to worry about now is the AGC and horizontal pixel adjustment. Even if I only get 720 horizontal pixels, I'm hoping I can adjust vertical blank to move center of screen. If this stuff is doable with dscaler and/or Linux I'm fine with that.

[eluniqo]

PREPARE FOR LONG TALK!

Received atsc 110 Kworld hybrid card (ATSC and analog). It gets real hot! I've never neen PVR-150 get this hot and that has mpeg2 encoder. I touch metal on rca plug and it is burning hot :eek:! Why so hot??

Support under linux actually exploits what's in the datasheet. You can indeed capture to BGR4 (32 bpp RGB little-endian), in addition to yuy2, bgr3, and a bunch of others (including grey-scale)! I'm not sure what the best option is according to datasheet, but obviously the saa713x chips are extremely versatile. This is way better than ATI's chips up to the 750 which have 12-bit ADC, or even the connexant chips (correct me if I'm wrong but the best connexant chips only allow 4:2:2 max colorspace). Whether or not the phillips saa713x chips upsamples 4:2:2 to RGB is unclear to me though, but the datasheet does indeed say it supports capture to RGB.

Under dscaler I tested saa7135 (ATSC 110 Kworld) and set comb filter to full. It only seems to work as 2D comb filter, but a really good 2D comb filter! It looks almost 3D with no motion artifacts so that is very good. Very small dot crawl on still motion but hardly any, and really sharp resolution! With temporal software filter enabled it looks like really good 2D cf with really good 3D cf, so basically sharp RGB. That's really good!

Problem with dscaler is too much cropping of vertical resolution. Dscaler is very nice to allow image adjustment (vdelay-hdelay) but only 480 vertical pixels are captured. There are at least 6 pixels cropped because of this limitation. Otherwise thanks to dscaler authors I can disable AGC, white and color peak, and keep image information flat like it should be, and capture like a normal human. Seems very stable too (dscaler 4.2.2)!

If someone can help me edit Dscaler source code to capture 512 or 544 vertical resolution that'd be great! Even better if I can capture to RGB without conversion (according to datasheet the saa713x does support capture to RGB output). Dscaler isn't really a problem TBH. But I've tried editing source code in saa713*.cpp and saa713*.h files to no avail. Changed 480 instances to 512, but dscaler insists on 480 vertical pixels. I'm sure this could be done in Linux but that is really hard and I must dig through lots of source code and edit; not to mention I have to further dig to alter AGC registers and other dirtyness.

So far the saa713x is a really good chip! Fortunately something like dscaler was produced for manual AGC and other nice settings for real PC capturing! Thank you the most to dscaler authors! Hopefully someone can help me edit dscaler source code to get 512 or 544 vertical pixels to capture without croppage.

[ChiDragon]

NTSC video has 525 total lines, not 544. If the driver allowed 486 you would get all active video lines, and then some. With 512 you would get all of the VBI lines that can potentially carry information, too. I've never seen this number used before; apparently some Avid ingest hardware can accommodate it? I don't think most cards will allow you to access the VBI as image data, because they do their own VBI slicing (http://linuxtv.org/downloads/v4l-dvb-apis/sliced.html).

[eluniqo]

NTSC video has 525 total lines, not 544. If the driver allowed 486 you would get all active video lines, and then some. With 512 you would get all of the VBI lines that can potentially carry information, too. I've never seen this number used before; apparently some Avid ingest hardware can accommodate it? I don't think most cards will allow you to access the VBI as image data, because they do their own VBI slicing (http://linuxtv.org/downloads/v4l-dvb-apis/sliced.html).

Yes that is true, but the capture window size can be expanded in multiples of 32. If I expand to exactly 525 lines it won't be very possible to transcode to other formats (xvid, mpeg2, x264, etc). 512 is probably best if no more vertical pixels left.

576 vertical pixels in linux with cx25843+cx23416 example with cartoon commercial-preview:
taken down for possible infringement even though it is a commercial preview...


This brings me to another problem with saa7135 in dscaler that is a bigger priority. I found it's very bad at scaling! It is very blurry and loses resolution with digital video essentials. I don't think it's outputting square pixels. There seems no way to deliver square pixels either. Tried changing horizontal width to 720, 640, 768, but they're all ugly! 720 seems to look best but it's still scaling to ugly output. Datasheet doesn't explain this well and it seems very unlikely I can get it in Linux (too hard or not enough time).

[ChiDragon]

If I expand to exactly 525 lines it won't be very possible to transcode to other formats (xvid, mpeg2, x264, etc).
I don't get it; why would you ever want to transcode the VBI anyway? Seems like the goal would be to decode it and store anything useful as metadata, not harm its usefulness with lossy compression.

Interesting screenshot, thanks. I'm confused why it's showing horizontal data from outside the visible video area in a 720-width image. And does that chip ignore Macrovision in Linux?

[eluniqo]

I don't think it ignores macrovision in Linux. Many codecs expect multiples of 32 so that's why 512 or 544 vertical pixels is better than 525 or 486; better compatibility is superior IMO, and capturing VBI is only a side effect of that (it is useful though and it can be cropped later anyway). Some codecs are okay with only powers of 2 but not many (mpeg2 works okay usually, but others show corruption). And the horizontal pixels have the same problem as vertical pixels, because sometimes there's extra portions beyond 720 horizontal pixels (sometimes up to 740!).

[ChiDragon]

I don't think it ignores macrovision in Linux.
Oh, I thought the grey bars at the top of the VBI were Macrovision pulses (http://upload.wikimedia.org/wikipedia/commons/f/fc/Macrovision_in_PictureMonitor.jpg) in mid-brighten.

And the horizontal pixels have the same problem as vertical pixels, because sometimes there's extra portions beyond 720 horizontal pixels (sometimes up to 740!).
So I guess you expanded the capture window (http://www.doom9.org/index.html?/capture/capture_window.html) but aren't able to change the number of captured pixels accordingly? I have no experience with what Linux allows.

[zerowalker]

Haven't read it all, but will state some things as i have done some research on capturing as i myself do it quite a bit.

9bit ADC is used internally, you can think of it as an increase to prevent rounding errors building up, as Analogue isn't in any Bit depth you could capture 20bit.
But as it's originally had (or rather what was recorded) is 8bit it doesn't make much sense to get all that "noise" of information, hence the low jump by 1 bit just to get the work doen, then output to 8 bit.

As for RGB and YUY2.

NTSC and PAL both output something that's similar to YUY2 and YV12 (or 4:2:2/4:2:0).

For easier terms, you can think that NTSC is YUY2 and PAL is YV12 cause it discards every other chroma line.

I probably have a very similar card to yours, CX23880, it's Okay but i had some serious issues with it's "White Crush" function which could only be accessed with DScaler,
and it's messing around with the brightness all the time, and if you turn it of, it will Crush the contrast instead (the name of the function pretty much contradicts what it does).
No idea what it's supposed to be, i guess it's some kind of Luma AGC that' just not working properly.
Hopefully you don't have it.

[eluniqo]

Thank you all for your help. It seems the cx23880-3 is much better option. It can capture the raw ADC in Windows. It's more flexible. Thanks.

[zerowalker]

Thank you all for your help. It seems the cx23880-3 is much better option. It can capture the raw ADC in Windows. It's more flexible. Thanks.

It can?

Never tried that, if that applies to my card.
Then again i think Jmac or what his name was, talked about this quite a while back. I think it was limited to Windows XP 32bit, so never got to try it out, but from my understanding quite some neat stuff could be done as you could get the raw data.

Would be interesting to hear about if you get it.