help deinterlacing with TempGaussMC

[skubany]

Hi,

I'm trying to deinterlace and compress DV home recordings.

Here is my progress.

I modified TempGaussMC_beta1u2.avsi initial script values to use the 'NNEDI2' mode by setting EdiMode = default( EdiMode,"NNEDI2")

I will be using MeGUI to convert 720x480@29fps DV home videos to 960x720@59fps H264.
So far I'm using standard MeGUI settings with the following exceptions:
In x264 encoder config I've set "Presets" to Slower and "ABR" mode to 5000 bitrate.

I will be using this script as the MeGUI input:
AVISource("test.avi")
#DirectShowSource("test.avi")
#ConverttoYv12(interlaced=true)
TempGaussMC_beta1u()
Spline36Resize(960,720,0,0,720,480)

Still deciding whether to go with AviSource or stick with DirectShowSource. The opinion is that AviSource is better but I get an error with AviSource stating that DV decoder can't be located while DirectShowSource works fine.

Edit:
Based on recommendations I installed Cedocida 0.2.2 and will use that as the DV decoder in the above script. I'm using the default Cedocida settings and "return info()" shows AviSource output as YV12, using MPEG 2 interlaced. Research done and onto converting :)

Some stats:
Using AMD Phenom II X4 940 @ 3,5GHz on WinXP 64bit with 8 GB ram. The above script in MeGUI 0.3.4.0 runs at 3.76 FPS with ~ 50-62% CPU usage. I'll be running two workers at a time to maximise CPU usage.

All suggestions welcomed (still).
Thanks.

[Guest]

The approximate output file size of a 500MB input clip is reported as 8GB! Is that correct? Yes, it is correct. You need to set a compression under Video/Compression. If you omit that you will get uncompressed RGB, which is very large.

[Inspector.Gadget]

Because TempGaussMC is a slow filter, if you can spare the 8gb space temporarily, your encoding workflow may (almost certainly will) go faster if you output to something like HuffYUV (a lossless compression scheme and a VFW encoder) and then use the now-deinterlaced HuffYUV clip as a source for any 2-pass encode using a lossy codec. In this way, you avoid invoking the slow filter twice.

[Didée]

Small but urgent mistake!

DirectShowSource("input.avi") # If the codec delivers YUY2 video, then ...
ConverttoYv12() # <- Here you are *destroying* the interlaced structure (chroma planes)


The minimum you have to do is

DirectShowSource("input.avi")
ConverttoYv12(interlaced=true)


Moreover, (for more reasons than I can explain now) it is advisable to stay away from DirectShowSource, if possible. For AVI files, it is recommended to use "AviSource()" instead. (If AviSource is giving you problems, please explain.)

[skubany]

Appreciate the instantaneous replies :)

Here is my workflow:
Capture (done) -> Denterlace (in progress/researching solutions) -> Add date (DV Date) -> Compress to DVD (mpeg2)

neuron2:
Eventhough I have the 8GB uncompressed file it will still yeld similar sized DVD compressed file compared to compressing the input file itself (the one still interlaced), right?

I can spare 8GB temporarily but I would not want it to cause a bigger final (compressed) file. The reason I go with uncompressed because I want any video compression to happen at the final stage (mpeg2 creation). I want to keep video quality loss to absolute minimum while deinterlacing.

Didee:
I did read that AVISource is better but I'm unable to locate AVISource.dll. Could you provide a link or place to search for this file?

When replying, please keep in mind that deinterlacing (avisynch/scripts/video formats) is all new to me.

[Inspector.Gadget]

I can spare 8GB temporarily but I would not want it to cause a bigger final (compressed) file. The reason I go with uncompressed because I want any video compression to happen at the final stage (mpeg2 creation). I want to keep video quality loss to absolute minimum while deinterlacing.

Then HuffYUV (and similar lossless video codecs) are ideal for your intermediate file: they don't add much time to the encoding pass you would do with TempGaussMC and they reduce the space you need for an intermediate file over uncompressed video by a huge amount.

[GodofaGap]

