x265 HEVC Encoder

[Barough]

x265 v3.5+87
Built on January 20, 2023, GCC 12.2.0

https://www.mediafire.com/file/iz8fqi7rqpi55sm

[benwaggoner]

Nope, the patch still does apply. So, I was wondering, if this bug is so big and there since (minimum) 2018, why did no one else notice?
Have been a before/after analysis to show the benefits of the fix?

[jpsdr]

I've made a new build of my custom version, small quick encode test seems fine.
Check my Github.

[guest]

I've made a new build of my custom version, small quick encode test seems fine.
Check my Github.

I have done a lot of testing, you maybe interested in the results:-

https://forum.doom9.org/showthread.php?p=1981517#post1981517
&
https://forum.doom9.org/showthread.php?p=1981553#post1981553

But only up to build 85.

[LeXXuz]

I've made a new build of my custom version, small quick encode test seems fine.
Check my Github.

jpsdr, I have been using v+75 with extra switches: "--aq-mode 5 --sbrc --sbrc-aq5 --sbrc-hyst" for 1080p SDR content.

Is this still valid with v+87? A lot of talk about new switch names here which confuses me a little.

[jpsdr]

@LeXXuz
For the same command line effect, you have to replace --sbrc --sbrc-aq5 --sbrc-hyst with --aq-auto 10 assuming you don't want the new sbrc (wich has totaly nothing to do with the first patch) and just keep the auto AQ feature.
(And still check with the log file ;))

[LeXXuz]

@LeXXuz
For the same command line effect, you have to replace --sbrc --sbrc-aq5 --sbrc-hyst with --aq-auto 10 assuming you don't want the new sbrc (wich has totaly nothing to do with the first patch) and just keep the auto AQ feature.
(And still check with the log file ;))

Thank you jpsdr. Actually I'm not sure if I want or need the new sbrc as I don't fully understand what it does and if it is beneficial for my usage. :o

So with the latest version I just add "--aq-mode 5 --aq-auto 10", is that right? :)

EDIT: Btw the clang version shows "x265 [INFO]: build info [Windows][MSVC 1928][64 bit] 10bit", is that correct :confused:

[Boulder]

So with the latest version I just add "--aq-mode 5 --aq-auto 10", is that right? :)

If you want to use the automatic AQ mode with AQ5 + hysteresis enabled, just use --aq-auto 10. --aq-auto 6 for HDR (enables auto mode + hysteresis, no AQ3 or AQ5 used since it's counterproductive).

[jpsdr]

EDIT: Btw the clang version shows "x265 [INFO]: build info [Windows][MSVC 1928][64 bit] 10bit", is that correct :confused:
Yes, because it's build with llvm but still with Visual Studio (so using clang compiler instead).

[Boulder]

@jpsdr: I've seen mentioned in some places that AQ mode 4 needs a bit lower aq-strength than other modes. Would it be possible to have a separate aq-strength parameter for it in case aq-auto is enabled?

[jpsdr]

@Boulder
Euh... I don't know. I'll see but absolutely not promises... Don't have time for now.

[Boulder]

@Boulder
Euh... I don't know. I'll see but absolutely not promises... Don't have time for now.

Thank you :)

I was thinking that it might be as simple as adding the parameter and then conditionally using it as the base strength when the mode for the frame is either X265_AQ_EDGE or X265_AQ_EDGE_BIAS.

[jpsdr]

@Boulder
For X265_AQ_EDGE the calcul is:

inclinedEdge = curFrame->m_lowres.edgeInclined[blockXY];
qp_adj = curFrame->m_lowres.qpCuTreeOffset[blockXY];
if(inclinedEdge && (qp_adj - avg_adj > 0))
qp_adj = ((strength + AQ_EDGE_BIAS) * (qp_adj - avg_adj));
else
qp_adj = strength * (qp_adj - avg_adj);

So, you want something that can change the value of strength when aq-auto is enabled ?
If it's that, 2 options. Somethings like strength2 = strength*coeff or strength2 = strength + bias with coeff=1 or bias=0 when aq-auto is disabled and use strength2 instead of strength in calcul.
And if i add some kind of AQ4 specific parameter, it can be applied to AQ 4 mode, with or without aq-auto enable, if default value keeps original behavior.

[Boulder]

What I was thinking was basically that - having AQ 4 its own strength parameter. Maybe making it equal to aq-strength in case aq-auto is not enabled so any command line would work normally.

