Dave Haynie
Forum Replies Created
-
[Stephen Mann] “Remember that Vegas started as an audio editor. (I believe that Video was added in Version 3).
Actually, Version 2 added video. I started with Vegas Pro (the original audio-only version), and have owned most since then.[Stephen Mann]
There was no GPU in the picture. No graphics, no GPU. Vegas was designed from the beginning to be hardware independent – it would run on any Windows PC and there was no special hardware requirements. It was this framework that Vegas developers were working with when they introduced video. It was an evolutionary addition to the audio product.”You’ll also notice that original Vegas knew not a thing about multiple processors, SIMD instructions (SSE, etc), or the x86-64 instruction set. Yet, it evolved to use each of these resources just dandy, and without most users really paying much attention to that fact.
Vegas is not hardware independent — it’s dependent on an x86 processor of some kind. But even that’s pretty flexible. GPGPU (General Purpose GPU) computing is actually far less hardware dependent than that. Using an API like OpenCL, you use a GPU if one exists, and if it’s there, the API (in theory, anyway) isolates you from the low-level details of the specific GPU. So add more processing cores, go from nVidia to ATi, etc. and things just work. Or at least they will once OpenCL is stable. It may be… it’s been a bit behind CUDA (nVidia’s proprietary GPGPU API) and Streams (ATi/AMD’s proprietary GPGPU API).
We’ve seen this all before.. in the OpenGL library. Vegas doesn’t use this much, maybe in a couple of 3D transitions. BCC uses it quite a bit. OpenGL will actually run on a very basic PC today, but when you add a good GPU, things get dramatically faster. Still very hardware dependent.
And these are OS-level things. I think the point of Vegas was never to ignore the better resources of evolving PCs, but simply to not require special hardware in order to function well. In fact, Vegas has supported custom hardware… I could use my DV camcorder as a display, driven directly by Vegas, long ago.
[Stephen Mann] “If Sony tried to rework Vegas to use the GPU for preview, it simply wouldn’t be Vegas any more. And we probably couldn’t afford it.”
In what possible way would it be different? Did the fact that Vegas went multiprocessor make it “not Vegas anymore” or unaffordable? Didn’t seem to, IMHO. GPU support is nothing more than yet another computing engine to tap.
And in fact, I don’t believe Vegas can survive in the long run without using the GPU. The era of GPGPU computing is upon us. Many people want to use those 400-800 stream processors they paid for, in addition to the handful of x86 processors. If Vegas doesn’t support this, people will ultimately leave for NLEs, like Premiere, that do.
And on a personal level, I don’t like seeing Premiere ahead of Vegas on anything. I used Premiere 6.something back in the dark old days, and it was heinous. You had to convert any form of video into the Premiere internal format before editing, it had all the audio and video tracks you wanted, as long as that was 3 and 2, respectively (or something like that). Audio was very much somewhere between a second class citizen and an afterthought.
Once Vegas grew video features, it was like stepping out of the stone age into the modern age. I could just drop a DV capture into Vegas and it worked, no issues with conversion, or the fact that Premiere didn’t support any DirectShow CODECs (only VfW). And yeah, while I certainly realize Premiere has improved, and they got to toss out a great deal of heinous stuff by going from “Premiere” to “Premiere Pro” (it’s always a bit of a risk to change you UI too much, even when it needs it), it’s clear that, in many areas today, Premiere Pro is ahead of Vegas. And runtime rendering speed is a biggie.
-Dave
-
[Stephen Mann] “The more I think about how Vegas non-destructive editing works, the less likely, I am certain, that the GPU would ever be used for preview. Or could, for that matter.”
As an Engineer with a collective 38 (ouch!) years of software development experience (hobby and pro, both), I would have to disagree with that assertion.
[Stephen Mann] “Vegas does not edit directly on the video media like Premiere, FCP or Avid. Instead, everything you do on the timeline is in the veg file (or memory if you haven’t saved the veg file). During preview or rendering, Vegas applies the instructions in the veg file for each frame of the media on the timeline and output to the resulting video or preview device. You never touched the original media.
None of those programs routinely do destructive editing.Here’s how accelerated rendering in Vegas would work. Conceptually, today, you have CPU-driven rendering. You have N media files in encoded form. Vegas had to read in the encoded format, via some CODEC or another, decode that into a frame buffer. Lather, rinse, repeat for each video or still in a composite. Next, each of these frame buffers is composited, via various rules that you’ve set up (compositing parents and children, masks, etc). Once that’s all done, whether for preview or output, that final video is submitted to the preview output device: a real graphics card frame buffer, an AVC or MPEG encoder, etc.
Now, sure, there may be some shortcuts to speed things up for preview, but that’s the job that absolutely has to be done, regardless of the various simple details.
Now, consider just the decoding phase. Right now, that’s done with my CPU. I know from benchmarking video playback that, for example, my AMDx6 will take about 40-60% of all six CPUs to deliver a realtime decode, into the GPU frame buffer, of a 1080/60p video in TM700 28Mb/s AVC. If I use a decoder that uses a graphics card and the DXVA 2.0 video acceleration API, I’n now down to about 6% CPU (given my fairly ancient nVidia GeForce GT8800 card).
It’s a given that the decode is path independent… whether the CPUs do it, the GPU helps, or I get a card with magic AVC elves on it, the decoder is a black box: AVC in, raw frame buffer out. Now, the final format you get via DXVA may not be what you want in Vegas, so we might not expect to see that degress of speedup using GPGPU code (CUDA, OpenCL, Streams, whatever) versus the dedicated video acceleration API in Windows. But if you can write a GPGPU program to even do just that one operation, encoded video to raw framebuffer in RAM, the video preview AND rendering will go faster.
In fact, AVC decoding can be a fairly big part of the rendering time, even for simple operations. Even a simple render from Vegas to any kind of output will be demonstrably slower if the source is AVC vs. MPEG, Cineform, or any other lower overhead CODEC with a well tuned CODEC (I was going to say DNxHD in there too, but I think it needs some performance tweaking).
[Stephen Mann]
Vegas does this one frame at a time. To get anything to the GPU, Vegas has to first assemble the frame from the instructions in the veg file. There’s just nothing left for a GPU to do. “Again, no way, Jose! Vegas is indeed interpreting the instructions (it’s running instructions in memory, not stored in a .veg file… these are loaded into RAM when you open a .veg file.. but the idea is correct). This is a set of higher level operations. A Veg file does not contain, for example, a separate composite instruction for each frame… Vegas just had a compositing engine that works from a pointer within the project, and does a frame at a time. The work the GPU would do would be helping to accelerate each of those tasks. In short, it’s doing exactly the same functions the CPU does now, only in parallel with the CPU, and hopefully, much faster than the CPU can do them.
-Dave
-
The Main Concept AVC CODEC only comes with lower resolution presets. But it’s perfectly capable of rendering higher resolution output. It does variable bitrate, which the Sony AVC CODEC does not; on the other hand, Sony can do High Profile, while Main Concept can do only Baseline and Main. Not that anyone particularly cares for a YouTube upload.. YouTube these days will take just about anything, but I can’t swear I’ve seen improvements on the final YouTube results going much beyond 6Mb/s (I have uploaded 20Mb/s clips, just to see what would happen).
The one weird thing I’ve found recently: I can get smooth 720/24p playback at 6Mb/s (with peaks to 8Mb/s) on my Android tablet (Tegra 2 based) via MainConcept, but only 4Mb/s via Sony. And Baseline, Main, or High (for Sony) all produce the same result. Weird.
-Dave
-
24p is fine. The one issue is that, like every tape-based camcorder, the TM700 stores 24p as 60i with pulldown. That’s an annoyance, and technically, it could use a bit less compression if it kept it as “native” 24p, since the duplicated fields would not be necessary. This seems to be an act of intentional sabotage by Panasonic — older consumer models, like my daughter’s SD9, as well as higher end models like my HMC40, store in native 24p.
The main reason this is annoying is that Vegas doesn’t detect that it’s 24p in pulldown, so you need some other means of dealing with it. I use Cineform, which does understand the 24p in a 60i wrapper for pretty much every camera.
The other annoyance in the TM700 is that there are not one, not two, but THREE separate mechanisms for setting your shooting mode. On the HMC40, there’s an on-screen pop-up that lets me select any resolution and bitrate that’s supported: 1080/60i, 1080/24p/ 720/60p, whatever. That menu exists on the TM700 too, but it only offers 1080/60i modes there. If you want 1080/60p, you press a button near the top of the camera. If you want 1080/24p, you have to dig down a little and set “Cinema” mode.
I have used 24p and found it good. In particular, when it’s dark, I can shoot at 1/24th sec. if necessary.. big advantage over 1/60th min that’s really needed for 60i.
-Dave
-
And yeah, I concur about the HVR-A1. It was brilliant, 5-6 years ago. I bought the Panny HMC40 after seeing some video from it, and have not had occasion to return to my A1. The TM700 (and the slightly upgraded TM900 — autofocus improvements, mostly) use the same sensors as the HMC40, but my TM700 was less than half the price. Makes a nice walking around camera, or a great B camera when used with the HMC40.
I’m more recently nuts about the video from my Canon 60D as well. But make no mistake – the DSLR is a different kind of video device. I like having one, but most of the time, I wouldn’t choose it if I had to bring only one camcorder. Unless I knew ahead of time I’d be shooting short events in the dark 🙂
-Dave
-
I’ll counter that AVC/AVCHD claim. It’s well worth the trouble, largely because it’s higher quality than anything you can touch on tape for anywhere near the price.
If your PC isn’t fast enough for it, a new PC isn’t all that pricey… I upgrade an older PC to AMDx6/3.2GHz last fall for about $400. But can also transcode to Cineform ($100) or DNxHD (free) for much more responsive HD editing with virtually no quality loss (and in fact, you may gain for complex, layered edits, because you’re editing in 4:2:2 rather than 4:2:0).
And tapeless is a big win, too. Not just the faster workflow, but the fact that memory doesn’t have to run at a specific speed. So you can shoot different bitrates and resolutions. Real 24p (though I think the HV30 does real 24p, only it has to encode it as 60i to match the tape format… DV/HDV didn’t really take 24p into account when designed), 30p, 60p, 60i, all in the same camera.
I was using Sony and Canon on tape, but switched to Panasonic for digital. They just seemed to have the best technology and the best prices, though certainly Sony and Canon have improved a bit since then (though neither sells a 3-chip camera for under $2K). I have both HMC40 and TM700 units. The HMC40 has an XLR module, kind of the same idea as my Sony HVR-A1, only optional, but very much made for the camera, not a clumsy add-on like a Beachtech unit.
If you really like Canon, they’re kind of doing a modern spin on the HVR-A1/HDR-HC1 pair, in the new AVCHD XA10/Vixia HF G10. These both use the same single chip CMOS sensor as the XF100. I’m personally a bit concerned about a single full raster Bayer sensor with respect to color fringing issues, but apparently Canon think they’ve made the world’s best 1/3″ sensor (you get three if you spend up to the XF300).
-Dave
-
I played a bit more with video on the Adam.
I found that, using Sony’s AVC encoder, I get perfect video at 720/24p@4Mb/s, on either baseline, main, or high profile. When I bump this up to 6Mb/s, I start having issues. And going to 1080/24p at 4Mb/s, same issues.
The issue here is de-sync, and it’s pretty clear what happens. The player isn’t quite keeping up with video decoding. But it doesn’t really do anything about that. So audio slowly walks away from video, and you wind up at the end with just the video playing. The proper action is to drop frames to keep up with the video, but none of the Android players I’ve tried will do this. This was kind of a 1980’s innovation, if not earlier, so I’m actually kind of shocked it’s not being done here.
But I had seen both WMV9 and MPEG-4/AVC play just dandy before at 6Mb/s, so I did a few more experiments. Seems that Main Concept, 720/24p, main profile, VBR, average 6Mb/s, peak 8Mb/s, plays just dandy on the Adam, no lost frames. We don’t have the controls over GOP we did with MPEG-2, so I really don’t have a good explanation of the difference here, but there it is. This also helps explain why some folks online have had more trouble with x264 encoded samples: the Tegra encoder must be sensitive in ways not yet fully qualified.
I tried 1080/24p at 4Mb/s from Sony and the same 6/8Mb/s with MainConcept. Neither plays without lag.
-Dave
-
Not denying it… particularly if you’re viewing on the device. Apple so far only supports 720p, and I think they limit it to base profile, even on the iPad 2. Then again, those of us wise enough to go for Android at this point must demand more!
Probably not a consideration at 3Mb/s or so, but the speed of the flash may also be an issue. I guess the Xoom has a big chunk of NAND flash internally… any idea how fast it is?
Just for yucks, I tried a YouTube video from a few years back. This is 720/30p AVC, encoded at 6146kb/s (including 128kb/s AAC audio), something derived from the original “Internet” AVC profiles, I’m sure. Dropped this onto a plain old USB stick, put it in my “Adam” tablet… plays perectly well, not a hint of a skip or jitter. Same video, in 720/30p 6Mb/s WMV also played just as well.
I tried a 720/60p video I had lying around, also about 6Mb/s. It played with a tiny bit of jitter… and in slow motion. Tried a higher bitrate MPEG-2 HD file.. not dice. No surprise, either, mobile devices are really looking for MP4/AVC.
Now this is on Android 2.2, not 3.0. I got much the same results with three different video players (stock Android, ES File browser player, and a customized player that’s part of the table software bundle.. not sure what the difference is).
-Dave
-
The Xoom should take videos up to 1920×1080/30p, but don’t use High Profile. John’s recommended Internet Profile is probably a good starting point… you don’t need anything beyond 720p for the tablet itself (maybe if you’re sending HDMI to an external screen).
I received a different tablet, based on the same Tegra 2 SOC, on Friday… have not had a chance to tweak video for it yet. But probably soon.
-Dave
-
[Mac McGinnis] “What problem will I see if using an ATI Radeon HD 5770 1024MB video card instead of the Nvidia?”
No problem. At present, Vegas 10 uses nVidia’s proprietary CUDA library for GPGPU (General Purpose Graphics Processing Unit) computing. Best as I’ve been able to figure, this can deliver maybe 6% (maybe less) improvement to renders, with the Sony AVC CODEC only.
AMD (nee ATi) uses a different proprietary GPGPU library called Streams, which has far less support among apps. Like, no support in Vegas.
In the future, we will hopefully see things move to standard libraries. The two you’re likely to encounter are the open standard OpenCL, and Microsoft’s DirectCompute library. Neither is well supported today, but once they are, any GPU will work with such accelerated applications.
For other things, either one may be just dandy. For example, plug-ins like Boris’ BCC7 use the GPU for acceleration, but primarily (or perhaps entirely) via the OpenGL library. That’s supported on any GPU, the faster the better, for effects that use it. Far as I know, few if any of Sony’s stock FX are OpenGL accelerated.
[Mac McGinnis] “Also, I have only 9GB of RAM as opposed to 12. What problem will this present?”
While kind of an odd amount, that’s perfectly fine. My main system here has 8GB, and while the price of upgrade is pretty tempting, I can’t honestly say I’m ever running out of RAM… this week.
-Dave