Capture Guide Suggestions Part 2 [Archive]

Wilbert

23rd May 2003, 16:25

equally, if you specify the coring option later, what is the point of doing the luma gain and offsets, cause both opt=coring and limiter will bring your levels back to tv range automatically, no?
They both bring your levels back to the tv range, but they don't do the same. Limiter (or opt=coring) just clips your luma to [16,235]. Meaning that [1,16] is mapped to [16] and [235,255] to [235].

luma offset adds luma, and luma gain multiplies luma with a constant factor. More info: http://www.avisynth.org/index.php?page=ColorYUV. So, that's entirely different.

I will clarify this a bit more in the guide.

equally, if you identify your cap setup requires luma adjustments, why not just re-calibrate the brightness settings in vdub capture settings? ditto for saturation,
Yes, you can do that (guide mentiones that).

saving time later doing what may then be an unncessary yv12 conversion and coloryuv adjustments?

1) yv12 conversion is only needed when finding the parameters (for using the histogram). If you found the parameters you can remove the yv12 conversion. Note that ColorYUV requires YUY2 or YV12.

2) So when encoding with TMPGEnc (to svcd/vcd), you are right. It is better to adjust your capture settings, since TMPGEnc requires RGB24. I will add this to the guide.

3) When encoding with CCE the required format is YUY2, so no problem there. Ditto for encoding to DivX/Xvid, that must be YV12 anyhow.

wotef

23rd May 2003, 17:23

ah, limiter and opt=coring are not additive, i get it now - tks for the explanation

BaronVlad

24th May 2003, 11:37

Sorry, dont have much time now since my girlfriend wants to play pingpong with me...

@dar1us: I would love to see your explaination in the guide !!! :)

It is now on our to-do list for version 3.0, you have no chance to get away from us without writing this part :D

EDIT:

Nice to see you here Owen, I am sorry that I dont have a machine that is able to give good results with Morgan. I tried it some time ago and it was horrible (bad quality or many drops)...:(

vfw - wdm: Win XP has a built-in-wrapper, so no problem with wdm drivers (at least with SP1). But you are right regarding win2k. Hope dar1us will give us this part:)

Shandra

25th May 2003, 00:54

Hi Folks,

Maybe ... as colourspace was already mentioned some hints about it in regards for later usage/filtering - what space to capture in (hardware/codec) and wich fits best/is better suited if you later use x/y/z as an app for the filtering....

Owen

26th May 2003, 04:02

Hi BaronVlad,
Sorry that you where not able to use Morgan successfully on you hardware. But I can assure you that in "Floating Point" mode it is MUCH better quality that PicVideo.
The "Guide" should encourage the use of Morgan 3.x over PicVideo on fast machines. PicVideo is only a good idea on slow Pc's.
PC's faster than about 2Gig can also capture direct to Xvid.
In 1 Pass, Fixed Quant 2 mode, this gives better quality than you would think, and allows many hours of capture. For some people this is important.

I use XP SP1 and cannot capture FULL 768x576 PAL in Virtual Dub.
The format is "Not Supported". I can only capture half resolution or less. This is normal, as the WDM-VFW Wrapper only supports HALF resolution capture. CPU usage is also higher with the wrapper.
Maybe someone could rewrite the capture part of Vdub to support WDM :D

A WDM capture application is REQUIRED under Win2k or XP for full resolution capture.
This means that Virtual Dub cannot be used for capture on WDM systems. The "Guide" should mention this.
All the best with the Guide.

Regards,

Owen

dar1us

26th May 2003, 12:47

OK, the guide is in writing, but the trade off is that someone helps me with my S-Video problems, perhaps I could see someone elses S-Video samples.

Check out this thread: http://forum.doom9.org/showthread.php?s=&postid=318719#post318719 this describes/details the problem.

Cheers

dar1us

ADLANCAS

30th May 2003, 19:52

Hi,

In cap. 1. Preface / Basics / 704/720/640x480 (Full NTSC) = High Quality is described:
Captured at: 704x480 with 7 pixels cropped horizontally
-> crop/add: 704x480 [exact: 702x480]

I’ve not enough aknowledge like you, but I only compared with the values in document
http://www.uwasa.fi/~f76998/video/conversion/ (I think you use this as reference)
and saw that the right value is [exact: 711x486] !
If this is right, should be also changed script for Avisynth, including crop/add before Resize.
-------------------------------------------------

“320x480 with vertical resize ("1/2 NTSC", not scientifically correct, but clear I hope) = Average Quality
Basically only half of the NTSC width (640/2 = 320), but the complete height is captured. But also the height is divided by two during the capture process so the resulting resolution will be at 384*288.”

Also here must have a little mistake (copied from PAL description).
Shouldn’t be “…resolution will be at 320*240” ?

I learned a lot with this guide. Thanks to all!

Alexandre

PS. Capture-Karten und aspect ratio fuer Dummies 1.0 by Der Karl
Where is this document? Thread is empty !

Wilbert

2nd June 2003, 09:23

In cap. 1. Preface / Basics / 704/720/640x480 (Full NTSC) = High Quality is described:
Captured at: 704x480 with 7 pixels cropped horizontally -> crop/add: 704x480 [exact: 702x480]
It's a typo what slipped through (must be 704x486/702x486). Thanks!

Also here must have a little mistake (copied from PAL description).
Shouldn’t be “…resolution will be at 320*240” ?
Yes, you are right.

PS. Capture-Karten und aspect ratio fuer Dummies 1.0 by Der Karl
Where is this document? Thread is empty !
Yeah, the attachments are still offline. I think I will put it on my homepage.

Wilbert

2nd June 2003, 14:09

In cap. 1. Preface / Basics / 704/720/640x480 (Full NTSC) = High Quality is described:
Captured at: 704x480 with 7 pixels cropped horizontally -> crop/add: 704x480 [exact: 702x480]
It's a typo what slipped through (must be 704x486/702x486). Thanks!
On a second thought, I'm wrong above (and the guide and you were both right).

You can either add borders at all four sides, resulting in: 711x486. But note that you could also crop all sides ending with 702.2x480.

calculations:
(711/486) * (72/79) = 4/3
(702.2/480) * (72/79) = 4/3

If you don't crop from 704->702.2 (but just leave it at 704) you will make a very small error, which is not noticable.

Ookami

2nd June 2003, 14:14

Hello.

My suggestions:

-Make an article how to set up a capture system correctly (Tim, should we go for it?)

-Put the whole document into one archive and make that available for download, it's annoying to save one html page at once... Didn't the first versions had this?

Karl's document:

http://www.videoxone.de/cgi-bin/load.pl?page=guides
http://guides.videoxone.de/derkarl/index.html

-MJPEG

Hasn't this have discussed dozens of times. It's always a tradeoff, if you want "best" quality you will not use MJPEG anyway.

>Maybe someone could rewrite the capture part of Vdub to support WDM

The 2.x branch will support WDM, AFAIK.

Cheers,

Mijo.

ADLANCAS

2nd June 2003, 17:46

@Wilbert

Yes, I agree with you. Maybe it's better to comment that capturing in 704x480 and making a script without crop/addborders will produce "a very small error, which is not noticable", because newbies like me has difficulty to understand such things, at least I have.

I've already post something about "Color Adjustment" in old thread and Killingspree agree with me and I haven't seen more comments about it, but version 2.0 was made without changes. Did you forgot or someone don't agree. (I'd like to know if I'm right or adjustment must be made only once)

@Ookami

Thanks for the links.(Oh...es ist auf Deustch, naturlich ganz einfach...aber nicht für mich!!)

A little question. Is it possible(good) to capture in YV12(for faster post processing)? (I think with MJPEG and Huffyuv not)

Alexandre

Wilbert

3rd June 2003, 09:17

Yes, I agree with you. Maybe it's better to comment that capturing in 704x480 and making a script without crop/addborders will produce "a very small error, which is not noticable", because newbies like me has difficulty to understand such things, at least I have.
We will do that.

