Forum Replies Created

Page 1 of 110
  • Dave Haynie

    September 18, 2017 at 1:51 pm in reply to: Viable option/use for M-DISC ?

    I absolutely recommend M-Disc. I use BDXL M-Disc for critical archival. Obviously, it has not been around 30 years, but you are better off with a non-organic disc than organic.

    M-Disc uses a proprietary HTL (high to low) technology, where the disc surface is naturally reflective, the written pits make it non-reflective. This is the opposite of the organic dye discs. They’re LTH, the laser zaps an area of dye, clearing it to reveal the reflective layer below. Problem is, over time the dye can fade where its expected to not fade.

    Even standard HTL Blu-ray is more reliable than organic dye based discs. The HTL Blu-ray is a layer of silicon and a layer of copper, which starts out reflective. The laser melts the two together, making it non-reflective. But watch out! This was the original BD-R formulation, but the folks with organic dye- based technology added an LTH version of BD-R, cheaper but subject to the same fading issues.

    -Dave

  • Dave Haynie

    September 13, 2017 at 5:32 pm in reply to: Any New GPU Updates for Sony Vegas 15?
  • Dave Haynie

    September 13, 2017 at 5:31 pm in reply to: Any New GPU Updates for Sony Vegas 15?

    The good news is yes, there’s a new MAGIX AVC CODEC that takes advantage of modern GPUs (well, at least today) and as well, Intel’s QSV instructions. The bad news is that, despite high-end AMD GPUs offering the best performance in Vegas 14 and earlier, they are not supporting AMD GPUs. No support for AMD VCE either. This suggests they coded it in CUDA rather than OpenCL. So, basically, a step backwards in technology.

    Maybe they address it later. But I wouldn’t hold my breath. If they had planned to support nVidia and AMD, there was absolutely no sense coding first in CUDA, since OpenCL is the universal standard. The goal should have been to move to real OpenCL without the stupid GPU-check that we’ve had in the Main Concept CODEC (which was, in fact, only there to force companies like Sony/MAGIX to relicense the CODEC with every new release. OpenCL is not even slightly GPU-specific… in fact, it’s been run on AMD CPUs and the Intel PHI processor, among other things).

    I’m skipping on upgrades until they start to make sense. Heading against the forward flow of technology is a huge fail in my book.

    -Dave

  • [Jeff David] “Yup – I know min DV tapes are outdated and the new mode is SD cards, but I still have the old camcorder that uses mini DV tapes and hours and hours of footage that I shot anywhere from 1 to 4 or so years ago.

    Someone mentioned to me they lose their quality over time. I.e. the sharpness etc. Is that true?

    Well, a couple of things there. Yes, SD cards are the common means of video acquisition these days. DO NOT USE THEM FOR LONG TERM STORAGE. The typical consumer SD card may start showing drop-outs after a year or two.

    DV tapes are, of course, digital as well. In both cases, it’s all or nothing. It’s absolutely impossible for the image to degrade at all, in any way, as long as you can read the tape. The problem is that, over time, you get bit rot — small errors start creeping into the tape data. What might have been a few sync or image glitches in the analog days becomes a digital glitch, or drop-out, in the digital age.

    If the format is DV or DVCAM or similar, this is likely to show up as some digital noise over a few blocks in a frame, but it can of course hit anywhere on the tape, including various headers and other formatting. The older the tape gets, the more you’ll see these. On HDV and similar, you have a greater chance of a glitch that’ll affect a whole series of frames, based on the way MPEG-2 works versus DV compression.

    I put all my Digital8, DV, and HDV material on a RAID drive over a decade ago. That’s backed up on Blu-ray BD-R HTL discs, which are far longer lasting than tapes. And more recently, BDXL M-Discs, even better.

    -Dave

  • Dave Haynie

    January 10, 2017 at 4:54 am in reply to: Display Interfacing and SuperMHL

    NIce list!

    But you also need to know your GPU’s capabilities. You can put a DisplayPort to HDMI 2.0 converter on an older GPU board, but it’s likely limited by the GPU’s display hardware to 2560×1600 or so resolutions. Many of today’s GPUs support 4K displays but won’t handle 8K… not that I’m personally too worried about moving to 8K anytime soon. And yet, 4K hit much. much faster than I had expected, mostly due to the manufacturing costs on 4K LCDs not being substantially higher than those of 2K LCDs.

    It’s the typical “weakest link” thing… something is going to set your boundaries. Could be the interconnect, could be the GPU… could even be the OS. For example, last I checked, MacOS didn’t support DisplayPort’s Multi-Stream protocol (the thing that lets you split a single DisplayPort into multiple DisplayPorts, or lets you “daisy-chain” DisplayPort monitors.

    -Dave

  • Dave Haynie

    January 10, 2017 at 4:47 am in reply to: Ultimate Vegas Machine?

    [James Redmond] “After reading these series of posts about using dual graphics cards, what I understood was to have one inexpensive card for display and other powerful card for rendering. In the earlier posts I thought your had recommended the FirePro series. When I had the 480 and the 5100 installed I could not get Vegas to use the FirePro 5100. That is when I called AMD tech support and they said to have both graphics card exactly the same. It had to do with the drivers. So I went with two 480.”

    That’s probably a better rig anyway.

    The “professional” cards are not well understood by most people, but they’re generally slower to much slower than same-year “standard” cards. And that’s from either AMD or nVidia.

    Basically, the pro cards are made from older chips. When AMD or nVidia make a new chip, it’s only possible when they can sell the thing in the millions. They don’t sell millions of pro-model GPUs for these FirePro or Quadro cards. But they do sell stability. So the drivers for any Pro card get a year or two of regular updates, and meanwhile, they’re looking at the chip, maybe making a tweak to fix a bug, probably enabling some extra memory, but that’s about it. So these hit the pro market with drivers that are very solid.

    Sometimes there are artificial restrictions on the standard cards. For example, nVidia has a few 64-bit OpenGL functions that run really slow on their standard cards compared to the pro cards. However, a few intrepid comedian-hackers out there re-coded those operations in CUDA for consumer cards, and they basically matched the pro versions. So it’s a software/driver handicap. But nothing that seems to ever affect video use.

    In the past, you might have had some advantage in the extra memory on a pro card. But there’s been such a push for larger memories on standard cards, to support multi-monitor and 4K gaming and that sort of thing. I looked at the latest when buying my upgrade last fall, and concluded that the RX480 was the best deal going. I could pay twice as much for a FirePro and get lower performance.

    One other advantage of the pro cards — they’re usually in a single-slot form factor. If I really wanted four GPUs in my system, that would become an issue. That’s the kind of thing some serious OpenGL users are looking for, like film animators, mechanical CAD people (I work with one of those guys… he’s got a 64″ 4K monitor on his desk at the office).

    Once example of this: I have a nVidia Quadro 4000 in my office PC… something the mechanical guys were pushing on me when I started there in 2012. A few years ago, I was playing around with digital currency and the experimental “ARS Coins” done on ARS Technica. I had set up my home system, with my 6 core i7-3930K and my Radeon HD6900.. that was cranking out some real coins. So I set up the same render at the office using the 4-core i7 and the nVidia… yawn. Not so good. Then I decided to try the AMD A6 (forget the version) in the tiny 1U rackmount PC I built as basically just a audio recorder. It was actually outperfoming the stand-alone performance of my 6-core i7, and it was just edging out the Quadro 4000. You could buy over a half-dozen of those A6 systems for the price of the nVidia! Sure, not a terribly fair thing, and I don’t use either the music PC or the office PC for video, so there’s no actual Vegas test there.

    -Dave

  • Exactly right.

    It’s important for everyone to understand how the GPU acceleration has been done over the years. As John mentioned, it’s in multiple places. Vegas itself seems to use it for compositing to some effect, and any plug-in can use it as well. If you generalize GPU support to both “compute” and “3D” support, Vegas accelerates using OpenCL in the first place, OpenGL in the second place. So many, many plug-ins get at least one of these kinds of accleration.

    Video CODECs can also support GPU acceleration, but historically, most have not. Sony’s AVC plug-ins did, but the effect wasn’t profound. And what acceleration there was worked with any old OpenCL acceleration you had available.

    The alternative MainConcept AVC CODEC was different. It ignored Vegas system settings, for the most part, about your GPU, and offered hard-wired acceleration for either CUDA (the nVidia proprietary general-purpose GPU computing language) or OpenCL (the industry standard, more today than ever). But here’s the problem: they didn’t just hard-wire these accelerations, they limited them to very specific graphics chips, all made before 2011. In short, they kind of short-circuited the whole point of OpenCL or even CPU — being device independent — and locked in the acceleration to just these GPUs, pretty much Radeon HD 4xxx, HD5xxx and HD6xxx from nVidia, and GeForce 4xx and 5xx boards. Much has happened in the last 6-7 years.

    I wrestled with the upgrade for quite awhile: to upgrade or to keep my AMD HD6970 (one of the fastest for Vegas). I recently pushed the issue this year, because I managed to kill one of my three monitors in the move to a new house, and replaced it with one of these crazy ultra-wide-screen displays, 34″ at 3440×1440 (same basic height as my two 2560×1440 screens). The older cards topped out at 2560 pixels across.

    Over all, this was a good decision. When I’m editing, things are much faster. Red car demo playback is smoother than it was — like butter — even at 32-bit. But rendering MainConcept AVC, just a bit longer. Of course, the MainConcept GPU rendering engine wasn’t free, it did have a small effect on the quality of the video. But I used it for most things, web videos and that kind of stuff. I could have kept the old card around, I have one of those higher-end X79 motherboards with several GPU-capable PCIe slots. But I didn’t really think it was worth the power, in my case. If you have two GPUs, Vegas can use either, but not both together, at least as set in the Vegas options menu. I’m not certain what the MainConcept plug-in does when it finds two GPUs.

    Anyway, I believe the bad decision to lock this plug-in to GPUs was MainConcept’s nasty way of getting their licensees to pay extra for new versions. Thing is, those new versions never even arrived. Main Concept has changed hands on a pretty regular basis, and every new owner has had a different strategy for what they wanted to do with it. It was founded in Germany as a commercial venture behind a shareware MPEG-2 encoder that the two founders had created. They were bought by DivX, Inc in 2007. DivX was bought by Sonic Solutions in 2010. Then Rovi bought Sonic Solutions in 2011. Rovi spun DivX back out in 2014, and they were bought by NeuLion (Plainview, NY) in 2015. Under Rovi, at least, they didn’t seem to do anything with AVC, but did develop an HEVC CODEC. No idea what NeuLion has in mind.

    Anyway, Magix would presumably need to license either an updated GPU-accelerated CODEC from NeuLion, someone else’s, or develop their own. The latest data sheet from NeuLion (https://www.mainconcept.com/fileadmin/user_upload/datasheets/AVC_SDK_DATASHEET.pdf) doesn’t even mention GPU acceleration for the encoder… perhaps not a thing they’re working on, and it would be kind of silly to continue to push that tech for 2010-ish GPUs only. No idea if Magix acquired some source-code access to Sony’s AVC CODEC, but it would take lots of work to get it as fast as MainConcept, pretty specialized work.

    -Dave

  • Dave Haynie

    December 20, 2016 at 7:01 am in reply to: v14 – a list of supported GPUs anywhere?

    I recently upgraded my video card… a new 3440×1440 monitor joined my dual 2560×1440 monitors, and I needed a card to support 4K-class resolutions. I got an AMD Radeon RX480, currently replaing the old HD6970. I could technically have both in there, but haven’t a reason yet.

    I ran the red car benchmark… curious results.

    Running full quality HD preview, it’s like butter… not a glitch. And the GPU seems to be taking a nap, whereas my old one was running in the 36-40% range. But without a GPU, this is very stuttery, so definitely using the new GPU in there.

    Then I ran a couple of renders. Rendering Sony AVC at 1080i60 and 16Mb/s gave me 1:36, versus the 1:34 I saw with the old card (though I didn’t set up a clean benchmark environment with all other apps shut down)… essentially the same.

    The MainConcept AVC render at 1080i60 and 25Mb/s was curious. I didn’t see any CPU/GPU option in Vegas 14… either it’s not there at all, or they finally don’t show it if it can’t help. Anyway, my system with the old GPU did it in 0:57 minutes… pretty fast. Without GPU, 5:19 minutes… these are all with 8-bit math. With the new GPU I got 3:09 minutes. So clearly, the AVC plug-in is not getting GPU acceleration, as expected. But the overall system Vegas system is.

    -Dave

  • Dave Haynie

    December 20, 2016 at 6:30 am in reply to: Proxies are twice the size of the original file!

    Something has to give.

    You can make a proxy in any format you like, of course. But let’s say we start with AVC encoded HD at 24Mb/s. That’s pretty standard, and AVC is computationally complex to decode… worse, still, if you’re got 4K original source material.

    So you want to transcode your AVC into something that will speed up your editing — that’s the usual thing. That AVC runs around 12GB/hour. So what to do with a proxy?

    Well, most people think, ok, I’ll render to a less computationally intensive format, so my edits are faster. Now, you could pick MPEG-2 at 24Mb/s, and that would be fine, and exactly the same size as your original files. But it’s not going to look at good. And since it doesn’t look as good, there’s probably no default template for rendering that format. You might pick, say, MPEG-2 at 50Mb/s, Cineform at 50Mb/s, DNxHD at 144Mb/s, etc…. those are going to grow substantially. The latter two also give you I-Frame-only encoding, which makes things faster still.

    The other option is to downrez. Chop your 4K to 1080p or 720p or whatever gives you the speed you want. Maybe the proxy is smaller, but is the proxy good enough for editing? I recall the early days of HDV… I was transcoding HDV proxies to DV, because that was fast editing. But bascially the same size, and lower quality (SD vs HD, naturally).

    Any proxy format that’s not larger is going to either be lower quality or more computationally intensive.

    -Dave

  • Dave Haynie

    November 30, 2016 at 9:56 pm in reply to: Vertical Video: Just say No!

    Well, you know, you’re all wrong.. the future is in triangular video. We’ve known this a long, long time.

    But seriously, vertical video is at best special-purpose. Sure, there are a few vertical video kiosks and ads that mandate a vertical crop. Mobile devices are mobile device… they work exactly as well as horizontal devices as they do vertical devices. On the other hand, the two 16:9 monitors and one 21:9 monitor on my desk, my 70″, 55″, and 32″ 16:9 televisions, etc. are all inherently horizontal. That’s going to be the standard delivery format going forward.

    And of course, if you’re somehow compelled to worship Satan by delivering vertical content for mobile devices, you can always crop from horizontal. Sure, my phone has a 2560 x 1440 display, but I’m not likely to notice a huge problem after all the other evils I’m going to subject my video to in order to get it on that tiny screen anyway.

    -Dave

Page 1 of 110

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy