Intermediate Codecs for Windows Users

[Jay Bloomfield]

Originally Posted by Keith Paisley

Any other ideas? Has anybody else been able to utilize coreAVC from within Vegas Pro using this method?

I think we discussed this before. Vegas will not use CoreAVC. Vegas only uses Video for Windows codecs and CoreAVC is a DirectShow decoder. No matter what you do, Vegas will always use it's built-in VFW h.264 decoder (mp4plug2.dll). The frameserving option may work, but I've never been able to frame serve properly into Vegas only out of it.

[Keith Paisley]

Originally Posted by Jay Bloomfield

I think we discussed this before. Vegas will not use CoreAVC. Vegas only uses Video for Windows codecs and CoreAVC is a DirectShow decoder. No matter what you do, Vegas will always use it's built-in VFW h.264 decoder (mp4plug2.dll). The frameserving option may work, but I've never been able to frame serve properly into Vegas only out of it.

Well, I managed to make it work. But you have to go into the CoreAVC configuration and set it to output RGB24. Apparently Vegas' AVI plugin just doesn't like YUV.

There's a problem, though; the video you get from this is inverted both vertically and horizontally. That can be fixed with AVISynth and/or Vegas, but in the end the preview frame rate on the timeline and scrubbing takes a pretty major hit, which basically makes this option no more attractive than any of the other alternatives that have been explored.

[Robert Martens]

My apologies for scattering all these instructions across two threads, but that inversion can be avoided by doing the RGB conversion with Avisynth instead of with CoreAVC as described here; the ConvertToSuchandsuch() filters run faster than a FlipVertical(), if I'm not mistaken.

And although I mentioned it in this thread, I find that the "Crop 1088 to 1080" option in CoreAVC doesn't work, at least through Avisynth, so you'll still need to use a crop filter, making the ultimate process as follows:

1.) Download and install the Pismo File Mount Audit Package, the Avisynth Virtual File System plugin, and CoreAVC.
2.) In CoreAVC, turn on Preferred decoder.
3.) Create your script, which is now much simpler:

DirectShowSource("directory/subdirectory/filename.mov").Crop(0,0,1920,1080)
ConvertToRGB24(matrix="Rec709")

Then, if necessary, use the Avisynth Batch Scripter I mentioned in the Vegas thread to create more than one script at a time.

I hope this helps, and again I'm sorry for being all over the place and confusing.

[Mark Hahn]

I've worked with premiere for years now and I'd love to have some codec working decently with my 5D2. I'm willing to re-encode multiple times if the editing is smooth and little quality is lost. I've read this thread slowly several times and it is total Greek to me.

Has anyone on this thread actually gotten any intermediate codec solution that they are happy with? I can't tell from this thread.

[Keith Paisley]

Originally Posted by Robert Martens

My apologies for scattering all these instructions across two threads, but that inversion can be avoided by doing the RGB conversion with Avisynth instead of with CoreAVC as described here; the ConvertToSuchandsuch() filters run faster than a FlipVertical(), if I'm not mistaken.

And although I mentioned it in this thread, I find that the "Crop 1088 to 1080" option in CoreAVC doesn't work, at least through Avisynth, so you'll still need to use a crop filter, making the ultimate process as follows:

1.) Download and install the Pismo File Mount Audit Package, the Avisynth Virtual File System plugin, and CoreAVC.
2.) In CoreAVC, turn on Preferred decoder.
3.) Create your script, which is now much simpler:

DirectShowSource("directory/subdirectory/filename.mov").Crop(0,0,1920,1080)
ConvertToRGB24(matrix="Rec709")

Then, if necessary, use the Avisynth Batch Scripter I mentioned in the Vegas thread to create more than one script at a time.

I hope this helps, and again I'm sorry for being all over the place and confusing.

yes, that helps a lot.