I've already post something about "Color Adjustment" in old thread and Killingspree agree with me and I haven't seen more comments about it, but version 2.0 was made without changes. Did you forgot or someone don't agree. (I'd like to know if I'm right or adjustment must be made only once)
I remember it was something about that capping from vhs or tv needs different contrast settings? I didn't respond because I don't know the possible reason for this (nor did I try it). Maybe BaronVlad/Ookami can comment on this? (Btw, did you try it with the same broadcasting: capping tv and recording to vhs at the same time (and capping that recording from the vhs at a later stage)?

A little question. Is it possible(good) to capture in YV12(for faster post processing)? (I think with MJPEG and Huffyuv not)
In the AviSynth YV12 you can find four lossless YV12 codecs (which can be used to capture in YV12). Two of them are 'variants' of MJPEG and Huffyuv.

ADLANCAS

3rd June 2003, 13:36

@Wilbert
(Btw, did you try it with the same broadcasting: capping tv and recording to vhs at the same time (and capping that recording from the vhs at a later stage)?
I'll do that.

In the AviSynth YV12 you can find four lossless YV12 codecs (which can be used to capture in YV12). Two of them are 'variants' of MJPEG and Huffyuv.
I've already had one before install v2.51, but I don't remember that I have more options now. Checking...

Yesterday, I made same tests with real-time compressing with good results. Of course, that we can get better quality with 2pass, but the results are good and maybe you can give a option to a "fast results" in capture guide. (I know that something is written there about it, but only superficially).

My settings are:
Source TV NTSC
Color format: YV12
Capture format: 320x480
DivX codec: NO GMC/NO Bidirectional Encoding, 1 pass quality-based
General Parameters:Psycho... = Normal / Pre-Processing=light
Resize to 320x240 (Bilinear)
All frames interlaced and Top Field First
Advanced Parameters: Quality slowest

Alexandre

BaronVlad

3rd June 2003, 22:50

Originally posted by Ookami

-Make an article how to set up a capture system correctly (Tim, should we go for it?)

Hi Mijo,

We could do this but not in the next weeks because of a lot of exams :( But much of this is in the FAQ anyway or did you mean which components to buy and how to connect ? This is true - it is missing.

Originally posted by Ookami

-Put the whole document into one archive and make that available for download, it's annoying to save one html page at once... Didn't the first versions had this?

AFAIK only the German version can be downloaded, but this should be no problem, doom9 should have the zipped documents and could put it online. (Traffic ???)

Originally posted by Ookami

Karl's document:

http://www.videoxone.de/cgi-bin/load.pl?page=guides
http://guides.videoxone.de/derkarl/index.html

Just came here to bring the link, but Mr. R. was faster :) (some time more)

Originally posted by Ookami

-MJPEG

Hasn't this have discussed dozens of times. It's always a tradeoff, if you want "best" quality you will not use MJPEG anyway.

In the Appendix there is a link to Owens first post in this forum, a longer discussion about capture codecs (and a bit of OT :D ):
http://forum.doom9.org/showthread.php?threadid=31172

ADLANCAS

4th June 2003, 00:46

According my tests, it really has a slight difference only in gain_y, but I think it´s not so significant since we use opt="coring".
For TV: gain_y=3
For VHS: gain_y=9

Alexandre

avih

5th June 2003, 03:59

Originally posted by Owen
... I use XP SP1 and cannot capture FULL 768x576 PAL in Virtual Dub.
The format is "Not Supported". I can only capture half resolution or less. This is normal, as the WDM-VFW Wrapper only supports HALF resolution capture. CPU usage is also higher with the wrapper.
Maybe someone could rewrite the capture part of Vdub to support WDM :D

A WDM capture application is REQUIRED under Win2k or XP for full resolution capture.
This means that Virtual Dub cannot be used for capture on WDM systems. The "Guide" should mention this.
All the best with the Guide.

Regards,

Owen

i CAN capture full res pal with vdub and XP-Pro (no SP1). i'm using btwincap, and the wdm wrapper kicks in without any questions asked.

some capture tips:

- disabling BOTH overlay and Preview can reduce the cpu load considerably while capturing.

- the dreaded VIA chip pci problem (occasional bright horizontal lines during capture) can be reduced significantly if using PS/2 mouse instead of a USB one (could be also for other USB devices, but my only USB is mouse)

Owen

5th June 2003, 16:07

Hi AVIH,
I take my hat off to you dude.
So it is possible.
Full res VFW capture in Vdub. does not work for me with a MSI TV@nywhere card.
From memory,(and mine is fuzzy :D) my BT8x8 TV card with BTwincap drivers did not work either, even with preview turned off.
Even if Vdub did work, performance was so bad that I gave it up for WDM capture apps.
I have been capturing direct to Xvid or Divx since 2000 when I had an Athlon 1.4Gig on a nasty VIA board and Win2k.
I seem to remember that VFW apps were just to slow to do this, due to the wrapper (lots of dropped frames). So I had to use WDM apps. I have used WDM ever since, and have not looked back.
WDM is just more efficient for modern hardware.
I know many people have problems with WDM and audio sync. But all my problems are solved and I can capture for as long as hard drive space allows with perfect audio sync.
So it can be done. :D

Mijo,
I am glad to hear that Vdub will be supporting WDM capture. But when ? :)

Regards,

Owen

Intel P4 3.06 @ 3.4, WinXP Pro SP1, 512M DDR400, Radeon 9500 Pro, Asus P4PE board with ADI on board sound (Great), MSI TV@nywhere.

Ookami

5th June 2003, 20:10

Originally posted by Owen
Mijo,
I am glad to hear that Vdub will be supporting WDM capture. But when ? :)

I doubt that it'll be anytime soon. But, except Avery Lee and his alpha/beta testers no one can know anyway.

Cheers,

Mijo.

chemmajik

10th June 2003, 10:33

My f878a seems to do full res captures when using composite or svideo when capturing blindly under btwincap drivers also for ntsc. But I did have to use PicVideo bec more to deal with hd space.

North2Polaris

24th November 2003, 23:34

Many thanks for the new version of the Guide!

In 1.3.4 Capture Resolution: NTSC of the Preface section, there is a table for capturing: ITU compliant video. In the table, there is the following statement:

“720x480 with 18 pixels overscan 702x480 (note: YUV requires even widht/height, accepting a small error, crop to 704x480 instead) 72/79”

Is this correct? The active area for NTSC is 711x486. In a later section of the guide -- “Processing the video using AviSynth”, 720x480 with a PAR of 72/79 and 9 pixels overscan is mentioned as one of the possible situations.

I have been trying to find an explanation of “generic PAR”. This is mentioned in the Guide and appears to be an important concept in terms of understanding how my capture card works (ATI All-in-Wonder Radeon 9000). I have looked at several of the references, searched the forum, and did a Google search for this term without much success.

Thanks.

trevlac

25th November 2003, 02:30

Originally posted by North2Polaris

In 1.3.4 Capture Resolution: NTSC of the Preface section, there is a table for capturing: ITU compliant video. In the table, there is the following statement:

I think the concept of a ITU-601 compliant card is incorrect in the guide. From tests done in this post: http://forum.doom9.org/showthread.php?s=&threadid=64635&perpage=20&pagenumber=1

It is clear that the 3 flavors of chips all capture and scale. One card tested did not scale, but it only offered 1 frame size. Given this, I'd say all cards capture and scale. So it is important to know what portion of the 711 line they grab as the active picture. It is my understanding that 'non bt8x8' ATI cards capture 704 and scale it to what you ask. If you want to confirm, simplely cap at both 704 and 720. If 704 is not a cropped version of the 720, the card scales. I do not have an ATI, but I very much suspect that this is the case. If you want to find the exact width, you may be able to test with the AVIA pixel crop test pattern. Because a dvd player itself will crop the 720 picture, you have to take that into account.

