ConvertToYV12 in Avisynth: Rec601, Rec709, PC.601, PC.709, or Average?

[CZbwoi]

I'm in my last step before I start exporting and I ran into a tricky problem, these options. I find that Rec709 and PC.709 look the best, but I need other opinions and the real answer. Here they are compared to what I'm frameserving out of Vegas:

Rec601:




Rec709:




PC.601:




PC.709:




Average:




What is the best choice here and what does it all mean? From what I learned, Rec is about what is displayed on TVs (or just older tube TVs?), PC is a wider full range for the modern day since our devices evolved. These videos will be played on phones, computers *and* TVs via USB drive or HDMI cord connecting a laptop to a TV. So taking all that into consideration, what do I do? Does Rec601/709 still matter if we're displaying these on a TV somehow, or did the color range get expanded on all modern widescreen TVs making that selection obsolete? And are the 709 picks slightly better than the 601 picks due to its bigger number, more bang for your buck type of thing?

[_Al_]

Something discouraging first. You will never get it like original if frame serving out of Vegas and using RGB, not even YUY2, there is either color going to be a bit off or whites get into illegal values a bit. And you chose correct color in your example, red, that color should be checked.
Closest to the original seems to be: convertToYV12(interlaced=true, matrix="PC.709") , where I get the same color because video is HD, but whites go closer to superwhites (that is why is important to not overblow them while shooting in the first place), but still it seems to be the closest to the original you can get frame serving. You want to get it 100% correct, like original, export lossless intermediate to be perfect (and even then I'm not sure, because I did it only couple of times and did not check levels and color pretty much).

Vegas could interpret your clip a bit different, it has habits to do that for lossless clips. Sony level effect comes in handy then (Computer RGB to Studio RGB or Studio RGB to Computer RGB). For example Think of that Studio RGB to Computer RGB effect as using matrix="PC.709" in Avisynth.

Another advice is using Avisynth script to compare original clip and frame serving clip. Something like:

a=avisource("Vegas_frame_server.avi").convertToYV12(interlaced=true, matrix="PC.709").subtitle("vegas").histogram()
LoadPlugin("C:\tools\dgindex\DGDecode.dll")                                        
b=MPEG2Source("F:\camcorder\eventX\original.clip.d2v").AssumeTFF().subtitle("original").histogram()
interleave(a,b)

because histogram is a must to see, to check your levels and you have to interleave images interleaving frames not compare them on screen next to each other, because screen can play tricks on you. You have a bright window on your left and everything will be brighter on the left on the screen, or background on the left is different etc. Or you use two different players that would treat videos differently while comparing. I know funny stuff, but mostly true. So load your original into Avisynth script (I had to use dgindex because using HDV video) load frame serving avi and then drop script into MPC-HC , stop playback and use that one step function, viewing frames, there is a button for it in MPC-HC gui at the bottom.

[johnmeyer]

Nick Hope has written quite a bit about frameserving out of Vegas and the color issues he encountered. The Vegas forum got screwed up when Sony sold it to Magix, so you may not be able to search there. Try Google.

_Al_ is right that the colors are sometimes off, but in my experience the shift is quite subtle and may be acceptable for you, depending on what you are doing. Put another way, the gains you are getting from whatever you are doing with your AVISynth scripts are probably far greater than the minor losses you may, or may not get from the color conversions.

Here's a Google search that might give you some help:

Nick Hope Posts on Vegas-->AVISynth Frameserving Issues

[CZbwoi]

Thanks for that guys. I tried to look over some of that guy's posts, and while informative I still have some questions.

Let me lay down some information first - for this current project, I'm not doing any color correcting in Avisynth, I'm doing that in Vegas. I'm strictly using it only for QTGMC, the virtualdub plugin ccd.vdf, and Spline36Resize.

The script I'm currently using now started off from people helping me out for color correcting in Avisynth, hence the ConvertToYV12 and whatnot. So with that I have some questions...

* If all I'm doing in Avisynth is for those 3 things, do I still need to ConvertToYV12 at the start and end? Or is none of that necessary if all I'm doing is those 3 things? Basically, is anything in the script dependent on YV12 being around? Or is that the video format most people typically end a project with, as that's better than RGB24/32 when displayed?

* I'm currently frameserving out of Vegas in RGB24, is it better to frameserve 32? Is YUY2 better than both or would make more sense to use?

* When I import a clip into Vegas, does it change the native video format of the file into what Vegas uses (while changing what the picture is displayed as), like into RGB24 or 32? Is this the case with only Vegas or does every NLE have their own as well?

* If this is not the case, does it matter how I frameserve it out of Vegas, or what is preferred?

* Is it smart to just frameserve out of Vegas as RGB32, apply the 3 things I want (assuming they work without ConvertToYV12), and save the script as is or is that bound to fail with some consequences or minor side effects I don't know of?

[remanyao]

Your eyes will tell you...

[jagabo]

Why don't you just test your workflow with standard colorbars and levels test patterns? That will easily tell you which matrix to use.

I don't use Vegas but from what I've read, what it does to video sometimes varies depending on the source -- the container and the codec.

[_Al_]

Use ConvertToYV12() before QTGMC because QTGMC needs YV12 or YUY2 video. But you use VirtualDub plugin which needs to be RGB so YOur decision. Perhaps put VD plugin before QTGMC and conversion is in between.

Vegas uses RGB internally , so if you frame serve YUY2 you have YUV > RGB >YUV right there anyway, so why not export RGB and use converttoYV12() in Avisynth. You want your delivery video to be in YUV specifically YV12 (marked in avisynth like that) which is 4:2:0 sampling. That is standard for videos to ensure non problematic playback together with non extreme x264 settings while encoding, you do not want too many reference frames, simply moderate settings, possibly preset medium to slow if slower than that always overriding number of reference frames to 4 as maximum.

Vegas can interpret footage differently, regarding levels, hence I mentioned that Sony levels effect where you can fix it right away if that is a case. You can recognize it right away if levels where interpreted wrong if after loading into Vegas you see colors washed out (need Studio RGB to computer RGB applied) or too dark and also over-bright at the same time (need Computer RGB to Studio RGB effect). You find out if that is your case. But most likely it is not your problem.

RGB 32 is always better than 24, but can you see the difference? I'd stay with 24. If you color correct 8bit (set in Vegas project properties), everything is rounded up already, why bother with RGB32.

While frame serving interlace, make sure in Vegas project properties is set interlace, setting should mirror your interlace clip. Vegas is frame serving Vegas properties, not Vegas clip properties. So they need to match. And you deinterlace and resize in Avisynth.

If you color correct in Vegas, it complicates things for comparison, because you loose reference point to original, so first compare it with original as I described above, and if everything seems to be ok, you just establish what you do, so only then you color correct in Vegas knowing colors would not be screwd up.

because your video is HD, so PC.709 was used. If colors, especially red are still way off (with no color correction) your video might not be in BT.709. Is your camcorder cheap hardware or some higher end? Then it should be ok. If that is a problem, not sure what to do right now of the bat, perhaps in Avisynth use (could be wrong):
convertToYV12(interlaced=true, matrix="PC.601")
#your script here
LoadPlugin("ColorMatrix.dll")
ColorMatrix(mode="Rec.601->Rec.709",clamp=0)

Last thing, if you down resize anyway, why not to try Yadif resize mode1 (I thing that is double frame rate) instead of QTGMC to speed things up considerably.

[jagabo]

RGB 32 is always better than 24, but can you see the difference?

RGB32 is exactly the same thing as RGB24 as far as the picture is concerned. The extra 8 bits are for the alpha channel.

[_Al_]

Oh, ok, I googled this further to get more depth to it and got this: http://www.animemusicvideos.org/forum/viewtopic.php?t=45357 , not sure if that is correct or some woo-doo, they say that 32bit is faster because of 32bit PC structure (or perhaps 64bit as well) ...

[jagabo]

they say that 32bit is faster because of 32bit PC structure

It can be faster, depending on how the code is written. But it requires 33 percent more memory. But there's no difference in picture quality. Ie, 24 bits is 8 bits red, 8 bits green, and 8 bits blue. 32 bits is 8 bits red, 8 bits green, 8 bits blue, and 8 bits alpha (or something else).

[SameSelf]

* I'm currently frameserving out of Vegas in RGB24, is it better to frameserve 32? Is YUY2 better than both or would make more sense to use?

* When I import a clip into Vegas, does it change the native video format of the file into what Vegas uses (while changing what the picture is displayed as), like into RGB24 or 32? Is this the case with only Vegas or does every NLE have their own as well?

* If this is not the case, does it matter how I frameserve it out of Vegas, or what is preferred?

* Is it smart to just frameserve out of Vegas as RGB32, apply the 3 things I want (assuming they work without ConvertToYV12), and save the script as is or is that bound to fail with some consequences or minor side effects I don't know of?

I can't tell exactly what your workflow is, but to answer your questions:

First, video is never RGB. Get that drilled into your head. Sadly, because we do everything on computers which are natively RGB, people get confused about this easily. Don't let it confuse you.

Second, I am not a Vegas user, but any NLE worth its salt should properly recognize video and operate in Y'CbCr space without some intermediate RGB transform (don't confuse this with the RGB transform to display the timeline on your computer monitor). However, every NLE is slightly different and finding lossless pathways can be a challenge, but you should never frameserve as RGB UNLESS for some strange reason you imported RGB video into Vegas. But then, I would say you screwed up somewhere in your workflow as NLEs aren't designed to operate in RGB space. Typically, the only programs that convert video to RGB internally are compositing programs, like After Effects, because they operate natively in RGB space. I can't speak for freeware like vdub, but I know I have successfully transcoded UYVY content losslessly with it, so I find _AI_'s comment about the vdub plugin expecting RGB surprising.