Didee:
I did read that AVISource is better but I'm unable to locate AVISource.dll. Could you provide a link or place to search for this file?
AviSource is a native Avisynth command. You don't need a external plugin for it. :)

[nm]

Here is my workflow:
Capture (done) -> Denterlace (in progress/researching solutions) -> Add date (DV Date) -> Compress to DVD (mpeg2)

Why are you deinterlacing for DVD? You'll only lose motion fluidity since DVD doesn't support 50/60p video.

[2Bdecided]

So in order of inappropriateness....

1. deinterlacing when you don't need to
2. using progressive chroma conversion on interlaced content (now fixed)
3. converting to RGB when the source and target are both YUV based (and probably clipped by the conversion!)
4. using directshowsource

If you tell us what you're trying to do, someone may be able to help.

Cheers,
David.

[skubany]

GodofaGap:
Was thinking that may be the case, but never tried using it. Will now :)
I'm getting "couldn't locate decompressor for fourcc dvsd" error and am looking at ways to fix it. So far I know it has to do with unavailable DV decoder.

Inspector.Gadget:
I will take a look at what you mentioned.

nm:
I don't think I'll be creating actuall DVDs. I think I'll just store the video on hard drives in mpeg2 (DVD) format - undecided yet. The clips will be played back on a computer so I figure it's best to deinterlace them so that it does not have to be done while they're being played since not all playback software might support it. Currently, the playback software that I plan to use is VLC and the WD HD Live. I'm not sure if WD HD Live does deinterlacing, haven't tried, but will soon.

2Bdecided:
"3. converting to RGB when the source and target are both YUV based (and probably clipped by the conversion!)"
I used this initially because without it the color of the output video was altered - very greenish. But it appears that using 'interlaced=true' earlier in the script makes convert to RGB unneccessary.

Thanks to everyone. I will modify my script accordingly. Further suggestions are welcome.

I will most likely keep the originals (interlaced) as well since hard drive space is cheap.

[nm]

The clips will be played back on a computer so I figure it's best to deinterlace them so that it does not have to be done while they're being played since not all playback software might support it. Currently, the playback software that I plan to use is VLC and the WD HD Live.

How about upscaling to 720p50/60 and encoding to Blu-ray-compatible H.264? Or do you need to support slow CPUs?

[NerdWithNoLife]

GodofaGap:
I'm getting "couldn't locate decompressor for fourcc dvsd" error and am looking at ways to fix it. So far I know it has to do with unavailable DV decoder.
Just install Cedocida DV codec.

[2Bdecided]

To deinterlace while maintaining full spatial and temporal resolution, you'd have to use a non-DVD compatible MPEG-2 profile / framerate.

You can get far better quality by deinterlacing in AVIsynth, but it's slow. VLC deinterlace = linear will let you watch interlaced content OK on-the-fly.

Cheers,
David.

[nm]

VLC deinterlace = linear will let you watch interlaced content OK on-the-fly.

VLC also has yadif (both half and full-rate modes) since version 1.0.3.

[WorBry]

VLC also has yadif (both half and full-rate modes) since version 1.0.3.

Neat. Thanks, I didnt know that. The Yadif implementation in FFDShow has never worked properly for me.

[2Bdecided]

I was using 0.8.4! :-0 So thanks for that.

(Not that it makes any difference at all for handheld camcorder footage!)

Cheers,
David.

[skubany]

nm:
How would I go about upscaling to 720p?
Would the result, quality wise, be equivalent to using the player's "full screen" option? - if so I might do just that

I figure x.264 encoder would come into play.

NerdWithNoLife:
I was reading about this codec (Cedocida DV) yesterday. It will probaly take me a few days to find one that I'll end up using.

--

I also tried comparing a deinterlaced clip to VLC's on the fly deinterlacing and VLC did not do as good of a job. I compared all available VLC (v1.xx) deinterlace methods. So I'll go ahead and deinterlace those clips for presentation/playback purposes, keeping originals as well.

[osgZach]

It also looks like you are using an older version of TGMC, there is a beta2 out now. Just thought I'd mention that..

