Q: Intermediates & alpha channels

Former user wrote on 1/12/2020, 11:04 AM

Hi Vegas Forum,

First post here, although I frequently lurk and have learned a lot from this board. Thanks for all of the information and experience that has been shared.

System specs: Vegas Pro 17 (build 387), Windows 10 Pro, x64, NVIDIA GeForce GTX 1060 6GB.

I’ve got a somewhat basic couple of questions about rendering to intermediates with alpha channels:

In one current project, I’ve got a simple PNG image-sequence on a track, and each of the PNG files contains an alpha-channel (naturally). There are graphics in the center of the frame, with the outside clipped to transparency. Very short, about 32 seconds.

Usually when I’m setting up these types of image sequences, I’ll drop a Vegas Solid Color media generator beneath the animation (which is muted before rendering), to be able to monitor the results with a color (cyan) other than a black background. At this stage, the alpha-channels in the image sequence enable track transparency, and it’s possible to see any track layer beneath.

Often when I’m rendering to an intermediate, I’m using the Magix Intermediate 422, usually 1080p, 30 fps. Since this intermediate type renders to MOV media (I presume, different from Apple Quicktime MOV, which is obsolete on Windows, but, as we know, works with alpha-channels), one would expect them to have alpha channels available in the rendered files, however…

Alpha-Channels:

When I render the 422 intermediate file though, load it onto a track, right-click on the video event and open its Properties dialog, on the Media tab, there is a drop-down selector for Alpha channel, and regardless of which is selected there – Straight (unmatted), Premultiplied, etc. – the areas of the video event that should be transparent using the alpha-channel, remain black.

Qs:

Is it in fact possible to use the Magix 422 intermediate format, to create video that includes the alpha-channels of the original pre-rendered media?

Are there possibly some rendering settings that could be tweaked to ensure that the video is actually getting rendered with the alpha-channel?

It would be extremely useful to be able to achieve this without having to install the old obsolete Quicktime codecs, which was the way I used to do this on Windows 7. Without some native method within Vegas Pro though, I’m unlikely to use QT.

Thanks in advance for any advice,

Back to post

Comments

joost-berk wrote on 1/16/2020, 9:40 AM

@Musicvid sorry for the mention. I was mistaking you for @Former user. But @Musicvid I understand your aversion against QT Animation. But I use this for broadcast live TV where speed and ease-of-use goes prior to (in some cases) quality. Then the QT Animation really is a nice way to handle files. They run very fast on networks and in broadcast servers.

Musicvid wrote on 1/16/2020, 10:07 AM

Yes they would, I imagine, for the same compression reasons I have a problem with in local storage and delivery.

If your broadcast servers can recognize UT 422, run your usual Bandwidth vs. Server Load tests, and I suspect you may be surprised on both counts. The technology emerged about the same time we were all using the bigger-is-faster model for streaming delivery.

Might even try XDCAM-EX35 for comparison.

Former user wrote on 1/16/2020, 11:07 AM

I use QT Animation for most graphics that I need an alpha channel. I have always been very happy with the quality and how Vegas handles playback.

Former user wrote on 1/17/2020, 12:01 PM

@joost-berk Thanks for sharing your settings, which I saved for reference. Also did a quick render test, and the quality looks pretty nice. Here though, I'm rendering at 1080p 30 fps. Now that I've got CineForm and QT up and running, next up will be HOS I suppose. Thanks again for everyone's help.

joost-berk wrote on 1/17/2020, 2:06 PM

@Musicvid it is unrealistic for broadcasters to use any 4444 or uncompressed files for alpha overlays. A lot of stuf is created in off-site studio's and is used immediately after production. So uploading times to broadcast servers is very important.

Broadcasters use MPEG-HD422 50 and QT Animation-RGBA for many years now because it is a proven methode. This will not change any time soon because you never change a winning team.

QT Animation-RGBA is only used for overlays (not for programming) and has a fair quality. And at the end of the broadcast transmission-line where several conversions at a maximum of 9 Mbit/s 1080i are made, even a real purist can't tell the difference between QT or 4444 any more. This is how TV-broadcasting works.

Musicvid wrote on 1/17/2020, 10:20 PM

@joost-berk

I only suggested other highly compressed 422 and 420 options, but sorry for being ridiculous. Isn't Animation 4444 RGBA?

joost-berk wrote on 1/18/2020, 4:33 AM

@Musicvid No hard feelings. :-) QT Animation is a different codec then ProRes 4444. Both support RGBA but the coding schemes are totaly different. Both codecs are also used for different purposes.

Musicvid wrote on 1/18/2020, 5:09 AM

No problem here either. I totally understand the difference between what has "always" been done and what "might" be done. I need to get out more.

Former user wrote on 1/18/2020, 5:48 AM

@joelsonforte.br Thanks for the information, videos and demonstrating that there is at least one method for rendering with alpha-channels natively within Vegas with the uncompressed AVI format. As we know though, the file sizes are huge, and with a short test render of 7 seconds here, the file size for 1080p was about 2GB(!).

I've noticed that you and a few others still seem to be primarily using VP14, and although I'm a licensed user of that version as well, I've moved along and upgraded to every version since, and now use VP17 on Windows 10 Pro.

Mentioning it to highlight that there are some apparent differences in the way VP17 works with some of these (older, Windows 7 period) third-party codecs, and rendering with alpha-channels. For example, on your suggestion, I installed the GV, HDX codec, but in contrast to your video demonstration, curiously, I found the "Render alpha channel" switch to be grayed out in VP17.

So, of the suggestions offered in this thread, the ones that have worked thus far in VP17, Windows 10 Pro, were the CineForm codec by Marco, and resorting to the old QT codec from @joost-berk. As stated previously, QT was what I used for this on Windows 7 and older VP versions, but wanted to avoid on Win-10, although I had to make a compromise.

