Hacked BT8xx driver to allow more capture resolutions? [Archive]

AVIL

20th March 2006, 10:45

Hi,

I've read another point of view in:

http://www.arachnotron.nl/videocap/doc/Karl_cap_v1_en.pdf

An excerpt:

Workings of
capture-chips:
rds): BT848/878 (almost all TV-ca
z. Scaling produces the needed horizontal resolutions. This
sults for PAL in the 64 µs window 1135.04 horizontal pixels. Those are sent through the
20 horizontal with correct 54/59 PAR). On this, a window is imposed which is 768 resp.
768) or 53.33 µs (for 720).
he BT-Chips digitize too much (768) or exactly correct (720).
o much for theory. The recommendations by Brooktree/Conextant are o.k. The reality
e, which the capture driver passes on, is always
ly
PAL is digitized at 17.735 MH
re
"scaler" and "Ultralock". This results in 944 pixels square format or 864 CCIR- compatible
(7
720 pixels wide.
So the resulting window is 52.0678 µs (for
S
looks different. The digitized rang
substantially smaller (about 200-300 ns less). Besides this, at 720 the scaling is complete
wrong.
That leaves only one conclusion: the drivers are wrong.

If that is correct both 768 and 720 are scaled down. Matter of choice.

Wilbert

21st March 2006, 21:15

According to the capture guide, this is not true. With the latest official Hauppauge drivers, the amount of "true" pixels is something close to 696x576 and with BTWinCap a bit more than that, I think it was 702x576.
This 696 corresponds to the capture window (the actual part of the PAL signal which is captured), but it doesn't say anything about the samplerate as AVIL says (which is much higher than 696).

You can look at it in the following way. Suppose a PAL signal is a full sinus wave with one period. You can divide that signal in as many points as you want, so the samplerate can be very high.

If the capture window is smaller than the PAL signal, then a portion of the PAL signal is captured. Thus the captured signal is a part of that sinus. But you still can divide it in as many points as you want, so the samplerate doesn't need to change.

Boulder

22nd March 2006, 07:21

This 696 corresponds to the capture window (the actual part of the PAL signal which is captured), but it doesn't say anything about the samplerate as AVIL says (which is much higher than 696).

You can look at it in the following way. Suppose a PAL signal is a full sinus wave with one period. You can divide that signal in as many points as you want, so the samplerate can be very high.

If the capture window is smaller than the PAL signal, then a portion of the PAL signal is captured. Thus the captured signal is a part of that sinus. But you still can divide it in as many points as you want, so the samplerate doesn't need to change.
OK, time for me to learn the first item of the day :)

So the point in using a width of 696 pixels with Hauppauge's drivers is due to the fact that you can add 4-pixel borders on the left and right side to get a DVD-compliant resolution without the need to resize? And in any other case it doesn't matter whether you capture 768 or 696 pixels if you just do either ITU or non-ITU based resizing?

Wilbert

22nd March 2006, 10:47

So the point in using a width of 696 pixels with Hauppauge's drivers is due to the fact that you can add 4-pixel borders on the left and right side to get a DVD-compliant resolution without the need to resize?
It's a consequence of it. But I don't see the logic in capturing less than the full PAL signal. Sometimes they capture a bit more (52.08 or 53.333) instead of 52. In that case you can capture at 704 (for 52.08) and 720 (for 53.333), crop it to 702x576 and resize it to a 4:3 format.

And in any other case it doesn't matter whether you capture 768 or 696 pixels if you just do either ITU or non-ITU based resizing?
Yes, it doesn't matter if your final format is MPEG-4 (PAR 1.0).

Boulder

22nd March 2006, 11:53

It's a consequence of it. But I don't see the logic in capturing less than the full PAL signal. Sometimes they capture a bit more (52.08 or 53.333) instead of 52. In that case you can capture at 704 (for 52.08) and 720 (for 53.333), crop it to 702x576 and resize it to a 4:3 format.

I once asked about that here : http://forum.doom9.org/showthread.php?p=396565#post396565 .

I also downsize to 672x544 and add 16-pixel borders for a nice compression boost since the caps tend to be quite noisy and don't compress too well. Is it correct to cap at 696x576, crop the black borders (if any) off and do ITU-based resizing, or is there a better way to do this? From what I can tell, I haven't been able to see any distracting A/R error.

Sorry for getting this topic slightly OT, feel free to move the post to a new thread if necessary. These capture width things are a bit confusing IMO.

Wilbert

22nd March 2006, 13:20

Oh, sorry. I think we are misunderstanding each other :) I agree that you should cap at 696x576 (and add black borders) when aiming for a 704x576 dvd.