Also.. if you can get a multithreaded Avisynth (there are a couple x32 and one active x64, I use the x64 version) going, TGMC will take a LOT less time, even if you don't use an external deinterlacer. I don't know how well the WDTV Live handles pure interlaced as I've never really tested it before, but making a good H264 progressive source, it will play it back like a champ. If it were for TV only viewing you could even get away with a pretty low bitrate, but that won't look too good on via VLC on a PC if you go fullscreen mode.

If you have a 64-bit CPU & OS installed, I'd recommend trying out JoshyD's thread in the Avisynth Development forum. The nice thing is, you can install x64 and play around with it, and it won't touch your 32-bit build as far as I can tell. So you don't really lose anything if it doesn't work out. Just have to manage separate plugins directories (x32/x64).

How long is your video? I'm using the UT codec for lossless intermediate files, and can squeeze about 22m:48s (Anime) into a 4gb file. Takes about 2h:30m to encode under multithreaded x64 Avisynth, w/TGMC.

[nm]

nm:
How would I go about upscaling to 720p?
Bob and resize with your favorite AviSynth filters. Encode with x264.

Would the result, quality wise, be equivalent to using the player's "full screen" option? - if so I might do just that
Well, you can use better resizing filters with AviSynth, but the difference is probably not noticeable. The reason why I suggested upscaling to 720p is that it's the only widely supported option for 50/60p outside PC software players. I don't know if WDTV plays 576p50/60, but many Blu-ray-players and standalone devices will not, even when they support 720p50/60.

[osgZach]

WDTV Live has loads of output modes to select from and if something is not in the current output spec it will scale it..

i.e I can play 480p, 720p / 1080p even though my TV only does up to 1080i (the mode I set the Live to) and it never switches modes to do it.

Looks great all the same from what I can tell.

Only thing I don't know is pure interlaced content. Haven't ever tested it and have no experience with encoding something properly as a test either..

[nm]

WDTV Live has loads of output modes to select from and if something is not in the current output spec it will scale it..

i.e I can play 480p, 720p / 1080p even though my TV only does up to 1080i (the mode I set the Live to) and it never switches modes to do it.

I know that scaling the output is not a problem but input framerates may be. Can it play 480p60 or 576p50 files? Otherwise you'll either need to deinterlace to 25/30p and lose half of the temporal resolution, or upscale to 720p.

[osgZach]

I'll try and test this tomorrow.

For 480p, I assume double rate (i.e vanilla TGMC) on an NTSC DVD (for 59.94fps) would be a sufficient test? Or are we talking -exactly- 60fps ?

[2Bdecided]

For 480p, I assume double rate (i.e vanilla TGMC) on an NTSC DVD (for 59.94fps) would be a sufficient test?You can't put "double rate" progressive on a DVD.

This has been mentioned already. Several times. ;)


When people say 60p, they mean 59.94p - no one uses 60.00p!

Cheers,
David.

[osgZach]

You can't put "double rate" progressive on a DVD.

This has been mentioned already. Several times. ;)


When people say 60p, they mean 59.94p - no one uses 60.00p!

Cheers,
David.


What do DVD's have to do with a WDTV Live ?

And so far the playback device mentioned include a PC (assumedly because of VLC) and a WDTV Live...

[2Bdecided]

Ah, sorry, you said "on an NTSC DVD", but I think you meant "from an NTSC DVD".

So the answer to your question is yes - 59.94p is not only a "sufficient" test, but it's also what you should be doing (not 60p).

Cheers,
David.

[osgZach]

Yes, hrm.. sometimes I think of one word and another comes out.

As for 59.94/60 just wanted to make sure.. seems a minority of people actually mean 60 when they say 60 :stupid:

[skubany]

osgZach:

I believe I did look at beta2 of the TGMC script (unless it came out sometime in the last 3-4 weeks) and ended up sticking with the current one. As for multicore. I have quad Phenom II @ 3,5GHz and testing shows about 3fps and 34% processor (entire) utilization. After I create a workflow I will most likely try to run two or three instances of virtual dub to load the CPU to 100%.

