musicvid,

Extremely well summarized! With your okay, I'd like to do a cut-and-paste (except item d) of this summary to be used as an intro to our revised reference webpage.

...Jerry

I find the phrases like "Decodes to and wants to see studio RGB levels" intensely confusing
I don't see what's confusing about it... but that's probably because I wrote it....

A codec consists of an encoder and decoder.
The decoder will decode to either studio or computer RGB levels. It will produce/make either studio or computer RGB levels.
The encoder expects either studio or computer RGB levels. Encoders will encode anything you throw at it, but may or may not produce the right results.

I don't know how else to explain this.

uploading [16,235] to YouTube/Vimeo/Facebook/JW Player
Your premise is flawed.

1a- Suppose you are creating a MPEG-2 or MPEG-4/H.264 file to upload to Youtube. These files do NOT contain RGB values. They contain Y'CbCr values. You simply need to produce a file with legal Y'CbCr values.
You are not uploading RGB values to Youtube... you are typically uploading a format that internally contains Y'CbCr values. You need to get those Y'CbCr values correct. It's not a good idea to say that you need to make your levels 16-235 RGB (e.g. black to 16 RGB, white at 235 RGB) because sometimes this is wrong and inappropriate.

In Vegas, you create proper Y'CbCr levels by feeding the encoder (or encoding codec) the levels it expects/wants to see. Most of the time, the encoder for video formats expects studio RGB levels. (Unfortunately there are exceptions.)

1b- Unfortunately you have no way of measuring these Y'CbCr values unless you have something like a hardware vectorscope with SDI input (at one point in time I had access to one). So perhaps it takes a little faith, but I can tell you that this Y'CbCr thing exists and that you need to get it right, even though you have no way of measuring it directly. And you get it right by giving the encoder / encoding codec what it wants... which is either studio or computer RGB levels.

2- The advice you give on this page:
http://www.bubblevision.com/underwater-video/YouTube-Vimeo-levels-fix.htm
is probably wrong more often than not.

Suppose you are shooting on a video format such as DV or HDV. You throw those clips into the timeline and edit. You render to MPEG-4 for upload to Youtube/whatever.
The default DV and HDV codecs decodes to studio RGB levels. (In 8-bit projects.)
The default MPEG-4 codec expects studio RGB levels. So it is happy.
No conversion from studio <--> computer RGB is necessary.

If you apply any sort of conversion then the levels will be off. But that, unfortunately, is what your article recommends for this common scenario.

What you probably didn't take into account is that you are probably already starting with studio RGB levels / 16-235 RGB levels. The real answer is outlined in the example workflows on my webpage.

3- You are probably getting attached to what you see in Vegas' Video Preview window. (I assume that you are working with video footage, not JPEGs or stills from a still camera.) Vegas' Video Preview window is probably wrong. That is not what your picture should look like.

In my article, I explain how to fix this.
Use an external monitor if your target format is DVD. You really must use an external monitor when delivering for television/video formats, otherwise you will get burned.
If you are outputting for Youtube, then maybe use a Windows Secondary display and check color management and studio RGB in the settings.

-- Most modern PC players, including all web-based delivery tested, expect 16-235 and map it out to 0-255 summarily
No. They expect a clip that conforms to the proper levels for that format.
For Y'CbCr formats, they expect black level at 16 Y' and white at 235 Y'.
For RGB formats... well you usually don't run into them (except Windows Media and JPEGs). But proper black level would be a 0 RGB and white at 255 RGB.

-- Most amateur video, the vast preponderance of what is uploaded to the internet for viewing and / or download, IS NOT SHOT IN A CONTROLLED 16-235 SPACE. This is very important to understand. Much (most?) of it is clipped at 255 already. Recommending that it come back clipped even more as a result of doing nothing is not good advice.
Almost all video cameras will record values above legal white value. Is this stupid? Yes, in my opinion. If you don't like this, then you have to map the 16-255 range to 16-235 range. Explained here:
http://www.glennchan.info/articles/vegas/color-correction/tutorial.htm
Converting from computer to studio RGB is inappropriate (e.g. mapping the 0-255 range to 16-235 range is inappropriate... this will raise your black level. try this while looking at an external monitor via firewire... it is wrong.).

