This assertion was too severe and deserve actual runtime handling.
The `pcr_helper` should just fail in case of inconsistent
input/output. This can happen in various case such as bogus encoder or
simply internal error in the `pcr_helper` code.
This patch is making sure the `pcr_helper` user can disable it in case
of failure.
Refs #27730
This patch make it possible to disable the PCR forwarding
synchronisation algorithm as it is still prone to bugs and will likely
fail on wrong encoder outputs.
The PCR forwarding is still enabled by default.
Refs #27730
The cp call is broken:
cp x262/vlc_build/x264.h x262/vlc_build/x262.h
cp: cannot stat 'x262/vlc_build/x264.h': No such file or directory
make: *** [../src/x262/rules.mak:37: .x262] Error 1
x264.h isn't generated inside the build directory (x262/vlc_build), but
exists in the x262 source directory. The install rules also install it
from the source directory. Therefore, copy it from and to the source
dir, not the build dir.
Regression from 697a2fcda3.
The sed call tried to glob the Makefile and *.h files in the contrib
directory, instead of the x262 source directory:
sed -i -e 's/x264_config/x262_config/g' *.h Makefile x262/*.c
sed: can't read *.h: No such file or directory
make: *** [../src/x262/rules.mak:31: .x262] Error 2
Regression from 637d00420f.
The test creates a libvlc instance with a medialibrary and check that
the medialibrary can generate a mock thumbnail for a given mock:// URL
with different parameters.
Multiple improvements can be done from here: in particular, the
medialibrary will insist in loading its discovery modules, whereas we
only need to check whether the thumbnailing work in this current test.
Some work needs to be done to evaluate whether it's interesting enough
to cut those discovery modules out for this test or extend the scenario
to other cases like testing those discovery modules.
Regression testing from #27749
When calling VLC_ML_NEW_EXTERNAL_MEDIA or VLC_ML_NEW_STREAM, the
medialibrary must be initialized because the priority context is
acquired, just list for the VLC_ML_GENERATE_THUMBNAIL request.
Ensure the medialibrary is initialized at the same location as other
queries like this.
The picture was referenced on the ThumbnailerCtx object, which release
it whenever one is not nullptr. However, after the changes in !3088,
commit 2ea2c7eb19, the release policy for
the picture being exported has been fixed to ensure the picture is
consumed whatever the conversion case.
Ensure the picture won't be released twice by swapping it from the
ThumbnailerCtx object before exporting.
Fix#27749
The generated .pc files do not contain -I${includedir}, only
-I${includedir}/$QTMODULE. This is because QMake finds out that our
standard contrib include path is already in the QMAKE_DEFAULT_INCDIRS
list.
When this includepath is not forced externally through some script and
only the .pc file flags are used for the qt plugin, the build fails:
In file included from /vlc/contrib/x86_64-linux-gnu/include/QtWidgets/QApplication:1,
from ../modules/gui/qt/vlc-qt-check.cpp:26:
/vlc/contrib/x86_64-linux-gnu/include/QtWidgets/qapplication.h:43:10: fatal error: QtWidgets/qtwidgetsglobal.h: No such file or directory
43 | #include <QtWidgets/qtwidgetsglobal.h>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fixes#27588.
It's only used when the file cannot be mapped in memory.
This was not a real implementation of pread. As the comment suggests, the
original offset was not respected. But we don't care in this case as we want to
read the whole file from start to end.
It is now a cancelation point. We can't cancel during the duration of the
ReadFile call, but at least we cancel when it's done even if the whole file is
not read.
According to the manpage, jrand48() must return a signed long integer
uniformly distributed over the interval [-2^31, 2^31).
The old implementation first computed iterate48(), which returns a
positive 48-bit integer (as 'uint64_t', then cast to 'int64_t'). Once
right-shifted by 16 bits, the result is guaranteed to be a 32-bit
positive integer as 'int64_t'.
It is then (implicitly) cast to 'long' to match the return type.
When the 32th bit is 0 (i.e. the value fits in 31-bit), then everything
is ok. However, when the 32nd bit is 1, then there are two cases (which
are both incorrect):
- if the 'long' type is 32-bit on the platform, then conversion from
'int64_t' to 'long' is undefined;
- if the 'long' type is more than 32-bit, then the resulting value will
be a positive integer in the interval [0, 2^32), whereas jrand48()
must return a value in the interval [-2^31, 2^31).
With a proper C11 compiler we don't need this. Either they activate C11
things in the compiler which should be there anyway. Or in the SDK
which is __USE_MINGW_ANSI_STDIO for C99 and nothing else.
Allocate a new picture by forwarding the host filter whenever the last
filter of the cvpx chain asked a new video buffer.
The host filter and last CVPX buffer are supposed to have the same
format, but the host filter might play a different role in its parent
filter chain than the requesting filter. In particular, filter chain
will try to detect the last filter, which can only work for filters
belonging to the chain.
Fix a crash when plugging a chain NV12->RV32 which creates first a
converter (cvpx) CVPX_NV12 -> CVPX_I420 -> I420 and then another
converter I420 -> RV32 filter, leading to the cvpx filter allocating
the wrong type of output frame.
Fixes#27721
Alaric Senat
Prince Gupta
Yann Lochet
Steve Lhomme
Johannes Kauffmann
Alexandre Janniaux
Francois Cartegnie
Tristan Matthews
Romain Vimont
Claudio Cambra
Thomas Guillem