Resize question

[midelic]

Something is not clear for me.Let's say i'm capturing to 640/576 rezolution and i want to resize after to 512/384(4:3)directly for example :bicubicresize(512,384).I'm not sure if i can downsize to 512/384 or i need other resolution.(ITU compliant?)

[trevlac]

What card/driver do you use to capture?
Are you viewing the end product on a TV or a PC?


I ask these because the right answer depends upon the answers.

I'd explain it this way: An analog PAL signal is 702x576 ITU-601 pixels. If everything is right, a ball is round. Your capture card driver captures a portion of this picture. Possibly even a 'larger' portion of this picture. It then most likely resizes to the 640x576 your capture app asked for. You have to know what the card/driver captures to calculate the correct aspect ratio. Finally, because PAL tv pixels are short and wide, and PC pixels are square, you need to know your end viewing method. A warning here. A software dvd player will try to adjust svcd/vcd/dvd source to PC viewing for you. If you do it yourself, and view this way, your doing it twice.

Here is an example based upon my best guess of what you have/want.

RealCaptureSize = 696x576 (of a 702x576 picture)
Asked for = 640x576 (the 696 is squished here)
Want 512x348 (which is 2/3 of 768x576 which is PC pixels that equal 702x576 TV pixels)

The 576-->384 is not in question.

The right target for the horizontal can be calculated (adjusting for all of the above) as follows:

640 * 696/640 * 128/117 * 2/3 = 508. Take this and pad to 512. :)

The above calculation is:
App Capture size * (Adjust for driver/card capture vs app capture size) * (Adjust from TV to PC pixels) * (Adjust for desired resize)

Here is a BBC link that explains some of the stuff. It does not talk about the fact that your card probably does not grab the complete active picture.

http://www.bbc.co.uk/commissioning/branding/picturesize.shtml

Hope this was clear.....

[midelic]

My card is based on BT878a chip and i use drivers from iulab(I can capture max to 768/576).The end product is for PC.I'm capturing from TV.
Let's suppose we have 2 scenarios.
1.First capture to 640/576,then resize to 512/384(4:3)then resize by player to 1024/768 which is also 4:3
2. capture to 640/576,resize to 512/448(almost the same PAR),then resize by player to 1024/768.(4:3)
Is not better have the file 4:3 aspect ratio if my final view is on computer display (ratio 4:3) ?Am i not loosing quality if the picture(non 4:3) is stretched to fit the computer rezolution?
I want to now if it is necessary to keep the same aspect ratio of the end file when i resize from 640/576 .

If i understand well from Karl's guide if my source is 640/576 and the target is PC (PAR 1:1) whith a file rez.512/384(DAR 4:3),I have to add 128 pixels to 640 to get 768,and after resize to 512/384.It is correct?It,s confusing when you have to resize from a resolution non standard(640/576)to a resolution for PC viewing .All guides show resizing from 704,720,768/576) to 640/480(4:3)(which is easiear,you can do it almost directly)
Thanks,
Regards

[trevlac]

For some reason, this topic is very confusing. I was confused reading your post. Let me try to explain what the process is. This should allow you to get the correct answer.

1) A pal picture is 4:3
2) A pal picture is 52 microseconds wide by 576 lines
3) A pal picture is 702 PAL TV pixels by 576 pal TV pixels
4) A pal picture is 768 by 576 square PC pixels
5) If your card/driver captures the entire active picture, what ever you ask for is 4:3. 720x576 is 4:3, 704x576 is 4:3, 640x576 is 4:3.

All of the above are 4:3. When you talk pixels, you need to know what kind you are talking about. #3 above is the same as #4. One is for TV, the other is for PC. Der Karl refers to one as 54/59 par and the other as 1:1 par (actually, I think 117/128 is more accurate than 54/59). For #5 at 720x576, he refers to this as generic par. He does not give the par for the others. Par by the way is Pixel Aspect Ratio. If your picture has not been cropped, you can always determin the par by dividing height by with, then mult by 1.333. (640x576 = 1.199 PAR). Unfortunately, if you crop, this no longer works. I like to think of these things as different currencies (euros, dollars, rupies, pounds, etc.). They measure the same thing, but they are not the same scale. Calling them all pixels confuses the matter.

