Poor H264 encoding quality in DaVinci

I'm getting poor quality renders from DaVinci when using H264 encoding. It loses sharpness and introduces washed out areas in places of an image image where details are more subtle. This happens no matter what settings I've tried (ran MANY tests). If I use MPEG4 encoder result is much sharper, staying more true to original source footage. If I later re-encode that MPEG4 clip into H264 using Adobe Media Encoder or other tools the result is sharp and not washed out meaning it's a problem with encoding in DaVinci.

As far as I remember it's always been this way. Anyone else having same experience? Is Blackmagic team aware of this? Any plans to look into it? If you need examples I can supply and provide more details.

DaVinci version 12.5.4

Funny I've found just the opposite. I'm on a DR studio on Mac pro 2013.
But now I'm going to go back and look at highlights and details to be sure.

What platform are you on ? What is the original media ?

I always found the H.264 support in Resolve pretty basic.

I never encode with Resolve as free tools like Handbrake or Hybrid are so much better.

It's okay for a quick preview render but not for anything more serious.

Whaooo, relying on Resolve to produce H264 is the true topic actually, and I'm impressed...

Especially when you know that Handbrake is THE piece of software to do this (its only job btw) : it always has up to date libraries, it is well supported and documented (even a good wiki for noobies), it is multi OS, it has anything you need to go further in fine tuning (8x8, cabac, no decimation, deblock, ...), super well multi-threaded, you can make presets and you can batch any number of clips to be encoded...

Frankly, going on with Resolve for H264 is crazy

Handbrake is good (like anything x264 based), except it's hardly up to date. It was very outdated, just recently (after year ?) it got new libraries. AAC audio was terrible on PC, recent version should be way better.

Always up to date on OSX

Always up to date on OSX

They get released at the same time, it just took them from Feb to end of December to make an update last year

I dunno, he was talking about poor AAC. On OSX, where Handbrake had been primarily developed on years ago, they let us choose HE-AAC or AAC, but bith of them take advantage of Core Audio, a deep framework of the system. Then no delay on this side anyway... Resolve also trakes advantage of Core audio since you cannot have access on Windows to all the audio plug-ins you find in OSX, only because Resolve grabs them from the Core Audio...

For the rest, not sure about what you're talking about : if there's no reason to release an update, why release one ? Just now, I just install 1.0.3 even though 1.0.2 was released a few weeks ago... Don't know what you're asking for...

These updates which you are talking about are some small updates/fixes, not core updates.

Core engine follows libav major releases which are very slow (last one took 2 years). PC and Mac are based on the same code. There has been tons of improvements over this time, new decoders added etc. Many reasons for new release, but author was waiting for libav12 major release.

On Mac audio is fine as you can chose OSX Core engine, on PC it was based for long time on very poor AAC code (this itself was important enough to get new release earlier). Now it's better.

It doesn't really matter for me (I use ffmpeg), but for many it does as Handbrake is easier to use.
It's free, so no obligation, but information that it's up to date is somehow "false". There was a lot happing in last 2 years in open source cores, but Handbrake was still using old code. Don't forget that Handbrake is "just" a GUI which link few open source projects.

Handbrake is good (like anything x264 based), except it's hardly up to date. It was very outdated, just recently (after year ?) it got new libraries. AAC audio was terrible on PC, recent version should be way better.

Relying on cute gui's is a poor choice; it only adds an unnecessary link that can break as well as requiring additional overhead which can result in slightly slower performance. The x264 cli executable gives one 24/7 access to the latest binaries—most recent being r2762 (January 30, 2017). However, development has slowed considerably and having the absolutely latest build is not quite as important as it once was (q.v. x265 development).