a) Professionals who already conform their levels to REC 709
Rec. 709 versus Rec. 601 is irrelevant. This is just a red herring that people mistakenly perpetuate. Both Rec. 601 and Rec. 709 call for black at 16 Y' and white at 235 Y' (*ok, technically the 10-bit equivalents of that). They call for the same levels...

amateur versus professional
This is irrelevant.

Though almost every other amateur and professional editing software on the market will handle levels conversions for you. Vegas... doesn't.

This is what web-based, browser-based, and desktop-based PC players and services currently send back in the majority of situations. We have seen nothing in hundreds of tests run over nine months with over 30 codec flavors and at least eight players on different OS' that suggests this behavior does not exist, a very few documented exceptions notwithstanding. How best to approach it, especially with video that was shot out of range, or whether to deal with it at all, shall forever remain a matter of personal choice, abilities, and preference, "appropriateness" aside. However, the "render for the codec, not the player" approach was not a reliable solution in my tests. Going back to my sandbox now . . .

Glenn, thank you again for your reply. You know a zillion times more than me about this stuff, and I've learnt a lot from your articles, so it's important for me not to be spreading what you see as mis-information.

The reason that I find "decodes to and wants to see studio RGB levels" confusing is because this, in my mind, implies that there will be no true blacks or whites in the decoded/displayed video, only video between 16-235, which is not what anyone wants. Perhaps I am confusing the DECODING of the video with the DISPLAYING of the video. Or maybe my colorspatially challenged thinking is inverted between squeezing and expanding.

I fully understand that MPEG-2 or MPEG-4/H.264 files do not contain RGB values. That's why I wrote "[16,235]" and not "[16,235] RGB". I know those formats are Y'CbCr, but Y' has an equivalent RGB value between 0 and 255, doesn't it?

I also know about the Vegas video preview window issue which is why, when I'm editing, I have a windows secondary monitor set up with color management and studio RGB in the settings.

I never intended at any point to say that all video should contain values ranging from 16 to 235 and INCLUDING 16 and 235. That would be silly. If that is how you are interpreting my article then I need to rewrite it to avoid that confusion.

Actually I can now see that the article can be improved. My Sony VX2000 (DV) and Z1 (HDV) have black at about 16 and white at about 255. So to recommend a stock C-RGB to S-RGB filter for such video is going to result in blacks never blacker than 16 in Flash Player. Not good. But at the other end I'm not keen on just clipping any highlights >235 as I don't want to lose that detail. I prefer rolling the whites off (i.e. somewhere between clipping and mapping). An awful lot of my footage has useful detail between 235 and 255.

But let's take dSLRs as another example. From what I have read (not seen), they shoot black at 0 and white at 255. If such footage is simply rendered to, for example, Sony AVC and uploaded to the web, it's going to get all its shadows and highlights clipped and have unexpectedly high contrast (at least for the Vegas user). What I am attempting to do with that article is to explain to people how to avoid that happening in a way that doesn't make their eyes glaze over and give them a headache, but at the same time be technically correct. Apparently it fails to do that, so I will revisit it.

Oh and I'm sure musicvid wasn't making a point of Rec.709 VERSUS Rec.601. He well knows that they have the same black and white levels.

EDIT: If anyone is confused where this discussion came from, it started in this thread.

Okay, here's a little Vegas Project I whipped up for comment. The left side has no FXs applied (i.e. it's orginal) . On the right side, I compressed the levels to the 16-235 range (where my old eyes see more detail). Obviously, you want to watch it in fullscreen 720p.



...Jerry

Actually I can now see that the article can be improved. My Sony VX2000 (DV) and Z1 (HDV) have black at about 16 and white at about 255. So to recommend a stock C-RGB to S-RGB filter for such video is going to result in blacks never blacker than 16 in Flash Player. Not good. But at the other end I'm not keen on just clipping any highlights >235 as I don't want to lose that detail. I prefer rolling the whites off (i.e. somewhere between clipping and mapping). An awful lot of my footage has useful detail between 235 and 255.
You can do that with the curve presets I talk about in my color correction article:
http://www.glennchan.info/articles/vegas/color-correction/tutorial.htm

Curve presets:
http://www.glennchan.info/articles/vegas/color-correction/curves-and-secondary-presets2.veg

What I am attempting to do with that article is to explain to people how to avoid that happening in a way that doesn't make their eyes glaze over and give them a headache, but at the same time be technically correct.
I don't think I've done a very good job at that, so hopefully somebody out there does a better job.

