Dave Haynie
Forum Replies Created
-
It’s not too happy with “help” in the subject…
What you’re seeing is too much motion for the bitrate, basically. This is going to be a problem with enough camera motion on any intraframe compression algorithm, like AVC or anything else you can get on YouTube.
Basically, what happens in AVC or MPEG-2 is this: there’s a single frame, called an I-Frame, which is basically just a high-rent JPEG, I is for “Independent”. So that’s compression, but only within that one frame. Ok, so now, along comes another frame. Rather than just compress that frame again and make another I-Frame, these algorithms are way more clever. They run a thing called a motion search algorithm between that first frame and the next, and try to figure out what doesn’t move, what does, and where. This is encoded as a set of motion vectors. Ok, so now, those motion vectors get applied to the first frame to try to transform it into the second. Then the second is subtracted, and only the different (basically, the error) is compressed. For the usual amount of motion between frames, that works pretty well… the error frame, which along with those very compact motion vectors gets compresses as a P-Frame (P = predictive), takes up much less space than that whole high-rent JPEG.
You run into a problem in any MPEG or even JPEG algorithm if you don’t have enough bits to compress the image… you start to get big blotchy areas, visible blocking between the “macrocells”, the blocks (usually 16×16 pixels) analyzed by the JPEG algorithm, etc. And in AVC or MPEG, you start to run low on bits for proper compression when you have to much motion, which means the motion prediction doesn’t compress well enough, meaning that each error frame is full of stuff, which has to be compressed into the expected tiny amount of space available.
The other problem you have — you’re kind of defining worst-case here, is lots and lots of detail in the area: all the foliage, all the ground cover, etc… it had lots of high frequency information in it. That’s what gets removed when the JPEG encoding takes place… JPEG basically does a low-pass filter on each of those macrocells I mentioned, cutting down higher frequency information as much as possible. Worse yet, when it’s doing a bit too much compression, you wind up with “digital noise”, which is another kind of high frequency information, and not one you want… but the next round of compression doesn’t know that.
I couldn’t trick YouTube into letting me steal the 1080p version, but the 720p is just as bad. And it looks like you’re getting a variable bitrate (which is good) varying between 2.5Mb/s and about 5Mb/s. That’s definitely not fast enough for the kind of video you’re shooting. Honestly, if I had that much jerking around, I’d shoot at 60p at minimum (twice the number of I-Frames for the same amount of motion… 720/60p is in the ATSC television spec largely because ESPN, backed by Disney, lobbied hard for it… for sports motion, of course), and ideally, with an I-Frame only camera. That doens’t immediately solve your problems getting to YouTube, but the cleaner you start with, the cleaner you’ll wind up with. If you’re using Heros, you need a Hero 3+ for 1080/60p at a decent bitrate.
Bottom line is, for this kind of video, shoot it as clean and high framerate, high bitrate as you can. If you edit and recompress, output that at a very high bitrate too… YouTube will take Blu-Ray quality and even some pro formats as uploads.
This may also help you get the best YouTube encoding. They have an algorithm that judges the quality of your video in various secret ways, which determines some of the parameters of the encoding, even which resolutions it’ll encode for you. I recently put up a video shot in part on HD camera, in part on SD camera (with high-quality uprez), but a good bit of the HD video was just shooting an interview on a projection screen via Skype. YouTube correctly sussed that the quality was basically SD, despite the fact I sent a Blu-ray quality encoding (I was trying to fool it — didn’t work).
-Dave
-
[Antonio Salva] “Thanx for the reply John, it is plugged into a USB 3 input. Do I need a special cable to access USB 3 speeds?”
You need a USB 3.0 cable… it has extra signals on it, compared to a USB 2.0 cable. That said, unless you have a bug somewhere in your system, even USB 2.0 is just fine for audio or even video speeds. That of course assumes a drive that’s not fragmented, no contention for that drive from other programs, a drive that’s not suffering errors, etc.
[Antonio Salva] ” I do have another USB device hooked up-an Ilok for some of the music plugins I own. Do you think this would take up bandwidth?”
If your other USB device is active and doing stuff, it’ll be taking some USB bandwidth, otherwise it shouldn’t. But there are the occasional drive bugs. It should be easy enough to unplug and verify. I would HOPE that a security dongle doesn’t eat up that much USB bandwidth.
[Antonio Salva] ” I noticed other people having this problem as well. I figured by the last build of Sony Pro version 12 they would have a lot of these type of kinks worked out.”
This is usually a system-level problem, not something attributable specifically to Vegas or any other DAW. In theory anyway, the USB subsystem and NTFS file systems are either correct or they’re not, and no specific program, running on top of these, has much impact on whether they work or not. No program like Vegas out to be doing special things for the type of media you’re using. It’s the operating system’s job to ensure these things work well together.
[Antonio Salva] ” I hardly had any problems with WAV files in version 8.”
Did you have the same hardware back then? If not, you might expect different performance. If so… Vegas 8 is over six years old. A typical HDD (internal or external) could easily be failing after 5-6 years of use. Do you still have Vegas 8 installed or available to install?
Just sayin’ … I use external media all the time, USB, HDD, SD Card, etc. I do all my audio recording on external drives (it’s on a different studio computer), bring it into Vegas as 24-bit/96kHz, and usually don’t even think about HDD speeds until I have a few dozen tracks playing at once (I projects with over 60). With audio, it’s not even about the HDD transfer speed, but the seek time.
[Antonio Salva] ” Interestingly, the video files play perfect from the external at the same time the WAV files won’t.”
Well, there’s that seek time thing again. Try moving the video files to the C: drive and see what happens. Video files need to get a new frame every 1/24-1/60th of a second, or they break up. Audio files need to deliver a new sample every 1/44100th-1/96000th of a second or so, or they judder, break up, etc. If you’re using a modern audio device with ASIO drivers, you can control the amount of buffering for audio in the ASIO driver to make seeks less important (fine for editing, not for overdubbing or live performance). If not, you may simply have an unstable situation. It’s expected behavior that, when you’re thrashing your drive (asking for more data than it can deliver, which again isn’t just peak single stream throughput, but the sum of the files and the seeks between them), audio will start to fail first. Yes, it’s counterinitutive, but that’s how it works.
-Dave
-
I should also point out that, at least in my case, my system supports up to 4 GPU cards. So I could add a R9 290 or some-such and still keep the HD6970 around IF it proved the better card for AVC rendering. Kind of a waste of power otherwise, but possible.
-Dave
-
You could get faster timeline acceleration going to a faster AMD GPU. They pretty much scale up as long as you go the same-or-higher class of GPU as well as upgrading the generation (eg, in the HD6870, “6” is the generation, “8” is the major class, and “7” is the subclass… my HD6970 is a bit faster at most things).
However, you will lose GPU accelerated rendering on Main Concept AVC if you go beyond the HD6xxx series with AMD or the GTX5xx series with nVidia. And as it’s been outlined here repeatedly, there are some mysterious issues with nVidia’s more recent GPUs and OpenGL… older cards often go faster, and not just in Vegas.
So I’ve been looking at faster cards.. but speed isn’t really a problem in most cases — I’m usually going at a full frame rate on typical video projects. I’ve been kind of waiting to see which direction Sony goes on future GPU stuff, but given the latest “nothing new” answer, I’d say you’re safe with a higher end 5xxx or 6xxx series AMD, and even better with a 7xxx or R9 series AMD, but that might slow down AVC rendering (might not, it depends on your CPU and the project specifics).
-Dave
-
It’s important to realize what’s happening here. You have a 1080/60i video that you’re rendering to 1080/30p (well, technically 29.97p, but let’s not worry about that).
What you have in that interlaced video is two temporal fields making up one frame. The first one has 540 lines of video at t = 0, the second has the other 540 lines of video at t = 1/60th second. In a true 30p video, you have the full frame changing every 1/30th of a second, in a 60i video you have half the frame changing every 1/60th of a second.
When you preview at half resolution, you’re eliminating half of the scan lines — thus, one of the two fields. So you’re never going to see the effect of interlaced video converted to progressive. And in fact, one of the ways that conversion is done is to simply toss out one of the fields and double the other… so you only have half the vertical resolution, but no temporal effects. And keep in mind that you have to view at Good or Best quality to get a preview of the de-interlacing method, as well. Draft and Preview don’t do this extra computation.
When you chose to Blend Fields, that’s taking both fields and just merging them together. So you get full vertical resolution, but if there’s much motion between the fields, you’ll see the effect of that motion, in artifacts like “mice teeth”, which zoomed out is that ghosting look you see.
When you select Interpolate, it works as I mentioned above… it tosses out one frame, and just interpolates the missing lines in the other by averaging previous and next lines together to fill in. So you have lower vertical resolution, but no problems with motion.
There are certainly more sophisticated de-interlacing methods out there in the world. It’s quite possible to use motion detection between fields to use a hybrid of the two methods, or even motion tracking to detect moving regions and re-align them for the unified image. You have to look at plug-ins for better de-interlacing methods. Sony’s got the two basic methods built-in.
-Dave
-
If there’s any significant rendering, color correction, etc in your project, you might try rendering out to an intermediate form in a couple of pieces, assemble those in a new project, then render the final. It’s possible you’re hitting a bug in some plug-in or another that’s not usually found with more typical rendering times.
I have used this technique to get past this sort of bug in the past.
-Dave
-
I would wait for some actual benchmarks. Looking at the GTX 750Ti vs. the HD 6870, I have a belief it would be somewhat faster at Vegas operations (eg, the stuff Vegas does internally that determines editing and part of rendering performance), but it’s hard to say for sure. On low-level OpenCL benchmarks, there’s no clear winner between the two.
-Dave
-
Vegas does support RAW files (I’m actually working on just such a project… I have a time lapse of my backyard from the last 15+ days, watching Spring happen at 6 frames per hour, shot raw on a Canon 60D). But it does that using Microsoft’s RAW filter. Which is here: https://www.microsoft.com/en-us/download/details.aspx?id=26829. And I just noticed they updated it very recently. But no mention of DNG support, as stupid as that would seem.
-Dave
-
[Antonio Salva] “Dave, can you tell us about your setup. I too am having problems playing WAV files. Even WAV files created bySony Vegas via CD capture within the program. I have also read another post that has this same problem. I installed Vegas Pro 12 hoping all the kinks would have been worked out by the last version. This is really frustrating because I can’t work on projects with this glitch”
Understand the frustration. I can’t say I have a clue about the solution. But here’s my setup:
Intel i7-3930K processor, 64GB DDR3 DRAM, 960GB SSD main drive, ~6GB RAID10 data drive, AMD Radeon HD6970 GPU, 2x 1440p + 1x 1200p monitors, external 12TB Drobo on Firewire 800. Dozens of USB ports via multiple 12-way USB 2.0 and one four-way USB 3.0 ports.
About once a season I do a recording of one of the “jam” groups I play with using the H4n, and various others at more random times. That’s usually 3-4 hours of sound, 4-channel (two stereo WAV files), 48kHz/24-bit, using internal mics and usually two external dynamic mics. For video projects, I generally set the Zoom up the same way, setting it “free running”, so it functions as a time base for cameras that are constantly getting turned on and off (DSLRs in particular). Running System 1.70, Version 1.01, on the Zoom.
What else… no CODEC packs installed, tons of software for internet, EE CAD, music, photography, etc. I run smart but not light… I haven’t found it that easy to screw up Vegas. You mentioned Vegas 13 Demo does the same thing? I was planning to ask if you tried re-installing, just for grins, but figured you did if you’re trying the Vegas 13 demo/purchased.
You can drop me one of the offending files (davehaynie@gmail.com on DropBox will work) and I’ll give a try here. That might at least tell you if the mutation is file-based or Vegas-based, but given that it plays in other things, you may have established that already.
-Dave
-
Keep in mind that MIT-156 is just a Balun… it’s only going to work with dynamic mics, not condensers. Most pro mics useful for video are condensers and need 48V phantom power. Thus the Beachtek… or H4n.
-Dave