This is a new API that offers two improvements over the existing field:
1. It allows setting a different limit per media type
2. It allows updating the limit after the graph has been configured, as
long as this would not cause already existing frames to exceed the limit
I'm not sure if the second point is ever useful, but it's easy to implement
regardless.
Because the old field will be deprecated, the new API just overrides the old
value wholesale. The alternative was to respect both (i.e. use the smaller
of the two limits); but this way, callers can use the new API to e.g.
selectively uncap the limit on audio frames while remaining backwards
compatible with older libavfilter.
Explicitly set limits are tracked separately, so that avfilter_graph_config()
re-derives all other limits from the old field on every call.
Signed-off-by: Niklas Haas <git@haasn.dev>
Minor semantic change to prepare for the upcoming commits.
This shouldn't regress anything because the new behavior is strictly more
permissive than the old behavior, and the distinction is only relevant
for the uncommon case of combined audio-video filters.
Signed-off-by: Niklas Haas <git@haasn.dev>
Lets the caller read back the negotiated chroma location and constrain the
sink to a list of accepted ones.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Lets the caller state the chroma siting of the frames it feeds in, which is
what the rest of the graph negotiates against. A tagged source constrains
the link to its own value, an untagged one places no constraint at all,
there being nothing to convert from.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Chroma sample location is the last of the video colorimetry properties
without a negotiated link value, so nothing downstream can ask a filter for
a particular siting and no encoder can constrain the graph. Add it alongside
the existing color space, color range and alpha mode negotiation.
Merge conflicts are resolved by inserting a scale filter, the same way as
for color space and color range.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Add an output_format option (cuda | cuarray) so the filter can produce
either pitched-linear (AV_PIX_FMT_CUDA, default) or block-linear
(AV_PIX_FMT_CUARRAY) device frames. This enables host-to-device
upload directly into CUarray surfaces for the CUARRAY transcode
pipeline.
Also extend the accepted input pixel format list with semi-planar 444
formats (NV24, P410, P416) and the planar MSB variants (YUV444P10MSB,
YUV444P12MSB). Semi-planar 444 formats are rejected with a clear
error when output_format=cuda, as they are only supported by the
CUarray allocation path.
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
Convert packed 24/32-bit RGB/BGR/RGBA/BGRA input to PAL8 using a per-frame palette
whose colors are placed on a face-centered cubic lattice (realized as the
scaled D3/D4 checkerboard lattice), with a user-supplied density controlling
the number of lattice steps spanning one color axis.
Only lattice points actually used by a frame enter its palette; if a frame
needs more than 256 of them, the filter will itearatively drop palettte
entries and reassign affected pixels until 256 color remain
lookup uses the Conway-Sloane rounding algorithm. Supported dithering
modes: none, ordered 8x8 bayer (swscale), Cluster & Void blue noise and
Floyd-Steinberg error diffusion.
Co-Authored-by: Fable-5
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This patch adds the transpose_cuda video filter.
It's similar to the existing transpose filter but accelerated by CUDA.
It supports the same pixel formats as the scale_cuda filter.
This also supersedes the deprecated transpose_npp filter.
Example usage:
ffmpeg -hwaccel cuda -hwaccel_output_format cuda -i <INPUT> -vf "transpose_cuda=dir=clock" <OUTPUT>
Signed-off-by: nyanmisaka <nst799610810@gmail.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
This patch adds screen capture support via AMF vsrc_amf:
ffmpeg -y \
-filter_complex "vsrc_amf=framerate=120:capture_mode=keep_framerate" \
-c:v hevc_amf \
-frames:v 300 \
output_grab.mp4
If the HW frames pool is insufficient,
increase extra_hw_frames in filter_complex.
The supported YUV pixel formats were separated between planar
and semiplanar. This approach reduces the number of CUDA kernels
for all pixel formats.
This patch:
1. Adds support for YUV 4:2:2 planar and semi-planar formats:
yuv422p, yuv422p10, nv16, p210, p216
2. Implements new conversion structures and kernel definitions
for planar and semi-planar formats
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
There is currently no way for API users to know that a buffersrc is no longer
accepting input, except by trying to feed it a frame and seeing what happens.
Of course, this is not possible if the user does not *have* a frame to feed,
but may still wish to know if the filter is still accepting input or not.
Since passing `frame == NULL` to `av_buffersrc_add_frame()` is already treated
as closing the input, we are left with no choice but to introduce a new
function for this.
We don't explicitly return the result of `ff_outlink_get_status()` to avoid
leaking internal status codes, and instead translate them all to AVERROR(EOF).
Enables timeline editing options for overlay_cuda similar to what overlay allows
Example overlaying an image on a video between 30 to 60 seconds:
ffmpeg -hwaccel cuda -hwaccel_output_format cuda -i sample-video.mp4 -i sample-image.jpg
-filter_complex "[1:v]hwupload_cuda[image],[0:v]scale_npp=format=yuv420p[video],[video][image]overlay_cuda=enable='between(t,30,60)'"
-c:v h264_nvenc -c:a copy -y overlay-output-gpu.mp4
Signed-off-by: Jorge Estrada <jestrada.list@gmail.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
This patch adds the pad_cuda video filter. A filter similar to the existing pad filter but accelerated by CUDA.
The filter shares the same options as the software pad filter.
Example usage:
ffmpeg -hwaccel cuda -hwaccel_output_format cuda -i input.mp4 -vf "pad_cuda=w=iw+100:h=ih+100:x=-1:y=-1:color=red" out.mp4
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
The crop filter has no effect on scale_cuda:
-vf crop=100:100,scale_cuda=100x100
Hardware frames (AV_PIX_FMT_FLAG_HWACCEL) are expected to use the crop_* properties,
as seen in the implementation vf_crop.c.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
"int-list" options are a hack that provides rudimentary support for
array-type options by treating them as byte arrays (i.e.
AV_OPT_TYPE_BINARY). Since we now have proper array-type options, they
should replace "int-list" everywhere (which happens to be just
buffersink).
Niklas Haas