“720x480 with 18 pixels overscan 702x480 (note: YUV requires even widht/height, accepting a small error, crop to 704x480 instead) 72/79”

Is this correct? The active area for NTSC is 711x468. In a later section of the guide -- “Processing the video using AviSynth”, 720x480 with a PAR of 72/79 and 9 pixels overscan is mentioned as one of the possible situations.

In this area of the guide, I believe they are trying to account for the loss of the 6 vertical lines. The guide is telling you to crop off to get the same aspect as 711/486. IOW: 702/480, because captures will auto crop 6 vertical. Now the only reason you would want to do this is so you can resize for PC viewing. For SVCD/DVD, 480 is the height. For DVD/SVCD you would then simply crop/pad to a valid size (720 or 704) and then possibly resize to 480 or 352 if you are going to SVCD or HHR.

However it is doubtful any card really captures at more than 1 size. If they do, they scale from a basic size to what you ask. I believe your ATI grabs 704x480 of the 711x486 picture and resizes if you asked for anything other than 704x480. If you are going for PC viewing, the guide suggests you simply resize to 640x480. If you are going to DVD D1, do nothing. If you are going to SVCD, pad to 720 and resize to 480x480. If you are going to HHR, resize to 352x480.

Hope this helps....

NOTE: When I say cards, I mean card/driver combo...

North2Polaris

25th November 2003, 06:17

Thanks, this helps.

The maximum capture resolution for my ATI card and the most current driver and the ATI capture software is 704x480. Earlier versions of the capture software also included a 720x480 option, which is no longer included. I can capture at 720x480 using VirtualVCR. I will check for scaling.

I do not have an ITU compliant capture card, but I do have a Canopus ADVC 100, which I use for converting old VHS tapes. Since DV is ITU compliant and according to the Canopus website, the ADVC “encodes the entire video frame”, I decided to see if a frame from a NTSC broadcast converted to DV by the ADVC showed evidence of horizontal compensation.

If you open the frame in MS Paint and zoom to 600x, you can easily see the pixel structure. There is a 5 pixel black border on the left and a 9 pixel black border on the right, suggesting that there at least 14 pixels of overscan, resulting in a horizontal compensation of at least 706 pixels. Of note, there is a 1 pixel wide black border at the top of the frame.

trevlac

25th November 2003, 15:47

I must tell you, I don't completely follow your post.

A few things I believe:

"ITU compliant capture card" is not a clear or valid statement. ITU-601 does specify 720x480 NTSC. It does not deal with compensation in any way from/to an analog source. I think the 6 are always cropped off. A resize would mess up the interlace.

“encodes the entire video frame” I doubt it. The entire 720x480 frame, but not the 711x486 frame. It crops the 6. (How it crops, I do not know. Maybe all from the top, bottom, some from top, bottom).

"horizontal compensation" when you say this, I'm not sure you are talking cropping or resize. There is no evidence that anything adjusts by resizing horizontally for the 486->480 crop. I believe the ATI 'cuts' 704x480 out of the 711x486 frame. Because it cuts it, the aspect has not changed. Even if it cuts 711x480 out, the aspect would be correct. The trick is to ask for what the card/driver cuts out. If you ask for anything else, it would resized to that value, most likely changeing the aspect. Because of all of this, 704x480 is better than 702x480. 702 may be closer to 4:3, but it's aspect is off. You see, after cropping, aspect has not changed, but frame size has. BTW: 704x480 is a nice size for DVD. For TV, you simply adjust the horizontal by 72/79. Do not change the vertical.

"ADVC 100 " I don't have one of these units. I do have a DVCam. I'm not clear on your tests, but if you pipe analog source into the ADVC, how do you know what the original source was? S-Video out from my DVD player is not 720x480. It most likely is 711x486, but how it gets there is not clear without testing the DVD player. In other words, If you go 720x480 DV in to the ADVC, then s-video out of the ADVC, how do you know what is comming out? Now throw the capture card in the mix. The post i mentioned used a scope on the analog out to clearify the effects of that step.

Trev:D

trevlac

25th November 2003, 16:05

Originally posted by North2Polaris

If you open this in a graphics program and zoom to 600x, you can easily see the pixel structure. There is a 5 pixel black border on the left and a 9 pixel black border on the right, suggesting that there at least 14 pixels of overscan, resulting in a horizontal compensation of at least 706 pixels. Of note, there is a 1 pixel wide black border at the top of the frame. If all 486 of the original pixels are present, this may mean that 487 pixels have been included in the “viewing area” or the “entire viewing area” of 486 vertical pixels has not been included.

I think this shows that the ADVC 100 may use horizontal compensation to convert NTSC analog video, as the Capture Guide proposes for ITU-compliant capture cards. Whether this is also true for ITU compliant capture cards remains a question.

I re-read your test to make sure I understood.

This is what I think about the horizontal:
Your vhs source produces a total scan line 63.555 microseconds. This is ITU-470. Of that, only 52.296 is active picture. There is not spec that says what this has to be exactly. There is a range. The ADVC captures 53.333 of the 63.555. This is in the ITU-601 spec. The xtra black is due to the sync signal from the VCR. To convert microseconds to pixels, you have to multiply by the sample rate. ITU-601 specifies 13.5MHz. So 52.296 = 706, 53.333 = 720.

For the vertical:
There is less room here. The VCR must produce 525 scan lines for NTSC. Which ones actually have a picture is questionable. They may also be shifted up or down. If they are too far down, you will see non-picture (sync signal) squiggly lines across the top.

Trev

Arachnotron

25th November 2003, 16:40

Perhaps it is nice to summarize what is actually in ITU-R BT.601-5.

that the following be used as a basis for digital coding standards for television studios in countries using the 525-line system as well as in those using the 625-line system:

This Recommendation specifies methods for digitally coding video signals. It includes a 13.5 MHz sampling rate for both 4:3 and 16:9 aspect ratios with performance adequate for present transmission systems. An alternative 18 MHz sampling rate for those 16:9 systems which require proportionately higher horizontal resolution is also specified.

For NTSC 4:3, an ITU compliant signal must look like this:

- Y,Cr,Cb coded (4:2:2 or 4:4:4, 13.5 MHz)
- 858 luminance samples per line, 429 colour-difference
- orthogonal sampling structure, Cr and Cb samples begin at Luma samples 1,3,5,7 etc.
- sampling freq. 13.5 MHz luma, 6.75 chroma
- PCM coded, 8 or 10 bits/sample
- 720 luma samples and 360 colour-diff samples per active part of line
- 16 T (luma pixel) front porch (end active up to horizontal ref next line)
- 122 T (luma pixel) from horizontal ref to start active (horizontal delay in Conexant speak)
- this puts the center at 122+360=482
- luma scale 0-255, black=16, white=235
- colour diff scale 225, 0=level 128
- 0 and 255 values only used for sync

Note that ITU-R BT.601-5 does not say anything about which lines contain the active picture part; it only discribes the digital representation of a single line.

trevlac

25th November 2003, 18:46

@Arachnotron

Nice summary. So what does ITU compliant capture card mean? Maybe that it captures using 13.5MHz samples -vs- my favorite 14.36MHz. :)

This of course is nice to know, but provides zero guidance as to the 'output' frame dimensions.

If 13.5 is 601 then 14.3 is 4FSC. :D

Arachnotron

25th November 2003, 19:13

This of course is nice to know, but provides zero guidance as to the 'output' frame dimensions.

Absolutely true. A bit off topic :D :D

It's just that since the term keeps popping up, it's nice to know what it actually means.

Since almost all cards have a scaler, all cards can produce an ITU pixel, either directly or through scaling, and all cards need 'help' to get the sizing right and to compensate for cropping.

After looking at a number of specsheets of capture chips, I can only conclude that as far as manufacturers are concerned the term ITU compliant translates to 'using a 13.5 MHz pixelclock'. All the other specifications are considered optional.