Former user wrote on 1/18/2020, 7:42 AM

@joelsonforte.br Although this is the most 'hacky' of all things suggested - and this sort of thing makes me personally very nervous from a security standpoint - against all common sense (from over >20 years working in IT) I did give it a try, and as before, this doesn't work in VP17.

In fact, it makes the Render As, Video For Windows, option completely disappear, so I restored the original aviplug.dll, which brought it back. Worth a try I suppose, and I'm glad that it works for VP14 users, but even here, it yet again demonstrates some fundamental differences in the way VP17 handles these functions, as opposed to the previous ones. One might suppose it's something to keep in mind, as even the earlier suggested Avid codecs didn't work with the combination of VP17 and Windows Pro 10 x64.

Former user wrote on 1/18/2020, 8:37 AM

A small correction and update regarding Avid's DNxHD codec in VP17, Windows 10 Pro x64:

Thanks to @Musicvid and the MovieStudioZen tutorial linked by @Chief24, I was able to get this working, and as @Musicvid pointed out in is original post, far smaller file sizes are possible with this, and there are a great deal of parameters available for controlling the rendering quality.

For example, the 7-second test render (with alpha-channel) I tried, exported a compressed MOV file, that in contrast to the 2GB uncompressed AVI, was a mere 500MB, and the quality looks very good.

Worth mentioning though, for anyone who might read this thread afterwards, to be able to use the Avid DNxHD codecs in VP17/Windows 10 Pro x64, required first installing the old QT for Windows codecs (perhaps the most inelegant part of it, but "whatever works" certainly applies here).

Thanks again for everyone's help, time and patience. Now I've got three nice alpha-channel options available.

Musicvid wrote on 1/18/2020, 3:04 PM

Hope you get the urge to try Happy Otter with UT 422, as another tool in your belt.

Former user wrote on 1/19/2020, 4:28 AM

@joelsonforte.br Thanks again for your help and time. It was worth a try.

Perhaps a bit naive to say, but in agreement with you, if these avi.dlls can be edited so that alpha-channels are enabled for all AVI rendering formats, then one might wonder what is holding the developers back from making such a change.

It's difficult to grasp that this is somehow going to add to the expense of VP with such a seemingly minor tweak, but as Musicvid suggested, there may be some licensing issues preventing such modifications.

Musicvid wrote on 1/19/2020, 10:45 AM

Again, no need to speculate. The feature has been working all along in Happy Otter.

Former user wrote on 1/19/2020, 11:49 AM

@Musicvid on yours and @fr0sty suggestion, I've now got HOS and MagicYUV Ultimate installed, and am beginning to explore it now.

wwaag wrote on 1/23/2020, 9:03 PM

@joelsonforte.br

Regarding the "hacky" procedure, it works OK here. Here's a screen grab with the HQX codec. Also works for MagicYUV and UtVideo.

Regarding HOS, I've added some new features directly supporting alpha channel renders for the next build. Here is a demo.

Since making the demo, I've added a couple of new templates for using VirtualDub. One makes use of the native Cineform encoder that the author has included since the Cineform codec is now open source, although you can still use of the older GoPro version. You can also render to ProRes 4444 with alpha, which surprisingly, Vegas can import to the timeline. The next build supporting these features should be available next week. At the moment, I'm adding the same functionality to another tool, RenderEvents.

turboBB73 wrote on 10/24/2020, 5:32 PM

A small correction and update regarding Avid's DNxHD codec in VP17, Windows 10 Pro x64:

Thanks to @Musicvid and the MovieStudioZen tutorial linked by @Chief24, I was able to get this working, and as @Musicvid pointed out in is original post, far smaller file sizes are possible with this, and there are a great deal of parameters available for controlling the rendering quality.

For example, the 7-second test render (with alpha-channel) I tried, exported a compressed MOV file, that in contrast to the 2GB uncompressed AVI, was a mere 500MB, and the quality looks very good.

Worth mentioning though, for anyone who might read this thread afterwards, to be able to use the Avid DNxHD codecs in VP17/Windows 10 Pro x64, required first installing the old QT for Windows codecs (perhaps the most inelegant part of it, but "whatever works" certainly applies here).

Thanks again for everyone's help, time and patience. Now I've got three nice alpha-channel options available.

Thank you so much for posting this follow up! I've been trying to get Avid Codec to work and despite installing the latest version and QT I still couldn't import DNxHD MOV files to VP15. The key here is as you said, you need an older version of QT (I used v7.6 from here) in order to make this all work. I recall now getting errors when installing QT 7.79.

john_dennis wrote on 10/24/2020, 6:09 PM

@turboBB73

Magic YUV 2.3 has a plug-in for later versions of Vegas Pro and supports lossless with alpha channel. No need for Quicktime, etc.

https://www.magicyuv.com/

Anyone who drinks coffee could probably spring for $14 US.

turboBB73 wrote on 11/14/2020, 9:28 PM

@john_dennis - thx for this suggestion, I installed the trial version but I still can't open the DNX encoded files. I'm on VP15 so I'm guessing it only has the plug-in for 17 and up?

john_dennis wrote on 11/15/2020, 11:54 AM

@turboBB73

Magic YUV does not decode DNX encoded files. Magic YUV RGBA can be used as an intermediate with alpha channel with a moderate file size and excellent playability. If you have DNX encoded files in a MOV wrapper that you must use, you have to proceed with getting a workable decoding solution.

While handy, a plugin for MagiC YUV is not absolutely necessary. You can access the Magic YUV RGBA settings under Video For Windows by making and saving a Custom Template from one of the existing templates.