Blackmagic Forum

I am trying to hit the best balance between file size and image quality for a 30 min video i am rendering but H.264 single pass encoding is not doing it for me. The video has a number of fade Ins and Outs that when rendered at anything less than 'Best' selected as a quality option they introduce ugly banding artifacts.

Multi Pass Encoding should be a good solution for this but surprisingly it is nowhere to be found on Resolve Studio v15.

The manual says:


but Resolve 15 on Windows doesn't show a Passes setting:


I don't think i have seen this setting in Resolve Studio 14 either.

Can we have an official response about this?

On a Mac, there is a control for Passes found between the Quality and Key Frame’s Settings when rendering QuickTime H.264. I found it interesting that H.265 didn’t allow me to select Passes either..


Sent from my iPad using Tapatalk

For better h.264 encoding I would suggest exporting to a mezzanine codec and to use for instance x264.

By the way, contrary to popular belief multi-pass encoding is not any better than single-pass and only makes sense when you need an exact file size.

Cary Knoop wrote:For better h.264 encoding I would suggest exporting to a mezzanine codec and to use for instance x264.

By the way, contrary to popular belief multi-pass encoding is not any better than single-pass and only makes sense when you need an exact file size.

Having encoded footage with almost every major software encoder over the last 15 years, i have to say that i have witnessed HUGE difference in quality (depending on type of footage) between single pass and multi pass encoding.

But this is besides the point of this thread. I am not looking for a mezzanine codec. I am trying to figure out why the H264 codec settings are not visible on the Windows version of Resolve.

In resolve for windows you do not have 2 pass encoding for h.264. Also audio in aac is limited to a maximum of 192kbit/s in resolve for windows.

Miltos Pilalitos wrote:

Cary Knoop wrote:For better h.264 encoding I would suggest exporting to a mezzanine codec and to use for instance x264.

By the way, contrary to popular belief multi-pass encoding is not any better than single-pass and only makes sense when you need an exact file size.

Having encoded footage with almost every major software encoder over the last 15 years, i have to say that i have witnessed HUGE difference in quality (depending on type of footage) between single pass and multi pass encoding.

But this is besides the point of this thread. I am not looking for a mezzanine codec. I am trying to figure out why the H264 codec settings are not visible on the Windows version of Resolve.

Have it your way, but if you look for quality I would not use H.264 implementation through Resolve.

Miltos Pilalitos wrote:

Cary Knoop wrote:For better h.264 encoding I would suggest exporting to a mezzanine codec and to use for instance x264.

By the way, contrary to popular belief multi-pass encoding is not any better than single-pass and only makes sense when you need an exact file size.

Having encoded footage with almost every major software encoder over the last 15 years, i have to say that i have witnessed HUGE difference in quality (depending on type of footage) between single pass and multi pass encoding.

But this is besides the point of this thread. I am not looking for a mezzanine codec. I am trying to figure out why the H264 codec settings are not visible on the Windows version of Resolve.

2 pass is only needed if you trying to achieve exact file size.
With good encoder like x264 1 pass CRF encode will give you 99.9% same quality as 2 pass encode with same final average bitrate (assuming same quality settings). This may not apply to crap encoders.
Instead of asking for 2 pass, use good encoder and you will be way better of (and without 2 pass)
Resolve h264 encoder is basic and this is unlikely to change. If you want good quality use 3rd party, anything x264 based (Handbrake, ffmpeg, Vdub2 etc).

Andrew Kolakowski wrote:Instead of asking for 2 pass, use good encoder and you will be way better of (and without 2 pass)
Resolve h264 encoder is basic and this is unlikely to change. If you want good quality use 3rd party, anything x264 based (Handbrake, ffmpeg, Vdub2 etc).

I have all of the software you mention and use them on occasion but i am not looking for a 3rd party solution in this thread.

All i am asking is why a setting that is described in the manual and is expected to be visible in the codec setup, is actually not where it is supposed to be on the Windows version of Resolve. Is it bug? Is it a "feature"? Is it just somehow forgotten during development?

There is no official response yet. This thread must be as invisible as the codec setting itself.

I guess the answer is that it *is* available with the Apple version but not the Linux/Windows versions due to the encoder software that is used on the respective platforms. They simply forgot to mention this in the manual?

Does the Studio version have a different (better) H.264 encoder vs Free ver??
Will either do H,265 10 bit/HDR ?
Thanks

The Studio version on a Mac does 10 bit H.265, but it seems 4:2:0 only.
Can't confirm HDR, since I don't have a display.

Hey,