Perhaps simply dropping the whole term would be better. ;)

North2Polaris

25th November 2003, 23:52

I would like to thank you both for your thoughtful replies. Also thanks for pointing out my mistake in the earlier post; 6 of the 486 vertical pixels are cropped off.

I hope the moderator will not consider these posts to be off topic. The authors of the guide clearly state in the preface that “we tried to make this guide a bit more technical than the previous version”. The reason I decided to post my initial questions in this thread was because these technical concepts are covered in Version 3.0 of the Capture Guide and are used to explain why certain recommendations for processing video are made.

Let me use the three examples from the AviSynth section of the Guide.

#1, when capturing at 720x480 (ITU compliant), the recommended script is:

BicubicResize(640,480)

#2, when capturing at 720x480 with overscan” and resizing for NTSC, XviD, the recommended script is::

Crop(8, 0, 712, 480)
AddBorders(0, 6, 0, 0)
BicubicResize(640, 480)

#3, when capturing at 704x480 (not ITU compliant) and resizing for NTSC, XviD, the recommended script is:

AddBorders(0,6,0,0)
BicubicResize(640,480)

To understand these three simple scripts, requires an understanding of the “active image area is 711x486 pixel” concept and the “ITU-compliant” concept. Why crop to 712? Why add a top border of 6? It would be easy to say “I have an ATI capture card and fall into category #3” and go on from there, but I suspect that for me, like many of the visitors to Doom9’s forums, this would not be nearly as interesting.

To understand these simple scripts, also requires an understanding of when these scripts should not be used. That is why I used the example of the Canopus ADVC DV converter, which can be considered a special “capture case”. What happens to a cable TV signal that passes through a JVC SVHS VCR and then goes out through the S video connector to the ADVC converter and gets saved as consumer DV on my PC? Do I use the recommendations in the Capture Guide or use those found in the DV forum. As you can see from the image posted above, I probably need to crop to 704 if I am going to resize for XviD, which is what I would do with DV from my digital camcorder, but for different reasons (the DV from my camcorder does not have black borders). Do I need to add a top border of 6 pixels before I resize to maintain the proper aspect ratio or do I just resize to 640x480 like I would do for DV from my camcorder?

I am also intrigued by footnotes #2 and #3 in the Capture guide. In #2, "as explained in the text, it is assumed that the six scan lines are cropped of during capturing. It is also assumed that there is no horizontal compensation for this (thus the actual image is.1.35:1). I have no evidence for this." In #3, “as explained in the text, it is assumed that the six scan lines are cropped off during capturing. Here, it is also assumed that there IS a horizontal compensation for this (thus the actual image is 4:3). I have no evidence for this. So if you have an ITU compliant capture card (NTSC), drop me a mail! “

I don’t have an ITU compliant capture card (NTSC), but I can pass a NTSC analog video signal through my VCR and ADVC converter and look at the resulting DV on my computer. Can a careful examination of the 720x480 DV frame posted above tell me what happened as the signal passed through these two black boxes? Probably not, but I learned a lot trying and from your comments.

I have not been able to think of a simple test of horizontal scaling (like the test described above for capture cards) for a DV converter, which "captures" at only one resolution, 720x480. In my test capture, the image area in the ADVC capture frame is 706x480 or 704x480. Can I assume that the Canopus ADVC performs horizontal scaling like many capture cards, although I have no evidence of this (I have not found a reference to this on the Canopus web site)?. If yes and I use a generic PAR of 81/88 as used in the Capture Guide for capture cards that perform horizontal scaling, the actual image ratio would then be 1.35:1. An image ratio of 1.35:1 is not a 4:3 format and the resizing script for the Canopus DV "TV capture" should be similar to that in recommendation #3 above:

Crop(6,0,-10,0) #the image is off centered
AddBorders(0, 6, 0, 0)
BicubicResize(640, 480)

If the ADVC does not perform horizontal scaling, I should use the following script:

Crop(6,0,-10,0)
BicubicResize(640,480)

A conundrum.

Perhaps future revisions of the Capture Guide could include a section on "capturing" analog video using a DV converter, since these devices are becoming more common!

I don’t think my family is ready yet for me to buy an oscilloscope.;)

trevlac

26th November 2003, 05:41

It's good to see you are working this out. Here is my opinion if it was not clear before.

The guide is wrong.

Originally posted by North2Polaris

#1, when capturing at 720x480 (ITU compliant), the recommended script is:

BicubicResize(640,480)

#2, when capturing at 720x480 with overscan” and resizing for NTSC, XviD, the recommended script is::

Crop(8, 0, 712, 480)
AddBorders(0, 6, 0, 0)
BicubicResize(640, 480)

#3, when capturing at 704x480 (not ITU compliant) and resizing for NTSC, XviD, the recommended script is:

AddBorders(0,6,0,0)
BicubicResize(640,480)

All of these are wrong. Regardless of what your card does. Actually, #2 is real close for DV. Maybe they choose 712 instead of 711 for a reason.

To understand why, all you need to know is:
1) A card/DV device captures a piece of the original source. Picture cutting out a part of an 8x10 picture. In this case you can even get bigger than the original. 711x486 is the original. DV does 720x480, ATI does 704x480.

2) NTSC TV pixels are 72/79 wide where as PC ones are 1. To move back and forth, multiply or divide by 72/79. IE. 711*72/79 = 648.

3) 648x486 is 4:3 and 640x480 is 4:3 on a PC. 711x486 is 4:3 on a TV.

So:

If your card/device captures (cuts out) 720x480 and you want 640x480 you can do #2 above or better yet, crop to 711x480, then crop off 9 more (to account for the PC xtra 8 in 648) 702x480, and resize to 640x480. I'd do this because the vertical resize is going to screw with the interlace.

If your card/device captures (cuts out) 704x480 and you want 640x480 you can crop to 702x480 and resize to 640x480. #3 is clearly wrong. If you add 6 vertical, you are shooting for 648x486 in PC pixels. 704*72/79=641. You wanted 648.

To understand these three simple scripts, requires an understanding of the “active image area is 711x486 pixel” concept and the “ITU-compliant” concept. Why crop to 712? Why add a top border of 6? It would be easy to say “I have an ATI capture card and fall into category #3” and go on from there, but I suspect that for me, like many of the visitors to Doom9’s forums, this would not be nearly as interesting.

- 711x486 is a 4:3 active image.
- ITU-compliant means nothing with regard to aspect ratio
- Crop to 712 because sometimes odd numbers are bad. 4:2:2 pixels are stored where 2 share color info. Odd numbers may muck this up.
- Padding back to 486 is a waste if you want 480 in the end.
- #3 is wrong for an ATI card

I don’t have an ITU compliant capture card (NTSC), but I can pass a NTSC analog video signal through my VCR and ADVC converter and look at the resulting DV on my computer. Can a careful examination of the 720x480 DV frame posted above tell me what happened as the signal passed through these two black boxes?

This test should tell you what your VCR is doing (on the horizontal). I think it is safe to say the ADVC captures the entire 720 which includes a centered 711. It does not scale. Crop to 702 and resize to 640 if you want 640x480. If you think the image is off center, it is due to the vcr. I'm not sure why you think this. Just because the crop is not even, does not mean that the center line moved.

I don’t think my family is ready yet for me to buy an oscilloscope.;)

Very funny. Mine either.

Wilbert

26th November 2003, 10:59

I'd like you to know that I'm following this very interesting thread. I was only very busy the past days. But I will certainly look at this, come back to you and update the guide.

Arachnotron

26th November 2003, 18:26

Again some related info that may be off-topic :D

Some off the resizing stuff in the guide is based on "Capture-Karten und aspect-ratio für Dummies" by Der Karl