What i meant was, that i didn't understand why the capture chip/driver would capture less than full PAL 52 µs (namely 51.56 µs).

Is it correct to cap at 696x576, crop the black borders (if any) off and do ITU-based resizing, or is there a better way to do this?
Depends how you resize and what your final format is. Could you give a concrete example?

Boulder

22nd March 2006, 13:38

Depends how you resize and what your final format is. Could you give a concrete example?
Let's assume that I've got a 696x576 capture from a regular analogue 4:3 transmission. There usually are no black borders on the left and right side (even if I capture at for example 720x576). I think this is due to the fact that the capture card scales as with my PVR-250 (which supposedly doesn't scale), I always had them in the 720x576 captures.

Then I input the file into FitCD and choose 704x576 as the source format as that's what the resolution would be after adding the 4-pixel borders on left and right. Then I set the cropping parameters - cropping at least those 4 pixels off left and right and cropping off top and bottom if there are any borders or some other crap to remove. ITU-R BT.601-4 is checked.

Then I set the destination as 704x576 (for DVD usage) and use 2 overscan blocks, which usually means that the video is resized to 672x544 and 16-pixel borders are added to each side.

That's the basic framework I've used for quite a while now.

Wilbert

23rd March 2006, 21:23

IThen I input the file into FitCD and choose 704x576 as the source format as that's what the resolution would be after adding the 4-pixel borders on left and right. Then I set the cropping parameters - cropping at least those 4 pixels off left and right and cropping off top and bottom if there are any borders or some other crap to remove. ITU-R BT.601-4 is checked.

Then I set the destination as 704x576 (for DVD usage) and use 2 overscan blocks, which usually means that the video is resized to 672x544 and 16-pixel borders are added to each side.
No, this is not correct. If you crop some stuff of your 702x576 (which equates the PAL standard) and resize to 672x544 you will change your AR. I advice you to use PARanoia from Inc: http://forum.doom9.org/showthread.php?t=101070. Here you can select the capture window.

I attached a screenshot from FitCD how to use it in this case (assuming cap at 696x576 + ITU checked). As you can see you are forces to crop a *specific* amount to get equal aspect ratio.

Note that the source and target PAR are equal (before and after cropping). Thus if you resize (and not simply scale the same about in both directions), you will mess up your aspect ratio.

source PAR:

4/3 * ([window width in µs] / 52.0 µs) * 576/696 = 4/3 * 51.56/52 * 576/696 = 1.094

target PAR:

4/3 * (52.148/52) * 576/704 = 1.094

Let's assume that I've got a 696x576 capture from a regular analogue 4:3 transmission. There usually are no black borders on the left and right side (even if I capture at for example 720x576). I think this is due to the fact that the capture card scales
No, this has nothing to do with scaling. Black borders can enter your capture in two ways: (1) it's already in the transmission (whether this is the case and the amount of it depends on the TV channel), (2) if your capture chip would use a capture window wider than 52 µs.

as with my PVR-250 (which supposedly doesn't scale), I always had them in the 720x576 captures.
Which chip/driver is used in your PVR-250?

Boulder

24th March 2006, 07:33

No, this is not correct. If you crop some stuff of your 702x576 (which equates the PAL standard) and resize to 672x544 you will change your AR. I advice you to use PARanoia from Inc: http://forum.doom9.org/showthread.php?t=101070. Here you can select the capture window.

Guess I'll have to check the program more thoroughly, I totally forgot that it existed :o I just did a really quick check in PARanoia to make sure that capping at 696x576 and adding 4-pixel borders to left and right is OK if I don't intend to resize :)

One question though: am I better off (quality-wise) capturing at for example 720x576 if I'm about to resize and use the overscan blocks, targetting for 704x576?

I've been trying to get the hang of this but looks like it's out of my league :stupid:

No, this has nothing to do with scaling. Black borders can enter your capture in two ways: (1) it's already in the transmission (whether this is the case and the amount of it depends on the TV channel), (2) if your capture chip would use a capture window wider than 52 µs.

Which chip/driver is used in your PVR-250?
Unfortunately I can't remember and I don't own the card anymore.

Wilbert

24th March 2006, 22:29

One question though: am I better off (quality-wise) capturing at for example 720x576 if I'm about to resize and use the overscan blocks, targetting for 704x576?
If you want to add vertical overscan, you will have to resize anyway. So, it doesn't matter which horizontal size you capture at.

Using the examples in: http://www.doom9.org/index.html?/capture/par.html:

The BT878 / Hauppauge WDM driver combo PAL capture at 768-w x 576 to DVD:

source PAR = (4/3) * (51.56/52.0) * 576/(768-w)
target: 672x544, PAR = 1.094

1. determine target vertical size and divide by the source vertical size: 544 / 576 = 0.9444.
2. multiply the source horizontal size with (source PAR) / (target PAR): (768-w) * (4/3) * (51.56/52.0) * 576/(768-w) / 1.094 = 696.
3. multiply the number from step 2 with the number from step 1 and you get the target horizontal size: 0.9444*696 = 657 -> 656 (rounded to an even number).
4. crop / add pixels: add 16 pixels to get 672 horizontally.

Thus, resizing 768-w x 576 to 656 x 544 and padding to 672x576 results in a clip with correct DVD PAR.

-----

See, whatever you choose for w, you have to resize to 656x544 anyway.

Boulder

27th March 2006, 20:25

Humm, is there something wrong with PARanoia's logic then? I captured at 720x576 last time and used PARanoia to get the crop and resize parameters. It gives me this:
(with Keep ITU enabled)

AviSource("E:\Temp\Captures\smart.avi")
LanczosResize(672,544,0,6,720,564)
Addborders(16,16,16,16)

Without Keep ITU enabled, it recommends resizing to 656x544 and adding borders as needed to get to 704x576.

Which one is correct then?

Wilbert

27th March 2006, 22:15

It works fine for me :confused: I used PARanoia_0.20b. Script:

# I selected your chip/driver and a 720x576 source.
AviSource("D:\Captures\jewel.avi")
BicubicResize(656,544,1/3,1/3,0,0,720,576)
Addborders(32,16,32,16)

It might be possible that both are correct. Will check that ...

screenshot:

Boulder

28th March 2006, 04:26

I get this with the latest PARanoia:
http://www.saunalahti.fi/sainki/smart_720.jpg
http://www.saunalahti.fi/sainki/smart_704.jpg

With 720x576 it adds 24-pixel borders to the left and right but not with 704x576 (which I always use).

Wilbert

1st April 2006, 22:07

Sorry for the late response :)

