[Dave Haynie]

Used to be the same with the Huey. The plain “Huey” (now apparently discontinud) supported a single monitor; the “Huey Pro” supports multiple monitors and more flexible settings (color temperature, gamma, whitepoint).

It’s true that calibration was originally created for photo work… you calibrated your monitor and printer so that what you saw on-screen matched what you printed (or, in the case of commerical work, what shows up in a magazine). But you need this every bit as much for video work. Even in the case of dual monitors, even of the same kind, you’re not necessarily matched out of the box.

The Huey Pro also acts as a light sensor in the room when not used for calibration, so it can dynamically adjust your color profile based on changing room light conditions.

-Dave

[Dave Haynie]

>> There is no need for an application to “support a graphics card”..

> This of course depends on what you’re doing.

Not really. Things like CUDA and OpenCL are used by an application to simply NOT have to support any specific graphics card — they’re OS-level abstractions. That’s the proper position of the OS… it provides a socket into which software and hardware independently plug themselves.

Certainly for some things, you need a specific level of capabilities, but again, this is properly handled through APIs. If your application needs to know about the specific graphics card in use, your app or the API it’s using is broken.

> Some software will simply run way better on card A vs card B

Sure it will. Some software will run on CPU A better than CPU B. In the case of a device like a graphics card, it could be a problem with the APIs, but it’s more likely a limit of one card vs. another. That still doesn’t mean the application needs special card-level knowledge.

> Speaking of Color, ATI-boards get the full range of rendering

Ages ago, the only choice for good color was Matrox… they used much higher quality DACs (back in the analog days), etc. Then ATi did pretty well, and I used them for awhile. And of course in digital, the graphic card is responsible for color modes, but not the color itself.. it’s just sending numbers. I went to nVidia for GPU acceleration some time ago, just to get decent AVC previews a few years back. Next time maybe ATi… I’m interested to see OpenCL replace CUDA as the go-to API, I don’t think Streams is getting much support from anyone. Apple is ahead there, being the initial architects of OpenCL.

As for calibration… it’s not Apple monitors per se that are any better than anyone else’s; Apple doesn’t make LCDs. But they do insist on IPS displays, which do have the best color stability. So yeah, if you’re not going to calibrate your monitor, you’re better off with an IPS. MVA is pretty close, and better for motion video. The vast majority of monitors are TN, which usually only resolves about 6 bits per color, and can vary quite a bit in what you actually see. I wouldn’t pick a TN monitor for color work of any kind, and it’s completely useless without calibration. But any monitor is going to change over time, as the backlight and panel ages. Even room temperature can have small effects on your panels.

Could be overkill, depending on your needs, but calibration is a pretty easy thing to do.

-Dave

[Dave Haynie]

Not sure what you’re talking about here.

Windows has support of high resolution monitors, just as MacOS does. In fact, I get my drivers directly from nVidia… not sure about the Mac platform. But that’s optimal.. they know the graphic device better than anyone else.

As far as GPU support goes, that’s a speed issue, not a quality one. Vegas doesn’t support the GPU in UI preview yet, only for rendering. They have improved their preview — AVC editing is noticeably faster in Vegas 10 than Vegas 9, but it’s all CPU based.

Not sure about FCP, but Vegas has a slew of options for video preview, including direct-to-device, if you have dedicated preview devices. For normal preview, when quality matters, I preview 1080p on a 1200p monitor, fullscreen, and the quality is limited by the monitor, not Vegas, IF I select the highest quality preview. There are options to scale down in quality and resolution.. you probably know that, but just in case… look for it.

There is no need for an application to “support a graphics card” .. in fact, I don’t want Vegas knowing about my graphics card specifically for video preview. I keep my monitors color calibrated, that runs through the operating system (as it should), and anything not going through the OS would bypass that as well.

And there’s another question… if you’re doing serious video or graphics work on a Mac, you most certainly have a color calibration device (it’s easy to tell.. I get a nag every two weeks to run calibration again). Do you have support for this when you boot Windows, or is it Mac-only? That alone could be the difference in image quality that you’re seeing.

This isn’t unique to computers, either.. most people don’t calibrate their HDTVs either. And HDTVs aren’t shipped with anything close to a good guess about calibration, either (don’t know about monitors), they’re shipped to make a big impact in 5 minutes on the retailer’s floor. Pretty close to the opposite of what you really want. I have done calibrations on friends’ and relatives’ TVs that have repeatedly kept them from returning them… and with all that, not one kick-back from Best Buy or Panasonic 🙁

