A great codec for linking with VirtualDub

riredale wrote on 5/8/2007, 7:11 PM
Like many of you, I do all my editing in Vegas but then often need to ship some clips over to VirtualDub for special processing. In my case I use DeShaker a lot.

Unfortunately, VDub can't read m2t files. It can read uncompressed, as well as Cineform and HuffYUV formats. For HDV work, uncompressed is just too cumbersome. Though Vegas can build a Cineform clip readable by VDub, that codec cannot be used by VDub to send the clip back to Vegas. I have been too cheap to buy the official Cineform ConnectHD codec(that can be used by VDub to build Cineform files), so that left HuffYUV.

HuffYUV works okay, but the files are still very large and the encoding process is slow. Then earlier today I stumbled upon an earlier thread by BJ_M that mentioned a company called PegasusImaging. They make a number of codecs, including an M-Jpeg one. I spent the better part of a day working with it, and am delighted to report that it works beautifully. The file size is about 3x that of m2t (similar to Cineform) and the encode/decode process is blazingly fast. When the codec is set to a quality rating of 19 the results are indistinguishable to me from the original in an A/B test on the Vegas timeline. Best part of all is that it's dirt cheap: $28!

I recall that some of you have been experimenting with some scripting software to make the bridge between Vegas and VDub less painful. I don't know much about that process, but can report that Pegasus' M-Jpeg codec is a great way of getting files manually to and from VDub.

Comments

John_Cline wrote on 5/8/2007, 7:24 PM
I've been successfully using the Pegasus' MJPEG codec for years for intermediate files, I've been having issues with it on my two quad-core machines and Pegasus is at a loss as to why this is happening. If I even click on a Pegasus MJPEG file in Windows Explorer, my machine locks up. It runs fine on all my other non-quad-core machines.

Nevertheless, I agree, it does look amazingly good and it is blazingly fast.

EDIT: Oops, it looks like they have released v3 of the codec, I'm still using v2. I'll upgrade to v3 and see what happens.
riredale wrote on 5/8/2007, 8:09 PM
One thing I learned about the configuration--

When you go into the configuration screen for the encoder (by going in via VDub's Video/Compression/Select Video Compression/Configure menus), you need to be sure that both "Assume Normalized YUV" and "Encode Normalized YUV" are selected. Otherwise, the luminance range is wrong, with blacks becoming dark greys. I noticed this immediately in my first full decode/encode cycles with VDub and DeShaker.
Guy Bruner wrote on 5/9/2007, 4:26 AM
Have you tried the Lagarith lossless codec? It creates much smaller files than HUFFYUV.
riredale wrote on 5/9/2007, 9:07 AM
Not for me. I tried it a few months ago, and then again just the other day. For me it actually took slightly longer than Huff.

I'm very pleased with the M-Jpeg codec, and even though it's lossy, it's just a teeny-tiny bit lossy, not enough for my eyes at the 19 setting.
Laurence wrote on 5/10/2007, 8:52 AM
Have you tried the M-Jpeg codec with applications like On2 Flix, Quicktime Pro or the DivX encoder? I'm still looking for a way to master that I can easily plug into various encoders.
Laurence wrote on 5/10/2007, 9:57 AM
OK, The Pegasys M-Jpeg codec seems to work pretty well in external programs. To me that is the biggest problem with codecs like Huffy and Lagaryth. They don't give you avi's that work in that many programs. The files they create are huge, they take forever to encode, and they don't playback smoothly from WMP. I know that that's the price of lossless, but if you can't see the difference, why bother.

Having said that, I know that there is a big difference between not being able to see the difference on a computer monitor and not being able to see the difference on a 60" plasma TV. Has anyone blown up the Pegasys M-Jpec codec really big and really scrutinized it there?
Laurence wrote on 5/10/2007, 10:47 AM
OK, I liked the codec enough to buy it. It really is a no-brainer given it's usefullness and low price.

One question though: is there any reason I should use a quality value of 19 rather than 20?
John_Cline wrote on 5/10/2007, 11:19 AM
"is there any reason I should use a quality value of 19 rather than 20"

Just to save a bit of space.
Laurence wrote on 5/10/2007, 12:28 PM
Another question: Should I check the "swap fields" tab when encoding HD since HD is upper field first?
OdieInAz wrote on 5/10/2007, 12:43 PM
>> "is there any reason I should use a quality value of 19 rather than 20"

Yikes! While everyone else is setting their codec to 19 or 20, I'm shopping around for a better codec. One goes at least 21 or 22.. No need skimp on quality - and I'll have the definite advantage by setting my codec to at least 21. :^|
Laurence wrote on 5/10/2007, 1:07 PM
> Yikes! While everyone else is setting their codec to 19 or 20, I'm shopping around for a better codec. One goes at least 21 or 22.. No need skimp on quality - and I'll have the definite advantage by setting my codec to at least 21. :^|

Kind of reminds me of Spinal Tap and the amps that go up to 11 .... ;-)
riredale wrote on 5/10/2007, 1:14 PM
Laurence:

