Remove this from the 1.3.x release branch since it's an API
change. Backward-compatible, but still. This change should
instead be released as part of flac 1.4.0.
This reverts commit 4ca0d85c5d.
Signed-off-by: Martijn van Beurden <mvanb1@gmail.com>
Remove this from the 1.3.x release branch since it's an API
change. Backward-compatible, but still. This change should
instead be released as part of flac 1.4.0.
This reverts commit 19a0e99ac3.
Signed-off-by: Martijn van Beurden <mvanb1@gmail.com>
When verify mode is enabled, once decoder flags end of stream,
encode processing is considered complete.
CVE-2021-0561
Signed-off-by: Ralph Giles <giles@thaumas.net>
Previously the FLAC__AVX2_SUPPORTED macro is defined, but actually
AVX2 functions are not used when built with clang because flac only
uses them when FLAC__AVX_SUPPORTED macro is set.
Signed-off-by: NotTsunami
This is required on windows, but not on other platforms.
It needs to be the default `Debug` target, rather than
`Release` to match CMAKE_BUILD_TYPE, for the $TARGET_FILE
mapping to produce the correct path.
See https://gitlab.kitware.com/cmake/cmake/-/issues/20283
The main test harnesses are written in unix shell script, so
they don't work on windows. A stanza was added to the cmake
config to skip all tests there to get a green build.
This is misleading, since no testing was done at all on Windows.
Instead, construct a separate set of tests on non-unix platforms,
calling the two api test programs, which of necessity are
compiled executables. Also invoke the two front-end programs
with just the --help switch to verify they at least start.
Thanks to Marcus Asteborg for the suggestion.
Failures within multi-line commands aren't detected properly
in the windows runner environment. Therefore split each
line into a separate step for the cmake build.
Use the `working-directory` key to mark the build subdir without
having the prepend a `cd` command.
Make use of the available builders for Microsoft Windows build
converage.
Unfortunately this job reports finding no tests to run, despite
being identical to other builds. Worse, this is not reported as
an error.
Windows doesn't have a package manager like linux and macos, so
until we figure out how to build and cache the ogg dependency
for the windows job, just skip ogg support.
The test harnesses log details to files during the run,
which is helpful when debugging issues which are only
reported as a run failure in the console output.
When the build job fails, upload an artifact consisting
of a zipfile with all the log files from the build,
so users can investigate test failures in ci more
easily.
Define builds for gitlab's continuous integration runners so we
some feedback on versions of the code hosted there, particularly
https://gitlab.xiph.org/xiph/flac.
Build with GNU Autotools, with CMake+ninja, and verify
the Makefile.lite build.
This uses the same Debian-based docker.io/library/gcc:9 container
image we use for most of the codec projects. That container
doesn't specify an unprivileged user so that we can install
packages.
However, some of flac's file-creation tests must be run as an
unprivileged user who owns the source tree. We therefore
create a user account and use `su` to run the tests.
In the case of the autotools job, `make distcheck` unpacks
the packaged source, so this takes care of ownership.
In the case of the other jobs, we must `chown` the entire
checkout and complete the build as the unprivileged user.
Another way to address this would be to define a custom
container image with the prerequisites installed before
switching to an unprivileged user for the entire build.
The current approach was simpler to get working.
Details:
- During the installation of the package with CMake, it stops
(via fail) when doc files should be copied. It was caused by
changing current binary to current source CMake directory.
Details:
- When building with CMake, pkg-config files flac.pc and flac++.pc
are not updated with Version information. This causes a failure
when running a configure script in opus-tools
(https://github.com/xiph/opus-tools).
Note that OGG_PACKAGE is set to "ogg" exactly as in the configure.ac,
but it is only set when the building explicitly with libogg.
Don't attempt to attach failed metadata objects. This also avoids
clobbering the error flag if attaching the objects should succeed.
There may still be problems later, for example calling _delete()
on a possibly null metadata object pointer, but this it at least
and improvement in the compromise between error handling and
readability in C.
Signed-off-by: Ralph Giles <giles@thaumas.net>
Run the CI on PRs and once a month (to detect failures due to updated images or dependencies).
Signed-off-by: Erik de Castro Lopo <erikd@mega-nerd.com>
Signed-off-by: Ralph Giles <giles@thaumas.net>
The following is the error from compiler:
Assembling cpu_asm.nasm
cmd.exe /D /C "C:\Users\appveyor\AppData\Local\Temp\1\tmp62cb769c16c04b79a2f73246c8ccf95a.cmd"
"/NASM/nasm.exe" -o "FLAC-asm.dir\Release\cpu_asm.obj" -fwin32 -I"C:\project\lib\flac\include\\" -I"C:\project\lib\flac\_build\Win32\\" -D"CMAKE_INTDIR="Release"" -dOBJ_FORMAT_win32 "C:\project\lib\flac\src\libFLAC\ia32\cpu_asm.nasm"
C:\project\lib\flac\src\libFLAC\ia32\cpu_asm.nasm:34: fatal: unable to open include file `nasm.h'
Closes#220.
Signed-off-by: Ozkan Sezer <sezeroz@gmail.com>
Because the compression ratio was calculated before processing
the input of the last frame, it did not include the size of this
last frame. This patch moves the calculation of the compression
ratio after the new input has been processed. Now the compression
ratio on very small files is correctly displayed.
Theoretically, when a rice parameter of 0, 24-bit samples, fixed
predictor with order 0, no rice escaping and a blocksize of 65536
is chosen, a subframe could be up to 2^24*65536 = 1 terabyte in
size. While this obviously should never happen, the analyse
function should be able to debug such a case.
A bug beginning in gcc version 9.2 causes strings to get incorrectly
stripped when passed directly to memcmp with a zero first byte (1).
This bug causes flac -t to fail on any .flac file with a md5 checksum
beginning in 00. To work around this bug, the FLAC__byte type is used
for an empty md5 sum to prevent a string from being stripped, which
is backwards compatible and avoids compile-time checks. This was
initially reported back in March 2020, but has seen more light since
Ubuntu 19.10 and up ship with gcc 9.2 as the default compiler. A
patch has been merged into the master gcc branch (2), but has not
been included in any versions as of this commit date.
The initial reporter provided a patch in their bug report (3), which
is included in this PR with authorship attributed to the reporter.
(1) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189
(2) https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=d5803b9876b3d11c93d1a10fabb3fbb1c4a14bd6
(3) https://sourceforge.net/p/flac/bugs/478/Closes#192.
There is a small typo in oss-fuzz/fuzzing/datasource/datasource.hpp.
Should read `operator` rather than `opertator`.
Signed-off-by: Ralph Giles <giles@thaumas.net>
* Improve CPU features detection
CMAKE_SYSTEM_PROCESSOR is pretty useless (e.g. when compiling with
MSVC ARM64 toolchain and Ninja still returns system processor).
* Don't build src/utils targets by default
Fix compilation for UWP platform.
* Add more Visual studio Git ignore patterns
* Autogenerate Doxygen docs
> if the partition order is zero, n = frame's blocksize - predictor order
> else if this is not the first partition of the subframe,
> n = (frame's blocksize / (2^partition order))
> else n = (frame's blocksize / (2^partition order)) - predictor order
if the partition order is zero, then partition_number can only be zero
if the partition order is zero, then
(frame's blocksize / (2^partition order))
is (frame's blocksize / 1) == frame's blocksize
Ralph Giles