avformat/wavdec: increase requested probe score for codec probe Codec probing was primarily added to the wav demuxer to support DTS-in-wav files, but DTS probing functions return AVPROBE_SCORE_EXTENSION+1, so we can be a bit more strict with the required score. This fixes MP3 misdetections for some wav files. Fixes ticket #11581. Signed-off-by: Marton Balint <cus@passwd.hu> (cherry picked from commit ce01c7fb58597f525e130f47a13ff77f1db62bf4)
lsws/ppc/yuv2rgb_altivec: Fix build in non-VSX environments with Clang Add a check for the existence of the vec_xl() function. Clang provides the function even with VSX not enabled. (cherry picked from commit 30a8641465f7b7923e92d8724ef6a595fccb9e58) Signed-off-by: Brad Smith <brad@comstyle.com>
configure: Improve the check for the rsync --contimeout option Traditionally, macOS has shipped an old version of rsync that lacked support for this option, hence this check (added in a8b3f0c5cf548f654e30c981988bb71981a3f8d3). However, in macOS 15.x, Apple have switched to providing rsync as a different tool, openrsync. The version of openrsync in at least macOS 15.2 does include "[--contimeout]" (note the lack of "=" after the option), in the output of "rsync --help", but when used, the tool errors out with "rsync: --contimeout=60: unknown option". So apparently the tool erroenously lists the option as supported, while it really isn't. The original rsync tool (with a new enough version) prints "--contimeout=SECONDS" in the output of "rsync --help". It is unclear which version of openrsync Apple are shipping; the latest upstream openrsync from OpenBSD does support the option and includes "[--contimeout=seconds]" in the output of "--help", and older versions don't seem to include the option as listed at all. Therefore, check for "--conntimeout=" with the "=", this should properly detect both new enough rsync and openrsync. This fixes running "fate-rsync" on macOS 15.x. Signed-off-by: Martin Storsj? <martin@martin.st> (cherry picked from commit 3cd4e8470a1ef82223d124523f8219691dfefb60)
rtmpproto: Avoid rare crashes in the fail: codepath in rtmp_open When running the cleanup in rtmp_close on failures in rtmp_open, we can in rare cases end up using rt->playpath, assuming that it is still set. The crash could happen if we hit the fail codepath in rtmp_open while publishing (rt->is_input == 0) with rt->state set to a value > STATE_FCPUBLISH. This would normally not happen while publishing; either we have an error (and rt->state <= STATE_FCPUBLISH) or we reach rt->state = STATE_PUBLISHING, and then we also return successfully from rtmp_open. The unexpected combination of states could happen if the server responds with e.g. "NetStream.Play.Stop" while expecting "NetStream.Publish.Start"; this sets rt->state to STATE_STOPPED, which also fulfills the condition "> STATE_FCPUBLISH". We don't need to free the rt->playpath/tcurl/flashver strings here; they're handled via AVOption, and thus are freed automatically when the protocol instance is freed (that's why they aren't freed manually within the rtmp_close function either). We also don't need to free the AVDictionary with options; it's owned by the caller. A smaller fix would be to just call rtmp_close before freeing the strings and dictionary, but as we don't need to free them at all, let's remove that redundant code. Signed-off-by: Martin Storsj? <martin@martin.st> (cherry picked from commit 8f4819ce01584e0858fdc312aa8a17c55e350a92)
lavc/aarch64: Fix ff_pred16x16_plane_neon_10 Fix test failure on aarch64: ./tests/checkasm/checkasm --test=h264pred 367840 Signed-off-by: Peng Bin <pengbin@visionular.com> Signed-off-by: Martin Storsj? <martin@martin.st> (cherry picked from commit 72a3656e8468a394373b6397aacc906d7f7794c2)
lavc/aarch64: Fix ff_pred8x8_plane_neon_10 Fix test failure on aarch64: ./tests/checkasm/checkasm --test=h264pred 479612 The mismatch between neon and C functions can also be reproduced using the following bitstream and command line. wget https://streams.videolan.org/ffmpeg/incoming/intra8x8pred_10bit.264 ./ffmpeg -cpuflags 0 -threads 1 -i intra8x8pred_10bit.264 -f framemd5 -y md5_ref ./ffmpeg -threads 1 -i intra8x8pred_10bit.264 -f framemd5 -y md5_neon Signed-off-by: Bin Peng <pengbin@visionular.com> Signed-off-by: Martin Storsj? <martin@martin.st> (cherry picked from commit decc9e643cc3ac5537f42b465e2637fbefbf41cc)
vp9: recon: Use emulated edge to prevent buffer overflows The arm/aarch64 horizontal filter reads one additional pixel beyond what the filter uses. This can become an issue if the application does not allocate larger buffers than what's required for the pixel data. If the motion vector points to the bottom right edge of the picture this becomes a read buffer overflow. This triggers segfaults in Firefox for video resolutions which result in a page aligned picture size like 1280x640. Prevent this by using emulated edge in this case. Fixes: https://bugzilla.mozilla.org/show_bug.cgi?id=1881185 Signed-off-by: Janne Grunau <janne-ffmpeg@jannau.net> Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com> (cherry picked from commit 060464105bdca82b8cfb91c7a6fb56df4c7cd9d0)
arm: vp9mc: Load only 12 pixels in the 4 pixel wide horizontal filter This reduces the amount the horizontal filters read beyond the filter width to a consistent 1 pixel. The data is not used so this is usually not noticeable. It becomes a problem when the application allocates frame buffers only for the aligned picture size and the end of it is at a page boundary. This happens for picture sizes which are a multiple of the page size like 1280x640. The frame buffer allocation is based on its most likely done via mmap + MAP_ANONYMOUS so start and end of the buffer are page aligned and the previous and next page are not necessarily mapped. This mirrors the aarch64 change. Signed-off-by: Janne Grunau <janne-ffmpeg@jannau.net> Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com> (cherry picked from commit f3662562156c9b908588b1e58e4203fd09217cb6)
aarch64: vp9mc: Load only 12 pixels in the 4 pixel wide horizontal filter This reduces the amount the horizontal filters read beyond the filter width to a consistent 1 pixel. The data is not used so this is usually not noticeable. It becomes a problem when the application allocates frame buffers only for the aligned picture size and the end of it is at a page boundary. This happens for picture sizes which are a multiple of the page size like 1280x640. The frame buffer allocation is based on its most likely done via mmap + MAP_ANONYMOUS so start and end of the buffer are page aligned and the previous and next page are not necessarily mapped. Under these conditions like seen by Firefox a read beyond the end of the buffer results in a segfault. After the over-read is reduced to a single pixel it's reasonable to use VP9's emulated edge motion compensation for this. Fixes: https://bugzilla.mozilla.org/show_bug.cgi?id=1881185 Signed-off-by: Janne Grunau <janne-ffmpeg@jannau.net> Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com> (cherry picked from commit 430c38f698a65d597e863330810b05e083682be6)
avfilter/f_loop: fix aloop activate logic The logic did not follow the documented behaviour and that caused skipping of some audio in the loop and in the leftover buffer. Example command line which should produce a smooth sine wave for the whole duration of the output: ffmpeg -f lavfi -i "sine=r=48000:f=480:d=4" -af "aloop=loop=4:start=48000:size=48000" out.wav Fixes ticket #11283. Signed-off-by: Marton Balint <cus@passwd.hu> (cherry picked from commit fe18ed3f2a9221af0beaec7b04b7804849db1f2f)
avfilter/f_loop: fix length of aloop leftover buffer If the audio loop stops inside an audio frame, the leftover buffer contains the end of the frame, which is not looped. The length supposed to be the part which was not written to the loop buffer, so we need to drain exactly that number of bytes from the leftover buffer. Signed-off-by: Marton Balint <cus@passwd.hu> (cherry picked from commit b33a59416072ad31a5840f33f9975d88acf45add)
avutil/wchar_filename: re-introduce explicit cast of void* to char*
Fixes compile error on windows with decklink:
In file included from ./libavformat/os_support.h:175,
from ./libavformat/internal.h:30,
from libavdevice/decklink_common.cpp:25:
./libavutil/wchar_filename.h: In function 'int wchartocp(unsigned int, const wchar_t*, char**)':
./libavutil/wchar_filename.h:59:32: error: invalid conversion from 'void*' to 'char*' [-fpermissive]
59 | *filename = av_malloc_array(num_chars, sizeof **filename);
| ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| void*
Regression since e9e8bea2e79bc3c481a6f81f75f6c871e3e0f367.
Fixes ticket #11103.
Signed-off-by: Marton Balint <cus@passwd.hu>
(cherry picked from commit 9b0128aa766221f8a32e13cf3c1d3e6d75a2d829)
avcodec/libx265: unbreak build for X265_BUILD >= 213 Earlier, x265 made an API change to support alpha and other multiple layer pictures. We added guards to accommodate that in 1f801dfdb5 They have now reverted that API change in https://bitbucket.org/multicoreware/x265_git/commits/78e5b703b1 Updated our wrapper guards to unbreak build again.