Ah that's too bad. It's kind of an important option to get good looking encodes in terms of finer details. Disabling deblocking sadly doesn't look very good. Would be lovely if something could be done.
Edit: Can the colon maybe be escaped in the inner string or sth?
Sounds great, thanks!
Re: Dithering
According to the documentation there's also https://ffmpeg.org/ffmpeg-scaler.html which seems to provide a choice of dithering.
The name "scaler" seems to be a bit misleading as it also appears to offer just pixel format conversion.
When encoding to x264, the deblock value cannot be changed in the settings for some reason, no matter what I enter, as soon as I click away or enter, it defaults to 0:0. Probably not too hard to solve, but would be awesome if it worked. The only thing I could do is to disable deblocking altogether, but I'd like to set something like -3:-3
Thanks, that seems to work fine!
Does this take into account the 16th bit which only adds/subtracts a single value? Or is that not the case with AE?
Well I'd argue converting from float to UInt16 is at least cleaner than doing the weird bit shifting and all that. And has more precision ultimately. Edit: However since you've already implemented the conversion, I suppose having the 16 bit option can't hurt. The floating point would be a nice addition ofc.
While we're at it, I'm wondering another thing, does ffmpeg have dithering that can be activated to convert to the target pix_fmt? It seems that in the 8-bit mode, After Effects already delivers dithered data, but in the 16 (well, 15) bit mode, it does not appear to do any dithering. And given that output formats like ProRes or HEVC aren't full 16 bit anyway, it might make sense to have an option to activate dithering for 16+ bit input formats to reduce banding for very high dynamic range and low noise content.
So for example for ProRes the the 16 bit or floating point content would be dithered down to 12 or 10 bit or whatever the encoder does.
Dithering would be bad for any scientific applications but good for anything artistic, so would be nice to be able to choose. AVISynth for example provides three options: No dithering, ordered dithering and Floyd-Steinberg dither in its ConvertBits() function.
I wouldn't expect you to implement such dithering yourself of course, just asking in case ffmpeg already offers that.
Aaah. Funny that... Photoshop does the same. I believe in Photoshop it is a kind of faux 16 bit, where it uses 15 bits for the 2^15 values and the additional bit is used to simply add or subtract 1. They use that to have a perfect gray value which helps them with some filters apparently. I wonder what the correct way to translate that into 16 bit may be.
Edit: Maybe it would be easier to disable the Trillions of Colors and instead allow floating point? That would take care of the weirdness and heighten the precision too.
Thanks a lot Vouk! That does unlock the option for Trillions of Colors however the output contrast/tone curve is pretty off, so I can't even quite tell if the full precision is being carried over. Did the test with ProRes 10 Bit 4:2:2 and compared it to an export using Millions of Colors. Generally speaking the image ends up a bit too dark but that doesn't quite fully describe the problem I think.
My project was as follows: 32 bit linear floating point, in linearized sRGB. Output color space in the Color Management tab in the export options was set to HDTV (Rec 709).
Any update on this by any chance?
Did some exporting from After Effects and it works great from what I can tell. But I couldn't set Trillions of Colors in the Output settings. Can that be enabled in some way? Especially for x265 encodes that would be very useful to not lose any precision. Currently only Millions of Colors can be selected.
Oh, didn't realize that, thanks for the info! Speed isn't important.
The difference in tmod are a few extra settings, mostly aq-related afaik, see this screenshot from the --fullhelp:
In particular I found the OreAQ setting of --aq3-mode rather useful as well as --aq3-boundary (helped preserve more details in shadows and highlights in my test by setting it to fullrange values). It plays together rather nicely with a strong normal AQ, as the normal AQ at higher intensities tends to lose detail around edges, which OreAQ restores.
This is kind of 2 requests in one.
For one, it would be awesome if the tmod x264 version was selectable, as it has some extra parameters that I like to use to improve my encodes. This is the one I mean: https://github.com/jpsdr/x264/releases
Second, I love encoding at 10 bit for a bit more efficiency and better dark values for potential screenshots/regrades. I know there's no hardware acceleration, but could this be made possible somehow either way? A 10 bit version is included with the tmod version.
I believe the relevant branch for the code is t_mod_New
I have no idea how much work this would be, so I'm just throwing it out there for your consideration. At least a 10 bit variant would be very nice, even if its not tmod.
