(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.
rtmp_write is used both for writing outputs as a server. The
rt->listen flag determines which mode we're running in.
Previously, when running as a server, the message stream id would
always be set to 0 for media/metadata messages. This is surprising
given that we have both responded to "createStream()" with a value
of 1 and sent a "Stream Begin 1" to the client. Furthermore, some
client libraries (Red5) seem to trip up on receiving
"@setDataFrame" on stream 0 (and may be correct to assume that
this message would be sent on stream 1).
Forward errors from `avio_read` directly. When `avio_read` sees EOF before
expected bytes can be read, consistently return `AVERROR_INVALIDDATA`
We used to return `AVERROR(AVERROR_INVALIDDATA)` when failing to read
metadata block headers. `AVERROR_INVALIDDATA` is already negative, so
wrapping in `AVERROR` leads to double-negation.
We used to return `AVERROR(EIO)` when failing to read extended metadata.
However, many times, the IO-layer is not at fault, the input data is simply
corrupted (truncated), so we return `AVERROR_INVALIDDATA` here as well.
---
Tomas: changed to use AVERROR_EOF
WMA files that fail to decode due to incoherent block lengths and
frame lengths currently result in a "Operation not permitted".
After this change, they will instead result in "Invalid data found
when processing input".
Several other error cases are also changed from returning -1.
As we change the error propagation logic in wma_decode_frame and
wma_decode_superframe, previous occurrences of returning
AVERROR_INVALIDDATA are also affected by this. This includes
"total_gain overread" and a "channel exponents_initialized" check.
---
Tomas: changed some -1's to AVERROR_INVALIDDATA
Currently, a prematurely broken connection normally leads to the same
EOF, as a completed successful transfer. However, enabling reconnect
changes this logic, and leads to the return of EIO.
This patch unifies that logic, leading to the return of EIO for premature
disconnect, regardless of setting of "reconnect".
This fixed wasm checkasm failure
$ wasm-tools validate tests/checkasm/checkasm
error: wasisdk://v25.0/build/sysroot/wasi-libc-wasm32-wasip1-threads/libc-top-half/musl/src/stdio/__stdio_close.c:24:9 function `__stdio_close` failed to validate
Caused by:
0: func 4581 failed to validate
1: type mismatch: expected i32 but nothing on stack (at offset 0x43b770)
Since close is declared as static function, it's more like a bug
in wasi sdk, but we can workaround it easily.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Reviewed-by: James Almer <jamrial@gmail.com>
We can't use AV_FRAME_SIDE_DATA_FLAG_REPLACE here because the side data already in the
frame should have priority over the global one, so just ensure we don't copy any if
it already exists.
Fixes ticket #11468.
Signed-off-by: James Almer <jamrial@gmail.com>