I've observed that this seems may be a pretty good solution if you're only frameserving a single clip, but if your working with multiple clips, the framerate falls through the floor. I put together a test project with 5 different clips being frameserved and there's a LOT of disk thrashing and it's only showing around 0.2fps on the preview timeline (which is down from around 6-8fps for a single clip). I'm guessing the Pismo package is a little resource intensive.

Sigh.... I wish there were some way for Sony to simply add full directshow support...

[Robert Martens]

Yeah, it's not perfect; seems we either use up the time and disk space to render intermediate files so we can have faster playback, or we save the space but can't play fast enough. I don't think it's so much the Pismo system as it is just the nature of frameserving so many files at once. Lots of disk access, and slow playback when doing so many things at the same time. Such is life.

If you'll indulge me, however, I just tried something that may help. I copied the single file I'd been using for testing a few times and mounted all of them via AVFS/PFM. Brought them into a Vegas project and, as you reported, slower than you can imagine (less than half a frame per second). I then browsed the AVFS sample file, however, and saw the No Interleave option. Adding AVFS_AVI_NoInterleave=true to the top (the very top, AVFS options apparently have to be the first lines in a script) of each script bumped my timeline playback--with Preview Quality set to Preview (Auto)--up to between thirteen and fifteen frames per second.

I also tried tweaking the AVFS_ReadAheadFrameCount variable, but it didn't make much positive difference. Setting it to 60 slowed everything to a crawl, dropping it to 7 shaved a few frames per second off the playback speed, and turning it off completely barely did anything. I guess there's a sweet spot in there somewhere for certain types of source footage, but I can't find it. For the moment the only setting that seems to improve performance is the NoInterleave thing.

[Keith Paisley]

Originally Posted by Robert Martens

Yeah, it's not perfect; seems we either use up the time and disk space to render intermediate files so we can have faster playback, or we save the space but can't play fast enough. I don't think it's so much the Pismo system as it is just the nature of frameserving so many files at once. Lots of disk access, and slow playback when doing so many things at the same time. Such is life.

If you'll indulge me, however, I just tried something that may help. I copied the single file I'd been using for testing a few times and mounted all of them via AVFS/PFM. Brought them into a Vegas project and, as you reported, slower than you can imagine (less than half a frame per second). I then browsed the AVFS sample file, however, and saw the No Interleave option. Adding AVFS_AVI_NoInterleave=true to the top (the very top, AVFS options apparently have to be the first lines in a script) of each script bumped my timeline playback--with Preview Quality set to Preview (Auto)--up to between thirteen and fifteen frames per second.

I also tried tweaking the AVFS_ReadAheadFrameCount variable, but it didn't make much positive difference. Setting it to 60 slowed everything to a crawl, dropping it to 7 shaved a few frames per second off the playback speed, and turning it off completely barely did anything. I guess there's a sweet spot in there somewhere for certain types of source footage, but I can't find it. For the moment the only setting that seems to improve performance is the NoInterleave thing.

I will try that and let you know how it goes.

13-15FPS?? That's pretty good. Is this test file you're using from a 5dMkII? I think the best I've seen has been around 8fps, but it's not always steady.

I've been using this (http://www.lunch-productions.de/files/MVI_0082.mov)
as a test clip for most of this stuff since I started fooling around with the colorspace issues, so I've also been using it for most of this testing as well.

[Robert Martens]

I've been using the "Original Quicktime version" file I downloaded from http://www.vimeo.com/2641870 for my fiddling, and the filename's in the same mvi_1234 format with specs that match the MkII's as far as I know, so I think it is a camera file. Correct me if I'm wrong.

In any event, I downloaded the file you referenced, and I see the same behavior as with the darts clip; slower than molasses without the NoInterleave variable, thirteen to fifteen with it, with either a single copy of the file or five of them thrown on the same timeline. The option was added, according to the AVFS readme, to improve compatibility with certain applications, and it seems Vegas is one of those.

[Keith Paisley]

