Capture Guide Suggestions Part 2

[Wilbert]

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.
I totally agree with this. I would like to see two versions. The first one is a short version, which should be clear for all users (including newbies). The second one should be an extended version which also explains the why and leaves of explaining of how it matches with the PAR based methods.

The only problem is that I don't have time before half december to make a decent proposal. So, I'm waiting for you ;)

[Arachnotron]

@ Wilbert

I totally agree with this. I would like to see two versions. The first one is a short version, which should be clear for all users (including newbies). The second one should be an extended version which also explains the why and leaves of explaining of how it matches with the PAR based methods.

Hi Wilbert,

I am willing to have a shot at the second one, but cannot absolutely guarantee it will be finished at dec 15th. It may be a few days later.

With the first one, do you meen a Trevlac-style method with tables? Perhaps Trevlac is game? :)

[erratic]

Originally posted by Arachnotron
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. ;)

AFAIK if you don't have special testing equipment you have to compare your captured video to a test pattern on a TV to correctly determine the capture area of your card. Depending on the card/driver all of these are possible, based on your earlier tests:

720x576
720x480
712x480 (BTWinCap NTSC)
704x576 (ATI Radeon PAL based on my simple tests + BTWinCap PAL)
704x480
696x576 (Hauppauge/iuLabs WDM PAL)
688x480 (Hauppauge/iuLabs WDM NTSC)

But there's no way of knowing what is correct by just looking at a captured video frame on a monitor. Or is there?

[Wilbert]

I am willing to have a shot at the second one, but cannot absolutely guarantee it will be finished at dec 15th. It may be a few days later.
After Christmas is fine :)

With the first one, do you meen a Trevlac-style method with tables? Perhaps Trevlac is game? :)
Yes, something like that. Trevlac, could you give it a shot (i.e. make a proposal)?

[Arachnotron]

@ erratic

But there's no way of knowing what is correct by just looking at a captured video frame on a monitor. Or is there?

Yes, there is.

I'm writing a small guide on this, but it makes use of the fact that a DVD player plays back every pixel in exactly 1/13.5 microseconds

So you simply hook up your DVD player to your capture card (s-video preferably), capture at 720x480 / 720x576 and look how many DVD pixels per line have made it into your capture.

To improve readout, I use vdub's 'save image sequence' command to produce an BMP file of a single frame. I then open it in Paint, zoom to 800%, enable the grid en look at the left and right edge.

I created two DVD directories with a suitable 10 second testclip which runs in a loop. They are optimised for this kind of analysis. Simply devide the number of DVD pixels seen by 13.5 and you have your capture window in microseconds
Two test DVD's in video_ts format (burn with nero or the like)
HTTP://www.arachnotron.nl/videocap/download/areatest_DVD_NTSC.rar
HTTP://www.arachnotron.nl/videocap/download/areatest_DVD_PAL.rar

There are some issues with cropping by DVD players which I will adress in the guide, but the principle should be obvious when you watch the DVD.

Of course, you need a DVD burner to burn them but I will add a SVCD ISO image version later (SVCD plays at 9 MHz, so SVCD pixels/9 gives the capwindow in microseconds too, just slightly less accurate)

Also, you must use a stand-alone DVD player, not a multimedia PC. The TV-out of a PC does some scaling which would make the result unpredictable.

Ha! That is allmost half the guide right there :)

[erratic]

I have done the test with my DVD player and a miniDVD. I had to use a long crummy composite cable, by the way. I notice that the picture isn't perfectly centered, but I'm not sure how to interpret the results. Could you check out these jpegs?

http://users.pandora.be/erratic/ATI-PAL.jpg
http://users.pandora.be/erratic/ATI-NTSC.jpg

[Arachnotron]

NTSC: pixel 6 up untill 718 = 713
PAL: pixel 12 up untill 717 = 705

Most likely your card captures 704 ITU pixels PAL and 712 ITU pixels NTSC.

