Poor H264 encoding quality in DaVinci

It is good to see this thread get back on track. I feel like some things need to be said lest my previous comments be misinterpreted.

I am uncertain which h.264 encoder DR uses never having much interest, but if I were to hazard a guess, it is probably a version of MainConcept which is ubiquitous among NLEs. Now, I said up above that x264 was arguably better than these bundled versions of MainConcept which is important because the bundled versions tend to be lite or crippled versions of MainConcept's full version due to licensing costs. MainConcept writes a very good standalone h.264 encoder and any claims that x264 is better than MC's full version fall squarely in the opinion camp. It is also worth pointing out that while x264 is FOSS, the organization offers a licensed or commercial version that can be used as a plugin for NLEs like PP, thereby sidestepping the need for frameserving or a DI. I won't say much more about this other than that if you are encoding video for widespread distribution, you should research the licensing of all encoders including x264.

yes -- it's quite unplausibe, that a commercial software, like the mainconcept codec sdk, doesn't learn by watching other very well open source implementations. for developers it's like studying an open book. they don't have to copy it in a shameless manner, but they are able to study some aspects in this other software, to learn from and optimize their own code.

i think, BMDs decision, to choose the windows operating system libraries for mpeg encoding, isn't just motivated by technical reasons or carelessness concerning image quality. it's more a consequence of legal constraints. if you just offer software, which only uses some still existing operating system infrastructure or media framework (like in the case of the old quicktime solution), it's usually not seen as a separate product, that falls under the terms of patent exploitation rights and charges. sure -- that's a highly controversial interpretation of the current legal situation in some parts of the world, but it's more or less the answer, why software manufactures handle it like this.

The only caveat is using x264 (gui or cli) adds an additional step to one's workflow

There's the crux of it, and why Resolve needs a better encoder with MP4 (and M4V) capabilities.

if you are planning to use a third-party encoder, what format should you export? I have settled on image sequences, but I am curious what others say.

As I prefer the MeGUI front end for x264, I export Cineform AVI files for encoding.

all the internal computations of modern video aspplications is done in the RGB domain nowadays.

That's not entirely true. It's very possible to start, edit and export YUV media in PP without converting to RGB at any point in the process.

i think, BMDs decision, to choose the windows operating system libraries for mpeg encoding

I guess that answers the question of which h.264 encoder is in DR and makes sense. Honestly, I would not expect BMD to offer anything above and beyond this. IMHO, the only possible solution is that BMD exposes the export tab for developers to write their own plugins like the x264 plugin for PP. Then those that can't live with a DI step in their workflow will have options. Because honestly, what other solution is there? Do we really think BMD is going to put a gold standard h.264 encoder in DR? Just put something in there, so it is not glaringly obvious that one is missing. Those who know better will find a workaround.

i think, BMDs decision, to choose the windows operating system libraries for mpeg encoding

I guess that answers the question of which h.264 encoder is in DR and makes sense. Honestly, I would not expect BMD to offer anything above and beyond this. IMHO, the only possible solution is that BMD exposes the export tab for developers to write their own plugins like the x264 plugin for PP. Then those that can't live with a DI step in their workflow will have options. Because honestly, what other solution is there? Do we really think BMD is going to put a gold standard h.264 encoder in DR? Just put something in there, so it is not glaringly obvious that one is missing. Those who know better will find a workaround.

BMD has opened Davinci Resolve for linux. Why despair? If he wants it, yes, he can. And i hope.
If you want to post + 22,000 messages so that it works in the long run we will get there ...

if you are planning to use a third-party encoder, what format should you export? I have settled on image sequences, but I am curious what others say.

As I prefer the MeGUI front end for x264, I export Cineform AVI files for encoding.

I have never been 100% sold on Cineform's wavelet based compression which, while offering considerable promise, is probably about a decade behind the development of DCT based methods. But interesting choice nonetheless and thanks for sharing.

"Poor H264 encoding quality in DaVinci" is a statement that as far as I can see has yet to be substantiated yet most here just agree and start criticizing Resolve's decoder and advocating 3rd party software.

Surely we need more info like some meaningful quality comparisons to direct AVC export from other NLE software at the same resolution, bitrate, color depth etc.
Next we need to find out what encoder Resolve uses before we can criticize. Do we know what decoders other NLEs use?
Last, we need to make sure it's exporting out h.264 AVC level 5.1/5.2. There have been 22 versions of the H.264/AVC standard since 2003 - but I'm sure BMD know that.