I have made an English translation available here (http://www.arachnotron.nl/videocap/doc/Karl_cap_v1_en.pdf)

The original German version can be found here (http://www.videoxone.de/cgi-bin/load.pl?page=derkarl)

I am now working on a small guide on how to determine the capture window of a capture device. And no, you don't need an oscilloscope to do it. ;)

trevlac

26th November 2003, 23:44

@Arachnotron

You are a Prince for doing this translation. One of my (many) faults is that I understand only 1 natural language.

From a quick read I got this:

ITU-Compliant cards capture the full 720 at 13.5 and do not scale. DV devices do this. Capture of 704 and no scale may also be acceptable by the definition.

Edit I got this wrong in my 1st read. I think the idea of generic PAR is based upon the false assumption that you get back the full active picture. BaronVlad even states that this is false. Anyway, I've corrected my numbers for NTSC
Generic PAR is based upon getting a 768 (648 for NTSC) sample adjusted to 720 by the card/driver. The BTwincap drivers may do this if you ask for 720. To get to your 1:1 par multiply by 1.06666 for PAL and 0.9 for NTSC. IE. 720*0.9 = 648. The point of this is that you can use this factor for resizing even after you crop, as opposed to just resizing.

@Wilbert

I wanted to say that I don't really know all (if any) of the answers myself. There seem to be many factors and I'm learning more every day. I'll see if I can post a good short outline on what I think about NTSC. A very hard job. In this thread I have just given pieces of info. I think the guide is great! It trys to cover a very hard subject. I just said it was wrong to make it clear that you need to know your hardware and destination to get the 'right' answer.

Trev ;)

Ok so here goes: Analog NTSC Capture & getting the AR 'right'

Goals of this 'guide'
1) Getting the Aspect Ratio 'right'
2) keep it simple process

What you need to know
1) Your target frame size
2) The Frame size sampled by your card/driver in 13.5MHz samples.

** Notes on #2: For BT8x8 and BTwincap this is 712. For many other BT8x8 drivers, this is 688. For CX chips/drivers this is 688. For ATI it's probably 704. Arachnotron published some test results and is creating a guide to get this info. Also, I am assuming you do not have a device that caps the full 486 lines.

Steps
1) Use a custom cap size equal to the 13.5MHz sample size discussed above. 704 (for ATI) by 480. This is 'DVD Pixels'. ;)
2) Resize to your destination width, round to even numbers.
2a) PC viewing = CapWidth * 72/79. (IE 704 * 72/79 = 642)
2b) SVCD = CapWidth * 2/3. (IE 704 * 2/3 = 470)
2c) HHR/CVD = CapWidth * 1/2. (IE 704 *1/2 = 352)
2d) DVD = No resize. You're at your width. :)
3) Crop or pad to hit your spec. (IE in the examples above, DVD and HHR are right on, SVCD needs a pad of 10. PC needs a crop of 2.)

Special Procedure
If you can not capture at a custome size, you cap a what you can (say 720), and apply a factor to the resizes above. The factor can be calculated as CustomeCapWidth / FixedCapWidth. For example on ATI, if you can't do 704 but can do 720, the factor is 704/720. The calculation for an SVCD size would then be 720 * 2/3 * 704/720 = 470.

Arachnotron

27th November 2003, 15:37

@ Trevlac
@ Wilbert

I have been struggeling with Der Karl, and wanted to see if I could come up with a more general approach that works for different capture windows. It is more complicated than Trevlacs, so maybe not suited to a general guide, but should work for any card and capture resolution as long as you know the capture window.

Below are some calculations I did. They are based on http://eeweb.poly.edu/~yao/EE4414/wang_videobook_ch01.pdf
pages 22-24

Do you think they are ok? Especially about the last example I am not so sure.

There are two ways to calculate PAR. One for square pixels, and one for line based systems, where every line of pixels represents one scanline. Every target which can be played back to a TV falls in the second category, for instance DVD, VCD, SVCD etc etc and of course the result of a capture card.

Square pixel is simple: PAR = DAR * (y pixels / x pixels )
which for square pixels reduces to 1 = 1.3333 * (y pixels / x pixels)

The other you use for anything where there is a 1 on 1 relation between rows of pixels and scanlines:

PAR = DAR * (line number / samples per line)

line number means all the lines in the frame, since on playback the missing lines are supplied by the device. For NTSC, this is 525.

Samples per line means samples per complete line, since again on playback a DVD/VCD player supplies the missing signal to make up the whole line. DAR is always 4:3 or 1.33333. Basically , you are relying on the DVD player, software VCD player or TV to create a picture with the correct DAR.

So for NTSC,

PAR = 1.3333 * (525 / samples per line)

Now, samples per line is (horizontal cap res * 63.555 / capture window in microseconds)

If you want to calculate this in DVD pixels, you can use

