Instead of calculating a^2, b^2, (a+b)^2 and (a-b)^2, calculate only
a^2, b^2 and 2*a*b in each iteration and derive the latter parts from
these three at the end.
Before and after:
A78
ac3_sum_square_bufferfly_int32_neon: 484.8 ( 2.00x)
ac3_sum_square_bufferfly_int32_neon: 468.2 ( 2.08x)
A72
ac3_sum_square_bufferfly_int32_neon: 793.6 ( 1.26x)
ac3_sum_square_bufferfly_int32_neon: 527.3 ( 1.92x)
Signed-off-by: Martin Storsjö <martin@martin.st>
Constify dstStrice argument of rgbx_to_nv12_neon_16_wrapper to be
compatible with other functions as used in function assignment.
Signed-off-by: Adam Lackorzynski <adam@l4re.org>
Signed-off-by: Martin Storsjö <martin@martin.st>
(setting to 100 as a reasonable compromise)
The change has caused regressions for many users and consumers.
Playlist reloads only happen when a playlist doesn't indicate that it
has ended (via #EXT-X-ENDLIST), which means that the addition of future
segments is still expected.
It is well possible that an HLS server is temporarily unable to serve
further segments but resumes after some time, either indicating a
discontinuity or even by fully catching up.
With a segment length of 3s, a max_reload value of 1000 corresponds to
a duration of 50 minutes which appears to be a reasonable default.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The issue is that this could consume gigabytes of VRAM at higher
resolutions for not that much of a speedup.
Automatic detection was not a good idea as we can't know how much
VRAM is actually free.
Just remove it.
BGR formats in Vulkan cannot be used in storage images, as the
pixel labels on storage images are always ordered as RGB, and
swizzling is not an option due to old hardware limitations.
This means that you must always use an RGB format and manually
swizzle when reading or writing to BGR images, or simply not use
a format in the shader itself.
This adds support for the latter.
&pl_alpha_overlay expects straight alpha, but the alpha output may be
premultiplied as a result of the target alpha mode (or in the absence of an
alpha channel). Fix it by requesting independent alpha explicitly when
blending.
There is no reason to only do this on the first input. It doesn't actually
matter for now given that we don't constrain the color space list, but it
may matter when that changes.
Signed-off-by: Niklas Haas <git@haasn.dev>
Each input is entirely independent and can have varying pixel formats,
color spaces, etc. To accomplish this, we need to make a full copy of the
format list for each subsequent input, rather than sharing the same ref.
Signed-off-by: Niklas Haas <git@haasn.dev>
Sponsored-by: nxtedition
Fixes a deprecation warning, and also fixes a bug where the depredated
skip_target_clearing option was not correctly mapped to the new API inside
libplacebo upstream.
Signed-off-by: Niklas Haas <git@haasn.dev>
Sponsored-by: nxtedition
These were introduced in libplacebo API version 220. We actually already
map the field by default, but deinterlacing was never enabled unless the user
explicitly forced it using extra_ops.
This filter already failed to compile on older versions, because of an
unconditional use of an API introduced in API version 220. Nobody noticed
this, so I conclude that it's safe to bump the required version by now.
External libraries are not components and so their CONFIG_ define
is in config.h.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It currently uses an intermediate int which wouldn't work
if linesize exceeded the range of int and inhibits compiler
optimizations. Also switch to pointer arithmetic and use
smaller scope.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
avctx->bits_per_raw_sample is always 10 or 12 here;
the checks have been added in preparation for making
bits_per_raw_sample user-settable via an AVOption,
but this never happened.
While just at it, also set unpack_alpha earlier
(where bits_per_raw_sample is set).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Using LONG_BITSTREAM_READER means that every get_bits() call
uses an AV_RB64() to ensure that cache always contains 32 valid bits
(as opposed to the ordinary 25 guaranteed by reading 32 bits);
yet this is unnecessary when unpacking alpha. So only use these
64bit reads where necessary.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Add RTP packetizer and depacketizer according to (most)
of the official AV1 RTP specification. This enables
streaming via RTSP between ffmpeg and ffmpeg and has
also been tested to work with AV1 RTSP streams via
GStreamer.
It also adds the required SDP attributes for AV1.
AV1 RTP encoding is marked as experimental due to
draft specification status, debug amount reduced
and other changes suggested by Tristan.
Added optional code for searching the sequence
header to determine the first packet for broken
AV1 encoders / parsers.
Stops depacketizing on corruption until next keyframe,
no longer prematurely issues packet on decoding if
temporal unit was not complete yet.
Change-Id: I90f5c5b9d577908a0d713606706b5654fde5f910
Signed-off-by: Chris Hodges <chrishod@axis.com>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
If there's ever a rework of the AAC encoder, it won't start from here.
The codec, with all its oddities and tweaks needed to acheive good quality
has strayed far from the academic work upon which this coder was based on.
Its been 20 years since this paper was released, and no known existing
implementations, open-source or proprietary that we know of, are based on it.
The LTP profile of AAC is... terrible.
It was an early 90's attempt at bridging the gap between speech
codecs and general purpose codecs. It did so by trying to exploit the fact
that most speech patterns are regular.
Unfortunately, it went about it the same way as AAC Main, by taking
the previous frame's samples, modifying them through an LPC filter,
transforming them back using a forward MDCT, putting the output
coefficients back into the current frame, and using delta coding.
But once again, they ignored basic mathematics and MDCT leakage.
Thankfully, because AAC LTP is meant to operate at very low bitrates,
the extreme quantization results in most leakage being irrelevant.
Unfortunately, the result is that the output sounds pretty much
terrible regardless of whether LTP is enabled or not.
This was the first attempt at trying to couple speech coding into AAC.
No, the second attempt did not succeed either.
Nnnneither did the third. Or fourth.
For the fifth one, they literally just jammed a speech codec into AAC
with USAC once they saw Opus do it.
Just drop support for encoding AAC LTP. It was always experimental
to begin with.
The Main profile of AAC is... terrible.
It enables the use of delta coding across coefficients of two frames
to try to increase compression, and it enabled one more pole for TNS
filters.
What the AAC authors failed to take into account were basic
mathematics, as MDCT leakage (e.g. the spread of each frequency when
represented in a discrete spectrum) is significant in most audio codecs.
This leads to huge variations between each frame, basically rendering
prediction completely pointless.
In fact, enabling AAC-Main prediction does not, in general, even recoup
the metadata losses from signalling the profile and prediction properties
in the first place. So you lose efficiency by using AAC Main.
The rumor is that it was put in the AAC spec for patent reasons, though
patent-wise, it has about as much use as a patent for a bicycle designed
for use by snakes.
The only other thing AAC Main changes is it permits 3-pole TNS filters.
When AAC's bands are absolutely tiny, except for very high frequency bands,
where you're likely to use PNS instead.
Just get rid of it.
This changes the default behaviour of ffmpeg where content-type headers
on an input gives an absolut probe score (of 75) to instead give a bonus
score (of 30). This gives the probe a better chance to arrive at the
correct format by (hopefully) giving a large enough bonus to push edge
cases in the right direction (MPEG-PS vs MP3, I am looking at you) while
also not adversly punishing clearer cases (raw ADTS marked as
"audio/mpeg" for example).
This patch was regression tested against 20 million recent podcast
submissions (after content-type propagation was added to
original-storage), and 50k Juno vodcasts submissions (dito). No adverse
effects observed (but the bonus may still need tweaking if other edge
cases are detected in production).
When an Info-tag is present, marking initial and trailing samples as
padding, those samples should not be included in the calculation of track
duration.
This solves a surprising user experience where converting a WAV->MP3->WAV,
ffprobe will show the duration of the mp3 as slightly longer than both the
input and the output.
As a result, the estimated duration and imprecise seek-results of some
FATE-tests have been updated.
