Dave Haynie
Forum Replies Created
-
[Michal Bronec] “I didnt heard about any DSLR that was damaged by overheating, so I am not afraid of it. “
A long time ago, with the very first video DSLRs, this might have been a problem for a few of them. Those that did risk overheating actually had a temp sensor and an automatic shutdown to protect the sensor. The Canon T2i could overheat.. it had a “red thermometer” warning if the sensor was getting to hot. Sony has some trouble in some of its pellicle mirror cameras with overheating (worse if AF is enabled, which makes it sound like the processor more than the sensor is what’s overheating), and they shut down to protect the camera as well. If the camera wasn’t expected to overheat by did anyway (eg, a poor design), It’s certainly not a general problem today.
The next roadblock is file size. Older models stop because a file fills up… they only support a 32-bit file system, and once you get to 4GB, it’s time to stop. Unlike true camcorders, there was no thought of seamless chaining to the next file (pretty much what every solid-state camcorder has done for a decade+). But that got fixed, too.
Newer models actually support a 64-bit file system (exFAT… any camera that supports SDXC cards supports exFAT), but typically don’t have 64-bit internal file management, so you still get bumped at 4GB. However, many of the more recent cameras chain files, just like camcorders do. My Canon 6D, for example, will record for 29’59”. That limit is a completely idiotic limit forced on everyone because of Europe. In Europe, they have a separate tax on video recording devices, but for arcane reasons, apparently you’re only recording video if you do so for 30min. or more. So Canon, Sony, and I think Nikon all stop at 29’59”, even if you’re using a US model, which has no rational reason for stopping there. Panasonic cameras, like the new GH4, do not stop at 29’59”.
If you have a Canon, you can get Magic Lantern software that sorta-kinda fixes this problem. It won’t be seamless, but you can set the enhanced firmware to immediately start recording again if the camera stops.
-Dave
-
It’s the same situation as Vegas 12. Vegas uses the Microsoft Raw API to import raw photos. So if you have the latest Microsoft Camera CODEC pack installed, you can drop supported raw files on the Vegas timeline. Don’t recall if DNG is supported, but I believe it has all Canon DSLRS covered. Works for me (6D, 60D).
Shame they didn’t add direct support for CinemaDNG, which would certainly be handier than dealing with thousands of raw files (in my case from time lapse shooting, haven’t tried the Magic Lantern raw hacks yet).
-Dave
-
What’s your player? If you’re using a Blu-ray player, you need to make a proper Blu-ray disc, at a proper Blu-ray resolution. 1280×720 is certainly an option, but nothing intermediate between that an SD. I would assume if you have a BD player that will connect to this kind of projector, it would do the downscaling. Most BD players today don’t have analog output, but most older ones will do YPrPb if not VGA.
On the other hand, if you’re playing from a computer or tablet, you can pretty much create any old resolution you like. But of course, you’ll need an older laptop if you’re connecting to a VGA projector. And of course, the PC will do the video size conversion on the fly for that screen type.
-Dave
-
[Miguel Peraza] “It’s sad to say, but Sony still hasn’t updated compatibility.”
As others have stated, the Main Concept issues are strictly Main Concept. I actually checked their web site, and the H.264 CODEC they’re advertising is exactly what Sony’s shipping today… unchanged since Vegas 11 or so. That’s the problem when you get acquired. When Main Concept was Main Concept, their primary function was developing CODECs to sell, mostly embedded as with Sony, in other folks’ products. When DivX bought them, the focus was certainly shifted, at least in part, to incorporating their CODEC technology in other products. When Rovio bought DivX, even more products, and pretty much zero development on the CODEC. And even with the split off of DivX and Main Concept to Parallax, I wouldn’t hold my breath for improvement.
If you want to fault Sony, go ahead, but the real problem is that they’ve stuck with Main Concept for AVC. They really should find another CODEC provider, and they should fully embrace the use of Windows-standard Direct Show CODECs… much better than Video for Windows, because they can output any format, not just AVI. Or fully document the Sony plug-in interface for CODECs. Or support a built-in frame server. This isn’t uniquely an H.264 problem, since there are a bunch of new CODECs up and coming that may become important son enough.
[Miguel Peraza] ” Newer cards do help accelerate the preview, but it does not accelerate the render for the most commonly used format.”
That’s not strictly true. If you see Vegas speeding up during preview, that same compositing engine is used — and sped up — during rendering. Which doesn’t just feed whatever CODEC you’re using faster, but also frees up more CPU cycles for that CODEC. So no, the GPU doesn’t speed up the rendering CODEC itself, but it does speed up rendering. Try a CPU-only versus OpenCL (as set in video preferences — don’t forget to reboot) to see the effect of the GPU with any un-accelerated CODEC.
And sure, Main Concept does an excellent job of using the GPU for H.264… I see about a 6x speedup over no GPU at all. They’re doing practically everything except entropy encoding on the GPU. But the quality is not as good as the CPU-only version.
-Dave
-
DPI is meaningful for print resolutions, but not really how you measure for video. Blu-ray video is 1920×1080, 1440×1080, or 1280 X 720 pixels.
If you are doing a simple slide show, you need not go any higher. Of course, that can get pretty boring, so it’s pretty common to animate photos a bit, by panning, zooming, and other effects… Google “The Ken Burns Effect” for some more information; these kinds of things are part of how Ken Burns turns photos and stories into compelling historical documentaries.
Here’s an example of one I made with my Dad’s photos… most of these were 6-8 Megapixel DSLR images:
https://www.youtube.com/watch?v=uQGf7xjWc4E
-Dave
Some contents or functionalities here are not available due to your cookie preferences!This happens because the functionality/content marked as “Google Youtube” uses cookies that you choosed to keep disabled. In order to view this content or use this functionality, please enable cookies: click here to open your cookie preferences.
-
[John Smith] “I tried rendering a video in Vegas using “CUDA” but it doesn’t seem to be all that fast?”
Sounds like a setting on the MainConcept AVC CODEC. That one does have very fast rendering for CUDA or OpenCL GPUs. Unfortunately, they stupidly have it locked to only specific GPUs, and only those that were out in 2011 or so… Main Concept was bought by DivX, who were in turn bought by Rovio, and pretty much no new work was done on the CODEC since. The whole point of CUDA and even moreso OpenCL was to do math in parallel independent of the processor (you can actually run OpenCL on x86 natively or Intel’s Phi board, not just on GPUs).
Fortunately, Vegas itself doesn’t have this problem, it’s just in the MainConcept AVC plug-in. Make sure your nVidia drivers run OpenCL, then go to Vegas preferences, under Video options, and you should find the place to select GPU acceleration. You have to reset it to take effect. Note that Vegas, like many if not most OpenCL programs only supports on GPU at a time. This acceleration affects Vegas compositing, plugins, etc. So the more work you do, the more it helps… and it helps on editing, preview, and rendering, just not the specific CODEC.
There are some reports of sketchy OpenCL performance on nVidia boards, particular Kepler boards… they are fast on some things, weirdly sl I w on others. Though I’d certainly expect a Titan to be pretty fast at anything it does.
-Dave
-
[Cedric Divang] “The quality difference is huge !”
This does tend to be a low-bitrate thing. And that’s not a shock… it’s pretty difficult to get just the right look at lower bitrates, and I’ll bet that the CPU version is doing things that simply don’t translate well to GPU coding… or are maybe just too complex.
Another thing to realize about MainConcept is that, as Norman mentioned, the GPU coder is a totally different piece of software. Main Concept MPEG and AVC go back decades, but the accelerated encoder was brand new code in Vegas 11, and unfortunately, that’s about the time MainConcept (and parent company DivX) were acquired by Rovio. Nothing much seems to have happened with this CODEC over these last three years. I suspect it’s typical of this… when a company like Rovio acquires a “components” company like DivX, they’re more interested in spending time getting that tech put into their other products than they are worrying about the future of that company’s much smaller market.
Anyway, even the CPU rendering isn’t as good as x264, as Norman mentioned. x264 is an open source project that’s had some clever and very vocal programmers working on it, pushing it harder than I’d guess just about anyone’s ever pushed the H.264/AVC spec. So particularly on low-bitrate stuff, it’s just better. This is the same AVC engine that Google uses for YouTube.
Handbrake is a good open source encoder that uses x264. Though you’ll probably find that just about anything that’s open source and creates H.264 video is doing it with x264. I’m kind of surprised someone like, oh I dunno, Sony, hasn’t incorporated x264 into their products. Sound be possible, even under the GPL, since Sony’s rendering engines are already external modules. And given that Main Concept seems to have given up on improving things.
TMPGenc’s Video Mastering Works also uses x264 as one of several AVC encoding engines (also supports Intel’s, which is tweaked for some x86 chips, and nVidia’s, which of course runs on nVidia GPUs… no OpenCL yet).
I love the integrated encoders. But given the rate at which Sony’s been adapting to new things like GPU acceleration, H.264 improvements, WebM/VP8/VP9, H.265, etc (eg, pretty much not at all), it doesn’t hurt to at least be aware of external encoding options. To use an external encoder, you have to export your complete project, of course, in some intermediate, high-quality format that’s accepted by the encoding program.
Nice video… yeah, that’s the x264 guy… very opinionated, but he’s got the results to back him up. And he does touch on some of the real problems. Obviously, video encoding does benefit from parallelism… that’s what happens in every actual hardware implementation. Of course, the x264 folks will claim they do better encoding than hardware encoders, too (and keep in mind, every hardware encoder is actually a bunch of software, some regular everyday CPU encoding, and a bunch of application-specific hardware). And they might be right.
Good news is that the GPU active in Vegas makes every render faster, simply because it’s applied to plug-ins, compositing, etc. So even if you run CPU-based AVC encoding, you benefit from the GPU (GPU acceleration ON in Vegas, CPU-Only on MainConcept).
-Dave
-
That’s the right way to shoot, but unfortunately, YouTube won’t preserve that.
I like what Norman pointed out too… camera shake control. That goes back to what I said about the whole MPEG/AVC encoding process. The ideal fast motion in an MPEG video is a stationary camera with something moving across a stationary background — does that pretty well.
When you have your fine detail, your fast motion, and constant moving of the background, that’s ok at high bitrate. But cut out half the frames (downsampling), so all those motion vectors are basically doubled in length, and the error frames made larger, etc. it’s just more than YouTube can cram into a low bitrate AVC.
Here are some things to try. First, try some stabilization. That’s probably going to help more than anything. You’ll note, in your video, when the camera does stop, things look dramatically better for the fractions of a second you do stop. If you can keep all that small motion from showing up in the video, it’s going to get better.
Next, do your own encoding at 29.97fps — downsampled from “60p” however you like to do it (blending or dropping frames). YouTube is going to do this anyway, so why not experiment with it and see if you can get a decent encoding even at a higher bitrate.
Next is blurring. Seriously. If you over analyze commercial DVD video like I did back in the early days, when I could not get my video to look as good (I was shooting regular sports stuff back then, about all the fast motion video I’ve done, mostly soccer), then you’ll notice that in really fast motion scenes, things sometimes get a little blurry. That’s a trick to keep the MPEG encoding from making things even worse.
As I mentioned before, the goal of block in the JPEG-like part of MPEG/AVC is to filter out high frequency information… stuff you may not notice. You don’t always notice these macrocell boundaries in HD, when the video is overly compressed, but they were really obvious in SD. Some of the other bad video, noise, etc. is due to the same issues. If you apply a little global blurring, using say a Gaussian blur with a very light touch, just in those most troubled areas, you’ll find those really bad parts looking better. You’re kind of applying just a little global “damage” to the scene to get past the big, very localized damage that bad encoding gets you. The loss of high detail in fast motion video isn’t usually very apparent, either, or a bunch of DVD/Blu-ray mastering engineers would have been out of work long ago. But those distortions or visible macroblocks, they jump right out at you.
-Dave
-
Well, good, at least the bad drive possibility is eliminated.
I’d try it the old fashioned way. Back before pretty much anyone was doing video on HDD, it was all about trying to get some number of audio tracks to work correctly.
So, start a new project, drop in one track from the drive in question. Does it play? Add a few more… eventually, you’ll start to judder. IF you had an ASIO audio device, you could up the buffering and get that back playing clean, but I don’t know of any way to tweak that through the standard drivers.
You might try ASIO4ALL and see if that works with your laptop audio device. You have to install that, then set Vegas to use it, and you lose system audio, which is of course what you usually want for serious audio work.
No, there is no fragmentation if that’s a new drive. Fragmentation naturally makes seeking worse, but with large files, there are always seeking issues.Anyway, you can try the same thing with a single video track, etc. No matter what the HDD, you will eventually run out of seek time, and audio will eventually start to judder. And when rendering, that same situation will result in renders more dictated by your HDD seek times than your CPU speed, which is certainly not what you want. This is why 7200rpm drives were once a must-have for any kind of multimedia work… lower seek times come from both less seeking (larger drives) and from faster spin. Laptop drives (both internal and external) are notoriously sketchy for this, because they seem to think it’s important to worry about power, a ridiculous notion for a media content machine (don’t get me started on laptops in general), but there you have it.
Also, I don’t think you mentioned, you have WAV files, but what kind of video files (media type, bitrate, etc) and how many in a project? Just trying to suss the impact of the video.
-Dave
-
One Update: I did manage to grab the 1080p stream… funny thing, it’s practically the same bitrate as the 720p stream. The total file size is 247MB for the 720p, 292MB for the 1080p. So I’m claiming YouTube has you flagged for lower quality video, probably based on the quality of the upload or perhaps even the original… you didn’t post specs on the camera, bitrate, framerate, etc. of the original, or the specs on the upload. Those are critical factors in getting YouTube to do you bidding.
-Dave