Personally, I think all the different TGMC version could be better documented/organized for those people that are starting to use them. It was a challenge to find all the available versions of the script, figure out the differences between them and decide on the one to use. There is a central wiki source but it seems outdated, when I was looking at it few weeks ago. Still, a great script and many thanks to all that contributed to it.

I'll look at the thread you've mentioned about AviSynth x64 edition.

I actually have a number of clips from past years. 25 or so 1hr tapes (231GB in uncompressed DV format). We've moved up to 1080i sony HD cam (HDR-SR1, WD HD Live plays those files very nicely) few years ago and I wanted to transfer the DV tapes to hard drive before they deteriorate even further. Having done the transfers I have some time to think about how I'll actually store them.

I will consider upscaling them to 720p.

"I'm using the UT codec for lossless intermediate files..."
What is 'UT'?

Thanks.

[osgZach]

UT is a lossless codec, just like I said ;)

That's what its called. Here is the latest post for its Doom9 thread.
http://forum.doom9.org/showthread.php?p=1382276#post1382276

It has both 32 and 64 bit versions (it appears to install both at once) which is great if you need to switch between Avisynth versions for some reason.

Regarding storage. DVD9 or BD 25/50 are probably good solutions to keep as hard copies. In terms of where to store them.

Also minor correction on an earlier statement.. I forgot my files are coming out as just over 18 minutes long (VFR decimation, but plays back at the original 22m:48s). Since I've paused my queue to do some WDTV Live tests on 480-60p I added up what I have so far, to give you an idea of file size. Of course different content compresses better or worse, depending.. But for 384.51 minutes of footage (across 21 files in my case, for 6h:28m:51s) the files add up to 84.8gb (explorer file details). Largest file is 4,681,445KB and the smallest is 4,002,280KB (4.02 & 4.681 GB respectively). Each file has around 33,000 frames give or take, and is encoded as 30fps progressive (although there are 24p sections in there too, not sure how this affect predictability on non-VFR sources)

I know my Huffy's would usually come out around 7GB or so.. sometimes I could even get files as big as 8 - 10gb for a single Anime episode. So I think UT does a very good job.
I would say these sizes are similar to Logarith.
It's not scientific though, so take it for what it's worth.

[osgZach]

Also.. these are the retail specs.. But I'm not sure if they accurately reflect any firmware changes, etc.. Because I know for sure I have played 1080p file, but I don't know if they were above 24fps or not.. It's probably unlikely.


Note:
- MPEG2 MP@HL up to 1920x1080p24, 1920x1080i30 or 1280x720p60 resolution.
- MPEG4.2 ASP@L5 up to 1280x720p30 resolution and no support for global motion compensation.
- WMV9/VC-1 MP@HL up to 1280x720p60 or 1920x1080p24 resolution. VC-1 AP@L3 up to 1920x1080i30, 1920x1080p24 or 1280x720p60 resolution.
- H.264 BP@L3 up to 720x480p30 or 720x576p25 resolution.
- H.264 MP@L4.1 and HP@4.1 up to 1920x1080p24, 1920x1080i30, or 1280x720p60 resolution.
- An audio receiver is required for multi-channel surround sound digital output.
- Compressed RGB JPEG formats only and progressive JPEG up to 2048x2048.
- Single layer TIFF files only.
- Uncompressed BMP only.


However.. It can playback 480p30 - which is what I encode my Anime DVD's at using TGMC. You just have to follow it with a SelectEven() (or SelectOdd I guess? I use Even) call.


TempGaussMC_whatever().SelectEven()

and you get 30fps progressive output. Although it takes longer. I call


MT("""TempGaussMC_beta2().SelectEven()""")


And it takes about 2 hours 30m roughly per 18m (22m:48s) VFR clip.

And it can also playback 720p files. I would assume it might do 720p60 if it supports it under Mpeg2, and also supports proper AVC Levels. The tricky thing about (H264) AVC Levels is on any given level, if you lower the resolution it usually should be possible to play something at a higher framerate, with more ref frames, etc.. There is probably a chart somewhere - I'll try to find it. Cause I may be remembering some of this wrong.

But at the very least. If you have 720x480 material, then making it 30p via TGMC.SelectEven() should not be a problem I would think.

