Use functions deltacast_get_frame_{mode,name} instead and just a
skeleton mode metadata hard-coded - compute what is needed/possible
(name, 1001-variant).
functional changes:
- 1080p50 is now possible (24p format set incorrectly before).
- vcap: metadata for American formats are corretly set (clock_system
was not taken into accout before and European was set, leading in slightly
incorrect metadata - 30 FPS instead of 29.97)
- vcap: available modes has now different order (American-style ordered
first - FPS is slightly smaller) + 2 small typos ("1Hz" and "59.97")
Otherwise this is roughly a refactor.
Some quite old GCC (7.5 in U18.04) don't have c23 function
attributes. While this is a bit old distro but the feature is quite new
according to C standard so use GCC attribute for now (we will almost
certainly compile with clang/GCC in Linux).
compute SHA256 checksums for builds
this is useful at least for 2 reasons:
1. user can ensure that the build comes really from the CI (isn't
tampered)
2. can identify or match version with appropriate action run (the $VERSION
is usually always "continuous", except for releases)
The sha256 sum is currently only show in the protocol, not uploaded
to GH releases - this doesn't seem to be needed because GH currently
already prints the checksum by itself on the download (releases) page.
Skip computing checksum in Win when uplad-artifact is used - the zip
is actually created by the Action so we cannot compute the checksum
on it.
/sbin/sha256sum is not present in CI mac workers for some reason
Remove commands that actually do nothing because uv-qt.exe is installed
by make install and the contents of bin/ subdirectory is not copied
"as is" as the command seem to imply.
+ use $(TARGET) in Makefile instead of bin/uv (which will be bin/uv.exe
in MSW but obviously it worked even without the extension)
Althought there are in deltacast_frame_modes the modes for eg. 1080p29
and 1080p30 listed separately, both point to the same video standard
mode VHD_VIDEOSTD_S274M_1080p_30Hz. This is perhaps taken orignally from
some SDK samples, anyways. The clock system seem to be required to set
separate from the video standard. This was hard-coded in init to 1/1.
There are (less common) compressions, that basically takes default
parameters so it is not necessary to keep record for them separately.
The struct, however, is used as the list of available/supported
compressions so now iterating over all UG codecs and including codecs
with the predicate !get_ug_to_av_codec(ug_codec).
Mostly just refactor, just compression_priority has been changed for those
that had 5xx values (J2K, HFYU, FFV1) to `500 + codec_id` - assuming that
those should have distinct values but the actual order doesn't matter.
Unsure if it didn't work ever or was broken at some time point but it
haven't worked just now. As only "dav1d" was preferred for AV1 and this
is selected by default, no functional change actually as for now.
It was used als for ug_codec<->av_codec, which is unneeded, already
done in lavc_utils. This also causes that every new codec must have been
added there.
Keep just the preferred_encoder part.
install -D in coreutil 8.22 (CentOS 7) didn't have the same semantic
as later versions if specified together with --target-dir (creating the
target dir). Syntax `install -D -m 644 x dst/x` (specifying dstfile name)
would also work as one command as well.
