Blackmagic Forum

Morning (o;

Just out of curiosity....will there ever be h264 encoding in resolve studio for Linux?
Or what is the exact reason there isn't any h264 encoding option but all other video editors on Linux have this option?

Do you run the rendered video then through ffmpeg to get for example 1080p youtube video?


wish a nice weekend (o;
richard

It all comes down to cost.
Adding h264 encoder requires licensing some h264 SDK, eg. Mainconcept and maybe some other fees.

That's too bad....

No possibilities to hook up like external ffmpeg encoder?
Resolve on Linux uses all sorts opensource libraries like libavcodec, libavformat and opencv.

So what do you use when you need h264 output?

You end up with two choices:

1. Buy DaVinci Resolve Studio. The paid version supports the encoding of Quicktime H.264 .MOV files.

2. Use an external tool like ffmpeg to transcode from another export format.

That’s really about it. H.264 support exists on the other operating systems because they come bundled as part of the OS (macOS definitely, but I believe so for Windows, too). As Resolve is made for the film industry where H.264 is 98% never used for anything, it’s not a high priority for BMD as their original target audience doesn’t really have a need for it. Particularly for studios running Linux.

Cheers,
Mike

MikeRochefort wrote:1. Buy DaVinci Resolve Studio. The paid version supports the encoding of Quicktime H.264 .MOV files.

Last I checked, the Linux Studio version allows h264/hevc decoding. You can import files with those codecs, business as usual.

MikeRochefort wrote:2. Use an external tool like ffmpeg to transcode from another export format.

Yup, that or Handbrake.

Those in the know have repeatedly said Resolve's h264 encoding on Win/Mac is not much to write home about in comparison to Handbrake/FFMPEG, so you're better off exporting to DNxHD and transcoding it separately.

Hmm..mp4 is the only option in resolve studio on linux....
Wonder why mp4 isn't the default preset for Youtube (o;

BTW: Why should I buy again resolve studio?

For other encoding stuff I use mostly kdenlive as it accepts most of the videos you throw at it and you can cut it to your needs if necessary...

Sulo Kokki wrote:Last I checked, the Linux Studio version allows h264/hevc decoding. You can import files with those codecs, business as usual.

The Supported Codecs document explicitly states that Quicktime H.264 video in a MOV container is possible to encode. All others are decode only. Then again it also says that ProRes is possible to encode but doesn’t mention that you need to purchase the $30,000 Advanced Panel in order to do so.

Cheers,
Mike

Last I checked was v14

But it does indeed show h264 encoding on v15. Another 'quiet' update on the Linux port, then, due to demand. That's nice, but v15 still needs the Advanced Panel dongle for ProRes, in the absence of reason.

In any case, the Linux port is catching on at its merry pace.

Where does it show h264 encoding in v15 resolve studio linux?

The closest thing I see is quicktime container and mp4 video...

If it says MP4 and not MPEG4 that might be it. I’m not completely sure, and I won’t be able to check until tomorrow. You could always run a quick render and use a video inspector to see what codec it’s using.

Cheers,
Mike

Well vlc shows it clearly as mpeg4 video codec and not h264 like produced mp4 files from kdenlive...

Youtube will accept both and recode if neccessary...for websites with html5 I recode it with kdenlive then...

MikeRochefort wrote:the film industry where H.264 is 98% never used for anything

H.264 is used for probably 98% of deliverables, when you include Home Video, Netflix, Amazon, Hulu, YouTube, etc.

Which makes me wonder why there is a youtube preset in linux but no h264

I assume most hobbyist films are published on the web rather then on tv or cinemas...

Vimeo will let you upload ProRes for playback, and YouTube is a complete mess. They transcode everything into extremely bit-starved VP9, so people have taken to exporting HD timelines to 4K, exporting in a mezzanine codec, and then uploading to YouTube, as that will net you a more reasonable number of bits per pixel.

As far as industry delivery goes, we deliver to many VOD platforms, all in h264, but they are require a more reasonable number of bits. At least one was 35Mb/s for HD.

Jim Simon wrote:H.264 is used for probably 98% of deliverables, when you include Home Video, Netflix, Amazon, Hulu, YouTube, etc.

Okay, you got me there . Streaming services as an end point pretty much rely on the format. I was referring to the more specific cinema industry where DaVinci originates (if that word is appropriate). I also tend to forget that delivery could mean final, rather than just handing off to the next person/studio in line as I'm usually never at the end of the chain. I feel like Resolve as an NLE is still pretty new so most places doing editorial are still in the Adobe/Avid camp (note: this is an uneducated assumption as I don't work in editorial).

As a broader question, how prevalent is Linux in post houses (not VFX houses)? I usually think or assume they're using macOS or Windows, where these codecs come free, as their environment/pipeline requirements/setups are probably pretty different than for those of us in VFX.

Cheers,
Mike

MikeRochefort wrote:I feel like Resolve as an NLE is still pretty new so most places doing editorial are still in the Adobe/Avid camp (note: this is an uneducated assumption as I don't work in editorial).

Since I work in editorial, I can easily confirm this It varies based on where you work, but the editing scene is still dominated by Avid, Adobe, and FCP here and there.

I know that there are some editors who are really excited about the potential of Resolve as an NLE, but they mostly can't still use it either because of some rough edges here and there or because the client simply demands that they work on a specific software.

As someone who does lots of freelance work, I still haven't managed to get a project where I can use Resolve since all of my clients specify the software they want me to use.

MikeRochefort wrote:As a broader question, how prevalent is Linux in post houses (not VFX houses)? I usually think or assume they're using macOS or Windows, where these codecs come free, as their environment/pipeline requirements/setups are probably pretty different than for those of us in VFX.

Although I haven't worked in a post house, my understanding is that Linux almost doesn't exist when it comes to editing specifically. That is mostly due to the fact that the main three NLEs don't have Linux versions at all.

There might be some audio post houses out there that use Linux since the state of DAWs on Linux is slightly better that NLEs. However, I highly doubt that they exist.

Grading might be a bit different since Resolve existed on Linux for years, so there could some places that are using Linux for their grading setups, but I am not a colorist myself so I cannot say for sure.

MikeRochefort wrote:As a broader question, how prevalent is Linux in post houses (not VFX houses)? I usually think or assume they're using macOS or Windows, where these codecs come free, as their environment/pipeline requirements/setups are probably pretty different than for those of us in VFX.

all necessary codecs are available on any common linux distributions as well! and it's coming for free like on those other operationg systems. it's just restricted by licensing issues. but that's just the same situation as on mac and windows systems, because they also do not allow you any professional use of the system provided codecs! that's explicitly stated in the EULAs of all those commercial operating systems...

and concerning all those never ending laments about the insufficient quality provided by free video platforms:

just take a simple HLS or DASH creation tool like: https://github.com/vincentbernat/video2hls
and a free html5 video player component for adaptive streaming like: https://github.com/videojs/http-streaming
and you can host your videos yourself on any simple webserver or CDN in any quality you want!

Martin Schitter wrote:but that's just the same situation as on mac and windows systems, because they also do not allow you any professional use of the system provided codecs! that's explicitly stated in the EULAs of all those commercial operating systems...

I did some more digging and it seems that this is a misunderstanding of the MPEG LA licensing. The licensing of patents like H.264 and HEVC are the beginning and end points of the distribution chain. So Apple and Microsoft pay royalties to have the codecs' encoders and decoders built in to the OS and made available to other applications that sit on top like FCPX or Premiere (they also have to be licensed accordingly, I believe. Built-in vs 3rd-party I haven't found distinct info for yet). End users can then utilize those codecs, regardless of their use case (business or not). The distributors of that finished content however, ie Vimeo, Google, or your own personal hosting service if you have one, those are the ones who need to pay the other side of the royalties. Users utilizing them locally to create content are not the ones who are required to pay anything or are breaking EULA's. Essentially bigger businesses are paying for your ability to use the codec.

The non-commercial/personal use is unclear in its context and poorly worded.

I've gotten my info from the following three articles, all of which were written before an apparent 2015 update to the terms of agreement in regards to free distribution that depended on how popular things got (the gist of it). I'm not a lawyer, and I may have missed something, so I do suggest reading them yourself.

https://www.engadget.com/2010/05/04/kno ... g-and-you/
https://www.zdnet.com/article/a-closer- ... -licenses/
https://betanews.com/2010/05/19/10-ques ... -on-h-264/

The best course of action would be to reach out to MPEG LA itself, or Apple too and ask for clarification.

Cheers,
Mike

MikeRochefort wrote:So Apple and Microsoft pay royalties to have the codecs' encoders and decoders built in to the OS and made available to other applications that sit on top like FCPX or Premiere (they also have to be licensed accordingly, I believe. Built-in vs 3rd-party I haven't found distinct info for yet).