You should set Factor to 2, because it letterboxes video (ie replaces actual video with black borders).

Boulder

1st April 2006, 22:27

Umm, do you mean "overlayed"? I've already got overscan factor=2..

Wilbert

2nd April 2006, 00:13

Sorry :) I meant: "You should NOT set Factor to 2, because it letterboxes video (ie replaces actual video with black borders)." Just leave it at 0.

It is useful if you resize to 704xsomething, and letterbox to add horizontal black borders.

Btw, i'm not sure what the "resized" and "overlayed" button do. I guess they are for preview.

Inc

2nd April 2006, 00:22

Problems? I tried to follow your issue but could you give me in some compressed few words the issue in its essential point? thanks.
EDIT: Ok, now I catched it! ;)

Wilbert, 0.20b is very outdated, please do check using latest 0.31b.
within that time some optimizations have been don on the code, so maybe a "bug" got into it. you never know.
Btw, i'm not sure what the "resized" and "overlayed" button do. I guess they are for preview.
Its the kind of how the overscan area will be applied. "Resized" means "Addborders()" and "Overlayed" means "Letterbox()"

Boulder,
With 720x576 it adds 24-pixel borders to the left and right but not with 704x576 (which I always use).
Thats correct, If you got a capture of for example more or less 52.00us then imho it makes no sense stretching the whole picture proportionally so it touches in its movie pixel information the whole final target 720 width. That would force the calculator also to UPSCALE the height which a) is not ITU correctly and b) ends up in a more blurry resizing where anyway only the 702x576 will be handled by the TV set.

I do see you do use FFdshow for decoding your input stream. Whats the type of your source? Huffyuv YV12? or FFDshows mpeg4?