that is an area of 704/13.5 = 52.15 µs PAL
that is an area of 712/13.5 = 52.74 µs PAL

The centering is probably caused by the DVD player. I'll go into the artefacts of DVD's in my guide.

There is some blurring caused by the JPG which makes it difficult.

Try capping againn at 712x480 and 704x576 and see if it becomes clearer.

Does it by any chance have a philips SAA7xxx chip on it?

edit
look at the first 1 pixel vertical stripe on the left and on the right, and note the number next to it. Sometimes the image is a bit blurry and difficult to determine.
Try sending a bmp, packed with RAR instead of a jpg

[erratic]

Two .bmp files: http://users.pandora.be/erratic/ATI.rar (742KB)

[Arachnotron]

I get about the same reading from this.

6-718 = 713 for NTSC
13-717 = 705 for PAL

Most likely the real numbers will be 704 and 712.

There is always an uncertainty of about 1 pixel in the result because of peak width.

Anyways, for your card, if you cap at 704x576 or 712x480 you should be near enough to ITU / DVD pixel size to dispense with resizing. Simply leaving PAL as-is or cropping NTSC to 704x480 would give DVD resolution with correct PAR. (or padding both to 720 if you prefer)

[Wilbert]

Does it by any chance have a philips SAA7xxx chip on it?
Yup, SAA7108. But, I don't have a dvd writer.

[North2Polaris]

Originally posted by trevlac

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
@trevlac
Your 3-step method is a more elegant solution and is probably less likely to result in calculation errors than longer methods that involve working with PARs.

The second figure in the Der Karl article, “Capture Cards and Aspect Ratios for Dummies”, shows an "analog wave" and the relationship between sampling matrix width and active pixels. Including this figure in a guide using your method could help many users "make the leap" from pixels to sampling matrix width.

The use of "target sampling rate" can be explained fairly simply. What is needed is to resample that part of the analog TV signal or wave that is included in the sampling matrix width using the target sampling rate. This calculation will give the target width in pixels that can then be used to resize the video in the new digital video format.

As someone who uses AviSynth, this method will change the script order that I use.

For example, converting DV to XviD for viewing on a computer.

sampling matrix width for NTSC DV = 53.3333
target sampling rate = 12 + 24/79 MHz
target pixels = 656.2 or 656

The script based on your method becomes:

BilinearResize(656, 480)
crop(8,0,-8,0)

The recommended script based on the DV FAQ is:

crop(8,0,704,480)
BilinearResize(640,480)

When using this script from the DV FAQ, cropping to 702 would be better than 704, but 702 is difficult to get to using AviSynth in YUY2 colorspace. Your method may give a more accurate resize than the method recommended in the DV FAQ, but I am not sure how to evaluate this.

The script based on your method also works equaly well for the the "TV capture" using the ADVC converter that I described in an earlier post -- 640x480 without black borders.

Thanks to all of you for your help on this. If you need a newbie to review drafts of the new guides, I would be happy to help. :helpful:

[erratic]

Originally posted by Arachnotron
Most likely the real numbers will be 704 and 712.

The weird thing about the NTSC number (712) is that ATI MMC 8.7 (latest version) only supports 704x480 for AVI captures and 720x480 for MPEG-2 captures. Better capture 712x480 AVI with another app.

For PAL it's 704x576 AVI and 720x576 MPEG-2. PAL AVI is correct, but I prefer VirtualDubMod anyway. I used to love Virtual VCR but then I found out about the very annoying DirectShow AVI offset and the AVI offset calculator.

[Arachnotron]

Oops! To fast! I made a big mistake here!

For NTSC:

5.5 up untill 17.5 + 2 black on the right = 713 + 2 = 715 pixels!
715 equals 52.96 µs

For PAL:

12.5 up untill 717.5 is 705 = 52.22

You count the white lines as 'whole" ; the gray lines are the result of a pixel 'hitting' a peak on the flank and count roughly as half.