The one thing Der Karl mentions but does not take into consideration is that your card crops a bit off of the original PAL 4:3 picture. A PAL TV picture is 702x576 TV Pixels (Pounds). Your card only gives you 696x576 TV Pixels (a few pennies short). If you asked for 640x576 (dollars), you may not know you got shorted. If you ask for 768x576 PC Pixels (euros) you also may not know you are missing out.

So the right answer is as follows: :D

If your PC app is going to resize to PC pixels (PAR of 1:1), then as long as you don't crop you original picture, it does not matter what you capture at. Although a bigger frame size should have more resolution. :)

Unfortunately, your card does crop. But you can just add back to be ok. If you lost 6 (TV Pixels or 1.094 PAR or Pounds), and you want to add them to a 640x576 (unknown PAR because of the crop or Francs) cap. You can work from what you do know. 696 and 640 represent the same thing. You know the 6 because you know 702 was the original picture. So 702-696 = 6. 640/696 = 0.9195 * 6 = 5.5 (Franc) pixels. 646x576 should be 4:3 (or close). If your PC app resizes this to 1:1 PAR PC pixels at 4:3 (such as 1024/768), you are set.

If you don't want to store your stuff at 646x576, you can resize to what ever you want (from 646x576) as long as you resize to 4:3 when you view it. (It sounds like your viewing app does this 1024x768 resize for you.)

I hope this helps. If you cap at 768x576, I'm not sure what your card/driver does. I made a calculater that should tell you what your card/driver does. Don't pay attention to the advice. I never completed that part. But the cap size info is correct.

http://trevlac.us/BT8x8calc.htm

Trev

[midelic]

Sorry, I was confused you.

Let me see, if I understand correctly:
1. Rez.720,704,768,640x576 PC pixels ,means resizing up or down from 702(cropped to 696)x576 TV pixels(using Bt8x8 chip whith iulab drivers).
2. You told me 640x 576 is 4:3 because the card is capturing the entire active area 702(696)x576 Tv pixels, resized(So 640x576 is equivalent 4:3 Tv aspect ratio and DAR=1.1111 PC ???).
3.If I don't crop, I can resize to 512x384 or whatever(multiple of 16) as long as I resize to 4:3 by player.
My question is ,if I crop(garbage ,black borders,overscan ) and I want to resize, how do I calculate the new width and height of the end file(PC target) .Of course the PAR has changed from 640x576(DAR=1.1111???and PAR=1.199) to whatever new PAR.The target file must have the same PAR whith the cropped source or doesn't matter?
Thanks for info,
Regards

[trevlac]

Sounds like you do know basically what is happening. :)

In another thread, I've been discussing a good clear way to do this. I'd like to try the idea on you. I'll try not to make it too long. I am changing some of what I said before. I want you to get the perfect PC size regardless of your player.

Forget PAR and Pixels.

Idea #1

Analog PAL TV is a continuous signal. This signal repeatly traces 625 lines in a zigzag fashion on your TV. Each line takes 64 microseconds to trace.

When you capture/digitize this signal, your card only looks at a 51.56 microsecond portion of only 576 lines. This is ok because at most, only 52 microseconds of the full 64, on only 576 lines, carry any picture info. You get 51.56 by 576 of a possible 52x576.

I repeat, your card always digitizes 51.56 microseconds for 576 lines. This is regardless of what dimension you ask.

Idea #2
If one was to turn a continuous line into pixels. One would sample a piece of it at a set interval. This in effect would be a dotted line that followed the original. Actually, If you want to turn a pixel line into an analog signal, it makes sense to do just the reverse.

In effect, video standards each have a specific sample rate. For DVD Pixels, one would sample a 53.333 microsecond line at 13.5 samples per microsecond. The result would be 53.333*13.5 = 720 DVD samples/pixels.

Here are some standard sample rates. Players must "reverse sample" to play one of these standards. Cards that capture to a given spec, must sample at these rates.
DV/DVD - 13.5 MHz
SVCD - 9 MHz
CVD - 6.5 MHz

Although there is no PAL TV on a PC capture hardware or hardware player, the sample rate for PAL TV on a PC can be calculated as 14.769 MHz.

Conclusion
To get DVD, SVCD, or even PAL TV on a PC pixels, you simply multiply your captured line length by the sample rate of your destination standard. This is what a hardware converter would do.

