[Dave Haynie]

VLC supports a crazy number of formats specifically because that’s its whole purpose. It contains many of the video CODECs itself, which is fine for an open source player tool (poorly optimized, but flexible), but not something a professional tool really should do, particularly for formats the manufacturer isn’t directly interested in supporting. That’s what media frameworks like Video for Windows, Quicktime, and DirectShow are for. Video professionals know this, and know how to deal with the rare incompatible format they encounter (as many have mentioned, DivX/XviD are among the least likely formats any Vegas user would need to edit). In a professional environment, you want the latest CODEC for anything special (Dirac, DNxHD, Cineform, things like that) and you don’t want to have to wait for an application revision to get it.

And even VLC is tapping quite a few of the open source community’s video tools to get all of these CODECs. It uses ffMPEG for quite a bit of this stuff. That’s also not a professional level tool, which is why Sony isn’t including it with Vegas. If you have a video file from a camcorder that Vegas can’t edit (assuming you’ve installed any support CODECs provided by the camera manufacturer), you MAY have a legit gripe with Sony. But the need to edit the #1 video format used for video piracy (not to suggest that’s the ONLY use for DivX…), no, that’s not even on the list of intended Vegas features. If this was important to you, one would THINK you would have researched this before plunking down $500.

And if you have a format that plays in VLC, you can at the least get VLC to transcode it for you… that’s built-in on VLC.

-Dave

[Dave Haynie]

The MP4 file wrapper was based on Quicktime, that’s why this works. Sometimes.

However, unless the NLE you’re using is using the Quicktime media framework to process MP4 files, there’s a pretty good chance this fails for anything but AVC video. There’s certainly no expectation that a normal MP4 file would contain MJPEG, Sorensen, or other old Apple-world CODECs.

-Dave

[Dave Haynie]

Consumer cameras, usually webcams (Flip clones) and digital still cameras are pretty much the only camcorders using Quicktime.

This is a historical thing. Yeah, some do use the Quicktime wrapper for MPEG-4 AVC, which is kind of silly given the better supported formats for this (AVC in an MPEG-2 Transport Stream wrapper, as AVCHD and AVCCAM use, AVC in an actual MPEG-4 wrapper, maybe even AVC in an MTS wrapper at some point).

The original use of Quicktime was for Motion JPEG, which was the video format of choice for digital still cameras until recently. There was never a single standard for MJPEG under Video for Windows… one device’s MJPEG support might set things slightly different than another’s. Quicktime, on the other hand, established two cross device standards for MJPEG pretty early in its life. Digital still cameras already had JPEG engines, so this was a natural goal. It’s only been in the last year or so that digital still cameras have adopted AVC or “AVC Lite” as Panasonic calls theirs (720/30p only, lower complexity profile lower complexity audio than you’ll find on a real AVC camcorder). It probably made sense for some companies to keep the Quicktime wrapper, just because they already knew all of the support questions.

It’s only fairly recently, as well, that you could expect any video editor to accept a wide variety of video formats for native editing, and Vegas was one of the first to do this. But some formats are not well designed. DivX and Xvid are stuffing what’s essentially MPEG-4 Part 2 (also known as MPEG-4 Advanced Simple Profile… a less aggressive CODEC than AVC) into an AVI wrapper, where it really doesn’t belong. That’s fine for playback on consumer gear (DivX is optimized for support of consumer devices: PMPs, “feature” DVD players, etc), but a pretty bad idea as an editing format.

-Dave

[Dave Haynie]

Hmm… I never pay attention to the things the camera manufacturer tells me :-). Of course, they’re just telling what’s known to work, not attempting to provide an inclusive list.

For PC playback, get “Splash Lite”. I just did… they seem to have fixed the problems it had with 64-bit Windows 7. I’m playing a 1080/60p file right now… it’s using about 50-60% CPU on my Q9550 @ 2.83GHz, on a full 1920×1080 monitor. That’s with GPU acceleration switched off… if I switch it on, it’s bouncing between 5% and 10% CPU. Not too shabby.