Very strange numbers indeed! I don't think this is an 13.5 MHz based card.

I suppose this means a lot of resizing. Sorry :D

[Arachnotron]

@Wilbert and erratic:

I just missed Wilberts remark about this card having a SAA7108 encoder/decoder.

That explains part of the crappy composite grab, since this chip has only a very basic combfilter. But it is a 13.5 MHz chip with an internal scaler.

ATI must really have done a number on the driver for this chip.

I will later produce a SVCD version of this DVD.

[erratic]

If PAL is 705 then I guess 704x576 is good enough without resizing.
Fortunately, NTSC (715) is not really my problem. :)

[erratic]

Originally posted by Arachnotron
@Wilbert and erratic:

I just missed Wilberts remark about this card having a SAA7108 encoder/decoder.

That explains part of the crappy composite grab, since this chip has only a very basic combfilter. But it is a 13.5 MHz chip with an internal scaler.

ATI must really have done a number on the driver for this chip.

I will later produce a SVCD version of this DVD.
I'm confused. I thought ATI made their own capture chip?

According to this page (http://www.aa981752.force9.co.uk/) ATI's Rage Theater capture chip appears on many ATI cards, from the Rage Pro 128 to the Radeon 8500DV.

In this thread (http://www.dvdrhelp.com/forum/archive/t176682.html) Metaluna writes that the AIW 9x00 boards (and the AIW VE) all have a new generation of capture chip, the Rage Theater 200, while the 7500, 8500DV, etc. use the older Rage Theater chip.

[Wilbert]

I'm confused. I thought ATI made their own capture chip?
Ohhh, I'm very sorry. I misread it :D I thought Arachnotron was asking for someone having a SAAA7xxx chip.

You are right, they have their own chip :)

[Arachnotron]

Check here (http://www.tech-report.com/reviews/2003q1/ati-aiw9700pro/index.x?pg=1)

It looks like you are right about it being an ATI capture chip.

From the specsheet of the theater 200 here (http://mirror.ati.com/products/theater200/theater200.pdf) I gather it communicates with the rest of the board using an ITU-656 interface; that implies a 13.5 MHz chip.

So probably the original theater chip is too.

But this is really getting off-topic :-)

[trevlac]

Originally posted by Wilbert
Yes, something like that. Trevlac, could you give it a shot (i.e. make a proposal)?

Sure,

Here is 1st cut at a table. I'd like to write some text around it and check the numbers, maybe breakout PAL and NTSC, but basically the table contains all of the resize widths for all of the cards from Arachnotron's tests. I may also add ATI as 52.148 for both PAL and NTSC. I'd base this on erratic's comments. I think he has commented on ATI. I may not remember this correctly. I'm tired ...


http://trevlac.us/Destination%20Width%20Resize%20Matrix.htm

[erratic]

Yes, I've tested ATI's Rage Theater capture chip.
Strange numbers: 705 PAL and 715 NTSC. :rolleyes:
I hope someone else will test ATI's newer Theater 200 chip.

[North2Polaris]

I have an ATI ALL-IN-WONDER 9000 PRO. I will try to run the test this weekend.

Additional information on the THEATER 2000 below. Should this discussion be moved to a new thread?

http://www.tomshardware.com/technews/20020104.html

"ATI says THEATER 200 is designed for use in consumer electronic equipment requiring video and audio capture, including multimedia PC to TV video graphics cards, set-top boxes, analog personal video recorders, LCD TVs, and other multimedia platforms. The chip captures Composite, S-Video, and Component (including High Definition) analog video signals and converts them to ITU-656 compliant digital video along with capturing the Sound IF (Intermediate Frequency) or composite audio outputs available from most tuners. It performs audio demodulation, stereo decoding, and outputs the decoded audio via I2S (inter-IC sound - a serial bus for digital audio). THEATER 200 features analog front-end circuitry that includes input source selection, anti-aliasing filters, advanced AGC (Automatic Gain Control) and Clamp circuitry, and dual 12-bit ADCs (Analog to Digital Converters). The video decoder includes Macrovision detection, a vertical and horizontal scaler, and an adaptive 2D comb filter. The chip supports video standards including NTSC, PAL, and SECAM, and audio standards including BTSC, DUAL FM, EIA-J, and NICAM."

[trevlac]

@erratic

I missed the discussion of your ATI tests. I missed that whole page #3, until just now. I see you have an 'official' number from the Rage Chip. Great!

@Arachnotron
@Wilbert

I don't think I mentioned it before, but in my focus on simplicity, I missed the fact that not using PAR makes it hard to match how many people think about and discuss this topic. Thanks Arachnotron for pointing this out.

I don't really like the table I made. I think it would be better to just list the Card/Driver capture line lengths and the sample rates of the standards, and let people do the math. I put some text around the explination, in another thread. I will re-read it tomorrow and try to come up with a 'proposal'.


@North2Polaris

It's great that you are participating in this. I consider myself a newbie. I've just been thinking about this topic alot lately.
:)

As far as the ATI chips being ITU-656, I wondered about that when I read about them before. As far as I know, ITU-656 just "describes the means of interconnecting digital television equipment". If the cards have a digital out, this makes sense. I'm not sure what ITU-656 in the absence of ITU-601 means.

I suspect they are like the other chips/drivers. They capture a portion of the full line and scale it to what you ask.

Here is a posted version of 656 http://www17.cds.ne.jp/~stray/ccir656.html

[Arachnotron]

@trevlac

The 13.5 MHz was just a theory, I have no way of knowing for sure. I just thought that because of the emphasis placed on ITU-656 in the specsheet, they might have made it 13.5 MHz since that would be the simplest way to do it. Leave the system on 13.5 and do the rest through scaling. But once again, it's just a guess.

Visual inspection might give an answer by looking what kind of crystals are on the card. The frequencies are written on them. You still need to be carefull with them, since the actual sampling clock is mostly generated from them

For instance, my philips cards are equipped with 24.676 MHz crystals which are used to generate an 27 MHz reference pulse.

[North2Polaris]

@Arachnotron

I ran your test on a ATI AIW Radeon 9000 Pro at three capture resolutions using VirtualVCR:

704x480
712x480
720x480

I also ran the test on a Canopus ADVC converter.

The 4 bitmaps can be extracted from the following file:

http://home.earthlink.net/~mcartter/sitebuildercontent/sitebuilderfiles/test_files.rar

As for the ATI AIW 9000 Pro, I "counted" 700.5 pixels, which would give a capture window of 700.5/13.5 = 51.8889, if I have followed your method correctly.

The ATI 712x480 and the 720x480 show evidence of scaling, correct?

How would you interpret the results of the ADVC converter?

Please let me know if my calculations are incorrect or if you would like me to run these tests again at different resolutions. I hope this adds to the database.

[Arachnotron]

@North2Polaris

Your DVD player crops and only displays pixels 7 up untill 715, so ca. 709 in totall

Als a result you captured some black pixels at the sides which DO count.

I therefor would set the ATI at 14.5-715.5 + 3 black =704 0r 52.15 µs

The ADVC is clearly an ITU device, since it captures

7 b + 7.5-715.5 + 4b = 709 + 11b = 720 DVD pixels or 53.33 µs

Notice also that your DVD player only displays pixels 7-715=709 pixels with blanking on either side. Unfortunatly, these numbers are completely different for each brand of DVD player which makes it impossible to say anything about the exact location of the center.

As to the underlying sampling which is re-sized, this is difficult to tell. It might be that the underlying sampling grid is 13.5 MHz, but slightly shifted compared to the DVD output. Or the underlying grid is not 13.5 and the pixels were made by scaling.

In the ADVC case I noticed the resulting ghosting is the same across the whole width of the capture. Notice that when yoy look at the ADCV cap at the range of verticle lines in the middle, they always have the same ghost on the left. From this I suspect 13.5 MHz sampling with the offset a little shifted compared to the DVD. So, no scaling at 720x480!

With the ATI, note that the ghosting in the lines on the sides does not match the ghosting of the lines in the center in the 704x480 cap (which should be unscaled if this were an 13.5 MHz device)
So I supect the ATI has a different 'base' sample rate than 13.5 and the ITU pixels are made by scaling.

(You can see this the clearest by cutting out a line from the outher edges and pasting it under a verticle line in the center at 800% zoom)


Notice by the way I am a complete amateur and may be completely off the mark. :)

