This is in line with other encoders, and is needed by the matroska muxer
to properly signal end trimming samples.
gaplessenc-pcm-to-mov-aac changes as the mov muxer now uses this information
when writing the edit list, so the shorter frame duration is not needed.
Signed-off-by: James Almer <jamrial@gmail.com>
They have been superseded by SSSE3. Notice that the functions removed
occupied 3424B with GCC and 6176B with Clang here, whereas
the SSSE3 functions replacing them occupy only 944B.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Superseded by SSSE3. By the way, the SSSE3 functions occupy
816B, but the functions removed now occupied 2304B with GCC
and 6512B with Clang (which inlined everything).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, only the fullpel test (i.e. the test without pixel
interpolation) has been tested at all.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Using ac3_fixed output was not enough as there's float to int conversion due to
the fact the mp3float decoder is used.
Instead of playing with codec combinations, just remove encoding from the test
altogheter. Mov supports muxing mp3 just fine.
Signed-off-by: James Almer <jamrial@gmail.com>
There's no guarantee the aac encoder will be bitexact in its output across platforms.
Use ac3_fixed instead of aac_fixed while at it, so the aac encoder can get improvements
without affecting this test.
Signed-off-by: James Almer <jamrial@gmail.com>
This filter uses a bunch of user32 functions, like GetMessage,
DispatchMessage, PeekMessage, GetWindowRect, etc.
This makes it clear that if the gfxcapture filter is built, we
need to link user32, if other components that depend on user32
would happen to be disabled.
Separately, if targeting UWP (with -DWINAPI_FAMILY=WINAPI_FAMILY_APP)
then these user32 APIs are unavailable. We have an existing
configure check for user32, checking for the GetShellWindow
function. This function isn't used by gfxfilter, but its
availability on UWP matches the other functions that gfxfilter
uses.
This fixes builds for UWP, by excluding the gfxcapture filter.
(This is somewhat ironic, as the gfxcapture filter uses
"winrt" APIs - but the implementation of the filter also relies
on lots of APIs that are unavailable in UWP/"winrt".)
Currently, such filter graphs just fail with a nebulous:
[fc#0 @ 0x2a7b3c0] [error] Error while filtering: Cannot allocate memory
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
The LAME attack detector high-pass filters at fs/4 before measuring attack
intensity, so the gentler attacks of tonal material (piano, plucked strings)
fall below the threshold and stay in long blocks, smearing pre-echo across the
quiet gap before the note. Relax the attack threshold for an isolated onset,
preceded by PSY_LAME_PE_GAP long frames with a near-silent pre-onset sub-block
(< PSY_LAME_PE_QUIET of the frame peak), so it switches to short blocks.
The TNS tool needed a full rewrite.
1.) PNS cannot be used with M/S or I/S or TNS. The coding tools
interfere with one another.
2.) The coeffs were windowed, which was wrong.
3.) The applied filter did not match what the spec required.
yuyvtoyuv422 reads the trailing odd V sample at src[2w+1], one byte further
than uyvytoyuv422, so the number of extra source bytes an odd width needs is
passed in per format (1 for UYVY, 2 for YUYV) and added to the stride.
uyvytoyuv420 and yuyvtoyuv420 are intentionally not added: their x86 mmxext
chroma averaging uses PAVGB rounding and so is not bit-exact with the C
reference, which truncates, so they cannot be verified this way.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The SIMD uyvytoyuv422 implementations only handled even widths correctly.
Add odd width and 1x1 entries so the trailing column handling is exercised
against the C reference.
An odd width reads one source byte more than 2*width, the V sample at
src[2w], so the stride is extended by one for odd widths.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The planes table stored a source stride smaller than the 2*width bytes a
packed UYVY line occupies (e.g. width 12 with stride 12), and the correct
stride for width 128 would be 256, which does not even fit the uint8_t
field. The test passed only because the oversized source buffer absorbed
the resulting out-of-bounds reads.
Derive srcStride from the width (2*width) instead of storing it, so each
line is passed its true size.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When writing edit lists and the last packet has skip samples side data to
report discard padding, for codecs that have a fixed frame size it's best to
always use the full packet duration to calculate track duration (and thus
bitrate in some cases) and let the edit list be the sole source of triming
information.
Signed-off-by: James Almer <jamrial@gmail.com>
This avoids having to declare it for every rule that generates
test input data, and adds such a missing tag for
tests/data/hls-seek.m3u8.
This fixes a case of a missing TAG for data/hls-seek.m3u8, which
caused it to be printed without a tag, like
" tests/data/hls-seek.m3u8", now printed as
"GEN tests/data/hls-seek.m3u8" as expected.
Add a muxer that wraps encoded image in the iTerm2 inline image protocol
(OSC 1337) so ffmpeg can play video directly in an iTerm2 terminal. The
output is a self-contained byte stream: it can be played live or saved
to a file and replayed with cat.
When writing the trailer for a RF64 WAV file, the ds64 chunk's 64-bit
version of the data chunk size incorrectly included the padding byte
that may have been added by ff_end_tag() for the data chunk.
Fix this by calculating the data chunk size before calling ff_end_tag().
The data chunk padding byte is only needed when the data is not already
a multiple of two bytes in length, which is fairly rare, requiring
something like mono 8-bit or 24-bit PCM with an odd number of samples to
trigger (and only with -rf64 auto or -rf64 always, neither of which is
enabled by default), so this bug is not likely to have affected many
real-world files.
Signed-off-by: Daniel Verkamp <daniel@drv.nu>
dst0/dst1 are uint16_t* allocated as width * sizeof(uint16_t), but
the memcmp at the end of check_add_left_pred_16 only compared `width`
bytes — missing the second half of each buffer. Same pattern used
correctly in tests/checkasm/huffyuvdsp.c (memcmp with width * sizeof()).
While at it, fix missing whitespace around & and || on the same line.
Fixes: fbe9148779 ("checkasm/llviddsp : add test for other dsp func")
Signed-off-by: Jeongkeun Kim <variety0724@gmail.com>
Use $(SRC_PATH), the source tree root, for consistent
repository-relative paths. SRC_DIR used before was undefined and this
macro only stripped leading /.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Otherwise remainder calculations will not work correctly if the input packets
have smaller frame sizes.
Should fix issue #23600.
Signed-off-by: James Almer <jamrial@gmail.com>
Lynne