Also, the kind of GPU acceleration supported in Vegas now is different than what you want here. Vegas is using CUDA, which is nVidia’s proprietary “Native GPU Computing” API — it’s designed for “GPGPU” computing… general purpose math acceleration on a GPU. Video acceleration under Windows has its own API — DXVA: Direct X Video Acceleration. This is part of what nVidia calls “Pure Video”, check it out here: https://www.nvidia.com/page/purevideo_support.html. In short, you may have some level of DVXA support even on nVidia devices that don’t do CUDA.

As for “expensive”.. you can get video acceleration on nVidia GeForce 8400 and 9400 class cards, maybe even lower-spec. That’s starting at about $40. But with an i7, you should be just dandy doing it SW-only. Definitely give Splash Lite a try.

-Dave

[Dave Haynie]

I’ve been making BDs for two-and-a-half years, using Sony’s DVD Architect on Windows. Yeah, you’re in trouble if you’re look to Apple for BD support… unfortunately, many of the media content creation software companies throw their specific politics into action in their software. For example, Sony put “3D” editing into the new release of Vegas… because Sony’s pushing really, really hard to market stereoscopic TVs, BD players, and software… not because most of us Vegas users wouldn’t have found more value in, say, GPU-accelerated editing/compositing (which is what Adobe users got in their last upgrade).

Apple believes the follow up to the DVD is the iPod/Apple TV, not the Blu-Ray. On the Mac PC, you’re probably better off looking at Encore. On the PC, pretty much every DVD authoring package now does Blu-Ray to some extent… even the super low end stuff. With DVD Architect, you get a very DVD-like model for Blu-Ray, and it’s almost a no brainer changing a DVD project to Blu-Ray, or vice-versa. This is particularly useful when you’re authoring for a wedding or other event… there’s very little extra work supporting both video disc formats.

-Dave

[Dave Haynie]

Well, there are a couple different issues.

Certainly, camcorders are recording at 24Mb/s … that TM700 1080/60p video is actually 28Mb/s AVC. But consider the camcorder’s problem: it has to not only record AVC, it has to do this in realtime, at very lower power. It may be using a simple AVC profile (Main rather than High, etc) in order to deliver, too.

It is not necessarily the case that lower bitrates encoded on a PC will be worse quality. A PC has all day to do the encoding, it can run a multi-pass encode, etc. With that said, I also agree that I want the best possible video on my Blu-Rays, and I’d prefer to use the highest bitrate that allows all the video and audio I need to fit on a BD25. I don’t know why Sony’s not allowing higher bitrates, particularly after all these years. Oddly, the Main Concept AVC CODEC will produce video up to at least 20Mb/s, even though everyone seems to use Sony’s for HD video and Main Concept for iPods and Smartphones.

-Dave

[Dave Haynie]

Those TM700 1080/60p AVC files will play smoothly on my aging laptop.. Core2 Duo at 2.4GHz. The trick is to use GPU acceleration: the laptop has a nVidia 8600M GPU, and that’s a big help… in fact, the only reason it can play such. On my desktop (Q9550 CPU, Core2 Quad at 2.83GHz, plus nVidia 8800GT) the 1080/60p files play, in Windows Media Player even, using only 12% CPU.

The trick here is that, under Windows 7, Microsoft themselves has provided an AVC decoder that uses the DXVA 2.0 API… GPU acceleration specifically for video playback.

Without that, I can play these, very smoothly, on my desktop, so you should too. But it’s very dependent on the player. VLC is pretty horrible, WMP too without the video acceleration. The Nero media player (Showtime, or something like that) did it, and before I upgraded to Windows 7, Splash Lite was another that could play these. AVC is a complex CODEC, but stuttering on these on an i7 indicates a poor playback program.

And yeah, Vegas is one of those, too. Smooth playback of 1080/60p also depends on a multithreaded player. Vegas 10 does this, but I’m pretty sure Vegas didn’t always.

-Dave

[Dave Haynie]