Following this, regardless of what width you capture at, you can resize to a standard width. For example, for PC viewing, a 51.56 line * 14.769 rate = 761.49 pixels. You probably use YUYV or some sort of 4:2:2 pixel storage. Because of this you should round to an even number (762) because 2 pixels share color info.

Croping the 'dirty edges'
At this point, you can crop the 762x576 as much as you want, as long as you pad back to equal 4:3. If you did not crop the vertical, you need to pad back to 768x576.

"Non Standard" PC frame sizes
If you want something like 512x384 vs the "standard" 768x576, you can simply reduce the whole thing by some set amount. In this case, 384/576 = 2/3 the standard size. Instead of resizing to the 'standard' 761.49 mentioned above, resize to 761.49 * 2/3 ~ 508.

Now do your croping, and pad back to 512x384.

Finally

You should now have a 4:3 picture suitable for any PC player. The original picture line was simply turned into PAL TV on a PC pixels, at 2/3 the "standard" size.


What do you think? :)

[midelic]

Interesting,
1. So:
74.074 nanosec /pixel
51.56:74.074=696 pixels Tv, which my card delivers, and
1:74.074=13.5 Mhz( Tv)
versus:
1:14.769=67.709 nanosec /pixel
51.56:67.709=761.494=762 pixels (PC)

Anyway ,I'm not interesting of adding any black borders to the whidth better cropping more the height centered the image and resize to whatever 4:3. So if I crop the height shouldn't I take in consideration PAR.

2.I've read some of your posts about the real capture area .I want the ask you something about the real motion area of a capture .So a capture card whith Bt8x8 and btwincap drivers has 704x 576 capture active area ,and a card Bt8x8 whith iulab drivers has 696x576 active area.I captured 2 small videoclips, one 640x576(whith iulab drivers)and the other 640x576(whith Btwincap drivers).I made 2 screen shots and I zoomed them.On the one whith iulab drivers I observed 1pixel black border on the left side.On the other(Btwincap) there are 5 pixels on the left and 1 pixel on the right .So is posible to be not so much diference in moving area size of the two capture ,knowing the signal(iulab drivers)is a bit off 51.56 versus 52 (standard)?

[trevlac]

Thanks for responding. I'm trying to come up with an easy way to explain all of this. I'm testing on you.

1) 14.769 sample rate * 51.56 microseconds = 762x576 PC pixels. If you'd rather crop some of the picture than add black, just crop down to a 4:3 ratio. 760x570 seems to be the next one down. This is easy because the PAR is 1. Padding for TV viewing (Non 1 PAR destinations) does not make as much of a difference. The TV overscan will hide even large borders. If one views SVCD/DVD/VCD on their PC, they may see the pad. I'd have to think about how to crop without speaking par for these.

2) The real motion area of a PAL signal is 52 microseconds by 576 lines. 702x576 13.5MHz pixels. Depending on the source, the full frame may not be filled. So given this, the minor differences in how much of the picture you get is no big deal. The only difference is that if you ask the BTwincap for 704(DVD) you get 704. No resize needed. If you ask iulabs for 704, you only get 696. Just a bit off.

[midelic]

Again we start whith:
14.769 sample rate*51.56microsec=762/576 Pc pixels.
But if I ask for 640/576 PC, that means resize from 762/576,not from 696/576 tv pixels because i capture all PC PAL lines(You said somewhere about resize from 696/576 to asked resolution)

[trevlac]

Originally posted by midelic
Again we start whith:
14.769 sample rate*51.56microsec=762/576 Pc pixels.
But if I ask for 640/576 PC, that means resize from 762/576,not from 696/576 tv pixels because i capture all PC PAL lines(You said somewhere about resize from 696/576 to asked resolution)



Let's say i'm capturing to 640/576 rezolution and i want to resize after to 512/384(4:3)

I'm sorry. Again I am being unclear. I'll try to answer your simple question.

If you capture at 640/576 with the iUlabs driver, you are capturing 51.56 microseconds at a rate of about 12.41MHz. 12.41 * 51.56=640.
You want square PC pixels. That would be a rate of 14.769 * 51.56=762x576. You want a final frame size of 512/384 which is 2/3 of full frame square pixels 768x576. You want to crop not pad so you dont see any border.

To summarize: You need to go from 12.41MHz pixels to 14.769MHz pixels, crop some, and hit exactly 512x384.

To do this, I'd convert from 12.41 to 14.769, up H by 2*4 and the V by 2*3 to get the H above 768, shrink to 2/3, and crop to exact size.