Putting aside the fact that its obvious that Handbrake should be chosen even if Resolve had a 2 passes option in Resolve for Win (because I respect the OP), the 1st answer that popped up in my mind was also

RCModelReviews wrote:I guess the answer is that it *is* available with the Apple version but not the Linux/Windows versions due to the encoder software that is used on the respective platforms. They simply forgot to mention this in the manual?

To be confirmed, of course

Uli Plank wrote:The Studio version on a Mac does 10 bit H.265, but it seems 4:2:0 only.
Can't confirm HDR, since I don't have a display.

It will be 4:2:0. Just check with mediainfo.

Free version also does H265 on Mac, because this is what new OSX provides.
I don't think there is a difference between free and Studio when it comes to h264/h265 encoding (decoding is different in Studio). There is definitely nothing related to HDR metadata for h265. Resolve always sets h265 headers to Rec.709 and no mastering display etc info.

There might be differences to codec availability depending on various OS types/versions but when a codec is available, it makes no sense why its codec settings should be hidden/locked.

This is an issue not exhausted with the MultiPass encoding setting. The codec setting options in Resolve are really basic. I have run into issues with broadcasters who required specific encoding settings for deliverable masters and i have always hit a roadblock with Resolve. This is something that has been mentioned before by others in this forum. It is a topic that pops up from time to time since the Resolve 9 times but i can't remember a single time that someone from BMD gave an official answer to this.

Handbrake or other 3rd party solutions will not always be the ideal solution. There are many situations in which a number of long duration exports need to be rendered from a single project and having to add another workflow step just because the Deliver page is so lacking can be a real disappointment.

Miltos - "I have always hit a roadblock with Resolve."
They definitely need more codec support for camera formats and delivery even it it means higher cost.
Also Windows H.265 10 bit HDR which now supported by consumer TVs and predicted by many as the next broadcast standard.
We can all download x264 and x265 encoders. If codec licensing is an issue, Resolve only needs to support them as a user plugin and liability is transferred to us.
Inferior quality delivery formats for professional software is not a solution.

What about this simple solution:

In the system preferences

FFmpeg location: ["c:\my ffmpeg path"]

On the delivery page:

Use FFmpeg: [x]
FFmpeg parameters: [ -i %RESOLVE% -c:v libx265 -crf 15 -pix_fmt yuv420p result.mp4 ]
(just an example, any valid parameters can be given)

%RESOLVE% = is replaced with resolve output piped to ffmpeg

If there are potential legal implications then instead have an option where Resolve output goes uncompressed to a named pipe in a given format (for instance y4m). ffmpeg could read the pipe even from a different computer! Or have 10 pipes and render all-intra in parallel on 10 different machines!

The latter seems like a great idea. I'm sure there are legal implications for tighter integration, since ffmpeg has some features that seem to be tolerated for a non-commercial project, but are not 100% legal (like ProRes on Windows).

Cary Knoop wrote:What about this simple solution:

In the system preferences

FFmpeg location: ["c:\my ffmpeg path"]

On the delivery page:

Use FFmpeg: [x]
FFmpeg parameters: [ -i %RESOLVE% -c:v libx265 -crf 15 -pix_fmt yuv420p result.mp4 ]
(just an example, any valid parameters can be given)

%RESOLVE% = is replaced with resolve output piped to ffmpeg

If there are potential legal implications then instead have an option where Resolve output goes uncompressed to a named pipe in a given format (for instance y4m). ffmpeg could read the pipe even from a different computer! Or have 10 pipes and render all-intra in parallel on 10 different machines!

Resolve already uses ffmpeg: look for the libavcodec, libavformat and libavutil libraries in the Resolve application folder. Additionally, x264 offers commercial licensing options, and so does x265.

Yes, but processing is not patented etc, so you can use it.
Codecs' math is, so you can't use directly. Mentioned commercial licensing= money, which means someone has to pay for it. For free version of Resolve this is not an option as BM would bee loosing serious money on this. This is why they escaped from eg. DD licensing etc. using OS provided functionality.

When you pipe from Resolve to ffmpeg then there won't be any legal issue as far as I understand. There can be proper integration, but ffmpeg libraries/binaries can't be part of Resolve installer. They need to be downloaded by user.
This is how Tweak RV uses ffmpeg. The give you cut off version (with free codecs), which you can replace yourself with your own build to get "paid" codecs. No one can punish you just for an integration.

Andrew Kolakowski wrote:Mentioned commercial licensing= money, which means someone has to pay for it. For free version of Resolve this is not an option as BM would bee loosing serious money on this.

