Forum Replies Created
-
Dave Haynie
October 19, 2010 at 1:11 pm in reply to: Why the poor 64bit performance compared to 32bit in Vegas 10?That’s weird. I noticed right away that Vegas 10 was faster at playback of at least AVCHD in 720p (I have some 1080p and 1080i projects on the way) than Vegas 9, and I’ve only bothered installing the 64-bit version so far.
One possibility … since you skipped Vegas 9, this is probably your first time using 64-bit Vegas, right. Any chance the CODEC for that video playback is different for 64-bit versus 32-bit? Since Vegas works from the native formats you’re using, it is at the mercy of some system level CODECs. Like other plug-ins, you need 64-bit versions of the video subsystem stuff, at least for optimal performance (not sure if it works at all, or just goes slower).
Your rendering performance in 64-bit stands to reason if your preview is slow. Usually, video decoding is not a significant overhead, but when it is, it obviously will add to the rendering time, since your input format must be decoded before any compositing or rendering can take place.
If this isn’t a common SD format, try transcoding it to something common, like DV, and see what Vegas 10a does with it.
-Dave
-
Blu-Ray for the former NTSC countries should be in either 1920×1080/60i or 1920×1080/24p… of course, actually 59.94 fields or 23.976 frames per second. Both are perfectly legal Blu-Ray. Most films are distributed in 24p, most television is distributed in 60i (though sometimes you’ll find 1280×720/60p, as that’s also a Blu-Ray and ATSC option).
Your best bet is to deliver in the format you shot in, if possible. If not, something close.
-Dave
-
Dave Haynie
October 19, 2010 at 5:10 am in reply to: Sony Vegas Pro 10 GPU ..What, where, when….No Way!In most RAID senarios, adding drives will speed up both reads and writes, but also increase latency. These days, latency is not usually an issue, but it’s easy to see why this is so. When you read or write from a single drive, you have over time an average latency to get the data, but sometimes it’s a bit faster. With a RAID, you actually have to wait for each drive to seek, so for any seek, it’s the worst actual case of all drives, even if the overall average seek time is the same.
Without a dedicated controller, the overhead of the RAID is exposed to the user. When its something like RAID0 or RAID1, there’s virtually no overhead. RAID5 does have overhead… nothing like “devoting a whole core” on a modern PC, but sure, it’s very measurable. Better RAID controllers devote a separate processor to run the RAID itself, and also buffer writes… so you actually hide nearly all seek time for writes, at least with the better controllers.
-Dave
-
Nope.. every modern video editor does non-destructive, realtime compositing. And there’s absolutely no reason you can’t use the GPU to help out at this — that’s kind of the point of GPUs — lots of massively parallel operations.
This was true even ages ago. There was a time when Premiere couldn’t edit native files… I used it long, long ago when it had to produce some kind of proxy file for editing. And even then, the edit-time preview was done in realtime, just like Vegas, just like pretty much any other video editor. Like Vegas, I believe you can also pre-render video in Premiere Pro, but it’ll happily try to play with realtime rendering, just as Vegas does.
The really unique thing about Vegas had long been the ability to not just edit native file formats, but to freely mix and match different ones on the same timeline. I think some editors still have issues with that, or with changing the output target in the middle of the project, that sort of thing.
And of course GPU could help here. You’re right that ultimately, you are compositing per-frame bitmaps… that’s summing numerous bitmaps, based on transparency, masking, etc. This is pure math… you COULD do this on a GPU — we are talking about CUDA here, it’s a math engine, nothing all that specific to graphics anymore. But maybe compositing isn’t an ideal use for this.
CUDA, OpenCL, Streams, etc… are all instanced of “GPGPU” APIs… general purpose computing using GPUs. Graphics itself made sense for this, particularly 3D, since it’s easily parallelized. Older GPUs were only applicable to graphics, working as a series of hard-wired blocks in a graphics pipeline. But modern GPUs replace those hard-wired blocks with hundreds of programmable elements. So while they work well at graphics, they can be used for many other kinds of parallel mathematics. nVidia even has a series of “GPUs”, the Tesla series, which don’t actually even have graphics output anymore: they’re only used for general purpose parallel computing. Some articles:
https://gizmodo.com/5252545/giz-explains-gpgpu-computing-and-why-itll-melt-your-face-off
https://gpgpu-computing.blogspot.com/How about all of the work that gets you to the point where those bitmaps exist. You have video files on disc, probably not stored in RAW format. GPU decoding of AVC or even MPEG-2 can be considerably faster than CPU-only decoding.
Then there’s plug-ins, effects, color corrections, etc. that’s what Adobe CS5 seems to be using the GPU for as well. You’re applying some kind of math intensive transform to the bitmap that results from the decode of the on-disc video. GPU computing can help here, too. The point of the GPU isn’t graphics operations, it’s general purpose match operations, taking place on hundred’s of computing elements in parallel. Each one isn’t as powerful as your CPU, but together, they can do 50x-100x the work of a single CPU core, depending on the nature of the work.
Here’s a decent article on how this works: https://tech.icrontic.com/articles/reviews/a-case-for-gpu-computing-adobe-premiere-pro-cs5-and-the-mercury-playback-engine/
-Dave
-
I generally upload in AVC. Most of my stuff is using one of the Internet AVC templates, maybe tweaked a bit… but ultimately, around 6Mb/s for a 720/24p or 720/30p upload.
Last June, I did a couple of same-day wedding uploads while staying in California in a place with really great Internet, and did 1080p uploads at 20Mb/s. It definitely looked better playing back at 1080p, which practically no one can do from YouTube. The 720p stuff was limited by YouTube’s deliver rate… no difference from the 6Mb/s 720p stuff I had done before.
-
Dave Haynie
October 13, 2010 at 6:11 pm in reply to: Mulitple 4K RED R3D files playback – computer specs neededThe video preview RAM is only for, well, RAM preview. As I understand it, if you don’t select a region and select “Build Dynamic RAM Preview”, this doesn’t get used. Vegas manages the caches and all for normal rendering/compositing on its own.
I would assume, if you’re using Red footage, you’re at least sometimes (color grading, etc) editing in 32-bit mode. That’s 32-bits per color, rather than 8-bits, as I understand it. So that’s 4,096 x 2,304 x 4 x 3 = 113,246,208 bytes per frame. In 8-bit mode, sure, it’s only 28,311,552 bytes per frame. But either way, it’s still 4x more of everything than the same stuff in 2K/HD. And I’ve found 2GB limits kind of on the edge of where HD editing starts to get good. Last year, I upgraded to 64-bit Windows 7, laptop and desktop, specifically to run 64-bit Vegas for HD editing. I do electronics CAD on this same PC, and that’s totally happy in 32-bit, even with 3D preview. Video is by far one of the few remaining Big Problems for home/small office computing.
-Dave
-
I don’t see why GPU rendering couldn’t be used for preview.
For example, just take something fairly time consuming like AVC decoding. On my fairly fast Q9550 system (quad core, 2.83GHz) it takes a pretty serious effort with a multithreaded video player to play back 1080/60p AVC video (admittedly, fairly high spec compares to many formats)… 60% or more of all CPU.
But plain old everyday Windows Media Player uses just 12% CPU, in conjunction with the new Microsoft AVC CODEC. This uses DVXA 2.0, not even CUDA or OpenCL. Supporting just that level of acceleration, I ought to be able to get full 60p playback with at least modest compositing on 3 AVC streams in Vegas. Can’t do that today, though Vegas 10 does seem better at AVC than Vegas 9. This seems to be what EDIUS Neo is doing, and why it’s so much faster at AVC than Vegas (I got this free with my HMC40, and while it’s a painful program to use in pretty much every other way, it’s certainly an existence proof that Vegas could be much, much better at this).
Adobe’s thing is using the GPU more for compositing and FX than decoding. I can’t imagine their non-destructive editing system is profoundly different than Sony’s, and yet, they’re getting very significant acceleration in Premiere CS5.
-Dave
-
I kind of like the nested projects approach, but I’ll admit I have used the FCP/Adobe mechanism. And here’s the thing… can you nest the alternate timelines in FCP?
Using the Vegas method, my alternate final projects can be composed themselves of alternate subprojects, etc. Sure, eventually you may run out of CPU power, but there’s no obvious limit. It seems like handling this at a single editor level would be unwieldy, fast. Do they support multiple levels of this, and/or Vegas-style project-as-an-asset use if they don’t? If not, I’ll take the Vegas approach.. even if it’s not quite as easy as you claim these others are, the power of it seems to make it worthwhile.
-Dave
-
After slightly over a year, the Cineform tech support people actually helped me on this.
I wrote about the failed upgrade. Turns out, their registration system had somehow merged me and some other user… so they wound up taking my second install and my upgrade. Whoops.
They may find this one innocent, but it’s a clearly flawed system. For one, you can register just based on your serial number. They ought to have a more secure system, where you have to create a login with password protection and enter the serial number — that way, you have a single point of failure at least for the S/N… if it hasn’t been compromised, you’re registered and then only you can do any new activity (installs, de-installs, upgrades) based on that number.
With that said, the very latest Cineform Neo 5 beta seems to work in Vegas 10. I had already deleted the Cineform files I had planned to use (still have the originals, of course), so this didn’t actually solve my initial problem, but in the long term, perhaps. I do like the Cineform product, it’s just that their registration/authorization system is seriously broken.
-Dave
-
No solution, but I’ve run into the same problem… only owned Vegas 10 for a few minutes so far, though. It’s also choking on my GearBox plug-in.
Particularly weird, since the online spec/blurbs for Vegas 10 specifically claim that it supports Cineform. Which really ought to be a redundant claim, since Cineform is under DirectShow/VfW, so no special support ought to be needed, or even particularly useful, unless Vegas is doing something special to improve the workflow.
They do qualify it as “Version 5.1 or later”, which doesn’t seem to relate to my Cineform NeoScene at all (V1.6.1?). Looks like 1+1 = 5 at Cineform. Anyway, I guess I have to order the upgrade, which isn’t too expensive, so I’ll try that and see what happens (knowing Cineform, it’s not going to happen tonight, but it would be great to be wrong).
Well, no, didn’t order the upgrade. Cineform has the most flawed registration system yet devised. They screwed up my initial purchase, and I had a hell of a time getting the program authorized. Now the registration server tells me my copy has already been upgraded… it definitely has not.
I think I’ll take another look at Avid’s DNxHD….
-Dave