Encoding miniDV tapes - XViD or progressive H264?
 

Hi All,

I have around 40 miniDV tapes with precious home videos, which I want to preseve. I also want them to be easily accessible from my player on wide screen TV.

Which format shall I choose? My first choice was to de-interlace and compress using XViD; I did that before and it works: files are x10 smaller and play nicely on my (5 years old) WD TV.

But all that seems osolete now; I've read re-interlacing causing information loss and instead of deinterlacing I shall:

de-noise
convert to progressive, doubling the frame rate
up-scale the resolution
encode with H264

Some people saying up-scaling is pointless; I also can hardly believe it will improve quality. Do you agree?

I've noticed my old WD TV is not always playing H264 smoothly; time to upgrade?

Xvid = NO is obsolete
The TV or the player on TV automatically and Deinterlaced scaliert the image.
If one must first be filtered and cut, then use a video editing program.

MP4 is just a container.
H.264 = image = AVC / AAC Audio or AC3 =

With a video editing program to spend or MP4 for free with Hybrid.http: //www.selur.de/

Or grab here and upload a snippet of a DV-AVI in WinZip or WinRAR

Thank you for explanation!
Can’t attach samples to the forum; “please wait” is displayed and nothing happens.
Samples are at http://www.ozshots.com/samples.zip
Daylight is quite OK while indoor has terrible noise and colour issues.

I’m using Sony Vegas for my current HD projects from new camera.
My starting point for old videos is just to make them easily available to watch unedited on TV screen; as there is lots of footage.

I’m thinking of keeping unprocessed files (large) as well as re-encoding them for easy viewing(small). Not sure really what to do.

I’m trying to download x264vfw codec for VirtualDub. Is there a guide with recommended settings?

x264vfw I would not take.
"VFW" = Video for Windows ........... is saved in the AVI container.
So as the ancient DivX and XviD.

ITU-T H.263 / MPEG-4 ASP Video: DivX, Xvid, Adobe Flash
"MPEG-4 ASP" is very old and not good quality.

The modern MP4 =
ITU-T H.264 / MPEG-4 AVC Video: x264, hybrid, Apple QuickTime, Nero Digital, MainConcept H.264 / AVC
is for the future ............. up in 2020 then H.265 / X265 is currently, I hope.

MP4 AVC = + audio as AAC or AC3.
----------------------------------

Hallo.Ich have your two DV-AVI to MP4 encoded with Hybrid.
In the example, both in progressive.

Hybrid is free.
http://www.selur.de/
He speaks English and German.

Stream in MP4 Container can also use video editing programs like Edius / Adobe Premiere and Sony Vegas are created per.

The Indoors sample has grain associated with CMOS noise. SOme of the finer grain can be removed, but the basic CMOS noise "pattern" will remain and objects will move around "undr" it becauew the CMOS noise signal is stronger than the video signal. The sample avi is dark and flat.

I deinterlaced "Indoors grain.avi" with QTGMC, removed most of the noise with MDegrain2, and corrected levels. I then made two samples in AVisynth, one at 576p and another at 720p (attached). The 720p is encoded as m2t for BluRay or AVCHD, but since .m2t isn't allowed for upload the 720p video is zip'd.

You may as well double-rate deinterlace these DV AVI's. DV doesn't interlace well and there's really no way to clean its noise without destroying a lot of video or throwing away half the frames. Discarding 50% of a video is not what one could call a suitable archive for family videos regarded as precious. Also, discarding frames from interlaced video results in judder and loss of temporal resolution during motion.

The Daylight video shows visible clipping, low color density, and artificially elevated black levels, resulting in a washed out image that lacks depth or life like qualities. The clipping of specular highlights occurred at some point during processing. All values from about RGB 180 and brighter were clamped to a single RGB value, so that highlight detail is destroyed. The image will lack "snap" or dynamic range at the bright end because of clipping of bright values. The hard clipping and high black levels are seen the in the top white section of the YUV histogram graph below. One can make the image "brighter", but there will be no gain in bright detail or dynamics and the image will simply look washed out. You can see the results of clipping in the bright "hot spot" on the girl's forehead and in the washed-out bright areas of the girl's clothing.
http://www.digitalfaq.com/forum/atta...1&d=1448125401

Levels and gamma corrected in Avisynth and VirtualDub:
http://www.digitalfaq.com/forum/atta...1&d=1448125464

Usually people will raise brightness or use autogain controls to try to compensate for clipped highlights, but this just makes a pale image. Or they do it to make everything look like bright daylight. The scene above was not shot in bright summer sunlight. The lighting is really subdued, hazy, cool-weather light. The effects of autogain are visible in both avi samples.

The avi's were processed with QTGMC, Avisynth's dither plugin pack, and VirtualDub. All encodes used x264 encoding apps.

sanlyn
But the question was x264vfw [MPEG-4 ASP]
or more modern MP4 [MPEG-4 AVC]

of restoration was not the question here.

h264. And not mp4. That's for low-bitrate web streaming. Stay with spec BluRay/AVCHD full-bitrate m2t, etc. Mp4 is for kids and games.

And if no cleanup or restoral, why bother with a forum? Anybody can encode ugly video from 1-2-3 steps shown on any website anywhere.

there is not any.
H.264 with point
and as a software called the x264.

MP4 is a Container, there can mpeg2 or x264 [AVC and AAC there be.

I have the statement only in German

But can safely read in English by Doom9 user LigH.

Look nevertheless times purely in the settings of hybrid.

Und noch mal, und noch mal, und immer wieder:

Alle (theoretischen) Standards der ITU-T beginnen mit einem Großbuchstaben und einem Punkt,
gefolgt von drei Ziffern - z.B.: H.261, H.263, H.264,H.265 (Video-Komprimierung), G.723 (Audio-Komprimierung) u.v.m.

Die (praktische) Implementierung als Software z.Bsp.namens x264,x265 dagegen beginnt mit einem Kleinbuchstaben ohne Punkt.

H.264,H.265 ist ein Standard - also Theorie.
x264,x265 ist ein Programm, eine Implementation des Standards - also Praxis.
__

H.264 ist als Kompressionsverfahren ein Teil des umfassenden Standards "MPEG-4 AVC",
das wäre ein Videoformat. MP4 wäre ein Kontainerformat, in dem AVC enthalten sein darf.

MKV wäre auch ein Kontainer. Auch da darf MPEG-4 AVC als Video enthalten sein,
das mit H.264 komprimiert wurde.

Das alles voneinander unterscheiden zu können, dürfte eure erste Aufgabe sein. Hier mal ein paar Beispiele, zu welchem Standard welche Software gehört:
ITU-T H.261 / MPEG-1 Video: TMPGEnc, bbMPEG
ITU-T H.262 / MPEG-2 Video: HCEnc, TMPGEnc, CCE, CPC,Procoder.
ITU-T H.263 / MPEG-4 ASP Video: DivX, Xvid, Adobe Flash
ITU-T H.264 / MPEG-4 AVC Video: x264, Hybrid,Apple QuickTime, Nero Digital, MainConcept H.264/AVC
ITU-T H.265 / MPEG-H HEVC Video: x265, Kvazaar
---------------------------------
http://forum.doom9.org/showthread.php?t=96059

Yes, as you mention, x264 is an h.264 encoding engine. It appears to be favored by those who don't care for the noisy h.264 encoding by scaled-down, inferior copies of MainConcept used in many NLE's. If the O.P. can afford a genuine, unaltered MainConcept professional edition, well and good.

The difference between the containers for DVD/BluRay/AVCHD, and the mp4 container, is that mp4 has no encoding or file structure standards. People throw any piece of garbage into an mp4 container and wonder why it plays like silly jelly on some players, or will not play at all. mp4 is for "low standards" or "no standard", both of which are very popular today and which have always been the typical consumer's quality a/v measurement standard since the earliest days of CRT TV. There are millions of examples of how MP4 can "accept" encoding of such poor quality that the results look worse than VHS.

On the other hand, encoding for DVD or BluRay or AVCHD specs helps to ensure widespread compatibility and at least a nominal gesture in favor of some level of quality that is at least better than VHS. The Three formats are playable anywhere today, where MP4 is not universal. The idea that MP4 is more convenient for PC playback is nonsense, as other formats are just as convenient on a PC.

If the owner wants an encoded format for their iPhone, iPad, or other toy, it would be waste of data bits and encoding time to encode to a single high-bitrate format for those toys, a 23-inch PC monitor, a 60-inch plasma, and archival quality at the same time. MP4 is a good idea for well-filtered, very low bitrate (below 1500 kbps), small frame size, 250-frame GOPs that defy clean edits, and use more destructive deinterlace methods. Then there is the question of audio, in which most encoders force AAC high compression into MP4 encodes. The first thing typical users do is encode at the lowest audio bitrate possible, firmly in the belief that "AAC" automatically means "better" quality at lower bitrates than AC3, DTS, or PCM (further proof that the average user is no audiophile).

Finally there are two myths that are very popular today but have no merit in actual use: the first myth is that h.264 is "better" than MPEG, the second myth being that MP4 is somehow "better" than anything else for no other reason than MP4 is MP4.

In this case I don't think the differences seriously matter to ozshots. Perhaps he just wants something that will play and make sounds. It's previously been alluded that the smallest file size is a main priority, which automatically precludes high quality bitrates and short GOPs to handle jittery home video camera motion (but, then, he also complained that the results were less than wonderful).

On the other hand, ozshots might be interested in something a little better that his previous results, so some suggestions have been offered in that regard. He will have to decide what he wants to aim for. The owner also hinted earlier that MP4 was an additional encoding choice for use on portable devices, which in that case would be a requirement. But encoding for portable gadgets and encoding for archival quality or big-screen viewing are two different requirements.

That you can not use the same AAC in lowest bit rate and highest quality, I can confirm you need there already reasonable conditions.

H.264 is part of MPEG, namely MPEG-4 (ISO / IEC 14496) Part 10 (AVC), and the MP4 container is also part of detailed standards and specifications (MPEG-4 Part 1, ISO base media file format)

I can not imagine that MP4 is less suitable as a container for high-quality content to me. Maybe just not as common in consumer formats.

Hybrid brings with Avisynth, also QTGMC and you can encode in interlaced .Also in large data rates.
x264 is more efficient than the mpeg2

What a pity, I thought I could here what to study.Habe your post times in the German Doom9 forum to translate inserted.
Answer must be read in the article. 2

http://forum.gleitz.info/showthread....brid-empfohlen

Guys, thank you all so much!
I have _a lot_ to learn in this area. And I don't think I will be an expert like you any time soon.
I'm not a pro; just an average dad with a camera, trying my best in capturing precious moments of family life.
I now have a stack of DV tapes tapes with raw footage which I want to make available for my family to watch in TV screen, and preserve for the future. Of course if even basic restoration can be made, this is awesome. Indoor footage is truly terrible. Restoration from sanlyn makes it look better.
I could not get “any guide on any site” explaining how to install h264 encoder for VirtualDub. A SourceForge link to X264vfw is broken. Out of desperation I’ve turned to Avidemux which seems to have everything pre-installed in one pack. I can’t find any guide on changing interlaced to progressive on Avidemux either. If I do nothing, interlacing artefacts are visible in encoded video.
So if you can help me to configure Avidemux h264 encoder in the right way, it will be great.
Again, thank you everyone for helping me out.

See attached example - this is my DV file encoded by Avidemux to MPEG 4 AVC (x264) without deinterlacing... clearly wrong and still at 25 FPS.
I'm also using resize from 720x576 to 1024x576, as my camera shots in widescreen.
So I need to do something to increase framerate to 50 FPS?

PS Oh, silly me! Should I just use Yadiff deinterlacing with "bob, temporal and spacial check"? That's all?

What about audio? lame mp3 is obsolete?

Video-Output---->Filters----Interlacing----Yadif
or to taste


For audio not forget the data rate to increase slightly
Default is at 128 kbps

See illustrations

http://www.digitalfaq.com/forum/styl...attach/zip.gif 20060727_2.zip (2.75 MB, 0 downloads)
You have an audio MP3 128 kbps
This is not good....[for my needs ]
AAC or AC3
Data rate from 192 kbps minimum

Here's my test file [Pal not anamorphic] as picture [Media Info]

In much "action" in the film but I would also increase the data rate for the image content yet.

Thank you!
Your example is still 25fps and unfortunately it does not looks good on my player.

Please have a look what I've tried - Yadiff with 50FPS and AAC audio on 224 bitrate.
What sould come first: yadiff or resize?

By the way there are few AAC encoders in Avidemux:
AAC (Faac)
AAC (lav)
AC3 (aften)
AC3 (lav)
Which one to choose?

Do you recommend any noise or sharpness filters for my videos?

Ah-ha ... The Lord wishes DV Avi in 50p;-)

Usually I stay in MP4 in interlaced mode [MBAFF]
Work rarely with AviDemux.

Only if I DV-AVI Scaliere something, for example at 960 x 720 then do ego at 50p

For this I take Avisynth and for encoding to MP4 the free hybrid.
Here's an example, original Canopus DV-AVI ---> Avisynth ---> Hybrid [Demuxed]

[Audio is processed separately in the rule.]
In hybrid I've included the free and good Nero.AAC.Enc.
That's enough for me.
-------------------

Yadif course, it's progressive

I work with Avisynth.
Cropping in Edius, preferences, and test pattern output to the Plasma TV or the interlaced control monitor, depending on the source

ozshots

the film jerky
Image is quite good, maybe a little increase the contrast and sharpness.
Try out.
In the example, [all created in Edius]
Links the original
Right my version

Filters you should always re-encode before

Thank you for your samples and notes. Please forgive any typos you find below. My family in Tennessee is preparing for the Thanksgiving holiday and the place is a madhouse.
:eek:

Yes, clearly. I think you can see that DV itself doesn't interlace well and has excessive combing. There are ways to clean it up, but you can't do it in Avidemux.

Your camera doesn't shoot "widescreen" video. It shoots 720x576 standard definition anamorphic PAL DV encoded for 16:9 widescreen DAR (Display Aspect Ratio). It does not shoot square-pixel 1:1 widescreen video. Notice that the PAL mp4 50p video I posted earlier is 720x576 but plays as "widescreen" 16:9. If you want to see 720x576 displayed as 16:9 in an editor like VirtualDub, you can change the display ratio to what it should be for display.

You double the frame rate by deinterlacing for that frame rate and doubling the number of frames. USing yadif at mode=1 (double framerate (bob), temporal and spatial interlacing check) doubles the number of frames for a frame rate of 50fps. I would recommend that yadif is not a very good deinterlacer for poorly interlaced video. QTGMC is the prime production deinterlacer of choice.

The 20060727_2.mkv sample quality is too low for demonstrating possible improvement. The best that can be done with it is to smooth motion, so I didn't work with it. Again, the IRE and gamma levels are too high and brights are clipped. You can't get snappy bright dynamics with clipped brights. Brightening the video won't help restore destroyed data. I also noted your mkv/mp4 encodes use very long 250-frame GOPs, which are inappropriate for any further cuts/edits without seriously degrading the video. You can get improved motion handling using much shorter GOPs.

It's not obsolete. But it happens to be among the lowest quality of all lossy audio compressors, even at higher bitrates. If you want DVD or BluRay or compatible specs, mp3 is not allowed.

