This fixes timeout issues and seems like it was intended
since the line emits an error log.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Marth64 <marth64@proxyid.net>
The format is used by at least Dish Network, but is not
defined in any DVB standard, so remove references to DVB.
This is a simple rename, no functional change.
Signed-off-by: Marth64 <marth64@proxyid.net>
AV1 uses a vastly different range than what the global options permit,
and also for the other codecs the range of the global options is at
least misaligned.
Fixes#11365
This commit extends the support for Temporal Filtering in NVENC for
AV1 and H.264 codecs. For natural videos with noise, NVENC temporal
filtering improves video coding efficiency by 4-5%.
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
This commit adds support for Ultra High Quality mode for AV1 on
NVIDIA GPUs.
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
This commit adds support for 4:2:2 encoding for HEVC and H.264 on
NVIDIA Blackwell GPUs. Additionally, it supports 10-bit encoding
for H.264 on Blackwell GPUs.
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
This commit adds support for 4:2:2 decoding for HEVC and H.264 on
NVIDIA Blackwell GPUs for cuviddec. Moreover, it supports 10-bit
decoding for H.264 on Blackwell GPUs.
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
This commit adds support for 4:2:2 decoding for HEVC and H.264 on
NVIDIA Blackwell GPUs. Additionally, it supports 10-bit decoding
for H.264 on Blackwell GPUs.
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
This commit adds support for 4:2:2 pixel formats, namely NV16 and
P216 for NVIDIA GPUs.
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
If there's a very large ISOBMFF box that needs to be skipped, it can
cause an overflow for ctx->skip. There's already a safeguard to return
quickly if ctx->skip > bufsize, so changing ctx->skip to int64_t will
allow this to happen even if ctx->skip would overflow a signed int.
Several other members are also changed to int64_t to avoid this problem
in other possible scenarios.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Reported-by: Kacper Michajlow <kasper93@gmail.com>
Fixes: clusterfuzz-testcase-minimized-fuzzer_loadfile-6085331937460224
`POS(1,` and `POS(2,` may trigger UBSAN report:
"runtime error: applying non-zero offset 304 to null pointer"
Looks like values are not used without `chroma_format_idc`,
so maybe there is no other issues than the UB.
Can't reproduce with "fate".
Signed-off-by: Vitaly Buka <vitalybuka@google.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: signed integer overflow: 7803923888585309955 - -3407677434275325337 cannot be represented in type 'int64_t' (aka 'long')
Fixes: 377736723/clusterfuzz-testcase-minimized-media_pipeline_integration_fuzzer-5052449500889088
Signed-off-by: James Almer <jamrial@gmail.com>
This function can return AVERROR_BUG in theory if something
went wrong, but so can the caller, so we should propagate that
error message upward in that case.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
When running the cleanup in rtmp_close on failures in rtmp_open,
we can in rare cases end up using rt->playpath, assuming that it
is still set.
The crash could happen if we hit the fail codepath in rtmp_open
while publishing (rt->is_input == 0) with rt->state set to
a value > STATE_FCPUBLISH.
This would normally not happen while publishing; either we have
an error (and rt->state <= STATE_FCPUBLISH) or we reach
rt->state = STATE_PUBLISHING, and then we also return successfully
from rtmp_open.
The unexpected combination of states could happen if the server
responds with e.g. "NetStream.Play.Stop" while expecting
"NetStream.Publish.Start"; this sets rt->state to STATE_STOPPED,
which also fulfills the condition "> STATE_FCPUBLISH".
We don't need to free the rt->playpath/tcurl/flashver strings here;
they're handled via AVOption, and thus are freed automatically when
the protocol instance is freed (that's why they aren't freed
manually within the rtmp_close function either).
We also don't need to free the AVDictionary with options; it's
owned by the caller.
A smaller fix would be to just call rtmp_close before freeing
the strings and dictionary, but as we don't need to free them
at all, let's remove that redundant code.
Signed-off-by: Martin Storsjö <martin@martin.st>
Traditionally, macOS has shipped an old version of rsync that lacked
support for this option, hence this check (added in
a8b3f0c5cf).
However, in macOS 15.x, Apple have switched to providing rsync as a
different tool, openrsync. The version of openrsync in at least
macOS 15.2 does include "[--contimeout]" (note the lack of "=" after
the option), in the output of "rsync --help", but when used, the tool
errors out with "rsync: --contimeout=60: unknown option". So apparently
the tool erroenously lists the option as supported, while it really
isn't.
The original rsync tool (with a new enough version) prints
"--contimeout=SECONDS" in the output of "rsync --help".
It is unclear which version of openrsync Apple are shipping; the latest
upstream openrsync from OpenBSD does support the option and includes
"[--contimeout=seconds]" in the output of "--help", and older versions
don't seem to include the option as listed at all.
Therefore, check for "--conntimeout=" with the "=", this should
properly detect both new enough rsync and openrsync.
This fixes running "fate-rsync" on macOS 15.x.
Signed-off-by: Martin Storsjö <martin@martin.st>
In f121d95, the outlink framerate was unconditionally unset.
This breaks/bloats outputs from CFR muxers unless the user explicitly
sets a sane framerate. And the most common invocation for setpts seen in
workflows, our docs and across the web is `PTS-STARTPTS` or others of the
general form `PTS+constant` which preserves the input framerate.
Default value is false, which restores old behaviour.
Fixes#11428
Global side data as exported by a decoder may no longer apply if a filter in
the chain altered the frames in some form, like changing color, dimensions,
or channel layout information.
After this change, any such changes in side data will be taken into account by
the encoder futher in the process.
Signed-off-by: James Almer <jamrial@gmail.com>
