Capture Guide Suggestions

[Wilbert]

but had no probs with loading in GKnot and getting a preview

Weird, can you try the following huffyuv (three frames):

http://www.geocities.com/wilbertdijkhof/huffyuv4.avi


You are somehow right, Wilbert, but there may be some people that are not able to write an Avisynth script on their own, and those can use GKnot for this.
As you notice, that works great for dvd's. But not for captures. I will see what I can do.

[BaronVlad]

:eek: 3 frames = 850 KB...:eek:

Wow, that is really what we call lossless compression. :)

I had no problem with GKnot, I could load the clip and got a preview, my script:

avisource("c:\huffyuv4.avi")

Which versions of programs and codec did you install ?

IMO the GKnot part should be a simple way how to do first steps with Avisynth, you can keep this part very short and link to doom9`s DVD Guides and your Avisynth part to reduce redundant words.

Thanks for your help again ;)

[^^-+I4004+-^^]

i agree completely with wilbert on GK part (we tend to agree
more and more lately...heh)...not real use for it on .avi's,but i agree with wilbert too (isn't that nice too..heeh) as if it can be sorted out to work for layman then it should be easier for him...right?GK should make for few steps less then we guys normally do...correct?
(ie. if it'll make people more aware of avs...as i said...)

for a man that likes to learn more ; VDub,Ndub,avisynth should make him bussy for a while...

another one for wilbert;
i belive you didn't included crop.addborders trick
(i believe i didn't saw it in,there's stuff on removing junk on top and bottom,and indeed letterbox is good enough for that,but it can be junk on the sides too.......i will apologize if i made you remove this part if it was present before...as it happens i believe it would be best to leave "letterbox" for top/bottom,and make an addition "Removing garbage from the sides (left/right) of the clip")?

i have used it yesterday with decent results;
[code]
#removes the junk,adds black borders,centers the image.....
#addblackborders for 16 compatibility[some nasty results on 572x416 #divx]
#for processing in yuy2 left and right must be even
#syntax:AddBorders(clip, int left, int top, int right, int bottom)
Crop(16,0,556,420).AddBorders(10,6,10,6)
#above is good for 7xx x 576->576x432 poor VHS as am using now for #TLN1..

( as junk on the sides is eating bitrate too...non 16 solid colors are not liked by the mpeg codecs,but i think they like junk on that borders even less!hehe )

wilbert,glad to see you had time to test that all 7xx resolutions have same amount of image inside....as i did here
http://i4004.0catch.com/704_720_768%20line.htm
(if someone missed it..heh)

/ivo

[killingspree]

Originally posted by Wilbert

Tomorrow, I will put up a new version including Steve's changes.


please make sure you really use the latest version of the guide... i am doing some changes atm and will upload it a bit later half an hour or so...

i will of course post here as soon as the new version is 'online'

steVe

[killingspree]

ok version 1.5 is up... (:

link: http://members.tripod.de/stefanstrobl/download.htm
changelog only: http://members.tripod.de/stefanstrobl/changelog.txt

please somebody read through the added deinterlacing and resizing part in the vdub post processing page. thanks

@Wilbert:
a) would you mind if i cropped / resized you avisynth screenshots a bit to improve loading times?
b)please check the changelog... i've added something to your part (of course only because Bvlad told me to :D)

steVe

[kempodragon]

I found a workaround for getting a preview of a Huffyuv file. Make a simple avs file using the AviSource () command and open the avs file in Gknot. Worked perfectly.

Whoops!! Someone already beat me to it. Shows what happens when you work third and are just getting up. :)

[Ookami]

A few suggestions:

- explaining overscan etc. ("Why do I see the mike on the PC monitor and not on the TV?" and "Help! I see not only headswitching, but even garbage on ________ !" :D ), maybe add it to the headswitching part
- (VD postprocessing) adding a link that explains the differences of the various res. filters (for those who want to read into it)
- on the additional NR filters add a bit more or at least a link to neuron2 site (as that's advanced stuff anyhow)
- add a few more reference links in the Appendix

Er, had more ideas... Sigh, getting old.

Nice work, y'all!

[Wilbert]

3 frames = 850 KB...

Wow, that is really what we call lossless compression.

:)

I had no problem with GKnot, I could load the clip and got a preview, my script:

avisource("c:\huffyuv4.avi")

Which versions of programs and codec did you install ?

Btw, you loaded the avi directly (without a script). Weird.

Installed programs/codecs:
- RipPack 0.28 beta6
- GKnot 0.28 beta5
- not the codec pack
- huffyuv v2.1.1 (http://math.berkeley.edu/~benrg/huffyuv.html, down atm)
- Windows 2000 SP2

Could you sent me the following file: avifil32.dll (w.j.dijkhof@tue.nl). Len0x said that this file is responsible for loading the huffyuv.


another one for wilbert;
i belive you didn't included crop.addborders trick
(i believe i didn't saw it in,there's stuff on removing junk on top and bottom,and indeed letterbox is good enough for that,but it can be junk on the sides too.......i will apologize if i made you remove this part if it was present before...as it happens i believe it would be best to leave "letterbox" for top/bottom,and make an addition "Removing garbage from the sides (left/right) of the clip")?
I removed the crop.addborders, and replaced it by letterbox. Btw, letterbox can also be applied to the left/right side of the clip. Will make a remark about it ...


please somebody read through the added deinterlacing and resizing part in the vdub post processing page. thanks

@Wilbert:
a) would you mind if i cropped / resized you avisynth screenshots a bit to improve loading times?
b)please check the changelog... i've added something to your part (of course only because Bvlad told me to )
Sure, no problem. I will look at the changelog (and download 1.5).


I found a workaround for getting a preview of a Huffyuv file. Make a simple avs file using the AviSource() command and open the avs file in Gknot. Worked perfectly.
So, you also couldn't load it directly? I will try this.

[BaronVlad]

I didnt load the avi directly, I used a script to load it, but in the script there is only "avisource()", the rest like cropping, resize... should be done with GKnot, can you show us your script ?

Mail is sent.:)

[Wilbert]

the rest like cropping, resize... should be done with GKnot, can you show us your script ?
I will post the script on friday. Btw, letterboxing (cropping is not necessaary) can't be done in GKnot. Resizing analog caps of 720x576 is also not possible, because it is always resized to 640x464 (and it has to be 640x480). That's what I meant with GKnot is not suited for this job :) Since I'm away tomorrow, I will post a new version on friday.

[TheWEF]

i did not read all of this long thread.
but i read PAR 54/59 and 11/10 in a number of posts and just want to mention (once more...) that these numbers are not correct.

PAL PAR is 128/117
NTSC PAR is 72/79

check out A Quick Guide to Digital Video Resolution and Aspect Ratio Conversions (http://www.uwasa.fi/~f76998/video/conversion/) and
this thread (http://forum.doom9.org/showthread.php?s=&threadid=42708).
btw.: you find all the correct PARs for commonly used capture resolutions if you press "select" in gknots PAR group box in the resolution tab.

this is just a hint. i'm tired of discussing this and i will not in this thread.

wef.

[Wilbert]

i did not read all of this long thread. but i read PAR 54/59 and 11/10 in a number of posts and just want to mention (once more...) that these numbers are not correct.

PAL PAR is 128/117
NTSC PAR is 72/79
I'm aware of this.


btw.: you find all the correct PARs for commonly used capture resolutions if you press "select" in gknots PAR group box in the resolution tab.
I do have a question about this though. Recently Ivo thaught me that 720x576 needs to be resized to 640x480 (and not 640x464), note we are talking about analog capturing (no dv or dvd). Can I select that in GKnot somewhere?

this is just a hint. i'm tired of discussing this and i will not in this thread.
Someone else?

[Wilbert]

I put up a new version.

- images240403.zip: only new pictures (of GKnot) [Steve, can you include those in your images v1.5 zipfile]
- htmlfiles240403.zip

changelog:

1.6 changes by Wilbert (24/04)
- changed processing_avisynth.html
- switched sections 4.2 and 4.3
- added links to AviSynth filters
- added 4.2.1: Processing interlaced video
- added 4.2.2: Using multiple captures to reduce noise
- changed the trimming in AviSynth part. Easiest is to do it with the script editor, therefor only links to vcf2avs
- added processing_gkont.html
- added gknot1.jpg-gknot7.jpg
- changed compression.html (switched audio and video)

I hope you like the GKnot part, of course other suggestions are welcome. If you want to use GKnot differently for this, please add a detailed proposal for this.

I didn't have the energy to read the rest. I suggest that we use the weekend to decide what needs to be added/changed/improved.

links:
http://www.geocities.com/wilbertdijkhof/htmlfiles240403.zip
http://www.geocities.com/wilbertdijkhof/images240403.zip

[TheWEF]

Originally posted by Wilbert
Recently Ivo thaught me that 720x576 needs to be resized to 640x480 (and not 640x464), note we are talking about analog capturing (no dv or dvd).

don't trust him! ;)
analog or digital - there is no difference.
just use gknot:

input res: 720*576
input par: select 128/117 (720*576)
H-Moldul: 1
horizontal res: 640
-> vertical res: 468 - that would be exact, but as you know, the codecs don't like that, so...

H-Moldul: 16
horizontal res: 640
-> vertical res: 464

you could also crop 8 pixels off each side to get real 4/3:

704*576 -> 640*480

wef.

[Wilbert]

don't trust him!
analog or digital - there is no difference.
just use gknot:
First, I know how to do the calculations, like you showed. Second there must be a difference between analog and digital. Ivo showed me (and of course I checked that), that capping at 768x576, 720x576 and 704x576 results in the same image. It is not the case that 704x576 is a cropped version of 720x576, but it is a scaled version. This implies that both must be resized to the same 4:3 resolution (640x480).

The pics (provided by Ivo) are given here:

wilbert,glad to see you had time to test that all 7xx resolutions have same amount of image inside....as i did here http://i4004.0catch.com/704_720_768%20line.htm
(if someone missed it..heh)
But of course, you can also check it yourself.

[killingspree]

Originally posted by Wilbert
I put up a new version.

- images240403.zip: only new pictures (of GKnot) [Steve, can you include those in your images v1.5 zipfile]


will do that right away...

steVe

[TheWEF]

Originally posted by Wilbert
This implies that both must be resized to the same 4:3 resolution (640x480).

or 640x464 or something else...
this just implies that obviously you have to find out the correct capture resolution first, everything else is guessing.

wef.

[^^-+I4004+-^^]

>Recently Ivo thaught me that 720x576 needs to be resized to 640x480 (and not 640x464),

now,i never said explicitly what input res. to resize to what output resolution,i have only showed you all horizontal sizes have complete image (ie. capture cards are not doing any cropping)
but ,hell,wilbert,you said it my friend,and you're right and it makes sense!!
indeed,7xx x 576 (xx being 04,20,68) NEEDS to be resized to 640x480 to have perfect AR!
i'm suggesting 768 as preffered only because it has more data,more quality than less resolutions!
704,720 or 768 resized to 640x480,you should end up with EXACTLY the same image (AR wise)....curently i don't have time to do that test,but i will (or if wilbert has more time....i have to capture "all the presidents man" in few moments....)

one should not forget one truth too;pixels on monitor are square(for 4:3 resolutions),so no need to take unsqaure pixels in account and resize as such they will be watched on devices that support unsqaure pixels!
(as 640x464 is step in that direction;not real need for such resizing!)

another reason why i don't like GK?
it first crops and then resizes (to have some spped up in processing)
i forst resize,then crop (to have perfect AR!)
GK will typically make some roundings (to "16") and i don't like it!this makes some AR offset,so i FIRST resize to 4:3 resolution,and then crop...in fact i never crop in that tsense...i add borders to keep mpeg codec happy...(as i have tried all sorts of things...funny resolutions....believe me,codec doen't like "2" or "4" resolutions...especially in horizontal way!)

but yet another thought;how do standalones(divx players) "see" PAR of divx->if they do same as PC (always square) there are no worries even in long term usage!

cheers
/ivo

ps. and again,wilbert thanks for support..........
and
ps2.@wef_sorry for misunderstanding on PAR's(in gk forum)

[TheWEF]

Originally posted by ^^-+I4004+-^^
ps2.@wef_sorry for misunderstanding on PAR's(in gk forum)

that's ok, but anyway...

Originally posted by ^^-+I4004+-^^
indeed,7xx x 576 (xx being 04,20,68) NEEDS to be resized to 640x480 to have perfect AR! [B]

Originally posted by ^^-+I4004+-^^
[B]so no need to take unsqaure pixels in account and resize as such they will be watched on devices that support unsqaure pixels!
(as 640x464 is step in that direction;not real need for such resizing!)

...what you are saying is still not true.
but i can't explain it any better than in the sticky in the gknot forum, or the perfect explanations in all the links i provided.

wef.

[TheWEF]

Originally posted by Wilbert
This implies that both must be resized to the same 4:3 resolution (640x480).

check out this:
http://www.dynalink.com.au/files/pdfs/bt878_specs_sheet.pdf

these capture devices can do internal cropping, resizing, scaling,...
so it's impossible to say what is correct without knowing how the drivers and capture software are programming and using the chips internal functions.

i guess you have to contact haupauge to really find out. or capture movies with round objects (balls) in it...


wef.

[^^-+I4004+-^^]

>...what you are saying is still not true.

no?really?
take a look here;
http://i4004.0catch.com/
[link is on the bottom of the page,couldn't enter this link directly it seems to big for this crappy reply window]
or,copy paste this to adress bar of browser...
"http://i4004.0catch.com/resizing%20the%207xx%20and%20pixel's%20appearance.htm"

(with this one,my talk of PAR is over,as i already said and (on this link)proved everything......non-believers,do your own tests....)

i reccomend you especially the slides
"http://i4004.0catch.com/alan_j_pakula_640x480[from%20768x576].jpg"
and
"http://i4004.0catch.com/alan_j_pakula_source768x576.jpg"

and i'm challenging you;if you see any AR change with those two samples,then i'm the one that's stupid all this time!
you'll have tot do better than just pointing us to GK sticky with numbers only:why should i use 640x464 for video that's to be played on 4:3 monitor,tv-out and i truely believe divx hardware players only play in square pixel mode(hm,is there PAR data in videoinfoheader of .avi file at all? i didn't saw it.....but i know mpeg2 has it!)

>but i can't explain it any better than in the sticky in the gknot forum, or the perfect explanations in all the links i provided

for all that i care,your sticky only has numbers and less explanations on why and how?(for example,you need to make that differentiation dvd player display/monitor display...you need to say that very clearly! or did you? anyhow,reading that sticky told me nothing on why 720x576 needs to be unsquare to fill the screen and how does it do it,and how come ntsc has 720 pixels too...because of this i made few sketches how do ntsc and pal mpeg2 pixels look on dvd-player->tv )

if i resized 7xx x 576 to 640x464 i would get AR offset->my tv-out is pure 4:3 square pixel (800x600 or 768x576)!
i have pointed you to 768x576 and 640x480 so you see there's no AR change between those two (and the 640x480 end image is the same for all 4 input resolutions...wondered why?)
bare in mind that 768x576 is prefectly square PAR for all our considerations!

you said
>i did not read all of this long thread.
but i read PAR 54/59 and 11/10

but no one here said that ntsc is "11/10"!luckily for ntsc people,derkarl only messed up the PAL PAR numbers in his lil documents!

and a final note;(this is just a repetition);your program is twistng the AR because you crop first and resize afterwards(that "16" compatible thing is making this offset.... i presume the calculus for this scaling and including the preservation of AR is correct(needed for 7xx x 576->640 x xxx resizing),but "16" is still a problem)

i'm not saying it's a big offset (as it probably isn't),but if you resized first,you wouldn't be having any of it!
yeap it would be a tad slower processing,but....at least i know i'm watching at perfect AR every time on my capturings....
every dvd-rip made with GK has a slight AR offset if GK is cropping first!(and it is!)

this was discused before here,and i wasn't the only one to notice this habit of cropping first (in my view wrong practice!)
http://forum.doom9.org/showthread.php?s=&threadid=46286
(the funny thing is that i was stating all this stuff on PAR there (as i am now!) too but i didn't know about PC producing ONLY square pixels,so i was unsure and erased some bits....but the part on resizing first as explained by me and justinus is very accurate...


i presume you don't have capture card,so you couldn't do such tests.....

ok,folks i'm off and won't come again to this thread;if you need any help with it,contact me via PM,as i won't go into all this thing again--> as it happens i have explained it at least 3 times by now,so you'll have to excuse me.....

gretins

/ivo

PS. no hard feelings,but now you do need a good explanation why should one use 640x464 instead of 640x480 on 4:3 display...

[TheWEF]

well, i should have known better. hopeless case. i'm gone... :)

[BaronVlad]

Originally posted by TheWEF
well, i should have known better. hopeless case. i'm gone... :)

:D Thanks WEF for coming here, I have to admit that I am very confused about this PAR..., if should have a look at your recommendations and talk with Karl about all this...:confused:

@Wilbert: Thanks for the GKnot part. One question: Dont you see a possibility to use GKnot for cropping..., you can change some things in the script afterwards, if you like, but replacing the need to write the Avisynth script on your own, that was my intention, you can choose the source resolution as theWEF said above. Problem is cutting the commercials, as I suggested here: http://forum.doom9.org/showthread.php?s=&threadid=51832

Hm..maybe you will find a way to make postprocessing more easy :)

But you made one big mistake in your parts, Avisynth as well as GKnot:

The author of these parts is not me, you did this great work, so you should put your name instead of mine there. :D

[Wilbert]

@TheWEF

well, i should have known better. hopeless case. i'm gone...
Before you go, I've two questions:

1) Do you think that it depends on the capture device whether 704x576 is a scaled or a croppped version of 720x576? All the links seem to assume that it is a cropped version, or am I misreading it?

2) Relating to the previous page. Suppose you capture at 768x576 (full pal resolution). Must this be resized to 640x480?

@BaronVlad,

@Wilbert: Thanks for the GKnot part. One question: Dont you see a possibility to use GKnot for cropping..., you can change some things in the script afterwards, if you like, but replacing the need to write the Avisynth script on your own, that was my intention, you can choose the source resolution as theWEF said above. Problem is cutting the commercials, as I suggested here: http://forum.doom9.org/showthread.php?s=&threadid=51832.
I know that's what you want, but I don't see any possibility to do that. Cutting commercials is not the only problem. Other problems are letterboxing (not possible), deinterlacing (especially pal), smoothing (the available smooth options are in general too soft), color correction (not possible). I just don't see how to do that in GKnot.

I will put up a new version this afternoon... I also want to see agreement on this par stuff :)

[TheWEF]

Originally posted by Wilbert
1) Do you think that it depends on the capture device whether 704x576 is a scaled or a croppped version of 720x576? All the links seem to assume that it is a cropped version, or am I misreading it?

at least in ivos case he seems to have gotten various scaled versions of the same frame.
this could be different with other hard or software, i don't know. without special testing it's impossible to tell what's the correct capture resolution (and the correct par). to find out if the captured frames are clipped or not i suggest this: connect your standalone dvd player to your capture card, capture and rip the dvd, compare frames...

here is my guess:
720x576 probably is the correct capture res for PAL (dvd frame is not clipped) and the par for resizing is 128/117. (-> 640x464)

if you find that the dvd frame is clipped, then it's probably pretty hard to tell whether the correct capture res is 704x576, par 128/117 (-> 640x480) or 768x576, par 768/767 (-> 640x480) and what you choose doesn't matter too much.

wef.

[Ookami]

Take a look at the last part of Karl's Capture Karten und aspect-ratio fuer Dummies ;-) (Arbeitsweise der Capture-Chips).

[BaronVlad]

@Mijo: Wer ? Ich oder WEF oder alle ?

:confused: :)

[Wilbert]

Yesterday I read the guide more carefully, and the answer is already given in there:

preface.html:

"704*576 with a PAR of 59/54 and 1 (max. 2) pixel overscan (black borders)
720*576 with a PAR of 59/54 and approx. 18 pixel overscan
720*576 without overscan -> not concurring with the ITU standards -> using a generic PAR (48/45)
768*576 with a PAR of 1/1 without overscan"

and also:

"With a BT 8x8 Chipset (common TV Capture Card) try 768 or 704 * 576 because of the (often) wrong scaling by the cards when 720 is used.
With Philips (mostly Asus/NVidia) try 704 (old drivers) or 720 (newer versions), as these cards have no scaler the resolution should be always right.
With ATI try 720 or 704. If you use 720 as I do, be sure to stick to the right PAR when resizing. Here it is the "generic PAR" of 45/48.
If you use a DV Codec, please remember that capturing with that one is limited to 720 anyway."

which implies the following:

768x576, 704x576 or 720x576 (without overscan) --> resize to 4:3
720x576 (with 16-18 pixels overscan) --> crop overscan --> resize to 4:3

I updated the guide. I added the NTSC counterpart:

"704*480 with a PAR of 10/11 and 1 (max. 2) pixel overscan (black borders)
720*480 with a PAR of 10/11 and approx. 18 pixel overscan
720*480 without overscan -> not concurring with the ITU standards -> using a generic PAR (8/9)
640*480 with a PAR of 1/1 without overscan"

I also updated processing.html (see changelog) and processing_avisynth.html. I think my part is finished, at least I don't know what else to change or add ...

http://www.geocities.com/wilbertdijkhof/htmlfiles280403.zip

[Der Karl]

Hi Wilbert,

sorry for my bad russian ;)

>which implies the following:
>768x576, 704x576 or 720x576 (without overscan) --> resize to 4:3
>720x576 (with 16-18 pixels overscan) --> crop overscan --> resize to 4:3

Right!

>I updated the guide. I added the NTSC counterpart:
>"704*480 with a PAR of 10/11 and 1 (max. 2) pixel overscan (black borders)
>720*480 with a PAR of 10/11 and approx. 18 pixel overscan
>720*480 without overscan -> not concurring with the ITU standards -> using a generic PAR (8/9)
>640*480 with a PAR of 1/1 without overscan"

Completely false!

NTSC uses a completely different timing _and_ scaling.
There are 486 scanlines with an "active part" of 52.66666µs/line.

German:

Das kann man nicht vergleichen! NTSC ist komplett anders. Die 13.5 MHz Samplingfrequenz lt. ITU
sind ein Kompromiß zwischen PAL/SECAM und NTSC.

Wie Wef schon schrieb: Hier http://www.uwasa.fi/~f76998/video/conversion/
ist alles sehr gut zusammengefasst.

Gruß Karl

[BaronVlad]

Wow,

Hi Karl, welcome to this forum ! :)

Thanks for your input, I will send you a PM, think it is more easy for both of us to write our suggestions in German words :scared:

[Der Karl]

@Baron Vlad

>This user's mailbox is currently full, and cannot be sent any messages until it is cleaned out.

Gruß Karl

[BaronVlad]

Grrr...

Yes I know ! I deleted some messages, should work now :(

Thanks Karl:)

[Ookami]

Hello Karl... Nice to "see" you here. Danke fuer Deine Muehe!

>Registered: Oct 2001

? :)

Too tired to write anything useful so I'll just check my mail and go to bed.

Good night,

Mijo.

[BaronVlad]

Hi,

sorry for this short post.

Tomorrow I will have a look into the guide (btw: where is steVe ?)

@Karl: thanks for the PM, I will also try to get this into my little brain tomorrow...

I have to leave now since my sweetheart was born exactly 27 years ago :)

[Wilbert]

>I updated the guide. I added the NTSC counterpart:
>"704*480 with a PAR of 10/11 and 1 (max. 2) pixel overscan (black borders)
>720*480 with a PAR of 10/11 and approx. 18 pixel overscan
>720*480 without overscan -> not concurring with the ITU standards -> using a generic PAR (8/9)
>640*480 with a PAR of 1/1 without overscan"

Completely false!

NTSC uses a completely different timing _and_ scaling.
There are 486 scanlines with an "active part" of 52.66666µs/line.
Thanks for the correction! Would the following be true (situations that can occur):

1) capping at 704x480 (7 pixels are cropped of horizontally, and 6 vertically) => crop/add black borders to obtain 711x486 => resize to 640x480.

I guess you could also crop to two pixels 702x480 and resize directly to 640x480.

2a) capping at 720x480 (9 pixels are added horizontally, and 6 cropped vertically) => crop/add black borders to obtain 711x480 => resize to 640x480.

2b) capping at 720x480 (upscaled to 720 horizontally, and 6 cropped vertically) => resize to 711x480 => crop/add black borders to obtain 720x480 => resize to 640x480 [of course, you could do this in two steps].

3a) capping at 640x480 (8 pixels are cropped of horizontally, and 6 vertically) => ok.

3b) capping at 640x480 (downscaled to 640 horizontally, and 6 pixels cropped vertically) => resize to 648x480 => add pixels 648x486 => resize to 640x480 (this can also be done in two steps)

I guess, in practice you can't see whether situation 3a or 3b is occuring (assuming that they can occur both)? In situation 1, most pixels are cropped. So, I guess best is to capture at 720x480 ?

I have to think about this more ...

[killingspree]

Originally posted by BaronVlad

Tomorrow I will have a look into the guide (btw: where is steVe ?)


right here...
just didn't have anything usefull to say... this AR discussion is a little over my head actually... (:
in addition i got quite a lot of work to do for the final written exam (Matura - oder Abi wie ihr sagt :-P) i got next week. Math is just killing me atm... i'm spending most of the time to get at least some into my head.

did i miss anything? if yes pls drop me a PM/email!

steVe

edit: like my new avatar? :D

[Wilbert]

did i miss anything?
No, except that the "NTSC par" stuff must be added correctly. I also noted there's nothing about NTSC deinterlacing. Perhaps you or BaronVlad can add this. All info can be found in Lukes guides IIRC.

Btw, I will ask Len0x to add telecide()/separatefields(). This should be enough to do the deinterlacing part in GKnot itself. (I also figured out, how to do the pal-resizing in GKnot.)

[killingspree]

Originally posted by Wilbert
No, except that the "NTSC par" stuff must be added correctly. I also noted there's nothing about NTSC deinterlacing. Perhaps you or BaronVlad can add this. All info can be found in Lukes guides IIRC.


sorry... i won't have time to do any serious work in the next week or so... afterwards i can again devote more time to doom9 and the guide!
still if you send me an email with some smaller changes to do i can add them.

cheers
steVe

[BaronVlad]

Hi steVe, nice avatar...

You should not do anything until your "abitur" is done !

But do we have a complete latest version of the guide ready ?

I somehow dont know exactly, is it steves site and the update of Wilbert (page 6 of this thread?)

Thanks.

EDIT: I got Wilberts part from page 7...:)

[killingspree]

Originally posted by BaronVlad
Hi steVe, nice avatar...

But do we have a complete latest version of the guide ready ?

I somehow dont know exactly, is it steves site and the update of Wilbert (page 6 of this thread?)


i've downloaded but still not looked at wilberts changes... but i'm quickly going to upload the new htmlfiles.zip to my page... only takes a minute anyway!
still wilberts link is the latest version. at least i haven't done and do not know about any further changes. wilbert?

steVe

edit: uploaded and ready for download!
@Wilbert: somehow it seems that something is changing some image pathes in a few html files (postprocessing and compression) while you are working on the guide. it has happened the second time now that the images/ path before the actualy jpg was gone. this time a hight and width = 40 has also been added to some paths. i don't have any explanation for this but could you just check if you find anything that is causing this? have fixed the image paths in the uploaded file!

[Wilbert]

still wilberts link is the latest version. at least i haven't done and do not know about any further changes. wilbert?
Yes, that is the latest version.

it has happened the second time now that the images/ path before the actualy jpg was gone.
That was my mistake, sorry. Won't happen again. (The problem was that I changed those two html pages on this pc, without unzipping the images.)

[BaronVlad]

Nice,

so let me summarize:

- I want to thank Karl for his PM -> PAL PAR will be in the guide as it is now.

- NTSC ? I dont know anything about NTSC, so I hope that Wilberts thoughts are correct now, anybody please confirm this ?! Otherwise we should cut this. (Page 7 of this thread) For this reason somebody instead of me should write the resize / Deinterlace stuff for NTSC also, otherwise it will be as it is now -> no NTSC Deinterlacing specifications directly in the guide, it is not that important I think, cause we linked to some threads.

- GKnot part: Do you want to change anything, Wilbert ? You said something about resize... ? If not we are almost ready with it, but one little point: In your picture one (A) you should choose "Bitrate = 128" in your sample, not your wav File to calculate the right bitrate. Also "C" in this picture: You can also choose MB via Dropdown and number of CDs...

- Is it ok for Len0x to add telecide()/separatefields()? If this is ready I think we can go online with the new version (including some minor changes in the Appendix..), close this thread and when it is online start a new one including todo list and newbie questions / problems.

Todo, as Mijo said: Connection of capture cards and (quality) problems with this

Your suggestions please
:)

[Wilbert]

NTSC ? I dont know anything about NTSC, so I hope that Wilberts thoughts are correct now, anybody please confirm this ?!
We will work this out with Karl, don't worry. Give me two days to think about it and to write it down properly.


For this reason somebody instead of me should write the resize / Deinterlace stuff for NTSC also
I can't do everything :) But once we know the ntsc stuff above, I can add a ntsc resize (sub)section.


In your picture one (A) you should choose "Bitrate = 128" in your sample, not your wav File to calculate the right bitrate. Also "C" in this picture: You can also choose MB via Dropdown and number of CDs...
I will correct this, thanks.


GKnot part: Do you want to change anything, Wilbert ? You said something about resize... ?
No, not in this version. If Len0x adds telecide()/separatefields() (I didn't ask yet), we can deinterlace with the GKnot options. Resizing is also possible, directly in GKnot. We can always change the GKnot section in a next update, but not know. The only problem is that I still can't see the clip when loading a huffyuv (directly or via a script) :)

[alky]

didnt read whole thread... but i am missing a delogo filter in the guide... i use this:
http://shelob.mordor.net/dgraft/delogo/delogo.html

[killingspree]

Originally posted by alky
didnt read whole thread... but i am missing a delogo filter in the guide... i use this:
http://shelob.mordor.net/dgraft/delogo/delogo.html

thank you... it has been pointed out to us already... it is part of our to do list (: nobody is using it atm though so we have are still looking for somebody to write this part (wouldn't be much but still...) *hinthint* :D

steVe

[Wilbert]

I have thought about it (NTSC resizing) more closely:

From the reference of Karl:
"525/59.94 systems have a line length of 63+5/9 (63.555...) µs, of which 52+2/3 (52.666...) µs is the "active" part that contains actual image information.
(The rest is reserved for horizontal blanking.)
52+2/3 µs × 13.5 MHz = 711 samples (pixels) per scanline.
In the vertical direction, there are 484 whole scanlines and 2 half lines. As above, all of them get digitized and half lines will be treated as if their missing other half belonged to the active picture, giving a total of 486 scanlines.
Thus, the active image area is 711×486 pixels. This is the actual area that forms the 4:3 (or anamorphic 16:9) frame."

Bottom line is that there are 486 scanlines. When capping 6 of them are cropped to obtain 480 scanlines. The following situations can occur when capping at: 640x480, 720x480 or 704x480:

1) capping at 704x480 (7 pixels are cropped of horizontally, and 6 vertically):
crop two pixels to obtain 702x480, and resize to 640x480. [PAR 72/79]

You can also resize directly (thus without cropping) to 640x480, making a small AR-error. (But people do this with PAL: 704x576-->640x480 too.)

2a) capping at 720x480 (9 pixels are added horizontally, and 6 cropped vertically):
crop/add black borders to obtain 711x486, and resize to 640x480. [PAR 72/79]

remark: in practice croppings/adds must be even.

2b) capping at 720x480 (upscaled to 720 horizontally, and 6 cropped vertically):
add black borders to obtain 720x486, and resize to 640x480. [generic PAR 9/10]

3a) capping at 640x480 (8 pixels are cropped of horizontally, and 6 vertically):
no need to crop or resize. [PAR 1/1]

3b) capping at 640x480 (downscaled to 640 horizontally, and 6 pixels cropped vertically):
add black borders to obtain 720x486, and resize to 640x480. [generic PAR 81/80]

Question 1) Does situation 3b happen in practice?

Question 2) If the answer to Q1 is affirmative, I guess the best is to advice people not to capture at 640x480. Since it is a bit hard to see whether situation 3a or 3b is occuring.

Question 3) Opinions? Is the above true? Karl, what do you think about it?

edit: there was a typo in 3b: PAR has to be 81/80 instead of 80/81.

[alky]

Originally posted by killingspree
thank you... it has been pointed out to us already... it is part of our to do list (: nobody is using it atm though so we have are still looking for somebody to write this part (wouldn't be much but still...) *hinthint* :D

steVe

hmm kay could write some about that...

but problem is i do not know a filter with "really good" results, delogo is a start, x-logo is better... but the perfect delogo filter would need some kind of motion detection to "move" picture information over the empty space a removed logo leaves.

anyone experienced enough in coding and video stuff ? :P

[Der Karl]

@Wilbert

It seems o.K. for me.
But: I dont have any experience in NTSC-capturing, so it ist only theory for me.
I am also not able to answer your questions - sorry!

Gruß Karl

[BaronVlad]

OK, as nobody is against Wilberts NTSC thoughts and it seems to be ok for Karl, we should put this into the guide (1-3, including Wilberts thoughts of hard decision...) thanks Wilbert.

steVe: Could you please merge this ? Then I will look into it, make some minor changes ("Helping hands" in the preface and appendix) and we can go online. As I said above, this thread will be closed and we start a new one,

including new "to do list" (logo, Connection of capture cards and (quality) problems with this, filters by Len0x)

Thank you all for your work in this guide :)

EDIT:

@Wilbert: Just saw your post: http://forum.doom9.org/showthread.php?s=&threadid=52550

Any reaction ? Something to confirm your thoughts ?

[Wilbert]

OK, as nobody is against Wilberts NTSC thoughts and it seems to be ok for Karl, we should put this into the guide (1-3, including Wilberts thoughts of hard decision...) thanks Wilbert.
Could you also update processing.html (the resize part). I will change processing_avisynth.html according to this.


@Wilbert: Just saw your post: http://forum.doom9.org/showthread.php?s=&threadid=52550. Any reaction ? Something to confirm your thoughts ?
I hope that jggimi sents something. Besides that, I didn't have any reaction so far. We will see ...