As for DR producing poor h.264 encodes, this should come as no surprise to anyone with a modicum of encoding experience. Adobe's bundled MainConcept encoder is also a far cry from x264 and has been for a while. The only caveat is using x264 (gui or cli) adds an additional step to one's workflow which may or may not be beneficial? One needs to weigh the additional time to render, storage requirements, and final delivery (e.g. do I really want to upload mp4's to YT when it gets re-encoded anyway?).

However, a reasonable question that I don't see asked very often is, 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.

I prefer ProResHQ or 444 as an intermediate codec.
Easy and good enough for 8bit compressed anyway.

Handbrake is good (like anything x264 based), except it's hardly up to date. It was very outdated, just recently (after year ?) it got new libraries. AAC audio was terrible on PC, recent version should be way better.

Relying on cute gui's is a poor choice; it only adds an unnecessary link that can break as well as requiring additional overhead which can result in slightly slower performance. The x264 cli executable gives one 24/7 access to the latest binaries—most recent being r2762 (January 30, 2017). However, development has slowed considerably and having the absolutely latest build is not quite as important as it once was (q.v. x265 development).

As for DR producing poor h.264 encodes, this should come as no surprise to anyone with a modicum of encoding experience. Adobe's bundled MainConcept encoder is also a far cry from x264 and has been for a while. The only caveat is using x264 (gui or cli) adds an additional step to one's workflow which may or may not be beneficial? One needs to weigh the additional time to render, storage requirements, and final delivery (e.g. do I really want to upload mp4's to YT when it gets re-encoded anyway?).

However, a reasonable question that I don't see asked very often is, 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.

Many people don't want to even hear about cmd tool
If tool is properly written than GUI is not a problem all- it has 0 impact on actual transcoding task. It's just to help you to pass parameters to x264 engine. Thing which can make a difference is eg. decoding engine (libav).

Image sequence is not the best choice as it's RGB based. For long time ffmepg was unable properly convert from RGB to YUV with correct matrix. Now you also have to know how to do it properly.

You want something already YUV based (properly converted from RGB world), so things like uncompressed 8/10bit, ProRes, DNxHR, Cineform etc. Some intermediate coded is probably best bet- good enough and not huge like uncompressed.

Ok, ok, I see...
I give up with Handbrake assets, which has always provided for us more than required to make very good files for anything on the web, and also in the BD world (even with not the latest of latest lib, but I said I gave up)...
Anyway, whatever delivering we make start from a ProRes out of Resolve or a NLE.

Handbrake is good (like anything x264 based), except it's hardly up to date. It was very outdated, just recently (after year ?) it got new libraries. AAC audio was terrible on PC, recent version should be way better.

Relying on cute gui's is a poor choice; it only adds an unnecessary link that can break as well as requiring additional overhead which can result in slightly slower performance. The x264 cli executable gives one 24/7 access to the latest binaries—most recent being r2762 (January 30, 2017). However, development has slowed considerably and having the absolutely latest build is not quite as important as it once was (q.v. x265 development).

Well, there is not that much more what can be done with x264 anymore Code is very well optimised.

As for DR producing poor h.264 encodes, this should come as no surprise to anyone with a modicum of encoding experience. Adobe's bundled MainConcept encoder is also a far cry from x264 and has been for a while. The only caveat is using x264 (gui or cli) adds an additional step to one's workflow which may or may not be beneficial? One needs to weigh the additional time to render, storage requirements, and final delivery (e.g. do I really want to upload mp4's to YT when it gets re-encoded anyway?).

80% of pro world uses Mainconcept SDK (some started x264, like Telestream), which is not the best, but proven and tested. It provides not only h264, but all other codecs and wrappers.

Image sequence is not the best choice as it's RGB based. For long time ffmepg was unable properly convert from RGB to YUV with correct matrix. Now you also have to know how to do it properly.

all the internal computations of modern video aspplications is done in the RGB domain nowadays. YCbCr is just useful for transfer and compression. in fact it's quite trivial to convert RGB to the latter. sure, it's not always done in an accurate manner! resolve in particular has demonstrated this kind of issues in an rather impressive frequency.

80% of pro world uses Mainconcept SDK (some started x264, like Telestream), which is not the best,..

yes -- i also don't like mainconcept based solutions, but the native windows system mechanisms, as presumable used by actual releases of resolve, look even worse.

all the internal computations of modern video aspplications is done in the RGB domain nowadays. YCbCr is just useful for transfer and compression. in fact it's quite trivial to convert RGB to the latter. sure, it's not always done in an accurate manner! resolve in particular has demonstrated this kind of issues in an rather impressive frequency.

Not really. This maybe true for Resolve or some other grading/compositing tools.
In NLEs, transcoders etc you rather most likely want to work in YUV (even do all filtering in YUV world) as almost all codecs are rather YUV based. Yes, RGB<->YUV is quite trivial, but it's not lossless and should be avoided if not 100% needed. Many apps use 32bit float 4444 YUV based pixel format.

2 different worlds, 2 different requirements/preferences.

RGB is an evil for compression as color and brightness are bound together.

Many people don't want to even hear about cmd tool

IMHO, if people are familiar with linux then they really have no excuse except to learn how to use the x264 or ffmpeg cli's. Honestly, I couldn't accomplish half of what I do without those two tools. I can't comment on anyone's aversion to a cmd tool, but I think more often than not it is a function of not knowing vs not wanting to know. Handbrake gets a lot of press for being nothing more than a cute gui on top of the ffmpeg/x264 engines. Call me a crusader.

Image sequence is not the best choice as it's RGB based. For long time ffmepg was unable properly convert from RGB to YUV with correct matrix. Now you also have to know how to do it properly.

You do realize that DR converts all assets to RGB internally regardless of the type, right (this has been confirmed by BMD)? Therefore, exporting as RGB sequence sidesteps whatever RGB to YCbCr conversion is going on in DR which BMD has been very closed fisted about (much to my chagrin). What scaler is used for chroma subsampling? What about dithering? These are all things I can easily control outside of DR which I prefer over the blackbox nature of DR. While in the past ffmpeg's -vf colormatrix was flaky, things have been improved dramatically with -vf scale which should be used now.

ffmpeg RGB->YUV conversion was overlooked for years. Last time I've tried was still not perfect. For example RGB48 to YUV path was fine, but going from DPX (gbrp10) to YUV was not (some tint present). Recent work finally made it more robust, but whole swscale is far from being 100% reliable. zimg should be way better.
When it comes to ffmpeg I test 5x before I trust it Some things are great, some still half done/accurate.

colormatrix was never a proper solution (and only 8bit anyway), but poor workaround which actually did not fix problem properly at all.

I agree with you, but trust me at least 50% people from this forum won't touch it.

You do realize that DR converts all assets to RGB internally regardless of the type, right (this has been confirmed by BMD)? Therefore, exporting as RGB sequence sidesteps whatever RGB to YCbCr conversion is going on in DR which BMD has been very closed fisted about (much to my chagrin).

That's why Resolve is not the best choice as converter between YUV based formats (e.g. ProRes to DNxHD) as it will force conversion to RGB, which you don't really want/need at all (if it's just a conversion task). BBC use to be crazy about going to RGB for no reason as RGB<->YUV is never lossless. Each task needs correct tool 1 for all is always going to be compromise somewhere.

i don't agree on this point. YUV/YCbCr processing should be more seen as kind of old fashioned broadcast heritage, but it doesn't make much sense in more complex high precision image processing software of our days. do you know any powerful non-legacy counterexample, that strictly works by utilizing YUV representations internally?

I'm on windows which somewhat limits my codec options ruling ProRes out.

I used to encode using MPEG4 compression before but in recent update (I think v12.5) MPEG4 bitrate was dropped drastically even at highest quality option so I'm looking for ways to render out fairly high quality video and got stuck.

And yes, Handbrake is THE best H264 encoder which I use a lot but I'd SO like to skip extra steps required to get great looking renders. So much time and energy is wasted on a seemingly straightforward process...

i don't agree on this point. YUV/YCbCr processing should be more seen as kind of old fashioned broadcast heritage, but it doesn't make much sense in more complex high precision image processing software of our days. do you know any powerful non-legacy counterexample, that strictly works by utilizing YUV representations internally?

What do you loose when you process in YUV 32bit float space compared to RGB, when you start and end in YUV? Nothing and actually gain speed and accuracy.
Adobe spent a lot of time implementing many filters in YUV (as well as GrassValley- Edius is almost exclusively YUV based) for exactly that reason. For some operations there is simply no need to go to RGB if you start and end in YUV. It's even undesired.

For example: convert ProResHQ to v210 format in Resolve and in AME. You should get 100% same result (v210 is native ProRes decoder format), but you won't as Resolve will convert v210 to RGB, then RGB back to v210 for export. This is totally undesired and also slows down conversion. It works this way in Resolve, but it doesn't mean it has to work this way in NLEs (you can design flow based on involved formats and needs). When you start with high-end source, mostly RAW it's easier/better to work in RGB (also when you process a lot on GPU). If you start with YUV based codecs it's better to stay in YUV as long as you can- simple as this. RGB processing superiority v YUV is a myth
RGB may be actually worse for any case:
http://annals-csis.org/Volume_3/pliks/206.pdf

I'm on windows which somewhat limits my codec options ruling ProRes out.

I used to encode using MPEG4 compression before but in recent update (I think v12.5) MPEG4 bitrate was dropped drastically even at highest quality option so I'm looking for ways to render out fairly high quality video and got stuck.

And yes, Handbrake is THE best H264 encoder which I use a lot but I'd SO like to skip extra steps required to get great looking renders. So much time and energy is wasted on a seemingly straightforward process...

World can't be so simple, it would be boring
All what you need is x264 export plugin for Resolve- maybe one day. There is one for Premiere developing now.

I'm on windows which somewhat limits my codec options ruling ProRes out.

no -- there are mature pres implementations for prores encoding available for windows just as well.
it's only resolve, which doesn't give you much freedom to customize it's capabilities by utilizing addons for this purpose.

...but I'd SO like to skip extra steps required to get great looking renders.

that's a very plausible claim and it's also very confusing, if results of the same multiplatform application look different on any actually used operating system.

the choice of codecs and media handling libraries is a really challenging problem. there are so many technical and legal troubles to work around concerning this matter, that we shouldn't criticize BMDs efforts to much. it's perfectly comprehensible, that they have chosen the native operating system capabilities as their preferred solution -- and it's indeed a noticeable improvement compared to the previous quicktime crap --, but i still think, support of a more modular extensible platform independent alternative, like gstreamer, would open very nice further improvements and possibilities as well.

What do you loose when you process in YUV 32bit float space compared to RGB, when you start and end in YUV? Nothing and actually gain speed and accuracy.

it's in fect a quite complex question, and i'm not sure, if i'm really able to grasp it in all practical consequences. it's not more then a personal opinion or estimation, that i can express about it.

i think, the main draw back of all kinds of internal YUV representation (in the actual video world its mostly YCbCr) should be seen in the uncommon and often more complicated math necessary. the only benefit you get, are some more ore less neglectable advantages concerning rounding issues, but otherwise it's mainly a more abstract representation, which doesn't fit very well into common approaches of image processing.

in fact, YUV data is in most cases used for display referred color information. that's a very bad starting point, even for quite simple creative image modifications. sure, the same will happen, if you take for example sRGB data and process it in a simple and unreflected way, without additional translation into linear space.

just take a look into this introductory article, to grasp, how important this is -- and how obvious the visual consequences may look, even for simple tasks, like blurring an image:

http://ninedegreesbelow.com/photography ... blend.html

it wasn't always taken for granted, that we have to consider this more complicated issues of color handling in digital image processing. many simple applications still do it in a quite unsatisfying manner until now -- and for simple video processing it's commonly handled even worse! -- that's why i consciously used the notion: non-legacy software.

i really like applications, that work more careful in this respect. often this implies some consequent break with the past and legacy broadcast traditions.

it's not only a question of the mathematics used within the programs, it also effects adequate representation and measurement tools. (e.g. traditional vectorscopes aren't a very useful kind of feedback, if you work beyond the rec709 conventions. other ways of chromaticity diagrams are much more useful and desirable in this case.)

so i would finally state, that it isn't RGB or YUV representation, that makes the difference (because that's usually just a different 'projection' of quite the same data), but more a matter of the real color science used while working with the affected images. in general, i would feel more alarmed in this respect, if applications try to work as close as possible to some given device referred color representation. this approach is usually quite counterproductive and insufficient, if you really want to get accurate color processing.

I don't really get why companies don't allow (or make it quite hard) to make plugins. Any software can be 2x more attractive though plugins, which quite often are provided even for free. It costs software maker nothing (except making good plugin extension engine) to maintain or support them (as this is done by plugin developer).

@andrew:

i was under the impression ofx was a recognized standard that would work in any nle?

i have a number of ofx plugins in both resolve, vegas and ppro. some are free, so presumably there's no stopping anyone writing a 'plugin' if they follow the rules?

i was under the impression ofx was a recognized standard that would work in any nle?

no -- openfx isn't the answer to all our needs! it's a highly specialized kind of plugin architecture for the processing of image data, but it doesn't have any support for audio, timecode etc., that you also want to access and preserve in more general purpose video processing. and in fact the ofx generator suite, which would allow the development of video file import plugins to some degree, is usually not very well supported in most applications. it would not be very handy to utilize it in resolve for any form of file import, bypassing the whole media management of the application...

and concerning to andrews statement:

I don't really get why companies don't allow (or make it quite hard) to make plugins.

yes -- i agree!
it's a very worthwhile aspect, if applications are open for any kind of customization and third party extensions, but you also should take into account, that it would only solve one part of the issue. it's in fact not that easy, to combine very nice free solutions, like ffmpeg, seamlessly with commercial software. e.g. the GPL license explicitly forbids any use in dynamic linked plugins utilized by non-free software! and that's not, because they want to restrict the freedom of users, but it's their main strategy, to protect free software in the long run against just becoming misused in a very unilateral and eclectic way.

There are always challenges. I just don't think that getting access to documentation/SDK/some help etc. should be one of them

There are always challenges. I just don't think that getting access to documentation/SDK/some help etc. should be one of them

yes -- i perfectly agree!
and indeed all sides could have some benefit of it!

Hi,

In Davinci Resolve:
- OFX for effects only
- delivery: NOP and currently no opening.

What I would like is that Davinci Resolve has the possibility of FrameServer in Delivery: so we can use the technology we want to encode what we want in the format we want.

Some quick thoughts.

First, I believe most NLEs (I can only speak as a Premiere Pro user) can operate exclusively in YUV. Adobe has even taken great pains to expose which effects are RGB, YUV, or both, so if an editor desires to avoid an RGB conversion and stay exclusively in YUV, they can. PP even offers smart rendering for numerous formats which means it won't re-encode footage that has no effects.

Second, the YUV-RGB-YUV conversion is not completely lossless. Unless your are dealing with YUV444 footage, you will have to scale the UV channels because RGB has no 4:2:2 or 4:2:0 analogs. And, none of the scalers are lossless. If you don't believe me try doing this with some YUV colorbars. The borders always get messed up. Furthermore, the RGB colorspace only covers about 1/6th of the YUV space, and "out-of-gamut" values opens a whole new can of worms. Some approaches will clip them, others use a soft knee. One can get around this somewhat by using RGB floating point and preserving the "out-of-gamut" values internally (there is just no way to display them). I know DR does this because when I dramatically pull down the gain I can see new values appearing on my scopes which is analogous to me applying my own soft knee.

It is for these reasons (I haven't even touched on gamma issues) that I transcode my ProResHQ footage to linear half float openEXR for DR. If there is a better way to navigate this minefield, I am all ears. I readily acknowledge that I am not an expert in these matters. I have just done a lot of testing and know from experience the problems.

Some quick thoughts.

Second, the YUV-RGB-YUV conversion is not completely lossless. Unless your are dealing with YUV444 footage, you will have to scale the UV channels because RGB has no 4:2:2 or 4:2:0 analogs. And, none of the scalers are lossless.

Not even this- whole conversion process is never lossless (regardless of 422 or how precise math you use). At least according to developers from doom9.

I have already discussed all the technical reasons that YUV to RGB conversions are lossy. But it is probably worth repeating:

1. Chroma subsampling (can be overcome with YUV444)
2. Rounding (can be overcome with floating point RGB)
3. Clipping (can be overcome by preserving out-of-gamut RGB values internally, just can't display them)

I may be missing something, but I don't think I am. Feel free to correct me. And I wouldn't believe everything you read at doom9. They are an insufferable and often misguided bunch.

Well, doom9 is big forum full of many people, but there few developers, who do things which are as advanced as Resolve engine itself

It seemed to me that Davinci Resolve is working in 32-bit RGBA. Rounding problems?

Well, doom9 is big forum full of many people, but there few developers, who do things which are as advanced as Resolve engine itself

I don't disagree that certain projects like x264 caused shockwaves in the industry (it is probably the single most important development to spur the move away from SD) and filters like QTGMC give commercial de-interlacers a run for their money. But x265 development is being led by MCW. And the world of video has moved far beyond the usefulness of the scripting tools they champion which are more suited to VHS restoration. When it comes to 4K+, high bit depth, HDR, VR, etc. Forget it.

It seemed to me that Davinci Resolve is working in 32-bit RGBA. Rounding problems?

I am probably not the best source for this, but to my knowledge DR converts EVERYTHING to floating point YRGB internally (which separates the luma channel) and works internally in this space when applying effects. This means technically there are no rounding errors. And I assume DR preserves out-of-gamut values as well. The one thing I don't know is how DR scales the chroma channels in 422/420 footage. But we are sort of talking about two different things. Lossless YUV to RGB conversion and back in a general sense of what is possible, and what does DR do specifically.

1. Chroma subsampling (can be overcome with YUV444)

i don't think, you'll find YUV444 much often used in practice. it simply doesn't make much sense.

3. Clipping (can be overcome by preserving out-of-gamut RGB values internally, just can't display them)

should we really take so much care about illegal colors outside of rec709 gamut?
no! -- this really doesn't make much sense neither.

sure, some broadcast experts still have to claim YUV capabilities, just as they have to work with interlaced video standards and all those other obscure heritage of analog video transmission every day till now. for them it may make some sense, to process YUV data just as we did it in good old analog days. sure -- that's still present in some specialized corners. but for most of us -- especially here in more high end color processing context --, it simply doesn't promise much benefit and attraction.

really -- i'm so happy, that i don't have to care about all the artifacts of interlaced video and similar stupid broadcast anachronisms anymore! its an invaluable relief! and there is still enough headroom for other useful improvements in state of the art image processing...

I think your response is better directed at Andrew. I was merely pointing out that technically one can overcome the hurdles that most people cite when attempting to losslessly convert YUV to RGB and back. Whether people care or want to is their prerogative, and I was not making any judgements about one thing or another. The only horse I have in this discussion is that it is better to be informed versus making incorrect statements.

Well, doom9 is big forum full of many people, but there few developers, who do things which are as advanced as Resolve engine itself

I don't disagree that certain projects like x264 caused shockwaves in the industry (it is probably the single most important development to spur the move away from SD) and filters like QTGMC give commercial de-interlacers a run for their money. But x265 development is being led by MCW. And the world of video has moved far beyond the usefulness of the scripting tools they champion which are more suited to VHS restoration. When it comes to 4K+, high bit depth, HDR, VR, etc. Forget it.

Really?
Can you show me 1 example of great (specially innovative) pice of pro software?
I'm so unimpressed with pro solutions, as in pro world it's all about money. So many pro software are based on so outdated cores as no one wants to spent money and do it based on current possibilities.
In open source world it's about fun, challenge, show of (sometimes) and this can create out of box solutions and ideas. They do it without access to specs, docs etc. They reverse engineering: ProRes, Cineform, GV codecs....industry instead trying to fight with those people should work with them (well, some companies do).

Have you seen any pro solution touching neural network based scaling algorithms? It took for many pro solutions ages to add quite simple at the end Lanczos3 scaling

Have you seen what madVR can do when it comes to HDR?
ATEME success is in big part thanks to doom9 forum also.
And yes- x264 shown the best what good open source project can achieve.

I know quite well pro and open source tools and are pro more advanced/better etc - not at all.

I made the mistake of being baited into a discussion about doom9. Can we just get back on track in discussing Resolve? Your enthusiasm for those other tools is better left at those other forums. I will be willing to continue, otherwise I am done.

I think original question has been answered: render intermediate file and use x264 based solution- ffmpeg, Handbrake etc.

........


Have you seen any pro solution touching neural network based scaling algorithms? It took for many pro solutions ages to add quite simple at the end Lanczos3 scaling

Have you seen what madVR can do when it comes to HDR?
ATEME success is in big part thanks to doom9 forum also.
And yes- x264 shown the best what good open source project can achieve.

I know quite well pro and open source tools and are pro more advanced/better etc - not at all.

Hi Andrew : my best is needi3 and i wait for a good deconvolution solution....

my best is nnedi3

yes, nnedi3 is very impressive...

i also recently stumbled over rusty_sr, a new super resolution solution written in pure rust. that's very interesting, because more and more image processing and video codec related work in the open source world is now done in this language. it helps to prevent a lot of common runtime errors without negative performance impact. a very important progress, because video files are very often used for serious security attacks. (see: http://www.zdnet.com/article/mozilla-be ... efox-rust/ and https://gstreamer.freedesktop.org/confe ... lines-rust )

i agree with andrew, this kind of innovative open source building blocks are indeed very useful!

they are often not written just for fun, but by very talented young researchers in the academic field.
if software comes with inviting APIs, plugin interfaces, etc. to build up, they are simply used, and the whole community has some benefit of it. but if it looks more like a pain, to hack even the simplest form of foreign access, the interesting development is going on elsewhere.

Heu Martin, Please correct....

........
Have you seen any pro solution touching neural network based scaling algorithms? It took for many pro solutions ages to add quite simple at the end Lanczos3 scaling
.

my best is needi3

yes, needi3 is very impressive...

Merci.

Heu Martin, Please correct....

o.k. -- the correct name is "Nnedi3"

Heu Martin, Please correct....

o.k. -- the correct name is "Nnedi3"

you're right. I will try to avoid you in the future.

Confused - I've read through the thread twice (some is over my head) and still don't understand.

What format is Eugene encoding from? What is his source format and is he converting to an intermediate codec before rendering out to h.264? If so, why?

Is there a h.264 (AVC) encoding quality problem in Resolve?
4k, HD?
Relative to what other NLEs encoding?
What encoder does Resolve use? x264 free encoder (used by Handbrake) is considered the best by many. MainConcept is also highly rated. Are two pass encoders better or necessary?
QT h.264 is rated among the worst encoders. See Img here http://imgur.com/a/B5jyE

What output file type is Eugene looking for? - Resolve only outputs h.264 Quicktime.
Why use 3rd party converters? I thought every conversion results in some quality loss.
My AVC export matches the bitrate and color depth to my source footage.
I need MP4 (file type is a codec wrapper) so I simply use a free utility to re-wrap Resolve H.264 to MP4 without using a converter.
I've been happy with Resolve quality so far - but I'm working with 8bit only.

Ok, I do realize I've supplied too little technical info. I'm encoding from 4K 16-bit Lossless CinemaDNG footage. Using H.264 typically for media delivery over Internet where size does matter while quality is still very much important. I got excited when I saw that H.264 encoding was implemented straight into Davinci only to find how poorly it was done, that's relative to any NLE. Footage encoded into H.264 from Davinci looses sharpness while other NLE's preserve sharpness and details even at much, much lower bitrate settings.