I was wondering if it would make sense to just change the calculation of 'strength' here, I haven't had the time to get the whole idea to work because the compiled exe won't accept my new parameters for some reason. What I did was just carbon copy the existing aq-strength and aq-bias-strength parameters in various files and adjust the variable names accordingly, but probably I've missed something. In this example there's also a different value for AQ 5 bias strength.


if (param->rc.aqMode == X265_AQ_EDGE || param->rc.aqMode == X265_AQ_EDGE_BIASED)
strength = param->rc.aqStrengthEdge * avg_adj;
else
strength = param->rc.aqStrength * avg_adj;
avg_adj = avg_adj - 0.5f * (avg_adj_pow2 - modeTwoConst) / avg_adj;
if (param->rc.aqMode == X265_AQ_EDGE_BIASED)
bias_strength = param->rc.aqBiasStrengthEdge * param->rc.aqStrengthEdge;
else
bias_strength = param->rc.aqBiasStrength * param->rc.aqStrength;

[jpsdr]

Is it what you want ?
https://github.com/jpsdr/x265/commit/3a56c08d4e451f8837ef67e9ca6dc36cef1d1880

[Boulder]

Is it what you want ?
https://github.com/jpsdr/x265/commit/3a56c08d4e451f8837ef67e9ca6dc36cef1d1880

Yes, that looks exactly what I thought of doing :) Thank you so much, I really appreciate it :thanks:

[jpsdr]

I don't know when i'll be able to make a build (as it takes time), maybe this evening, maybe in few days, but you still can make your own build frommy github.

[Boulder]

I don't know when i'll be able to make a build (as it takes time), maybe this evening, maybe in few days, but you still can make your own build frommy github.

No worries, I created a diff file to use for patching in Media Autobuild Suite so I got a compiled exe to test. First impression looks good, so I believe it's working. I didn't do any frame by frame compares but just watched an encoded clip to see if anything's weird.

[jpsdr]

If you have your own build, in that case, i'll realy take my time to make a new build... ;)

[Boulder]

If you have your own build, in that case, i'll realy take my time to make a new build... ;)

Yeah, no problem with that :)

If anyone wants to test the modifications, here's the build I made. 10-bit only, and optimized for Zen 3. I can also provide the patch file I used if needed.

https://drive.google.com/file/d/1WGiv0vzrpqrPI3_atczSWGuQqZJUdo3N/view?usp=share_link

[vadlerg]

Thank You for sharing the build.

--aq-auto 10 works. It is about 3% faster than --aq-mode 4 and may preserve a bit more detail.

When using --rd 4 --dynamic-rd 3 options I've got the warning
x265 [WARN]: Dynamic-rd disabled, requires RD <= 4, VBV and aq-mode enabled

That seems to be not rational. There must be some typo in the source, the build itself is OK.

[Boulder]

Thank You for sharing the build.

--aq-auto 10 works. It is about 3% faster than --aq-mode 4 and may preserve a bit more detail.

When using --rd 4 --dynamic-rd 3 options I've got the warning


That seems to be not rational. There must be some typo in the source, the build itself is OK.

The error message is a bit bad English to me. Do you have VBV enabled as well? I believe the AQ-mode checks ok if AQ auto is enabled.

if (m_param->dynamicRd && (!bIsVbv || !p->rc.aqMode || p->rdLevel > 4))
{
p->dynamicRd = 0;
x265_log(p, X265_LOG_WARNING, "Dynamic-rd disabled, requires RD <= 4, VBV and aq-mode enabled\n");
}

[vadlerg]

VBV is set automatically because of the parameters --crf 18 --preset slower --profile main10 --level-idc 52 .
aqMode should be 2 by default, but --aq-auto 10 sets it to AQ: mode / str(edg) / qg-size / cu-tree : auto-hyst-aq5 / 1.0(1.0) / 32 / 1
rdLevel is set to 4 and encoder still disabling dynamic-rd, even if I set --rd to 3.
In the INFO section I see
x265 [INFO]: tools: rect amp limit-modes rd=4 psy-rd=2.00 rdoq=2 psy-rdoq=1.00
x265 [INFO]: tools: rskip mode=2 rskip-edge-threshold=0.03 limit-tu=4 signhide
x265 [INFO]: tools: tmvp b-intra strong-intra-smoothing deblock sao
x265 [INFO]: tools: selective-sao