My first test was at the default, which I think was 15. Okay, I was able to see some jpeg artifacts on a few grey areas of the image. I then tried each of the settings from there to 20.

On 20, I could not see any difference at all between the raw m2t original and the M-Jpeg codec after going after going m2t -> mjpeg -> VDub (add logo) -> mjpeg -> Vegas. In other words, the codec was used twice.

On 18 I could barely make out the very slightest difference on just a very few demanding parts of a still frame.

On 19 I really couldn't see any difference at all. So that's where I figured I should operate.

With 20 the file size was about twice as large and the processing time was somewhat longer. But if you want, go for it.
Laurence wrote on 5/10/2007, 1:25 PM
I used to have a cheap Dazzle firewire video capture device. When I used it, I could see absolutely no degradation on my computer monitor between the original footage and the captured footage. It looked fine on my 32" TV as well. Then one day, I did a video for a presentation with a projector where the image was maybe ten feet across on a nice white screen. Suddenly I could see all sorts of problems that weren't even visable on my computer monitor. I bought a Canopus box shortly after and never used the Dazzle again. Since then I have never trusted my computer monitor to give me the whole story. Currently I use a 21" LCD, but that is WAY more forgiving than a 60" plasma or an 10' image projected on a wall.

I imagine that the file size of a maximum quality m-jpeg file is still a lot smaller than a Huffy or Lagaryth file.

Any idea about whether or not I should use the "swap fields" tab on 1920 x 1080 x 60i projects? I was thinking of using the m-jpec codec as an intermediate between Vegas and DVDit Pro HD, and rather than spending the hour and a half of rendering that it would take to figure this out by experimentation, I thought somebody might already know. Google searches haven't turned up much so far.
riredale wrote on 5/10/2007, 9:48 PM
The sure-fire way is to do a 5-minute project and try it both ways. A field out of order issue sticks out like a sore thumb.
Laurence wrote on 5/10/2007, 10:34 PM
OK, I had success leaving the "swap fields" tab unchecked.

Going up to 20 with the quality slider gives you an avi that takes up almost as much space as an uncompressed avi! "19" is looking like a better option.

As far as going back and forth between Vegas and VirtualDub, I still prefer Cineform. You have to remember that Cineform smart-renders in Vegas and so the "Deshaken" avi only gets rendered one extra time rather than two with the m-jpeg codec. Also, the Cineform codec is designed for rerenders. On their website they show details from a tenth generation render that look the same as the original m2t.

On the other hand, the m-jpeg codec seems to work better with a number of other programs such as Quicktime, On2 Flix Pro and the DivX converter application.

Edit: I just did a test. At a quality setting of 20, the m-jpeg file is about a tenth the size of an uncompressed avi.
Laurence wrote on 5/10/2007, 11:06 PM
I like the Pegasys m-jpeg codec with Bluff Titler. You can use odd sizes with this codec and 1440 x 810 x 29.97p works well with a 1440 x 1080i project. The 1440 dimension is already correct and the 810 is better than the 540 per field of the 1080i project. Cool!