[erratic]

I wonder why North2Polaris gets different NTSC results. My Rage Theater chip captures 715 lines, his newer Theater 200 chip captures 704 lines. I assume we're both using the same drivers, Catalyst 3.9 (the latest).

ATI's capture software (Multimedia Center) used to support 720x480 for NTSC, but lately that has been changed to 704x480. 720x480 has been removed from the AVI capture settings. That's why I already assumed that 704x480 would be correct, but my results were different.

Is this simply due to the newer capture chip or could my DVD player's NTSC output have something to do with it?

It would be great if someone in the US could test the old rage Theater chip (ATI 8500 or older card). We also need someone in PAL land to test the Theater 200 chip.

[Arachnotron]

@ erratic

Does your DVD player have a switch to force NTSC mode? If not, it probably put out a PAL-60 signal.

Perhaps that is the difference?

edit
By the way, the timing of a PAL60 signal is the same as NTSC, only the color coding is different. Which you would not notice with a grayscale testpic. But the ATI may treat it differently. The BT878/BTWincap combination certainly does judging by my earlier results
(PAL 704, NTSC 712 but PAL60 699 )

Your use of a composite lead increases the error somewhat (perhaps a pixel off) but not that much.

[erratic]

My DVD player does not have an NTSC switch, but I can capture the test pattern as NTSC, NTSC-J, PAL-60 and PAL-M. PAL-60 and PAL-M look worse (blurrier) than NTSC though. I don't think the capture area is different, however. Still 715 lines apparently, although it's hard to tell because of the blurriness.

