Comments

Thanks to this post I was able to finally understand why in Vegas 15 Build 321 the images from my Phantom were running fine and in Build 361 it was crashing.

As I understand it, in Build 321 these Blacklist formats were encoded natively by Compoundplug and not by so4compoundplug and you could not change that.

In Build 361 these blacklist formats are now encoded by so4compoundplug natively, but Magix gave us the option to switch to compoundplug using Blacklist. I get it right?

From Vegas Pro 15 build 384, so4_blacklist_vp15.xml is placed by default in C:\Program Files\VEGAS\VEGAS Pro 1X.0\ where it can be read, so there is no longer any need to move it.

In VP16 it still has "15" in the filename.

Hardware decoding of AVC requires the so4compoundplug decoder, but the blacklist disables so4compoundplug, even with hardware decoding enabled (Preferences > File I/O).

Some users of VP17 (e.g. and another 2 below it) have reported improved decoding of DJI/GoPro/XiaoYi AVC on NVDEC-capable NVIDIA GPUs by removing C:\Program Files\VEGAS\VEGAS Pro 17.0\so4_blacklist_vp15.xml.

If you want to try it, I recommend you rename that file to something like so4_blacklist_vp15.xmlDISABLED instead of removing it completely.

It's possible that decoding of DJI/GoPro/XiaoYi AVC is also improved with some QSV hardware decoding, and that has been available since VP15. Certainly worth a try if you use those formats and have a CPU with a good QSV capability. Besides the File I/O tab preferences in VP17, you need to check "Preferences > General > Enable QSV encoding and decoding (where available)" in VP15/16/17.

The developers are aware of this and may consider changing the default blacklist behaviour in a future version.

Please comment with your findings below if you try it.

Nick, I hope this isn't a stupid question (and please delete if it is or if it's inappropriate) but can you clarify the connection between the File I/O "Enable Hardware Decoding" setting and the Video "GPU acceleration of video processing" options.

For example, must the latter be set to something other than OFF in order for the former to have any practical use? Or indeed vice versa?

If there is no connection betwee them then what does the File I/O setting do that the GPU acceleration setting doesn't?

And, finally, do both of these relate to timeline playback only or to rendering as well (in which case, how does the choice of hardware encoder in the render template come into play?).

It's very confusing but it could be that I'm just thick.

Thanks

David

Nick, I hope this isn't a stupid question (and please delete if it is or if it's inappropriate) but can you clarify the connection between the File I/O "Enable Hardware Decoding" setting and the Video "GPU acceleration of video processing" options.

@David Johns The File I/O "Enable Hardware Decoding" setting uses the NVDEC technology in supported NVIDIA GPUs, or the QSV technology in supported Intel processors, to decode supported formats. Those formats are currently AVC and HEVC (but perhaps not all variants of those).

"GPU acceleration of video processing" uses OpenCL to accelerate playback of the timeline and GPU-enabled FX. OpenCL is available on AMD and NVIDIA GPUs, but AMD's implementation has generally worked better with VEGAS.

For example, must the latter be set to something other than OFF in order for the former to have any practical use? Or indeed vice versa?

I don't think so. I assume both can be ON if you have the technology to support it. I don't have a GPU capable of NVDEC or QSV so I can't test it. Maybe others who do can share their experience on that.

And, finally, do both of these relate to timeline playback only or to rendering as well (in which case, how does the choice of hardware encoder in the render template come into play?).

They apply to rendering inasmuch as the timeline has to be decoded as the video is rendering, although neither setting applies to the renderer itself. That setting is controlled in the "Encode Mode" on the Render As "Custom Settings" dialog. You can more or less think of that as separate from the 2 decoding-related settings, although I suppose there might be some performance disadvantage to using either NVIDIA or Intel for both decoding and encoding.

It's very confusing but it could be that I'm just thick.

It is indeed very confusing and I don't have a complete grasp of it myself.

Maybe others who do can share their experience on that.

It is indeed very confusing and I don't have a complete grasp of it myself.

I showed my experiences here many times.
Previewing and rendering goes much faster and better with both options on.
I also had never the need to switch that so4compoundplug off, always did its job more than sufficient.

Here are my screengrabs with OBS during playing of previewing both possibilities on and off and the rendertimes of such an 1 minute 4K testproject with heavy GOPro 7 4K HEVC files, previewed in preview full 50p 4K project and rendered to a Magix AVC 4K 50p file with the default settings

Previewing

Rendering

Hardware decoding of AVC requires the so4compoundplug decoder, but the blacklist disables so4compoundplug, even with hardware decoding enabled (Preferences > File I/O).

Some users of VP17 (e.g. and another 2 below it) have reported improved decoding of DJI/GoPro/XiaoYi AVC on NVDEC-capable NVIDIA GPUs by removing C:\Program Files\VEGAS\VEGAS Pro 17.0\so4_blacklist_vp15.xml.

From what I've been able to deduce XiaoYI action cameras were added to davinci Resolve Hardware decoder blacklist due to File Size - MAX crashing it. If file size was 4GB or lower did not crash. To fix problem people re-wrap h.264. Can anyone test file size max with vegas after removing blacklist?

Hardware decoding of AVC requires the so4compoundplug decoder, but the blacklist disables so4compoundplug, even with hardware decoding enabled (Preferences > File I/O).

Some users of VP17 (e.g. and another 2 below it) have reported improved decoding of DJI/GoPro/XiaoYi AVC on NVDEC-capable NVIDIA GPUs by removing C:\Program Files\VEGAS\VEGAS Pro 17.0\so4_blacklist_vp15.xml.

From what I've been able to deduce XiaoYI action cameras were added to davinci Resolve Hardware decoder blacklist due to File Size - MAX crashing it. If file size was 4GB or lower did not crash. To fix problem people re-wrap h.264. Can anyone test file size max with vegas after removing blacklist?

@bob-h Do you mean just a re-wrap from MPEG-4 to MPEG-4? (for example using ffmpeg)

I've been told that what the 3 formats in the default blacklist have in common is that their I-frames are not marked correctly in their MP4 tables. i.e. The information in their STSS box is not accurate. This may be because they are using the same (flawed) library.

I can confirm that the following ffmpeg rewrap command does not improve so4 playback of a DJI AVC file, even at less than 4GB:

ffmpeg -i original.mp4 -c:v copy -c:a copy rewrapped.mp4