Ok, I tested it a little bit - it doesn't seem to change the preview framerate much for a single clip, BUT the biggest problem I see is that since you're de-interleaving the audio from the video track, it gets out of synch. On the one test clip I've been using, the audio track was shorter by about 1/2 second (0:26:16 vs 0:27:02). That could be problematic on larger projects but not such a big deal if you're using off-camera audio (except maybe in the case you're trying to synch the offcamera audio with the standard track)

[Robert Martens]

I should have known that was too good to be true; there's supposed to be an updated AVFS that includes performance improvements at some point, so keep an eye on the homepage, but until then I guess we'll just have to use the Avisynth setup only for individual clips.

Looks like it's still intermediate renders for Mark II footage, sorry guys.

[Keith Paisley]

Originally Posted by Robert Martens

I've been using the "Original Quicktime version" file I downloaded from Darts at Lark Tavern - Albany, NY - 08, Dec on Vimeo for my fiddling, and the filename's in the same mvi_1234 format with specs that match the MkII's as far as I know, so I think it is a camera file. Correct me if I'm wrong.

In any event, I downloaded the file you referenced, and I see the same behavior as with the darts clip; slower than molasses without the NoInterleave variable, thirteen to fifteen with it, with either a single copy of the file or five of them thrown on the same timeline. The option was added, according to the AVFS readme, to improve compatibility with certain applications, and it seems Vegas is one of those.

13-15fps is better than I've seen yet on my machine. I saw you mention in another thread that you have a Q6600. That's what I'm using too. I wonder why my machine's not pushing those frame rates... What are your project settings?

My Q6600 has 2GB of RAM and an Nvidia 7600GT video card. I have XP and Vista 64, but I have only barely used Vista 64 (in fact, I've only installed it on a test drive), so everything I've talked about here is reference to XP SP3. I have 8GB of RAM (4x2GB) sitting in the drawer - I haven't bothered installing it, but I bought it for when I'm ready to go to Vista 64 full time. I understand there are potentially a bunch of issues with 64-bit software, and having pulled my hair out due to 32/64-bit OS issues in the past on other OS's, I've sort of been loathe to subject myself to the same stuff on Windows. I briefly tried Vegas 8.1 on vista 64 and it did seem a bit quicker but not mind blowingly so.

This Q6600 machine is over 18 months old now so I was considering upgrading to a Core i7 box. I'm pretty sure the Q6600 is more than enough hardware to handle what we need to do, though, so I've resisted the numerous urges to spend on the i7. I'm convinced that all we need is functional software. I'm afraid that the biggest bottleneck we're currently looking at at the moment is VFW on Vegas.

[Robert Martens]

I was up until one thirty last night trying to solve this somehow, but no such luck. Multiple files still cause problems, with the framerate starting out all right but tanking in short order.

Single clips, as I said, I can repeatedly play back at a sustained 13-15 frames per second (takes a second or two to get up to speed, but not too long) over the length of the clip by using the following script:

DirectShowSource("filename.mov",pixel_type="RGB24")
FlipVertical()
Crop(0,0,1920,1080)

Using the pixel_type parameter of DSS isn't normally recommended because apparently some DirectShow filters mess up the conversion, but here it seems like it works, and runs a bit faster than a Convert filter in Avisynth. This script runs at the aforementioned speed with NoInterleave left off, so video and audio stay in sync.

Another quick note, I found that with "Crop 1088 to 1080" turned on in the CoreAVC configuration, using this script, then going into combustion, I ended up with four black lines at the bottom of the picture, despite the image being the correct 1920 by 1080 dimension. The Crop filter in this case should have had no effect if the CoreAVC crop option did what I thought it did, but apparently strange things happen in this circumstance. Explicitly turning the crop option off in the codec configuration dialog allowed the Avisynth script to work the way I'd intended, and combustion saw a proper image, at the correct size, with all the image data and no black pixels.

To finally answer the question you asked, Keith, my Vegas project settings are based on the HD 1080-60i template (not HDV, mind you), but with Field order set to None and framerate set to 30. Why exactly you wouldn't see similar performance with a similar system (I also have two gigs of RAM, XP Service Pack 3, and an even worse graphics card, an AGP 8X 6800GS) I can't be certain, but I do have a SATA II hard drive with a sixteen megabyte cache. With such frequent access of large amounts of data I imagine that might help. Beyond that I have no idea, sorry.

[Keith Paisley]

Originally Posted by Robert Martens

I was up until one thirty last night trying to solve this somehow, but no such luck. Multiple files still cause problems, with the framerate starting out all right but tanking in short order.

Single clips, as I said, I can repeatedly play back at a sustained 13-15 frames per second (takes a second or two to get up to speed, but not too long) over the length of the clip by using the following script:

DirectShowSource("filename.mov",pixel_type="RGB24")
FlipVertical()
Crop(0,0,1920,1080)

Using the pixel_type parameter of DSS isn't normally recommended because apparently some DirectShow filters mess up the conversion, but here it seems like it works, and runs a bit faster than a Convert filter in Avisynth. This script runs at the aforementioned speed with NoInterleave left off, so video and audio stay in sync.

Another quick note, I found that with "Crop 1088 to 1080" turned on in the CoreAVC configuration, using this script, then going into combustion, I ended up with four black lines at the bottom of the picture, despite the image being the correct 1920 by 1080 dimension. The Crop filter in this case should have had no effect if the CoreAVC crop option did what I thought it did, but apparently strange things happen in this circumstance. Explicitly turning the crop option off in the codec configuration dialog allowed the Avisynth script to work the way I'd intended, and combustion saw a proper image, at the correct size, with all the image data and no black pixels.

To finally answer the question you asked, Keith, my Vegas project settings are based on the HD 1080-60i template (not HDV, mind you), but with Field order set to None and framerate set to 30. Why exactly you wouldn't see similar performance with a similar system (I also have two gigs of RAM, XP Service Pack 3, and an even worse graphics card, an AGP 8X 6800GS) I can't be certain, but I do have a SATA II hard drive with a sixteen megabyte cache. With such frequent access of large amounts of data I imagine that might help. Beyond that I have no idea, sorry.

hehe, the first "big" project I tried (still a test, but a bit of a rigorous one just due to the sheer number of clips) and Vegas choked on the re-wrappered files. There are around 35 different files on the timeline so I didn't bother even trying the alternative method you came up with, simply because it would have been a lot more mouse clicks. Basically any time I tried rendering the file using the rewrapped files Vegas crashed. So I finally ended up transcoding everything into 720p using the built-in Cineform HDV codec and it worked beautifully. Watching the preview and editing at a rock solid 30.000 fps is a thing of beauty too. Oh well, it sure would be nice if Neo HD didn't cost $500. I can't see spending that much just to fix something (colorspace glitches) that we shouldn't have to worry about in the first place.

[Robert Martens]

So close, and yet so far. I guess we have our answer.

There's always Lagarith and the older HuffYUV if you don't mind rendering, but I can't get them to play back at full speed.

If neither of those codecs works out for you, then I suppose it's right back to square one.

[Keith Paisley]

Originally Posted by Robert Martens

So close, and yet so far. I guess we have our answer.

There's always Lagarith and the older HuffYUV if you don't mind rendering, but I can't get them to play back at full speed.

If neither of those codecs works out for you, then I suppose it's right back to square one.

So far from what I can tell, Cineform hdv works beautifully. I just wish my workflow weren't so complicated.

At best case, I'd like to edit the videos straight out of the camera. I've been doing it with satisfactory results using DV and HDV for years now. If I can't do that, then I'd like to have a very streamlined, one step process for converting the footage to something I can use to edit (I'm okay with the 720p limitation for now). It seems like Neo HD may be that thing, but $500 seems to be a bit too much to spend to get something that should work properly in the first place (correct colorspace from our 5dMk2 files).