[Dave Haynie]

I’m not a big RAM Preview user, and I’ve seen my memory use jump over 6GB running Vegas… so it’s reasonable to imagine it’ll go higher still.

I was pretty happy with 8GB until some recent still photo work (just vacation shots) pushed me past that as a comfortable limit (compositing and contrast mapping of panoramic shots from an 18Mpixel camera).

I like to say the best laptop for Vegas use is a desktop… if you’re a dedicated laptop person, find the fastest laptop you can. But for video, stills, and electronics CAD, I’m unhappy unless I’m front of dual 24″ monitors. There’s just not enough space on a laptop screen, much less the likelihood that it’s a TN LCD, rather than PVA/MVA or IPS. And how often are you going to color-calibrate that laptop?

Of course, I have a laptop for remote work. Mostly that’s used for audio recording (though I’m seriously considering adding a 1U rack PC to my mobile audio rig instead), occasionally for same-day editing if I’m doing video in a different city. If you do that kind of thing all the time, the laptop makes some sense.

-Dave

[Dave Haynie]

It’s entirely based on your use patterns.

So when your system is really loaded up, start the Windows task manager, go to the “Performance” page, and hit the “Resource Monitor” button. Now, got to the memory page of the Resource Monitor, and watch the three windows on the left.

You’re looking for the percentage of used memory in the top “Used Physical Memory” pane, how smooth the Commit Change pane is, and if you get many spikes on the Hard Faults/sec pane.

If you rarely see hard faults, in particular, you’re not doing much virtual memory, which means you’re not running out. You’ll always see some hard faults, simply because code is often loaded “virtually”.. the loader physically allocates part of a program, but simply marks the rest loaded, and lets the VM mechanism actually load the remaining code. But if you see lots of activity here, you could improve performance with additional memory, at least on a 64-bit OS.

And don’t panic too much about a fairly large amount of used physical memory. All modern OSs will try to allocate big chunks of memory for buffers and caches when they’re not otherwise occupied — unused memory is a waste. As applications need more physical memory, the OS will back off on its variable use of said resources. For example, I have 12GB on my system here, and just running regular stuff (web browsers, emailer, etc) I see 4GB used and 4GB “cached”… the OS has sucked up a whole 4GB in an effort to make the whole thing go faster.

Really, for video, I had 8GB for the least few years and didn’t think I needed any more. But I recently bought a new still camera, a Canon 60D (18Mpixel), and on a recent trip to Alaska, I shot a number of 10-30 photo panoramas. I print RAW out to 48-bit uncompressed TIFFs, and align them in Photoshop… oh, wow… 8GB isn’t all that much memory anymore! I never would have bet that still photo editing would have been the thing to push me over the top.

-Dave

[Dave Haynie]

Just a point of clarification here… JBOD (Just a Bunch Of Discs) is a non-RAID configuration. So you’re correct about wanting level 5 RAID…that spreads redundancy across four (or more) identical drives, allowing one to fail with no data loss. JBOD systems can do drive spanning, to turn four smaller drives into one big-ass volume, but there’s no data redundancy.

-Dave

[Dave Haynie]

BCC doesn’t use CUDA, it used OpenGL. Stephen probably knows this, but I figured I’d explain it all to the group, since this is a point of confusion.

There are actually several different programming interfaces a graphics card presents.

The oldest is the “standard” 3D graphics interface. And on Windows machines, there are actually two of these, Microsoft’s DirectX graphics interface, and the OpenGL (Open Graphics Language) API defined in the 80s largely by Silicon Graphics. DirectX is more often used for gaming (though some games use OpenGL), OpenGL is considered more precise, and thus is used for 3D video or 3D CAD rendering.

The next is video playback acceleration. Like graphics, this is another very graphics specific API. Microsoft added their interface, DXVA (DirectX Video Acceleration) way back, to standardize the fact that video cards were starting to support video acceleration in hardware. This was greatly improved under DXVA 2.0 in Vista, but being Vista, most folks didn’t know about this until Windows 7.

On my 6-core AMD processor, playing back a 1080//60p video (kind of the worst-case these days) will run around 50% CPU (all six) playing unaccelerated in a program like VLC. When run it plain old Windows Media Player, which uses Microsoft’s accelerated H.264/AVC decoder, I see only 7-8% CPU being used.

