Parallel encoding to speed up aomenc

[Boulder]

I've now pushed the latest version to the repo. Quite a few small tweaks there, namely the ability to tweak the saturation of the FGS analysis clip and doing tone mapping of HDR sources (using DGHDRtoSDR) and adjustable downscaling in the scene change detection phase for faster processing and increased accuracy. The progress bar also works better now and gives a more accurate estimate of remaining time.

I've put several grain table files in the repo as well if anyone finds them useful.

[Blue_MiSfit]

Hmm... comparing those encodes against the reference in the free version of MSU VQMT I see a slight hue shift towards magenta in the AV1 version but not in the HEVC version... Not sure what could be the cause of that.

[Boulder]

Originally Posted by Blue_MiSfit

Hmm... comparing those encodes against the reference in the free version of MSU VQMT I see a slight hue shift towards magenta in the AV1 version but not in the HEVC version... Not sure what could be the cause of that.

Yes, I have noticed the same thing myself. I've been trying to find out the reason and I think I've caught it.. if you feed 8-bit input to aomenc (and encode at 10 bits as is recommended), the result gets this shift. If you convert the source to 10 bits before inputting it, the colors look pretty much the same in the encode as in the source.

I need to test this with different cases and try to replicate it with the vanilla aomenc so I can see if the problem's there or in the lavish fork.

[Boulder]

The hue shift issue occurs when using FGS and 8-bit input, works fine if the source is converted to 10 bits or an FGS table is not used. I didn't check if it applies to 8-bit encodes, as there's really no use doing those.

I've opened a case in the aomedia issue tracker, let's see if anything happens. For the time being, I need to add the conversion step to my tool. I still think that a B/W film grain table is better than one with chroma data included

[benwaggoner]

Originally Posted by Boulder

The hue shift issue occurs when using FGS and 8-bit input, works fine if the source is converted to 10 bits or an FGS table is not used. I didn't check if it applies to 8-bit encodes, as there's really no use doing those.

I've opened a case in the aomedia issue tracker, let's see if anything happens. For the time being, I need to add the conversion step to my tool. I still think that a B/W film grain table is better than one with chroma data included

Hmm, perhaps they're doing some sort of 4x scale factor for chroma instead of using bicubic interpolation or something. A straight multiple would round down chroma value a bit. Inverse dithering with interpolation is a largely untapped approach. Basically it should be like a bicubic, but in depth instead of area.

[Boulder]

I've developed the tool further along the way and the latest change was to add the support for encoding end credits using different Q and --cpu-used.

I think the next bigger step will be adding support for SVT-AV1, there is a huge performance boost incoming and also very interesting development regarding aq-mode 2 and low contrast sources which are often a problem for encoders.