So bottomline, stay in YUV space and avoid any RGB transformations unless you have specific reasons to do so and really know what you are doing.

[_Al_]

I was under impressions that virtualdub plugins need RGB, I used them in the past. I googled OP's ccd.vdf plugin and got this from txt help file, it also uses RGB color space:

LoadVirtualDubPlugin ("c:\Program Files\VirtualDub\plugins\ccd.vdf", "ccd",0)
ConvertToRGB32(interlaced=true)
ccd(30,1)

[jagabo]

I was under impressions that virtualdub plugins need RGB

Most of them do.

[SameSelf]

Another reason to avoid vdub plugin.

[_Al_]

He exports RGB anyway, why should he avoid it, Vegas uses RGB internally, so logically he uses RGB all the way along only when necessary he switches back to YUV. He needs to do that a bit sooner because of QTGMC, but anyway.

[CZbwoi]

Thanks for all the comments guys, I have to leave the state for the weekend but will pick back up once I'm back and will report here if I have any more questions.

[SameSelf]

He exports RGB anyway, why should he avoid it, Vegas uses RGB internally, so logically he uses RGB all the way along only when necessary he switches back to YUV. He needs to do that a bit sooner because of QTGMC, but anyway.

Are you 100% certain about that? That is a serious knock against Vegas if it can't edit YUV content natively.