What I've tried to do is [1] to list as many codecs as possible, and [2] to point out all the exceptions and gotchas. Unfortunately, there are a lot of exceptions and little things to watch out for. It does not help that Vegas 9 introduced new exceptions with the addition of 32-bit projects and compositing gamma.

This is what I have so far:
http://www.glennchan.info/articles/vegas/v8color/vegas-9-levels.htm
---------------------------

How Vegas works

In Vegas, the levels of all your footage depend on the codec being used.

* Some codecs decode to studio RGB levels. Other codecs decode to computer RGB levels.
* Some codecs will encode files with proper levels only if they receive studio RGB levels. They will produce incorrect files if they aren't getting studio RGB levels. Other codecs expect computer RGB levels.

So this is what you have to do:

1. Convert everything to either studio or computer RGB.
2. When you render your final output, check what sort of levels the codec is expecting. You may need to convert between computer and studio RGB.

The example workflows below cover the most common situations. They also cover most of the 'gotchas' that you can run into.

Example Workflow - 8-Bit Vegas project with mostly video clips

Suppose you have DV, HDV, and JPEG images in your timeline. For 8-bit projects, I recommend converting everything to studio RGB levels.

Looking at the codec table, we see that DV and HDV both decode to studio RGB levels in 8-bit projects. We do not necessarily have to do anything to these media. However, almost all DV and HDV cameras will record illegal superwhite values above 235 RGB. You may wish to apply color correction to these clips to deal with these illegal values.

We see that JPEG images decode to computer RGB levels. Since we want studio RGB levels, we will apply the "computer RGB to studio RGB" Color Corrector (or Levels) FX preset to all our JPEG images. One way to do this is to select JPEG images in the timeline, have the Video FX window open (Alt + 8), and drag the preset from the Video FX window onto selected clips/events on the timeline.

For previewing, the Video Preview window will be inaccurate. From the table above, we see that the Video Preview window expects/wants to see computer RGB levels. However, it is receiving studio RGB levels. So, the image it displays will be incorrect. For accurate monitoring, preview through a DV/firewire device to an external monitor. To send the video to the camera, the material has to be compressed into DV. The default DV codec (the Sony Vegas DV codec) expects studio RGB levels. We are feeding studio RGB levels, so we don't have to do anything.

When rendering the final project, we have to check to see what codec we're rendering to and what levels it expects.

* Suppose we print to tape. Vegas' default DV codec in this case expects studio RGB levels, which is what we are sending it. So we do nothing special in this situation.
* Suppose we want to make a DVD. Vegas' default MPEG-2 codec in this case also expects studio RGB levels, so again we do nothing.
* Suppose we want to render to Quicktime for a web encode. The Quicktime codec used for web streaming probably expects to see computer RGB levels. We will need to convert our studio RGB levels to computer RGB levels. One way of doing this is to nest the Vegas project into another Vegas project. Then, apply a "studio RGB to computer RGB" preset onto the nested project. The reason for using nesting is to avoid using Video Output FX and forgetting to remove the Color Corrector FX when we are done with it.

If the project is for DVD or broadcast output, we should do something about the default background color (0 0 0 RGB). This is an ILLEGAL black and can cause the picture to roll on very old TV sets. To fix this, we add a solid color media generator to make a black of 16 16 16 RGB and put this onto the bottommost track in Vegas. Similarly, when we want to generate white, we need to use 235 235 235 RGB instead of 255 255 255 RGB.

[....]

Example workflow - 32-bit project with mostly video clips

*Life is simpler if you simply use an 8-bit project instead.

I know those formats are Y'CbCr, but Y' has an equivalent RGB value between 0 and 255, doesn't it?
No.

Suppose that when you convert from Y'CbCr to RGB, 16 Y' becomes 0 RGB. Everything below 16 Y' will be clipped. 235 Y' becomes 255 RGB. Everything above 235 Y' will be clipped (!!!!). Because almost all video cameras record image detail above 235 Y', this can be highly undesirable. Because you clipped this information when converting to RGB, you cannot recover this information.

Now if you convert 16 Y' to 16 RGB and 235 Y' to 235 RGB, then you don't have the clipping of important image detail from before (*actually you still have a very small amount of clipping... but we'll ignore that). But, there are some tradeoffs to doing this. e.g. displaying the RGB values directly gives an incorrect image, bit values are wasted on illegal values that shouldn't be displayed, etc.