Sure, that's probably also why hardware accelerated h.264 decode on nvidia is limited to the full version. I wouldn't mind if x264/x265 output only were available in the full version of Resolve. It's easy enough to output a DPX seq or intermediate MOV and then pipe that into x264 manually, but for paying users it would be nice to have the integration in Resolve directly and save the disk space required for an intermediate render.

Most professional users would output a high-quality master anyway for several reasons.
Like:
– A client might come back and want a revision after a long time and he/she didn't pay you for storing the whole project.
– Or the next codec in fashion on the internet has changed from H.264 via H.265 to VP9 or anything new and you'd have to encode again.
– Or you need to burn in some subtitles.
– Or you need a scene for a demoreel.

And so on.

Uli Plank wrote:Most professional users would output a high-quality master anyway for several reasons.
Like:
– A client might come back and want a revision after a long time and he/she didn't pay you for storing the whole project.
– Or the next codec in fashion on the internet has changed from H.264 via H.265 to VP9 or anything new and you'd have to encode again.
– Or you need to burn in some subtitles.
– Or you need a scene for a demoreel.

And so on.

I hope it won't ever

I would love the ability to pipe output to ffmpeg via separate library, as is common in many softwares.

Sam Steti wrote: I hope it won't ever

I don't think it will anything but AV1 - at least I hope not

Micha Clazing wrote: It's easy enough to output a DPX seq or intermediate MOV and then pipe that into x264 manually, but for paying users it would be nice to have the integration in Resolve directly and save the disk space required for an intermediate render.

I couldn't agree more.

Resolve definitely needs more encoding options. The Deliver page is a kind of overlooked part in the whole Davinci Resolve grand design.

Uli Plank wrote:Most professional users would output a high-quality master anyway for several reasons.

It never ceases to amaze me how people on this forum, more than almost anywhere else, manage to drag in completely tangential arguments and present them as solid proof for an already far-fetched posit (see also: the many threads about external monitoring).

For me it really depends whether a grade renders above or below realtime. If it renders in realtime or above, I won't bother saving the intermediate render. If it renders (far) below realtime because of heavy effects, I'll pre-render an intermediate and save it for later use. I always save the entire project including all sources in original quality anyway, as I have unlimited backup storage and offer the possibility of going back to old projects for re-renders or modifications/revisions as a service to my clients.

Miltos Pilalitos wrote:

Micha Clazing wrote: It's easy enough to output a DPX seq or intermediate MOV and then pipe that into x264 manually, but for paying users it would be nice to have the integration in Resolve directly and save the disk space required for an intermediate render.

I couldn't agree more.

Resolve definitely needs more encoding options. The Deliver page is a kind of overlooked part in the whole Davinci Resolve grand design.

+1

Some sort of plugin architecture with an SDK package for the delivery page would be nice, even if just for the Studio version. 3rd parties could sell encoders or you could code your own. This would also provide an easy way to add a frame server. License fees would be pushed to the plugin provider.

Gary Hango wrote:Some sort of plugin architecture with an SDK package for the delivery page would be nice, even if just for the Studio version. 3rd parties could sell encoders or you could code your own. This would also provide an easy way to add a frame server. License fees would be pushed to the plugin provider.

This.

With the right hooks it really wouldn't be too hard for a third party plugin to provide integration with ffmpeg and solve 99% of people's codec problems in one fell swoop, without dragging BMD into legally murky waters.

I still don't understand why Resolve uses Quicktime only for Windows users. QT is now history in Windows and hardly ever used. If Wiki is correct it's also about the worst software encoder. What about VFW AVI/MP4? Professional software should offer professional results. Mainconcept is used in Hitfilm (free).

Resolve is not using QuickTime as an encoder, it only uses the file format. Like nearly everybody else they have replaced the outdated QT framework on the PC with their own routines.
BUT Resolve relies on OS functions for decoding or encoding of H.264/265, which have nothing to do with QT, but with hardware capabilities and the implementation in Windows.

Al Spaeth wrote:I still don't understand why Resolve uses Quicktime only for Windows users. QT is now history in Windows and hardly ever used. If Wiki is correct it's also about the worst software encoder. What about VFW AVI/MP4? Professional software should offer professional results. Mainconcept is used in Hitfilm (free).

Mainconcept provides SDK for many codecs, which you need to license from them. It's definitely not free.
If Hitfilm has enough purchases of paid versions they can provide some functionality in free version as well. It's business decision.

