View Single Post
Old 7th April 2003, 20:54   #10  |  Link
^^-+I4004+-^^
Banned
 
^^-+I4004+-^^'s Avatar
 
Join Date: Aug 2002
Location: Croatia [local name:Hrvatska]
Posts: 551
ok,here we go,i have opened round 18 pages and
have them before me,but for a start i would
opt for a opinion where the capture
guide and post-process guide should be completely
separated;no mixing between these two....
(in any good capturing these two steps are
separated anyhow..all postprocessing should
be done afterwards...denoising especially (heh).....
so if the deinterlacing guide is already existant,
in my mind it should be tweaked a bit for the
analog purposes [noise is there,and that
makes deint. harder,should we denoise first with separated
fields,or deinterlace first....you know what i mean..hehe]

now,let's see;
[preface]
>The source will be a PAL system and you should end up with a DivX .avi file muxed with a cbr-mp3 audio, in your preferred filesize. For the more advanced users, who prefer vbr-mp3 or ogg-vorbis, I include a small excursion into high quality sound

i think many would argue on the benefits/disadvantages of vbr-mp3
instead of cbr,but that's the listeners choice after all,and i'm not
to much into that but let me just say that cbr at 192kbit sounds pretty fine to me.....(ie. cbr is high-quality too....)
but ok,it's a "small excursion"...hehe

> But if you want to play your videos on your standalone player, DivX will not help you, because the standalone cannot playback mpeg4 (DivX).

and this

>(A new generation of players is just emerging that play DivX.)


seems a bit contradictory ;i would prefer just the
last statement,with
an additional note that one should aim to make such divx files
that will look nice on both emerging divx players and PC's....
(ie. to aim for higher resolutions,makin it "16" compatible etc.)
although only very few people have these players now....
[this is not so important anyhow,divx players have miles to
go before they can stack up to PS versatility]

>384*288 (1/4 PAL) = Low Quality
+ filters generally not necessary

?
i would say that filters are MORE important on the
lores,than hi-res capture;16x16 error blocks are much easier to
spot on 384x288 then on 768x576......
(as 16x16 is relatively small for 768x576 and big for 384x288)
also;lores capture usually get smaller bitrate,and that
doesn't help either,so filtering is a must for lores...

>7xx*576 (Full PAL) = High Quality
Full PAL is actually at 768*576, but different capture cards will calculate the resolution in different ways, so that there will be different values. The chosen resolution is determined by your capture card. I am using an ATI Radeon and thus decided to use a resolution of 720*576.

here ,i think, it would be fine to state that 768x576 is a
preffered
resolution if you aim for mpeg4 codecs and the video
will be projected
to monitor or tv-out ( all monitors,and mine (heh) tv-out chip have
only square pixel output resolutons...768x576 etc. )...
and 720x576 will be best raw material to make dvd compliant
mpeg2 (ie. 720x576 has nonsqaure pixelAR)
if you have 720x576 source and you resize that to 640x480,you have
640x480 with unsquare pixel,and this shouldn't be so....(or?)
i like to keep it square pixelAR all the time,from capturing till encoding.....(you guessed it;i don't have dvd-player)
[your ati capturings on 720x576 don't fill teh complete screen,right?]
also perhaps it should be mentioned that vdsync 1411 includes
tweaked bt8x8 tweaker where you can set the pixelAR exactly correct
and according to ccir601,as bt cards are not quite standard compliant
on 720x576...(but ARE square pixel on 768x576)

[optimizing]
>1) A fast and large hard drive. Best would be 7200 rpm, with a large cache, and as many Gigs as possible.

it would be closer to the truth to say that any ata66 drive will
do (even huff at cca. 10MB/s is not problem for ata66 drive)
you're right...it can't be too big......
[i think it's important for users to know that paying
twice the money for 7200
or SCSI is not so wise if they can invest that extra
money in better
capturing device.....]
my 2MB cache,5400 ata133 drive working in ata66 mode (didn't applied
no w2k SP's) doesn't drop at all.....also "defrag." is a strange word in my dictionary....so you be the judge what's needed....

[preparing]
>Audio -> Compression -> in the dropdown box labeled 'name' you should choose CD-quality.

if one is capturing mono VHS,then this is not good choice;
mono VHS can't go above 16khz (not in it's wildest dreams)
so capping it at 44khz will only capture much more hiss....
i reccommend 32khz/16bit mono sound for mono VHS sources...
(or ; don't capture the hiss....mp3 doesn't like it either...)

>Video -> turn off Overlay and Preview using VFW drivers, with BT8x8 chips.

if you turn off both,how will you see the image?
preview should be on,and overlay not,as one cannot capture full-pal on VFW if overlay is on.....
if there are drops,THEN consider turning the preview off too...
(first step to troubleshoot framedrops)

>Set the framerate (PAL) to 25, set the buffers as shown in the screenshot below, and activate "Lock video stream to audio".

always capping without this ticked,and always fine
sync on VFW....more research is needed to see what it does
to VFW and what to WDM capturing....

>Capture -> Disk I/O
In this small window you can match VirtualDub to your computer's hard drive speed. I got tired of frequently switching these settings so I just leave the defaults.

don't think this is of importance;if the device drops frames the chances are this is not
the problem......(my Erazor continues to drop no matter the
buffering...as it's the driver issue....)
i think default is fine for majority.......

[384*288 (1/4 PAL) ]
>If it is possible to choose more than one Huffyuv codec, make sure you choose the one for the data format you just entered in the previous step (e.g., YUY2).

all huffyuv modes are lossless,so choose the one that allows you to go to highest
resolution with your CPU.....
(if "predict median(best)" works fine,then ok..if not,chose faster but
with less cempressability)

>For the PicVideo MJPEG codec, set the quality to 18 or 19, and under Advanced, set Luminance Quality to 2 and Chrominance Quality to 3.

picvideo will yield decent results from "17" to "19" (20 overkill and it seems to drop more at least here)
chroma subsampling can be 4:1:1 without loss in image quality (but reduces
bitrate even further)

>Noise reduction
The worse the source is the more disturbances you'll have in your capture. This is the so-called "Noise". VirtualDub lower the amount of noise, which is often also responsible for dropped frames. Unfortunately, this also softens the picture and needs some CPU power too.


NR shouldn't be used on-the-fly anyhow...(and + VDUb doesn't have
real good NR filter....and i have tried quite a few...)
also : from this sentence one could imagine that NR on
capturing might
decrease number of dropped frames,and this is not the case ;
a/d converting chipset is receiving the noisy signal and
converting it
.....denoise is done only AFTERWARDS,and WILL NOT help if the dropped
frames are caused by the noisy video....
(NR on-the-fly only blurs and loads the CPU...shouldn't be mentioned at all.......)
all post processing should be done afterwards....
(although someone will be ok with NR+deinterlace on the fly...i'm not..)

>Furthermore, I should probably mention that you should not touch the computer during the capture process!!!

this is ok,many people forget this and want to "do something while they capture"...ohh,come on......it's enough if it can do capturing alone...

[postprocessing the video]

i think folks should be encouraged to use avisynth right on this
spot ; from all that i see vdub's days as a filtering util
are numbered : avs is faster (works in YUY2),it has more powerfull
NR filters (lindsey dubb's filters have no vdub "cousins" , no vdub
NR that i saw can stack with them...)
sure,it's not user friendly,but hey,if you're capturing,you might as well go that mile extra....(or mile and a half..heh)
in my case,with simillar filtering,avs is almost twice as fast....
(and i have slow cpu,so....)
recently,.vcf files with cutting info can be converted to
.avs files and that means vdub is only used for editing and compressing ; all postprocessing and cutting is done inside the avs
script..(a dream cum drue.....)

[384*576 with vertical resize ("1/2 PAL") ]
>When capturing from analog sources, you often see a colored (green most of the time) line on the bottom of the picture. This is ugly to look at and can also lead to dropped frames. This problem can be solved by simply reducing the height of the captured video slightly. You can just deduct a few lines off the height, e.g., use 572 instead of 576.

never seen that green line myself,and also,this should only be encouraged if there are big problems with dropping;
this is messing the video in a bad way ,but was already discussed
(xesdeeni posed a nice explanation what happens)
use this trick only if you have no other place to go...
(this blurs image heavily)
i have a sample on http://i4004.bizhosting.com/
( 720x576 and 720x540...you'll see the difference only 16 lines are taken out but it's like 30% blurier )

>Setting up Vertical Reduction
Video -> Vertical Reduction -> 2:1 Linear (smoother picture but less CPU intensive) or 2:1 Cubic (sharper)

if cpu can't take it,you might as well capture at 384x576
and do vertical2:1 afterwards.....

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

ok,i guess that would be that........
[ and remember : processing separated , encourage avs use.....
capturing is one thing,and making decent encode of it quite
another.... ]

/ivo
ps.lol-is it detailed enough?
^^-+I4004+-^^ is offline