Btw. Im just again in the PARanoias code to add some features, so any hints or bug reports are very welcome :) Thanks

Wilbert

2nd April 2006, 01:26

Its the kind of how the overscan area will be applied. "Resized" means "Addborders()" and "Overlayed" means "Letterbox()"
Perhaps you can make that clearer in the gui, because i never would have guessed that :)

Boulder

2nd April 2006, 08:57

I do see you do use FFdshow for decoding your input stream. Whats the type of your source? Huffyuv YV12? or FFDshows mpeg4?

It's ffdshow's HuffYUV YUY2.

Btw. Im just again in the PARanoias code to add some features, so any hints or bug reports are very welcome :) Thanks
AVS input would be nice, I usually have to edit the commercials out so with avs input the detection would be done on the actual movie/episode.

So, to sum it up: what resolution should I use in my case (the Hauppauge drivers/BT878 chip) if I want to end up with 704x576 and use 2 overscan blocks (with AddBorders)?

Inc

2nd April 2006, 10:48

It's ffdshow's HuffYUV YUY2.
In this case DO add a "Pixel_type="YUY2" to your resulting avisource() line, cause here avisynth internally first requests the decoder to decode to YV12. And as you can see thats why I added the "Format" Info left above where you can see what colorpsace does result when avisynth opens the source. By adding "Pixel_type="YUY2" you force ffdshow to decode to YUY2, means the Cspace will be kept. Otherwise you directly could use HuffYUV YV12 and the result would be the same ;)
In case of "mjpeg" FourCC inputs PARanoia can detect the that and automatically adds that needed "Pixel_type="YUY2" in the resulting script. But as FFDS or FFVH could use both YV12 and YUY2 therefore the user has to add it manually.

So, to sum it up: what resolution should I use in my case (the Hauppauge drivers/BT878 chip) if I want to end up with 704x576 and use 2 overscan blocks (with AddBorders)?
So the Hauppauge drivers/BT878 chip combination does sample at 51,56us but outputs a 720x576 stream. So these 696 (51,56) are simply bumped up to the resulting 720x576.
THATs why it makes NO sense capturing at 720x576 qualitywise. Do cap to the nearest resolution wich fits the cards 51,56us output and in here as 51,56us equals 696x576 therefor do use 704x576 ... everything else would do end up in more internal cards scalings.

Now if you got 51,56us fitting within 720x576 and you will end up in 704x576 + 2blocks resized overscan ... youll need this:

AviSource("H:\d2v Testings\696x576-720x576.avi",Pixel_type="YUY2")
LanczosResize(672,544,0,6,720,564)
Addborders(16,16,16,16)

The appl. output:

http://img117.imageshack.us/img117/3411/paranoiaresult4bd.gif

The test where I brought that 704x576 output back to TV PAR 1:1 and overlayed it to a 1:1 Circle template.

http://img86.imageshack.us/img86/7194/result6mc.gif

Boulder

2nd April 2006, 11:06

In this case DO add a "Pixel_type="YUY2" to your resulting avisource() line, cause here avisynth internally first requests the decoder to decode to YV12. And as you can see thats why I added the "Format" Info left above where you can see what colorpsace does result when avisynth opens the source. By adding "Pixel_type="YUY2" you force ffdshow to decode to YUY2, means the Cspace will be kept. Otherwise you directly could use HuffYUV YV12 and the result would be the same ;)

Of course, I just took the script example from PARanoia. I usually use generic scripts for each TV series, adjusting just the cropping and resizing parameters and denoiser thresholds.

So the Hauppauge drivers/BT878 chip combination does sample at 51,56us but outputs a 720x576 stream. So these 696 (51,56) are simply bumped up to the resulting 720x576.
THATs why it makes NO sense capturing at 720x576 qualitywise. Do cap to the nearest resolution wich fits the cards 51,56us output and in here as 51,56us equals 696x576 therefor do use 704x576 ... everything else would do end up in more internal cards scalings.

Looks like I've been doing things correctly for my setup then, capturing at 696x576:)

Oh, one more feature request for PARanoia: the possibility to set default settings.

Inc

2nd April 2006, 22:29

The deafult settings? Normally everything you do set (except the resizing itself) is set into an ini file when closing the appl. Like the used Resizers or Avisynth commands and also cap-card settings etc etc etc.