samples per line = (horizontal cap res * ( 858 / capture windows in DVD pixels)

If the sample rate is fixed, and there is no scaler, you can even use

samples per line = ( 63.555 * sample rate in MHz)

Now, the active capture area of your card comes in. Suppose you are capturing at 720 x 480:

for DV and other ITU compliant devices, this gives

PAR = 1.333 * (525 / (720 * 63.555 / 53.333 )) or 1.333 * (525 / (720 * 858 / 720)) = 0.816

If there is no scaler, the sampling rate, 13.5, is known so equally valid is:

PAR = 1.333 * (525 / (63.555 * 13.5 )) = 1.333 * (525 / 858 ) = 0.816

For BTwincap driver on BT878:

PAR = 1.333 * (525 / (720 * 63.555 / 52.74 )) or 1.333 * (525/ (720 * 858 / 712)) = 0.807

For Hauppauge dribvers on BT878:

PAR = 1.333 * (525 / (720 * 63.555 / 50.96 )) or 1.333 * (525/ (720 * 858 / 688)) = 0.780

For the targets, the PAR can be calculated from the active area, or from the sampling rate:

PAR = 1.33333 * (line number / (63.5555 * sample rate in MHz)

There is a nice table at http://www.uwasa.fi/~f76998/video/conversion/

DVD, 720x480:

PAR = 1.333 * (525 / (63.555 * 13.5 )) = 1.333 * (525 / 858 ) = 0.816

SVCD, 480x480:

PAR = 1.333 * (525 / (63.555 * 9 ) = 1.224

VCD, 352x240:

each pixelline represents 2 scanlines on playback, so total video lines is now 525 / 2 !!

PAR = 1.333 * ( 0.5 * 525 / (63.555 * 6.75 ) = 0.816

A few examples:

to make a SVCD using the DV cap:

Assume I want to keep all the lines and only resize horizontally

source PAR is 0.816
target PAR is 1.224

I need 480 * (1.224 / 0.816) pixels = 720 pixels at the source resolution.

I only need to resize from 720x480 to 480 x 480 and I am ok.

To make this same SVCD using the BT878 Hauppaige cap:

source PAR is 0.780
target PAR is 1.224

I need 480 * (1.224 / 0.780) = 753.2 pixels horizontally in the source

I only have 720, so now I need to add 24 pixels at the sides to produce 754 x 480 and resize to 480x480

But suppose I want to letterbox afterwards...............

I have 720 pixels in my source; these represent 720 * (0.780 / 1.224) = 458.8 pixels at the target PAR.

I can also resize 720x480 to 458 x 480 and add a total of 22 black pixels on the sides afterwards to make 480 x 480

But suppose I hate letterboxes and my source is progressive so I don't care about interlacing.............

if I resize 720 horizontal to 480 horizontal, the number of vertical pixels must change too, to keep the aspect ratio correct.

Basically, I have 458.8 svcd pixels worth of information which I enlarge to 480

So I would need (480 / 458.8) * 480 lines = 502 lines of SVCD lines to keep the aspect ratio fixed.

so: resize 720x480 to 480x502 and crop 22 lines

Last example: 640x480 square pixel, BT878 with BTwincap driver

Source PAR is 0.807
Target PAR is 1

I want to keep the vertical resolution identical. so I need 640 * (1 / 0.807) = 793.1 pixels at the source PAR. I only have 720, so I must add 74 pixels to get a total of 794x480 and resize to 640x480.

trevlac

28th November 2003, 17:21

@Arachnotron

I wanted to say that I will reply. I first feel I need to fully read thru the excellent PDF link you posted.

:D

Arachnotron

28th November 2003, 20:38

I first feel I need to fully read thru the excellent PDF link you posted

So do I read it completely myself I mean . I wish I found it a month earlier :D

But I already learned at least the last example is wrong. For Square pixel 640x480 the line-based PAR is

PAR = 1.333 * (525 / (( 640 * 63.5555) / 52.148) = 0.897

I'm still trying to figure out why it isn't "1" ... :(

Back to the drawing board !!
:mad: :mad:

Edit
I just realised, I should have normalized for the active area only, not the whole line (52.14 instead of 63.555, 480 instead of 525. To tired to do the math right now. And tomorrow.. HCC! The bigest computer faire in the netherlands.

Wilbert

29th November 2003, 14:48

Edit
I just realised, I should have normalized for the active area only, not the whole line (52.14 instead of 63.555, 480 instead of 525. To tired to do the math right now.
Of course, in that case the PAR equals 1, but it should be 640/648=0.988. Since the image is slightly squeezed.

I still don't understand it completely. I guess the DAR would be 1.35 (648x480) in that case, and

PAR = 1.35 * (486 / (( 640 * ???) / 52.148) = ???

I don't have access to a pdf reader on this pc, so I can't check anything.

Arachnotron

29th November 2003, 20:38

@ Wilbert

Hi Wilbert,

I remembered the NTSC active area wrong. It's 52.66, not 52.14.

I was trying to determine where Der Karl got his PAR's from in order to find a general method for scaling which is accurate for all cards after you have determined the active area.
Since I made some mistakes, and Karl calculated only in PAL, I think it would be easier to use PAL and deal with NTSC later. The active area is easier to calculate with, since it is 52 microseconds(which is exactly 702 ITU pixels) while for NTSC there is some ambiguity about the size of the active area, 52.66 +/- 0.2 accoring to BT.470-6.

Here we go again :D

PAR = DAR * ( line number / samples per line )

Line number is 576 NOT 625 ! That was my other mistake.

Samples per line is ((horizontal capture res) * (PAL active part line in microseconds) ) / (capture window of card in microseconds)

easier to work with would be ((horizontal capture res) * (PAl active area in ITU pixels) ) / (capture window of card in ITU pixels)

For PAL, the active area is 52 microseconds or 702 ITU pixels

For BT878, IUlabs or Hauppauge PAL, the capture area is 51.56 or 696 ITU pixels
768x576 : PAR = 1.333 * 576 / ((768 * 702) / 696) = 0.9915
720x576 : PAR = 1.333 * 576 / ((720 * 702) / 696) = 1.0575
704x576 : PAR = 1.333 * 576 / ((704 * 702) / 696) = 1.0816

For BT878, BTwincap PAL, the capture area is 52.15 or 704 ITU pixels
768x576 : PAR = 1.333 * 576 / ((768 * 702) / 704) = 1.0028
720x576 : PAR = 1.333 * 576 / ((720 * 702) / 704) = 1.0697
704x576 : PAR = 1.333 * 576 / ((704 * 702) / 704) = 1.0909

For DV, ITU card, the capture area is 53.33333 or 720 ITU pixels
768x576 : PAR = 1.333 * 576 / ((768 * 702) / 720) = 1.0256
720x576 : PAR = 1.333 * 576 / ((720 * 702) / 720) = 1.0940
704x576 : PAR = 1.333 * 576 / ((704 * 702) / 720) = 1.1189

DVD player, and other ITU device at 13.5 MHz:
PAR = 1.333 * 576 / (52 * 13.5 ) = 1.333 * (576 / 702 ) = 1.0940

svcd player, a device at 9 MHz:
PAR = 1.333 * 576 / (52 * 9 ) = 1.333 * (576 / 468 ) = 1.6410

vcd player, a device at 6.75 MHz:
PAR = 1.333 * 288 / (52 * 6.75) = 1.333 * (288 / 351) = 1.0940

In all this, I can still not find the 'generic' PAR used by Karl, 1.066666
But I think it corresponds to a 720x576 capture using a theoretical capture card with a capture window that is exactly 52 microseconds wide.

PAR = 1.333* 576 /( 720 * 52 / 52) = 1.066664

The other PAR, 54/59 or 1.0926 I cannot find at all. He claims this is the PAR for devices that output signals for TV like DVD players. But I get 1.0940 for DVD and VCD, 1.64 for SVCD. I don't get this.. :confused:

Nevertheless, I think that if you know the capture area used by your card, you can calculate the PAR for any capture resolution as above, take the target PAR and calculate exactly how to crop and / or resize.

Edit 1: as trevlac pointed out, at the cards active area should read capture window! changed that.

trevlac

30th November 2003, 04:03

Hello Folks. I'd like to give this a try :)

From first post
Last example: 640x480 square pixel, BT878 with BTwincap driver

Source PAR is 0.807
Target PAR is 1

Source PAR is 0.987, because the image was cropped. It was 640x486. NTSC PAR is 486/711 x 4/3 = 0.911 (see source link below)

BTWincap gets close with 712x480 because it crops 6 from the top. You have to add those back to get the PAR of 640x486.

http://www.quantel.com/domisphere/infopool.nsf/HTML/565C7D89F2D64F3680256C8000444A4D

Originally posted by Arachnotron
while for NTSC there is some ambiguity about the size of the active area, 52.66 +/- 0.2 accoring to BT.470-6.

Tell me about it! I just go with 711x486 because it is in the quantel link.

PAR = DAR * ( line number / samples per line )

Samples per line is ((horizontal capture res) * (PAL active part line) ) / (capture window of card in microseconds)

I think the bold part above is wong to use to express PAR. The cards crop the active picture. This does not effect the PAR nor the IAR. This follows thru for all of your calcs below.

You should express this as another factor, and then multiply it by PAR.

I want to call it CF or crop factor :) I'm not sure what you call the end value.

For BT878, IUlabs or Hauppauge PAL, the active area is 51.56 or 696 ITU pixels
768x576 : PAR = 1.333 * 576 / ((768 * 702) / 696) = 0.9915
720x576 : PAR = 1.333 * 576 / ((720 * 702) / 696) = 1.0575
704x576 : PAR = 1.333 * 576 / ((704 * 702) / 696) = 1.0816

768x576 : PAR = 1.333 * 576 / 768 = 1 * (696/702) = 0.9915
720x576 : PAR = 1.333 * 576 / 720 = 1.066666 * (696/702) = 1.0575

Does that number look interesting? Der Karl was saying that if you use a card that scales (does not grab the full 53.6666 ITU line), then you have to use 1.06666 as PAR. Problem is that he assumed the card/driver would at least grab the full active picture (52 microseconds for PAL). Although, it is interesting that he pointed out that they don't do this (are a few nano seconds off).

For BT878, BTwincap PAL, the active area is 52.15 or 704 ITU pixels
768x576 : PAR = 1.333 * 576 / ((768 * 702) / 704) = 1.0028
720x576 : PAR = 1.333 * 576 / ((720 * 702) / 704) = 1.0697
704x576 : PAR = 1.333 * 576 / ((704 * 702) / 704) = 1.0909

For DV, ITU card, the active area is 53.33333 or 720 ITU pixels
768x576 : PAR = 1.333 * 576 / ((768 * 702) / 720) = 1.0256
720x576 : PAR = 1.333 * 576 / ((720 * 702) / 720) = 1.0940
704x576 : PAR = 1.333 * 576 / ((704 * 702) / 720) = 1.1189

The above is misleading. The active picture area is not 52.15 or 53.3333. It can be at most 52. For these, the Crop Factor does not work because there was no crop. There was pad. Where as the Crop Factor is (Sampled Width/Active Width ) The Pad Factor is (Active Width/Sampled Width), the inverse.

In all this, I can still not find the 'generic' PAR used by Karl, 1.066666
But I think it corresponds to a 720x576 capture using a theoretical capture card with a capture window that is exactly 52 microseconds wide.

PAR = 1.333* 576 /( 720 * 52 / 52) = 1.066664

Yep. That's what I think.

The other PAR, 54/59 or 1.0926 I cannot find at all. He claims this is the PAR for devices that output signals for TV like DVD players. But I get 1.0940 for DVD and VCD, 1.64 for SVCD. I don't get this.. :confused:

I too was confused by this. I think he is a tiny bit wrong. His number is derived from a 'Standard' PC video sample rate of 14.75. Unfortunately, this is not really square, but 14.75*52 = 767. Working from this, one can get 13.5/14.75 = 54/59. A general NTSC number quoted is 10/11, where 72/79 is more correct when comparing PC pixels of 1:1.

Here is a link that shows the derivation of this 54/59. http://www.lurkertech.com/lg/pixelaspect.html

------------------------

To summarize my thoughts:

- Frame size does not equal PAR
- One can only calculate PAR from the Full Image (and no more)
- To get back to the Full image one must compensate for Pad or Crop

I like your calculation, but I'm not sure what to call it's result. I also think it hides the crop/pad that takes place.

This took me forever to type. :D I had to fix many errors in my reasoning. Hope I got close.

Arachnotron

30th November 2003, 15:01

@ Trevlac,

I am sorry about your long answer, but since most points are based upon mistakes I made I would like to ask you to look at the numbers in my last, PAL only post again bearing the following in mind:

1. In the NTSC post I made a mistake in using the whole line instead of the active part and 525 lines instead of 480. You should disregard the numbers in that post since they are wrong ( as I wrote in the PAL post)

2. In the PAL post, my calculations were correct. However, in my discription (it was late :( ) I used the term "active area" instead of "capture area" . I did use the correct numbers though.

I edited my PAL post to correct this (bold text)

A little background:

PAR = DAR * (number of lines) / (pixels in the active area)

since no card captures exactly the active area, you have to use an correction factor, which is a constant for a given card.

For an ITU card (I mean the ones without scaling) you have to
multiply by 52 and devide by 53.333 to get the numbers of pixels per active part
cap at 720x576, you get 720 * 52 / 53.3333 = 702
You can do this also in ITU pixels : 720 * 702 / 720

Could you please re-read it and say what you think bearing this info in mind?

Edit

I just finished the lurkertech article. You are right, that is the source of Karl's second PAR. Only I don't know if you should call it a PAR. It looks more like the conversion factor going from an ITU BT601 signal to industry standard square pixel.

Anyhow, it's more of a terminology question, it doesnt invalidate my calculations.

Edit 2

Suppose you capture 702x576 on an 13.5 Mhz device with active area of 52 microseconds or 702 ITU pixels

PAR = 1.3333 * 576 / ( 702 * (702 / 702)) = 1.0940
Or a single pixel is 9.4% wider than high

identical to http://www.quantel.com/domisphere/infopool.nsf/HTML/565C7D89F2D64F3680256C8000444A4D

So my way of calculating the PAR seems correct ?

All my calculations rests on two assumptions:

- the capture card does not resize vertically, one scanline produces one row of pixels;
- a picture cutout of 52 microseconds horizontally by 576 lines vertically produces an 4:3 image on a TV

(Assume you take an imaginary analogue TV camera and points it on a 4 meters wide 3 meters high wall and zoom in untill it completely fills the frame including overscan. This camera takes 64 microseconds to trace a complete line. At the point where 52 microseconds are spent scanning the wall, 576 lines will contain parts of the wall picture.)

trevlac

1st December 2003, 03:53

@Arachnotron

I did actually reply to your PAL post. In a long winded way I just was trying to say that the use of PAR "confuses" me. I can follow your calculations and I agree, they work. However, when I step thru in my head, I can't match it well to the math.

I think my trouble is PAR and pixles. These seem so artificial. Numbers are refering to pixels with different PAR values. There can be ITU, PC, and the unknown scaled cap pixels in 1 calculation.

I like how you use microseconds and sample rates. Going from that to pixels is simple. Talk of PAR seems to be an intermediate step to get to where we want to be. Maybe if we skip pixels and PAR it would be much more clear. :)

Since everyone wants to know what to resize to, given their cap; the simple answer is "Capture line width in microseconds" * "Sample rate of your destination pixels".

The sample rates are listed here: http://www.uwasa.fi/~f76998/video/conversion/#conversion_table

With this and info on the capture line length of card/driver combos, a simple table could explain it all.

Examples:
For BT878, IUlabs or Hauppauge PAL, the active area is 51.56
Regardless of what you cap at, resize to the following:

DVD 720 -- 51.56 * 13.5 = 696 and PAD to 720
DVD 704 -- 51.56 * 13.5 = 696 and PAD to 704
PC 768 -- 51.56 * 14.769 = 762 and PAD to 768
SVCD 480 -- 51.56 * 9 = 464 and PAD to 480
HHR 352 -- 51.56 * 6.75 = 348 and PAD to 352

For DV, ITU card, the capture area is 53.33333
Regardless of what you cap at, resize to the following:

DVD 720 -- 53.333 * 13.5 = 720 no pad or crop
DVD 704 -- 53.333 * 13.5 = 720, crop to 704
PC 768 -- 53.333 * 14.769 = 788 and crop to 768
SVCD 480 -- 53.333 * 9 = 480 no pad or crop
HHR 352 -- 53.333 * 6.75 = 360, crop to 352

-----------------------
Don't get me wrong. I think you calculations are correct. I just had trouble explaining them in 'English'. ;)

What do you think of the method above for resize instructions? It of course assumes no change on the vertical (which I think is a good idea anyway, unless you are dropping one of the fields.)

There would also have to be a way to give people their card/driver microsecond length if it was not known. :D

I would really like feedback from you and Wilbert on this. I like it so much, I might even do a write up.

North2Polaris

1st December 2003, 06:13

@Trevlac
@Arachnotron
@Wilbert

Over this Thanksgiving holiday in the States, I have been following your posts, reading the articles, and working through the calculations myself.

Trevlac, I was probably writing this about the same time you were writing your comments. I have made some suggestions below that remain more complicated than yours, but the intent is still to simplify and at the same time provide the details that will prove helpful to readers of Version 3 of the Capture Guide.

Part of my approach to these “aspect ratio” problems has been to identify definitions for terms. Unfortunately, some of terms are not consistently defined in the sources available on the Internet.

In some articles, calculations are based on “older” video standards, such as “industry standard” (12 + 27/99 MHz) square pixel format. The article by Pirazzi on “Square and Non-Square Pixels” and some of the examples used in the Der Karl article, “Capture Cards and Aspect Ratios for Dummies”, use this industry standard. In the Pirazzi article, PARS of 54/49 for 625/50 systems and 11/10 for 525/59.94 systems will seem mystifying at first to those used to working with computer monitors and thinking in terms of “true” computer square format pixels with a PAR of 1/1.

Some definitions may be hard to find, because they are found in a reference not written in a language understood by the reader. Many thanks to the Arachnotron for his translation of the article by Der Karl. It was not until I read this article that I was able to find a definition for “generic PAR”. According to Der Karl in Example #3, “’generic-PAR’ can be recognized by the fact that the entire 720 pixels contains picture information”. Based on a comment in the Capture Guide, I suspect that people who use FitCD and Gordian Knot may find the term “generic PAR” familiar. In addition, despite the best efforts of translators, the meaning of “generic” as used here may not be clear for many speakers of English.

I would like to suggest that the Capture Guide use the definition of PAR on page 23 of “Chapter1: Video Formation, Perception, and Representation” that Arachnotron brought to our attention:

http://eeweb.poly.edu/~yao/EE4414/wang_videobook_ch01.pdf

PAR = horizontal sampling interval/vertical sampling interval = IAR * fs,y/ fs,x

Where,

PAR = pixel aspect ratio
IAR = Image Aspect Ratio (this is equivalent to Display Aspect Ratio or DAR)(4:3 for PAL and NTSC)

fs,y = the number of horizontal lines
fs,x = the number of samples per line

horizontal sampling area = picture-width/fs,x
vertical sampling area = picture-height/fs,y

I find that the short form of this equation is easier to use, but it is important to realize its derivation:

PAR = IAR * fs,y/ fs,x

This equation combined with the methods used in “A Quick Guide to Digital Video Formats and Aspect Ratio Conversions” at:

http://www.uwasa.fi/~f76998/video/conversion/

seems to provide a way for readers of the Capture Guide who are moderately comfortable with mathematics to solve aspect ratio problems. With some editing, I think that this could be further simplified for readers who are less familiar with mathematics and/or less familiar with the English language. The table could also be simplified by including the most common PAL and NTSC formats and referring the reader to the full article for the more unusual formats.

The basic outline for conversion methods could be similar to that found in “3.1 How to use the table for conversions”:

Let's assume you have a video clip in one format and wish to convert it to another, so that it remains in correct aspect ratio throughout the process.

1. Locate your source and target formats in the table.

2. Calculate the vertical conversion factor: vertical_conversion_factor = target_active_picture_height / source_active_picture_height

3. Calculate the horizontal conversion factor: horizontal_conversion_factor = (source_PAR) / (destination_PAR) * (vertical_conversion_factor)

4. Calculate the new horizontal size: target_sampling_matrix_width = horizontal_conversion_factor * source_sampling_matrix_width

5. Calculate the new vertical size: target_sampling_matrix_height = vertical_conversion_factor * source_sampling_matrix_height

6. Resample the image to the new size

7. Check if the new size matches the target resolution's sampling matrix dimensions. If not, crop and pad accordingly so that it will.

Like Trevlac, I think that for clarity, PAR should be separated from cropping and padding and “conversion factors”. It is easier to deal with a complicated problem by breaking it down into its parts.;)

Arachnotron

1st December 2003, 14:17

OK, I take it everybody now agrees my basic calculations are correct, but not usefull in this form to explain the workings to anyone else unless they already understand most of it.

@ north2polaris

I agree with most your approach, but I think some explanation of cropping and letterboxing decisions as in Der Karl is inevitable considering we are talking analogue captures with 'dirty' edges here.

The number of examples need not be too great since 99% of the cases can be covered with the following 5 formats:

VCD
S-VCD
DVD full
DVD D1
square pixel for unscaled display on a computer screen

Anything more exotic can be referred to references

As a secomd point I would suggest to put the target PAR's in a table, but calculate the source PAR's, since they are dependent on card/driver caracteristics.

I would suggest to use a generic formula which incorporate a card/specific driver constant.

CCC (=card correction constant) = active area (PAL or NTSC) / capture area (PAL or NTSC)

The user will have to determine this only once, since it is independent of the capture resolution. When unable to do so can try some of the suggestions from a table of known examples.
I am writing a short guide on how to determine such a constant, and it should not be too difficult.

So, your source PAR becomes (4/3)*(captured_vertical_lines)/( CCC * captured_horizontal_pixels)

If you include an example, most readers should be able to calculate this.

If you want to go even further down the table road, by taking out the CCC, you now CAN make a generic table for each capture resolution. A generic PAR would be

(4/3)* (capped_lines)/(capped_hor_pixels_per_active_area)

The PAR for a certain cap resolution now becomes

(generic_PAR)/ CCC_your_card

@Trevlac

Yes, PAR's are very arteficial and difficult to visualize. But considering the number of variables involved, putting everything in a table becomes difficult.

My point was, that the PAR of the capture file is a variable, which , since you keep the number of lines a constant, depends on two things:
-How large is your capture window
-How many pixels do you put in it

So capping DV at 720x576 gives you the same pixel size as using my terratec Cinergy card and capping at 704x576 or capping 696x576 using a BT878, IULABS combo etc. etc.

Anyhow : thanks for the discussion up untill now! It's nice to finally begin to understand what it is I am doing :D :D

edit

There would also have to be a way to give people their card/driver microsecond length if it was not known.

I know, I know. I expect to have something in a day or 3 :)

trevlac

1st December 2003, 14:36

@North2Polaris

I think Jukka Aho's method is still too complicated. This is because he uses pixels. I say forget the pixels. Reduce the process from 7 steps to 3.

1) Look up source "sampling matrix width", and target "sampling rate" from the table.
2) Multiply this by target (source sampling matrix width) * (target sampling rate)
3) Crop/Pad

His 1st Example goes like this:
1) src sampling matrix width = 52.14815; trgt sampling rate = 13.5
2) 52.14815 * 13.5 = 704
3) Pad 704 to 720