640x576-->762x576-->770x582-->513x388-->512x384
Or in short, resize to 513x388 and crop to 512x384. If you don't like 513(I don't), use (774x585) 516x390 and crop.

Now my questions to you are:

Why do you cap at 640? Can't go higher? 768 would give you more info for filters. If you don't filter and can cap custom, go directly for 516x390 and just crop.

Why 2/3 size? This will most likely mess up the interlace. Do you deinterlace before you resize? You should. If you deinterlace, ignore my 'direct cap' comment above. Actually, because you don't want borders, the resize is some odd amount, not really 2/3.

I must say, I do not watch stuff on my PC, so I don't really understand your motivation.

Back to your player. If it resizes what ever you have as long as it is a 4:3 ratio, you could also just crop the 640x576 down a bit and forget about 512x384. 640x576 == 762x576 in different pixels. 760x570 is 4:3 in PC pixels. 760/14.769=51.45msec. 51.46*12.41 ~ 638x570. So crop 640x576 to 638x570.

To answer some other questions.
If you player resizes to 4:3, and you have a full frame, ie 638x570, you will get a non distorted picture, because the original 4:3 picture is squeezed into the 640. The player will just unsqueeze.

If you watch at 768+ and cap at less, you are loosing resolution.

I hope I've helped. I'm sorry I have not been clear. I've been thinking about this topic too much lately. Your requirements of not padding and hitting 2/3 of a full frame really throw a wrench in my simple method.

Thanks

W

[midelic]

I've learned a lot from you.
I understand now many things.
So ,don't be upset on me if i continue whith this.


First I don't see the link between 12,41 and 14.769 (640 and 762)in your calculation.How do you convert it? 640/576 are not square pixels and 762/576 are square pixels cropped from 768. How do you get 516/390 from 640/576?For example if I capture 620/576 ,I get resizing the same 516/390 like before?
Secondly if is not posible to get exactly 512/384,how do I get (calculations) one closer to this(to view on a pc not distorted),but resulted from 640/576 cropped all around (for example 638/570) .Eventually I will accept black bars, but only for the height.How do you calculate this whithout PAR?In conclusion ,I want a picture resolution(resized) to view on a pc(in full screen) without distorsions(ball to be round)
Sorry but is something unclear here.

1.I use 640/576 because I'm capturing directly in Xvid (need performant processor).If I raise the resolution I get dropped frames.
2.I use postprocessing filtering(deinterlace,denoising) and resizing the movie for easy archiving(HD or CD)
3.I prefer whatching movies on the computer instead of tv because of higher resolution and better video quality.(Better,I'd have big display monitor for viewing movies)

What I understood from other guide, it?s not corect to consider 14,769 Mhz sample rate, real.The real one is 14.75 MHz ,delivered by any video card for the real "square" pixel ,which is not really square(768/767 ratio). The 14,769 million pixels /sec sample rate, is for teoretical purposes for comparation ,representing the ideal 1:1 square pixel(which not exists).So in fact 51.56 x14,75= 760 (almost square)pixels
Thanks,
Regards

[trevlac]

Originally posted by midelic
I've learned a lot from you.
I understand now many things.
So ,don't be upset on me if i continue whith this.

I've very much enjoyed our conversation. I was hoping you were not angry with my dezlânat talk. I'm happy to continue. I will be out of town for a few days, so it may take some time for my next reply. :)


First I don't see the link between 12,41 and 14.769 (640 and 762)in your calculation.How do you convert it? 640/576 are not square pixels and 762/576 are square pixels cropped from 768.

640 and 762 are both representations of the same line length. The 640 pixels are wide and not of any standard. The 762 ones are square and perfect for a PC. I came up with 14.769 because I know the full PAL line length is 52mSecs, and 4:3 PAL in square pixels is 768x576. 768/52mS = 14.769MHz. I also know your line lenght due to tests run by Arachnotron. 51.56mS. So you only capture 51.56*14.769=762 square pixels. Because you captured the 51.56 length as 640 (non square) pixels, I can calculate the rate as 640/51.56 = 12.41. So there really is no conversion. 762 and 640 are the same length, just in different size pixels. Because you want square pixels, I prefer to forget about the 640 if I can.


How do you get 516/390 from 640/576?For example if I capture 620/576 ,I get resizing the same 516/390 like before?