[_Al_]

Yes, it is a known fact for a long time. Btw. Is it not After Effect using RGB as well? Do you not use it because of that?

It would work better to not have YUV to RGB while not using any effects, cuts only, but in my book there are far more important things as oppose searching for differences under microscope.

Editing softwares lack CRF encoding, cannot handle resize for interlaced footage well, so YUV-RGB-YUV looks not that bad at all if you start to dig in this. Vegas is also a superb software to work with. I know your threads about lossless video migration between softwares , Avisynth included. After playing with videos for a decent time, this is not important at all to me. That YUV-RGB-YUV upset. You look for a tiny discrepancies that folks would not register at all. But they might notice a bad encoding in low light, gradient, it is obvious. So instead of this almost to perfect original outcome, I'd rather spend a time to encode those parts again using zones if it matters. But most of the time it does not matter anyway. To be sincere and get a genuine response ,a non intrusive approach is much better, you rather use a cellphone in the first place (folks do not mind those, but pull a decent size camera out and they freak out) and highlights and other mess is greatly forgiven. If you are videographer and it matters, using good camcorder, I do not think that YUV-RGB-YUV thing ruins your footage anyway. I used it all the time, was shoooting with VX2000 in SD times and everyone admired the footage and clarity, even low light. Vegas did not ruin anything.

[CZbwoi]

Yep, and the only reason I've been frameserving through Vegas is because Premiere would give me this bad chroma effect: https://forum.videohelp.com/threads/378101-My-Premiere-Pro-exports-give-me-little-black...=1#post2441570

Then the concept of using an NLE for color correcting instead with it's color curves/levels tools which seems easier to me at this point enticed me to keep on using Vegas for that purpose and frameserving out. Also the fact that I could add all the separate clips into Vegas' timeline and frameserve it out as one file to be exported eventually is playing a big part into that, because I don't know if it's possible to do that same thing strictly in Avisynth - make your script reflect on about 13 consecutive clips and join them all together seamlessly in the end, meaning having your Avisynth script in AvsPmod's timeline scroller look like an NLE's containing multiple clips. If that's possible and anyone knows how to do so, I'd appreciate you letting me know.