This can ignore the crop/pad factor due to the cards/drivers. That is because we don't first translate the sample width to some standard and then translate it back. We just take what you got and turn it into the pixels you want.

As far as vertical, Aho points out anything other than .5,1, or 2 is strange. In fact, it is a real problem going from 576 to 480, and not as simple as a resize. So I ignore the vertical. If you want a simple change here you can just divide / multiply by a factor of 2.

Trev

Arachnotron

1st December 2003, 14:44

to break in on this :)

This can ignore the crop/pad factor due to the cards/drivers.

Using the src sampling matrix width is just changing one card specific factor for another.

Also, if you simplify to far, you end up creating a black box for the reader, which leaves him/her with a problem the moment something non-standard pops up.

trevlac

1st December 2003, 15:27

Originally posted by Arachnotron
Using the src sampling matrix width is just changing one card specific factor for another.

Also, if you simplify to far, you end up creating a black box for the reader, which leaves him/her with a problem the moment something non-standard pops up.

Hello...

I think (at least until you convince me otherwise) that the sampling matrix width is the only true factor. All others are derived from it. If you want to derive pixels, use it. The is especially true because we are talking about analog source.

I will post a simple table for know conversions.

What is a non-standard example to test my "simple method" with?

Going from 696(13.5Mhz)x576 to 640(square)x480 ? That seems to be a strange one to me. I guess people do this for PC viewing, but I'd think you would have to deinterlace first.