-Dave

[Dave Haynie]

That’s interesting. I used Premiere briefly back it the 90s, and never liked it. Largely, it was the idea of having to use proxy files for video and audio in those days… despite PCs by then being fast enough for SD editing native. And the fact that audio was treated as a second class entity… I was an audio guy getting into video in those days.

I was under the impression they had pretty much fixed both of those issues in Premiere Pro.

Of course, if you’re doing Blu-Ray, Apple’s intentional lack of support there couldn’t be a good thing either… that would get some users looking toward Adobe, even if they stayed on the Mac platform.

Unfortunately, Apple lets their particular view of consumer buying habits infect their professional tools in bad ways. As a Sony Vegas user, I’m glad to know this will NEVER happen to us (for instance, Sony would never spend crazy time on “3D” support but miss the GPU-accelerated UI that pretty much every other major NLE introduced this year… oh, wait…).

-Dave

[Dave Haynie]

I second that.

The rendering pipeline is just one part of the whole system. And from my experience, if you’re not seeing 100% CPU during a render, it’s because the system is waiting on something else.

What it’s waiting on… who knows. If you’re doing 8 layers of compositing, there are 8x as many HDD loads, lots of other CPU work, plug-ins, etc. And I’ll bet not all of them are multi-threaded.

Years back, I ran into this myself. I had moved from a 2-core to a 4-core system, and yet, I was seeing horrible rendering times. When I took a closer look, I found that the HDD was actually the bottleneck. The project I was working on had multiple video layers, many 6Mpixel and 8Mpixel DSLR photos, etc. And I had it all on one HDD, going back to the same HDD, no RAID, all high-def, etc. Once I spread the assets out to multiple devices, I got my 100% CPU rendering back.

With that many assets on the drive, the HDD speed itself was probably not the issue. As you jump around on a mechanical device like an HDD, the performance will start to more resemble the seek time than the burst time you’ll see in an HDD test. I already knew this… I did audio for years before video, and for multiple tracks, especially back in the 90s, seek time was more important than raw transfer time. You’ll eliminate this in a RAM disk, of course. But this is just offered as an example of an unexpected bottleneck.

Try this: load up one video file, Cineform or whatever, and render out to AVC on another drive — no effects, nothing but the render. That’s your baseline… if all CPUs are pegged, great. If not, it’s probably a limitation in Vegas, or some weird system thing.

-Dave

[Dave Haynie]

Not to suggest Adobe’s doing anything right or take away from Sony.. but what are the settings for the Premiere render? Are you also rendering CBR, or is it a flavor of VBR?

CBR is fine, and at 8Mb/s, you’re doing about as well as you can, as long as your project will fit. However, for a longer video, you generally want variable bitrate. For commercially produced DVDs, you have an encoding engineer who’s looking at the video, varying things like bitrate, global low pass filters, and other tweaks to deliver the best possible video. Without that, a 2-pass VBR will offer some of the same adaptations, at the expense of rendering time.

Not that I have any problem with Sony’s MPEG-2 output. I started making digital videos on my own in the early 1990s. The first target was Video CD, and there were exactly two encoders that did this well: Panasonic’s MPEG-1 encoder and TMPGenc. The latter could also do a low bitrate MPEG-2 for “SuperVideoCD”… my first generation Pioneer DVD player supported this odd format as well (and DVD-R, and DVD-RW… they didn’t use the Philips reference platform that caused so many early players to contain bugs that rejected DVD-R/RW).

So going into DVD, I was skeptical of other encoders. The early versions of the Main Concept code were not up to the TMPGenc quality, but by the time Vegas got video support, the quality was excellent. I think these days, most of the MPEG-2 encoders offer similar quality.. this is a mature technology. Now, AVC, on the other hand…

-Dave

[Dave Haynie]

Since you’re downscaling and rendering… did you try setting the project to “Best” quality and 32-bit/video level pixels. This will affect your final output quality. Of course, given its MPEG, you do want to match the bitrate and other issues (VBR vs CBR, multiple pass) to match what you’re seeing in Adobe.

There was a day when MPEG-2 encoders varied dramatically in quality. I haven’t found that to be as true today, but that doesn’t mean there’s no possible difference. But for certain, you won’t see Vegas match Premiere if one is set to best possible output and the other is not.

-Dave

[Dave Haynie]