[poisondeathray]

Yep, and the only reason I've been frameserving through Vegas is because Premiere would give me this bad chroma effect: https://forum.videohelp.com/threads/378101-My-Premiere-Pro-exports-give-me-little-black...=1#post2441570

Then the concept of using an NLE for color correcting instead with it's color curves/levels tools which seems easier to me at this point enticed me to keep on using Vegas for that purpose and frameserving out. Also the fact that I could add all the separate clips into Vegas' timeline and frameserve it out as one file to be exported eventually is playing a big part into that, because I don't know if it's possible to do that same thing strictly in Avisynth - make your script reflect on about 13 consecutive clips and join them all together seamlessly in the end, meaning having your Avisynth script in AvsPmod's timeline scroller look like an NLE's containing multiple clips. If that's possible and anyone knows how to do so, I'd appreciate you letting me know.

I posted a workaround for PP to treat as interlaced for the chroma upsampling - just rename the extension from .mpg to .ts, and it will treat and upsample the chroma as interlaced properly instead of progressive

You can use aligned splice to join clips in avisynth (use "++")

eg. append 3 clips end to end

a = AVISource("video1.avi")
b = AVISource("video2.avi")
c = AVISource("video3.avi")

a ++ b ++ c

[CZbwoi]

Does color correcting in PP and using it do the same thing that Vegas does in the end, turning your work and frameserving it out into RGB, making the switch back to PP meaningless?

You can use aligned splice to join clips in avisynth (use "++")

eg. append 3 clips end to end

I'm getting an error whenever I try this, presumably because I'm trying to import .MPG files into a program called Avisynth...*facepalm*. I think this is the reason, or one of, that led to me to frameserving in the first place. Unless there's another workaround I don't know about that can make my .MPG files open up in Avisynth.

But I guess if PP doesn't work in RGB like Vegas does then that is the way to go again..?

[poisondeathray]

Does color correcting in PP and using it do the same thing that Vegas does in the end, turning your work and frameserving it out into RGB, making the switch back to PP meaningless?

I don't understand this question ?

PP can frameserve too , either with debugmode framesever or advanced frameserver. It can frameserve YUY2, UYVY or RGB . But some people have problems with dmfs or afs - it's unstable for many people. Premiere's timeline can be YUV or RGB.

If you use RGB filters (e.g. some types of color correction filters are RGB only, but others are YUV), the discussion about RGB, YUV is pointless because it's going to RGB after applying an RGB filter. But if you use YUV filters only, then you can stay in YUV .

You can use aligned splice to join clips in avisynth (use "++")

eg. append 3 clips end to end

I'm getting an error whenever I try this, presumably because I'm trying to import .MPG files into a program called Avisynth...*facepalm*. I think this is the reason, or one of, that led to me to frameserving in the first place. Unless there's another workaround I don't know about that can make my .MPG files open up in Avisynth.

But I guess if PP doesn't work in RGB like Vegas does then that is the way to go again..?

The most reliable way to open .mpg mpeg2 video files is to index them with dgindex first, then use mpeg2source("file.2dv") . There are ways to batch index and process if you have many to do. (AVISource is for "AVI" container files)

[CZbwoi]

I don't understand this question ?

If you look through the thread, I was told that Vegas works in RGB internally and turns all your files into that in the process, so if I were to frameserve out to use QTGMC and I'd have to convert to YUY2/YV12, the colors would be slightly off from what I saw in my Vegas workflow, as you see in all these picture examples when I change what PC or Rec version I want to be in. Nothing is exactly what I saw in Vegas, because I went from what Vegas gave me in RGB -> YV12. So that's why I was asking if working in PP is the exact same way as how these people were explaining working in Vegas is, turning everything you do into RGB.

