Better to be safer than usual, since the signal contains literally no
audible data, and is so expensive to code, the coder itself is very
reluctant to do so except at very high rates.
The iDCT located its tile by linearly scanning the tile column/row start
tables. The APV tile grid is uniform-sized columns and rows with a single
remainder tile at each edge, so the tile index is just the luma position
divided by the (constant) first step, clamped to the last tile. Single
column/row grids have no step to read and resolve to index 0.
apv_read_vlc() dispatched on the three APV code layouts with two data-
dependent branches and, for the long form, a second show/skip. The longest
legal code plus its optional sign bit fits in a single 32-bit window, so
compute all three candidate (value, length) pairs unconditionally and
select with no divergent branches: one show_bits(32) and one skip_bits per
code. apv_read_vlc_sign() additionally folds the trailing sign bit into the
same window, removing the separate get_bit() refill that DC and AC levels
did. Clamps on the long-form length guard corrupt streams without affecting
legal decodes.
The entropy pass wrote each decoded coefficient into the output image as
16-bit scratch, then the iDCT pass read it back, dequantised it and
overwrote the same texel with the final pixel. Routing the coefficients
through the image couples the two passes to the image layout and forces
the entropy shader to address the descriptor-indexed image.
Add a dedicated device-local int16 buffer instead: the entropy shader
writes coefficients into it (one plane per component, MB-aligned coded
size) and the iDCT reads them, so the image is written exactly once, by
the iDCT. The buffer is zero-filled before the entropy dispatch so blocks
with no coded coefficients read as zero, and the decode->iDCT hand-off
becomes a buffer barrier. The output image is still cleared so any padding
the iDCT does not cover stays zero.
DCs can go over int16_t, and when it does, dc_add wraps, so the wrong sign
is reported, which causes errors when decoding more DCs.
Do the prediction in int and narrow to int16 only at store time. The
read_ac_vals() sign change is cosmetic (the value is only ever 0/-1, and
the old code already widened it).
Uses the gather shader from the APV encoder to copy the packet data on
the GPU with a second pass.
Replace all of that with a seg_gather compute dispatch in the
same submission as the encode. It packs the per-slice slots tight and in
order into a contiguous host-visible buffer, so the final packet is just
the sum of the per-slice sizes and the gathered buffer is handed straight
to pkt->buf with no extra submit, no copy, no CPU involvement.
The slots are sized with the version-4 worst-case formula (the realistic
lossless bound, ~17x tighter than the version-3 budget this encoder never
approaches; the emitted bitstream version is unchanged) and rounded down
to a 16-byte multiple so the gather reads them with aligned wide loads.
Removes the transfer queue family, its exec pool, and the buf_regions
scratch array.
For SDR codecs, we have zero dependency on the images we decode. So using
the same scheme as the software code led us to needing unnecessarily to block
on a semaphore wait.
Instead of doing this, just make the imageviews a dependency of the exec context.
Saves on CPU, matters particularly for very fast decoding speeds.
FFv1 gets a slight workaround that's still better than what we did before.
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>
Lynne