Dave Haynie
Forum Replies Created
-
Yeah, that’s what I guessed.. you have an MPEG-2 TS file, which includes streams for AVC and for AAC. The importer for this kind of file in Vegas seems to be a built-in, it’s not being run via Microsoft’s DirectShow, which is what most players will use.
That might be a good decision, technologically, I don’t know. Vegas has this weird mix of doing file import via Video for Windows, but using DirectShow (until recently) as the only plug-in architecture… a Windows standard, but not an industry standard for video plug-ins. But the needs of an editor aren’t necessarily aligned with the needs of the player, so maybe they have a good reason for this.
Anyway, in the TS stream, each stream is identified by a pre-defined code… you see that as “ID” in your dump. For any reader, it either knows that that means, or it doesn’t. The MPEG-2 Transport Stream is used largely because it solves the problem of digital video transmission well, no need to change it. But new media types need their IDs… and the ID for AVC in an TS file was established by AVCHD, if not before. But AVCHD uses AC3 as its audio CODEC, not AAC.
There are camcorders that leave behind the AVCHD spec for maybe a more generic MP4 file wrapper. AAC is basically the standard audio format for MP4, though I’m sure others are supported.. at least in some readers.
Ok, enough with the story… here’s a real life thing to actually try. Go find “YAMB”, download it, run it. See if it can figure out your .TS format, export to .MP4. If it understands the AC3, it may be able to create a legal .MP4 file that Vegas understands.
Another alternative… Go find “VLC”, load up your file. It almost certainly plays, with audio.. VLC is like that. If it does, find the conversion tab, and just write out an audio file, convert to WAV or whatever. Then load that in Vegas aside your already imported AVC, check that there’s no audio sync loss, and you should be good to go.
-Dave
-
Hey.. I type fast.
Oh, if you have a dual CPU unit, you definitely want more threads — at least one thread per core is what I recommend.
I haven’t done a scientifically proper study on the effect of extra threads (eg, more threads than cores). If there’s sufficient stalling while threads wait for I/O, you might benefit from a couple of extras. The main point is, at least one thread per core. If you add too many, you might get into drive thrashing (too many seeks) and also memory issues, since each thread will need some real resources. Sounds like another interesting experiment (damn! I was planning to play with Win8 this weekend, and my new TC-Helicon vocal stomp-box, and I have two unfinished videos in the works, and … ok, maybe not too soon)…
[shane etter] “also, my buffer setting was at 128mb. i have 8gb of RAM altogether. should i make it more or less? “
That’s probably ok.. you have lots of cores, and don’t want to starve them. Rule of thumb is 2GB per core, so you’re ok, but not likely to have tons of extra memory. I have found performance increases going to more than zero, and I found no value on my system beyond 1GB (but I have only six cores and 16GB RAM). You could try a short rendering benchmark and see if you see any differences between 0, 128, 512, and 1024 (eg, 1GB). I’m also not certain how the amount of buffer memory relates to the number of cores… if Vegas is tapping this memory for rendering, which a bunch of us believe is true, it’s very likely that more CPUs want a little more memory.
Vegas has always been opaque on this. As mentioned, I “grew up” dealing with these issues in the audio world. Once Cakewalk added audio, they were very clear about the various buffer settings, so I knew exactly where memory was being used. And, particularly with the primitive PC HW of the 90s, you needed to know those things to tweak up a system. I have Vegas well tuned, but it’s more trial and error… just where I found (and others, working independently) that the RAM preview memory was actually a factor in rendering, too. Like I said, opaque.
-Dave
-
If this is the class of “error can’t be determined” that you get immediately, could definitely be your settings.
I had a number of higher bitrate presets, things I’ve been using for years, like 50Mb/s CBR MPEG-2 output, things like that. When I first got Vegas 11, I found a number of these templates errored out with the same sort of message.
I know basically what’s happening here. For rendering, Vegas is spawning a subprocess that’s using independent modules, such as the Main Concept CODECs, etc. I think the design here is such that Sony’s pretty much expecting the Vegas UI to do all the bounds checking for each of these. So they expect the subprocess to pretty much just work… and they fail completely when the subprocess rejects the render, for whatever reason. Clearly, in the case I found, I had parameters that were just dandy in the old version of the Main Concept MPEG-2 engine, but considered out-of-bounds by the new one (I ultimately fixed this by going to a slightly lower bitrate).
I guess I’d find it a little suprising, but maybe less so after my initial experience with Vegas 11, that this might change in-between Vegas 11 releases. Or maybe this was a template you hadn’t used before with Vegas 11. Either way, that’s the one source of this kind of error I’ve run into before, and with at least a credible explanation.
-Dave
-
[shane etter] “I should have mentioned that on the side, i run this pc as my main DAW with latency in the microseconds, so im pretty sure its good and setup right. in Cakewalk Sonar X1, the developer confirmed you needed a tweak to allow Sonar to handle more than two processors at a time. Also Windows 7 needs some tweaks. “
Windows does actually have what’s come to be known as “soft realtime” performance. It’s not the same as a full fledged RTOS, but even that’s not what most people think it is. An RTOS isn’t necessarily super fast… the point of an RTOS is to be super predictable. An RTOS formally specifies things like maximum task switch and maximum interrupt latencies, it does thread priority elevation to avoid deadlocks, etc. For purposes of running Vegas or Sonar or other media programs, Windows IS realtime. For the purposes of controlling a nuclear reactor or a spaceship, not to much.
[shane etter] “Can anyone with more than 4x CPU’s confirm that Vegas will utilize at or near 100% of the available CPU?:
To actually just answer the question: Yup. I run a six core AMD 1090T (3.2GHz) and 16GB RAM. I usually see over 90%, often close to 98%, when rendering CPU-only (more on that later). It’s going to depend on many things, and the more complex your project, the more potential for weirdness to creep in.
There are several possibilities here. One is the easy one, and the one you alluded to with Sonar (I’m also a Sonar user): settings. Look at Preferences/Video, and you’ll see a few tweakables there. The obvious one: number of rendering threads. If you wanted to ensure Vegas never went beyond 50% CPU utilization for rending on a quad core processor, set that to “2” and you’re there. This should normally match the number of cores (real or virtual might be a bit more of a science project, if you have an i7).
The next tweakable there that will have an effect on performance is the Dynamic RAM Preview setting. During editing, this is the chunk of RAM Vegas allocates to use for a RAM preview buffer. Experimental evidence from a bunch of us here suggests that this is used for buffering during rendering. A relatively small amount here will speed up rendering, as you would expect RAM buffering to do. Large values may starve your system of RAM that would better be used for other stages of rendering.
After the small bits of tuning possible, check the use of any plug-ins. A good, modern plug-in can be multithreaded; a not so good, not so modern plug-in may not be. Certainly, if you ever see performance drop to “essentially one core”, try disabling some plug-ins, particularly third party, and see if it just snaps back.
Well tuned Vegas can very readily deliver 95%-99% CPU utilization on rendering, that’s usually what I’m seeing… with a few caveats related to where you bottlenecks live. The most obvious one is hard disc speed. As most people here probably know well, modern HDDs are fast… really fast. Any SATA drive worth still using should deliver read performance in excess of 50MB/s sustained, many can hit 100MB/s (you can pretty much ignore the SATA link speed, that’s a potential, but you probably only hit that on cash to PC transfers… HDD speed is a matter of mechanics). However, if you’ve been a DAW user for long, you may recall a time when PCs were pretty limited to the number of tracks they could support. Back then, it wasn’t HDD speed that really mattered, but seek time. Moving track to track is 1000’s of times slower than reading data along a track. So on DAWs, the number of audio tracks is usually limited by seeking, and you’re aware of this, as a serious DAW users, because you might routinely run dozens of audio tracks.
Video users don’t necessarily think in these terms, but the same physics still applies. Maybe you’re used to editing a single video track, rending it out, everything’s cool, you hit a 95% CPU use. Then you move to another project, and things hit a wall. I ran into that wall first back in 2006, on a wedding shoot that had not only two video tracks but very, very heavy use of 6-8Mpixel still photos (the happy couple had not one, not two, but three professional photographers covering it, in addition to my video). I was driving Vegas to its knees, rending was running at maybe 20%, etc. What I did was move the photo assets to a different HDD, render out to yet another HDD… and I was back in the saddle, getting full speed renderings (as one of my first full HD projects, it wasn’t pretty anyway… an hour’s AVC render back then took 28 hours on my PC and 24 on my laptop… the same dual core Core2 laptop I consider too slow for serious video work today). So use your DAW brain when thinking about what’s on disc.
And finally, there’s this great new thing in Vegas 11, if you ever move up from Vegas 9: GPU support. You will absolutely find that, at least on most systems, there’s an inverse relationship between CPU use and GPU use. As you get that GPU well used and well fed with data, the CPU has more idle time. So that’s simply waiting for a GPU job to finish. Like any loosely coupled multiprocessing scenario, at least some of the overhead is now spent in communications between the two, and there will be short gaps based on that protocol, too. It might turn out that some CPU/GPU combinations are an ideal match. But in most cases, you’ll see at least a small drop in CPU utilization, even if the GPU never runs much above 50% use (about where I see mine; I have a fairly speedy AMD Radeon 6970).
-Dave
-
PC DVRs often produce slightly weird files.
It could the combination of media type and file wrapper. For example, Vegas would expect AVC and AAC in an MPEG-4 file, but it would expect AC-3 or MPEG Layer 2 audio in an MPEG-2 Transport Stream or Program file.
Certainly some of this is due to Sony’s using their own built-in decoder/splitter for MPEG and MPEG-4 files, rather than Microsoft’s DirectShow system… at least last I checked. While you can technically put any audio or video type in any given file wrapper, there aren’t always respected standard for things like, say, AAC in an MPEG-2 TS file.
I’ve also noticed that some DVRs use just plain weird video formats; maybe intentionally so. For example, Microsoft’s recording uses a format called DVR-MS, which isn’t generally understood by video editors. A few others do weird modifications to .MP4 or .TS files… not sure why, but it happens.
-Dave
-
[John Bean] ”
Now how is it bailing when your test cases are skewed to best case scenarios?
“This is HARDLY a best-case video. Nor is it a worst-case video. It’s one that I could produce when the whim took me, that met all my criteria for a professionally done comparison test. This means a legally available video, with a very clean original in better-than-Blu-ray format. It also helped that much of the group also has this video downloaded… many of us were running the Sony benchmark last fall. For a proper test, the original must be available for comparisons, and I had no ability to upload such a file in the time available.
In fact, I thought the “best” of the bunch was kind of gimme. Last I checked, every response I got so far picked that one correctly.
[John Bean] “Plus, why I am going to waste my internet bandwidth downloading all of your test cases when its clear you skewed them towards a best case scenario?”
Your downloads are so metered a few 100MB is a problem? That can only be true if you’re on satellite… or dialup.
Why? Perhaps to be seen as a stand-up guy, rather than a troll? Or… as you previously suggested… maybe to actually learn something for a change, rather than just spew incorrect information.
[John Bean] “Do a real test like I suggested. Here they are again:”
This, again, is a completely real test. It’s done properly. If you prefer a different comparison test, feel free. But I strongly recommend you don’t steal other folks video and post or link it here. I know many of us have strong feelings against piracy in any form… as a published author in five media formats, I’m very much at the top of that list.
The second reason — the test is only a test of the encoding and upscaling methods if it uses the same source. A DVD is differently mastered, and will skew the result — and not always in favor of the DVD, either. DVD video rates require lots more motion blurring to avoid macroblock noise than the equivalent Blu-ray video. Plus, since I included a Blu-ray-class video in the comparison, I can’t use Blu-ray quality as my source video. I must have something of higher quality. Otherwise, I’m imposing the Blu-ray compression artifacts on all of those lower resolution versions.
Third reason — your test doesn’t actually test what I’m after. Yes, if you select a very busy action scene, even from some piece of drek like a Michael Bay film, you may get different results. The big problem with that is that, again, you need to start with clean video, which you aren’t going to get from either Blu-ray or DVD, even if you didn’t mind breaking the law in the process.
Plus, that doesn’t actually advance this argument. I have already told you that I believe that an upscaled DVD can, some circumstances, look very good… perhaps better than lower bitrate HD. I have no reason to prove that, and given that you have previously stated that you believe this always to be the case (you seem to be changing your tune here, but you did, twice, claim it was mathematically impossible, even though you couldn’t do the math), you should jump at the chance to view my samples and prove that you’re correct.
But you also misunderstand the test. You did inspire it, but I wouldn’t have wasted any time on that, even just sitting here trying to get Windows 8 to install on a VM (working now). There is one sample that, yes, is certainly the right answer. The rest of them… I really don’t know. There is not necessarily a second right answer. Maybe a few wrong answers, but this is video, and the goal is not accuracy or anything else, only what looks good to the viewer. My opinion, your opinion, everyone who’s taken the test — all valid. I’m interested in knowing which way things skew, because I have been digitally encoding video for over 20 years, and I find this an interesting thing to explore. This is NOT a trap, unless you make it one for yourself.
[John Bean] “2. Or, ask yourself, would you be willing to shoot your next video project with one of those $200 consumer camcorders that are 1080p with low-bitrates of 4-6Mb/s. I mean, it’s 1920x1080p, right?!”
I don’t actually know of any consumer 1080p camcorder with a limit of 4-6Mb/s… even the “Flips” that did 1080p recorded at 10Mb/s or so, and those are toys for children, not camcorders. I can think of several scenarios where I might run my pro AVC camcorder or either of my high-end consumer satellite cameras at low as 6Mb/s. Even the original HD Hero Pro ($199) does 1080p at 15Mb/s.. and LOTS of people use these for professional purposes (a friend of mine has some video shot on several of these debuting on Discovery Channel’s “Shark Week” this summer… of sharks, of course).
I wouldn’t choose a toy camcorder for a variety of reasons. While it might technically support 1080p recording, if this is the “Flip” style toy camera/camcorder you’re alluding to (Flip itself is defunct.. Cisco dropped the brand last year), these have lens apertures too small for the sensor, so they get all kinds of diffraction blurring, even before you start to record. They don’t have a enough computation power to do good AVC encoding, so in all likelihood their 6Mb/s is nothing close to the quality of my Camcorder’s 6Mb/s.
And that’s in turn not as good as the 6Mb/s I can encode in a PC using one of the better encoders around, 2-pass mode, all the time in the world for encoding. That won’t compare to my better camcorders at 24Mb/s or 28Mb/s, or my HDSLR at 44Mb/s. But it will look better than the 20-24Mb/s AVC produced by even high end consumer camcorders from, say, 2006-2007 vintage or earlier. AVC is a complex algorithm, and the encoder on a camcorder has to be able to encode in realtime at a power cost of probably about 2-4W or less. That’s why it wasn’t until 2009 or so that AVCHD camcorders exceeded the quality of HDV, even given the technically much better coding efficiency of AVC. To get a 2x gain in coding efficiency, you may need a 10x or 100x gain in computing power.
My cell phone also supports 1080p recording (stock at 10Mb/s, hacked up to 45Mb/s last I checked), and I probably wouldn’t shoot a film on it. That hasn’t stopped some people, however … Google for Hooman Khalili and Pat Gilles’ film “Olive”. You’ll find that a recent box office hit, “Act of Valor”, was shot on Canon 5Ds, which don’t even support the full range of the AVC spec (perfectly good AVC for sure, but they don’t have the processor performance to encode B frames, which is one reason they need to record at 44Mb/s… their 44Mb/s is not close to twice as good as the 22Mb/s-24Mb/s you’ll find on many “AVCHD” labelled camcorders. Good, yes, but not as good at might sound from the bitrate numbers).
-Dave
-
[John Bean] “I appreciate your efforts. That is the only way to learn.”
I have been learning for decades. You ought to try it sometime.
[John Bean] “So of course, the results will look good even at low bitrates.”
There’s plenty of motion in there. Others have already submitted answers, and they’re pretty much getting it “right”. If you’re planning to bail, it’s clearly because you can’t actually judge video yourself, you just like to play with numbers.
So I’m waiting. Put up or shut up. There are very clear differences between these. Here’s another hint.. the lowest bitrate represented here it 1/8th of the highest bitrate. If you can’t tell those apart, you’re nothing but a poser.
-Dave
-
Yeah… thinking about it, I believe I remuxed my AVCHD prior to moving it to the Mac. The video files did load, just way too slow to consider using. I’m sure I could have loaded DNxHD or persuaded the Mac to trans code to ProRes or whatever, but ultimately the downrezed AVC-Intra was good enough. I wouldn’t have chosen to do extensive AVCHD editing on Vegas on my laptop either, but it is at least possible.
-Dave
-
[John Bean] “Your claim that a YouTube 1920x1080p video at low bit-rates like 6 Mb/s is far superior than a DVD video at standard MPEG bit-rates like 8 Mb/s just doesn’t make sense mathematically, nor can it be validated with any visual comparisons.”
Do not put words in my mouth: you know very well that’s not what I said. What I said is that a 6Mb/s 1080p video may well be visually superior to an 8Mb/s DVD, when viewed on a high resolution display. I actually does make sense mathematically, but even more sense when discussing the cognitive psychology aspect. Since I minored in Cog-Psych, and have a BS degree in Math (and EE), I feel pretty qualified to claim this does make sense.
However, sir, I see your gauntlet thrown, and I happily pick it up. A battle of wits, to the death! The game starts here: https://forums.creativecow.net/readpost/24/945522. It ends when you choose, and we both drink!
-Dave