Blackmagic Forum

Can Resolve encode H.265?

Is there a plugin which will let Resolve encode H.265?

There are no export plugins. Resolve export options are controlled by BM.
Export some intermediate file (ProRes, DNxHR, uncompressed) and use one of the x265 based encoders, ffmpeg etc.
You have Handbrake, Hybrid etc GUIs.

Thank you. I've been using a similar route of Resolve exporting QT HQ and AME making the H265.

My daydream is the Resolve developer team decides to incorporate H265 encode.

I would not go this route anyway. Resolve can't be everything and even if ti will have h265 encoder most likely it will be very average with limited options. Instead of this I would rather see ability to write plugins for Resolve export options. It would be far more powerful feature.

It's not Resolve, but the Blackmagic UltraStudio 4K Extreme can encode h265 they say (in real time) - anybody have any experience with it they can share? Wondering about experiences people have had using it with Resolve....

In order to use this box you would need to play in realtime over SDI/HDMI your Resolve timeline. This box encodes only live SDI/HDMI signal.
I rather 10x would prefer to export ProRes etc and encode with some h265 encoder. It's also expensive box.

Andrew Kolakowski wrote:I would not go this route anyway. Resolve can't be everything and even if ti will have h265 encoder most likely it will be very average with limited options. Instead of this I would rather see ability to write plugins for Resolve export options. It would be far more powerful feature.

I second that opinion!

Weird that this is not supported :/

Its the most efficient way to transfer final video for online usage.

Actually VP9 is a better codec, at least when you use YT, cause that's what YT does with your h265 - it converts it to VP9, loosing quality on the way of course. So uploading VP9 in the first place get's you better quality.

Youtube ALWAYS re-encodes, so you can't say that sending h265 gives worse quality. If you send "good enough" file then it doesn't matter if it's VP9 or h265 or h264 (or ProRes). It just has to be good quality, not already over-compressed one.

Andrew Kolakowski wrote:Youtube ALWAYS re-encodes, so you can't say that sending h265 gives worse quality. If you send "good enough" file then it doesn't matter if it's VP9 or h265 or h264 (or ProRes). It just has to be good quality, not already over-compressed one.

yes -- you are right about this 'ALWAYS', but i still have to defend franks advice.
i can not point to actual souce anymore, but somewhere it was reported, that youtube is using ffmpeg for rencoding in more computing efficient manner, e.g. by disabling the crf feature etc. it's therefor not always useful, to simply use those options, which would give the best results without such an additional and different configured reencoding step. utilizing VP9 and it's codec specific bandwidth and quality metrics control for upload, should indeed work a little bit better in this case.

Martin Schitter wrote:yes -- you are right about this 'ALWAYS', but i still have to defend franks advice.
i can not point to actual souce anymore, but somewhere it was reported, that youtube is using ffmpeg for rencoding in more computing efficient manner, e.g. by disabling the crf feature etc. it's therefor not always useful, to simply use those options, which would give the best results without such an additional and different configured reencoding step. utilizing VP9 and it's codec specific bandwidth and quality metrics control for upload, should indeed work a little bit better in this case.

Unless someone can actually demonstrate with reasonable bitrates there is a difference I will question the validity of the proposition.

Martin Schitter wrote:

Andrew Kolakowski wrote:Youtube ALWAYS re-encodes, so you can't say that sending h265 gives worse quality. If you send "good enough" file then it doesn't matter if it's VP9 or h265 or h264 (or ProRes). It just has to be good quality, not already over-compressed one.

yes -- you are right about this 'ALWAYS', but i still have to defend franks advice.
i can not point to actual souce anymore, but somewhere it was reported, that youtube is using ffmpeg for rencoding in more computing efficient manner, e.g. by disabling the crf feature etc. it's therefor not always useful, to simply use those options, which would give the best results without such an additional and different configured reencoding step. utilizing VP9 and it's codec specific bandwidth and quality metrics control for upload, should indeed work a little bit better in this case.

They have to re-encode as they need all different profiles (which are very specific) and have to be aligned for smooth streaming.
You may say that re-encodign from VP9 to VP9 may give some advantage, but I doubt it's at the level of being visible (specially that youtube compresses so much). Not sure how else uploading VP9 can be beneficial to the end quality.

Cary Knoop wrote:
Unless someone can actually demonstrate with reasonable bitrates there is a difference I will question the validity of the proposition.

Here you go

This new format bumps everybody one notch closer to our goal of instant, high-quality, buffer-free videos. That means that if your Internet connection used to only play up to 480p without buffering on YouTube, it can now play silky smooth 720p with VP9.