Well...it's not exactly converted "right". It has been incorrecrtly deinterlaced using the wrong field order. DVD, BluRay, and several other formats in PAL/NTSC are usually Top Field First (TFF), interlaced. But Dv-AVI is Bottom Field First (BFF). Did you notice the jerky and noisy double images during motion? If you play this video in Virtualdub or other editor and move it frame by frame, one frame at a time, you'll see that the motion is forward-back-forward-back, etc. If you can't see this, I've attached a sample of a part of the mkv with the frame rate slowed to 5 fps to show how the video actually plays:

bad_field_order_original_5fps.mkv (.zip)
The field order can be corrected in Avisynth by separating even and odd frames and interleaving them in reverse order:

But note that this correction should not have been necessary. The attached video is the result of running that correction script:

field_order_correction.mp4

The correction still has slight residual judder and serious horizontal line twitter from bad deinterlacing and low bitrate encoding. I didn't address those problems. Better to avoid them in the first place.

Avidemux doesn't resize very well. It has softened the original video and made it look rather plastic.

Any of those encoders will do. If you want mp4, you usually must use AAC.

QTGMC does some denoising and motion interpolation. Primarily QTGMC is not a denoisier in itself, so often other filters have to address specific problems. Trying to clean up sloppy interlace, combing, and aliasing effects with DV is a real chore. That's why I suggested that you should properly deinterlace for double frame rates and not re-interlace these particular movies if you want clean playback. Note that 50 fps is not allowed for DVD disc or standard def BluRay disc. 50p standard definition can be used with mp4, mkv, etc., but if formatted as such the limitation is PC playback or external playback from USB stick, external drive, external media server, or burned to optical disc as "data" files. Note that some external players won't play mkv containers, and some have restrictions with mp4 structure.

If deinterlaced and properly upscaled for HD at 1280x720/50p, that format is BluRay/AVCHD compatible. The .m2t files I posted earlier were encoded for BluRay or PC/TV playback or BluRay disc authoring.

I find apps like Avidemux OK for quick encoding or edits, but they're not adequate for real cleanup, good deinterlacing, or clean resizing. I used Avisynth, VirtualDub, and a very popular separate encoder. Below are abbreviated summaries of the workflow I used, working with decoded lossless media, for the three sample videos I posted earlier:

Workflow summary:

daylight_720p.m2t (1280x720 progressive 50fps, 16:9 (1:1 square pixel)
Initial Colorspace correction (Avisynth): ConverttoYV12(interlaced=true,matrix="Rec601")
Levels correction(in AVisynth/YUV): ColorYUV, SmoothLevels, SmoothTweak
Deinterlace: QTGMC (medium denoising enabled)
Upscale for BluRay/AVCHD: 16-bit dither tools in Avisynth, Spline36Resize to 1280x720
To RGB for VirtualDub color grading: 16-bit Dither_convert_yuv_to_rgb (interlaced=false)
VirtualDub filters: ColorMill, Levels GUI, ColorTools histogram
RGB to YV12 for encoding: VirtualDub output to YV12/Lagarith lossless compression
Encoder: TMPGenc Video Mastering Works 5
Bitrate/GOP: 25-frame GOP, 7500kbps VBR, 50p, x264 encoder
Audio: Dolby AC3, 256kbps, 48KHz

Indoor_576p.mp4 (720x576, progressive 50fps, anamorphic 16:9)
Initial Colorspace correction (Avisynth): ConverttoYV12(interlaced=true,matrix="Rec601")
Levels correction(in AVisynth/YUV): ColorYUV, SmoothLevels
Deinterlace: QTGMC (high denoising enabled)
Denoising: Mdegrain2, TemporalSoften, GradFun3 anti-banding, LimitedSharpenFaster
Resizing: None
To RGB for VirtualDub color grading: 16-bit Dither_convert_yuv_to_rgb (interlaced=false)
VirtualDub filters: Camcorder Color Denoise, ColorMill, Gradation curves, ColorTools histogram
RGB to YV12 for encoding: VirtualDub output to YV12/Lagarith lossless compression
Encoder: TMPGenc Video Mastering Works 5, BT709 color.
Bitrate/GOP: 25-frame GOP, 5000kbps VBR, 50p, anamorphic 16:9 DAR, x264 encoder
Audio: AAC, 253kbps, 48KHz

Indoor_720p.m2t (1280x720 progressive 50fps, 16:9 (1:1 square pixel)
Initial Colorspace correction (Avisynth): ConverttoYV12(interlaced=true,matrix="Rec601")
Levels correction(in AVisynth/YUV): ColorYUV, SmoothLevels, SmoothTweak
Deinterlace: QTGMC (high denoising enabled)
Denoising: Mdegrain2, TemporalSoften, GradFun3 anti-banding, LimitedSharpenFaster
Upscale for BluRay/AVCHD: 16-bit dither tools in Avisynth, Spline36Resize to 1280x720
To RGB for VirtualDub color grading: 16-bit Dither_convert_yuv_to_rgb (interlaced = false)
VirtualDub filters: Camcorder Color Denoise, ColorMill, Gradation curves, ColorTools histogram
RGB to YV12 for encoding: VirtualDub output to YV12/Lagarith lossless compression
Encoder: TMPGenc Video Mastering Works 5
Bitrate/GOP: 25-frame GOP, 7000kbps VBR, 50p, x264 encoder, 16:9 (1:1)
Audio: Dolby AC3, 256kbps, 48KHz

Hi All,
I’m speechless about this forum… I didn’t get that much help anywhere for a long time!
I’ve tried Avisynth but I get stuck very quickly, as it needed scripts to be created from scratch and I didn’t know where to start. In Avidemux I can setup filters and then save as script.
My output target are files on HDD, I think it’s more convenient comparing to a stack of blue-rays, which get scratched, lost etc.
Thank you for so much advice, I will try to digest it now….

I know what you mean about discs. The cheap ones damage easily and don't last anyway. HDD's are a good idea. I hav about 14 or 15b of them myself, and about 3000 DVD/BD retail and home made. Of course if a hard drive goes on the blitz and you have 40 videos on it, well....

I wouldn't bother resizing SD video if its aspect ratio is already 16:9. Set top players and most TV's and Smart TV's can scale to your TV's frame a lot better than the resizers and deinterlacers in most one-stop apps and NLE's.

Avisynth isn't that difficult if you start with some decent samples. It also helps to post the exact code of a script that isn't working, and the exact text of any Avisynth error message. I run Avisynth scripts in Virtualdub. For what you want, you won't get better performance than Avisynth and Virtualdub together. you need more suitable tools. It doesn't have to be that complicated. Everything I mentioned except TMPGEnc is free. But there are free encoders, too -- Avidemux being one, and it can read lossless Avi output saved with Virtualdub.

Anyway, good luck. After some of this holiday rush slows down a bit I'll try posting a sample script if you're interested. The filters and methods I used as noted earlier are pretty much standard operating procedure.

This forum pretty much blew my mind, too, when I first saw it years back. Often enough, it still does.

I'm using RAID mirror for all valuable data, plus rotating offsite backup (HDD left at work). Learned that a hard way ;-/

I wouldn't bother resizing SD video if its aspect ratio is already 16:9. Set top players and most TV's and Smart TV's can scale to your TV's frame a lot better than the resizers and deinterlacers in most one-stop apps and NLE's.

Can you please point me to 1-2-3 guide?

The best examples are .avs scripts and Virtualdub filter examples in the restoration and capture forums. There are several r cent projects. One that i can link to now has source video so badly degraded that it makes your look like an MGM movie. Keep in mind that with many of these projects, the filters and exact procedures won't usually apply to your own projects -- there aren't any "one-size-fits-all" solutions in video work. The examples in this project won't tell you how to fix your video. But you'll get an idea what an avs script looks like, how the statements flow, and how they work. You'll notice that some filters or functions are used repeatedly, but with different settings. Besides, the video in the linked project was just too far gone for much real improvement.

Try browsing the images, scripts and explanations in this thread, VirtualDub filters to improve color?, posts #21, #22, #27, and #31. You're welcome to look over the entire thread, if you want.

After the big holiday rush smooths down here in Tennessee, I'll clean and post the scripts I used for the videos I posted earlier. Thanks for your patience.

Thank you for a very useful thread!
http://www.digitalfaq.com/forum/vide...improve-2.html

This should be on Avisynh website "how to get started"! I will try to follow it and get Avisynh installed and configured.

I hope you are having a great holidays!

Sorry for the delay. Holidays are getting to be such chaos nowadays.

Well, take a breath and relax.....Most of this will be brand new. Why there is no one-stop tutorial for this seems odd t me. But it would certainly be one long, long tutorial. At least this is the sort of thing you learn once and just repeat, more or less.

This is the workflow, scripts, and filters I used on the video samples in post #5 (http://www.digitalfaq.com/forum/vide...html#post40666). You can always do things the way you want, and others might get the same results differenly.

Let's start with Daylight.avi. I used two Avisynth scripts, in two steps. The first script makes basic YUV color and levels adjustments, then deinterlaces/denoises, then converts to RGB for VirtualDub filters. The output was saved in Virtualdub to Lagarith lossless YV12. Next, script #2 resizes that output to HD 1280x720, which is also BluRayAVCHD compatible. Why use two steps? Frankly, if I had upscaled in the first script I'd have to hassle with big frames in Virtualdub. I avoid big frames until the end, if I can. The upscale also used 16-bit dithering plugins which use different support files than QTGMC. You could do it all in one script, but running a long script that does a lot of work is slo-o-o-o-ow. And sometimes you want to use two steps because Step 2 might be altered for some reason and it's a chore to run all the steps again from the start just for the last procedure.

The first Avisynth script for Daylight.avi (Step 1):

AviSource("E:\forum\ozshots\Daylight.avi")
ConvertToYV12(interlaced=true):
The first statement opens and decodes the AVI. The path statement "E:\forum\ozshots\Daylight.avi" tells Avisynth that AVI's location in my system. You would have to edit that path statement for your system. AviSource() can open SONY DV because I have that codec in my system. Other formats like MPEG, h264 containers, etc., have other Avisynth functions and plugins to open those formats. I had to use "ConvertToYV12(interlaced=true)" to get plain vanilla YV12 as Avisynth's plugins know it, because SONY's DV codec is DVSD, a different flavor of YUV that stores chroma data in a manner that some Avisynth plugins don't interpret as "YV12". Note that "interlaced=true" has to be included for interlaced video -- otherwise, chroma gets interpreted as progressive and, thus, gets screwed up.

ColorYuv(off_y=-8,cont_u=-40):
The black level and gamma are too high. Basically the video is too bright, off to the right side of a histogram. The brights are clipped, as explained in an earlier post. Unfortunately I don't know how they got that way (Vegas, perhaps, did an sRGB conversion before saving it as SONY DV? I don't know how the sample was made). "off_y=-8" shifts all luma and color values 8 points to the left or dark end, and "cont_y=-40" lowers contrast to keep some of those brights from looking too "hot" when displayed in RGB. Often you would use this to help retrieve some blown-out highlights, but in this case the clipping had already occurred earlier but we'd not want to make it worse.

SmoothLevels(16,0.90,255,16,245,chroma=200,limiter =0,tvrange=true,dither=100,protect=6):
SmoothLevels() is a function in Avisynth's SmoothAdjust plugin. It's a more sophisticated version of Avisynth's built-in Levels() function. It's strength is that it uses parameters that can adjust its operations and uses dithering techniques to avoid banding issues or hard edges on gradients. Facial tones and soft gradations from darker to lighter areas of the face are examples of areas where hard edges and banding can occur during color adjustment or denoising.

The first 5 numbers in the SmoothLevels statement work this way: "16" is the dark level input starting point, specified as RGB 16. "0.90" adjusts gamma: the default is 1.0, but to bring midtones down to a more natural level gamma is adjusted down a bit. "255" represents the limit of bright level input to work with. The next "16" is what we want for dark level output -- in this case, the dark level's bottom was specified as RGB 16 and we want to keep RGB 16 values as-is. "245" is the bright level output target: with the hard bright clipping in this video, the specified "255" input values are gently toned down to RGB 245, or just enough to keep brights in histograms within RGB 16-245. Specifying 240 for bright output was a bit dark, so I used 245 to put a little snap in the brights without overrun into the unsafe bright area. In this case, a very slight amount of overrun wouldn't matter much, because the video is clipped anyway.

Other values in SmoothLevels(): chroma=200 specifies full dithering power for chroma adjustment. Limiter=0 specifies no clamping or crushing at bright or dark extremes. tvrange=true means, of course, to work with the desired RGB 16-235 range for video. dither=100 means do all the dithering you can (which is a bit slower than the default), and protect=6 means to make no adjustments on RGB values of RGB 6 or darker.

SmoothTweak(saturation=1.15):
SmoothTweak() is another function in the SmoothAdjust plugin. It increases color saturation in this somewhat washed-out video and, for video with bright clipping, it helps to add the impression of a bit more dynamic range than is possible with clipping. This function also performs chroma dithering to prevent hard edges on gradients and soft-edged shadows. The default is 1.0. Small saturation values with this plugin can go a long way, so be careful.

AssumeBFF().QTGMC(preset="medium",sharpness=0.7):
Obviously we want to insure that QTGMC knows that the interlaced fields are Bottom Field First (BFF). BFF is actually the default for Avisynth, but obsessive-compulsives like Yours Truly want to be certain about these things. The "medium" preset does some pretty good denoising and anti-aliasing without oversmoothing. The default denoiser in the "medium" preset is dfttest, which helps with macroblocks and DV compression artifacts. The default sharpness is 1.0, but I used 0.7 to avoid oversharpening effects, which are common with DV.

ConvertToRGB32(matrix="Rec601",interlaced=false):
Converts YV12 to RGB for VirtualDub processing. At this point the video is 50fps progressive, not interlaced. "Rec601" is the color matrix being used here for standard definition video.

VirtualDub processing:
While the Avisynth decoded and filtered output is being monitored in VirtualDub, I added some VDub filters to clean up Avisynth's output. Usually you can apply VDub filters on Avisynth output using "full processing mode", unless your script runs so slowly that jockeying back and forth in the video to check filter results puts you into an apoplectic state. In this case, things were going fast enough to make VDub filtration practical during a single run.

The three VDub filters used were gradation curves, ColorMill, and VDub's built-in "Levels". I also added VDub's ColorTools RGB histogram to check the results.

Below: VirtualDub with the ColorMill filter in action! ColorMill uses sliders that affect the image in all colors in three main ranges: darks, midtones, and brights, separately or all at once. In this image, the "Middle Point" is being adjusted upward slightly, from 0 to 2. In RGB, the center of the spectrum is RGB 128. The midpoint slider can raise or lower that target. In this case it's raised just a bit to lend the impression of greater "presence" to the image without affecting darks or brights.
http://www.digitalfaq.com/forum/atta...1&d=1448927688

Below: The VirtualDub "Levels" filter with its histogram activated. The adjustment here is strictly in the darks (left-hand pointer arrow) without affecting mids or brights. This is a very subtle adjustment but it adds a greater impression of depth.
http://www.digitalfaq.com/forum/atta...1&d=1448927742

Below: VDub's gradation curve is used to raise the midtone values just a tiny bit without affecting other parts of the spectrum, yet it also makes the image look brighter. The effects shown in these reduced images are subtle -- easier to see when using the real thing. Here, the RGB curve is also bent a little at the top right to tame the brightest colors above RGB 220. The small "dots" along the curve (diagonal line) are anchor points that hold the other parts of the curve in place.
http://www.digitalfaq.com/forum/atta...1&d=1448927884

Below: RGB histograms for the same frames, showing "before" readings of the original capture (left-hand image), and "after" AVisynth and VirtualDub adjustments (right-hand image). The left-hand histogram of the original video shows elevated blacks and high gamma, with a pink arrow pointing at the way Luma and two of the colors climb up the bright side of the histogram wall (clipping). The "after" histogram shows better darks, more natural midtones, and the clipping tamed and controlled.
http://www.digitalfaq.com/forum/atta...1&d=1448927963

The next steps of resizing and encoding require YV12. In VirtualDub, "full processing mode" was selected for output. Color depth was set to YV12, compression was set to Lagarith YV12. The results were saved this way with "Save AVI..." and given the name "Daylight_01.avi".

STEP 2:
You'll notice a more complicated plugin loading in the script, this time around. This is the code I used for the upscaling step:

dppath="D:\Avisynth 2.5\plugins\AVS26\dither\":
OMG, why is he doing this? First, the dither plugin package uses its own version of some well known Avisynth plugins, as well as some of its own. Some of these plugins have names that are similar to "normal" plugins (like masktools2). You can't keep two plugins with the same name in the same plugin folder. Also, a lot of plugins are seldom used, so why make Avisynth search through a ton of unused plugins to find what it wants? And sometimes you'll devise your own set of special versions for this or that, which could be confusing and chaotic if they're all in the same place.

The default location for Avisynth plugins is in the Avisynth 2.5 or 2.6 program folder in Windows. You can make your own custome-named plugins folder and keep those custom folders wherever you want. I keep them as subfolders in the Avisynth program folder. But you do have to tell Avisynth specifically where those folders are located. Otherwise it looks in "plugins" and, not finding what it wants -- or finding something you didn't want it to find -- AVvsynth just gets stubborn and belches error messages.

Most people have Avisynth in "C:\Program Files\Avisynth 2.5" or "C:\Program Files(x86)\Avisynth 2.5". The Avisynth name might also be 2.6 instead of 2.5, depending on which version of Avisynth you installed and when you installed it. I'm using Avisynth 2.6, which a long time ago was installed earlier in a program folder named "Avisynth 2.5". In fact you can name Avisynth's program folder anything you want during installation, but let's not get so cool that you we can't tell what's going on. My Avisynth stuff is installed on my D: drive as "D:\Avisynth 2.5\" with all of its plugins. Why the D: drive? Did you ever have to re-install Windows? Or what if you should need to do that? Zap, you'd have to replace all your plugins -- if you can find copies of 'em. Avisynth on my D: drive is also backed up on a separate hard drive. The same copy of that folder and its plugins are also installed on the D: drive of another PC.

I have the dither plugins installed in a subfolder at "D:\Avisynth 2.5\plugins\AVS26\dither\". That subfolder is for special Avisynth 2.6 plugins that sometimes conflict with older 2.5 filters. What I can do is specifically point to the plugins I want, which will override the default plugins in the default folder. Avisynth won't even look in the default folder for those specified filters: instead, it will import or load the filters from the location I specify.

The dither package has several plugins. I want to load 5 of them. But I don't want to retype the path statement 5 times. Pain in the neck. Instead, I create a user-defined entity in memory (officially called a "user-defined variable") that I called "dppath". Of course, dppath is short for "dither plugins path" (cute!). I tell Avisynth that the user-created "dppath" contains a string of text characters, and the character string it contains is "D:\Avisynth 2.5\plugins\AVS26\dither\". Note that the closing "\" is also part of that character string. Then I tell Avisynth to join that dppath character string with the name of a plugin using the concatenate symbol ("+").
Thus, the statement
Import(dppath+"Dither.avsi")
becomes interpreted during run time as:
Import("D:\Avisynth 2.5\plugins\AVS26\dither\Dither.avsi")

In Avisynth, .dll's and .avsi's are automatically loaded if they're in the plugins folder. But if you're not using the default folder, you have to explicitly use Import() to load plugins that are text files (.avsi and .avs plugins are text files), and in this case I have to explicitly use LoadPlugin() to load dll's that are not in the default plugins folder.

These statements:

at run time are interpreted as having been typed in this manner:

AviSource("E:\forum\ozshots\Daylight_01.avi"):
AviSource tells Avisynth to load and decode the Daylight_01.avi that I saved with VirtualDub in Step 1. That AVI is losslessly compressed Lagarith YV12.

Dither_convert_8_to_16 ()
Dither_resize16(1280, 720, kernel="spline36", cplace="MPEG2")
DitherPost():
The dither plugin documentation is pretty specific about most procedures, so these statements come pretty much right out of the html doc. Dither_convert_8_to_16() converts the incoming file from the conventional 8-bit data to 16-bit data. The Dither_resize16() function resizes that new version to 1280x720 using Spline36 resize and the color matrix for MPEG2 (that is, the colorspace is YV12 for MPEG2). You can use MPEG2 even if you later encode with h.264. DitherPost() returns the clip to 8-bit data -- or else you wouldn't be able to read it -- or AVisynth would likely crash trying to output what would look like 16-bit garbage.

Why use 16-bit? I don't always use it, but I use it a lot for DV source to avoid banding and other 8-bit resize/color effects such as posterizing. You can read all about it here: Color banding and noise removal (post #3) (http://forum.doom9.org/showpost.php?...59&postcount=3)

ColorMatrix(mode="Rec.601->Rec.709"):
ColorMatrix.dll is an Avisynth plugin that properly converts standard definition Rec.601 color matrices to HD Rec.709. You can also do this with the dither plugin, but it takes too long and usually isn't different. The .dll is in my default plugins folder, so it loads automatically with no help on my part.

The output of Avisynth STEP 2 is saved in VirtualDub using "fast recompress" with Lagarith YV12 for encoding.

You can save template scripts as text files so you don't have to retype all this stuff. I've used the same resizing script so many times it's now just a copy-and-rename job.

One big question: how do you save those Virtualdub filter settings or communicate them to others? It's a chore to tell someone in detail how to set up something like values for gradation curves. You can save its settings as a text file, but you'll see a text string for the settings that would be longer than 256 bytes. You can save VirtualDub settings using "File..." -> "Save processing settings" and give the resulting file a location and name. The file type is .vcf. It's really a plain text file with a .vcf file ending. You can even open it in Notepad and read it (but don't change anything. You'll be sorry). You can reload those filters and settings using "File..." -> "Load processing settings...", point to the saved .vcf file, and voila! As long as you or another user has those same VDub plugins in their VDub folder, the filters and settings will load as desired.

I guess that's enough exhaustion for now, so I'll wait to post details later for the "indoor grain" file. It used a similar script but with extra help for cleaning all that CMOS noise, and more color work.

Hi Sanlyn, I'm totally speachless about such a detailed analysys of my video!
I will try to replicate your steps.

What worried me most:

The sample was shot on Canon DV and captured using Vegas. I thought it just the camera making mistakes in exposure? Do you think Vegas made changes to the files, I thought they are always downloaded exactly as-is, 1 to 1? Should I try to use different program for the same file and see if any difference?

Hopefully your master file were left intact as natively interlaced. Get the data off the tape, and leave the 13gb/hour files on a reliable hard drive. While people say that drives die -- and they do, but nowhere with the frequency suggested -- DV tape is more fragile than drives.

Yep, DivX/XviD (MPEG-4 Part 2) is 2000s.
Modern is H.264 (MPEG-4 Part 10) in MP4 or MKV wrapper.

good = de-noise
good = convert to progressive, doubling the frame rate (or use QTGMC and just deinterlace)
useless in software = up-scale the resolution (let the HDTV do it)
good = encode with H264

WDTV was always shaky, but it's the best box around. A higher-end Samsung Blu-ray player is another option. I actually prefer the BD for watching MP4. The WDTV Live (not regular) is what I use for DVD ISOs.

I'm not fond of NLEs for basic work like this. They really suck at interlace handling. Avisynth + VirtualDub is what you want for your tasks. Keep the NLE for editing before or after your conversions and clean-up.

x264vfw is a PITA. It's too buggy. Last I knew, it also had a huge delay from the official x264, which was itself buggy (crashes a lot for no reason) and continuously adding features. x264vfw works, but I rarely use it. I prefer Avidemux or MainConcept for the encoding. I'd rather encode out lossless from VuirtualDub, and let the encoder chew on it without worrying about losing VirtualDub or Avisynth work.

MC SDK (Adobe, etc) isn't bad. It's usually the people using it choosing the wrong bitrate or settings. The main complaint is that files are large. So yes, x264 can get small files. But arguably MainConcept looks superior to x264 when quality really matters (ie, studios, not home users). I used MC for work, x264 via Avidemux for play.

AAC needs to be 96mbps minimum, 44.1kHz minimum. That sounds fine, assuming the encoder is good. That's a spec insisted on by my last studio gig. Sometimes, for personal stuff, I use 128kbps AAC, but that's me purposely being overkill.

AC3 is licensed, and they started to crack down on unlicensed decoders in 2013-2014. Don't use it, else it may not play on some devices. AAC is open source. AC3 is fine for DVD, but lousy for streaming.

sanlyn seems to be giving you a crash course in Avisynth. Long post. :salute:

Yes, I’m leaving the original DV files intact – they are all on mirror RAID + a backup.
I have finished capturing of 47 tapes – big job :eek:
Now I just want to play them conveniently on WDTV. The new model and latest firmware still can’t handle DV files, and still displays combing on interlaced files. So I’m upscaling to 50fps.
I also have to resize – while I can change aspect ratio every time I play a file, it’s just too much clicking.

I’m using batch mode, without de-noise filters for now, and I see scary messages on my test “daylight.avi” file – see encoding.log
Is that dropped frames? Should I try to re-capture using different program?
[getNextFrameAs] Audio thread stopped, no more data
[encode] [x264] Cannot get next image
[encode] Flushing delayed frames

[nextPicture] Cannot get next picture. Last segment
[getNextFrameAs] [Bridge] Base did not get an image
[refillPacketBuffer] Consumed all data from this audio segment
[OpenDmlDemuxer] Index Exceeded 346/346
[getPacket] AudioGetPacket failed, audioSegment=0
[getPacket] ..and this is the last segment
[DecodeNextPicture] getFrame failed for frame 222
[nextPictureInternal] Next picture failed
[DecodeNextPicture] getFrame failed for frame 223
[nextPictureInternal] Next picture failed
[DecodeNextPicture] getFrame failed for frame 224
[nextPictureInternal] Next picture failed
[DecodeNextPicture] getFrame failed for frame 225

@lordsmurf, thanks for the input. Always new insights.
I agree 1000% with that one. I made two versions of the Indoor AVI, 576p and 720p. I'm not sure why so many users feel the need to upscale standard def to High Def. Maybe a misunderstanding of some sort. The 576p isn't resized, to illustrate that a playback setup will upscale anyway. Upsizing SD requires a lot of work and careful methods to overcome the problem of interpolation errors. Every NLE I've ever used makes a mess of it. The #2 script shouldn't have been necessary, as a proper 576p will look just like 720p when played but without the extra interpolations needed to upscale in software first. Resizing, whether up or down, always entails some level of loss.

Just a slight correction: converting 25fps to 50fps isn't "upscaling". The 576p and the 720p are both 50fps progressive videos. The 720p is upscaled, the 576p isn't.

Whatever you're using for playback should output the proper aspect ratio. The 576p was encoded for a 16:9 display aspect ratio. If you have to click buttons to make anamorphic video play properly, something's amiss. DVD at 16:9 and retail BluRay standard definition (yes, BluRay is often SD, not HD) encoded for 16:9, as well as MP4/MKV, etc., encoded for a 16:9 DAR, should display as 16:9.

I don't know how Vegas captures AVI. I've always seen DV transferred 1:1, not recorded or re-encoded for capture.

Some time back I had Vegas Pro v9 on a PC but after a year I just didn't use it any more. It's possible that the bright clamping on the Daylight video was done in Vegas, either during capture or during copy, but I don't know. When I used Vegas it was a problem with VHS captures, as it didn't convert YUY2 to RGB so well for color work. Since then I've used After Effects for a timeline NLE and its ColorFinesse plugin, but I have to input lossless media from Avisynth because AE didn't convert properly either, and it wasn't up to the task of repairing VHS glitches. AE has many priceless features, but I use it only with lossless input/output.

Below, the same image in post #5 with the YUV histogram of a frame from the original Daylight.avi. I've added a pink arrow to the upper right corner of the histogram. Note that the white graph (luma) has a sharp, straight upward spike at the right-hand edge. The luma values are well within the desired range of RGB 16-235, indicated by the darker shaded areas along the histogram's side borders. The right-hand spike indicates hard clipping of brights. Clipping means that any data above a certain point has been clamped to a single value. If the original bright end clipping point was at RGB 200, then no data beyond RGB 200 exists. It can't be recreated. You can lower the brights if you want, but no data will be retrieved; anything that was originally brighter than RGB 200 was clamped to RGB 200. The lowered brights will simply be darker, but its details won't change or expand to the original details that were brighter than RGB 200. You can see the effects of clipping in the lost detail in clothing highlights and the mild hot spot on the girl's forehead.
http://www.digitalfaq.com/forum/atta...1&d=1448979744

If you try to "brighten" those burned-out highlights, they'll just "glow" on the screen but won't reveal any more detail. If hard clipping had not occurred, you would still have a brightness range in the original video that included values at and even above RGB 255. Correcting in YUV with Avisynth, much of that detail could have been retrieved and interpolated into usable values brighter than the clipping point shown here. So you would be able to achieve more dynamic range at the bright end rather than use filtering tricks to make the image look more crisp than it really is.

I'm still working on some detail for the Indoor AVI, which posed some really interesting problems. But I have a PC repair customer this morning that's slowing things down. Will post more later.

The original "daylight" is displayed here in Vegas 13 per way.

Avisynth is here the rescue, Sony Vegas works internally only in RGB

Yes, I'm sorry this must be very basic question but I can't get this right!
In Avideumux, I have:
Video output: Mpeg4 AVC (x264)
Configure -> Output 1 -> Predefined Aspect Ratio 64:45 (PAL 16:9)

The output file is still 4:3 - I can post it here...
What is wrong? How do I setup 16:9 aspect ratio?

I prefer not to scale if I don't have to...

This is what's in the script. I can see "vui.sar_height=45", "vui.sar_width=64",

adm.videoCodec("x264", "useAdvancedConfiguration=True", "general.params=AQ=22", "general.threads=0", "general.preset=ultrafast", "general.tuning=film", "general.profile=baseline", "general.fast_decode=False", "general.zero_latency=False"
, "general.fast_first_pass=True", "level=-1", "vui.sar_height=45", "vui.sar_width=64", "MaxRefFrames=3", "MinIdr=25", "MaxIdr=250", "i_scenecut_threshold=40", "intra_refresh=False", "MaxBFrame=3", "i_bframe_adaptive=1"
, "i_bframe_bias=0", "i_bframe_pyramid=2", "b_deblocking_filter=True", "i_deblocking_filter_alphac0=0", "i_deblocking_filter_beta=0", "cabac=True", "interlaced=False", "constrained_intra=False", "tff=True"
, "fake_interlaced=False", "analyze.b_8x8=True", "analyze.b_i4x4=True", "analyze.b_i8x8=True", "analyze.b_p8x8=True", "analyze.b_p16x16=False", "analyze.b_b16x16=False", "analyze.weighted_pred=2", "analyze.weighted_bipred=True"
, "analyze.direct_mv_pred=1", "analyze.chroma_offset=0", "analyze.me_method=1", "analyze.me_range=16", "analyze.mv_range=-1", "analyze.mv_range_thread=-1", "analyze.subpel_refine=7", "analyze.chroma_me=True"
, "analyze.mixed_references=True", "analyze.trellis=1", "analyze.psy_rd=1.000000", "analyze.psy_trellis=0.000000", "analyze.fast_pskip=True", "analyze.dct_decimate=True", "analyze.noise_reduction=0", "analyze.psy=True"
, "analyze.intra_luma=11", "analyze.inter_luma=21", "ratecontrol.rc_method=0", "ratecontrol.qp_constant=0", "ratecontrol.qp_min=10", "ratecontrol.qp_max=51", "ratecontrol.qp_step=4", "ratecontrol.bitrate=0"
, "ratecontrol.rate_tolerance=1.000000", "ratecontrol.vbv_max_bitrate=0", "ratecontrol.vbv_buffer_size=0", "ratecontrol.vbv_buffer_init=0", "ratecontrol.ip_factor=1.400000", "ratecontrol.pb_factor=1.300000"
, "ratecontrol.aq_mode=1", "ratecontrol.aq_strength=1.000000", "ratecontrol.mb_tree=True", "ratecontrol.lookahead=40")

Hello
I sanlyns readjusted steps.
I have the Canopus DV Enc only installed here.
So had to install the Sony Enc.

Step 1 but with Avisynth_MT [MT = Multitasking]...=23-24 fps
everything okay.

Step 2 of sanlyn
I have in line "ColorMatrix ..... put a # at the beginning
---------------------------

Addendum.
Brain turned ... ColorMatrix.dll lacked in Plugins folder.
Now it works

Hi All, before I get onto deep waters of restoration, I want to make sure at least I have captured the video correctly. I have downloaded the same "daylight" video using STOIK CAPTURE instead of Vegas. This Stoik unfortunately does not recognize separate shots and capture the whole tape in a single file. So I've captured a bit longer shot.
What surprised me: Vegas captured 8 second file with 29.4 MB
Stoik capture for 12 seconds is whooping 246 MB! This goes beyond my understanding: I thought DV capture is just copying a file from A to B? Both files plays on PC and I can't spot much difference in quality.
If anyone have patience to download the 246mb file, its here: http://www.ozshots.com/daylight_stoik.avi

I should also say it's not Vegas 9, it's actually a separate exe file called "vidcap 6.0". The camera is Canon MVX430E
Thank you so much for helping me!

I can not help you much.
your Sony DV-AVI is compressed.
The Stoik is therefore uncompressed RGB.

I work only once every leap year times with Stoik.
But you can because the settings, select which codec, see picture

I'm totally confused... I always thought 1hour DV Tape holds about 13GB of data, and that's what Vegas is capturing. Stoik is uncompressing compressed data?

Yes, on mini-DV.
On large DV tapes course goes even more.

From DV tapes I read 1: 1 directly into Edius or take the free WinDV a.
I see differences only in the header.

Vegas I only now and then, I have been working with Avisynth / VDub and Edius.

What are you doing in Vegas ... cropping, so adjust movie length or?
-----------------------

In Vegas, it is possible to encode DV-AVI.
See image

Yes, miniDV = 13gb/hour

A good idea. You've already seen how glitches during capture cause trouble later. I've always thought DV was copied 1:1 via Firewire and something like WinDV, not captured.

After many delays (and 2 more cups of coffee), here's the workflow and details I used for the Indoor grain.avi. This required some tricky denoising and color work. But you'll see that I used the same filters as with the Daylight avi, but with some help from others.

Here is the script:

Import("D:\Avisynth 2.5\plugins\LimitedSharpenFaster.avs")
LimitedSharpenFaster is stored as an .avs file in my Avisynth plugins, so it has to be imported as a script. As an .avs filter, it won't load automatically. Why did I save it as .avs instead of auto-loading avsi? Because this plugin has more than one version, but with pretty much the same internal code in each.

dppath="D:\Avisynth 2.5\plugins\AVS26\dither\"
Import(dppath+"Dither.avs")
Import(dppath+"mt_xxpand_multi.avs")
LoadPlugin(dppath+"avstp.dll")
LoadPlugin(dppath+"dither.dll")
LoadPlugin(dppath+"masktools2.dll")
LoadPlugin(dppath+"mvtools2.dll")
The dither plugins will be needed here. As mentioned earlier, there's a lot of grainy junk to be removed, but doing so also removes the grain that defined fine gradations and other small details. Later statements will compensate for that. Again, by using a variable to define the path character string, the above statements are interpreted at run time to read this way:

Quote:

Import("D:\Avisynth 2.5\plugins\AVS26\dither\Dither.avs") Import("D:\Avisynth 2.5\plugins\AVS26\dither\mt_xxpand_multi.avs") LoadPlugin("D:\Avisynth 2.5\plugins\AVS26\dither\avstp.dll") LoadPlugin("D:\Avisynth 2.5\plugins\AVS26\dither\dither.dll") LoadPlugin("D:\Avisynth 2.5\plugins\AVS26\dither\masktools2.dll") LoadPlugin("D:\Avisynth 2.5\plugins\AVS26\dither\mvtools2.dll")

If you want, you can hard-code that path letter by letter. But usually manual typing like this involves typos, which are headaches.

AviSource("E:\forum\ozshots\Indoor grain.avi")
ConvertToYV12(interlaced=true)
AviSource() opens the DV file as usual, and ConvertToYV12() converts SONY's version of 4:2:0 to the format most Avisynth filters were designed for.

AssumeBFF().QTGMC(sharpness=0.7,EZDenoise=2)
This statement sets the interlaced field order (BFF) and runs QTGMC for deinterlacing. QTGMC denoisies, too, but it can't handle every kind of noise. Here, we're aiming for ragged edges, interlace combing, and clumpy CMOS grain. Because not all of the grain will be removed with this one step, sharpnbess=0.7 avoids oversharpening. EZDenoise=2 is a special QTGMC value which in this case overrides the default denoising for something more powerful. You can use stronger values, but it would look over filtered.

source=last
super = source.MSuper(pel=2, sharp=1)
backward_vec2 = MAnalyse(super, isb = true, delta = 2, blksize=8, overlap=4, dct=0)
backward_vec1 = MAnalyse(super, isb = true, delta = 1, blksize=8, overlap=4, dct=0)
forward_vec1 = MAnalyse(super, isb = false, delta = 1, blksize=8, overlap=4, dct=0)
forward_vec2 = MAnalyse(super, isb = false, delta = 2, blksize=8, overlap=4, dct=0)
MDegrain2(source,super, backward_vec1,forward_vec1,backward_vec2,forward_v ec2,thSAD=400)
This second denoising routine is pretty much a standby with Avisynth. I didn't make up this code myself. It's copied right out of the mvtools documentation for its MDegrain2 function, word for word. Note something special here: "source=last" tells Avisynth that the "last" result from the lines before entering this routine is to be known as "source". Those previous results will be referred to twice in this routine.

The first time "source" is pointed to is in the second line of the code, which is "super = source.MSuper(pel=2, sharp=1)". This line tells the routine to use the "source" named earlier and do something to it, and then call the result "super". Nice thing here is that you don't really have to know why it's called "super", just use it the way the filter's designer set it up.

Next, the code creates some "forward" and "backward" entities. What the code does is make a digital motion schematic of the two frames preceding the current frame (look 2 frames backward), and make digital motion schematics of the two frames following the current frame (look 2 frames forward).

Finally, the MDegrain2() function is used to compare the noise and motion patterns in the "source" with the noise and motion patterns in "super" and the "forward" and "backward" guys, then decide what's noise and what isn't noise, and clean up the current frame using all that info. Complicated? Yes. Slow? Well, yes. Effective? Yep, and it does it without destroying a lot of wanted detail. Many people do this in two steps. Being in a hurry, I did it all in the same script. The script ran at about 4 frames per second. Good work takes time.

TemporalSoften(4,4,8,15,2)
This is a built-in Avisynth function, used as recommended in the Avisynth doc. What remains after all of the above cleanup is still some flickering, simmering grunge, seen mainly in the walls as the video plays. It smooths that flickering, and also helps smooth hard edges in those delicate transitions you see in the skin shadows and highlights. TemporalSoften is a big favorite.

GradFun3(thr=0.6,mask=0)
GradFun3() is an anti-banding, anti-block function in the dither plugin package that uses dithering to soften hard edges in gradient areas, like skin shadows and walls. Now that I've removed much of the grain that defined smooth transitions, I have to repair that removal with something that makes those edges smooth again. GradFun3 also adds some very fine grain to mask transition edges. The "thr" (i.e, threshold) value determines the filter's strength. The default is 0.3 (I think), but 0.6 seemed work well.

LimitedSharpenFaster(strength=75)
Let's sharpen the results that might have been softened too much. LimitedShartpenFaster (aka "LSF") is another old standby that tries to sharpen without adding edge artifacts such as halos. A little more grain will be added in the next line, so sharpen first before adding any more film-like grain.

AddGrainC(1.0,1.0)
AddGrainC is one of QTGMC's support files used to avoid an over filtered, waxy look. It's also a filter in its own right that you can used by itself. The two "1.0" parameters control the amount of grain (0.1 for luma, and a second 0.1 for chroma). This would be grain so fine that it's hardly visible, even finer than movie film grain. 100% of that CMNOS noise hasn't been removed -- if we cleaned all of it, you wouldn't have muchy video left. So add some fine grain to close the gap between bigger clumps of CMOS noise. Adding too much would of course be noisy, as well as fuzzy.

I know, it seems bizarre to remove a ton of noise and then add some back, but this is controlled and purposeful noise -- not randomly dancing junk.

ConvertToRGB32(matrix="Rec6-1",interlaced=false)
This is for Virtualdub RGB filtering that follows. The video is now 50fps progressive, so "interlaced=false". Note that the script doesn't include any levels or color adjustment. That's OK, since levels here are safe. But the color needs fixing and overall brightness should be expanded upward to make the scene look more natural.

return last
This instruction tells Avisynth to output the results of the last thing the script did. The reason we need to specify that Avisynth should "return the last result" is because the script has named a bunch of other things that are actually different versions that were being processed. Some of things that were named are "source", "super", "backward_vec1", etc. Those entities are still named in memory -- Avisynth has to know exactly which version of the processing we want. What we want retruned is the "last" thing that was done.

Should you decide to use any of this stuff but have trouble getting or loading the pluigins, just ask. The forum and I have zip'd packages for these filters.

You could feed this script directly to VirtualDub and load VDub filters on top of it. But, really, it runs too slow for that to be practical. I elected to save the results of the script as a Lagarith RGB working file, which I can delete later. Then I opened that RGB file in VirtualDub. I'll cover that in the next post.

below is an unprocessed frame image from the original indoor avi. The CMOS noise doesn't look so bad here, although the image is rather fuzzy. But during play, the noise "moves" and bristles, and looks worse. There is also some chroma noise that can go unnoticed -- until you start removing the grain, when the chroma stains stand out and flutter.
http://www.digitalfaq.com/forum/atta...1&d=1449082249

Below, a 2X blowup of a portion of the walls from the above image. With all the grain it's difficult to see at first, but the chroma noise is magenta and cyan stains in bright and dark areas. Most degrainers have little effect on this kind of noise.
http://www.digitalfaq.com/forum/atta...1&d=1449082288

Below, the same area after denoising and color correction. The filter for the chroma stains was VirtualDub's Camcorder Color Denoise (aka "CCD").
http://www.digitalfaq.com/forum/atta...1&d=1449082338

Below are YUV (left) and RGB (right) histograms of a typical frame from the original indoors avi. Black levels are OK, but the scene lacks bright values beyond the midtones and looks rather grim and lifeless. The scene is also too yellow, thanks to indoor lighting. We don't want to make this scene look like bright daylight (that would look too artificial). But it would be nice to not have pumpkin colored skin and to have a you-are-there feeling to it.
http://www.digitalfaq.com/forum/atta...1&d=1449082431

To spruce up levels and colors, three VDub filters were used: Camcorder Color Denoise and two color filters, gradation curves and ColorMill. The CoilorTools histogram and an external pixel value sampler were used to monitor the results. The settings were saved in a .vcf file.

You don't need images of all the filter settings (they would fill several web pages), but the image below is screen shots of two of the gradation curve settings that were used. These show corrections for Green and Blue, mostly at the bright end. The corrections for brightness and Red are too minor to mention, though they do make a visible difference.

The green correction (left panel) is mostly at the bright end. The Blue correction (right panel) is more extensive, again mostly to extend the brighter part of the image. Note that when correcting RGB, adding or subtracting color also increases or decreases brightness at the same time, because brightness values and color values in RGB are stored in the same pixel. Brightness and color are stored separately in YUV. Also below you'll see the resulting RGB histogram for all of the filtering corrections made. The overall balance is still slightly warm to convey the look of indoor lighting.
http://www.digitalfaq.com/forum/atta...1&d=1449082521

By adjusting the diagonal line in this filter, you can correct specific color and brightness ranges without affecting other values. In this case, the diagonal line is adjusted for a smooth transition of brightness and color from the dark end (the bottom of the line) to the brights (the top of the line). Moving any part of the diagonal line to the left is an increase in values. Movement to the left is a decrease. A large or small portion of the line can be changed without affecting other parts of the line. The small "circles" are anchor points to hold parts of the line in place -- otherwise, the line would automatically spread into a "curve", which is why the filter is called a curves filter. There are dozens of free Photoshop and Vegas websites that show how to use gradation curves.

The filtered version was saved out of VirtualDub as Lagarith YV12 for encoding. I imported that YV12 file into TMPGenc Mastering Works for encoding -- and, being obsessive, I added a little more color and levels correction tweaks using some of TMPGenc's YUV filters collection. The filters can also be set to work in RGB and other colorspaces.
http://www.digitalfaq.com/forum/atta...1&d=1449082599

Notice in this image that the color of my desktop is RGB32 dark gray, almost black, to avoid distractions when working with video.

The file was encoded with the x264 encoder as 720x576 PAL 50fps progressive, with a 16:9 display aspect ratio.

Hope the capture problems are solved soon. Users more familiar with different DV capture methods and software should be able to clarify matters. The Firewire method is the only one I'm familiar with.

I will re-capture again using WinDV and post it here.
I was under impression, that Vegas does exactly 1:1 read from the tape.

Looks like there is a bug with aspect ratio in Avidemux 2.6 so I will try 2.5...

http://avidemux.org/smif/index.php?topic=10970.0

If you have to get a PCI Firewire adapter card, don't get one that has a VIA chipset. I understand that Adaptec IEEE 1394 PCI adapter cards are the proper type.