640x576 and 620x576 are both the same as 762x576. First 2 are wide non standard pixels, last one is square PC pixels in a non 4:3 frame. I prefer to work in the 762x576 number. You wanted 512x384, which is 2/3 of 768x576. Reducing 762x576 by 2/3 would give you 508x384. You did not want to pad the width but wanted to crop the height. To achieve this I suggested adding groups of 4 pixels to the width and 3 to the height until you got 508x384 up to your target frame size, all around. 508+4/384+3 = 512/387, 512+4/387+3 = 516/391. Actually, I added the 4:3 pixels to a 762x576 frame because I thought it would be better to do before the 2/3 reduction. So the numbers for this example are a little different due to rounding. Generally I'd say it is better to resize to an even number. I'm still learning why this is, but even is better.


Secondly if is not posible to get exactly 512/384,how do I get (calculations) one closer to this(to view on a pc not distorted),but resulted from 640/576 cropped all around (for example 638/570) .
...
How do you calculate this whithout PAR?In conclusion ,I want a picture resolution(resized) to view on a pc(in full screen) without distorsions(ball to be round)

Perhaps Arachnotron's calculation of PAR would be better for you.
PAR = 1.333 * 576 / ((640 * 702) / 696) = 1.19. Replace the 640 with 620 if you cap at 620. 696 is your cards line length at 13.5Mhz. 702 is the full line length (52ms) at 13.5MHz. BTW: 13.5 is the DVD standard sample rate.

How do you use this 1.19? 640 * 1.19 = 762. Because you want the width as reference (don't want to pad) crop the 576 until you get 1.333. or about 570. 762(640)x570 = 1.336 Now resize to 512x384. :)

In other words: crop 640x576 or 620x576 to 640(620)x570 then resize to 512x384.

Seems so simple. Maybe Arachnotron should have saved you from me. :)


Eventually I will accept black bars, but only for the height.

You will never need bars on the top/bottom. You need width to get the full picture.



What I understood from other guide, it?s not corect to consider 14,769 Mhz sample rate, real.The real one is 14.75 MHz ,delivered by any video card for the real "square" pixel ,which is not really square(768/767 ratio). The 14,769 million pixels /sec sample rate, is for teoretical purposes for comparation ,representing the ideal 1:1 square pixel(which not exists).So in fact 51.56 x14,75= 760 (almost square)pixels


Actually, 14.75 is derived from how old MJPEG capture cards worked. If you viewed their results on a PC, the picture would be very slightly off. Video or pictures origniating from the PC are truely square. If you want to display on the PC a 100% proper TV picture, you would not use 14.75. The 14.769 number is derived, but correct. It is based upon the fact that 1) PC pixels are square (PAR 1:1), 2) a PAL active picture is 52msec in length and 576 lines in height, 3) A PC screen has a DAR of 4:3.

768/576 is 4:3, 52 * 14.769 = 768.

In some of those other threads there are links that go into more detail.

Trev

[midelic]

I think, I've found out a way to calculate this ,mathematicaly more simple:

640*576 non square pixel and 762*576 square pixels represents the same PAL frame,but you can transform(in fact scaling) one pixel to another.For example one pixel is x mm wide and y mm height and the other y mm wide ,and y height(square)so we have:
640 pixels (x mm wide)and 762(y mm wide).To do this scaling we simple : 640(x wide)*(762/640 scaling ratio factor)=762( y wide)square pixels.

So capturing to 640*576 ,cropping to 638*570(non square pixels, but the same x wide pixels as 640*576) ,scaling in square pixels: 638*(762/640)=760*570(570*1.3333=760)square pixels(4:3), now resize to 512*384. Simple isn't it? So we need source witdh to calculate scaling ratio factor.
It's almost like Arachnotron's method above .I wrote this before viewing your post.I hope ,I didn't invent hot water.

Another thing, I've just find out.
762/576 is not a valid (yuy2 or yv12)resolution.
The width must be multiple of 4.
So in my case 760*576 is full pal,640/576 is coresponding to 760*576. When I capture I loose 2 more pixel due to color conversion.
Try to capture to 762 /576 ,you'l see you can't or you capture to 768/576 and crop to 762/576, and again you are not allowed.So we have to recalculate .

Thanks

P.S.You start learning french and ending whith romanian.

[trevlac]