VP9 also has benefits for people with limited bandwidth or expensive data plans. By cutting bitrates in as much as half, it dramatically increases the set of users that can watch 360p quality video without increased rebuffering or cost.

Opening the door to 4K
And for those who can never get enough pixels (including your humble author!), VP9 unlocks the burgeoning world of 4K videos. At larger video sizes, VP9 actually gets even more efficient than its predecessors, so uninterrupted 4K content can now be streamed by a significant and growing part of the YouTube audience. The amount of 4K video uploaded to YouTube has more than tripled in the past year, and VP9 helps us plan for improved streaming into the future.

[/quote]



https://youtube-eng.googleblog.com/2015 ... utube.html

the main advantage of vp9 should be seen in the fact, that you do not have to fight all this licensing issues, like in the case of ProRes and and MPEG codecs. while i can somehow understand, that manufactures are not able to support this other export formats in the free versions of their applications, because of economic reasons, this isn't an excuse to exclude vp9. it's therefore hard to understand, why this option isn't used, to give us at least one up to date and efficient delivery codec of acceptable quality. nevertheless i would appreciate at least h.264/h.265 import capabilities in all variants (=linux too!) of resolve. this codecs may not be very useful for the high demands of professional "studio" work, but they would be very handy for the average user resp. less profitable amateurish work and ingest from consumer cameras.

and for sure, i second this request for plugin support!

Frank Glencairn wrote:Here you go

This new format bumps everybody one notch closer to our goal of instant, high-quality, buffer-free videos. That means that if your Internet connection used to only play up to 480p without buffering on YouTube, it can now play silky smooth 720p with VP9.

VP9 also has benefits for people with limited bandwidth or expensive data plans. By cutting bitrates in as much as half, it dramatically increases the set of users that can watch 360p quality video without increased rebuffering or cost.

Opening the door to 4K
And for those who can never get enough pixels (including your humble author!), VP9 unlocks the burgeoning world of 4K videos. At larger video sizes, VP9 actually gets even more efficient than its predecessors, so uninterrupted 4K content can now be streamed by a significant and growing part of the YouTube audience. The amount of 4K video uploaded to YouTube has more than tripled in the past year, and VP9 helps us plan for improved streaming into the future.

Nobody is questioning that VP9 (or H.265) is a more efficient codec than earlier generation codecs.

That was not the discussion, the discussion is about the argument that it is better to upload a video with VP9 than any other codec with a similar PSNR because YouTube re-encodes the video to VP9.

Cary Knoop wrote:That was not the discussion, the discussion is about the argument that it is better to upload a video with VP9 than any other codec with a similar PSNR because YouTube re-encodes the video to VP9.

just to get a vague idea, why using the same compression method/settings or at least very similar principles of indirect description of the actual image content, may lead to better results, take a look at this links:

about the general resp. mathematical foundation of the problem:

https://en.wikipedia.org/wiki/Generatio ... ranscoding

https://books.google.at/books?id=8uLEXlN9ouAC&lpg=PA388 (The Art of Digital Video, p. 388-395)
"Concatenation loss occures when the losses introduced by one codec are compounded by a second codec.
...
It is now increasingly accepted that concatenation of compression techniques is potentially damaging and results are worse if the codecs are different."

http://www.dvxuser.com/V6/showthread.ph ... what-is-it

https://tech.ebu.ch/docs/techreview/trev_271-dalton.pdf (p. 39)
"When codecs are concatenated, the overall PSNR
is a function of several factors, the most important
being:

a) The PSNR generally accumulates according to
a root-mean-square law (see Fig. 4). Thus for
two similar codecs, the PSNR is reduced by
approximately 3dB. For dissimilar codecs, the
PSNR of the higher compression unit domi-
nates but errors from the lower compression
unit can still reduce the overall PSNR.
..."


and about the particular importance of the first [few] transcodings in particular:

http://goughlui.com/2016/11/22/video-co ... s-testing/

Yes, but in case of youtube you need many profiles at different resolutions, so when frame size changes importance of the same codec also weakens (no?).
On top of this add fact that youtube uses low bitrates, so this will overshadow basically everything else.

Other way- it's way easier to "compensate" h264 encode by using bit higher bitrate than encoding VP9. It's waste fo time to encode VP9 only because for given size you MAY get 1dB higher PSNR on youtube, which will look quite crap anyway.
This may have more meaning if you use really low bitrate for youtube master, but then again you use VP9 mainly because it's more efficient.

Also- don't forget that youtube still creates h264 encodes as well, so what you watch is not always VP9.

Andrew Kolakowski wrote:youtube uses low bitrates, so this will overshadow basically everything else.