[Arachnotron]

My DVD player does not have an NTSC switch, but I can capture the test pattern as NTSC, NTSC-J, PAL-60 and PAL-M. PAL-60 and PAL-M look worse (blurrier) than NTSC though

I suspect the signal was PAL-60, since most PAL DVD players do this when confronted with an NTSC DVD. The additional blurry could be caused by the comb-filter kicking in. But you are correct, if the area stays the same with all those settings PAL-60 should not be the problem here.

I'm baffled :confused: by this.

If it was your DVD player you would expect the PAL value to be strange also. By the way, what kind do you have?

[erratic]

My DVD player is a Neufunk 2210S (aka Bluesky 2210S (http://www.macetvideo.com/bluesky2210/bluesky2210.html)).

[trevlac]

You guys speak french too !?!

I feel so inadequate :stupid:

[Arachnotron]

You guys speak french too !?!

I don't, only German and English. We Dutch have to learn other peoples languages, because the rest of the world can't be bothered to learn ours. :)

Belgium also is a small country. And they already use two languages to begin with....

In the end we will probably all speak Chinese :D :D

[erratic]

I just tested my DVD player with some NTSC video in color. In ATI MMC, NTSC and NTSC-J are in color, PAL-60 and PAL-M are not, so the output from my DVD player is true NTSC, not PAL-60.

[North2Polaris]

Originally posted by erratic
It would be great if someone in the US could test the old rage Theater chip (ATI 8500 or older card).
I have an old ATI AIW Radeon, the first in the series with the Rage Theater chip. I put this card into my system and ran the test at 704x480 and 720x480.

The 2 bitmaps can be extracted from the following:

http://home.earthlink.net/~mcartter/sitebuildercontent/sitebuilderfiles/upload.rar

4 black + (7.5 - 715.5) = 712 or 52.741 microseconds

I am starting to understand how to read the test pattern. My count may be off a few pixels. The total may be 715. I am not sure where the cut off is on the right edge.

[Arachnotron]

The problem is that the right edges of your capture window coincide with the right crop point of your DVD player.

From the 720 cap it looks as if your DVD player only outputs pixels 7-716. I think the cap area is about 714 pixels wide, but it is very difficult to see because of this.

Could you try 712x480 too? (maybe using virtualvcr if the ATI tool won't let you do this) If the area really is 712, this should look much sharper.

I am working on a guide for this. The working version can be found here (http://www.arachnotron.nl/videocap/site/capture_area.html). It is by no means finished, but look at the second picture for an explanation of some of the things you might see at the edges

[North2Polaris]

@Arachnotron

Thanks. I did use VirtualVCR at 4 different capture resolutions, including 712x480. All 4 bitmaps are now in the archive below.

http://home.earthlink.net/~mcartter/sitebuildercontent/sitebuilderfiles/upload.rar

[Arachnotron]

There is a second method to read this testpic.

1. search for a verticle line from the array of lines in the middle of the pic on the left side. I chose line 80; this corresponds with pixel 79 in the 720x480 cap

2. search for another horizontal line on the right side with a matching gray block pattern. I chose line 490 which has the center in pixel 492 in the cap

zo, 490-80=411 DVD pixels ended up in 492-79=414 cap pixels

the cap area = (411/414)*720 = 714.8 = 715 DVD pixels

edit
With this card it is perhaps better to cap high and resize to 714.

This second method is soo much easier than the first, and much more accurate. Also, DVD player cropping is not a problem any more.

But now I have to re-write my guide. And maybe create other test DVD's :(. Oh well, back to the old drawing board :D

[erratic]

So the ATI results are:

Rage Theater capture chip:
NTSC - 715x480
PAL - 705x576

Theater 200 capture chip:
NTSC - 705x480
PAL - not tested (but probably 705x576)

AFAIK you can't use odd numbers for the capture resolution, so with a Theater chip the obvious choice for PAL is 704x576.

[Arachnotron]

@ erratic

Mostly the horizontal resolution must be devidible by 8 for capturing.

I'll look over the other caps using the other method tonight.

[erratic]

With my ATI card every resolution divisable by 2 seems to work, up to 720. The Rage Theater chip doesn't support 768x576, but 718x576 works. I've also tried 468x576 successfully (with padding afterwards for SVCD).

[trevlac]

@wilbert

I made a copy of the guide preface with my proposed changes.
http://trevlac.us/preface.htm

I tried to follow the original outline. The things I wanted to change were 1) Fit in new resize methods 2) Give info on card/driver specifics 3) Address PC,DVD,SVCD & VCD in a common way