I'll point Arachnotron to your calculation. I wanted to add the following to help people reading this. A confusing thing is that 640 = 762. This is because 640 units are wider than the 762 units.


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.

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

As far as 762 not being valid. YUY2 and YV12 can both have sizes that are factors of 2 (not just 4). It is the codec that compresses the final result that may limit to 4. So you can resize to something like 762, as long as you pad/crop to 768 before your codec saves the results.

Here is a link: http://www.avisynth.org/index.php?page=DataStorageInAviSynth

I've been looking into this myself. It appears huffy needs 4s. Uncompressed would be ok with 2s. Mpeg would most likely need 16s.

[Wilbert]

Minor correction. In the same link it is said that interlaced YV12 should be mod 4.

It is the codec that compresses the final result that may limit to 4.
True.

[Arachnotron]

@Medelic

If I understand correctly, you want to:

- cap with BT878a and iulabs drivers at 640x576
- resize to 512x384
- loose all the 'junk' pixels on the sides

Your method is actually a rewrite of the calculations I did and the ones Der Karl did. The differences lie in the order in which you do the steps, and sometimes which steps you combine to one step.

Though you didn't write it down in the last post, you start out by converting your cap to square pixel using the PAR for your card; you just split it up in steps.

If you have to resize and crop in both directions, converting to square pixel is a good step to take to get your brain around it. :)

Below an example on how I would calculate this. The numbers are a bit different because of a change in capture window:

The iulabs driver on the BT878 captures an area of 51.48 µs or 695 ITU pixels. My original measurement was 1 pixel off.
That makes the source PAR:

1.33333 * 576 / (640 * 52 / 51.48) = 1.188

From a small cap I made, I notice 3 black lines at the top, 8 at the bottom. The sides look ok to me, but lets assume you want to loose 2 pixels on both sides.

That makes a crop of 4 lines at the top (3 will give problems), 8 lines at the bottom and 2 on either side. If the codec/colorspace you use has other restrictions, you might have to crop differenty

I now have a clean picture of 636x564, but still with PAR = 1.188 since cropping doesn't change the PAR.

Since you want to resize both horizontally and vertically, it is easier to calculate from a square pixel intermediate.

To transform a line to square pixels you would get 636 * 1.188 = 755.6

so the cropped cap would be 755.6x564 in square pixels.

so I need (512/755.6)*564 = 382.2 lines if I want to use all the horizontal pixels from the cap

Or, I need (384/564)*755.6 = 514.45 pixels if I want to use all the lines from the cap

So I can either resize 636x564 to 514x384 and crop 2 pixels or
resize 636x564 to 512x382 and add two black lines at the bottom.

Again, codec permitting

Of course, this will look horrible because of interlacing artefacts. Don't do this at home! :D

@everybody: is this correct???

edit

this is a truly horrible target resolution. If you own a NVIDIA based card (geforce) you might want to look in on this (http://www.inmatrix.com/files/dcgenie_download.shtml)

This util adds a 768x576 resolution to your PC.
then simply cap at 760x576, pad and letterbox without resizing and you are done :).

edit2
@Medelic

Reading back my response I realize my answer may sound a bit negative about your calculations. It is not intended to be. There are many ways to get from A to B.