You can make a case for converting 16 Y' to 0 RGB, and you can make a case for converting 16 Y' to 16 RGB. Some codecs put legal black at 0 RGB, others at 16 RGB.

That's why I wrote "[16,235]" and not "[16,235] RGB".
This is one of my pet peeves... the units matter. [16,235] could refer to Y' or to RGB... two different things.

Okay, here's a little Vegas Project I whipped up for comment. The left side has no FXs applied (i.e. it's orginal) . On the right side, I compressed the levels to the 16-235 range (where my old eyes see more detail). Obviously, you want to watch it in fullscreen 720p.

Here's what I see:

1a- It looks like you applied a computer RGB to studio RGB preset on the right hand side.
1b- The original video looks like it is typical DV or HDV or some format like that. Black is probably around 16 Y' (slightly elevated in this case) and white is at 255 Y', because this is a typical camera that records image detail above legal white level.

2- On the right hand side in the Youtube video, the blacks look milky. They are around 19 RGB and higher. Well above legal black level. Which is not the same as the original video.

I don't think that there is additional detail in the blacks, though it might appear that way if your monitor crushes black detail (or if there is a lot of glare on your monitor).

3- It would be more technically correct to map the 16-255 RGB range to 16-235 RGB in Vegas. (Not doing it is also arguably valid.)

Whether or not that looks better is subjective. Though my rule of thumb is that you should almost always make the black level kiss 0% black / legal black level.

Device/Graphics Card: Desktop, AMD Phenom Quad-core, ATI Graphics
OS: Win 7-64
Firefox 3.6.16
Flash Player 10,2,152,32
240p - white/black
360p - white/black
480p - white/black
720p - white/black

I also checked on my old Sony laptop with Intel dual-core
OS: Win 7-32
Firefox 4.0
Flash Player 10,2,152,32
240p - white/black
360p - white/black
480p - white/black
720p - white/black

This histogram is typical of my Z1 HDV footage in fully auto "run and gun" mode:



A while ago I saved Glenn's curves as presets and modified a couple as well. Here's one I like to use on footage like that.



It clips illegal blacks but keeps some of the detail in the "illegal" highlights instead of just clipping it. The middle part of the curve is very close to the default (straight line corner-to-corner). Obviously in an ideal world it's better to colour correct everything on an event-by-event basis but if we're talking blanket recommendations for AVC web-upload, this is possibly a better one for typical DV/HDV footage than a C-RGB to S-RGB conversion. Can't speak for AVCHD cameras as I've only ever seen a couple of clips from them on the Vegas scopes. Anyone agree? Disagree?

My take on the "blacks already at 16" question is detailed halfway down the previous thread with my "corrected" picture of Nick's boats. It was written in language still photographers will understand. Rolling off the whites just a bit is a further refinement that may or may not be desirable in a given scene, esp. if there is already some brickwall clipping. One could hard cut the blacks also if it is actually destined for broadcast.
http://www.sonycreativesoftware.com/forums/ShowMessage.asp?ForumID=4&MessageID=754538

"But let's take dSLRs as another example. From what I have read (not seen), they shoot black at 0 and white at 255. If such footage is simply rendered to, for example, Sony AVC and uploaded to the web, it's going to get all its shadows and highlights clipped and have unexpectedly high contrast (at least for the Vegas user). "

As far as what people with no knowledge of lighting and exposure typically shoot, this amateur dslr footage I was given pretty much tells the story. Anyone who's been following these threads knows exactly what the simple approach is if it was headed for Youtube or another player (add the Studio RGB levels filter and be done with it).
:

I have read all these posts, and read Glenn's great tutorials, and I think I understand the theory. However, the actual practice of getting things to work is a lot harder.

Here is what I have found.

1. If I encode HDV to MP4 using the MainConcept AVC codec, and then put this MP4 back on the Vegas 10 timeline, I can "A/B" back and forth between the original and the MP4, and the levels and colors look identical. To my simple brain, this seems like a useful test, because it eliminates all the issues of whether some other player or application deals with levels or colorspace issues differently than Vegas.