Also, I find it inaccurate to refer to "frame size" as resolution. I tried to fit both in because most people seem to mean frame size when they say resolution.

Here is a link on the relationship between frame size, resolution , and bandwidth. http://www.maxim-ic.com/appnotes.cfm/appnote_number/750


@all

Feel free to give feeback. I would be happy to make any changes. You could also just grab the page and edit to your hearts content. Of course, this is all dependant upon Wilbert. After all, it is his guide.

BTW: I tried to add the info on the ATI chips. I may not have the final results correct. This is great stuff you are providing.

Trev :)


Edit:
I wanted to thank midelic for letting me try to explain resizing in this thread: http://forum.doom9.org/showthread.php?s=&threadid=65809
It was a great conversation for me. It showed me the limits of my simple method with a simple explination.

[trevlac]

Originally posted by erratic
With my ATI card every resolution divisable by 2 seems to work, up to 720. The Rage Theater chip doesn't support 768x576, but 718x576 works. I've also tried 468x576 successfully (with padding afterwards for SVCD).

My experience is also that factors of 2 are what is needed. I assume this is because 2 pixels share color information for 4:2:2, in 24 bytes. So samples are converted to pixels in groups of 2. Macropixels.

By this logic, if you cap in a 4:1:1 (4:2:0) color, you could only use factors of 4.

