Capture Guide Suggestions

[^^-+I4004+-^^]

>Do you think it is a problem of the videocard? A while ago, when I still had a TNT2, I always had to capture at 704x576 and always saw ten lines of garbage at the bottom of the clip. Nowadays I'm using a Geforce 4, but I can't remember if it matters whether capping to 704x576 or 720x576. Using the latter resolution, I didn't have garbage.


probably some cards (ati? never saw it on bt or erazor)
think of this garbage on the bottom as a noise and if
there's a noise they "hide" it with solid green....

btvfw driver hides noise with solid blue,btwincap hides it with
solid green (that's how i connected these two...)
but bt NEVER hides only few lines on the bottom ; if it sees noise
it hides the complete screen when noise in image
(overall) exceedes some treshold....(vfw driver has lower treshold than
btwincap,ie. you'll see more noise there until driver shuts-off the image and converts the screen to solid green)

so i never saw this with bt8x8 (as it's not triggered by only
few lines of noise on bottom of the screen...it's drivers can only
blank (fill complete screen with blue or green) if there's too much of noise
all round the image)

VHS has distinctive "head switching" noise on the bottom
(looks like succesive lines are not aligned...some get sideways..aslo
seems like something's missing...and it is;
this is the moment when one head is turned off and other begins to
scan the tape...cannot be seamless....)
and tv transmission has none of this but usually some blank
black space on the bottom
(sometimes only 1,5 line,sometimes more...
you can exactly see that 1 field ends on half of the screen
if you load this to image viewer,and blow it a bit;there's one
completely blank line (black line) and one that ends on the half the screen...interesting...huh?)

if you capture VHS you MUST see that garbage on the bottom (or this
"green line" that hides it) otherwise you're not capturing complete
video image .....576-1,5 lines....most of time all are used
(that's why we love PAL,right?hehe)

vlad,throw this one in too...(hehe)

[BaronVlad]

Ok, much to read, much to do.

steVe said, that the hardware stuff should be mostly in the FAQ, that is exactly my opinion, a guide should first describe how to do something, for me it is very important to show everybody, how to do captures, not only the advanced users that know all these things already. So the guide should show hardware related thinks on the surface (where it is important for the setup, i.g. bt8*8 <-> philipps), detailed things should be in the FAQ. Somebody please look into the FAQ (there is a short sentence about hardware linking to Scuba) If that is not enough or if there is something that has to be added, please drop a few lines ready to be inserted into the FAQ and I will do it.

But I agree, we also have to give some ideas to the advanced users. So, here is my suggestion for the new structure:

The guide will be divided into 2 main parts.

PART ONE (Capturing):


1. Preface / Basics
optimizing your system / additional software needed

2. Preparing the capture
general settings
extra settings:
384*288 (1/4 PAL) or direct VCD at 352*288
384*576 with vertical resize ("1/2 PAL")
7xx*576 (Full PAL) or direct SVCD at 480*576

3. Capturing

This part is alreday online, some minor bugfixes can be done (green line with VHS only, NR not with Huffyuv, the lock video to audio stream thing, NTSC should be added (see above)

PART TWO (Postprocessing):

We should have different methods in it:

1. Using VDub (Important for noobs, remember: everybody should end up with a watchable movie in the end)
cutting out commercials
Using Filters (Explaining how to add filters with a sample as it is done in the German guide already, could be "only" translated and bugfixed, which filters should be added -> Deinterlacing, Resizing and the other stuff, for detailed information linked to discussions about different methods in the forum)
Audio and video compression
frameserving (for the one who wants to do this)

2. Using GKnot (Some words about the differences between DVD and avi encoding with GKnot and the a Link to doom9s guides)

3. Using Avisynth (best way for advanced users)
Wilberts part, explaination how scripts work, how to add the plugins, do filtering...
Short summarry of how to do the encoding with the following program (MPEG4 via VDub Mod can be linked to my part above, think the mpeg2 stuff can be linked to doom9s guides.

After that we can have some Addons when we want to, i.g.:

audio problems
"high quality sound" (vbr mp3/ogg)
improving playback quality
(more to come)

Appendix


These are my thoughts, please let me know what you think.

I need your help,

I would be glad if steVe could do the bugfixes and translate and modify the VDub part.

Wilbert already writes the Avisynth Guide, I would be very happy to be allowed to integrate this into our little guide.

ivo, it would be nice, if you could look into the hardware stuff (FAQ) and give me a suggestion.

Who wants to do the GKnot part ? Shouldnt be much, but I am sorry, I dont have so much time to do all this, cause university starts and I have to hurry up a bit with my "real life"



BTW: Little Update in the FAQ yesterday (thanks Mijo)

[killingspree]

Originally posted by BaronVlad

I would be glad if steVe could do the bugfixes and translate and modify the VDub part.

i sure can do this as long as their's no specific (expecially short) deadline. i'm going to be away large parts of the upcoming weeks and will not be able to do much more than answer a few PMs/mails and probably have a short look at the doom9 news.
still if you mail the bugfixes to me i'll try to incorporate everything as fast as i can.
@bvlad: i think the vdub part that was included in your analoque guide is already translated. correct me if i'm wrong. if there's some parts missing (which i don't hope as i actually tested all the links etc and compared the two folders) please tell me and i'll translate them with highest priority!
i think this is the part: http://www.doom9.org/capture/postprocessing.html

regarding all the changes i completely agree with BaronVlad

regards
steVe

[Wilbert]

These are my thoughts, please let me know what you think.

I agree!

Wilbert already writes the Avisynth Guide, I would be very happy to be allowed to integrate this into our little guide.

I will give you a first draft on Monday, and we can discuss it then.

Who wants to do the GKnot part ? Shouldnt be much, but I am sorry, I dont have so much time to do all this, cause university starts and I have to hurry up a bit with my "real life"

If no one else wants to do this, I can do it. But it will take much time. The main problem is that I don't have internet at home, so I have to ask other people for the GKnot software. And I have to practice a bit because I never used GKnot for this

[BaronVlad]

That sounds quite good, thank you very much for your help.

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

I will ask Karl, whether it is ok, if we translate his aspect ratio for dummies guide, as it is very important to understand all these things. Any volunteer to do the translation ?

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

As we have started an open discussion, I post my Bugfix thoughts here for steVe:

We leave the Preface as it is, changes to be made will take effect, when the rest is ready.

optimizing your system / additional software needed as it is

2. Preparing the capture
- Audio -> Compression. I got a mail with the hint to use the MS ADPCM at 44,1 KHz to reduce the audio size to 1/4 of before, maybe we could add this as a little hint (didnt check this out by now.
- "Video -> turn off Overlay and Preview" change to "Video -> turn off Overlay and activate Preview or maybe deactivate both to save CPU time"
- Capture -> Settings:
Add the NTSC Settings with Screenie (if possible):
~something like this: "Due to some minor bug in VDub, 29.97 FPS cannot be set
The capture will be at 29.971 FPS and AVI2SVCD will reject the file
The FPS *MUST* be set to 29.9697 FPS to work properly"
- "Lock video stream to audio stream" add: Do this only, if you capture with compatibility mode, no need to this in normal captures

extra settings:
- In all resolution regarding green line:
~Something like that (you are free to choose the find the right expression instead of my bad English): If you capture from a tape, you normally should see an ungly line at the bottom (i.g. green or pink) If you dont see this line you may not have the correct resolution (the whole picture). To avoid dropped frames you can try to crop some pixel at the bottom (i.g. 286 instead of 288 or something similiar)
- Huffyuv: Add the comment that we should start with "Predict median (best)" and that we can go beyond if we get problems.
- Noise reduction:
add the comment, that NR should only be used when capping MJPEG not when using Huffyuv because of loosing information.

This is the End of steVes part one.

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

Postprocessing using VDub:

Lets have a look into the translation of the German part. Should be ok (if you have the Deinterlacing and resizing stuff in it)

But we should add, that the "right" resolution is 768 * 576 (thats PAL, what should we do with NTSC ??? The same ? ) and you have to correct the resolution, if you capped with 720 or 704 * 576

After a Deinterlacing sample add a link to Lukes Guides (see Capture FAQ for details)
Also color correction should be added, if you dont want to go into details you can also find this in Lukes Guides.
After the resize options explained with a sample link into the following discussion:
http://forum.doom9.org/showthread.php?s=&threadid=42274 (more suggestions welcome)

Compression: Correct the calculation (100 instead of 1024 when using DivX). delete the Excel sheet thing and add a recommendation for GKnot

Thats all for steVe now, I think, and it is enough

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

@Wilbert: I am looking forward to see you Avisynth part

Regarding GKnot: That should be no big thing: to load more than one avi into GKnot (i.g. segmented capture as recommended always) you have to use a little avs with segmentedavisource. Remember that you have to delete the last little file when capturing huffyuv, no need to do this with mjpeg, dont ask me why.

When done, just load this avs with GKnot, do your settings -> doom9s guides.

I am happy to see such a great effort, starting to work with GKnot just for this little guide, thank you.

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

I am sure, I forgot something, please add.

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

We just have to wait for ivos suggestions, I think...


Thanks for your time

[Ookami]

IMO, the guide should not cover too much, because it will only drive the newbies away.

For instance someone who just wants to capture a few TV shows in the month and make LQ encodings, a discussion about the NTSC->PAL conversion problem is way over the head and interest.

I always though that you though the same way, Tim?

-Full PAL etc.

This was discussed more than once. As for the different full PAL res. of the various card (704x576 vs. 720x576 etc.) Karl has made some nice explanations about that one, you can ask Karl about it to do it for the guide.

-Resizing algos:

http://forum.doom9.org/showthread.ph...g&pagenumber=2

-Deinterlacing

IMO, you could just link to the FAQ and Manonos new doc (when it's out).


>Audio -> Compression. I got a mail with the hint to use the MS ADPCM at 44,1 KHz to reduce the audio size to 1/4 of before, maybe we could add this as a little hint (didnt check this out by now.

Great God! No! ADPCM is lossy! How about encoding to WMA or MP3 to have even less audio size? IMO, the audio is the least problem, especially if you capture with Huffyuv or Loco .

>If you capture from a tape, you normally should see an ungly line at the bottom (i.g. green or pink

Totally unecessary. It depends on with what you capture anyway. Not to mention that I've captured from live TV with headswitching noise because certain TV station even send *cough* SVHS material *cough* through the air...

>add the comment, that NR should only be used when capping MJPEG not when using Huffyuv because of loosing information.

? Now, that's really illogical, captain! NR is more efficient if you have MORE of the original information avalaible! So, this was the main reason why I always said that devices like the DC 10 etc. are in a minus when you want to postprocess your video with filters etc. NR depends on the taste of the user and the end format. If you encode to a crappy VCD then it's mostly overkill to do NR at all (want to blur your lo res picture even more?), but even this is debatable and depends on the observer.

More comments when I read more of this...

Cheers,

Mijo.

[Wilbert]

Just a few random comments:

But we should add, that the "right" resolution is 768 * 576 (thats PAL, what should we do with NTSC ??? The same ?) and you have to correct the resolution, if you capped with 720 or 704 * 576

The right resolutions are (corrected for the ITU bla bla standard) given in (1) and (2):

1) hx576 with h=720*59/54 = 786.7 (PAL), which implies that capping at 768x576 still needs correcting. The problem is of course that you can't capture at 786.7x576
2) hx480 with h=720*10/11 = 654.5 (NTSC), which implies that capping at 640x480 still needs correcting.
3) capturing at 704x576 (AR =1.3354) => resize to 4x3. Note 704*59/54/576=1.3354.
4) capturing at 720x480 (AR =1.3657) => resize to "not exactly 4x3".
5) NTSC similar comments, regarding (3) and (4).

Also color correction should be added, if you dont want to go into details you can also find this in Lukes Guides.

Maybe someone knows this. Luke use the Histogram in Virtualdub to correct the brightness and contrast. If I check histograms in one of the tabs, nothing happens ?

When done, just load this avs with GKnot, do your settings -> doom9s guides.

Yes, it's not much work.

-Deinterlacing
IMO, you could just link to the FAQ and Manonos new doc (when it's out).

Personally I wouldn't do just linking. You will scare all newbies away. Don't get me wrong, these guides are very good. But if you are new to all of this stuff, I think that the way Luke explained it in his guide is far more comprehensible. Besides these docs (FAQ and Manonos new doc) consider only AviSynth deinterlacing.

[BaronVlad]

Hmmpf...

steVe, please be sure to think about Mijos statement above.

If you like, then add something with the greeeeeeeen line, otherwise just delete the sentence and let them all run into this trap

@Mijo: I also think that the guide shouldnt cover to much for the newbies, cause of that we have the simple VDub way and will not change so much (only some bugfixes) to be sure, that EVERYBODY is able to make (good) captures with this guide, i sent Karl a PM regarding the translation and will look into it / ask him for this NTSC stuff.

Think it is time to think of something else than capturing now, my brain is empty as you see above.

EDIT: seems that Wilbert an me started writing the same time, but he was faster. It is better to have a clear describtion in the guide, but for these things we need somebody to write this, that is alot of work and if we have an own part, we should integrate it as "optional" to keep the guide clean and short and not to scare the noobs, cause not everybody does it all the time.

I am sure, steVe does his job very well, including the resolution thing in some words that evrybody is able to understand

I am not able to get one word into my head anymore.

[killingspree]

hi
of course i'm going to regard it... i think we might mention the green lines somewhere in brackets (you might see a few ... if you do you can crop them away...)

unfortunately i still have not recieved the updated guide from doom9 although i've droped him a PM this morning. so as long as i do not have this new guide, editing doesn't make any since IMHO

still some very good thoughts in the above posts (:

regards
steVe

edit: damn must we always be posting at the same time (: well i'll see what i can do... i think we should get it very well structured. so that the newbies just have to follow the destinct line through the guide and the advanced user have to loop trough a few links to get the detailed information etc. but in order to do the structuring i'll first need a full list of contents... best would be in cronological order... perhaps i'll do a post tomorrow listing the current content and will add the necessary things as they come along in this thread! what do you think about that?

[BaronVlad]

Originally posted by killingspree
what do you think about that?

Great,

I am away a bit to clean up my room now...

[killingspree]

just wanted to say that i got the guide from doom9... the editing can begin (:

steVe

[killingspree]

ok well, as promised i'll have the table of contents here so we can sort out how we are going to part the guide etc... i'll also indicate here what changes have been done already: the guide i'm handling now is the exact same version as published online

1. Preface / Basics

translated Dr. karl's link (:
optimizing your system / additional software needed
[i] we'll leave those "as is" as baronvlad said above

2. Preparing the capture
audio: bvlad said i should change it, ookami said i shouldn't because it is lossy (MS ADPCM at 44,1 KHz)
video: changed the overlay & preview off to just overlay off
i also added all to other stuff bvlad wrote in his thread above. a zip file with the pages that have been changed is attached to the end of the post!

general settings
extra settings:
384*288 (1/4 PAL) or direct VCD at 352*288
384*576 with vertical resize ("1/2 PAL")
7xx*576 (Full PAL) or direct SVCD at 480*576

about the green line. i somehow don't know what i should write now?? i chose the "you might see" version: [update:]i now used the 'version' wilbert used below with a little add on from myself, as the formulation sounds way superior (:

Capturing from VHS tape you will ALWAYS see few lines on the bottom that a) look weird (looks like they don't belong there) and have some noise... or
b) have same color ( green or pink) in a case when capture driver tries to hide this "headswitching noise" so you don't see it.
If you don't see anything of this from VHS source,better check your input resolution,as you MUST see these if you're capturing complete signal (480 lines for NTSC and 576 for PAL),funny,but something is wrong if you DON'T see these lines from VHS. The lines (or greens field) will be treated in the Post-Processing section of this guide. If your computer drops frames during capture you can also try to cut these few lines off when capturing.

changed HuffYUV and NR as advised above. still again i'm not sure if this is what you guys want. (especially regarding Ookamis post) i've added that NR should only be used before capturing if using MJPEG codec, otherwise one can also do this afterwards!

3. Capturing

4. Postprocessing the video
cutting out commercials

5. Audio and video compression
ok, i think i've corrected the 1000/1024 'error' when calculating the bitrate, see quote below. somebody please check this! oh and one more thing: when calculating the audio bitrate you still calculate with 1024 don't you?

Therefore take 636 MB x 1000 gives Kilobyte x 8 gives Kilobit. That is the space
available on your CD. (636 x 1000 x 8 = 5210112 Kilobit). Now calculate kilobit
per second (5210112 / 90min. / 60sec. = 964).

frameserving

6. Add-ons
audio problems
high quality sound (vbr mp3/ogg)
improving playback quality

Appendix


ok... sorry i know this message is incomplete, but i don't have enough time to correct the other things atm. i'll probably do it tonight!
one more problem (question): where should i put the resolution thingy? rather on each page (full, 1/2 and 1/4 PAL) or somewhere further up in the beginning?

steVe
PS: i'll attach the files later on... (:

[BaronVlad]

Hi steVe,

glad to see editing is on the run.

Regarding audio, please believe Mijo, cause

BTW: I got a mail with the hint, that the Link to "Frameserving" at the startpage doesnt work, this is true, could you check what is going on there ?

Thanks.

[^^-+I4004+-^^]

after a day and a half off (really gettin too saturated),and now writing from notepad (power-cut
seems likely...lol! wilbert doesn't have web at home,i
won't have electricity at all (soon)...what are we doing? hehe...anyhow),so excuse any mistakes and formatting issues (i've resized notepad window to
resemble the size of space for posts on forum...let's see if it works...hm..works better with "wordwrap" off..now i copy-paste)

uhhh as i see it's gonna be quite a job,let's see....
you asked about FAQ;
i think that in answer to "3.) Which TV Capture cards are commonly used? "
you linked two misleading documents;
they both point that the ultimate and cheap solution for home capturing are combo-boards , but i disagree :
i have seen the images coming from asus,ati,matrox and
simple bt8x8 card beats all of these....
and bt8x8 cards are even cheaper.....and if in addition bt8x8 card with huffyuv and hires looks better than advc100,need i say more ? ( even though my
hdd is "RIP"(not "rip",but RestsInPeace),i will probably get the samples again and
publish that on my web....after that,you might as well remove these 2 links that states that combo boards
are better than the rest.....and link that web of mine...hehe )

also;i think the start of "21.) What can I do against dropframes? " is a bit off too ;
dropped frames ARE a disease that NEEDS to be cured
(it's good that you linked the cure too (vdsync) )
also
"If you have so many dropped frames that you will notice them (the video "stutters") "

EVERY dropped frame is visible; (see how much drops
can you tolerate if you capture sports...i should say not too many...),so this sentence is too mild ne
should aim for 0 dropped frames from the beginning...
ie. if the dropped frame (because of a/v sync...these ones are rare,truth) occurs on some fast scene,it's not satisfactory to know why did it happen...(when you miss the piece of video )
so :dropped frames are a disease that needs to be cured,and as we know the cure,why should we settle for
less than "0 dropped frames" across complete capture...?
this disease is caused by hardware/drivers out of
specs,but it's a disease anyway....

i don't see other mistakes (although these 2 are not drastic mistakes,but simply my experience on devices
is different (i'll try to provide screenshots as soon as possible hmm..and if possible) and dropped frames
should be avoided :stating that "few dropped frames
doesn't make a difference and they are not a disease that needs to be cured" doesn't help much : just encourage users to be with progs that resample sound
or live with those drops..(i go for first solution...)

now few things form this thread;

on adpcm compression during capture: no,i don't see the need for this....audio bitrate is not the problem anyhow........but if one really needs to go that far to save some small amounts of space,you can mention it....(i doubt there's a need for this )

on "Due to some minor bug in VDub, 29.97 FPS cannot be set The capture will be at 29.971 FPS ", as i said..i
believe avery lee knows EXACTLY what's the framerate of NTSC,and seems like avi2svcd author doesn't
( 29.9697 ? this precision (on vertical deflection) is impossible to achieve
in analog video signal! so NTSC is 29,97 for all that i'm concerned......)
if this is true ALL vdub ntsc capturing that was done with veedub has wrong framerate : i doubt this is the
truth....i see that tmpgenc sees files captured by vdub as "29,97" and accepts them (even though i produced this file on pal input and had dropped quite a few frames)
if no one from usa can confirm this,i say let's just drop it......

>>If you capture from a tape, you normally should see an ungly line at the bottom (i.g. green or pink
>Totally unecessary.

so it's not necessary for people to know why the noise
(and subsequent green line in some cases) appears on
the bottom of the screen ALWAYS when they capture VHS
and sometimes from live-tv?hmmm
regarding the english for this perhaps;

"Capturing from VHS tape you will ALWAYS see few lines on the bottom that a) look weird (looks like they don't belong there) and have some noise...
or
b) have same color ( green or pink) in a case when capture driver tries to hide this "headswitching noise" so you don't see it.
If you don't see anything of this from VHS source,better check your input resolution,as you MUST see these if you're capturing complete signal (480 lines for NTSC and 576 for PAL),funny,but something is wrong if you DON'T see these lines from VHS "
and "see further notes on post-process guides to get rid of it"....etc.

that should make them sleep easier (hehe)

NR issue is occurring again: bb has said that NR will
do good for MJPEG,but it's not so easy : it will also
introduce SOME ghosting (this looks like evaporating of moving objects ) more you NR the more you see of ghosting :and then MJPEG doesn't like this pixelization and you're right where you started from
(or?)....i think NR on this early stage will only cause problems;it'll blur,it'll ghost probably will
result in poorer end result (ie.unsharper image)
and MJPEG will still have "ringing" on sharp edges (like subtitles etc.)
NR will introduce ghosting for huffyuv too...(it's just like introducing NR filter afterwards...only you cannot tweak it to suit image noise best,as you're denoising while capturing ie. you cannot tweak it after you started to capture......)
i say leave it ,but only as a hint... say that it will introduce some blurring too.........
(if everyone would use it,then we will have much more
blurred video....bare in mind that resizers blur too,and that there'll be another NR in post process probably too.....as this on-line NR can't remove all the noise...)
in other words;
NR in VDUB is not that good
NR on-the-fly is not good either....
blurring the image while capturing is wrong....
(it'll be too blurry afterwards because of resizing/codec anyhow...no need to do it deliberately)

>1) hx576 with h=720*59/54 = 786.7 (PAL), which implies that capping at 768x576 still needs correcting

768x576 cannot be corrected for ITU standard,as it doesn't have much to do with it......
720*mpeg2 PAR(59/54) is pretty funny calculus if you ask me..that way you didn't got anything that is related
to square pixel (1:1) of 768x576.......but: 576x1.333(4:3AR)
=768 and the pixels are square so it's good....
it's 768x576 and it's not ccir601 compliant as ccir601
requires non-square pixels....we PC people don't have use for non-square pixels.....we use them only if we aim for DVD compliant mpeg2/mpeg1 video...
(ie. you used 720 as a reference,but it's not a reference for video on PC,but reference for video
on DVD....)
and if you capped with 704 or 720 and aim for perfect
square pixel then you need to do some elaborate resizing to get it prefectly right (this is explained
in derkarl's guide to some extent....a reason more why we should see it in english too...also i regard my simple method as more precise and better and has no
AR error at all...i have mentioned it above)
alternatively ,you can just watch 704x576 with player set to 4:3 and it's good.........(player will compensate)

>If I check histograms in one of the tabs, nothing happens ?

i think it only works for lo-res....in hires video image
overrruns this tab so it's not visible (my explanation anyway...)
complete histogram thing is not defined well enough:
what's an "image with same amounts of black and white"?
rather calibrate your monitor and use your eyes.....
small error can be tweaked with "tweak" of avs anyhow...vdub has filter for adjusting this too
(no,not "levels"..levels is undefined too(and funny for user)...there's a
plugin)
i would skip this issue.......

and a bit about GKnot; i have never used it (and probably never will...don't see real use for it for
.avi....probably because i know my codecs pretty well by now),but i know a story something like this;
"i want everything automated,so i let GK to do all
decisions for me;it does resolution,it does bitrate..i mean if GK says it's good,i say ok....."
after this i saw some 512x384 divx that looked pretty
bad.....(source was 720x576).......
so,if GK will always do such thing,then does he/she need it at all?
i think decision on resolution should be based on different merits;for example,if we know that target for mentioned case was 50min on 700MB,we know (or i know) that you can pack more resolution to cca. 1800
kbit/s (or at least i'm doing it all the time) than mere 512x384........this compressability test is all
wrong if you ask me.....with it you rely on machine
deciding for you;and for noise in analog capture how will it do it?it's always different noise,source etc.
50min on 512x384?ohh,come on....i'm using mpeg4 because it's better than mpeg2,better than SVCD...720x576->512x384 is sh*t most of the time....and worse than SVCD for sure...
(just one example how rookie can be tricked into
making lousy PC video...)

respect

/ivo

[Jukke]

Hi,
Just a quick note on using GKnot on captured material. I use a pretty straight forward procedure on this subject. Capture in 720x576 (PAL) with I-frames only (for cutting purposes) as mpeg2. Cut out unwanted parts if needed with suitable tool, then straight to GKnot and go by the Doom9-guides with the following exceptions:
* Just after the DVD2AVI-project is made, convert the mpa-audio to mp3 cbr 128 with BeSweet and add this to the GKnot-project
* Always set the input as 4:3 PAL (as I live in a PAL-country)

If you use GKnot0.28, let GKnot mux the audio with VDubMod. If you use GKnot0.27 or older, mux the audio separately with VDubMod.

This procedure works like a champ with my AIW Radeon 9000 with its Philips-tuner and captured via MMC8.1

Just my two cents...

[Wilbert]

768x576 cannot be corrected for ITU standard,as it doesn't have much to do with it...... 720*mpeg2 PAR(59/54) is pretty funny calculus if you ask me..that way you didn't got anything that is related to square pixel (1:1) of 768x576.......but: 576x1.333(4:3AR)=768 and the pixels are square so it's good....

Of course if you capture with Huffyuv the pixels are always square, not matter what resolution you capture at. The problem is that your image itself is squeezed.

it's 768x576 and it's not ccir601 compliant as ccir601 requires non-square pixels....we PC people don't have use for non-square pixels.....we use them only if we aim for DVD compliant mpeg2/mpeg1 video... (ie. you used 720 as a reference,but it's not a reference for video on PC,but reference for video on DVD....)

I don't agree with your here. The problem is that if you capture at 768x576 your clip will be squeezed a little bit, and you have to correct for it. But apperently you don't agree with that, and you call the calculations which show that "funny".

A side note. I think it's good not to talk about this ITU stuff, in the vdub newbie section.

[BaronVlad]

hi again,

@Jukke:

Sorry, we are discussing about avi captures (Huffyuv, mjpeg) here, no need to do DVD2AVI...

@all:

I got a mail from Mijo, my thoughts after reading this is:

Let us wait a bit, until Wilbert has a beta version of his Avisynth guide and steVe has a beta of the new guide. Then we discuss about all this again. It is important that we have one version to discuss about, not only a theory

The FAQ will stay the same until we are ready with this guide, Scubas ideas about the hardware are a bit old but good, think we can live with this point.

BTW: I got also a Mail from Karl (Thanks): It is ok to translate the capture aspect ratio thing (there wont be a describtion for NTSC as Karl has no time for this). As the home of this document was videoxone all the time, ich will ask tED66 where to put the translated document . We now need a volunteer to do the translation, he should know all these standards and stuff very good to make sure, that the translation is of the same quality, the original is. (bb, Mijo ? )

[killingspree]

Originally posted by BaronVlad


BTW: I got a mail with the hint, that the Link to "Frameserving" at the startpage doesnt work, this is true, could you check what is going on there ?

checked that... the link is working in the version i have on my computer but doesn't work on doom9. somehow i think the page got lost during upload. got to talk about this to doom9 as soon as possible. also there seem to be a problem when using the next button from the 'audio and video compression site'. it directs you right to the appendix. frameserving is completely left out this way ?!? strange as it is not a pure linking error, because i wrote 'appendix' next to the next link (:

anyway, i did some more changes today... look in my post above for details! also i quoted some changes above. please somebody read through them quickly and check for eventual spelling mistakes or errors! thanks

Lets have a look into the translation of the German part. Should be ok (if you have the Deinterlacing and resizing stuff in it)

But we should add, that the "right" resolution is 768 * 576 (thats PAL, what should we do with NTSC ??? The same ? ) and you have to correct the resolution, if you capped with 720 or 704 * 576

Originally posted by BaronVlad

After a Deinterlacing sample add a link to Lukes Guides (see Capture FAQ for details)
Also color correction should be added, if you dont want to go into details you can also find this in Lukes Guides.
After the resize options explained with a sample link into the following discussion:
http://forum.doom9.org/showthread.php?s=&threadid=42274

ok got a few 'problems' here.
a) i've been looking for the deinterlacing part now for quite some time but haven't found it. not in the english guide neither in the german counterpart. of course i could add something like this, but if there was something i could just copy and paste it would be much more convenient!
b) should i do these color correction thingies too? i mean i've followed luke's guide some time ago when doing my first captures, but it was a while ago and i didn't capture very much lately thus i'd have to read /practice a bit before writing the section (time issue)
c) resizing: again... should i do this? I can but it will take some time...

oh and about the 'true resolution' of PAL/NTSC: you got me there to (:
steVe

[Wilbert]

@BaronVlad,
What format do you want the guide? html?

But we should add, that the "right" resolution is 768 * 576 (thats PAL, what should we do with NTSC ??? The same ? ) and you have to correct the resolution, if you capped with 720 or 704 * 576

I think it is 640x480 for NTSC.

a) i've been looking for the deinterlacing part now for quite some time but haven't found it.

General talk:
http://www.lukesvideo.com/interlacing.html
http://www.lukesvideo.com/telecining.html

How to deinterlace with vdub filters:
http://www.lukesvideo.com/highresprocess.html

b) should i do these color correction thingies too?

That would be very nice. If that histogram stuff doesn't work, you can download a histogram filter from Donald Graft (http://shelob.mordor.net/dgraft/histogram.html). I guess it works in the same way.

c) resizing: again... should i do this? I can but it will take some time...

Yes, that's not so much work. For the vdub newby guide I suggest not to talk about ITU compliance.

[^^-+I4004+-^^]

Originally posted by Wilbert
Of course if you capture with Huffyuv the pixels are always square, not matter what resolution you capture at. The problem is that your image itself is squeezed.


I don't agree with your here. The problem is that if you capture at 768x576 your clip will be squeezed a little bit, and you have to correct for it. But apperently you don't agree with that, and you call the calculations which show that "funny".

A side note. I think it's good not to talk about this ITU stuff, in the vdub newbie section.

pixel AR is not conditioned by the compressor (huff or
mjpeg) but with the sampling frequency of card/driver...

768x576 looks same as tv image and is not squeezed
(at least not on my tv-out which is square pixel too
it has 768x576,800x600,640x480,so it's square pixel all the way)

why are you correcting the square pixel resolution with the
standard for unsquare mpeg2 pixel?
square pixel doesn't need no correction;576*1,3333=768....
here's a good read for you:it explains how come 720x576 (and 720x480)
fills the complete screen on dvd video (note that PAL is 59/54 and NTSC is 10/11 for mpeg2 raster....)
include that PC always have square pixel on monitor (my tv-out has it too,how bout yours?) and you'll understand why you can't do
720x59/54 to give you anything....
http://www.mir.com/DMG/aspect.html
also,see this page
http://free-st.hinet.hr/ikostic3/video_/video.htm
this is what happens when i changed pixelAR DURING the capture...
note that image on monitor stays within same dimensions,but underlying
image is changing AR...try it on tv-out too....when the image was
stretched (horizontally) the most,it got nearest to the tv image
(you have this image on tv via the astra satellite if you have access
so you can compare tv-out and live tv)
(or elaborate why have you used such calculus?)

also i have already stated tthat ntsc is 640x480 for sqaure pixel
and 720x480 for unsqaure mpeg2 pixel
use 640x480 for PC mpeg4 video,and 720x480 for dvd compliantt video