So far, this hasn’t been used in a video NLE. I believe it could be used, but it would be pretty complex, since the goal of this is delivering a decoded image to video memory, not to system memory.

The final set of graphics card APIs fall under the banner of GPGPU compuing: General Purpose GPU computing. The idea here is, why not make those 100’s of graphics processors do any kind of work. This idea has also kind of co-evolved with the GPUs themselves… the latest GPUs do things like 64-bit floating point, which isn’t necessarily all that useful just for graphics rendering.

There are several different programming interfaces for these. Not surprisingly, the graphics chip companies started this whole thing, so there’s the CUDA interface, from nVidia, which only works on nVidia processors, and the Streams interface, now depricated, which used to run on the AMD/ATi chips. These allow a programmer to break a math problem down into many parallel chunks and use the GPU to compute it, which is a good thing. The bad part — as you get faster match engine architectures, they’re harder to use in a natural way.

So coders started first with plain old floating point math, very easy but only runs in parallel if you have a CPU with several floating point pipelines and a runtime scheduler. Next came the SIMD instructions: one instruction runs on several chunks of data… this is also called small vector math. This is MMX and the various SSE levels… much harder to code, but much faster once you do.

There are other GPGPU APIs. One probably already on most systems is OpenCL (Open Computer Language), an effort to make GPGPU run independently of GPU type. nVidia supports OpenCL in CUDA these days, and AMD/ATi now supports OpenCL as their primary interface. It’s only really been solid for less than a year now… Sony added OpenCL support in recent versions of Vegas 10, just for Sony AVC rendering, as with the CUDA support before.

The main reason Sony hasn’t integrated this for other kinds of acceleration, I believe, is that it’s a very big job. You’re not just re-designing the video decoding, rendering engine, and other internals around GPGPU, you’re adding this to any non-trivial plug-in, or the effect is muted. Other companies made edit-time GPU acceleration a major selling point of this year’s releases, particularly Adobe and Grass Valley. Sony’s major new feature was stereoscopic support, perhaps the new plug-in engine, and apparently, some major under-the-hood re-architecting.

Given that most NLEs these days, like Adobe, have largely copied Sony’s modern behavior (no re-rendering of input video, realtime on-screen editing, etc), I don’t believe GPU acceleration for editing is impossible. Given the level of support Sony seems to devote to new releases over companies like Adobe, I’m also not holding my breath.

But hey, at least Vegas isn’t going backwards like Apple did with FCP X. In truth, while the 3D stuff wasn’t all that useful to me, overall, proper support of BCC plug-ins via the OFX standard has proven more useful to me than accelerated editing.

-Dave

[Dave Haynie]

While a 5400RPM drive is not ideal for editing, it’s hardly “too slow”. Most editing is concerned with linear drive speed — how many bits per second you can pull from a drive in a straight line, a couple of files. That’s a function of drive density and rotational velocity, and in modern times, the drive density has been the key. That’s how much stuff is available in a single rotation. If I cram twice as much data per track on a 5400RPM drive as a 7200RPM drive, that 5400RPM drive will go 1.5x faster than the 7200RPM drive.

So, for example, a 2TB 5400RPM drive is probably much faster than a 500GB 7200RPM drive, for straight-line stuff. Obviously, the 2TB 7200RPM is faster than either. If you have a very small data drive, upgrade it, both for speed and capacity, but only after you get a multi-core CPU.

Where drive speed still matters a great deal is latency… the rotational velocity has the largest single influence on the seek time. This can have an effect on overall rendering speed if you’re loading too many assets from one drive. That’s easily cured by using multiple drives. This is the predominant issue for audio recording in realtime.. drive seeks will have a large influence on the number of tracks you can record or play back in realtime (I did audio on PCs for a good ten years before I got into video… my field recording rig is still more impressive than my video gear).

Keep in mind that HDDs are many, many times faster than most video media. My camcorders record at up to 28Mb/s. When I encode 1080/60p in Cineform, it’s about 130Mb/s. DNxHD video is usually around 144Mb/s.. that’s probably the slowest video I’m likely to use. A typical decent HDD these days can easily read at 50MB/s-100MB/s, faster still if you’re using an SSD. That’s 400Mb/s-800Mb/s… you video is read much faster than realtime. The SATA interface is rated at up to 6000Mb/s… not bottleneck there.