2. If I frameserve, using YUY2, out of Vegas, and into a variation of Nick's deinterlacing script, and then open that script in Virtualdub and render out using HufYUV, and put the resulting AVI file back onto the Vegas 10 timeline, once again, I get a perfect match in levels. In doing this, I do NOT use any "matrix" or "level" statements in the script.

3. However ... if I do the same thing as #2 and then render using MeGUI, I need to add a "Levels(16, 1, 235, 0, 255, coring=false)" to the AVISynth script and, no matter what other things I do, I get a subtle, but very noticeable, shift in the reds (towards orange) but all other colors appear to stay the same.

All of this probably means that MeGUI is doing bad things which, reluctantly, I have decided is the problem. This does mean, though, that using it as the encoder may cause small levels and color problems that I wouldn't get using another encoder. I'm looking into "--fullrange on" and other MeGUI switches to see if I can fix this, but at present, I think that MeGUI may be a large part of the issue -- at least for me -- in some of these levels issues.

John, it's not MeGUI's fault, it's what it's being fed. The colour changes happen earlier in the chain.

Background 1: When conversions are made between Y'CbCr and RGB, different luma coefficients (or different "matrices") can be used in the calculation. In general Rec.601 coefficients should be used for SD and Rec.709 coefficients should be used for HD. Glenn has an article about this here, and it's explained on Wikipedia here. One aspect I have noticed where 601 is used on footage that should really have 709 used on it is that reds shift towards orange.

Background 2: John is frameserving in YUY2 because he is using AviSynth 2.6 MT (multi-threaded) which doesn't support RGB24 input. He gets better stability using the QTGMC deinterlace script with that AviSynth than other multi-threaded versions of AviSynth (which do support RGB24 input).

OK, so if we are frameserving in RGB in Debugmode Frameserver then no conversion is taking place and colours/levels are unchanged. In that case we can control how the RGB signal gets converted to YV12 in AviSynth by using the matrix option in the ConvertToYV12 statement. See this page. So for example I am using ConvertToYV12(interlaced=true, matrix="PC.709") which tells it to use 709 coefficients and keep the full range. However if we are Frameserving in YUY2 then the matrix option is not supported because there is no RGB>Y'CbCr conversion going on.