The basic formula's are simple and contain only a few steps, but there are different ways to write them down and to use the ratio's in them (sampling rate ratio's versus windows in µs ratio's versus DVD/ITU pixel ratio's) and in the order in which you calculate things. As long as all the basic steps are there, and the final aspect ratio is there, just take the one you are comfortable with.

[trevlac]

Originally posted by Wilbert
Minor correction. In the same link it is said that interlaced YV12 should be mod 4.

But I thought it said that for height. Width is ok at mod 2. I think if you don't deinterlace and you are not going for a height of 576, 288, or 144, you are asking for trouble. 384 for example is mod 4, but if you went from 576, the only I could see that working is seperating the fields, resize, weave. Even at that, you are asking for 6 lines to become 4. I'd think it would not work well.

I of course have not practical experience with this. I mainly do NTSC full height for TV viewing.

By the Way; erratic has reported he can do a 714x576 cap (mod 2 width) with Pic mjpeg. Then avisynth complains, if he does not pad/crop 1st thing.

[midelic]

@trevlac
I coulnd't set 762/576 capture size regardless of huffyuv or Xvid.
In virtualvcr I received " Cannot Set Video Format E-Fail;80004005"
@Arachnotron
PAR=1.33333 * 576 / (640 * 52 / 51.48) = 1.188
I've seen you took the reference 52*14.769=768 pixels.But in fact i get 51.48*14.769=760( cropped from 768) square pixels full Pal picture non 4:3.The problem is to determine the full pal resolution in square pixels.If you do that the rest is simple math.So the question is how many square pixels width my card delivers?If i ask 768/576, that's mean resize from 760/576?I think, what i need is a resolution whith PAR 1:1 not necessarily 4:3 as long as i get 4:3 from player.Maybe, is something that escapes from me.
And before resize ,I deinterlace.Whith my calculations,after cropping I got 508*382 resolution square pixels

[Arachnotron]

I've seen you took the reference 52*14.769=768 pixels.But in fact i get 51.48*14.769=760( cropped from 768) square pixels full Pal picture non 4:3.

You are looking at it from the wrong angle. Your source PAR is 1.188. So 640x576 captured on your card equals 640 x 1.188 = 760.32 square pixels, provided you keep the number of lines the same.

so 640x576 at PAR 1.188 equals 760x576 square pixel. Which is what you use.
As I said, we do the same thing, but in a different order. :)

[midelic]

@Arachnotron
Sorry
It,s midnight here. I'm a litle tired.
I understood now ,you are right ,it's in fact the same thing.
Thanks.You were helpful.

[trevlac]

Originally posted by midelic
@trevlac
I coulnd't set 762/576 capture size regardless of huffyuv or Xvid.
In virtualvcr I received " Cannot Set Video Format E-Fail;80004005"


I think 80004005 is a generic microsoft access error. Regardless, the following things may not let you set custom frame sizes.

1) Application (virtualVCR does allow custom sizes)
2) Driver (BTwincap seems to allow most any even number)
3) Codec (Try a short uncompressed clip YUY2 to test #1 & #2) Xvid requires 16s (It's mpeg right?) and Huffy seems to require 4s)

Erratic has reported he can cap at 714 using PIC Mjpeg. I have not had a chance to test. #2 is most likely your problem.

I know of no real advantage to a custom capture if you are going to resize after capture anyway. Although, Arachnotron, in his testing is talking about interference patters produced by not caping the 'natural' size of a picture. I'm not sure about this. I'd have to read about harmonics. :)

[avih]

it was a pleasure reading this thread :)
it just reassures (not that it was really needed), that here's one of the best places in the world to discuss digital video matters :)

cheers ppl
avih

[cypher_soundz]

Hi,
going for a height of 576, 288, or 144 , gives me the joy of not deinterlacing, but i just wondered if some one could give me some detailed information on why? also i take it this is only for PAL source?
Regards
cyph

[trevlac]

Originally posted by cypher_soundz
going for a height of 576, 288, or 144 , gives me the joy of not deinterlacing, but i just wondered if some one could give me some detailed information on why? also i take it this is only for PAL source?


PAL source is a frame made of 2 interlaced fields that are about 702x288 big. These come to your TV 1 right after another and in effect are weaved together to give you a frame size of 702x576. If you card is set to capture only 1/2 the height (or less), it more than likely just ignores one of the fields. In effect what is capture is a single progressive frame 702x288 vs an interlaced frame made of 2 fields 702x288 with a slight time delay between them.

NTSC is the same, the numbers are about 711x480 and 711x240.

The 702 and 711 numbers are the horizontal TV size. DVD pads/crops this out to 720 or 704. For PC size, it is stretched/shrunk to 768 (PAL), 640(NTSC).

At least that's how I think it works ;)

PS: Most of the prior discussion was because most cards do not capture the full 702 or 711. They do some 'unknown' number, but you can test to know. :sly:

[cypher_soundz]

thanks for the insight, so would this be appled to a interlaced dvd? I have treid it and it works, is this the same method?
Regards
cyph

[trevlac]

Originally posted by cypher_soundz
so would this be appled to a interlaced dvd? I have treid it and it works, is this the same method?

I'm not sure what you mean. Please describe 'the method'. If you play a DVD into your capture card, the DVD player converts the signal into a PAL std. signal. Is this what you mean?

BTW: A VHS tape is like a DVD. It is not stored as the broadcast standard. It is converted to the standard by the player. TV analog inputs expect 'the Standard'.

At least this is how I understand it. :)