i already quoted the relevant section from this operating systems EULAs just a few days ago:

"NONE OF THE LICENSES EXTEND TO ANY OTHER PRODUCT..."

MikeRochefort wrote:

Martin Schitter wrote:but that's just the same situation as on mac and windows systems, because they also do not allow you any professional use of the system provided codecs! that's explicitly stated in the EULAs of all those commercial operating systems...

I did some more digging and it seems that this is a misunderstanding of the MPEG LA licensing. The licensing of patents like H.264 and HEVC are the beginning and end points of the distribution chain. So Apple and Microsoft pay royalties to have the codecs' encoders and decoders built in to the OS and made available to other applications that sit on top like FCPX or Premiere (they also have to be licensed accordingly, I believe. Built-in vs 3rd-party I haven't found distinct info for yet). End users can then utilize those codecs, regardless of their use case (business or not). The distributors of that finished content however, ie Vimeo, Google, or your own personal hosting service if you have one, those are the ones who need to pay the other side of the royalties. Users utilizing them locally to create content are not the ones who are required to pay anything or are breaking EULA's. Essentially bigger businesses are paying for your ability to use the codec.

The non-commercial/personal use is unclear in its context and poorly worded.

I've gotten my info from the following three articles, all of which were written before an apparent 2015 update to the terms of agreement in regards to free distribution that depended on how popular things got (the gist of it). I'm not a lawyer, and I may have missed something, so I do suggest reading them yourself.