I don't think you've mentioned what resolution your material is? I went back and skimmed but didn't see any mention.. is it 480 or 576 ?

Edit: It will play back 480p60 fine from what I can tell.

[Leak]

Neat. Thanks, I didnt know that. The Yadif implementation in FFDShow has never worked properly for me.
It works great for me - maybe you don't have "Process frames flagged as progressive" checked? That would almost certainly prevent it from doing anything on most sources...

np: Bomb The Bass - Start (Back To Light)

[WorBry]

maybe you don't have "Process frames flagged as progressive" checked?

Aha, you`re right. I hadnt thought that would be relevant to a pure interlaced source, but obviously it is. Works fine now. Thanks. :)

[skubany]

Some time has passed, lets try to revive this thread. Hopefuly there will be just as much interest in it as before :)

What have I done for the past month, not much. I have checked how WDTV Live HD handles deinterlacing. The result, the smoothnes of the video is lost. As if Live HD was dropping every other frame.

More questions.

If I want to keep fps at 60 (59.xxx) it seems that I have to upscale it to 720p. Unless there exists a codec that can compress DV 720x480 @ 60fps to same resolution and fps. I've only seen 30fps (29.xxx) for the above resolution and 60fps is allowed only for resolutions 720p and up. Upscaling, can someone tell me how I can do that with AviSynth or through other programs? Also, will software upscaling produce the same result as realtime upscaling by whatever player/tv is used?

What are my options for deinterlacing DV to 30fps? I've tried TempGaussMC_beta1u().SelectEven() which gives pretty much the same result as compressing deinterlaced 60fps to MPEG 30fps. When watching the resulting video it's clear that every other frame gets dropped (video smoothnes is lost).

Thanks.

[2Bdecided]

Unless there exists a codec that can compress DV 720x480 @ 60fps to same resolution and fps.Almost any codec can do this. MPEG-4 AVC or ASP, MPEG-2 High Level, even DV-AVI (it's a bit non-standard so don't expect it to work). The question is whether your hardware will play it.

I've only seen 30fps (29.xxx) for the above resolution and 60fps is allowed only for resolutions 720p and up. Upscaling, can someone tell me how I can do that with AviSynth or through other programs?There are plenty of threads on upscaling in this forum, and there's one in the DV forum right near the top.

Also, will software upscaling produce the same result as realtime upscaling by whatever player/tv is used?Better, the same, or worse, depending on "whatever" is used already, and what AVIsynth process you choose.

What are my options for deinterlacing DV to 30fps? I've tried TempGaussMC_beta1u().SelectEven() which gives pretty much the same result as compressing deinterlaced 60fps to MPEG 30fps. When watching the resulting video it's clear that every other frame gets dropped (video smoothnes is lost).Yes, that is the most common option. The other is blending the fields (or deinterlaced frames), which will make everything blurred when it moves, but look smoother. Stick with 60fps.

Cheers,
David.

[levi]

I would recommend caution in using JoshyD's avisynth x64. I use it, but it has a lot of ongoing development... bugs still being worked out. For someone new to this, I would hate to cause confusion when doing it right but still having errors due to bugs. You can get reasonably close performance with some of the older versions and not have that risk.

[skubany]

Ok, so I think I have found all the software that I'll end up using in encoding my DV source home videos.

Spline36Resize(1080,720,0,0,720,480) looks to be doing a very good job at upscaling.

After looking a long time for an encoder, it seems I'll end up using MeGUI x264 to encode my 1080x720@60 clips. The part that I like about MeGUI the most is that it takes an .avs script which means that DV is turned into the final output file in one pass without having to allocate GBs upon GBs for temporary deinterlaced/upscaled files, before they get encoded.

I've produced a test file using MeGUIs VBR@5000 setting. I also moved the slider on the encoder's config page to "Slow" (in the future I will try "Very Slow" as well). In the result, I have noticed the colors are slightly changed. Maybe a case of brightness being higher than the input video's.

Another question that I have, can anyone who is familiar with MeGUI suggest a good setting? What works very well most of the time when encoding 720x480i DV source to H.264? Anything I should be paying attention to when configuring the MeGUI program?

Next step for now is to make sure that WD TV HD Live can play this latest test file.

Thanks.

[Inspector.Gadget]

In the result, I have noticed the colors are slightly changed. Maybe a case of brightness being higher than the input video's.

This is likely a decoder issue. BTW, why 1080x720? And why do scaling with (good, but not magic) Avisynth scalers instead of your display?

[um3k]

BTW, why 1080x720?

1080/720 = 1.5 = 720/480

I.E. not respecting pixel aspect ratio.

The easy answer is that it should be 960x720 (for 4:3) or 1280x720 (for 16:9).

The slightly more complicated answer is that, depending on your camera, for complete accuracy you might need to scale from 704x480 instead of 720x480.

The somewhat frustrating answer is that the only way to know what your camera uses is to shoot test footage.

If you go with the easy answer, you'll be on par with many video professionals. If you go with a harder one, you're on your way to becoming one of us.

[Inspector.Gadget]

Yeah. IMO as long as you're resizing W+H it's fine to shoot for an output that corresponds to 1:1 par.

[2Bdecided]

If you go with the easy answer, you'll be on par with many video professionals. If you go with a harder one, you're on your way to becoming one of us.<smile>

Though if they're old home movies, and you choose the common-but-wrong one, you'll only make the people in the movies 2% thinner (assuming they're standing up) - and few people will complain about that! ;) Unless it makes the difference between then-and-now even greater! :( :p

As for upscaling, there are better ways to upscale within AVIsynth than straight spline36resize. e.g. see the improving resolution thread in the DV forum.

Cheers,
David.

[henryho_hk]

osgZach:
I have quad Phenom II @ 3,5GHz and testing shows about 3fps and 34% processor (entire) utilization.

For TGMC+NNEDI (no. of threads set to 1) scripts, I am always splitting the Pass-0 task into 4 parts to feed my quad-core Q6600.

[skubany]

This is likely a decoder issue. BTW, why 1080x720? And why do scaling with (good, but not magic) Avisynth scalers instead of your display?

Why, because prior to finding out about MeGUI the encoder that I planned on using allowed only 30fps for resolutions of 720x480. MeGUI might allow me to encode 720x480@60fps and if so I may forgo upscaling.

Another reason is that you said that software upscaling might yield better results than realtime upscaling. I have no control over realtime upscaling but can, to a degree, control the software upscaler.

I will look into this further.

umk:
"1080/720 = 1.5 = 720/480"
So it's not that simple?
720x480 upscaled should be 960x720?

As for camera resolution. I have no idea. It's a JVC GR-DVM50. I assumed the program that does the capture would know the size of the frame. There are no settings for choosing the frame size.

If anything the captured video might be slightly squished (top to bottom, not sides). It's hard to compare using the cameras LCD.


Yeah. IMO as long as you're resizing W+H it's fine to shoot for an output that corresponds to 1:1 par.
Yes, I want 1:1 resizing. If my setting are incorrect please let me know what the final vertical size should be when going from 480h->720h lines.


As for upscaling, there are better ways to upscale within AVIsynth than straight spline36resize. e.g. see the improving resolution thread in the DV forum.
I'll take a look at that.

henryho_hk:
I was running 3 instances to max the CPU. With MeGUI it looks like it'll be 2 instances.

[um3k]

Assuming you don't have the 16:9 squeeze mode turned on, correct, you should be resizing to 960x720. Try this:

Spline36Resize(960,720,8,0,704,480)

[Inspector.Gadget]

720x480 upscaled should be 960x720?

Only if your input is 4:3. If it is 16:9, then 1280x720 is the appropriate size. If you're not upsizing, then I imagine your device must support non-square pixels for 720x480 content, so then the thing to do is set the appropriate dimensions in x264 using the --sar X:Y command (read x264 --fullhelp for guidance).

[skubany]

Assuming you don't have the 16:9 squeeze mode turned on, correct, you should be resizing to 960x720. Try this:

Spline36Resize(960,720,8,0,704,480)

The recording is 4:3, I have not set any modes. My camera is set to record at 4:3 aspect ratio.
I must say, the capture did look like it's stretched by the sides but I thought the capture software knew what it's doing and didn't question it.

After running a test encode with Spline36Resize(960,720,0,0,720,480) the output looks much better now. People in the recording no longer look unnaturally short.

If I leave the third parameter as 8 I get a bar on the right of the output video which looks like the video data to the left of it only blurred. I thought the thrid and fourth parameters are used for cropping/adding borders but it does not seem to be the case.

I changed the recommended 704 to 720 because the size of my capture is 720x480. Given this, should I still keep the fifth parameter as 704? If so, why?

Finally, am I losing picture quality by correcting the stretching of the video introduced by my capture software (omitting the impact of resizing on the output video)? Or is it just some pixel dimensions correction that Inspector.Gadget mentioned and nothing more. This is more of a curiosity question because I still have to go through the process else my video will be of the wrong resolution and look stretched. From the sample clips that I created upscaling+resolution correction doesn't seem to impact quality of the recording.

Thanks.

[Gavino]

If I leave the third parameter as 8 I get a bar on the right of the output video which looks like the video data to the left of it only blurred. I thought the thrid and fourth parameters are used for cropping/adding borders but it does not seem to be the case.

I changed the recommended 704 to 720 because the size of my capture is 720x480. Given this, should I still keep the fifth parameter as 704? If so, why?
Spline36Resize(960,720,0,0,720,480) uses the entire 720 input width to create the 960 output width.

Spline36Resize(960,720,8,0,704,480) crops 8 pixels from each side, stretching the central 704 pixels to 960. This is considered more correct as the 16:9 aspect ratio is defined to apply to those 704 pixels. However, not all sources conform to this.

Spline36Resize(960,720,8,0,720,480) is definitely wrong, since it takes a width of 720 starting from pixel 8, ie it extends beyond the right hand edge, causing the resizer to produce artifacts there.

[skubany]

I'm almost there. I'm planning to start compressing my home videos next week.

But we're not done here just yet :)

Why is AviSource better than DirectShowSource?

Reason I ask is that DirectShowSource works as is but I still have to look for a DV decoder for AviSource (which currently gives errors if I try to use it) or point it to an exisitng decoder which DirectShowSource uses, if that would work.

I will update my original post with the latest script.

[Inspector.Gadget]

It isn't, necessarily. It's more of a frame accuracy and stability question, plus there were a lot of issues in the past with B-frame order with packed AVIs and various decoders. Personally, I would use DSS2(), which is frame accurate. You get it by moving AVSS.dll from the Haali Media Splitter package to your Avisynth plugins folder. The caveat here is that you can't use it for audio. If you're not serving audio through Avisynth anyway (and you probably shouldn't be cutting and joining while using TempGaussMC for speed reasons alone), then you'll be fine. If you are, then you can still call audio with DirectShowSource() in the same script.

[skubany]

I will be compressing audio separately and then joining the two (video+audio) in a mkv package. MeGUI has a separate panel for audio encoding and I'll be using that part of the program.

[2Bdecided]

You need to install cedocida (about 10 seconds effort), and use AVIsource.

Don't use some random unknown DV codec - cedocia is the one to use. It solves a lot of potential problems (I've seen people report blocky errors with other "professional" DV codecs - why risk it), and it'll deliver whichever chroma format you require (rather than possibly converting RGB back to YV12).

Cheers,
David.

[skubany]

DDS2 [DSS2("test.avi")] does not work in my script (as appears in the first post, DirectShowSource was replaced with DDS2).

The output is not fluid when there is quick camera movement in the recording. Quality, as compared with still frames at many points in my test footage, is no different than DirectShowSource.

Cedocida. I wan't to try that next but I don't want to screw up my video codecs. Cedocida install states that current decoder will be overwritten. How can I bring back my old decoder once Cedocida is uninstalled?

I plan to configure cedocida to "force YV12" and "YV12 chroma sampling -> DV". Is that correct? Will I still need "ConverttoYv12(interlaced=true)" in my script, since it seems codecida will already give YV12 which TempGaussMC expects?

Thanks