NVDEC and CUVID now output AV_PIX_FMT_P012 (12-bit 4:2:0), AV_PIX_FMT_P212
(12-bit 4:2:2) and AV_PIX_FMT_YUV444P10MSB / AV_PIX_FMT_YUV444P12MSB
(10/12-bit 4:4:4) for high-bit-depth content, but these CUDA filters
rejected the formats in their supported-format lists, breaking pipelines
such as "-hwaccel cuda ... -vf scale_cuda" on 12-bit input.
These formats use 16-bit sample storage, and the filters select their CUDA
kernel by byte-storage size and plane layout, not by the number of valid
bits, so they can reuse the existing 16-bit kernels:
- scale_cuda: P012/P212 -> "semiplanar16", YUV444P10MSB/YUV444P12MSB ->
"planar16".
- transpose_cuda: the ushort/ushort2 kernels are chosen from the pixel
descriptor (byte size + channel count); just allow the new formats.
- thumbnail_cuda: P012 reuses the P010/P016 path and the MSB 4:4:4 formats
reuse the YUV444P16 path; P012 is added to the 4:2:0 chroma-histogram
scaling as well. (thumbnail has no 4:2:2 path, so P212 is not added.)
The CUDA deinterlacers (bwdif_cuda, yadif_cuda) already accept any format
with <= 2 bytes per sample and <= 2 channels, so they need no change. The
8-bit-only filters (overlay_cuda, pad_cuda, bilateral_cuda, chromakey_cuda,
colorspace_cuda) do not support high bit depths and are left untouched.
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
Since 9e857e1f8a, library.mak generates a
response file containing the list of input object files. This was done
to avoid hitting the 8192 character command line limit on Windows
shells.
However, that particular solution still relies on emitting a
very long `echo` command that gets delegated to a subshell. This means
that, for example, running `make` within problematic shells like Git
Bash could still hit the command line length limit when this `echo` step
is ran. Other MSYS2 shells are not affected, meaning the previous
workaround only helped when running in an MSYS2 environment, but broke
when using Git Bash, e.g. for MSVC. This primarily affected `libavcodec`
due to the sheer volume of files contained within.
To avoid this problem, this commit changes the object emission step to
use GNU make's `file` builtin to write the list of object files. `file`
itself was introduced in GNU Make 4.0, but FFmpeg still supports old
versions--notably Apple's ancient Make 3.81--so for older make versions
that don't support this, the old echo subshell is used. This tradeoff
should be fine since it's trivial to grab a new-enough Make on Windows,
and other platforms that may be stuck with ancient Make versions
shouldn't have nearly as restrictive command line limits.
Signed-off-by: crueter <crueter@eden-emu.dev>
Fixes use of uninitialized value and dumping it into AVERAGE-BANDWIDTH
in playlist. Note this will be correctly set when we are at final
segment, otherwise it's optional.
Fixes: fate-hls-seek test on MSAN build
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
The switch to the new NVDEC pixel formats made cuvid_derive_output_format()
and the format probe select AV_PIX_FMT_P012 for 12-bit 4:2:0,
AV_PIX_FMT_P210/P212 for 10/12-bit 4:2:2 and AV_PIX_FMT_YUV444P10MSB/
YUV444P12MSB for 10/12-bit 4:4:4, but cuvid_handle_video_sequence() still
only mapped the older formats to a CUVID surface format. Decoding such
streams therefore failed with "Unsupported output format" (AVERROR(EINVAL));
because every packet then errored without producing a frame, the failure
could also manifest as a hang rather than a clean error exit. The
system-memory copy path in cuvid_output_frame() rejected the same formats
with AVERROR_BUG.
Map P012 to cudaVideoSurfaceFormat_P016 (mirroring P010), P210/P212 to
cudaVideoSurfaceFormat_P216 (mirroring P216) and YUV444P10MSB/YUV444P12MSB
to cudaVideoSurfaceFormat_YUV444_16Bit (mirroring YUV444P16); the hardware
surface is physically 16-bit and the pixel format only records the number
of valid bits. Add the same formats to the system-memory copy path, whose
per-plane geometry is already derived generically from the pixel descriptor.
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
NVDEC and CUVID decode 12-bit 4:2:0 content to AV_PIX_FMT_P012 and
12-bit 4:2:2 to AV_PIX_FMT_P212, but these formats were missing from
the CUDA frames context supported format list. As a result
av_hwframe_ctx_init() rejected them ("Pixel format not supported",
AVERROR(ENOSYS)), so decoding 12-bit content to CUDA frames and
hwdownload of such frames both failed.
Add P012 and P212 next to the existing P010/P016 and P210/P216 entries.
The per-plane device transfer is derived generically from the pixel
descriptor, so no other changes are required.
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
The seven *_from_name() functions in pixdesc.c (color_range,
color_primaries, color_transfer, color_space, chroma_location,
alpha_mode) used av_strstart() for prefix matching, which returns
incorrect results when one name is a prefix of another.
av_color_space_from_name("ycgco-re") matched "ycgco" at index
AVCOL_SPC_YCGCO and returned 8 instead of AVCOL_SPC_YCGCO_RE.
av_color_space_from_name("ycgco-ro") had the same issue. The
*_ext name lookups inside av_color_primaries_from_name and
av_color_transfer_from_name had the same flaw.
Switch all eight call sites from av_strstart() to strcmp() for
exact matching. No in-tree callers rely on prefix matching.
Signed-off-by: marcos ashton <marcosashiglesias@gmail.com>
Sometimes the duration itself reflects the remainder samples by being set to a
value lower than the frame size, but in other cases it's done only through
a discard padding value in side data.
Take the latter into account when calculating durations.
Fixes issue #23532.
Signed-off-by: James Almer <jamrial@gmail.com>
This may be faster or slower than the existing specialized kernels,
so I opted not to prefer it by default. I also deliberately didn't expose
additional filter function capabilites yet.
The main motivating reason here is to get correct anti-aliasing behavior
when downscaling, which is currently completely broken.
Signed-off-by: Niklas Haas <git@haasn.dev>
Useful for GPU-based filters, which may also need to compute filter weights.
Since we cannot cross-link to internal functions, we need to recompile this
helper inside libavfilter.c.
Signed-off-by: Niklas Haas <git@haasn.dev>
Anchor c->first_timestamp to the playlist that established it and only let
that playlist's expiring segments advance it, so it slides exactly once
per window slide.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
After a seek, hls_read_packet drops packets until each playlist reaches
seek_timestamp. That threshold lives on c->first_timestamp's baseline,
i.e. the DTS of whichever stream produced the very first packet. Streams
can have different DTS baselines though. So comparing one stream's
threshold against another stream's DTS is wrong. A stream whose first
keyframe precedes the global baseline gets its segment keyframe dropped
and resumes a segment (or more) late.
Track the first DTS per playlist and rebase the threshold onto each
playlist's own baseline. Since HLS segments are presentation-aligned
across renditions, every stream then resumes at the same presentation
time. seek_timestamp keeps its meaning on the global timeline, only the
per-playlist comparison value is translated.
This fixes playlists that would be unable to play from the start, and
instead skip one or more segments, before data is output.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
find_timestamp_in_playlist() already selects the first segment when the
target is below the playlist's first timestamp, but returns 0.
hls_read_seek() treats that as a failure, and all seek operation is
failed.
This breaks seeking to the very start whenever the requested timestamp
is slightly below the first one. Clamp such targets to the first segment
and report success instead.
Fixes: https://github.com/mpv-player/mpv/issues/14840#issuecomment-4703186169
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
CMAF and other EXT-X-BYTERANGE playlists address consecutive segments as
contiguous byte ranges of a single resource. Each segment was fetched with
a separate bounded request, paying a request/response round-trip per
segment even though the connection was kept alive.
Keep the AVIOContext open across segments of the same resource and seek to
the next segment instead of reopening, for contiguous ranges the seek
targets the current position and issues no request in practice.
Non-contiguous, encrypted and non-seekable cases fall back to the
previous reopen behaviour.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Master playlists can reference the same media playlist URI from several
rendition group. new_playlist() allocated a separate playlist struct for
each reference, this is unndeded work and we can fold duplicates into
single probe.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Add a seek test for an HLS master playlist with separate audio and video
media playlists with different DTS baselines.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
If the HTTP server still has stale bytes in the TCP receive buffer, but
the underlying conection was already closed, then the http_open_cnx()
call might fail even though we successfully drained the previous request.
In this case, there is no proper fallback to a new connection, leading to
sudden truncation.
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
Otherwise, this might leak stale bytes that were already drained by the
HTTP soft-seek attempt.
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
This avoids an underflow if short_seek is negative (which can happen if e.g.
ffurl_get_short_seek() returns AVERROR(ENOSYS)), as well as a possible
underflow if the read position is somehow past `range_end` (e.g. if the HTTP
server malicously lied about the content range but gave us more bytes anyway)
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
Deprecated in commit 09c53a04c5
on 2022-06-11.
Thanks to Michael Niedermayer for pointing out that
the documentation needs to be updated, too.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The avpriv_packet_list_put/get/free() functions and the PacketList type
were implemented in libavcodec and exported via the avpriv_ mechanism
solely so that libavformat (and decklink in libavdevice) could use them;
libavcodec itself has no users of them. Exporting them across the library
boundary has the usual drawbacks for shared builds (export/import overhead
and having to keep them around for ABI stability even once unneeded).
Move the implementation and the PacketList/PacketListEntry types to
libavformat and rename the functions to ff_packet_list_*(). libavformat is
the primary user and compiles the new packet_list.c directly; decklink,
the only libavdevice user, gets a private copy for shared builds via the
SHLIBOBJS scheme already used for reverse.o and ccfifo.o (static builds
resolve the symbols from libavformat).
AVPACKET_IS_EMPTY() and ff_side_data_set_prft() remain in
libavcodec/packet_internal.h as they are libavcodec-internal.
This fallback function is used if external MMX is available,
while inline MMX and intrinsics for emitting emms are unavailable.
It is implemented as an avpriv function, which has several
drawbacks for shared builds:
1. The function is so small (3 bytes; 16 with padding)
that the overhead of exporting and importing it dwarfs
the gains from code deduplication.
2. A call to an external library has more overhead than
a library-internal one.
3. It may cause linking failures when a libavutil not exporting
avpriv_emms_asm() is paired with a library needing it
(if inline assembly and intrinsics were unavailable when building
the dependent library). I am not aware of this ever happening.
4. We would be forced to keep avpriv_emms_asm() around for ABI stability
even after it is no longer needed.
This commit therefore uses the STLIBOBJS, SHLIBOBJS approach
to duplicating it into each library on its own if needed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