Video decode (eg, your CPU) is always the bottleneck. A modern Core-2 or i3/5/7 single core is probably not fast enough to decode HD AVC in realtime on its own. It’s very code dependent, but on my 6 processor AMD 1090T, I see some video players (VLC, for example) taking as much as 50% CPU to play 1080/60p in realtime, 25% for 720/60p or 1080/60i. That 1080/60p drops to 7% CPU using a better video player with GPU acceleration. You may see some of that kind of thing running the latest Adobe Premiere, but Vegas doesn’t do this yet. So even for just plain editing, you want all the CPU you can get — every CPU is still inadequate, once you start thinking about a few layers of 1080/60p AVC in an edit. And that same decoding time applies during a render… Vegas has to decode each frame, apply all FX, render the final single frame, etc. even before the AVC encoder is invoked. This can be sped up a bit editing in MPEG-2, better still in something like Cineform, when performance matters.

-Dave

[Dave Haynie]

Sony Vegas won’t directly burn an AVCHD disc. DVD Architect will create a Blu-ray compilation for use on DVD, but it will not create a proper AVCHD format — there are small but important differences. And the main reason for caring about this is that most Blu-ray players will play AVCHD discs, only a few will play “Blu-ray on DVD”.

What you want to do is create a high quality AVC rendering, up to 18Mb/s bitrate. Audio should be rendered in AC-3. Download the free “MultiAVCHD” application, and use this to create the final AVCHD file structure. Then burn this on a DVD using the UDF 2.5 or 2.6 file system, and you have made yourself an AVCHD DVD. These can be DVD5 or DVD9 by the way.. the results for shorter videos won’t be quite as good as full Blu-ray, but given the quality of most camcorders, pretty close.. and certainly much better than scaling down to DVD-Video.

-Dave

[Dave Haynie]

You can’t actually make a JPEG file with a transparent background. Transparency is supported by Photoship .PSD files, GIFs, PNGs, and a few other file formats.

It doesn’t much matter which graphics format you use — there’s nothing magical about a PNG or JPEG versus a GIF. GIFs are limited in color, so that’s one thing to be concerned about, but other than that, one’s going to animate about as well as another. On the other hand, a GIF itself can be an animation, which makes this easier to accomplish, sometimes.

Of course, a JPEG or any other image type can be chroma-keyed. Some of the small graphics animations I’ve done were using GIF clip-art, usually designed for web pages, without transparent background. If the GIF was a little weird on its own, I could get it better, resized perhaps, etc. as a video clip, then use that and key out the background.

One concern, particularly if you’re animating in interlaced video, is that a very “computery” image, something with prominent horizontal lines, is going to flicker in the interlacing. You’ll also see flicker if you move an object too quickly without adding motion blur (I use BCC for this, these days).

Here’s a video I did a few years ago, with all kinds of graphics animation:

-Dave

[Dave Haynie]

Cool! I didn’t actually know about that one.

I guess, basically, because Panasonic did 28Mb/s 1080/60p in early 2010, but they didn’t dub it AVCHD. The format is exactly what you’d expect for AVCHD… I’m pretty sure it’s AVCHD 2.0 compliant, after the fact.

Of course, Panasonic and Sony created the AVCHD spec out of the Blu-ray spec. But this doesn’t actually change anything for disc media.. the limit for DVD is still 18Mb/s, and there’s no support for AVCHD on Blu-ray media. So this is a memory card thing only, far as cameras and players go. Nearly every current BD players supports AVCHD (it’s kind of crazy, in fact… most will not play a BDMV on DVD, but put that same video on the slightly different AVCHD file structure, and nearly all BD players handle it).

Of course, if you do see a Blu-ray player with the “AVCHD 2.0” label on it, you know it’ll play 3D and 50p/60p.. but not necessarily from BD or DVD. But it certainly COULD play it from BD, given a modified spec. As I said, I was surprised they didn’t include 60p in the 3D Blu-ray spec, since at that point, the hardware is effectively doing the same thing (the AVC-MVC format is actually using only 50% more data than 2D, but the computation is likely to be slightly more than twice as much to decode).

