"You must look at decode only."

It certainly is about decode, because that's the topic here.

@Howard-Vigorita
Then isn't this expected behaviour because your system does not match the specs needed for 4:2:2 10 bit HEVC hardware decoding?

@Howard-Vigorita
Then isn't this expected behaviour because your system does not match the specs needed for 4:2:2 10 bit HEVC hardware decoding?

Personally, for me expected behaviour would be:

• Be able to load a 10bit/HEVC422 or 420 clip regardless of CPU/GPU configuration.
• If there's a GPU capable of decoding, use GPU.
• If there's an Intel iGPU capable of decoding, use iGPU.
• All else, use CPU for either timeline, proxy creation and rendering.

But I'm not seeing it.

Yes, I see what you mean (and I second this), though the topic is the support of HEVC 422 hardware decoding for (new generation) Intel systems. And here I can't see a difference to the Resolve news which is also bound to latest Intel generation hardware.

This thread is going in circles as we figured out the state of affairs already.

482 didn't add non-Intel GPU decoding.
The Intel decoding works with processors none of us use at this time.
There is no software decoding of these files (yet) to fall back upon where there is no dedicated or iGPU decoding option.

But when it comes to HEVC hardware decoding with Intel iGPUs, Vegas has now caught up with Resolve 17.1.
The free version of Resolve 17 opens 10-bit 4:2:0 HEVC with a garbled picture and 4:2:2 with audio only, for comparison.

FWIW, I just tested Handbrake and was able to take a 10-bit 4:2:2 HEVC file (a7S III) and convert it to a 10-bit AVC, so there are workarounds with free software if you have is this type of file and need to edit it today.

FWIW 2, you can't compare encoding and decoding abilities of GPUs by looking at FLOPS as that reflects the performance of the entire GPU. Just the decoder chip on an NVIDIA card has limited power and may or may not be any faster than the Intel decoding in an iGPU. QSV can also beat high-end GPU encoders in raw rendering speed (JN's 2080 is losing to his UHD 630 with QSV link, and turned in the 3rd fastest rendering performance to date with the Intel).

Although this thread is ostensibly about hardware decoding of the hevc 422 format, if both hardware and software support are lacking, blocking the format is an improvement over Vegas crashing or locking up... I just wasn't expecting that workaround. Fwiw, my mpc-hc viewer plays it as does the dropbox viewer. Resolve (free version), as observed by @RogerS however, only loads the video stream of the 422 version on my systems and only plays the 420 version smoothly with Nvidia gpu. Vegas plays the 420 version smoothly for me under Nvidia and Amd.

I believe Resolve (free version) is locked to 8 Bit files only, thus not really relevant in this conversation. And yes, maybe FLOPS may not be the ultimate benchmark measure, but I dare say a factor x15 throughput with identical capabilities, ie 'HEVC 420 hardware decoding' seems quite convincing, even if the truth was +/-30% deviation, nVidia would be by far the better performance to be expected, thus a better option to be pursued for the sake of value4money. Thanks @RogerS for the handbrake idea, I shall investigate ;-)

0

If it's about finding a workaround to transcode 4:2:2 10 bit HEVC to a non-Intel compatible 4:2:2 10 bit format you could also use a simple ffmpeg script to transcode to ProRes or XAVC. HOS does same job from within Vegas Pro.

Just the decoder chip on an NVIDIA card has limited power and may or may not be any faster than the Intel decoding in an iGPU.

These are the speeds of the Nvidia NVDEC's, they are all single chip like the consumer cards except for the Tesla T4.

So slow hardware decode speed is not the reason Vegas can't decode HEVC 420 10bit. Why is it they can update intel GPU decode so fast but not fix a software problem that no other Video editor has. RogerS you need to get your insiders to start talking, you can manage the dissemination of information in best possible light

FWIW, I just tested Handbrake and was able to take a 10-bit 4:2:2 HEVC file (a7S III) and convert it to a 10-bit AVC, so there are workarounds with free software if you have is this type of file and need to edit it today.

The problem there is that you lose the 4:2:2 colour, and you gain nothing, as GPU's don't decode 10bit AVC. Prores quicktime now works as it should on Vegas thanks to the recent update so you can keep your 422 colour and have a good editing experience if you use Shutter Encoder, which is an example of a nice free GUI transcoder for people that don't like command line input. This is a comparison between your 4k 420 10bit Handbrake file and the Prores422, it's very much Night and Day. The lack of timeline responsiveness is seen throughout such an AVC edit

The only non-Vegas tools I have as of today are Handbrake and Resolve, so it's good to learn new ways of transcoding files. Resolve is relevant in that people say Vegas can't do what free software does, but in the case of Resolve it is not helpful for this type of file unless you get the Studio version.