^This.

This whole discussion that you would get better results on YouTube if you use VP9 instead of any other codec with the same PSNR is entirely academic.

Andrew Kolakowski wrote:Yes, but in case of youtube you need many profiles at different resolutions, so when frame size changes importance of the same codec also weakens (no?).

yes, andrew, that's indeed a sound argument. there are many aspects, where this actual changes will have more impact than the benefits of using the same compression technology. but for other aspects, this doesn't have to be true. advanced features like the motion compensation capabilities or intra prediction features of newer codecs, which set them apart from more primitive predecessors, may be not affected by this changes to the same extent. the set of this kind of elementary compression features simple define the "language", how an indirect and more compact description of the image sequence can be expressed. and this also structures their capabilities to "translate" and prevent some aspects resp. image details across the mentioned changes.

in usage scenarios, where most of this circumstances remain unchanged (i.e. only intra frames, constant resolution and macro block size etc.), this doesn't have much significance. that's one of the reasons, why relative simple codecs, like prores/dnxhr/mpeg2, still behave exceptionally well in practical video editing work and usually do not show excessive generation loss. but the huge changes between the representation in mezzanine codecs and the final delivery and also between different types of highly compressed video footage are much more critical in this regard.

nevertheless your objection is perfectly valid and plausible, and i don't want to argue in a pure speculative manner. but i also try to consider this simple fundamental principles of data compression in my practical decisions. once you become aware of this kind of issues, you simply can not act anymore like a naive virgin and mix up all kind of completely different codecs in a carefree eclectic and arbitrary manner.

Andrew Kolakowski wrote:On top of this add fact that youtube uses low bitrates, so this will overshadow basically everything else.

yes -- but as already quoted in my last message, it still makes a difference, whether different codecs are in involved!
if you use the same or very similar compression method twice in different intensity, the result is indeed defined mostly by the stronger compression process. but in case of different compression methods, the errors introduced by both techniques may summarize.

Andrew Kolakowski wrote:Other way- it's way easier to "compensate" h264 encode by using bit higher bitrate than encoding VP9. It's waste of time to encode VP9 only because for given size you MAY get 1dB higher PSNR on youtube, which will look quite crap anyway.

well -- if you don't care about this minor differences, you could also just follow the advises for the average user at the youtube FAQ page.

and if you really want better results, self hosting is perhaps the most promising and more consequent way to archive this goal. but then, at the latest, you will have to learn a little bit more about the real benefits and practical relevance of vp9 in nowadays delivery of video data.

Andrew Kolakowski wrote:Also- don't forget that youtube still creates h264 encodes as well, so what you watch is not always VP9.

yes -- but that's more ore less just a fallback alternative of even less satisfying image quality for a nearly negligible small share of apple devices, which still do not support vp9. but in practice vp9 is by far the most important codec for video delivery over the web today. it's a little bit different, whenever hardware decoders and consumer devices are also involved, which often lag behind because of less flexible adaptation capabilities, but wherever software or more recent graphics accelerators are utilized for decoding, vp9 has undoubtedly won the game. h.265/hevc, which could have been an equal alternative, is simply irrelevant in practice, because it's not supported by most browsers due to all this well known licensing troubles.

I can encode to VP9 in DR Studio on my Mac, but it's very sloooow…

This was my last argument for Martin. VP9 is atm. very slow, to the point where it's almost unusable in many situations.

Martin Schitter wrote:

Andrew Kolakowski wrote:Other way- it's way easier to "compensate" h264 encode by using bit higher bitrate than encoding VP9. It's waste of time to encode VP9 only because for given size you MAY get 1dB higher PSNR on youtube, which will look quite crap anyway.

well -- if you don't care about this minor differences, you could also just follow the advises for the average user at the youtube FAQ page.

and if you really want better results, self hosting is perhaps the most promising and more consequent way to archive this goal. but then, at the latest, you will have to learn a little bit more about the real benefits and practical relevance of vp9 in nowadays delivery of video data.

I definitely don't want to follow youtube guides, but don't want to wait for VP9 crazy slow export times either

Andrew Kolakowski wrote:I definitely don't want to follow youtube guides, but don't want for VP9 crazy slow export times either

yes, vp9 encoding is unfortunately very slow. usually you only get about 50% of libx256 speed in most software implementations. but if you own a quite recent intel cpu, you could utilize the hardware accelerated ' vp9_vaapi' of ffmpeg, which should provide quite satisfaying encoding frame rates.

and 'slooooow' is always a very stretchable term... have you ever enjoyed the encoding speed of AV1?