[Boulder]

aqMode should be 2 by default


Then it must be because of --aq-auto. I'll take a look at it when I'm back home from work and adjust that check in the code accordingly to make it work again.

[LeXXuz]

aqMode should be 2 by default, but --aq-auto 10 sets it to


Isn't that what it is supposed to do?
https://forum.doom9.org/showthread.php?p=1981600#post1981600

[vadlerg]

Of course it is what it supposed to be but this should not disable dynamicRd.

[Boulder]

Of course it is what it supposed to be but this should not disable dynamicRd.

Yes, it's probably just that validation which has not been updated accordingly. I don't remember I've ever seen the dynamic RD option used by anyone so it's definitely understandable.

[Boulder]

I found the cause of the issue, it's not auto-aq related. The validation is almost ok, it just doesn't understand that --level-idc enables VBV. If you add the VBV parameters to the command line, it will work.

EDIT: Here's a build where the validation is fixed (if VBV is not set and --level-idc is 0, it will disable dynamic-rd): https://drive.google.com/file/d/1U9cz3xsdp06ji79ZHyGA3oyuz29tYLul/view?usp=share_link

[benwaggoner]

Yes, it's probably just that validation which has not been updated accordingly. I don't remember I've ever seen the dynamic RD option used by anyone so it's definitely understandable.
I've used it before, with high resolution CRF with VBV encodes. It lets the encoder run faster when it can achieve CRF, and then slows down to improve quality when VBV limitations keep CRF from being hit.

It can improve throughput across many clips, but perf improvements for any given encode are unpredictable, varying with how often the content would hit the VBV.

Of course, this will increase ABR versus just using full complexity the whole time, so it's quite scenario specific. There is also the risk of the different modes causing some "stylistic" discontinuities.

[vadlerg]

Thank You. That's it.

[jpsdr]

I'm stuck with an issue i've no idea for now how to solve, and i may think that's there is just no solution at all (unless a loooooot of rework of the code).
After adding just the command line asked by Boulder, i've hit the C1061 error issue with MS compiler... :(
Why have they done this...????
As it's specific to MS compiler, i still can make the clang version, but for now, it's the only build i can do.
To do the others builds, i have to see how i can build x265 with gcc, maybe i'll do that, but not the time for now...

[jpsdr]

Finaly i made some tests for gcc build, but when things want to get in your way, they are very efficients... :(

I've tested msys script build, but what i'm looking for is where i can find the parameter list you see in command like this:cmake -G "MSYS Makefiles" ../../../source -DHIGH_BIT_DEPTH=ON -DEXPORT_C_API=OFF -DENABLE_SHARED=OFF -DENABLE_CLI=OFF -DMAIN12=ON
I want to make a static standalone .exe, not a one when you start it asked a lot of gcc dll...!
This is possible with cmake-gui (i have trouble to make it start also), but cmake-gui doesn't give all the options (you don't have 12bits for exemple).
Also, i would like to add "-mavx2" in the gcc command, no idea how to do that's kind of stuff (this is why i choose the Visual Studio solution, where i have access to all the compiler options in the ide).

Edit
Even with "static link CRT" checked in cmake-gui, the .exe from gcc build is still asking for dll... Not the same than my first attempt without, but still...

So, gcc builders, can you provide my your whole complete build script ?
As i said, when things want to get in your way, they are very efficients !!

[Boulder]

For GCC builds, I use Media Autobuild Suite to take care of the cumbersome scripting. You can use custom patches, for example with x265, create a file named x265_git_extra.sh and add the patch in the main 'build' folder and it will get applied during the compile operation. This is what I have in the file.

#!/bin/bash

_pre_ninja(){

patch -p 1 -i "$LOCALBUILDDIR/x265-jpsdr-aqauto-v5.patch"

}

[qyot27]

I've tested msys script build, but what i'm looking for is where i can find the parameter list you see in command like this:cmake -G "MSYS Makefiles" ../../../source -DHIGH_BIT_DEPTH=ON -DEXPORT_C_API=OFF -DENABLE_SHARED=OFF -DENABLE_CLI=OFF -DMAIN12=ON
cmake . -LAH will emit the full list of variables that get set with their values, although it isn't all that nicely formatted. In many cases it's just easier to open CMakeLists.txt and see what things are either listed as option() or being toggled as an environment variable with set() or some such.