I agree ProRes makes sense as an intermediate format and I'm using that and MagicYUV, which play back well on my machine. Isn't a 10-bit 4:2:0 AVC file accelerated in Vegas with a Intel GPU?

"slow hardware decode speed is not the reason Vegas can't decode HEVC 420 10bit"
Nobody said that it was. My statement was solely that iGPUs aren't nearly as incompetent for encoding and decoding as benchmarks that look at the entire GPU would suggest (they are trash for 3D calculations, but for these dedicated tasks can be efficient).

Vegas needs a CPU decoding solution for different variants of 10-bit HEVC at a minimum so all users can bring it onto the timeline and make proxy files or transcode in Vegas. NVENC/AMD 4:2:0 support would also be very much welcome.

Going around in circles all right!

Anyway, my 2 cents. I don't have the OP's test file, had it previously, somewhere, so am using something similar, Canon R5 test sample ... CLOG, Hevc 10 bit 422.

#1 Issue is it won't currently load in VP17 and latest build VP18. Solution, use VP16. It uses the following decoder.

Streams (debug)
  Raw stream: 0
  Video stream: 0
  Codec name: 'HEVC'
  Codec name: 'Intel HEVC Decoder'
  Codec fourcc: error
  Data rate: 0 (bytes/sec)
  Text data rate: ''

#2 If you don't have VP16, and or you prefer to use VP18 b482 then transcode to either mp4 or Prores. I did both using a simple ffmpeg script, for Prores, using VFR2CFR for the mp4. On my lower specced Laptop the playback was much better using the converted Prores compared to the mp4. On my PC there was still a difference, but only slight.

#3 Magix should add back in support to VP18 for these hevc 10 bit 422 files.

#4 As per Marco's machine, HW acc., decoding assistance will only currently come with next generation. Intel iGPU and GPU's.

Using VP16, with Intel set as HW Acc. on the source, non-converted media, PC playback was ~ say 80/90% as good as the converted mp4 files, so not too shabby! About 18-20fps. But when I switched HW Acc. to the more powerful Nvidia GPU, playback went down ~ 10%. When I checked the decoder in use for the media, it still shows Intel?

Anyway, that's it.

Since we're going around in circles I'll add a link to a previous demo I did in response to the same question back in January using HOS to import A7III 10bit 422 by transcoding to ProRes 422.

https://www.vegascreativesoftware.info/us/forum/hevc-10-bit-422-and-420-howsit-going-magix-434-update-below--125821/?page=1#ca789452

For those wishing a free option, I'd suggest use of VirtualDub which IMHO is superior to apps such Handbrake for creating intermediates since in addition to creating the FFmpeg versions of ProRes, it also permits transcoding to other formats including lossless such as MagicYUV (which plays very well on the TL), GrassValley HQX, Cineform, etc. Plus, AFAIK, Handbrake has never solved its audio delay problem when transcoding to AVC.

@JN-

Here's a link to the file uploaded by the OP and the one I used for the above demo.

https://drive.google.com/file/d/1-7RDXnHrbJui-2RsllIHTHAbtOCtVkbB/view

@wwaag Thanks.

I tested the Sony hevc 10 bit 422 50 fps AVsupport clip in VP16 on my laptop. Loads into VP, plays similar to the hevc 10 bit 422 Canon R5 clip.

Very interesting--it works! Just loaded the same clip into my desktop V16 and it decodes perfectly. Not very high fps playback, but it does work. With a proxy, it would be a workable solution.

BTW: it uses the mxhevcplug.dll decoder.  Version 1.0 (Build 8532)

Same results here as @JN- and @wwaag w/v16... plays but very poorly. No Intel igpu utilization at all. Also tried v17 and that crashes as soon as it's clicked on in the explorer. Tried temporarily copying mxhevcplug.dll from v16 to v17 but that didn't work and messed up 420 decoding which was quite spectacular before I did that.

Confirmed VP17 crashed loading the file. With my all AMD computer, Resolve 17 Studio played the file without issue and smoothly. CPU usage was over 30% and GPU 9% without any corrections.

VEGASDerek wrote on 3/17/2021, 8:40 AM

We have updates to our HEVC support, specifically for 4:2:2, but we were not able to get them completed in time for this update. Hopefully we will have some improvements available for the next update.

@fr0sty thanks for this! Canon isn't on my "list" for next camera upgrades, but it's good to know that Vegas will be able to handle the file format if someone "gifts" me one!

@Reyfox As I understand it, the 4k test 10 bit 422 and 420 hevc samples are from the Sony A7S III and the Canon R5. I assume that other cameras may produce those type of files also.

@JN- both those cameras are not on my radar, but support is crucial. And if one pro editor supports it, Vegas should too.