-Dave

[Dave Haynie]

[Sigfrid Nordström] “It is fairly much as I thought. One is just tempted to think that BD players going up all the way to 54Mbit/s would be easily converted to cope with 28Mbit/s in Mpeg 4.
“

Generic BD players, probably not. Though I would venture a guess that any BD player capable of 3D output should have enough computational power to do a single stream at 1080p. Certainly the PS3 could support it… that’s why I was kind of surprised that they didn’t roll 1080/50-60p support in with the 3D update. Oh well…

[Sigfrid Nordström] “One wonders how Sony thought when they implemented the “PS 28Mbit/s” mode for their whole range, since the BD standard does not comply with it. It looks good on the fact sheet I suppose and possibly a new BD standard is just round the corner? “

I don’t think so… they’re basically just following the competition. Panasonic’s had 1080/60p for at least a year-and-a-half now in some models, even Sanyo had it. There’s nothing in current camcorders directly related to Blu-ray.

The AVCHD standard was derived from Blu-ray, but it was scaled way down to be useful for camcorders, including DVD, Blu-ray, and flash media models. The cap on that standard is 24Mb/s, so unless there’s a reason to change that limit, no one does.

1080/50-60p provided such a reason. Panasonic came out at 28Mb/s, so it’s no big surprise that Sony would go there too. That’s not AVCHD, but it can’t be anyway, since 1080/50-60p is not an AVCHD-legal resolution anyway. This still keeps recording just dandy on a Class 4 SDHC card (which can technically support up to 32Mb/s).

I suspect these rates eventually move on up. Many DSLRs are already shooting at much higher rates in AVC for video… they don’t shy away from demanding faster memory cards to keep up.

[Sigfrid Nordström] “Possibly you can work out a bespoke PC to render 1080 50p but most people seem to think PCs would struggle with this and PCs are not the right environment in this case. Any hard drive storage is of doubtful stability in a long term perspective. This is where BDs make sense along with being fairly cheap and versatile to use.”

I can do 1080/60p on my 2-core laptop using GPU acceleration for rendering… it’s not THAT difficult. But keep in mind, a PC is supposed to be a general purpose computational device. BD players are very tightly designed to the job that’s fully qualified for them up front… unless you’re running on a game machine like the PS3, which is also designed to be general purpose (and, not surprisingly, takes about 10x the power to run, versus a dedicated BD player… it does all decoding in software, versus fixed hardware for the BD player).

Hard drive storage has its limits. They are fairly reliable, and if you treat them as a storage media rather than an archival media, they’re fine. You can certainly burn 1080/50-60p video file to BD for backup, just not as BDMV discs that will play on regular players. I think right now it’s actually the case that HDDs are still as cheap, give or take, as BD storage, but that’s not likely to last. Still, when I first started making Blu-ray discs, I calculated that the HDD storage I would need to store a season of a TV show (I was using “Lost” on Blu-ray as a model) actually cost me more than the Blu-ray set did… that’s one of the real problems with online purchases of video (assuming they actually sold you BD quality video, which they never will). But a media PC isn’t a horrible idea for showing your own videos.. I use my PS3 for this, though getting it to play 1080/60p is questionable right now, largely because its not something Sony seems to care about.

[Sigfrid Nordström] “f you start with a more aggressive form of compression in 50p and then transform it into 50i (also going from Mpeg 4 to Mpeg 2) would it not seem better to shoot in FX mode (24Mbit/s) and burn it to a BD in Sony´s PMB which I think leaves it in Mpeg 4? Having said that, in support of the first method, 1080 50p burnt into 1080 50i each frame becomes a field which would perhaps make some sense?”

I’m never going to burn directly from the camcorder files anyway, since I always edit. So the camcorder format isn’t important to me, but yeah, you ought to be able to take raw video from any AVCHD camcorder and burn directly to compliant Blu-ray without re-encoding, given that AVCHD is largely a subset of Blu-ray (AVC is also know as MPEG-4 part 10, but most of the time when people say “MPEG-4” video they’re referring to MPEG-4 part 2, also called MPEG-4 Advanced Simple Profile… so be careful about causing confusion. “AVC” or “H.264” are more commonly used).