For MPEG and/or DV, there may be a requirement of (8s ?)16s. Due to Macro blocks. I'm not sure.

I'm not sure about all of this. Just what I'm guessing.


:D

[Arachnotron]

@ Trevlac

My experience is also that factors of 2 are what is needed. I assume this is because 2 pixels share color information for 4:2:2, in 24 bytes. So samples are converted to pixels in groups of 2.

It depends on the brand. Philips drivers will accept anything devidable by 2, but I think Hauppauge drivers accept only divisions by 8. But I am at work right now, so I cannot check it.

But I think it would be more of an restriction set in the driver than a hardware issue, and that devidibility by 2 is the only 'hard' limit for the reasons you mentioned.

By the way, nice work Trev. :D I have some reading to do tonight....

[erratic]

Well, with an ATI Rage Theater chip it's possible to capture NTSC@714x480 and then crop/pad to 704/720x480 for DVD authoring (no resizing necessary). That's how I would do it anyway.

[Arachnotron]

@Erratic,

You are perfectly right of course. Much easier.

[trevlac]

I just wanted to make some corrections to my macro pixel comments.

For Packed 4:2:2 fromats like YUY2, each macropixel is 4 bytes (16 bits per pixel) and contains 2 pixels. YV12 is not packed so no macropixels. Maybe you can cap in this at 1 pixel intervals (if the driver and card support it).

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_c/directx/htm/yuvvideosubtypes.asp

@erratic

I use BTwincap and cap at 712 and crop to 704 (while I cap). I use VirtualVCR's built in crop filter for this. I noticed you mentioned a problem with VVCR. Just another thing for me to look into.... The learning never stops. :)

[Arachnotron]

I just opened a new thread for the discussion about determining the capture area. That should leave this thread free for discussions about the new Capture Guide.

I recalculated the data accumulated so far, but no surprises :-)

Everybody interested in this, please move over to:

http://forum.doom9.org/showthread.php?s=&threadid=66191

[Arachnotron]

@trevlac
@erratic

About the issue about dividibility by 2, 4 or 8 : the driver may not give you a problem, but the codec might on later processing. Look at this thread a few days back:

http://forum.doom9.org/showthread.php?s=&threadid=65159

[erratic]

Originally posted by trevlac
I use BTwincap and cap at 712 and crop to 704 (while I cap). I use VirtualVCR's built in crop filter for this. I noticed you mentioned a problem with VVCR. Just another thing for me to look into.... The learning never stops. :)
AVI offset calculator (http://darkfalz.hypermart.net/software/): This is intended for people who use WDM capture device/programs. These often create AVI captures with internal audio and video offsets, which make their playback sync correctly but tend to ruin things when you try to edit them. This tool calculates the total offset, sets the internal offsets to zero, and renames the file so that you can manually adjust the audio skew in VirtualDub or other application prior to editing. This should result in proper sync for playback and editing.

A few threads you should read:
http://forum.doom9.org/showthread.php?&threadid=50978
http://virtualvcr.sourceforge.net/forum/index.php?act=ST&f=4&t=541
The most annoying problem is that the offset (reported by the AVI offset caclulator) sometimes needs to be fixed, but sometimes it doesn't, as you can read in the thread from the VVCR forum. That was driving me mad, so I decided to capture with VirtualDubMod instead.

[erratic]

Originally posted by Arachnotron
About the issue about dividibility by 2, 4 or 8 : the driver may not give you a problem, but the codec might on later processing.
Yes, I suppose people should test this first by capturing 714x480 and then try their usual post-processing on the AVI file until they're sure everything works.