https://www.engadget.com/2010/05/04/kno ... g-and-you/
https://www.zdnet.com/article/a-closer- ... -licenses/
https://betanews.com/2010/05/19/10-ques ... -on-h-264/

The best course of action would be to reach out to MPEG LA itself, or Apple too and ask for clarification.

Cheers,
Mike

Yes, so you as private person can in theory produce free h264 content, but MS or Apple or BM when selling a tool needs to pay license. This is how I understand it. Also when you as a private person start producing content commercially and make money on it then you may also need to pay license.
BBC did pay a lot of money to MPEG LA, so they can legally use h264 in ffmpeg.

Andrew Kolakowski wrote:Yes, so you as private person can in theory produce free h264 content, but MS or Apple or BM when selling a tool needs to pay license. This is how I understand it. Also when you as a private person start producing content commercially and make money on it then you may also need to pay license.
BBC did pay a lot of money to MPEG LA, so they can legally use h264 in ffmpeg.

that's how i would read it, too.

nevertheless i'dont see the significant difference between the situation on mac os/windows and linux, because this explicitly stated limitations (i.e. "non-extensibility") affecting third party software and the rather narrow conceived freedom of personal/non-commercial use doesn't look so much different on all those operating systems. no matter, if you utilize an open source implementation of the patented techniques or the system provided codecs of commercial operating systems, you would always have to pay [presumable the same amount of] royalties.

Andrew Kolakowski wrote:Yes, so you as private person can in theory produce free h264 content, but MS or Apple or BM when selling a tool needs to pay license. This is how I understand it. Also when you as a private person start producing content commercially and make money on it then you may also need to pay license.

I agree with all but the last part. My understanding is that even then you don’t need to pay a royalty unless you are the one distributing it to the end users for viewership. I’m not saying this is right, but it’s the interpretation I read considering Flash also had a similar license.