Looks like I've been doing things correctly for my setup then, capturing at 696x576So paranoia in case of 2blocks overscan will use ...

AviSource("H:\d2v Testings\696x576.avi")
LanczosResize(672,544,0,6,696,564)
Addborders(16,16,16,16)

This is a good approach as the height wont be scaled up.
But now lets do see if the target will be 704x576 incl. NO overscan:

AviSource("H:\d2v Testings\696x576.avi")
LanczosResize(704,576,0,3,696,570)

Here you end up in a quality trap only cause you force the output to be mod16 ;)
Means the resizer takes that into account and crops the height to 570 and scales it up again to 576 just do compensate the stretching of the 696 (51,56us) to the correct 704 (52,148us):
(51,56 / 52,148) * 576 = 569,50

In this case (if you dont worry about mod16 but about max poss. quality without any interpolation, you should set the resize Mod also to 2 and the result will be a simple padding from 51,56us to 52,148us:

AviSource("H:\d2v Testings\696x576.avi")
LanczosResize(696,576,0,0,696,576)
Addborders(4,0,4,0)

Equals to:
AviSource("H:\d2v Testings\696x576.avi")
Addborders(4,0,4,0)

But as for shure you want 2blocks overscan, do here choose "overlayed" instead:

AviSource("H:\d2v Testings\696x576.avi")
Addborders(4,0,4,0)
Letterbox(16,16,16,16)

So -->that should be your script :) --> Fast, SAME compression gain and NO increased blurring due interpolation when targeting 704 ;)

If your SAP supports it, you should think about targeting 544x576 as full TV PAL captures do never use the detailness of 704/696 and so a lanczos resize to 544x576 could fit to your visual quality needs and its an even more compressable alternative:

Just try and compare:

AviSource("H:\d2v Testings\696x576.avi")
LanczosResize(512,560,0,3,696,570)
Addborders(16,8,16,8)
letterbox(16,16,0,0)

The resulted AR error is 0.17

Boulder

3rd April 2006, 06:12

The deafult settings? Normally everything you do set (except the resizing itself) is set into an ini file when closing the appl. Like the used Resizers or Avisynth commands and also cap-card settings etc etc etc.

It would be nice if the destination resolution was saved as well since I nearly always use 704x576 :)

So paranoia in case of 2blocks overscan will use ...

AviSource("H:\d2v Testings\696x576.avi")
LanczosResize(672,544,0,6,696,564)
Addborders(16,16,16,16)

That's what I've been using lately.

AviSource("H:\d2v Testings\696x576.avi")
Addborders(4,0,4,0)

This is what I've used if I don't want to use LetterBox() and don't want to end up resizing at all.

But as for shure you want 2blocks overscan, do here choose "overlayed" instead:

AviSource("H:\d2v Testings\696x576.avi")
Addborders(4,0,4,0)
Letterbox(16,16,16,16)

So -->that should be your script :) --> Fast, SAME compression gain and NO increased blurring due interpolation when targeting 704 ;)

I'll have to compare that approach to the regular AddBorders overscan.

If your SAP supports it, you should think about targeting 544x576 as full TV PAL captures do never use the detailness of 704/696 and so a lanczos resize to 544x576 could fit to your visual quality needs and its an even more compressable alternative:

Just try and compare:

AviSource("H:\d2v Testings\696x576.avi")
LanczosResize(512,560,0,3,696,570)
Addborders(16,8,16,8)
letterbox(16,16,0,0)

The resulted AR error is 0.17
Unfortunately it doesn't support that resolution on DVDs, on SVCDs it does..

klinika

3rd April 2006, 16:37

Btw. Im just again in the PARanoias code to add some features, so any hints or bug reports are very welcome :)

Would a zoom feature be feasible, to crop the borders to the last bad pixel? Currently I have to use vdub for zoom and use its cropping values in Paranoia. Not that it's much of a bother though. Excellently useful app btw :-)

Inc

3rd April 2006, 17:01

? You mean u use Vdub for cropping and entering the values afterwards in Paranoia?

Do an Autocrop and you wont need Vdubs cropping anymore. The Autocropping can be adjusted in its threshold easely.

Ill add a Feature where you can use the Mousepointer to move the cropping lines like in Vdub - but Zooming imho makes no sense unless you do set a monitors depth of 1280x960 on a 15" CRT Monitor ;)