Low light has been an HD issue all along, and of course, a camcorder issue before that. Over time, sensors have improved… the same kind of sensor today is probably better at low light, all things being equal, than one from a few years ago.

Tragically, of course, things are never quite equal. Early pro/prosumer 3-chip cameras boosted low-light capability by using 1/2 resolution sensors… this, huge pixels, usually with the green sensor offset. You’d pay a little in sharpness, but win back some low-light capabilities. The first HDV camcorders did this too… your FX1 used three 1 Mpixel sensors, rather than the three 2Mpixel+ sensors used in most of today’s pro/prosumer camcorders. And even with older sensors, your 1/3″ chips are gathering more light than the 1/4″ chips in my Panny, though probably less than the 24mm x 36mm sensor in a Canon 5D Mk II.

I take it you’re monitoring via analog component outputs? That is presumably a tap directly from the sensor output somewhere, maybe even at full resolution, but be careful… are you using the same monitors you’re using for HDV editing? Probably not. Small field monitors are often less than full resolution, but small enough to make that not so important, and so they basically run a low-pass filter over your video. So you don’t see the imperfections you’ll see when you start editing on that 24″+ monitor back at the ranch. Maybe not, but something to consider — do a real test

-Dave

[Dave Haynie]

AVCHD vs. HDV is absolutely not a low-light issue. Both encode whatever your camera’s sensor is capturing.

In practical terms, low light technology is one of the primary areas that every camcorder company has been attacking. These days, I can buy a consumer model like the Panny TM700 that does low light better than some of the early HDV pro models. But it’s not the CODEC, it’s the evolution of sensor technology.

The real issue with HDV vs. AVCHD is quality and flexibility. Given a matching lighting condition, it wasn’t really until 2009 that any AVC camera could match the overall quality of an HDV camera. But these days, I think it’s pretty clearly flipped. I bet money on it..

I bought a Panasonic HMC40 and a TM700 in the last year, to replace more expensive HDV gear. The 1920 vs. 1440 resolution was a minor issue; the real rational was better low-light (I’ve been working a bit lower end than you) and better overall quality. In theory, AVC should deliver twice the quality of MPEG-2 at the same bitrate. Thus, a 1920×1080 encoding at 24Mb/s should be better than a 1440×1080 encoding at 25Mb/s. Today, it is, no questions.

And then there’s the flexibility. My Sony HDV camcorder did 1080/60i. The HMC40 does 1080/60i|30p|24p and 720/60p|24p. The TM700 adds 1080/60p capability. And no, it’s not as nice to use as the HMC40, but on a tripod, it delivers the same result.

If you have SDI or HDMI out or some-such, straight from the camera, and some PCs, you could get a better result with a realtime capture card. If you’re happy with the low-light capabilities of the current gear, no problems.. but again, most of the issue isn’t the encoder. It’s true that a noisy image will screw with modern interframe lossy compression, but the compression doesn’t create the sensor noise. And of course, needing a PC per camera or two isn’t a terribly mobile rig.

-Dave

[Dave Haynie]

Cineform Neoscene gives you a more edit-friendly video format. While technically it’s using wavelet rather than DCT compression, the end result is that you get something that’s more like DV… no interframe compression. Because it’s not another DCT format, and because it’s been highly tweaked for “intermediate format” editing, it has only a very small effect on video quality, versus native editing. Using a different DCT format, like going from AVC to MPEG-2 MXF as some do, can tend to reinforce the DCT compression artifacts common to both CODECs.

The one issue with Cineform is size: you can get about 50-60GB/hour, versus under 12GB/hr for DV, HDV, or 24Mb/s AVCHD. You’ll need ample storage, and if you do lots of video tracks at once, fast hard drives. I have occasionally run into speed problems with Cineform just due to HDD performance, but that was some time ago, and it’s solved by using multiple drives (then again, I’ve also done projects with 40+ compositing layers).

I don’t think the bitrate’s going to matter much… if you’re happy editing AVCHD at 16Mb/s, going to 24Mb/s at the same resolution shouldn’t seem much different.

-Dave