Thanks Uli - my mistake as H.264 render is called QT. MOV is not a useful delivery wrapper for me on a Win system. If they are using the Win encoder (whatever that may be), why not give us a VFW MP4/AVI option? Unfortunately AVC render quality remains a problem. Resolve is extremely powerful but it would be nice to have an end-to-end NLE. "Use Handbrake" is not a solution for camera formats and delivery quality - just an annoying work-around.

Thanks Andrew - From the Wiki comparison above it looks like a decent (better) encoder?

Staxrip works pretty good, it's fast and supports a lot of codecs.
Also 1,2 and 3 pass.

Al Spaeth wrote:
Thanks Andrew - From the Wiki comparison above it looks like a decent (better) encoder?

Mainconcept is ok. It's used a lot in many apps (cheap and expensive): Adobe, Vegas, Flame, Edius, Episode, Vantage and many, many more. Very popular SDK. For h264/5 both x264 and x265 are better though.

Al Spaeth wrote:MOV is not a useful delivery wrapper for me on a Win system.

Why, what is wrong with the mov wrapper?

Andrew Kolakowski wrote:both x264 and x265 are better though.

And free to use Why don't NLEs use them?

When you embed them into your NLE (so they are distributed inside installer) which you sell commercially then they are not free. You need commercial license which both have and was made specially for such a case. This is how it's done in Vantage, which uses x264 and x265.
If you provide an integration only in your NLE, but ask user to download binaries then they are "free" and all licensing requirements are passed to user, not NLE seller. This is how I understand it. Some tools use this approach.

Does that mean free NLEs can use them? Any idea what the paid license cost is compared to Mainconcept?
Just trying to understand why they pay for Mainconcept when x264/265 are better encoders?

I don't think fact software is free solves licensing issues.
Codecs are full of math and there are companies which own patents for specific bits of math. They simply want money for the fact that it's used and others make money on it- whenever it's on encoding, streaming etc. There are rules and bodies which look after this for them. It's like with music, photos etc. If I take a picture and you use it (without asking me) in eg. movie which later makes millions, I can sue you and get % of your earnings. Same with codecs- math inside is patented and it's difficult today to make a new codec which doesn't touch any of those patents. This is why google made VP9

They are probably similar cost. Mainconcept has been on market for long time, so companies use it as they know how to work with it, have code ready for integration etc.(guessing). In the same time because x264 is so well written some companies decided to integrate it (mainly due to clients demands). Telestream is one of such a companies for example. There may be some other bits into whole story, which "normal" people are not aware (until you pay lawyer to explain and check it).

Thanks - I got it. Any chance VP9 or another codec might replace AVC/HEVC. I never thought I would see the day when intermediate codecs like Cineform, DnX etc would be free but they are now.

Maybe, but h264 is integrated to so many devices (HEVC also now) that it's not easy. Other than this VP9 is painfully slow. VP9 now also have decent hardware decoding coverage.
Here is some blog about new codec:
https://streaminglearningcenter.com/cod ... g-vvc.html

there are some numbers there, but no VP9 stats.

AV1 (a-v-one) is going to be the next ‘big’ codec drop for open source users. It’s designed to be competitive to HEVC/H.265 and uses a liberal license. Might see 1.0 released this year.

Cheers,
Mike

Al Spaeth wrote:Does that mean free NLEs can use them?

yes -- but "free" has a lot of meanings. in case of x264/5 it also requires, that the source code is available and publishued under a compatible license...

Andrew Kolakowski wrote:Other than this VP9 is painfully slow.

that's not true! if you choose adequate multi-thread encoding options, it's just as fast as CPU based x265 encoding.

see: http://wiki.webmproject.org/ffmpeg/vp9-encoding-guide

MikeRochefort wrote:AV1 (a-v-one) is going to be the next ‘big’ codec drop for open source users. It’s designed to be competitive to HEVC/H.265 and uses a liberal license. Might see 1.0 released this year.

it is already released resp. the bitstream format finalized!

and concerning compression efficiency it's actually much better than h.265. it's simply one generation ahead. in this respect VP9 was a more equal counterpart of h.256. but even this codec has in practice a much better support in actual browsers than h.265 [except on apple products], because of all this stupid licensing issues.

AV1 is indeed really promising advance, but definitely it isn't usable right now in practice.
even the fastest existing AV1 encoder (rav1e) looks still incredible slow, and important parts (e.g. useful muxer support) are still missing -- but it's getting better every week!