The most reliable way to open .mpg mpeg2 video files is to index them with dgindex first, then use mpeg2source("file.2dv") . (AVISource is for "AVI" container files

I'll try this out when I can soon and if I won't use an NLE anymore.

If you use RGB filters (e.g. some types of color correction filters are RGB only, but others are YUV), the discussion about RGB, YUV is pointless because it's going to RGB after applying an RGB filter. But if you use YUV filters only, then you can stay in YUV .

The only reason for me to do anything in RGB is because as I understood that's what Vegas transforms what you work on by default, and for the vdub plugin ccd.vdf. Is there another plugin I can use in Avisynth in YUY2/YV12 mode that is like ccd.vdf so I don't have to convert to RGB anymore? I need to get rid of these blue and yellow spots some videos have, so if I could get that same effect ccd.vdf pulls off but with a plugin that doesn't require switching to RGB that would be perfect. Because it seems that frameserving out in RGB/switching to RGB in Avisynth is what is slightly throwing these colors off.

[jagabo]

Nothing is exactly what I saw in Vegas, because I went from what Vegas gave me in RGB -> YV12.

Converting from RGB to YV12 doesn't change the colors, it blurs them. If you are seeing significant brightness, hue and/or saturation changes something else is going wrong.

Here's a convenient batch file that uses DgIndex to build an index file and create an AviSynth script to open that file:

"G:\Program Files\DgIndex\DGIndex.exe" -i "%~d1%~p1%~n1%~x1" -o "%~d1%~p1%~n1" -fo 0 -om 2 -exit
echo Mpeg2Source("%~d1%~p1%~n1.d2v", CPU2="ooooxx", Info=3) > "%~1.avs"
echo TFM(d2v="%~d1%~p1%~n1.d2v") >> "%~1.avs"
echo TDecimate() >> "%~1.avs"

Change the path to DgIndex to match where it is on your system. If you put that batch file in your SendTo folder you can right click on an MPG file and select Send To -> NameOfBatchFile.bat. Or you can drag/drop the MPG file onto the batch file anywhere you put it. It will build the index file and avs script in the same folder as the MPG file. You may not need the TFM and TDecimate lines. But you can use them as a guide on how to include any filters you use often.

[SameSelf]

Yes, it is a known fact for a long time. Btw. Is it not After Effect using RGB as well? Do you not use it because of that?

It would work better to not have YUV to RGB while not using any effects, cuts only, but in my book there are far more important things as oppose searching for differences under microscope.

Editing softwares lack CRF encoding, cannot handle resize for interlaced footage well, so YUV-RGB-YUV looks not that bad at all if you start to dig in this. Vegas is also a superb software to work with. I know your threads about lossless video migration between softwares , Avisynth included. After playing with videos for a decent time, this is not important at all to me. That YUV-RGB-YUV upset. You look for a tiny discrepancies that folks would not register at all. But they might notice a bad encoding in low light, gradient, it is obvious. So instead of this almost to perfect original outcome, I'd rather spend a time to encode those parts again using zones if it matters. But most of the time it does not matter anyway. To be sincere and get a genuine response ,a non intrusive approach is much better, you rather use a cellphone in the first place (folks do not mind those, but pull a decent size camera out and they freak out) and highlights and other mess is greatly forgiven. If you are videographer and it matters, using good camcorder, I do not think that YUV-RGB-YUV thing ruins your footage anyway. I used it all the time, was shoooting with VX2000 in SD times and everyone admired the footage and clarity, even low light. Vegas did not ruin anything.

AE is a compositing program, not an NLE. I would have thought you understood the difference. Once again, I stated already that I have never used Vegas, so berating me for not knowing and inquiring lacks civility. You seem to take great offense in my suggestion that Vegas, gasp, may have a weakness. Well, I have news for you. Every program does, so getting pissy over it is a fool's game.

FWIW, I don't make it a habit to hate on Vegas. Avisynth and vdub, though, they are fair game imo. Bwahahahahaha!

[_Al_]

I'm not beating anybody, you are misleading op with inputs, not even knowing software, not realizing that he uses RGB VD plugin AND I do not take any offense because you speak against Vegas, just straightening things up, because it was necessary.

About your derogatory inputs, nothing new. If it makes you bigger go ahead.

[SameSelf]

How am I misleading the OP by suggesting he avoid RGB conversions? He is the one saying he is struggling with color shift issues. Pdr even hinted at such. You seem to be the one who is ignoring that the RGB conversion could be the problem. I am not saying 100% categorically it is. But it is easier to troubleshoot these sort of problems by eliminating unnecessary conversions first or perhaps doing the conversion outside of Vegas first.

[_Al_]

You ask me a question, remember? You got answer. Then you accuse me of answering?

And he basically MUST use RGB while using frame server out of Vegas and using RGB VD plugin in Avisynth.

That thread about chroma is about SD video, this thread he started with HD video, different camcorder, perhaps HD footage from the beginning. If Colors are messed up or badly interpreted by Vegas because of bad flag or something (recorede as 601, I do not know, whatever ), I told him also to check everything in Vegas without color change. The best thing would be the sample, as usually, you know very well without sample it is always guessing, flames, because of folks like you etc.

ok, it is not SD footage, there is some sample also in that thread, hopefully there is some red in it, I test it tomorrow

[_Al_]

ok I tested it, that M2U00012.MPG sample from the other clip, it is SD clip , interlaced, tff, 720x480

created avs where I interleaved that MPG and created avs using frame server from Vegas avi using: ConvertToYV12(interlaced=true, matrix="PC.601").

videos are exactly the same, colors, everything, that script was this:

LoadPlugin("C:\tools\dgindex\DGDecode.dll")                                         
original = MPEG2Source("C:\test\test.d2v").AssumeTFF().subtitle("original").histogram()
Vegas_dmfs = AviSource("C:\Vegas_dmfs.avi").assumetff().ConvertToYV12(interlaced=true, matrix="PC.601").subtitle("Vegas_dmfs").histogram()
interleave(original,Vegas_dmfs)

that is the first step to make sure frame server works, then there is second step, to make sure if encoder works as well, in my case x264 so I also encoded that frame server avi to interlaced video with sar 32:27, no resize and created avisynth script where I interleaved original and that created mp4 encoded by x264

LoadPlugin("C:\tools\dgindex\DGDecode.dll")                                        
original = MPEG2Source("C:\test\test.d2v").AssumeTFF().subtitle("original").histogram()
LoadPlugin("C:\tools\lsmash\Avisynth\LSMASHSource.dll")  
encoded_mp4 = LSMASHVideoSource("C:\test\test Vegas dmfs.mp4").subtitle("encoded_mp4").histogram()  
interleave(original,encoded_mp4)

Colors do not change.
Did not test it with qtgmc. Or ccd.vdf but I would not test that filter, there is just point to be made it frame serves alright and encodes alright also without any filters that might cause problem (if).

[CZbwoi]

I had something long typed out...went away from the computer, clicked Go Advanced so I could use things like the code feature, got hit with a "token expired" message and my whole comment got deleted. Wtf, thanks.


_AL_, when you frameserved out for the test, did it frameserve with the default RGB24 or did you change it? And since being in RGB for ccd.vdf and needing to go to YV12 for QTGMC is altering some of my colors, along with not knowing which Rec or PC to use, is there a camcorder denoise filter like ccd.vdf that doesn't require me to be in RGB? I just need to get rid of some slight blue/yellow spots, are there only vdub filters that can do this?

Converting from RGB to YV12 doesn't change the colors, it blurs them. If you are seeing significant brightness, hue and/or saturation changes something else is going wrong.

When I erased this code from my script, while I frameserved out as YUY2, it would lighten the picture and change it:

LoadVirtualDubPlugin("C:\Users\CZ\Desktop\Video Capture\VirtualDub-1.10.4\plugins32\ccd.vdf","ccd") 
ConvertToRGB32()
ccd(10,0) # threshold (0-100), multithreading (0=off. 1=on)

But that's most likely because I'm starting off in YUY2. Which brings me to this question, if I frameserve out in RGB32 instead of RGB24, is that okay? I don't see the point of going out in 24 when right away I'll be converting to 32 for ccd.vdf (which requires it), until I can figure out if if there's another filter to use besides ccd.vdf to get the same effect in while staying in YV12. Because right now I'm going 24>32>YV12, when I could simply be going 32>YV12. Does frameserving out in 32 instead of 24 make encoding slower in the end because of what you said that it uses 33% more memory, or does all of that get voided out since I end up in YV12 - and in the end would have converted to 32 from 24 for the filter and to YV12 for QTGMC? Basically - does encoding speed or anything change depending on if I frameserve out in 32 instead of 24, even if I'll end up going up to 32 and changing to YV12 in my script had I frameserved out 24?

Here's a convenient batch file that uses DgIndex to build an index file and create an AviSynth script to open that file:

I wouldn't need the part to make a script though - since I'm combining multiple files into one video, I'll only be working in 1 script with the append tool if I were to do it all in avisynth. And if I go back to using avisynth for color correcting, I don't know how I could possibly pull off what I'm doing in Vegas now with it's color curves/levels tools. I don't see anything of the sort in avisynth where I can control the individual color ranges so simply and smoothly up/down in the RGBparade.