In regards to the Apple stuff, I’m assuming that they didn’t write a license for macOS, but rather for Quicktime. Otherwise they may have had to pay royalties for Quicktime, FCP, iMovie, Logic Pro, iTunes, and possibly Garageband. Since they filter everything through Quicktime they pay once. I’m pretty sure that’s also how BMD does it on the Apple platform, and sublicense access to Quicktime in the process. I wouldn’t particularly know what they do on Windows.

Considering on Linux they already support the decoding of H.264 and H.265 streams (with or without ffmpeg), and the encoding of a Quicktime version (supposedly), to me it stands to reason that they just haven’t spent the time on adding the support for the encoding of unless their specific license agreements are platform restricted which would be weird. I’ll take a dig through the libraries later today that are included in Resolve and see if I can determine which ones might be used for decoding. I’ve never bothered looking through its libraries yet. All they really need is support for the x264/x265 encoders which appear to be the only known encoders for Linux, but if they want to include them in the build as binaries to call they will have to pay a licensing fee. Since they already pay Apple for Quicktime maybe they think that’s enough for now.

Cheers,
Mike

Well it contains:

Code: Select all

klingler@debian:/opt/resolve$ ls -l libs/libav*
lrwxrwxrwx 1 root root       23 Mar 29 13:55 libs/libavcodec.so -> libavcodec.so.57.24.102
lrwxrwxrwx 1 root root       23 Mar 29 13:55 libs/libavcodec.so.57 -> libavcodec.so.57.24.102
-rwxr-xr-x 1 root root 13191128 Mar 29 13:55 libs/libavcodec.so.57.24.102
lrwxrwxrwx 1 root root       24 Mar 29 13:55 libs/libavformat.so -> libavformat.so.57.25.100
lrwxrwxrwx 1 root root       24 Mar 29 13:55 libs/libavformat.so.57 -> libavformat.so.57.25.100
-rwxr-xr-x 1 root root  2073144 Mar 29 13:55 libs/libavformat.so.57.25.100
lrwxrwxrwx 1 root root       22 Mar 29 13:55 libs/libavutil.so -> libavutil.so.55.17.103
lrwxrwxrwx 1 root root       22 Mar 29 13:55 libs/libavutil.so.55 -> libavutil.so.55.17.103
-rwxr-xr-x 1 root root   391536 Mar 29 13:55 libs/libavutil.so.55.17.103


So libavcodec is there...but it seems they left out the h264 encoder part intentionally...

Code: Select all