what's really interesting about this actual AV1 development is also the fact, that it somehow coincides with other revolutionary changes in web software development. webassambly has opened possibilities, which where not available in the past. if you look at experiments like: https://developers.google.com/web/updat ... 8/wasm-av1 you can already get an impression, how wasm based decoding may solve platform specific incompatibilities in the near future. that's nothing radical new, because ogv.js already realized similar goals in the past, and was for example utilized to deliver all videos on wikipedia to those few devices (mainly apple crap), which don't support VP9 out of the box, but this new wasm/rust based solutions are a hell of a lot faster and more secure...

Cary Knoop wrote:what is wrong with the mov wrapper?

If one bit falls over in the file the whole thing becomes unreadable and almost unrecoverable. Much like the HFS file system, come to think of it.

Micha Clazing wrote:

Cary Knoop wrote:what is wrong with the mov wrapper?

If one bit falls over in the file the whole thing becomes unreadable and almost unrecoverable. Much like the HFS file system, come to think of it.

hmm -- i haven't stumbled over this kind of issue in practice until now...

but quicktime also saves a most of the important metainformation at the end of files, if not explicitly using e.g. the -faststart option, provide by some tools. this technical detail is much more often the cause of real world troubles and will hinder the reconstruction of truncated .mov files...

Martin Schitter wrote:
that's not true! if you choose adequate multi-thread encoding options, it's just as fast as CPU based x265 encoding.

see: http://wiki.webmproject.org/ffmpeg/vp9-encoding-guide

Not really. VP9 speed 4 (mid setting) is 2fps and x265 preset medium is 9fps on my machine (4 cores).
VP9 speed 8 (fastest one) is still only 3fps. x265 ultrafast is 26fps.
VP9 speed 1 is 1fps, x265 veryslow is 1.8fps.
VP9 seems to have small speed range, where with x265 you have quite big range.

Don't know how quality compares for given pairs, but hard to call it as fast. In both cases CPU is above 80% with x265 going closer to 100%

Micha Clazing wrote:

Cary Knoop wrote:what is wrong with the mov wrapper?

If one bit falls over in the file the whole thing becomes unreadable and almost unrecoverable. Much like the HFS file system, come to think of it.

I had few weeks ago corrupted ProRes MOV file where only 1 frame had issue, yet rest of the file was fine and readable.

Andrew Kolakowski wrote:Not really. VP9 speed 4 (mid setting) is 2fps and x265 preset medium is 9fps on my machine (4 cores).
VP9 speed 8 (fastest one) is still only 3fps. x265 ultrafast is 26fps.
VP9 speed 1 is 1fps, x265 veryslow is 1.8fps.
VP9 seems to have small speed range, where with x265 you have quite big range.
Don't know how quality compares for given pairs, but hard to call it as fast. In both cases CPU is above 80% with x265 going closer to 100%

on my debian linux desktop machine [using the default quality settings and just manually enabling 12 threads in case of vp9] on an arbitrary chosen file i get roughly:

x264 ~100fps
x265 ~50fps
vp9 ~25fps

but the default quality is much worse in case of x265!
if you try to archive similar quality, x256 will run much slower...

vgl. p10 and p19 in: http://www.compression.ru/video/codec_c ... coders.pdf

in practice, there isn't much difference, which one you take...

and btw. the system load an memory consumption in case of vp9 is significant lower!

Martin Schitter wrote:

Andrew Kolakowski wrote:Not really. VP9 speed 4 (mid setting) is 2fps and x265 preset medium is 9fps on my machine (4 cores).
VP9 speed 8 (fastest one) is still only 3fps. x265 ultrafast is 26fps.
VP9 speed 1 is 1fps, x265 veryslow is 1.8fps.
VP9 seems to have small speed range, where with x265 you have quite big range.
Don't know how quality compares for given pairs, but hard to call it as fast. In both cases CPU is above 80% with x265 going closer to 100%

on my debian linux desktop machine i get roughly [using the default quality setting and just manually enabling 12 threads in case of vp9] on an arbitrary chosen file:

x264 ~100fps
x265 ~50fps
vp9 ~25fps

but the default quality is much worse in case of x265!
if you try to archive similar quality, x256 will run much slower...
in practice, there isn't much difference, which one you take...

and btw. the system load an memory consumption in case of vp9 is significant lower!

Maybe things scale differently with more cores. I had threads set to 8. ffmpeg 4.02 and ProRes source.
x264 medium is 21fps. So x264/5 looks relatively like yours, but you seems to have some "special" VP9 version It can be very low bitrate (1Mbit) which x265 seems to be faster for.

Andrew Kolakowski wrote:... but you seems to have some "special" VP9 version

it's just the default debian package: libvpx5:amd64/buster 1.7.0-3 uptodate