The drawvg filter can draw vector graphics on top of a video, using libcairo. It
is enabled if FFmpeg is configured with `--enable-cairo`.
The language for drawvg scripts is documented in `doc/drawvg-reference.texi`.
There are two new tests:
- `fate-filter-drawvg-interpreter` launch a script with most commands, and
verify which libcairo functions are executed.
- `fate-filter-drawvg-video` render a very simple image, just to verify that
libcairo is working as expected.
Signed-off-by: Ayose <ayosec@gmail.com>
fate-lavf-flv is dependency of fate-api-seek, but the fate-api-seek is
setting CMP = null, which affects fate-lavf-flv. Reset CMP value to
expected by the flv test and use default diff compare.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
The last 3dnow functions have been removed in commit
5ef613bcb0. So remove 3dnow
from configure; the only thing kept is that --disable-amd3dnow
is still accepted, but no longer advertised by --help.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Supresses:
warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)
Also drop L, as shift will never exceed 31.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
This is how images encoded with specific transfer function should be
viewed. Image viewers that doesn't support named trc metadata, will
fallback to simple gAMA value and both of those cases should produce the
same image apperance for the viewer.
Fixes: https://github.com/mpv-player/mpv/issues/13438
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
The mismatch between neon and C functions can be reproduced
using the following bitstream and command line on aarch64 devices.
wget https://streams.videolan.org/ffmpeg/incoming/replay_intra_pred_16x16.h264
./ffmpeg -cpuflags 0 -threads 1 -i replay_intra_pred_16x16.h264 -f framemd5 -y md5_ref
./ffmpeg -threads 1 -i replay_intra_pred_16x16.h264 -f framemd5 -y md5_neon
Signed-off-by: Bin Peng <pengbin@visionular.com>
Previously, the LC3 encoder only accepted planar float (AV_SAMPLE_FMT_FLTP).
This change extends support to packed float (AV_SAMPLE_FMT_FLT) by properly
handling channel layout and sample stride.
The pcm data pointer and stride are now calculated based on the sample
format: for planar, use frame->data[ch]; for packed, use frame->data[0]
with channel offset. The stride is set to 1 for planar and number of
channels for packed layout.
This enables encoding from common packed audio sources without requiring
a prior planar conversion, improving usability and efficiency.
Signed-off-by: cenzhanquan1 <cenzhanquan1@xiaomi.com>
1. Adds support for respecting the requested sample format. Previously,
the decoder always used AV_SAMPLE_FMT_FLTP. Now it checks if the
caller requested a specific format via avctx->request_sample_fmt and
honors that request when supported.
2. Improves planar/interleaved audio buffer handling. The decoding
logic now properly handles both planar and interleaved sample
formats by calculating the correct stride and buffer pointers based
on the actual sample format.
The changes include:
- Added format mapping between AVSampleFormat and lc3_pcm_format
- Implemented format selection logic in initialization.
- Updated buffer pointer calculation for planar/interleaved data.
- Maintained backward compatibility with existing behavior.
Signed-off-by: cenzhanquan1 <cenzhanquan1@xiaomi.com>
Add dtls_active flag to specify the dtls role.
Properly set the send key and recv key depends on DTLS role:
As DTLS server, the recv key is client master key plus salt,
the send key is server master key plus salt.
As DTLS client, the recv key is server master key plus salt,
the send key is client master key plus salt.
Signed-off-by: Jack Lau <jacklau1222@qq.com>
If using the delay_moov flag in combination with hybrid_fragment
(which is a potentially problematic combination otherwise - the
ftyp box does end up hidden in the end), then we need to flush
twice to get both the moov box and the first fragment, if the
file is finished before the first fragment is completed.
If samples were available when the moov was written, chunking
for those samples has been done already, which has to be reset
here.
This is the case when not using empty_moov, when the moov box
describes the first fragment - this case was accounted for already.
But if using the delay_moov flag, then those samples also were
available when writing the moov, so chunking for them has already
been done in this case as well.
Therefore, always reset chunking here (it should be harmless to
always do it), and update the comment to clarify the cases
involved here.
When calculating the max size of an output PNG packet, we should
include the size of a possible eXIf chunk that we may write.
This fixes a regression since d3190a64c3
as well as a bug that existed prior in the apng encoder since commit
4a580975d4.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
When splitting a 5 lines image in 2 slices one will be 3 lines and thus need more space
Fixes: Assertion sc->slice_coding_mode == 0 failed at libavcodec/ffv1enc.c:1668
Fixes: 422811239/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FFV1_fuzzer-4933405139861504
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
We do not support larger tiles as we use signed int
Alternatively we can check this in apv_decode_tile_component() or init_get_bits*()
or support bitstreams above 2gb length
Fixes: init_get_bits() failure later
Fixes: 421817631/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APV_fuzzer-4957386534354944
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>