It’s kind of telling that, of the five formats you specifically mention, only one (DVCProHD) is an actual camcorder format, and at that, not really an industry standard. Yes, it’s known well in the industry, but it’s a Panasonic proprietary format (as well as not really HD). ProRes, similarly… well known in the industry, but an Apple proprietary format. DNxHD is open source but owned by Avid, and generally not a capture format. Cineform, of course, also not a typical capture format, and also very proprietary. As is Quicktime itself (which you need for DNxHD and ProRes, at the very least).

How about native support for actual cross-vendor camera capture standards, like MXF/MPEG-2 (a SMPTE standard) or AVCHD?

However, I think it’s kind of irrelevant about what FCP actually CAN edit, in this context. When you’re dealing with a service bureau of some sort, they’re generally going to suggest their format or two of choice to make their lives easier, not yours. And perhaps to cover their butts… they can’t support a format that’s going to get transcoded into ProRes or some such, without the possibility that the conversion changes your video in unacceptable ways.

And with that said, I shoot AVCCAM from time to time at work, hand my SDHC card to our internet media guy, and he happily edits away in FCP. Maybe it goes to ProRes (probably… he’s just got a Mac laptop… I’d probably use Cineform for any non-trivial editing of AVC on my dual-core laptop), but it goes without a hitch. I think it’s even easier for him if I remux the MPEG-2 TS streams to MPEG-4, but I don’t bother anymore.

This is a common phenomena in support, across the board. You find a “minimum configuration” sticker on nearly every software package. This usually has little to do with what actually works or not… it’s really a statement of the level of hardware you need to speak to tech support about problems — they’re minimizing their needed expertise by supporting only those systems they need to support, not everything that’ll work.

-Dave

[Dave Haynie]

I didn’t know Cineform of any kind was bundled with Vegas since… I had the original Cineform Connect bundled with Vegas 4. That was kind of needed for HDV editing back in those days, but eventually, PCs and Vegas got faster. Didn’t realize it was in later versions of Vegas, but I had the stand-alone version of NeoScene by then anyway, for better support of 24p-in-60i video that’s still not properly dealt with by Vegas for some odd reason.

Anyway.. my point it, it works just dandy without special application knowledge, just like any other VfW CODEC. Sure, you need a 64-bit version for 64-bit use, and it’s quite possible Sony’s licensed versions only worked in Vegas. But in general, when I install Cineform as a VfW/Directshow CODEC, I expect it work everywhere. It worked just dandy in Vegas 9, for example.

So I’m curious… Vegas 10 supporting their private API — something must be gained form that. Any ideas? And not allowing it shut off, that’s creating all kinds of needless trouble. For example, if I fire up Vegas 9, I can render via VfW to Cineform, call up the configuration menu for Cineform, and most important, not crash when I try to render 1080/20p. In Vegas 10, I’m crashing. So I’ve lost something important, and yeah, hopefully very temporarily. But I do wonder, given that the “Sony Does Nothing” Senario suits my needs and the “Sony messes with it” currently does not, just what we all get for this trouble, once it does work. As an engineer, I have a certain aversion to seeing perfectly good wheels re-invented, poorly.

Not intending to beat you up over this or anything, just figured, since you knew about the use of the private APIs, you might know more details.

-Dave

[Dave Haynie]

Vegas can actually render MJPEG (two different kinds) in a Quicktime wrapper.

There may be broadcast MJPEG standards, and it’s also common for some digital robotics video, but there was not real AVI standard for MJPEG. Back in the day, you could find a bunch of different flavors, with different small details that made it a pain to use.

CE companies actually came to understand this. And given that Apple actually had standardized MJPEG under Quicktime, many adoped this for their digital still camera video. Which is why so many DSC models produce .mov files rather than .avis or some other format.

I agree with John… I wouldn’t choose MJPEG as an intermediary format. And it’s pretty slow to render… maybe a problem with Vegas and Quicktime in general. I much prefer Cineform, but if I needed something free, I might use Avid’s DNxHD. Also also, also supported in Vegas under Quicktime, but designed specifically as an intermediate CODEC.

At some point Dirac/Dirac Pro might be worth looking at; these are from the BBC, and still kind of in experimenter’s form at present, but they’re Wavelet based, like Cineform. If you shoot in DCT (MPEG-2, MPEG-4, MJPEG, DV, etc) you’re likely to get less loss, all things being equal, going to a non-DCT format for your intermediate CODEC. Editing DCT to DCT (and perhaps final rendering to another DCT CODEC) can tend to reinforce the DCT block boundaries (these work by breaking video up into “blocks”, originally 16×16, these days somewhat flexible… if you overcompress, you’ll actually see the block boundaries in your video).

-Dave