If you did not care about the interlace problem, I'd do this:
51.56 * 14.769 = 762x576 very simple so far.

Then since you want to shrink that by 480/576, just mult both dimensions by .8333 = 762*.83333 x 576*.83333 = 635x480
696x576 --> 635x480 & pad to 640x480 is perfect.

After all, you are the one who got me thinking in microseconds. Pixels with different PARs are like thinking in different currencies all at the same time (maybe easier for a European than a Yank).

Exactly how many Euros is 5 Gulden? :D

Arachnotron

1st December 2003, 15:58

@ trevlac

I agree with your calculations completely! And yes, working in microseconds and samplingrates instead of pixels is in the end what really happens.

It is just that I wonder if by doing this we end up with a to 'condensed' method for the guide. We get some tables, which will work in most cases.

Which is ok, but doesn' explain the why and leaves you with the problem of explaining how it matches with the PAR based methods found in the other references.

It's a judgement call; how far do you want to simplify things for the reader and how much do you want to explain to them

Exactly how many Euros is 5 Gulden?

Why, that is simple. You don't need to know. The kind people running supermarkets end espcially the bars increased the prices to such an extend that we got nice round figures in Euro's which are almost identical to the old numbers in guilders. And because this is so depressing when one consideres the current price of beer calculated in guilders nobody cares to try anymore. The results are to depressing ... :D

By the way, did you know that visiting Americans often find us Dutch a bit er.. blunt, if not downright rude? I wonder why... :D :D :D