klingler@debian:/opt/resolve/libs$ strings libavcodec.so.57.24.102 | grep 264
avpriv_h264_has_num_reorder_frames
h264
H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10
s->avctx->codec_id != AV_CODEC_ID_H264
libavcodec/h264.c
Q264
H264 Decoder
libavcodec/h264_cavlc.c
h264_mp4toannexb
libavcodec/h264_picture.c
libavcodec/h264_refs.c
x264 - core %d
x264 - core 0000
libavcodec/h264_slice.c
h264_slice_header_init() failed
h264_slice_header_init() failed
libavcodec/h264dsp.c
(Plibavcodec/h264pred.c
dct264
memory management control operations (H.264)
ff_h264_check_intra_pred_mode < 0


It would be really nice if someone from Blackmagic shed some light on this issue. As users, we shouldn’t be left in the dark to speculate about why a key feature of an NLE is missing from the Linux version of their app.

Please respond Blackmagic devs! If it’s down to licensing, why isn’t this covered in the purchase cost of the studio version?

BMD is pretty open about what codecs are supported and what not.

https://documents.blackmagicdesign.com/DaVinciResolve/20180426-942419/DaVinci_Resolve_15_Supported_Codec_List.pdf

Yes, I’ve read that document already. It just doesn’t seem reasonable that just because we’re using Linux, we don’t have the ability to encode into h.264. It’s a common non platform specific codec. If I’m paying for the h.264 licence on Windows & Mac when I buy the studio version, that should be extended to Linux too. I’m never going to be using Resolve on Windows or macOS. It’s pretty clear that this codec is a key feature of the software as ‘YouTube’, ‘Vimeo’ etc are encoding presets in the export space. These buttons are essentially broken in the Linux version.

Stephen Thomas wrote:Yes, I’ve read that document already. It just doesn’t seem reasonable that just because we’re using Linux, we don’t have the ability to encode into h.264. It’s a common non platform specific codec. If I’m paying for the h.264 licence on Windows & Mac when I buy the studio version, that should be extended to Linux too. I’m never going to be using Resolve on Windows or macOS. It’s pretty clear that this codec is a key feature of the software as ‘YouTube’, ‘Vimeo’ etc are encoding presets in the export space. These buttons are essentially broken in the Linux version.

On the otherhand the linux version is a lot faster with a lot of cores/threads than the apple and windows version. You can't have it all (well you actually can if you want to). Their are many options to transcode to h.264/x.264 so it's not much of a problem to be honest. Staxrip on windows is the fastest with the most possible settings these days that I know of (yes also 3 pass) and it scales linear upto atleast 16c/32tr.

And there is always Wine to the rescue https://wiki.winehq.org/Main_Page

The Intel CPUs (Skylake, Kaby Lake, and some Xeons) with the Intel Graphics iGPU have powerful H.264 and H.265 hardware decoding for the timeline and encoding (QSV) including HDR, 10 bit HEVC and Rec 2020.
I read some time ago BMD added Intel iGPU support to Resolve but not sure if they added QSV encoding as a render option as many other NLEs have. Could hardware encoding overcome the Linux vs Win codec problem? It's fast - they even claim 4k30p HEVC real-time encode.
https://www.anandtech.com/show/10959/intel-launches-7th-generation-kaby-lake-i7-7700k-i5-7600k-i3-7350k/6

Well I read some time ago that the Intel hardware encoder isn't of good quality when it comes to h264/h265...

But for Youtube it would be by far sufficient

What a discussion I started (o;

For me on the Linux platform it would be nice if I could hook in an external encoder like ffmpeg as a command line argument with placeholders...

Yes, thanks for starting this discussion

I know there are ways around not having h.264, like encoding in ffmepg, but it’s an extra step that could seemingly be removed very simply by Blackmagic. I have a Mac specifically for encoding for Clearcast (Compressor and Sorensen Squeeze are pretty much the only encoders that Clearcast will accept files from), so I’m fine going the extra mile for encoding when it’s needed. When I need to just get something out for client review though, it’s a hassle to export from Resolve in one format, then transcode into another format again for streaming. I can’t think of one other video application that doesn’t offer h.264 as an option. Even bloomin Photoshop can do it and that’s not a video application...

I'm curious : which codec do you use to transcode h264 videos and use them in Resolve ? Because I use Resolve with Windows 10 (for YouTube videos), I like it very much and I plan to switch on Linux.

And my last problem is about video editing : kdenlive and other software don't have for exemple audio/video autosync, and I must admit, even I did it manually before, it's a really nice feature.

Thanks a lot,

Jim Simon wrote:

MikeRochefort wrote:the film industry where H.264 is 98% never used for anything

H.264 is used for probably 98% of deliverables, when you include Home Video, Netflix, Amazon, Hulu, YouTube, etc.

Yes, however, both Netflix and Amazon require prores hq as mastering from facilities

Jim Simon wrote:

MikeRochefort wrote:the film industry where H.264 is 98% never used for anything

H.264 is used for probably 98% of deliverables, when you include Home Video, Netflix, Amazon, Hulu, YouTube, etc.

in fact it's nowadays mostly VP9, which is used for most high quality delivery over the net. only apple is strictly boycotting this free alternative and only supports h.264 and h.265 in their browsers [and seems to have lot of interest to maximize MPEG LA royalty shares], but for all other devices, video platform companies and end user interests VP9 is a better choice and helps to save a lot of money...

waltervolpatto wrote:Yes, however, both Netflix and Amazon require prores hq as mastering from facilities.

i think, even in professional production contexts it is quite useful, to have this more consumer oriented simple import/export capabilities available -- e.g. for all sorts of simple preview exchange, etc.

davorin wrote:Well I read some time ago that the Intel hardware encoder isn't of good quality when it comes to h264/h265...
But for Youtube it would be by far sufficient

That was "some time ago" and there were some quality issues with the old 4000 series iGPUs but it has been fixed. Many NLEs, like Edius, now support it for timeline decoding and hardware accelerated encoding (intel Quick Sync - QSV). Also has VP9 (8 bit) as per table above. Would also be good for laptops as many have i7 CPUs with integrated Intel Graphics iGPUs.
I think BMD worked with Intel to add Resolve support and would appreciate more info on if, when, and how.

BMD's support of QSV has been raised before and I believe it would be a great idea. When I want a good H264 (or H265) render at a relatively low bitrate, I render out in DR at maximum bitrate and then re-encode with Handbrake using QSV at that lower bitrate. It's nice and quick -- and it's also very good quality, markedly better than the results I get from DR at the same bitrate so if there were quality issues before, it looks like they've been fixed recently.

Hmm...Haven't seen any QuickSync support on macOS nor on Debian Handbrake...not even on the nightly builds...is that on Windows only?

davorin wrote:Hmm...Haven't seen any QuickSync support on macOS nor on Debian Handbrake...not even on the nightly builds...is that on Windows only?

Supported on FCPX and PremierPro 2018. Couple of examples.

Halve your export times in Premiere Pro cc2018 LATEST UPDATE

Premiere CC 2018 H264 uses Quick Sync, faster than FCPX on iMac Pro at H264 encoding
https://forums.creativecow.net/thread/335/101459

HandBrake for Mac 1.1.1
https://www.techspot.com/downloads/3469-handbrake-for-mac.html
"What's New: Improved Intel QuickSync Video support"

(I'm not a mac user so can't verify)

Ah no I meant Handbrake with QuickSync support (o;

I totally dropped Adobe Cloud lately in favour of other software

RCModelReviews wrote:BMD's support of QSV has been raised before and I believe it would be a great idea. When I want a good H264 (or H265) render at a relatively low bitrate, I render out in DR at maximum bitrate and then re-encode with Handbrake using QSV at that lower bitrate. It's nice and quick -- and it's also very good quality, markedly better than the results I get from DR at the same bitrate so if there were quality issues before, it looks like they've been fixed recently.

+1
Intel also claim H.265 at 120 Mb - shouldn't be too shoddy Once again - probably not for the pros but a valuable enhancement to Resolve for many of us (now that it's not priced only for the pros) and a common feature in many other NLEs as mentioned above which compete with Resolve.

The Intel iGPU does not rate highly as a gaming GPU but has some powerful media capabilities for editing including H.264 & H.265 timeline decoding and fast hardware render. Intel offer a SDK for it.

For those not familiar with with it here is a video explaining how Grass Valley added it to Edius 8 plus a list of Intel CPUs that have the iGPU (most consumer desktops and laptops). Edius 10.1 has added H.265 10 bit support.


And the GV link with CPU list
https://www.edius.net/quicksync.html

You always have to remember that HW decoding is strictly for 4:2:0 files only+ in case of H264 also 8bit only!

Andrew Kolakowski wrote:You always have to remember that HW decoding is strictly for 4:2:0 files only+ in case of H264 also 8bit only!

in practice you should only use 4:2:0 for h.264/h.265 content, which should be compatible and playable by most existing software and display devices. it's horrible, if you use 4:2:2 e.g. for video streaming over the net, but only very few people are able to watch it without serious troubles in their browsers or on smart tv sets etc.

4:2:2 also doesn't bring so much quality gain in real world. this kind of asymmetric color subsampling was only invented for interlaced video processing, where you simply had proceed the horizontal axis in a different way than the vertical one, because the individual fields of the data stream were also showing this characteristics. but in our days, where we usually try to avoid interlaced video formats as much as possible, 4:2:2 is more a reminder from the past, which IMHO doesn't make much sense in practice anymore.

4:4:4 is much more consequent choice, if you really want to avoid any color subsampling side effects. this variant is more likely supported by a hardware acceleration solutions, but i still wouldn't use it for any real world delivery.

Andrew Kolakowski wrote:You always have to remember that HW decoding is strictly for 4:2:0 files only+ in case of H264 also 8bit only!

Thanks Andrew - True but 10 Bit 4k H.265 HDR is also 4:2:0 so we are getting 10bit sampling per pixel with Rec 2020 color. I'm still using 8 bit Rec 709.
It could solve the problem of 4K AVC and HEVC laptop editing .
As I said above it probably not for the pros but works on Linux, Mac and Windows.
With your codec knowledge (never ceases to amaze me) maybe you might understand this additional info (way over my head)

Enable Billions of Colors with 10-Bit HEVC
https://software.intel.com/en-us/articles/enable-10bpp

And here is some info on the Intel® Media Server Studio SDK
Deliver High Quality, High Performance HEVC via Intel® Media Server Studio
https://software.intel.com/sites/default/files/managed/b8/d0/intel-hevc-whitepaper.pdf

Intel new chips support 10bit for HEVC, but none does it for H264 (and this is probably not going to change- otherwise it would be already done). h264 for Intel is bit of a past and they don't want to waste resources to add support for 10bit.
In the same time when your video is 4:2:2 then this is not supported for h264 nor h265. Intel HW decoding is for consumer market, not pro, so 4:2:2 support is just not there.
HW encoding is full of compromises and it never really can match well optimised software encoders. Still it can be very useful in many cases.

Decoding/encoding h264/5 and actual video output bit depth on DP/HDMI are 2 different things. Decoding is done on different/dedicated chip which is inside GPU, but also somehow a separate unit.

Agreed Andrew -
For delivery, AVC/H.264 is 8bit and 10 bit is HEVC/H.265 only. H.264 8 bit is fine for most web uploads including 4K for now. H.265 is growing in popularity both for capture and delivery as 4K HEVC claims better image quality at the same bitrate and half the 4K AVC file size. HEVC is a better codec but can require 10X the compute power for software encode/decode which is a challenge for NLEs..
HEVC 10 bit 4:2:0 covers HDR and Rec 2020 for the latest UHD HDR TVs and may be used for broadcast.
Neither AVC or HEVC are "edit friendly" due to high compression rates for timeline decoding.
Hardware assisted decoding is good for editing as per Edius video above.

From the Anandtech link I posted above:
"Intel claims that Kaby Lake-U/Y can handle up to eight 4Kp30 AVC and HEVC decodes simultaneously."
"With Kaby Lake-U/Y's process improvements, even the 4.5W TDP Y-series processors can handle real-time HEVC 4Kp30 encode." HEVC decode support is rated at 4Kp60 up to 120 Mbps.

In terms of encoding/render - software encoding quality, in theory, should be better due to hardware mathematical rounding - but QSV may be acceptable.
RCModelReviews (above) claims QSV is "markedly better than the results I get from DR at the same bitrate"
It's enough to test quality using Handbrake to produce AVC 8bit and HEVC 10bit with and without Intel iGPU Quick Sync (QSV) using a Kaby lake or Coffee Lake i7 CPU and visually compare the results and speed.

Andrew Kolakowski wrote:Decoding/encoding h264/5 and actual video output bit depth on DP/HDMI are 2 different things. Decoding is done on different/dedicated chip which is inside GPU, but also somehow a separate unit.

I'm no expert but according to Anandtech there are three dedicated Fixed Function Media Engines - MFX, VQE and SFC.
"The new circuitry for hardware accelerating HEVC Main10 and VP9 are part of the MFX block. The MFX block can now handle 8b/10b HEVC and VP9 decode and 10b HEVC / 8b VP9 encode. The QuickSync block also gets a few updates to improve quality further, and AVC encode performance also receives a boost."
"The Video Quality Engine (VQE) also receives some tweaks for HDR and Wide Color Gamut (Rec.2020) support. Skylake's VQE brought in RAW image processing support with a 16-bit image pipeline for selected filters."

Like the suggestion to add support for a second monitor for playback using a GPU, this may not be a solution for the pros (who need the BMD card) but a valuable enhancement for many and a useful feature currently available in many NLEs.

Intel iGPU hardware accelerated encode/decode is supported by the competition including Premiere Pro, Edius, FCPX, VEGAS PRO and others. Many are considered pro NLEs not just for the "consumer market".