As I see it, Vegas Pro 10 "correctly" uses Rec.709 coefficients internally to convert your HDV (Y'CbCr) footage to RGB for display (using compoundplug.dll). However it appears that if Debugmode Frameserver is set to frameserve in YUY2 then it uses Rec.601 coefficients when it converts from Vegas' internal RGB to YUY2. So the colours get shifted (red towards orange etc.). Also the levels get "squeezed" (full range to 16-235 range).

To get the colours correct again, you need to add ColorMatrix to your AviSynth plugins and add this line to your script somewhere:

ColorMatrix(mode="Rec.601->Rec.709")

Depending on whether you took care of levels in Vegas or not, the squeezed 16-235 range may be exactly what you want for YouTube upload so it gets expanded back to full range on playback. But if it isn't then your Levels(16, 1, 235, 0, 255, coring=false) will more or less put the levels back to full range. However that statement scales chroma by the same ratio as luma, [16,235] to [0,255]. Rather we should be scaling chroma from [16,240] to [0,255]. The following line does this accurately and so is preferable to the Levels filter, and no extra DLL required. I've tested it and the match is minutely closer to the original.

ColorYUV(levels="TV->PC")

Here's a finished (single-threaded) script for you:

AVISource("e:\frameserver.avi")

assumetff()

ConvertToYV12(interlaced=true)

ColorMatrix(mode="Rec.601->Rec.709")

LanczosResize(1280,height)

QTGMC( Preset="Very Fast" ).SelectEven()

LanczosResize(width,720)

ColorYUV(levels="TV->PC") #expands levels back to full range

One thing to bear in mind is that MeGUI's preview uses 601 for everything, even HD, but it passes Y'CbCr to x264 untouched. So don't worry about an apparent shift from red to orange etc. in the MeGUI preview.

Also, the fullrange option you mentioned in x264 is a VUI (video usability info) flag in the stream. The VUI settings are not used by the encoder but are merely suggestions to the playback equipment, like metadata. Apparently Adobe Flash Player does respect it, so it has significance for rendering x264 for self-hosting. I would say YouTube probably ignore it when they decode your uploaded video but you never know. Might be worth a test. If they do respect it then this might be an alternative way of controlling levels.

One thing I don't quite understand is why you're not getting a colour shift when you frameserve in YUY2 and render to Huffyuv in Virtualdub. Perhaps aviplug.dll is behaving differently from compoundplug.dll by using Rec.601 to convert back to RGB and so it matches the original levels. Anyway I wouldn't dwell on that. The above script works.

Coming in late to the discussion, because john pointed to it from the debugmode frameserver list.

I have a question for Nick and John regarding Frameserving using YUY2: I had been under the impression that Vegas only outputs to RGB24 to begin with, so YUY2 or RGB32 were not particularly helpful. I think I had read this from some old documentation on the frame server itself, but I can't remember. Maybe I should look at the source code or ask Satish. You guys have any insight into this?

- Erik

I had been under the impression that Vegas only outputs to RGB24 to begin with, so YUY2 or RGB32 were not particularly helpful.I cannot answer this with certainty, but I have the same memory: Vegas is RGB32 natively, so serving out YUY2 involves a conversion. If someone else knows differently, I won't argue, because I'm not 100% certain.

Here's what Satish had to say about that way back in 2004: [url=http://www.sonycreativesoftware.com/forums/showmessage.asp?forumid=4&messageid=301018]

From that I assume that RGB32 is only useful over RGB24 if you have an alpha channel. John found that RGB32 halved his performance compared to RGB24 when doing QTGMC->MeGUI jobs.

YUY2 frameserving only came into our reckoning because the multi-threaded AviSynth 2.6 does not support RGB24. In that workflow John is converting it to YV12 anyway because QTGMC works faster with that than with YUY2.

John found that RGB32 halved his performance compared to RGB24 when doing QTGMC->MeGUI jobs.Just to be clear, I don't think I ever have used the RGB32 output, so that must have been a different John (we have a lot of them in this forum). As for RGB24 vs. YUY2 frameserving, I was quite happy to stick with with RGB24 except that the version of AVISynth I was forced to use in order to get the QTGMC script to quit crashing when using AVISynth in multithreading mode (AVISynth 2.6MT) for some reason eliminated the ability to ingest RGB via the AVISource command. So, I had to serve using YUY2 and then convert to YV12. However, this does introduce some very subtle shifts, but only in saturated reds; everything else is unaffected, including levels. I never did figure out how to stop that behavior, and it is pretty subtle, unlike the whole 0,15,235,255 issue which is quite pronounce and absolutely must be addressed.

Just to be clear, I don't think I ever have used the RGB32 output...

19th March you (or someone impersonating you) wrote me (by email): "...one downside is that AVISynth 2.6 does not read RGB24 output from Satish's Frameserver. It does read RGB32 and YUY2. The conversion to RGB32 cuts performance in half, so that is no good.", which I read to mean you'd tried RGB32 and it's half the speed of RGB24. No?

...this does introduce some very subtle shifts, but only in saturated reds; everything else is unaffected, including levels. I never did figure out how to stop that behavior...

Did ColorMatrix(mode="Rec.601->Rec.709") not work for you then John (see above)?

19th March you (or someone impersonating you) wrote me (by email)Ah, I forgot to check my emails to you, and I'd forgotten that I did try RGB32 after RGB24 failed. Thanks for reminding me.

I've had many problems with the AVISynth 2.6MT version using your QTGMC workflow, and yesterday I went back to 2.58 MT (I forget which build, since there are several people who have built different versions from the same source code). This cures all the color conversion problems I was having. I haven't tried it on a long MeGUI render, so it may not be stable, but I'll forgo using MeGUI in order to avoid the significant quality issues. Since you got into this far further than I did, I assume you know about this:

AVISynth Known Issues

About halfway down that page you'll see a heading: Improper YV12<->YUY2 Conversions. The red shift I have noted several times is actually just one of the many problems. It turns out that not only are the colors shifting, but the chroma plane is shifting position as well, providing all sorts of lovely chroma ghosts. I spent about twenty minutes yesterday, when doing my re-sizing tests, chasing this down. I realize that the link above says that this is an issue in 2.58, but in my experience, the problem was HUGE in the 2.6MT build I was using, and non-existent in my (older) build of 2.58 (I have two different 2.58 versions).

So, unfortunately, this is yet another important variable for your tutorial: the version of AVISynth used matters not only for stability, but also for the quality of the result. I hadn't expected this.