I'm still not convinced - but I am convinced that if BMD want Resolve to compete with products like Adobe PPro cc, they need to add more export (delivery) formats including mp4. h.264 Quicktime should not be the only option. We should not have to use 3rd party software to create compatible camera import media or the delivery formats we need including h.265.

I think there are two things to know:
- leave the choice of the encoder and there is our responsibility,
For example the Human-Machine Interface (HMI) proposed by Sorenson Squeeze (which is a very good encoder) for X264

x264_sorenson squeeze.jpg

- the most frustrating: use the encoders proposed by Davinci Resolve but there, at least (for all codec), should propose the HMI that goes with it. Keep the default settings or use the HMI.

hqx.jpg

Surely we need more info like some meaningful quality comparisons to direct AVC export from other NLE software at the same resolution, bitrate, color depth etc.

it's quite easy to do some objective quality measurements (PSNR, SSIM...) yourself. it also was described here in the forum in some similar threads.

concerning the GUI/HMI question, i would add, that resolve only allows you to specify the compression ratio by a traditional [maximum] bandwidth entry. that's not always the best method. content depending variable bandwidth encoding is better controlled by image quality related specifications (eg. CRF in ffmpeg)

Last, we need to make sure it's exporting out h.264 AVC level 5.1/5.2. There have been 22 versions of the H.264/AVC standard since 2003 - but I'm sure BMD know that.

I'm still not convinced - but I am convinced that if BMD want Resolve to compete with products like Adobe PPro cc, they need to add more export (delivery) formats including mp4. h.264 Quicktime should not be the only option. We should not have to use 3rd party software to create compatible camera import media or the delivery formats we need including h.265.

Levels and standards have not much to do with it. If you are exporting e.g. HD you at 30Mbit and set level e.g. to 5.1 it won't make any difference compared to level 4.1 from the same encoder. Levels control maximum bitrate/resolution (+ some other bits), but won't help if encoder is poor You actually don't want level 5.1 as many hardware decoders support only up to e.g. 4.1. Such a file will be only problematic, not any better.

Yes, when Resolve was a grading tools export options were half important as you could say that image sequences+ intermediate codecs are enough. Now Resolve claims to be best NLE out there, so export options are very important and they are no near good enough for such a claim

