Capture Guide Suggestions Part 2

[Arachnotron]

@ trevlac,

I still haven't finished reading your additions to the guide, but on a quick read my eye was caught by this remark:

It is assumed here that capping at 768x576 is not ITU compliant, in other words the full 4:3 image is captured. I haven't seen any evidence for this. So if you can capture at 768x576 with an ITU compliant capture card, please drop me a mail!

There was an inaccuracy in my determination of the capture area of the BT878 card with BTwincap drivers for PAL. Using a new method and cross-checking with your calculator (which is correct for PAL too by the way) I found an active area of 702 DVD pixels instead of 704. Which equals 52 µs.
(see http://www.arachnotron.nl/videocap/site/capture_area2.html )

So for this card/driver combo, capping at 768x576 results in perfect PAL square pixel. Of course, for most other drivers the result would indeed be something completely different.

I will reevaluate my previous results and keep you posted when I have done so. Expect no great changes (2 pixels at most) but in this case the result turned out a bit unfortunate.


edit I really shoud read better. Ah well, it is late.
I confused comments 1 and 4. Please disregard my comment about footnote (1)

[trevlac]

The footnotes were left over from Wilbert's original. They may not apply. I was tired by the end and figured I should get feedback before I worried about proper footnotes.

Some things I have learned since the proposal I made:

1) Resizes to even numbers should be ok in a YUY2 colorspace. This should probably be explained better. Wilbert pointed me to a link that does. http://www.avisynth.org/index.php?page=DataStorageInAviSynth

However, the final frame size may need to be a factor of 4 or 8 depending on the codec. This can be achieved with padding or crop. But, people may not be able to cap at numbers like 714x576. I have not researched what the codecs do, but erratic my shed some light if he can do 714x576.

2) In another thread I have been discussing this resize thing. Your PAR calculation seemed to be the best way in this particular case. In case I have not said it before, I think your calc is truely PAR for the captured pixels. The strange part is they are 'weird' pixels. Perhaps a simple picture will also help people. Here is what I was thinking....



A) _____________
B) ___________
C) '''''''''''
D) """""""""""


A) = Full Line Length 52ms
B) = Capture Line Length 51.56ms
C) = Captured Length in 640(?MHz) Pixels
D) = Captured Length in 762 Square PC Pixels

B, C, D all cover the same length.
D pixels just cover less of an area than C pixels. AKA, C pixels are wider.

3) At the bottom of this thread: http://forum.doom9.org/showthread.php?s=&postid=408652#post408652
Midelic, feels he has a simpler calculation for PAR, including the issue where the full line is not captured.

[erratic]

Originally posted by trevlac
However, the final frame size may need to be a factor of 4 or 8 depending on the codec. This can be achieved with padding or crop. But, people may not be able to cap at numbers like 714x576. I have not researched what the codecs do, but erratic my shed some light if he can do 714x576.

I can capture 714x576 fine with PICVideo MJPEG. I can open the AVI file with VirtualDubMod. If I use an AVisynth scipt (avisource) I get an error message: YUY2 images for output must have a width divisible by 4 (use crop)!

Immediately after the avisource command I have to crop or pad, then avysinth doesn't complain anymore.

[Arachnotron]

@trevlac,
@ medelic,

I have been ignoring the PAR discussion for a while since I was busy finishing my guide on determining the capture area. As soon as I have caught up I will give a fuller response.

In the meantime a few short remarks. Most is probably old stuff, but it helps me get my brain around it :)

The problem with PAR is that TV lines have no physical size or aspect ratio. The size of the picture, and it's aspect ratio, are entirely depentent upon the TV set. With a lot of TV's you can squeeze the picture vertically or horizontally, effectively changing the aspect ratio of the resulting picture without any change to the original analogue signal.

On my remote there is even a button which squeezes the picture vertically so you can correct for 9:16 pictures with incorrect aspect ratio's. When you press it, the lines are not changed; they are simply focussed on a more narrow area of the tube

This leave you with a problem when going from TV lines to pixels, which DO have an aspect ratio.

You have to define a standard.
Mine was that if you take 576 TV lines and put a frame over it that covers 52.0 µs of the total 64 µs line, the result on a TV set is DEFINED as having a 4:3 aspect ratio. This may not be entirely correct (in fact, on my own TV it is not) but that mostly does not matter.

You only use it as a reference value. As long as you use it both for the source and the target, you are ok, at least as long as both are TV based formats like VCD, DVD etc.

It becomes more difficult when you go to square pixel, where the relationship with actual TV lines is broken. There, the definition must hold for the result to have correct AR.

As you can imagine, for NTSC setting a workable reference frame is much more difficult.


So far, I have not found any CCIR or ITU recommendation giving a relation between lines and µs on the one side and aspect ratio on the other. Can anyone point me to one?

As to the point of slightly different active window sizes: this is a result of pixels having discrete values. You cannot have half pixels.

So if you take 52 µs at a 13.5 MHz sample rate, you get exactly 702 pixels.
But at 7.375 (CCIR CD-i) you get 383.5, which you must round to 384.

However, since this CD-i is played back at 7.375, the resulting Aspect ratio will still be correct, since the 52 µs window will contain the data from 383.5 pixels.

Again, as soon as you go to square pixels you run into a problem. But the problem is so small, it can safely be ignored.