I've been wondering what's the difference between your binaries, Barough's and LigH's?

Also, i read in the x265 online manual (x265.readthedocs.io) that AQ-Mode 3 is good for low bitrate 10bit encodes... But what is considered low bitrates for Full-HD and 4K?

I backup my bluray movie collection @ Full-HD between 4000 and 8000kbs (depends mostly on the amount of grain, some movies can go higher but those are the exception. Animations tend to go lower)...
Is that considered low bitrates?

I've been wondering what's the difference between your binaries, Barough's and LigH's?

No clue how exactly Barough builds them ... but probably negligible.

I use the media-autobuild_suite as MSYS2 base environment, but still run separate build scripts in MinGW32 and MinGW64. No additional optimizations, just semi-automatic preparation for building the archive to be uploaded.

I use the media-autobuild_suite as MSYS2 base environment, but still run separate build scripts in MinGW32 and MinGW64. No additional optimizations, just semi-automatic preparation for building the archive to be uploaded.

Means: We use the same tools to build them, and very similar ways to do that. You may not notice any differences (e.g. in speed) when comparing both while encoding the same material with the same parameters.

was wondering the same.
i did some test encodes with default parameters and "--dynamic-refine --refine-intra 4" @1000kbit/s Two Pass
i couldn't really tell a difference...
how are you supposed to see a difference when changing one parameter? that's almost impossible in my eyes - without picking single frames, which doesn't make much sense anyways.
decoding at ultra low bitrate?

Well, I did not expect obvious differences for random material and convenient bitrates; someone with more insight might know academic cases where an improvement can be expected. My guess would be: questionable cost-benefit ratio.

had some thoughts about the aq-motion option I wanted to share. on the previous pages I referred to a scene where this option creates serious and very noticeable artifacts. here is the source clip and encodings to compare. focus on the two guys walking back to the truck after the first scene cut:https://mega.nz/#F!DMYT2ICb!4aufAuilmDJAn-Bj-Gzcpg

commandline that was used with --aq-motion / --no-aq-motion resp.:

Code:

--preset slow --crf 23 --profile main10 --no-sao

this is the description of the feature from the x265 documentation

Quote:

--aq-motion, --no-aq-motion
Adjust the AQ offsets based on the relative motion of each block with respect to the motion of the frame. The more the relative motion of the block, the more quantization is used. Default disabled. Experimental Feature

this is apparently also applied when the frame doesn't move at all. so even when the scene is still, moving parts will use more quantization. I'd assume the original intention of this option is to only use more quantization in moving scenes where the block in question doesn't follow the global motion direction.

with a faster moving scene more quantization should be less noticeable on blocks with alternate direction. so to make this option more viable I'd suggest to scale the option with the speed of the global motion. with this still scenes shouldn't be affected at all and slow scenes less which avoids ugly results like demonstrated with the sample.

this is apparently also applied when the frame doesn't move at all. so even when the scene is still, moving parts will use more quantization. I'd assume the original intention of this option is to only use more quantization in moving scenes where the block in question doesn't follow the global motion direction.

with a faster moving scene more quantization should be less noticeable on blocks with alternate direction. so to make this option more viable I'd suggest to scale the option with the speed of the global motion. with this still scenes shouldn't be affected at all and slow scenes less which avoids ugly results like demonstrated with the sample.

By the time the encoder would have even a rough idea of the global motion of the frame, more than half the blocks would already be quantized and done. x265 doesn't do any global motion estimation in the lookahead phase, it just decides if a scenecut is warranted, and everything else happens in a huge combined phase that outputs blocks as it gobbles them up.

Maybe a check for the inverse of emergency VBV could be enabled: Once the frame is over, go back and say "hey, that frame was pretty easy after all and didn't need to be so overcompressed." Or since global motion is known by the end, look back and see the oops before flushing the frame. Performance would take a pretty big hit every time it happened, especially if it affects future frames that are already mid-encode, but you need quality modes too. --aq-motion has promise in increasing overall quality, managing it just seems difficult.

__________________There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order.

thanks foxyshadis for your explanations, I'm not that familiar with the inner workings of the encoder. well, there goes my idea. maybe there are some other approaches to improve aq-motion. I think it definitely has potential and behaves well in many cases.

x265 v2.7+25 introduces the CLI option single-sei (to write all SEI messages in one single NAL, which may cause compatibility issues with reference decoders); but its documentation is missing in the full help, so I'll wait for the next patch.

By the time the encoder would have even a rough idea of the global motion of the frame, more than half the blocks would already be quantized and done. x265 doesn't do any global motion estimation in the lookahead phase, it just decides if a scenecut is warranted, and everything else happens in a huge combined phase that outputs blocks as it gobbles them up.

Maybe a check for the inverse of emergency VBV could be enabled: Once the frame is over, go back and say "hey, that frame was pretty easy after all and didn't need to be so overcompressed." Or since global motion is known by the end, look back and see the oops before flushing the frame. Performance would take a pretty big hit every time it happened, especially if it affects future frames that are already mid-encode, but you need quality modes too. --aq-motion has promise in increasing overall quality, managing it just seems difficult.

Good analysis. That said, doing a coarse estimate of global motion in a downrezzed frame during lookahead is a perfectly reasonable strategy. Also the 1st pass global motion is known in later passes, so the above could work with 2-pass or even refine analysis. Global motion should be pretty consistent across frame sizes, so data from a lower Rez can be reused it doing an adaptation set.

x265 has static levels of refinement(--refine inter <level>/refine intra <level>) which can be used with --analysis-reuse-level 10.
Efficiency in terms of quality increases as the levels of refinement increases. This quality increase results from additional computation thereby increasing the overall encoding time.
For a better quality-speed trade-off, dynamic refinement was introduced where the encoder dynamically switches between different inter refine levels.
This basically exploits the fact that not all CUs are required to be encoded with same level for better performance/quality.
Considering the complexity of video content and the analysis information from first pass, the encoder can intelligently decide the optimal level of refinement for each CU.
Intra frames are usually encoded with best quality as they are used as references by the consecutive frames. Hence error introduced in intra frames due to reusing analysis data can propagate to frames that use these intra frames as reference.
To minimize the chances of error propagation, refine-intra 4 (level with best quality) restricts reusing analysis data for intra frames and forces the encoder to perform full intra analysis in the second pass.
This is why x265 documentation suggests to use dynamic refinement along with refine-intra 4 and this setting is expected to give improved quality than other refine intra levels for some videos.

yeah, i think i will use this as default, combined with slow preset.
afaik there are some settings that haven't really been adopted to presets. are there any plans to revise presets?
btw. can't wait for that avx 512 - ready to overheat my cpu