If you know for certainty that you want 1080/50i, shoot in 1080/50i. The advantage of shooting in 1080/50p, even for Blu-ray, is that you decide later if 1080/50i or 720/50p was the right answer for the material you shot. And you get the archival format as well… 1080/50p may be more useful in the future, maybe the next time a Blu-ray upgrade rolls around.

We shooting in NTSC-land formats have an advantage, since most NTSC camcorders will also shoot in 1080/24p mode.. not sure if that’s as well established in the former PAL territories (the frame rates survive, but both NTSC and PAL themselves are dying off fast). I shoot 24p for a film-like look, and as well for low-light… I can shoot at 1/24th second at 24p, but only down to 1/60th second for 60i or 60p.

The bitrate isn’t the limit… any BD player can certainly decode 54Mb/s or whatever the limit is these days… 3D players are required to decode up to 70-something-Mb/s. The problem is whether they can actually decode twice as many frames per second. The data rate is really a function of a the medium (eg, the Blu-ray disc player mechanism), while the decoding rate is largely a function of the processor in the BD player.

-Dave

[Dave Haynie]

[Sigfrid Nordström] “I am currently using a Sony HX100 for filming in 1920×1080 50p (PS mode 28Mbit/s) and burning these on to a Blu Ray in Vegas Pro 10. As yet BDs (Blu Rays) don´t seem to support this format in Mpeg 2 (although some people claim that it does i.e. Vegas) so all authoring/burning progammes seem to down convert from 50p to 50i. “

That’s correct…1080/50p is not a supported Blu-ray format. You can convert to 1080/50i or 720/50p, your choice. It’s not possible to update most Blu-ray player for 50p or 60p, that would require twice the decoding rate they currently support. Technically speaking, any BD player capable of 3D support should be pretty close to allowing 50p/60p, but sadly, while the 3D profile did increase the speed and maximum bitrate permitted for 3D discs, it did not add a 50p/60p mode.

[Sigfrid Nordström] “When you go from 1920X1080 50i to 1920×1080 50p the bit rate increases fom 24Mbit/s to 28Mbit/s, does this not entail heavier compression for each frame? “

Of course, camcorder bitrates are dictated by standards and capabilities of the current hardware. But sure, that is the case… 28Mb/s for 1080/50p delivers a lower per-frame bit budget than 24Mb/s for 1080/50i.

That’s probably ok, though, at least most of the time. The way MPEG standards work, they encode a single “I-Frame”, for “Independent”. This is like a single frame in DV or Motion JPEG. For subsequent (usually at least 15) frames, the image stored is based on previous (and possible subsequent) frames. The MPEG algorithm runs a motion estimation algorithm, which encodes “motion vectors”… take frame N, calculate how to change it to frame N+1. Now, take just the difference between that calculated frame and the actual one, and that’s all you have to store (well, along with the motion vectors).

When you’re recording at 50p, you have twice the frame rate. So, all things being equal, objects only move half as much from frame to frame… so you can use fewer bits per frame to encode the differences. And errors are only on-screen for half as long, so it’s more forgiving based on time, too.

We’ve seen this before. MPEG-2 on DVD is usually encoded at around 7-8.5Mb/s, give or take. HDV is encoded at 1440×1080, four times the data of a DVD per frame. So we’d like to see 28-34Mb/s on the average. But we only get 25Mb/s for HDV. Going to ATSC television, we’re actually recording six times the data of a DVD per frame, 1920×1080 and that’s down to 19.4Mb/s or less in the stream.

And similarly, that’s pretty much ok. An HD image is broken up into many, many more DCT blocks than an SD image, and each is visually much smaller. So for the same image, we’ll have far less information in each block, and even though HD will put more detail in the overall image, we’re much less sensitive to defects in the smaller details. So we can get away with a bit less of a bit budget per DCT block.

Of course, some cameras will use more bits anyway. 25-28Mb/s AVC is an improvement over MPEG-2 at 19-25Mb/s. But of course, you can get better results with higher bitrates for either. Most higher end pro cameras go for higher-still bitrate MPEG-2 (35-50Mb/s) rather than AVC. This is part just because of momentum — AVC encoders are computationally more complex, and still improving, while MPEG-2 is mature. And many higher end pros have a well established MPEG-2 toolchain.

-Dave