Mainconcept engine is not that bad (still not that good as x264 or ATEME), but you have to use latest version and have license to all features (and if you don't expose parameters set them well internally).

Last, we need to make sure it's exporting out h.264 AVC level 5.1/5.2. There have been 22 versions of the H.264/AVC standard since 2003 - but I'm sure BMD know that.

I'm still not convinced - but I am convinced that if BMD want Resolve to compete with products like Adobe PPro cc, they need to add more export (delivery) formats including mp4. h.264 Quicktime should not be the only option. We should not have to use 3rd party software to create compatible camera import media or the delivery formats we need including h.265.

Levels and standards have not much to do with it. If you are exporting e.g. HD you at 30Mbit and set level e.g. to 5.1 it won't make any difference compared to level 4.1 from the same encoder. Levels control maximum bitrate/resolution (+ some other bits), but won't help if encoder is poor You actually don't want level 5.1 as many hardware decoders support only up to e.g. 4.1. Such a feel will be only problematic, not any better.

Yes, when Resolve was a grading tools export options were half important as you could say that image sequences+ intermediate codecs are enough. Now Resolve claims to be best NLE out there, so export options are very important and they are no near good enough for such a claim

Mainconcept engine is not that bad (still not that good as x264 or ATEME), but you have to use latest version and have license to all features (and if you don't expose parameters set them well internally).

Hi Andrew,
Good points - thanks.
I agree - they have created a great NLE, but the workflow looks more like a studio grading tool than a end-to-end turnkey NLE solution. Have a look at the import/export formats supported in GV Edius.
Why don't we just ask BMD how they encode/decode h.264? Resolve was designed for end-to-end pro quality.
What does Adobe use??
Why can't Resolve use x264 - it's free??
Regarding hardware decoding - I wouldn't be surprised to see them add h.264/265 hardware acceleration encoding using latest Intel Graphics. Kaby Lake cpu has on board full hardware acceleration for encode and decode of 4K HEVC Main10 profile videos. (4:2:0)
http://www.anandtech.com/show/10959/intel-launches-7th-generation-kaby-lake-i7-7700k-i5-7600k-i3-7350k/6

i think, the way, how autodesk outsourced all the media handling in flame to mediareactor from drastic technologies, is a much more convincing practical example [even though it also looks quite limited concerning h.264/265 handling in particular].

Hi Andrew,
Good points - thanks.
I agree - they have created a great NLE, but the workflow looks more like a studio grading tool than a end-to-end turnkey NLE solution. Have a look at the import/export formats supported in GV Edius.
Why don't we just ask BMD how they encode/decode h.264? Resolve was designed for end-to-end pro quality.
What does Adobe use??
Why can't Resolve use x264 - it's free??
Regarding hardware decoding - I wouldn't be surprised to see them add h.264/265 hardware acceleration encoding using latest Intel Graphics. Kaby Lake cpu has on board full hardware acceleration for encode and decode of 4K HEVC Main10 profile videos. (4:2:0)
http://www.anandtech.com/show/10959/intel-launches-7th-generation-kaby-lake-i7-7700k-i5-7600k-i3-7350k/6

Most codecs in Adobe are based on Mainconcept, including h264.
x264 for Resolve would not be free- BM would have to license x264 for pro usage (there is special version of x264 for this). It's bit different if you use x264 as private person and if you want to include it in some professional product. Telestream uses licensed x264.
Mainconcept is not that bad, but you have to license all options (I think there are different licensing levels) and tweak your presets correctly. It's still not as good as x264.

Hardware encoding (specially Intel) is getting better and better.

Edius codec handling is quite good and whole code is very polished (processing is YUV based and crazy fast).

i think, the way, how autodesk outsourced all the media handling in flame to mediareactor from drastic technologies, is a much more convincing practical example [even though it also looks quite limited concerning h.264/265 handling in particular].

Mediareactor provides small part of codecs handling in Flame (just few more fancy formats). Flame is also mainly Mainconcept based+ SDKs from each camera manufacturer+ AVIDs DNxHD/R+Apple licensed ProRes+Sony XAVC libraries etc. Flame actually supports piping, but it's bit hidden Flame also includes ffmpeg libraries.
Mediareactor is also in Scratch.
Small note about quality of pro tools- Flame just now in ver 2018 enabled 32bit float processing (and proper EXR support) It was/still is based on such a old engine.

As I prefer the MeGUI front end for x264, I export Cineform AVI files for encoding.

I too take this approach. In my own quality metric tests, using a variety of 1080p HD-AVC mp4/mov clips for input, I found that Cineform avi exported at 'High' quality (i.e. Film Scan 1) gave consistently higher PSNR and SSIM scores than 8 or 10-bit DNxHD.mov exports at the respective bitrate for the source frame rate. That also took into account round trip conversion back to 8-bit YV12 (via AVISynth) in order to perform the quality metric tests with the native HD-AVC clip as the reference. For 10-bit DNxHD, that requires a special build of the AVISynth ffms2 (FFmpegSource) plugin and likewise to feed YV12 to MeGUI for x264 encoding. Whereas, Cineform only needs the vfw codec from GoPro Studio to be installed.

Of course the same can be accomplished with ffmpeg and libx264, now that ffmpeg has Cineform decode support; I just find it easier to use custom x264 encode profiles set up in MeGUI.

What disappoints me a little is that Resolve 12.5, does not extend support to other third-party vfw codecs, including efficient lossless formats like UTVideo and MagicYUV, both of which support 10-bit encoding. Is this something that will ever be considered? IMHO Resolve suffers for want of a viable lossless export option.

I have never been 100% sold on Cineform's wavelet based compression

What I prefer about Cineform is the use of Constant Quality encoding. So if a frame only needs 10 bits, it won't be stuck at 20 and thus pad the file. If a frame needs 30, it won't be stuck at 20 and thus reduce quality.

Cineform is the only mezzanine codec I've found on Windows (besides lossless) that offers this option.

Doing some pixel peeping at 400%, I'm quite satisfied with level 4 encoding for Masters.

Mediareactor provides small part of codecs handling in Flame (just few more fancy formats). ... Flame actually supports piping, but it's bit hidden

no, it's far beyond simple piped processing using frameserver hacks -- that wouldn't preserve metadata etc. --, but flames internal architecture is quite unique in many ways.

outsourcing the related development efforts to a foreign company was a very remarkable and controversially debated topic. of course, autodesk did it, to archive first and foremost powerful features for high end purposes (raw format debayering on the GPU, etc.), not just better/cheap support for typical amateur footage and youtube delivery...

Will Harris explains the motivations behind this drastic change in an interview at 5:46-7:25:

and here you'll see, how it fits into the whole application and GUI:

Just found out Hitfilm also uses Mainconcept.
Now we need to fund out what Resolve uses.

Jim - I agree, Cineform is is an excellent codec and I would like to see it added to the transcoding options for Optimized Media in Resolve.
The only truly lossless (and fastest) intermediate is called Magic YUV https://www.magicyuv.com/. It works in most NLEs that support VFW - but not in Resolve. I've used it as an intermediate for h.264 4k mp4 on a low end i5 for realtime edit with a high quality preview. It's excellent but file sizes are large.

Andrew - "BM would have to license x264 for pro usage"
I didn't read the fine print. Not sure if it's possible, but given that x264 is the best encoder, it would be nice if Resolve could add it as a user downloaded "plugin" so that we non-pros could download and use the free version in Resolve. Pro licensing would be left to the users and no a BMD responsibility. It would also add h.265 and BluRay format support.
Handbrake uses "Video Encoders: H.265 (x265 and QuickSync), H.264(x264 and QuickSync), H.265 MPEG-4 and MPEG-2, VP8, VP9 and Theora". If pro resolve users produce h.264 using Handbrake (free), (which uses x264) what happens to the license fees?

Al

Mediareactor provides small part of codecs handling in Flame (just few more fancy formats). ... Flame actually supports piping, but it's bit hidden

no, it's far beyond simple piped processing using frameserver hacks -- that wouldn't preserve metadata etc. --, but flames internal architecture is quite unique in many ways.

outsourcing the related development efforts to a foreign company was a very remarkable and controversially debated topic. of course, autodesk did it, to archive first and foremost powerful features for high end purposes (raw format debayering on the GPU, etc.), not just better/cheap support for typical amateur footage and youtube delivery...

Will Harris explains the motivations behind this drastic change in an interview at 5:46-7:25:

and here you'll see, how it fits into the whole application and GUI:

Don't see anything special there. It's just a import plugin (maediarecator can be also on export side).
It does handle only some codecs- at least only some codecs has been tested and verified by Autodesk. It supports many formats, but it's not optimised for speed. Autodesk needed it for formats like DNG (where there is no good SDK provided)- other cameras Sony, RED, Arri, etc are handled through manufacturers SDKs.

This has not much to do with fact that Flame only just got proper support for EXR and 32bit float processing- quite unimpressive for software which costs as much as house There has been a lot of changes from 2015 as Autodesk has been pushed by many key users.

Mediareactor has been on the market for quite a while and drastic is a small company- I know them quite well.
Scratch also has it integrated, but they seams to slowly move away from it- I think because code is not very fast.

I'm talking about actual piping in Flame (not its internal engine and whole network with backburner etc). You can pipe to eg. ffmpeg.
Flame has many unique features (specially to work between many Flame systems), but in the same time engine was/is old. There was also need to make it more open, so that's why you have Python hooks now. Autodesk has hard time to try to keep is so crazy expensive as they can't offer that much more compared to other systems. In many areas they are actually behind others. Fact that you see Mac version and now ability to rent Flame is big move for Autodesk and this been discussed a lot as not everyone is happy about these new possibilities to own Flame.

Handbrake uses "Video Encoders: H.265 (x265 and QuickSync), H.264(x264 and QuickSync), H.265 MPEG-4 and MPEG-2, VP8, VP9 and Theora". If pro resolve users produce h.264 using Handbrake (free), (which uses x264) what happens to the license fees?

Al

I'm not that good with this licensing needs- when you do it yourself it's different.
Try googling it:

https://www.engadget.com/2010/05/04/kno ... g-and-you/
http://www.zdnet.com/article/a-closer-l ... -licenses/

Handbrake uses "Video Encoders: H.265 (x265 and QuickSync), H.264(x264 and QuickSync), H.265 MPEG-4 and MPEG-2, VP8, VP9 and Theora". If pro resolve users produce h.264 using Handbrake (free), (which uses x264) what happens to the license fees?

Al

I'm not that good with this licensing needs- when you do it yourself it's different.
Try googling it:

Without getting into legal issues - If Handbrake leaves it to the end user, why shouldn't Resolve? Adobe added Cineform support but it's up to the end user to get it from GoPro - remember software has "end user" licenses.

Handbrake is free, but I don't really know exactly how to explain it. If it would not be needed than Telestream or other companies (Sorenson, PEGASYS) would not needed any special agreements for x264.

Adobe has licensed Cineform as far as I understand and provides native support- you don't need to install or obtain anything additional anymore.
Cineform engine itself has such a ability that you integrate it to your software, but license can be provided separately (on a system level). This is how Resolve has it integrated. Problem is that Cineform has changed and gives more for free, but Resolve integration on Mac seams to be not fully aware of it.

I'm not that good with this licensing needs- when you do it yourself it's different.

you are right, this licensing/royalty issues are the real problem! realizing better mpeg support isn't so much a technical question, but more a challenge for the legal department of companies. in this respect, it doesn't make much difference, which particular SDK/libraries you choose. only the few operating system component based solutions may offer some advantages in this respect. and even there, i would see it more as a kind of quite questionable pragmatic protection by big players and their extensive patent/stock portfolios, than a principle solution.

sure -- h.264 has become a very important codec. we may see some really good open and royalty free alternatives (eg. AOMs AV1) in near future, but h.264 and its hardware based implementations in actual cameras will go along with us for quite a while.

from a technical point of view, utilizing x264 would have some advantages. the resulting image quality of encoding would indeed look better, but x246 also has it's flaws. i don't have to tell you about all the troubles related to its 8bit heritage and the bad support for any scenarios deviating from typical media player and streaming file format converters. more optimized random access to frames and decoding for backward playing, as needed by NLEs and suchlike, is just as bad supported in this free alternative as in most other commercially available solutions.

concerning my references to autodesk flame, i think, you didn't get my point. it's not just stupid namedropping, when i mention this software. autodesks remarkable decision, to outsource codec support to third party suppliers, is only one reason, why i pointed to it. it's a very interesting example in some other respects, too. eventrough i agree with you, that it looks quite ancient in may ways. nevertheless it's also a very impressive source of stimuli, revealing, how things can by done in an uncommon fashion. in contrast to davinci resolve there are extensive technical documentations available for the flame family products, which let you grasp a lot of insight concerning its internal structure and APIs. if your interested in media software development, this is an incredible treasure of clues. in some respects it often feels like studding historic documents. e.g. the StoneFS layer, i.e. the internal frame store representation -- yes, on a first sight, it looks like a remnant of the stone age. you may ask yourself: does it really make any sense, to handle things like that, nowadays, where storage devices have become much faster and efficient? but after a while submerging into this strange sphere, it also opens the mind for quite uncommon new kinds of solution for actual challenges in software development...

i dimly remember some software using FUSE to translate image sequences and video files somehow invisible to the user and his preferred software in the background. sure, this isn't the most efficient and high performance solution to this task, but it's an interesting alternative, which can be realized quite easy on linux and mac os. it doesn't need any modifications of existing end user software and also solves the necessary process division between free and closed source software as required by the GPL. i think, this could seen as one of the most promising approaches, to realize your suggestions. in fact, it wouldn't be just an improvement for resolve users. it would open the same new capabilities to a lot of other commercial products, which show similar compromises concerning h.264 handling, just as well.

Yes, companies have hard time to please customers who demand more and more. That's why they started focusing on things which they do the best and use 3rd party for other parts of their software. It's not bad approach at all if you know and trust your 3rd party supplier.

I know Flame internals a bit- worked for a company which has probably the biggest Flames installation in Europe (25+ systems). Done quite cool things around it.

We're far from main topic now.

The only truly lossless intermediate is called Magic YUV

UT is also a mathematically lossless VFW codec which works fine in Adobe software, but frustratingly, not in Resolve. I use it frequently, along with Cineform.

http://www.videohelp.com/software/Ut-Video-Codec-Suite

Adobe added Cineform support but it's up to the end user to get it from GoPro.

That is not correct. Premiere Pro can read and write Cineform files without any additional installation from GoPro. In fact, installing GoPro software has actually interfered with the proper operation of Cineform in Premiere Pro. Users in the Adobe forums report Cineform working properly once they uninstalled the Cineform software.

The only truly lossless intermediate is called Magic YUV

UT is also a mathematically lossless VFW codec which works fine in Adobe software, but frustratingly, not in Resolve. I use it frequently, along with Cineform.

http://www.videohelp.com/software/Ut-Video-Codec-Suite

There are few lossless codecs out there, UTvideo, MagicYUV and ffmpeg's ffvhuff, ffv1 are probably most capable (with 10, 12, or even 16bit support). MagicUYV is quite new (done by Hungarian guy), the fastest and also has nice set of pixel formats supported (including capture cards friendly v210, R210 and r10K).
There were some attempts to add MagicYUV as native Adobe codec, but so far they failed. Non-native support is bit problematic and prone to issue/performance loss. I think Adobe is quite happy with Cineform+DNxHR.

Resolve supports only what BM adds, there is no support for QT system codecs (or VFW, diretchsow).

We are out of topic again.

Given the YUV - RGB - YUV processing, I've found that avoiding 'round tripping' completely is a good solution. I shoot native ProRes HQ so I always cut in my NLE and Export only an EDL/XML to Finish in Resolve, finally Mastering out to a DPX Export.

I transcode the DPX Master to any and all Deliverables using a well implemented ffmpeg based solution. This workflow has proved ideal for many years.

Just watch your RGB to YUV conversion in ffmpeg as it's quite bad with it. Some routes are not very precise. DPX to YUV is one of them as then conversion is done from gbrp10le pixel format to YUV. This is less precise than converting gbrp10le into RGB48 and than going to YUV. Looks like there are some "shortcuts" in ffmpeg maths (bit shifting) when starting pixel format is gbrp10le.
Even latest ffmpeg has this problem and previous versions had way bigger problems (red or green tint).
I would rather use zscale filter, which provides very accurate conversion (more accurate than Resolve or AE).

Handbrake is free, but I don't really know exactly how to explain it. If it would not be needed than Telestream or other companies (Sorenson, PEGASYS) would not needed any special agreements for x264.

Adobe has licensed Cineform as far as I understand and provides native support- you don't need to install or obtain anything additional anymore.
Cineform engine itself has such a ability that you integrate it to your software, but license can be provided separately (on a system level). This is how Resolve has it integrated. Problem is that Cineform has changed and gives more for free, but Resolve integration on Mac seams to be not fully aware of it.

My understanding (may be wrong) in correspondence with Jake Seagrave from Cineform is that Adobe added Cineform Support but the codec license rested with the end user as Cineform is free to use and comes with GoPro Studio download. Jake worked with Adobe to add Cineform Support.
Here is a Cineform DIY for Adobe from Jake
https://cineform.zendesk.com/hc/en-us/articles/206527836-A-Do-It-Yourself-Guide-to-adding-CineForm-support-in-Adobe-CC-Windows-.
Not sure if it's relevant to how Resolve has implemented Cineform.
Also a link from Adobe re The GoPro Cineform codec
https://helpx.adobe.com/premiere-pro/using/gopro-cineform-codec.html
I haven't used Adobe for many years, but originally users had to download the Avid and Cineform codecs separately. Cineform may come with Adobe now, but I believe users still need to download GoPro Cineform for playback in other apps.

My point was that adding support for something does not require licensing if the end user is responsible for obtaining it - similar to plugins. x264 needs a GUI like Handbrake to use it but can be downloaded for free on it's own. Surely Resolve could do something similar if there was sufficient user demand??

You don't need to do anything in Adobe anymore. Cineform works straight away regardless if you had Cineform product installed or clean system. It's a proper native support.

I think it's much more complicated than just leaving it to end user to get license. BM as company can't use free version I think. If you write a x264 Resolve plugin and give it for free than maybe this will work.

I think it's much more complicated than just leaving it to end user to get license. BM as company can't use free version I think. If you write a x264 Resolve plugin and give it for free than maybe this will work.

you are right -- it's not that easy!

first of all, you can not use the common GPL licensed version of x264 in closed sorce software. it doesn't make any difference, if the affected software is available for free or an expensive product. it only matters, that its souce code is accessible under a GPL compatible license (but be warned: even an open source plugin for a closed source application would violate the GPL!).

sure -- since 2010 x264 is also available under a second commercial license for use in closed source products. but in this case you'll have to pay some licensing fee depending on the number sold units (~$1 per sold unit was given as a rough orientation in the first announcement)

this commercial licensing concerns only the use of the actual implementation. it doesn't include the royalties for patent protected technologies charged by MPEG-LA (as described in the mentioned announcement from 2010: "MPEG-LA's fees are zero for the first 100,000 units, 20 cents per unit until 5 million, and 10 cents beyond that, capping at around $5m per year.")

i think, the MPEG-LA related fees got significant reduced over time and the fight about exploitation rights are increasingly shifting from h.264 towards h.265, but it's still a can of worms.

Martin -
How can they possibly control it? MpegLA offers licensing for h.264 AVC codec which is offered in every NLE I can think of including GoPro Studio (free). It is the most popular capture and delivery codec for consumer cameras etc and used by YouTube, Vimeo, TVs, media players etc. etc. Do they all pay license fees? Doubtful.
We already have h.264 codec support for import and export in Resolve so I assume the codec is not the problem.
x264 on the other hand is a method of software encoding which produces h.264 AVC output. Do they pay license fees to use h.264 to MpegLA for their free product??

VideoLAN website states
"Trademarks
VideoLAN, VLC, VLC media player and x264 are trademarks owned by VideoLAN.
The full usage is detailed under, in the French section, but you should know that those trademarks will not block any normal use and redistribution of the open source software from VideoLAN."
"Patents and codec licenses
Neither French law nor European conventions recognize software as patentable (see French section below). Therefore, software patents licenses do not apply on VideoLAN software."

Maybe we should just ask BMD for x264/265 and let them decide.

Yes, Netlifx, Youtube, camera manufactures etc (whoever uses h264 in big numbers) have to pay licenses for h264 usage and this is exactly the reason why google (and others) is working on VP9 (other codecs) which meant to be free of any royalties. Problem is that there are so many patents granted related to encoding that it's actually very difficult to make sure you don't use any technology which is patented.
It's way more complicated than you may assume.

Martin - ...

that's a whole bunch of questions, but i'll try to answer a view aspects...

How can they possibly control it? MpegLA offers licensing for h.264 AVC codec which is offered in every NLE I can think of[...] It is the most popular capture and delivery codec for consumer cameras etc and used by YouTube, Vimeo, TVs, media players etc. etc. Do they all pay license fees? Doubtful.

yes, i think, they all pay huge amounts of licensing fees! -- especially the big ones.

what's quite unique about MPEG LA is it's role as a sole central licensing authority representing the interests of a very extensive group of patent holders. but in fact even in the case of AVC there are still some additional patent holders outside of the pool, which could claim even further royalties.

even members represented by MPEG LA have to pay their fees. for example: Microsoft pays into MPEG-LA about twice as much as it receives back for rights to H.264. this charges also affect major open source products just the same as commercial products. this was one of the main reasons, why firefox/mozilla didn't support h.264 for quite a long time. they would otherwise have been forced to pay the full $5m bill. this issue was finally solved, when MPEG LA declared some drastic suspension of charge for some period of time and extended the royalty free policy for free internet content. it was just the same stupid game we now see around HEVC again.

We already have h.264 codec support for import and export in Resolve so I assume the codec is not the problem.

in an ideal and just world, it shouldn't make any difference, which actual implementation is used for h.264 en-/decoding. you would simply have to pay the same amounts to MPEG LA. but as mentioned in a previous post, i'm in doubt, that it runs like this in our real world.

Neither French law nor European conventions recognize software as patentable (see French section below). Therefore, software patents licenses do not apply on VideoLAN software.

that's indeed a very important detail! the patent claims involved in MPEG licensing are not valid all over the world. especially the legal situation in France looks quite different to many other countries. that's why it became the mecca of free video software and codec development. most important open source video projects have their home base there. but that's no solution for a global player like BMD.

I know BBC paid big M$, so they can use x264 (ffmbc) and in the same time keep MPEG LA happy (probably because BBC iPlayer delivery uses h264)

Just watch your RGB to YUV conversion in ffmpeg as it's quite bad with it.

I agree with Craig. Are you completely satisfied with DR's RGB to YUV conversion for every input and output? I don't have the time to vet every single pathway in and out of DR. So I settle on a workflow that works and functions in an agnostic manner. Please post an example of ffmpeg's badness.

Try yourself. Generate bars (it can be any image actually) in e.g. Premiere and export as DPX. Convert this in Resolve, Adobe and ffmpeg to e.g. v210.
Bring all to AE (in 16 or 32bit mode) and check values with color picker: original DPX v v210. Then convert with ffmpeg using zscale. You don't even need color picker- if you look closely you will see difference by naked eye for standard ffmpeg DPX to YUV conversion (-vf scale). This should not happen at all as both formats are 10bit.

Resolve converts everything into RGB, so there is only 1 math to convert it back to YUV (bugs are possible on import stage).
ffmpeg does not normalise input files, so this is why there are many paths for RGB<->YUV conversion and some of them are not very accurate (its enough to use intermediate RGB48 pixel format to get better result). It's way better than it use to be even year ago. There was a lot of inaccuracy- you had green or red tint (also when going to 8bit YUV formats). Most apps produce files which at least in AE show +-few levels (around 3 levels in 10bit scale). ffmpeg produces up to 10 levels difference (at least this is max what I have seen). This is to much as it's visible to the eye.

zscale produces most accurate results- well, filter is well designed, was debugged on doom9, before it got into ffmpeg. Quite interesting that it's more accurate than AE and Resolve (both working in 32bit float). zscale also uses 32bit float math, at least one in avisynth and vs, so I assume in ffmpeg also.

If you trust ffmpeg that's your decision, just don't try to convince me about its accuracy Even if I use it a lot I don't use it for some things because it's far from being perfect.

I don't use Resolve almost at all for my work, but DPX to v210 is okish.
Interesting that Resolve did produce +-1 level error even when going to 10bit RGB format (which except packing structure is identical to DPX), but zscale produced perfect result without any error. Is Resolve 32bit float engine that accurate ?
Going from DPX back to DPX produced perfect result in Resolve, so at least this is good.

ffmpeg does not normalise input files, so this is why there are many paths for RGB<->YUV conversion and some of them are not very accurate.

if you are really picky about this subtleties, you should perhaps use natron in batch mode for conversion. it's a hell of a lot slower, but it combines richness of ffmpegs file format support with the accuracy of OpenColorIO based colorspace transformations.

but i personally do not see much practical need for such a circuitous route.

If I see difference by eye (and it shouldn't be visible) than it's definitely not good enough. I don't need to use anything super fancy, just a software which does it properly (well, even ffmpeg itself but not with scale filter). Most apps are actually good enough, it's just ffmpeg which is poor for this task. There is really no need to try to make it more dramatic or complicated- it's simple bug (or maybe deliberate shortcut) in math inside ffmpeg.
I don't see a reason to have it done inaccurately if I'm aware of it and solution is actually very simple.

We use Wayne Norton's Convert v4.0 for most of our transcoding requirements and although it mostly uses ffmpeg, there are some instances of ffmbc in there (as well as other 'engines' too) but on our calibrated 10bit SDI 4K grading monitor, (gamma 2.4) DPX to h.264 conversions looks pretty good. If we compare our compressed HD Youtube uploads on our properly setup 55" Sony 9000 series 4K TV with other YT streams, we're generally happy with the results.

Looking good and being accurate is a little different story.

Hi,
Just a question: what is the quality of the Sony MPEG4 encoder for the H264?

Sony MPEG4 is not a h264 replacement. It's an intermediate codec, the same what you have on SR tapes. It's on the ProRes, DNxHR level. 450Mbit (422) mode is very high quality, 225Mbit around ProRes HQ.

Sony MPEG4 is not a h264 replacement. It's an intermediate codec, the same what you have on SR tapes. It's on the ProRes, DNxHR level. 450Mbit (422) mode is very high quality, 225Mbit around ProRes HQ.

sorry, but i have to disagree. sonys XAVC is in fact just another all-intra AVC/h.264 variant!
h.264 is often misunderstood as long-GOP delivery codec only. but that's only one possible manifestation. it can be used as very capable intermediate format as well. HEVC/h.265 and it's marvelous image compession -- as also used in BPG -- is even better in this respect.
what's really special about sonys actual implementation, is their very well working hardware acceleration. CABAC, the lossless arithmetic compression used in some h.264 profiles, is a very computing intensive task. it's quite demanding, if you want to use it in realtime on high quality data streams. sonys professional solutions handle this very well. but you can archive even better image quality by using ffmpeg/x264 lossless mode (-qp:v 0 -profile:v high444 -intra). you just have to be aware, that this kind of profile isn't supported by most commercial h.264 implementations resp. applications.

Please read the name- Sony MPEG4, which is Sony's SR codec used on SR tapes. We are not talking about XAVC. Totally different thing.

Please read the name- Sony MPEG4, which is Sony's SR codec used on SR tapes. We are not talking about XAVC. Totally different thing.

perhaps it's just a lack of understanding on my side, but i didn't interpret Jean Claudes question as strict related to sonys SR codecs or other h.264 predecessors.

Try yourself.

Like I said, I don't have time to vet every single codec under the sun. It does not surprise me in the least that there are some codecs that have issues with one program or another. That is why I said, find the one that works, then move one. I vetted all my round trips, and they are perfectly lossless to the nth generation in DR, Nuke, PP, AE, ffmpeg, etc. Of course, final delivery for distribution is not lossless, but I have vetted that there are no color shifts and the artifacts in test images are as expected. No need for color pickers or naked eye comparisons, this is using proper scopes. This is basic blocking and tackling imho. If you haven't vetted your pipelines with test images, you are flying blind, but more importantly the round trips I do for vfx would fail hard. So I can guarantee there are no lurking problems behind the scenes. And when I deviate from my vetted workflow, I know exactly what sort of issues I am introducing into my footage. Like Craig, sometimes I am ok with that. Knowledge is power.