Dave Haynie
Forum Replies Created
-
[Nigel O'Neill] “If you are a full-time video editor, I think you are in the wrong profession :-)”
No, it’s only a part-time thing. I have done video, photography, and animation for employers in the past, as well as free-lance. But my main gig is usually designing electronic devices of some sort or another. I got into video back when the “electronic device” was usually an Amiga computer, back in the mid-80s to early-90s.
-Dave
-
[Nigel O'Neill] “Dave, is it possible Vegas is not actually utilising the full potential of the 2nd CPU as the Vegas code is not optimised for it?
Probably not in the way you’re thinking. Your machine is a pure SMP (symmetric multiprocessing) machine. Vegas only knows about the number of threads its allowed to use, it doesn’t really understand machine architecture beyond that — that’s up to the Windows scheduler.
The main problem here is that you doubled your memory load, but didn’t double your memory speed. This is the basic flaw with pure SMP systems, and why very large parallel systems go to NUMA (Non-Uniform Memory Architecture) or loosely-coupled/distributed computing (think of a bunch of CPU + memory modules interconnected with very high speed networks). In fact, that’s the basic architecture of the AMD processors going back quite a ways (to the original Opteron), and on Intel CPUs since the i-series was introduced.
If you had a new dual-socket system, you’d have separate memory for each processor, which would eliminate the contention you can, depending on the work being done, see on your system. Think of it this way: if every CPU core is running entirely out of cache, your system will go twice as fast as it did with the single CPU. If every CPU is hitting memory at the same time, it’ll go much slower than it would have otherwise.
So sure, it’s possible there are access patterns that would improve Vegas’ performance on your kind of system, and perhaps some that are better suited to more common media workstations. When you break up a job into multiple threads, there’s some degree of thinking about just how to break that up. For example, if you’re decoding video frames, do you pipeline things so each processor is always working on a full frame, or do you break each frame up into N chunks and feed them to each processor? In the former case, you’re going to spend more resources on memory, in the latter case, more of the CPU overhead will be spent on communications between the chips. And of course, for AVC or MPEG, you could every split things by GOP, but that starts to get big. Well, big-ish… I guess around 712MB of buffer, if you wanted to feed a GOP in HD to each CPU on an 8-core system.
And there’s another pretty obvious one I forgot to mention: memory. Not only do you have contention for the main memory bus, but of course, in a fully multithreaded application, you’re added a big chunk of memory use per CPU. Your mileage may vary, of course, by the job being done. There’s a floating recommendation around here of 2GB per core, minimum… not sure if that comes from Sony or not. I’ve seen about 7.5-8GB of memory in use on my six-core processor running Vegas renders, so obviously, not a hard and fast rule. But that’s another thing to double-check — look at your physical memory, and see if virtual memory is growing while doing the playback or anything else that’s slowed down.
Memory thrashing is a potential issue for every streaming application. In some kinds of work, there’s a small amount of data coming into the CPU and lots of computation. That’s fairly typical of a large number of server-type applications (certainly not all of them). Your system will do really well at this. On the other hand, think about video processing… you’re reading in fairly low bandwidth data (AVC at 21-44Mb/s, typically) but expanding this to uncompressed memory buffers, that’s about 8GB per minute per channel for 1080p24 video. And of course, for you to see a video display, each de-compressed chunk has to be composited into another buffer, and finally, displayed. Sure, there’s some streamlining there, but the basic idea is that you’re creating lots of data in memory, but not doing a great deal with it. So there’s going to be lots of main memory access. Most systems today have fewer cores and/or faster memory, so memory isn’t usually the bottleneck. But under the right circumstances, maybe. And that chance goes up as the CPU performance increases or memory performance decreases.
[Nigel O'Neill]
We run itanium Superdomes at work and unless the code is optimised for the architecture, you don’t see the benefits.”The Superdome is a “ccNUMA” architecture system. That’s a NUMA system with an efficient structure to allow very large numbers of CPUs.. each Itanium has its own local memory, and it can access memory elsewhere in the system. But that access is far less efficient — it’s both lower speed, and subject to contention, particularly if you scale all the way up to 128 cores. If the application and OS treat such a system as a pure SMP system, the performance will be much lower than if processes can basically be scheduled between local CPUs and memory, using the shared cross-point and links primarily for communications.
-Dave
-
9800Kb/s also assumes there’s no audio… most of the time, you want audio. Your 9.8Mb/s is both audio and video, so the first thing you do is to back off from the peak based on whatever audio you’re using.
Yes, any commercial player will handle full 9.8Mb/s. But if that player has trouble reading your disc (the player’s fault, not yours), there’s no margin for retries at full bitrate (well, in theory — in practice, things like PS3s and BD players read DVDs at 2x, so they don’t have an issue). This is why many folks limit video to 8Mb/s.
On anything but talking heads, VBR is the right decision. Yeah, as John says, if you can fit the whole thing at 8Mb/s CBR, you won’t see VBR as a noticeable improvement. But it also doesn’t hurt anything but your time.
DVDR-DL/+DL are a problem for many players. It’s really the technology.. like DVD-R/+R and DVD-RW/+RW before it, these aren’t perfect copies of a glass mastered dual layer disc. The reflectance of the second DVD layer on a glass mastered disc is supposed to be at least 25% (in fact, there was a bug in the early Philips DVD reference code that flagged such a low reflectance disc as dual-layer… unfortunate because DVD-RW is usually around 25%; that’s the only reason many early players didn’t handle the RW discs). It’s about 15-20%, either layer, on a DVDR-DL.
And these came out late. Naturally, the DVD drive you use to burn the discs read them. Some older players have very good AGC circuits that compensate for reflectance in the name of compensating for aging lasers (the main reason for AGC circuits in DVD laser systems). Others simply can’t read these discs — they don’t really meet the original DVD specs.
-Dave
-
I pretty much agree. 24/96 is great for music. 24-bit is particularly useful for audio-for-video, since it offers an additional 48dB of headroom, so you can kind of not worry about audio levels and just deal with the video.
But for voice, you can probably use the Zoom’s AGC settings. I never use that for music — it’s likely to act like a slow compressor, and it’s also probably going to get fooled by sharp peaks. But for voice… you’ll probably compress anyway, somewhere in the editing process. Don’t know if the AGC in the Zoom 1 is any good, but I found the H4n’s acceptable for speech recording.
-Dave
-
A couple of things… I take it this is an E5400 “Harpertown” Xeon, vintage 2007 or so. When you see a slowdown, look at what could be slower.
When you have a single processor, all cores more or less coordinate, via shared L2 (and L3, in newer CPUs) and very wide internal buses, to optimize memory access. And of course, in more recent systems (pretty much all AMDs in recent memory, and Intels starting with the “i” series), each CPU has two or three dedicated memory channels.
But back up a few years, and your second CPU is now totally sharing memory access with the first. This basically means that each core has half the bandwidth to main memory that it had, previously, when the system is busy and missing cache hits.
Only, it’s probably actually less than half. Modern memory systems are like muscle cars — very fast in a straight line, but trouble when you have to take that corner. DDR2 memories can actually track a couple of simultaneous streaming memory accesses at the same time, but I think it’s only two. You now have eight potentially different chunks of memory being hit all at the same time.
That’s not a problem if CPU is really the bottleneck. Give them enough processing to do, and you’ll see 2x the performance you had with just the one CPU. But hit memory too much, and it’s absolutely going to drop.
The only thing I’m confused on is why the HDSLR AVC (which is either AVCHD or Canon-style, which is higher bitrate but actually simpler to decode) would be worse than your performance on MXF/MPEG-2 at similar or higher bitrates, if memory performance is the real issue. But at the very least, it’s unlikely that Vegas would be optimized for this kind of system, since it’s both pretty high end, and old-fashioned (eg, current Xeons will use the i-series style on-chip memory controllers and high-speed point-to-point links between each other). Could simply be there’s more intermediate processing in large memory pools for AVC decode.
Try some performance monitoring. During editing and playback, how many cores do you see doing work, and what level are they hitting (percentage of maximum). Try telling Vegas to use fewer cores. Turn off hyperthreading, if this series hyperthreads — that’s yet another thing thrashing main memory, and also on-chip cache.
-Dave
-
Photos shown on uncalibrated monitors are not going to be graded correctly. If you’re not doing any color adjustments, you may just be lucky that your PC monitor is faithful to what you expect to see, or maybe it’s showing you total fiction. Can’t really tell without color calibration. About all you know is that your monitor and your TV are different. And unless you have a CRT or LCD IPS or PVA/MVA monitor, there’s no special reason to expect your monitor to be the correct one here.
The best calibration is with a calibration tool. I use a fairly cheap one called a Huey Pro, from Pantone, which is probably out of production. Anything’s better than nothing. But without this, you can get a decent calibration if you have a color-aware application (like Photoshop) and a color profiled printer, like pretty much any Epson. Print a test pattern, a photo, etc. and compare to the colors on your monitor. Adjust accordingly.
Now take those same photos and test patterns to your TV. Adjust accordingly.
Also, check your DVD collection for any DVD with the “THX” logo on it (or see here: https://www.thx.com/home/dvd/search.html). THX DVDs include a short color calibration segment (“The THX Optimizer”) that will offer a very specific series of images to help you set dark levels (adjust brightness), light levels (adjust contrast), and color properly. You can run this on your PC, too.
-Dave
-
When I did my original benchmarks (on a Notion Ink Adam, running the same Tegra 2 as the Xoom) I was on Android 2.3. The most objectionable thing I found was that the player itself was broken.
The occasional bit of jerkiness is usually easy enough to avoid in a good media player design, but not the end of the world. All consumer-level players on PCs have to account for the occasional bit of PC overload, so they double or triple buffer the video, and they sync video to audio. If the video decoder gets behind, they’ll drop a frame — simple enough.
Only, at least in Android 2.2, that didn’t happen. It sure looked to me as if the audio and video were being processed by unrelated threads. Not a problem up to 6Mb/s with Main Concept AVC, 720/24p I think I was running. But much beyond that, and it wasn’t glitching that was a problem, it was the audio walking away from the video, as the player endeavored to show every video frame. There probably had to be a limit on the de-sync, but I didn’t find it.
That issue could easily be solved by a proper player design. As I have ICS on there now, it’s probably time to try it again and see if they actually did fix it (I reported the problem.. know a few more people at Google these days, though not necessarily involved in Android). All Tegra2 AVC decoding is supposed to be done by a special processor on the Tegra (not the GPU, but a special video decoder module, usually the case on ARM SOCs), but there’s no telling if all implementations use this… and some of the nVidia stuff is still closed source, so I may be seeing worse-case performance than an OEM build would today.
-Dave
-
DVD Architect is not the best place to make the MPEG-2 for your DVD. But the settings for it are in the project settings panel. Usually, DVDA defaults to 8Mb/s CBR encoding, which is pretty close to the maximum quality rating for DVD.
On the other hand, it’s questionable when the last time DVDA got an update of its MPEG-2 encoder. So I’d use Vegas anyway. Unless you have around an hour’s worth of video, you are not going to fill a DVD. The maximum bitrate technically is a bit over 9Mb/s, but one normally leaves a little room for audio. For larger projects, going to 2-pass VBR (variable bit rate) will allow the encoder to use more bits for the busy parts and fewer for the static parts. But this doesn’t get you anything if your video is short enough to not use up the whole disc.
-Dave
-
Agreed. I have a Cowboy Studios CN-160… you can get two for under $100, and have plenty of money left over for beer or AA cells. And yeah, it’ll take a couple of different camcorder batteries as well, though nothing I own :-(. The panel is fine, comes with diffuser and color “gels” (well, they’re hard plastic, but do diffuse and/or change your color temp), and there’s a dimmer. There’s also an LED battery gauge, which is pretty handy.
I’m not much of a light guy… I hate shooting in artificial (on-camera) light. But when you can’t avoid it, you need something or you don’t get the shot. I was more than willing to give one of these a try, before plunking down three-or-more bills on a similar Litepanel unit.
-Dave
-
If you’re looking for lighter weight files for editing… you’re not getting that. In fact, AVC in an .M2T wrapper and AVC in an .MTS wrapper are essentially the same thing… the wrapper is MPEG-2 Transport Stream in both cases, the AVC video (aka H.264, aka MPEG-4 Layer 10) is the thing that your PC can’t handle.
Rendering to an .MP4 file doesn’t do anything for you either… that’s still AVC, just in a different file wrapper. Add to that the fact that Vegas 9 has problems with some .MP4 files (probably not those rendered by Vegas, but you never know).
Try rendering to a similar format in an MXF file. That’s a high bitrate professional MPEG-2 format, which is dramatically easier for your PC to decode. That’s the one that’s built-in to Vegas that I would use as an intermediate file. I have never seen Vegas go over 8GB use (on a 16GB system… I got the memory upgrade for photography of all things; kind of went my 10Mpixel -> 18Mpixel upgrade), so you’re fine on memory. And if that’s a 1.5GHz single core or Pentium, you really don’t have a PC I’d recommend for HD editing. Though I’ll admit to having done it on a pretty slow machine myself in years past, not one that slow.. even my six year old laptop has a dual-core Core2 at 2.4GHz. And I wouldn’t do much AVC editing on that bad boy.
-Dave