Due to how track order handling works, the function for setting the
display dimensions of a track is called twice if a track order is
present. That means that the function should be idempotent & not
change anything the second time around.
Unfortunately this wasn't the case if an aspect ratio factor was given
for a video track. In that case the result of the calculation is
stored back in a variable that is used in said calculation, meaning
the inputs for the calculation were different the second time
around. This led to the pixel aspect ratio being applied on top of the
given aspect ratio of the command line.
For example, with a pixel resolution of 720x576 (pixel aspect ratio of
5/4 or 1.25) and a given aspect ratio factor of 1/1, nothing should
change at all; the display dimensions should equal the pixel
dimensions at 720x576.
Instead, the calculation went something like this:
1. 720 (pixel width) * 1/1 (aspect ratio factor given on the command
line) / 576 = 5/4; store that value in the same variable that
previously held the aspect ratio factor given on the command line
2. 720 (pixel width) * 5/4 (the value from step 1) / 576 = 900/576
As stated initially this only happened when calling the function more
than once, which in turn only happened if a track order was
given. Unfortunately version 77 introduced sorting the tracks in the
output file by their type if no track order was given by the user,
which implicitly creates said track order, effectively triggering this
issue every time an aspect ratio factor was given.
That being said, even before version 77 it also always happened each
time `mkvmerge` was run from MKVToolNix GUI as the GUI always adds an
explicit track order.
On some compiler versions with some options the previous way seemed to
cause errors wrt. undefined references. So give the variable a fixed
place to live.
Otherwise `qmake` might add compiler flags that aren't understood by
the other one.
Actual issue that triggered this change: on Arch with Qt 6.5.2 no
matter what `CC`/`CXX` are set to, `qmake` always assumes `g++` & uses
`linux-g++` as the spec, adding `-mno-direct-extern-access`. `clang`'s
equivalent is `-fno-direct-access-external-data`, though.
The sampling frequency in cores & in EXSS sub-stream elements may be
different. If a core is present, its sampling frequency must be used
for timestamp calculation; otherwise timestamps as well as the track's
overall duration will be wrong.
Therefore look for a core within the first probing buffer. If one is
found, start processing from there instead of from the first header
found.
Fixes#3602
Currently for raw OBU bitstream input only.
The metadata is present in metadata OBUs with metadata_type = 4.
The format of the AV1 RPUs contains the size bytes, and consists of the original
RPU with shifted bytes, so it must be shifted back to the original payload first.
The method was found in existing vendor Linux kernel codebases.