I want to make a static standalone .exe, not a one when you start it asked a lot of gcc dll...!
This is possible with cmake-gui (i have trouble to make it start also), but cmake-gui doesn't give all the options (you don't have 12bits for exemple).
Also, i would like to add "-mavx2" in the gcc command, no idea how to do that's kind of stuff (this is why i choose the Visual Studio solution, where i have access to all the compiler options in the ide).

Edit
Even with "static link CRT" checked in cmake-gui, the .exe from gcc build is still asking for dll... Not the same than my first attempt without, but still...

So, gcc builders, can you provide my your whole complete build script ?
As i said, when things want to get in your way, they are very efficients !!
See example here (yes, x265 is in the guide, but for clarity's sake use a smaller example):
https://github.com/qyot27/mpv/blob/18aa1fd40f234931d13d3512dfd835275add7dd2/DOCS/crosscompile-mingw-tedious.txt#L475

Most GCC toolchains that are widely distributed are built assuming shared runtime by default, you have to either pass something like -static-libgcc -static-libstdc++ to LDFLAGS (in CMake, -DCMAKE_SHARED_LINKER_FLAGS for libraries and -DCMAKE_EXE_LINKER_FLAGS for executables) or you can just turn this off entirely by building GCC with static runtime only (which is what I do when building the MinGW/GCC toolchain, hence why the guide doesn't use those flags).

I need to do a good refresh on that guide because while I typically do a once-through every six months after moving to the current release of Ubuntu, I was so stressed out last year and now spend >95% of my time in Linux that I still haven't done so since last May or something like that.

[jpsdr]

Ok, translation issue from my part, my question is not properly made.

I was asking, from people using gcc, their whole complete build script for building static x265 (not building gcc...).

[LigH]

Mine (https://www.ligh.de/software/MABS/makehdr10_w64-git.sh) (depends on the media-autobuild suite directory tree and its MSYS2/MinGW64 shell).

[jpsdr]

@LigH
Is in your script the following line:export CXXFLAGS= allow to add compiler options (like -mavx2) that will be used afterward ?

[LigH]

No, just basic adaptions of the Multicoreware templates.

[jpsdr]

No luck, i've tried several options, but i always have an error message telling me that libstdc++6.dll is missing when i try to run the x265.exe builded... :(
Don't know what option i have to use to make a standalone version.

[LeXXuz]

@LeXXuz
For the same command line effect, you have to replace --sbrc --sbrc-aq5 --sbrc-hyst with --aq-auto 10 assuming you don't want the new sbrc (wich has totaly nothing to do with the first patch) and just keep the auto AQ feature.
(And still check with the log file ;))

jpsdr, is it normal that Mediainfo shows all kinds of aq-mode when encoding with --aq-mode 5? Some files show aq-mode=2, others 3, 4 or 5. All have been encoded with --aq-mode 5 and --aq-auto 10.

[filler56789]

No luck, i've tried several options, but i always have an error message telling me that libstdc++6.dll is missing when i try to run the x265.exe builded... :(
Don't know what option i have to use to make a standalone version.

As qyot27 already said, your "best" (ooops :o) option is to use a "static" build of GCC for Windows...
so you won't have to mess around with the CMake flags;
(just as an example...) ↓↓↓
-DCMAKE_EXE_LINKER_FLAGS="-static-libstdc++ -static -pthread" when configuring resolves it with vanilla MSys2 with default repo packages.

When I still had the "energy" to make builds of x265.exe, and when I did not use the GCC binaries compiled by myself, I used the GCC packages built by nevcairiel or by www.msystem.waw.pl/x265.

H.T.H. :-|

[jpsdr]

@LeXXuz
I don't know how Mediainfo get his information, neither how x265 stores them. As in auto-aq the aq-mode changes on the fly, according how/when x265 stores the informations retrievied by Mediainfo, it would not be surprising to see differents values. But... for the same file with the exact same parameters, you should always have the same result.
@filler56789
Ok, thanks, i'll try with the gcc versions on www.msystem.waw.pl/x265, i allready use this for one of my x264 build.
So it means that the gcc version provided by default with msys2 isn't working with the standard scripts provided in the build/msys directory of x265 git... (unless tweak them).

Edit:
According CMakeList.txt, CMAKE_CXX_FLAGS is not used unless you set CMAKE_BUILD_TYPE to None.
Using CMAKE_CXX_FLAGS seems to me the only way to add tune build options (like -mavx2).
But, i've not been able to figure out what are the CXX_FLAGS options in Release build.

[FranceBB]

I used the GCC packages built by nevcairiel or by www.msystem.waw.pl/x265.

I used them too, but the readme should really be updated as they're no longer Windows XP compatible and have not been for a while now (I think pre-pandemic).

@jpsdr... I'll bother you soon-ish via email, as soon as I have a bit of spare time at work (which is unlikely given the stuff I have to do right now). Anyway, to summarize, although I was totally fine with your x264 mod for x264, the fact that the company I work for is part of the partner program with Multicoreware makes me a bit "sad" to have to use modded version of x265 as well, so I'm determined to gather a list of the changes and come up with a big proposal to MCW to eventually merge them back into x265 and we can do this together given that we already had a chat with them about that other thing you asked last time. TL;DR given that we actually have a say on this, I'd like to avoid having an x265 mod that ends up becoming yet another x264 mod-like kind of situation where changes/fixes/improvements are never merged back and no one cares.

[StvG]

@filler56789
Ok, thanks, i'll try with the gcc versions on www.msystem.waw.pl/x265, i allready use this for one of my x264 build.
So it means that the gcc version provided by default with msys2 isn't working with the standard scripts provided in the build/msys directory of x265 git... (unless tweak them).

Edit:
According CMakeList.txt, CMAKE_CXX_FLAGS is not used unless you set CMAKE_BUILD_TYPE to None.
Using CMAKE_CXX_FLAGS seems to me the only way to add tune build options (like -mavx2).
But, i've not been able to figure out what are the CXX_FLAGS options in Release build.

For CMAKE_BUILD_TYPE=Release use CMAKE_CXX_FLAGS_RELEASE / CMAKE_C_FLAGS_RELEASE

In order to use provided msys2 gcc and have statically linked internal libs use -DCMAKE_CXX_FLAGS_RELEASE="-static-libgcc -static-libstdc++ -static".

[jpsdr]

@StvG
Yes !! Finaly, it's working with the msys2 gcc. Thanks, after several people tall me the same thing, it finaly enters in my head... :D

Now... The last step.

I have several mingw64 directories in my msys directory for switching gcc versions. By default, my mingw64 directory is the one provided by gcc. I have two others: mingw64_win32 (the www.msystem.waw.pl/x265 version) and another mingw64_mcf, le LH Mouse version. To switch, i just rename, for exemple: "mingw64 -> mingw64_posix" and "mingw64_win32 -> mingw64", and then, i start the "MSYS2 MinGW 64-bit" icon of MSYS2 and check with a "gcc -v". This works perfectly fine for doing my several x264 builds.
And when there is a new release of the Win32/MCF version, i delete the mingw64_xx directory and extract/replace by the new version.
So, i just tried to do the same thing for x265, and... It didn't work, the script told me "cmake: command unknow"... :(
It seems that the mcf, and "worse", the one provided by www.msystem.waw.pl/x265 don't have cmake.
I didn't try yet to "re-install" cmake on the renamed directory, is it the only way ?

Edit:
As i was afraid, as i've already installed cmake, even if i put a mingw64 directory without it, msys said that's it's already installed and has nothing to do.
I can't switch to another version... :(
Edit2:
I was using pacman -S --needed, i changed to pacman -S, it said it's allready installed but re-install anyway, but... only the package, not the necessary dependancies, msys thinks they are all installed.
cmake installed but still not working with alternative gcc version...

@FranceBB
99% of the patches are not mine. They came either from the Patman version or others, i just gathered them.

[filler56789]

@jpsdr && to anyone interested as well...

«User Guide: How to setup an MSYS2 building environment»

https://forum.videohelp.com/threads/394148-How-to-setup-an-MSYS2-building-environment

12) Time to edit the file home\YourUsername\.bash_profile.
Add the lines below:

export PS1='[\w]\n<$MSYSTEM> '

PATH=/commons:/CMAKE/bin:/GIT/bin:/HG:$PATH
export PATH

[jpsdr]

For now, i've been able in my mcf version, to "re-install" cmake, after compare the dependencies with the list of installed packages in mcf version, and after a dozen of missing dll and a dozen of more packages, to have the whole list of things to install... And build success with mcf.

[StvG]

I have several mingw64 directories in my msys directory for switching gcc versions. By default, my mingw64 directory is the one provided by gcc. I have two others: mingw64_win32 (the www.msystem.waw.pl/x265 version) and another mingw64_mcf, le LH Mouse version. To switch, i just rename, for exemple: "mingw64 -> mingw64_posix" and "mingw64_win32 -> mingw64", and then, i start the "MSYS2 MinGW 64-bit" icon of MSYS2 and check with a "gcc -v". This works perfectly fine for doing my several x264 builds.
And when there is a new release of the Win32/MCF version, i delete the mingw64_xx directory and extract/replace by the new version.
So, i just tried to do the same thing for x265, and... It didn't work, the script told me "cmake: command unknow"... :(
It seems that the mcf, and "worse", the one provided by www.msystem.waw.pl/x265 don't have cmake.
I didn't try yet to "re-install" cmake on the renamed directory, is it the only way ?

You can download cmake (https://cmake.org/download/). Then you can use the absolute path. For example /d/cmake/bin/cmake.exe -G Ninja ... Or you can add it PATH.

[jpsdr]

Thanks.

Any idea why this works:
mkdir -p 10bit

cd 10bit
cmake -G "MSYS Makefiles" ../../../source -DENABLE_SHARED=OFF -DHIGH_BIT_DEPTH=ON -DENABLE_CLI=ON -DSTATIC_LINK_CRT=ON -DCMAKE_CXX_FLAGS_RELEASE="-static-libgcc -static-libstdc++ -static"
make ${MAKEFLAGS}

and this doesn't:mkdir -p 8bit_x64 10bit_x64 12bit_x64

cd 12bit_x64
cmake -G "MSYS Makefiles" ../../../source -DHIGH_BIT_DEPTH=ON -DEXPORT_C_API=OFF -DENABLE_SHARED=OFF -DENABLE_CLI=OFF -DMAIN12=ON -DCMAKE_CXX_FLAGS_RELEASE="-static-libgcc -static-libstdc++ -static"
make ${MAKEFLAGS}
cp libx265.a ../8bit_x64/libx265_main12.a

cd ../10bit_x64
cmake -G "MSYS Makefiles" ../../../source -DHIGH_BIT_DEPTH=ON -DEXPORT_C_API=OFF -DENABLE_SHARED=OFF -DENABLE_CLI=OFF -DCMAKE_CXX_FLAGS_RELEASE="-static-libgcc -static-libstdc++ -static"
make ${MAKEFLAGS}
cp libx265.a ../8bit_x64/libx265_main10.a

cd ../8bit_x64
cmake -G "MSYS Makefiles" ../../../source -DEXTRA_LIB="x265_main10.a;x265_main12.a" -DEXTRA_LINK_FLAGS=-L. -DENABLE_CLI=ON -DENABLE_SHARED=OFF -DLINKED_10BIT=ON -DLINKED_12BIT=ON -DSTATIC_LINK_CRT=ON -DCMAKE_CXX_FLAGS_RELEASE="-static-libgcc -static-libstdc++ -static"
make ${MAKEFLAGS}

# rename the 8bit library, then combine all three into libx265.a using GNU ar
mv libx265.a libx265_main.a

ar -M <<EOF
CREATE libx265.a
ADDLIB libx265_main.a
ADDLIB libx265_main10.a
ADDLIB libx265_main12.a
SAVE
END
EOF

With LH Mouse mcf gcc version, the multilib version is asking for libmcfgthread-1.dll but the just 10bit is not...

Edit:
Didn't check yet (lack of time, ended things at 1am) with msys2 gcc version instead of mcf.

[LeXXuz]

@LeXXuz
I don't know how Mediainfo get his information, neither how x265 stores them. As in auto-aq the aq-mode changes on the fly, according how/when x265 stores the informations retrievied by Mediainfo, it would not be surprising to see differents values. But... for the same file with the exact same parameters, you should always have the same result.


Thanks for that explanation. :) I was just wondering because sometimes it shows aq-mode=5 which would be correct and sometimes all the others.

Guess I had the wrong understanding of mode 5. I thought it is a mode of its own which behaves like one of the other modes depending on scenery, therefore constantly flagged as mode 5 throughout the entire stream.

So it is more like a 'fictitious' mode which switches through the other modes depending on scenery and changing the mode flags accordingly? That still confuses me a little. Because in that case Mediainfo should never display aq-mode=5 for some files, no?