Tutorial to convert camcorder movie using avisynth and virtualdubmod

[David caid]

Hello,

Here is a tutorial to save movie shot with a camcorder into a Xvid format using avisynth and Virtualdubmod 1.5.10.

If you are an expert, then you won't learn anything, so I suppose this is for nOObs only. The other point of this tutorial is to make things clear in my head.
--------
So,
From the hardware part :
I have a Sony DCR-HC14 (I think it is almost equivalent to the TRV19 in the USA).
I have a amazing IBM 46 GB UDMA33 5400 RPM harddisk. If you make a rough calculation, a DV movie is around
1 GB/5minutes=200GB/min=3.3MB/s << 33 MB/S (UDMA33).

Copy the movie onto the harddisk
--------------------------------
I just plug my camcorder using the firewire cable (that was not in when I bought my camcorder, :angry:).
Then using microsoft movie maker (version 1.1.2427.1), I select file/reccord and start reccording my movie onto the harddisk (highest quality).
It creates a RAW avi file (type2 : video+sound) (around 1 GB per 5 minutes). Up to now, the maximum file size I have is less than 2 GB and I've never lost any images.

Convert your M$ DV movie into a canopus DV movie.
--------------------------------------------------
That's what struggle me for a while. I was able to copy and read DV movie using movie maker and mplayer, but there was no codecs installed, but they were some directshow codecs (it is may be not the right terms). So virtualdubmod or avisynth were not working as they require video for windows codecs (VFW).
So I did install the canopus codecs to use avisynth. I chose canopus codecs because of the sticky thread regarding codec comaparison (http://forum.doom9.org/showthread.php?s=&threadid=33526) and you can find the link for the canopus codecs (http://forum.doom9.org/showthread.php?s=&threadid=33519).
In my case I had to change my files from the M$ DV format into the canopus DV format, so I use the canopus DV converter (http://forum.doom9.org/showthread.php?s=&threadid=33526). It is only changing the FourCC code. But you can also use the Xvid FourCC changer (in the Koepi binaries).

After that you have a file that can be use by avisynth (as you installed also the codecs).

avisynth script
---------------
Here is a simple script, it should be optimized depending of the shooting situation.
Please search in other posts for better video processing script
I added some comment into it

# AVisynth script
# PLUGINS
LoadPlugin("C:\PROGRA~1\Xvid\GORDIA~1\AviSynthPlugins\decomb.dll")
LoadPlugin("C:\PROGRA~1\Xvid\GORDIA~1\AviSynthPlugins\FluxSmooth.dll")
# SOURCE
film=AviSource("E:\Film\Camcorder\movie.AVI")
# Color sampling - because of the canopus bug
film=film.FixBrokenChromaUpsampling()
# if you want to keep only from seconds number 10 to 12 and 16 to 18 - I'm doing PAL reccording
A=film.trim(250,300)
B=film.trim(400,450)
# Z is always the final movie you want to encode, so that you don't have to change the real encoding part.
Z = A+B
# Some crop (based on the aspect ratio thread
Z=Z.crop(8,0,704,576)
# because cheap camcorder are interlaced ;-(
Z=Z.FieldDeinterlace(blend=false)
# a soft noise remover
Z=Z.Temporalsoften(2,3,3,mode=2,scenechange=6)
Z=Z.mergechroma(Z.blur(1.3))
Z=Z.FluxSmooth(5,7)
# standard resize
Z=Z.Bicubicresize(640,480) #307200 pixels
return Z
# end of avisynth script


Audio ebcoding
--------------
I use virtualdubmod to extract the PCM audio from the DV type 2.
Then I encode the wav file into ogg using besweet software.

Xvid encoding
-------------
I will not write down all the procedure how to use virtualdub, if you manage to get to this point, you probably know how to encode.
the version use is the 1.5.10.1, as soon as the 1.6 of virtualdubmod will be out, you might be able to skip the canopus codecs installation as the 1.6 version of virtualdub is able to handle DV movie (but is not able to make .ogm file)
For my encoding, I always prefer the quality to the encoding speed (2 pass, motion search precision set to ultra-high. I also put only 1 hour of movie onto a 700 MB CD, so I can encode with a bitrate of 1600 kb/s, so assumign a 128 kb/s for the ogg audio, I can encode my video with a bitrate of 1400 kb/s

Here you are, you have a perfect Xvid+ogg file.

Based on the comment of bb
If you want to read the file on some standalone DVD player, you need to encode the audio into MP3 and use the .avi container

Enjoy,
David

[bb]

Hi David,

thank you very much for submitting your guide. I like the free software only approach. Although I have not yet tested it line by line, I'd like to add a few comments:

- DV uses a bandwidth of about 3.6 MB/s, so you should be prepared to consume a little more space than you calculated (3.3 MB/s).

- You should clearly state that the result of the procedure is an OGM file, which cannot be played on standalones. An alternative is to encode the audio to MP3 using Lame or BeSweet, then mux to AVI using VirtualDubMod. This way you'd be compatible with standalones.

- There are many alternatives regarding the deinterlacing and denoising filters.

- Trimming can be done in Windows Movie Maker, too; you should export to DV again before encoding to XviD through the AviSynth script.

bb

[WorBry]

Great tutorial. My only comment would be, do you really need to apply that much denoising and smoothing for what should be a pretty clean DV source?

I, like you, am capturing from a Sony DV camcorder (in my case a DCR-PC115E). I'm using Ulead VideoStudio 8 for both capture (Type II DV)and editing right now, mostly for its video overlay capability; as I understand, the capture software itself doesnt directly affect the quality of the captured DV file. I've tried a few DV codecs (although not Canopus) and have settled on the Sony DV Software Codec, largely because it appears eliminate the "color bleed" I was observing with other decompressors, and to which single CCD camcorders are prone. The only downside is that the Sony codec tends to produce a slight haziness, which, seems to be due to a luma shift when the codec upsamples from YUV to RGB24. However, this is quite correctable. So after considerable experimentation I've settled on a fairly simple AVS script that I now use for all conversions to other formats (DivX, XviD, VP6 and Nero Digital - including their new AVC codec).

avisource("E:\test file.avi")
ConvertToYUY2(interlaced=true)
ColorYUV(off_y=,gain_y=)
KernelDeint(order=0,sharp=true)or TDeint(order=0)
LanczosResize(720,528)
Undot()or RemoveGrain(mode=2)

I dont do any cropping - just resize to the equivalent square-pixel resolution (ITU standard)

The ColorYUV filter is used to correct the "Sony luma shift" effect I mentioned. I prefer to do this manually by adjusting the offset and gain values. The method is detailed in the capture guide on this forum (see Processing the Video with AVISynth). Or you can set as ColorYUV(levels="TV->PC") but, in my experience, this really slows down the encoding rate.

The use of Undot or RemoveGrain to reduce the grain ("mosquito noise")is really just a matter of personal preference. I dont find the need to apply any heavy-duty smoothers or denoisers, at least for DV captures, provided you're shooting under good lighting conditions.

Cheers

[David caid]

Originally posted by bb
Hi David,

thank you very much for submitting your guide.
I learned quite a lot with Doom9 forum, so it is normal also to contribute.


I like the free software only approach.

There is still the windows movie maker equivalent to find.


- DV uses a bandwidth of about 3.6 MB/s, so you should be prepared to consume a little more space than you calculated (3.3 MB/s).

As I said, it is just a rough calculation, because I often see some people claiming you need a 7200 RPM HD or a S-ATA harddisk. My point is just to show that even with a 4 year-old HD, the DV bandwith is 8 to 10 times smaller. even if your HD would deacrese the max speed to half, you still have margin. So losses of images during DV capture is not due to hardware.


- You should clearly state that the result of the procedure is an OGM file, which cannot be played on standalones. An alternative is to encode the audio to MP3 using Lame or BeSweet, then mux to AVI using VirtualDubMod. This way you'd be compatible with standalones.

Good point.



- There are many alternatives regarding the deinterlacing and denoising filters.

I wrote that it "is a simple script, it should be optimized depending of the shooting situation."
But you're right, I should have clearly state this. I'll edit my post.


- Trimming can be done in Windows Movie Maker, too; you should export to DV again before encoding to XviD through the AviSynth script.

As you mention, I only looked to the GPL software solution.
So What I usualy do is capture all DV movie on my harddisk. Then I play with my avisynth script. It also allow me to make several version of my movie (if I want to distribute it to my friend or my familly) or if you want to make some test, you just have the same RAW data and make several .avs file and enqueue it in VirtualDubMod.
For example, you can imagine doing soething like
A=film.trim(250,300) # scene 1
B=film.trim(300,375) # scene 2
C=film.trim(375,500) # scene 3
# change the order, #3-#1-#2
Z = C+A+B
if then you prefer another order, you do not touch the RAW data, just modify your avisynth script, I think it is safer not to modify the DV film.

Thanks for your positive comment

David

[David caid]

Originally posted by WorBry
Great tutorial. My only comment would be, do you really need to apply that much denoising and smoothing for what should be a pretty clean DV source?

My avisynth script is surely not the best one regarding the denoising and smoothing.
I was so happy to make my avisynth+virtualdubMod solution work that I didn't change my avisnth script.


as I understand, the capture software itself doesnt directly affect the quality of the captured DV file.

Exactly, the capture is just a streaming process, but windows is adding a FourCC code in the AVI file. So it determines which codecs will be used to read it.
The codecs is then use during the reading part to encode it into Xvid (or other codecs). It is here where you need the best codecs (for you :D ).


ConvertToYUY2(interlaced=true)
ColorYUV(off_y=,gain_y=)
KernelDeint(order=0,sharp=true)or TDeint(order=0)

I don't know those filter, I will have a look to them. I'll read the capture guide.


I dont do any cropping - just resize to the equivalent square-pixel
resolution (ITU standard)

I found a green colomn on my DV shoot (probably because I was doing a travelling in front a window with sun outside), so I needed this crop. Then will doing the resizing I keep the good ratio (based on the Aspect ratio thread).

Thanks for your avisynth script, I'll give a try to compare.

David

[WorBry]

Hi David,

Just a note about the script filters. I'm only converting to YUY2 because the Sony Codec up-samples to RGB24 and the stream needs to be in a YUV format a) so that I can correct the "luma shift" effect and b) because Undot doesnt work with RGB. However, RemoveGrain does, as do both the deinterlacers I use - KernelDeint and TDeint - both of which give excellent results. TDeint sharpens by default. For both it is important to set the order=0 as DV is bottom field first. Cant remember now why I decided not to use FieldDeinterlace. I still have the test samples, which on revisiting look pretty good. One thing I do recall that it has a chroma-deinterlace parameter which helped to reduce the "color bleed" that I was getting with my default DV compressor at the time (Adaptec DVSoft - yuk). However, the Sony Codec eliminated the need for that. Never used the Canopus codec myself. The codec comparison "sticky" at the head of this DV Forum seems to suggest that it suffers from the same sort of luminance shifts as the Sony Codec with RGB. Main Concept's codec avoids these problems, but is a bit too grainy for my personal liking...and also is not free. The FFDShow DV codec is also a pretty good freeware option. You have to enable the libavcodec in the decoder config settings for DV (dvsd).

Edit: Just tried the FixBrokenChromaUpsampling filter in place of ColorYUV in my script to see if it fixes the Sony "luminance shift" .....but it doesnt, so it is obviously not the same phenomenon.

P.S. David, you really need to upgrade your pc - it must be taking you light years to do this stuff? Been there myself and have the mental s...s...scars to prove it.

[David caid]

Hello Worby,

Thanks for the explanation regarding your script.
This week end, I'll have a look to your deinterlacers (I also want to try something like that
SeparateFields()
SelectEvery(2,1)

then, I will look to denoiser.
By the way, I was looking to the guide you refer, is that in the DV forum ? or in Doom9's forums :confused:

Regarding the different codecs, I have chosen canopus because it is working in the YUV2 colourspace, may be I could give a try with Sony.


Originally posted by WorBry

Edit: Just tried the FixBrokenChromaUpsampling filter in place of ColorYUV in my script to see if it fixes the Sony "luminance shift" .....but it doesnt, so it is obviously not the same phenomenon.

I thought the FixBrokenChromaUpsampling was also fixing the luminance shift.


P.S. David, you really need to upgrade your pc - it must be taking you light years to do this stuff? Been there myself and have the mental s...s...scars to prove it. [/B]
Well, I'm very proud of my machine, in fact. for 2 reasons :
-First this is with this machine that I started encoding using FlaskMpeg and divX3.0
-Second, I'm :angry: with people/ads... telling me I have to buy the latest HD special video or that they encodes with the amazing 120 fps (I've seen that more often than you think). they read there file at the same speed as me : 25 fps (for PAL users) :D I'll modify my signature.
But indeed you're right, when I'm making tests, It takes ages (A 1 minute movie is encoded in 5 to 10 minutes :rolleyes: )
Queueing RuLeZ :D
Well I might change my PC next year or continue encoding during nights :D

David

ps : I checked that with the Canopus codecs installed, movie maker is still using the directshow codecs of M$ to copy the DV stream onto the harddisk, so you need to change the FourCC anyway.

[WorBry]

Hi David,

The capture guide is in the main GUIDES section:

TV Capture & DV Cameras -> Analogue TV Capture Guide -> Processing Video with AviSynth ->(7.29) Color Adjustment. There's also a parallel section - Processing Video with VirtualDub.

On that note, SmoothDeinterlacer is also an excellent alternative if you want to post-process in VirtualDub. I sometimes go that route with VHS to AVI captures, mainly because FlaxensVHS filter does a great job at correcting the types of chromashifts that tend to crop up with VHS sources. It's also a good choice if you ever plan to encode at double framerate (50fps) i.e. SeparateFields with AviSynth and then SmoothDeinterlacer (alternate fields) in VDub. Produces amazingly fluid playback, but you need a fast pc....and on that note...

Glad (hope) you received my comment about your box in the light spirit in which it was intended. I only upgraded from my trusty old crate (500MHz PIII, 256MB RAM, W2KPro) to a faster machine (AMDXP2800,1GB RAM, XPPro)two months....convinced the wife that it would avoid me hogging the one PC and that it would mean me spending less time on the new one "playing around with videos" ......how devious is the male species

:D

[David caid]

Hello,

I did some tests about deinterlacing to compare the 2 deinterlacing filter,
Based on the capture guide (see the post of Worbry just above), it turns out that the Sony DHC14E, is doing PAL trully interlaced.
Is that true for all sony product ? all digital camcorders ? It would be nice to make a thread with a database with such information.

So from the guide, you might use KernelDeint filter. As I used, FieldDeinterlace, I wanted to check what was the difference.
I did several test.
Using this script :

Y=film.FieldDeinterlace(blend=false)
W=film.KernelDeint(order=0,sharp=true)
Z=Subtract(W,Y) #.Levels(125,1,130,0,255) (if you want to increase contraste)
or
Z=compare(W,Y)


There is not a lot of differences.
I tried also with KernelDeint(order=1,sharp=true), as WorBry told that it is bottom field first (order=0, normally).
It doesn't make visible difference, does it make sound shifting ? How did you get this info WorBry that it is BFF ?
If you use the compare filter, then the PSNR is around 36 (instead of 32).

The option sharp=true improve slightly the PSNR.
Well, so based on this, I might use the KernelDeint(order=0,sharp=true) filter for a while. It seems to be good.
Therefore I like the option sharp=true as I don't like blurry image (it is a personal choice).

Ciao
David

ps : About my configuration, you make the point "....convinced the wife " ... I'll try your argumentation "With a faster PC, I'll spend less time on it :D

[WorBry]

Hi David,

There are "progressive scan" camcorders out there but, as I understand it, native DV is always interlaced BFF (wheras DVD is TFF). Here's how to prove it to yourself (abstract from KernelDeint filter info):

"KernelDeint() takes the following named parameters:

order (0-1, default none!) This parameter defines the field order of the clip. It is very important to set this correctly. Use order=0 for bottom field first (bff). Use order=1 for top field first (tff). You must specify order; DGBob throws an exception if you omit this parameter.

It is essential to set the field order properly for correct rendering. Because setting it correctly is so important, you are strongly encouraged not to make assumptions about the field order of a clip, but rather to verify the field order using the following procedure.

To determine the field order, make an Avisynth script that serves the raw clip without any processing. If it were an AVI, then just AviSource() would be used. For our examples, we'll use AviSource(). Add a script line to separate the fields using top field first, as follows:

AviSource("your_clip.avi")
AssumeTFF().SeparateFields()

Now serve the script into VirtualDub and find an area with motion. Single step forward through the motion. Note whether the motion progresses always forward as it should, or whether it jumps back and forth as it proceeds. For example, if the field order is wrong, an object moving steadily from left to right would move right, then jump back left a little, then move right again, etc. If the field order is correct, it moves steadily to the right.

If the motion is correct with AssumeTFF().SeparateFields(), then your field order is top field first and you must set order=1. If the motion is incorrect, then your field order is bottom field first and you must set order=0. If you are want to double check things, you can use AssumeBFF.SeparateFields() to check correct operation for bottom field first."

You can adjust other parameters (threshold etc), but generally I find that the defaults work well with my DV sources.

Cheers,

PS - Not sure the wife is too convinced about me spending less time on the computer, but she is well impressed with the quality of the videos !

[WorBry]

David, if you're still out there. Actually it would appear that DV is not always Bottom Field First (BFF). Just tried out the Matrox DV/DVCAM codec for decompressing my PAL Type II DV sources, and it definitely reverses the field order to TFF - which is OK, as long as you remember to set KernelDeint to Order=1 when deinterlacing with AVISynth and change the "source clip" field order from BFF to TFF when using TMPGenc to convert to DVD (otherwise you'll get a very shaky DVD). Actually, I'm pretty impressed with the results. Like the Sony DV codec, it appears to eliminate the "color bleed" that I've noticed with other DV codecs. Wheras the Sony codec upsamples to RGB24, the Matrox codec upsamples to RGB32 (or so AVISource.Info tells me in AVS). More importantly, the luminance range appears to be accurately mapped to 16-235 when converted to YUV colorspace, resulting in much less "haze" than the Sony codec. This has particular benefits in DVD conversion (for DVD player/TV playback) using TMPGenc, as I've never been able to figure out what color adjustments should be applied in TMPGenc to correct for this "luminance shift" that arises when using the Sony codec for decompression. The only downside, is that the Matrox codec is slower, but it's worth the wait.