Re: [FFmpeg-devel] [PATCH v2] avutil/hwcontext_videotoolbox: Set proper CVBuffer colorspace
> On May 20, 2024, at 09:12, Marvin Scholz wrote:
>
> Fix #10884
> ---
> libavutil/hwcontext_videotoolbox.c | 54 +-
> 1 file changed, 38 insertions(+), 16 deletions(-)
>
> diff --git a/libavutil/hwcontext_videotoolbox.c
> b/libavutil/hwcontext_videotoolbox.c
> index 9f82b104c3..4a35bfc7ff 100644
> --- a/libavutil/hwcontext_videotoolbox.c
> +++ b/libavutil/hwcontext_videotoolbox.c
> @@ -530,6 +530,8 @@ CFStringRef av_map_videotoolbox_color_trc_from_av(enum
> AVColorTransferCharacteri
> static int vt_pixbuf_set_colorspace(void *log_ctx,
> CVPixelBufferRef pixbuf, const AVFrame
> *src)
> {
> +CGColorSpaceRef colorspace = NULL;
> +CFMutableDictionaryRef attachments = NULL;
> CFStringRef colormatrix = NULL, colorpri = NULL, colortrc = NULL;
> Float32 gamma = 0;
>
> @@ -550,37 +552,57 @@ static int vt_pixbuf_set_colorspace(void *log_ctx,
> else if (src->color_trc == AVCOL_TRC_GAMMA28)
> gamma = 2.8;
>
> +attachments = CFDictionaryCreateMutable(NULL, 0,
> +
> ,
> +
> );
> +if (!attachments)
> +return AVERROR(ENOMEM);
> +
> if (colormatrix) {
> -CVBufferSetAttachment(
> -pixbuf,
> +CFDictionarySetValue(
> +attachments,
> kCVImageBufferYCbCrMatrixKey,
> -colormatrix,
> -kCVAttachmentMode_ShouldPropagate);
> +colormatrix);
> }
> if (colorpri) {
> -CVBufferSetAttachment(
> -pixbuf,
> +CFDictionarySetValue(
> +attachments,
> kCVImageBufferColorPrimariesKey,
> -colorpri,
> -kCVAttachmentMode_ShouldPropagate);
> +colorpri);
> }
> if (colortrc) {
> -CVBufferSetAttachment(
> -pixbuf,
> +CFDictionarySetValue(
> +attachments,
> kCVImageBufferTransferFunctionKey,
> -colortrc,
> -kCVAttachmentMode_ShouldPropagate);
> +colortrc);
> }
> if (gamma != 0) {
> CFNumberRef gamma_level = CFNumberCreate(NULL, kCFNumberFloat32Type,
> );
> -CVBufferSetAttachment(
> -pixbuf,
> +CFDictionarySetValue(
> +attachments,
> kCVImageBufferGammaLevelKey,
> -gamma_level,
> -kCVAttachmentMode_ShouldPropagate);
> +gamma_level);
> CFRelease(gamma_level);
> }
>
> +if (__builtin_available(macOS 10.8, iOS 10, *))
> +colorspace =
> CVImageBufferCreateColorSpaceFromAttachments(attachments);
> +
> +if (colorspace) {
> +CFDictionarySetValue(
> +attachments,
> +kCVImageBufferCGColorSpaceKey,
> +colorspace);
> +CFRelease(colorspace);
> +} else
> +av_log(log_ctx, AV_LOG_WARNING, "Unable to set proper colorspace for
> the CVImageBuffer.\n");
This will spam the console on SDR video inputs because they have nothing to be
set as the attachment and the colorspace creation will always fail and return
nil.
> +
> +CVBufferSetAttachments(
> +pixbuf,
> +attachments,
> +kCVAttachmentMode_ShouldPropagate);
> +CFRelease(attachments);
> +
> return 0;
> }
>
>
> base-commit: 463c573e6b6489c588bee90124d5cf92db8ccaaa
> --
> 2.39.3 (Apple Git-145)
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] duplicate symbol '_dec_init' in: fftools/ffmpeg_dec.o
Can you try to change the `BD_PRIVATE` to
`__attribute__((visibility("hidden")))` in the line defines `dec_init`
src/libbluray/disc/dec.h then recompile libbluray to see if it fixes the
linking issue?
> On Mar 17, 2024, at 05:09, Helmut K. C. Tessarek wrote:
>
> Hi,
>
> On 2024-03-16 10:26, Christopher Degawa wrote:
>> Seems the conflict comes from
>> https://code.videolan.org/videolan/libbluray/-/blob/master/src/libbluray/disc/dec.c?ref_type=heads#L287
>> and
>> https://github.com/FFmpeg/FFmpeg/commit/c4de5778bceab3c15f1239f1f16816749a7fd3b6
>> Perhaps you could also try asking libbluray if they could use an internal
>> prefix. Otherwise you might need to do a rename of that function on
>> ffmpeg's side.
>
> Hmm, this commit in ffmpeg broke the possibility to link ffmpeg with
> libbluray. Just to make this perfectly clear, before that commit it worked
> without issues.
>
> This means that nobody is able to use libbluray and ffmpeg from this point
> forward. I am sorry, but this commit should be reverted.
>
> The commit message reads: Rename dec_open to dec_init(), as it is more
> descriptive of its new purpose.
>
> Who cares about how descriptive it is as long as it works. Now it doesn't.
> This was not a change to implement a feature or fix a bug, but a simple
> refactor, because somebody didn't like the name.
>
> In reality I agree with you that it might be better for libbluray to use a
> prefix/namespace or whatever. But until then, ffmpeg should still be able to
> be linked with libbluray.
>
> Is my standpoint unreasonable? If so, why?
>
> Cheers,
> K. C.
>
> --
> regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944
> Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944
>
> /*
> Thou shalt not follow the NULL pointer for chaos and madness
> await thee at its end.
> */
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] duplicate symbol '_dec_init' in: fftools/ffmpeg_dec.o
If you are using Xcode >= 15 then you will need to add `-Wl,-ld_classic` to LDFLAGS. During configure you will also need to set `--host-ldflags='-Wl,-ld_classic’`. > On Mar 16, 2024, at 09:04, Helmut K. C. Tessarek wrote: > > Hello, > > It's me again - the dude who compiles ffmpeg for macOS... ;-) > > I haven't updated the referenced libbluray, but only compiled ffmpeg the way > I always do. The last time was about 3 days ago and all was good. > > This is the git hash of ffmpeg I tried to compile: b47abd5737 > > duplicate symbol '_dec_init' in: >fftools/ffmpeg_dec.o >/Users/Shared/ffmpeg/sw/lib/libbluray.a(libbluray_la-dec.o) > ld: 1 duplicate symbol for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > > The only code that changed was ffmpeg and libx265, thus I suspect it was a > change to ffmpeg. I can't really do a git bisect, because this error only > happens after ffmpeg is compiled at the linker stage, so that would take me > forever > > However, the dev who did a change related to this would probably know right > away. > > Cheers, > K. C. > > > -- > regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 > Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 > > /* > Thou shalt not follow the NULL pointer for chaos and madness > await thee at its end. > */ > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4] avfilter: add vf_overlay_videotoolbox
A ping for this as it is already a week.
> On Feb 28, 2024, at 00:35, gnattu via ffmpeg-devel
> wrote:
>
> Overlay filter for VideoToolbox hwframes. Unlike most hardware
> overlay filters, this filter does not require the two inputs to
> have the same pixel format; instead, it will perform format
> conversion automatically with hardware accelerated methods.
>
> Signed-off-by: Gnattu OC
> ---
> Changes from v3:
>
> - Fixes an issue that 8bit depth BGRA overlay frames are not correctly
> converted to 16bit
> - Added a constraint to input pixel formats as VideoToolbox cannot convert
> all of its hardwareframes
>
> Changelog | 1 +
> configure | 1 +
> doc/filters.texi | 52 ++
> libavfilter/Makefile | 3 +
> libavfilter/allfilters.c | 1 +
> libavfilter/metal/utils.m | 7 +-
> .../metal/vf_overlay_videotoolbox.metal | 58 ++
> libavfilter/vf_overlay_videotoolbox.m | 609 ++
> 8 files changed, 730 insertions(+), 2 deletions(-)
> create mode 100644 libavfilter/metal/vf_overlay_videotoolbox.metal
> create mode 100644 libavfilter/vf_overlay_videotoolbox.m
>
> diff --git a/Changelog b/Changelog
> index 610ee61dd6..3ecfdab81b 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -27,6 +27,7 @@ version :
> - a C11-compliant compiler is now required; note that this requirement
> will be bumped to C17 in the near future, so consider updating your
> build environment if it lacks C17 support
> +- VideoToolbox overlay filter
>
> version 6.1:
> - libaribcaption decoder
> diff --git a/configure b/configure
> index 23066efa32..a7c349d126 100755
> --- a/configure
> +++ b/configure
> @@ -3807,6 +3807,7 @@ overlay_qsv_filter_deps="libmfx"
> overlay_qsv_filter_select="qsvvpp"
> overlay_vaapi_filter_deps="vaapi VAProcPipelineCaps_blend_flags"
> overlay_vulkan_filter_deps="vulkan spirv_compiler"
> +overlay_videotoolbox_filter_deps="metal corevideo coreimage videotoolbox"
> owdenoise_filter_deps="gpl"
> pad_opencl_filter_deps="opencl"
> pan_filter_deps="swresample"
> diff --git a/doc/filters.texi b/doc/filters.texi
> index e0436a5755..bfb77562cb 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -19033,6 +19033,58 @@ See @ref{framesync}.
>
> This filter also supports the @ref{framesync} options.
>
> +@section overlay_videotoolbox
> +
> +Overlay one video on top of another.
> +
> +This is the VideoToolbox variant of the @ref{overlay} filter.
> +It takes two inputs and has one output. The first input is the "main" video
> on which the second input is overlaid.
> +It only accepts VideoToolbox frames. The underlying input pixel formats do
> not have to match.
> +Different input pixel formats and color spaces will be automatically
> converted using hardware accelerated methods.
> +The final output will have the same pixel format and color space as the
> "main" input.
> +
> +The filter accepts the following options:
> +
> +@table @option
> +
> +@item x
> +Set the x coordinate of the overlaid video on the main video.
> +Default value is @code{0}.
> +
> +@item y
> +Set the y coordinate of the overlaid video on the main video.
> +Default value is @code{0}.
> +
> +@item eof_action
> +See @ref{framesync}.
> +
> +@item shortest
> +See @ref{framesync}.
> +
> +@item repeatlast
> +See @ref{framesync}.
> +
> +@end table
> +
> +@subsection Examples
> +
> +@itemize
> +@item
> +Overlay an image LOGO at the top-left corner of the INPUT video.
> +The INPUT video is in nv12 format and the LOGO image is in rgba format.
> +@example
> +-hwaccel videotoolbox -i INPUT -i LOGO -codec:v:0 h264_videotoolbox
> -filter_complex "[0:v]format=nv12,hwupload[a], [1:v]format=rgba,hwupload[b],
> [a][b]overlay_videotoolbox" OUTPUT
> +@end example
> +@item
> +Overlay an SDR video OVERLAY at the top-left corner of the HDR video MAIN.
> +The INPUT video is in p010 format and the LOGO image is in nv12 format.
> +The OUTPUT video will also be an HDR video with OVERLAY mapped to HDR.
> +@example
> +-hwaccel videotoolbox -i MAIN -i OVERLAY -codec:v:0 hevc_videotoolbox -tag:v
> hvc1 -filter_complex "[0:v]format=p010,hwupload[a],
> [1:v]format=nv12,hwupload[b], [a][b]overlay_videotoolbox" OUTPUT
> +@end example
> +
> +@end itemize
> +
> @section owdenoise
>
> Apply Overcomplete Wavelet denoiser.
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index f6c1d641d6..ea1389ab57 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -413,6 +413,9 @@ OBJS-$(CONFIG_OVERLAY_OPENCL_FILTER) +=
> vf_overlay_opencl.o opencl.o \
> OBJS-$(CONFIG_OVERLAY_QSV_FILTER)+= vf_overlay_qsv.o framesync.o
> OBJS-$(CONFIG_OVERLAY_VAAPI_FILTER) += vf_overlay_vaapi.o
> framesync.o vaapi_vpp.o
> OBJS-$(CONFIG_OVERLAY_VULKAN_FILTER) += vf_overlay_vulkan.o vulkan.o
> vulkan_filter.o
>
Re: [FFmpeg-devel] [PATCH] hwcontext_videotoolbox: add vt_device_derive
I’ve tested and confirmed to work, and `reverse=1` also works for chaining to other videotoolbox filters. > On Feb 23, 2024, at 22:25, Zhao Zhili wrote: > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] avfilter: add vf_overlay_videotoolbox
A ping for this.
> On Feb 21, 2024, at 09:53, gnattu wrote:
>
> Overlay filter for VideoToolbox hwframes. Unlike most hardware
> overlay filters, this filter does not require the two inputs to
> have the same pixel format; instead, it will perform format
> conversion automatically with hardware accelerated methods.
>
> Signed-off-by: Gnattu OC
> ---
> Changelog | 1 +
> configure | 1 +
> doc/filters.texi | 52 ++
> libavfilter/Makefile | 3 +
> libavfilter/allfilters.c | 1 +
> libavfilter/metal/utils.h | 1 -
> libavfilter/metal/utils.m | 7 +-
> .../metal/vf_overlay_videotoolbox.metal | 58 ++
> libavfilter/vf_overlay_videotoolbox.m | 551 ++
> 9 files changed, 672 insertions(+), 3 deletions(-)
> create mode 100644 libavfilter/metal/vf_overlay_videotoolbox.metal
> create mode 100644 libavfilter/vf_overlay_videotoolbox.m
>
> diff --git a/Changelog b/Changelog
> index 610ee61dd6..3ecfdab81b 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -27,6 +27,7 @@ version :
> - a C11-compliant compiler is now required; note that this requirement
> will be bumped to C17 in the near future, so consider updating your
> build environment if it lacks C17 support
> +- VideoToolbox overlay filter
>
> version 6.1:
> - libaribcaption decoder
> diff --git a/configure b/configure
> index 23066efa32..a7c349d126 100755
> --- a/configure
> +++ b/configure
> @@ -3807,6 +3807,7 @@ overlay_qsv_filter_deps="libmfx"
> overlay_qsv_filter_select="qsvvpp"
> overlay_vaapi_filter_deps="vaapi VAProcPipelineCaps_blend_flags"
> overlay_vulkan_filter_deps="vulkan spirv_compiler"
> +overlay_videotoolbox_filter_deps="metal corevideo coreimage videotoolbox"
> owdenoise_filter_deps="gpl"
> pad_opencl_filter_deps="opencl"
> pan_filter_deps="swresample"
> diff --git a/doc/filters.texi b/doc/filters.texi
> index e0436a5755..bfb77562cb 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -19033,6 +19033,58 @@ See @ref{framesync}.
>
> This filter also supports the @ref{framesync} options.
>
> +@section overlay_videotoolbox
> +
> +Overlay one video on top of another.
> +
> +This is the VideoToolbox variant of the @ref{overlay} filter.
> +It takes two inputs and has one output. The first input is the "main" video
> on which the second input is overlaid.
> +It only accepts VideoToolbox frames. The underlying input pixel formats do
> not have to match.
> +Different input pixel formats and color spaces will be automatically
> converted using hardware accelerated methods.
> +The final output will have the same pixel format and color space as the
> "main" input.
> +
> +The filter accepts the following options:
> +
> +@table @option
> +
> +@item x
> +Set the x coordinate of the overlaid video on the main video.
> +Default value is @code{0}.
> +
> +@item y
> +Set the y coordinate of the overlaid video on the main video.
> +Default value is @code{0}.
> +
> +@item eof_action
> +See @ref{framesync}.
> +
> +@item shortest
> +See @ref{framesync}.
> +
> +@item repeatlast
> +See @ref{framesync}.
> +
> +@end table
> +
> +@subsection Examples
> +
> +@itemize
> +@item
> +Overlay an image LOGO at the top-left corner of the INPUT video.
> +The INPUT video is in nv12 format and the LOGO image is in rgba format.
> +@example
> +-hwaccel videotoolbox -i INPUT -i LOGO -codec:v:0 h264_videotoolbox
> -filter_complex "[0:v]format=nv12,hwupload[a], [1:v]format=rgba,hwupload[b],
> [a][b]overlay_videotoolbox" OUTPUT
> +@end example
> +@item
> +Overlay an SDR video OVERLAY at the top-left corner of the HDR video MAIN.
> +The INPUT video is in p010 format and the LOGO image is in nv12 format.
> +The OUTPUT video will also be an HDR video with OVERLAY mapped to HDR.
> +@example
> +-hwaccel videotoolbox -i MAIN -i OVERLAY -codec:v:0 hevc_videotoolbox -tag:v
> hvc1 -filter_complex "[0:v]format=p010,hwupload[a],
> [1:v]format=nv12,hwupload[b], [a][b]overlay_videotoolbox" OUTPUT
> +@end example
> +
> +@end itemize
> +
> @section owdenoise
>
> Apply Overcomplete Wavelet denoiser.
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index f6c1d641d6..ea1389ab57 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -413,6 +413,9 @@ OBJS-$(CONFIG_OVERLAY_OPENCL_FILTER) +=
> vf_overlay_opencl.o opencl.o \
> OBJS-$(CONFIG_OVERLAY_QSV_FILTER)+= vf_overlay_qsv.o framesync.o
> OBJS-$(CONFIG_OVERLAY_VAAPI_FILTER) += vf_overlay_vaapi.o
> framesync.o vaapi_vpp.o
> OBJS-$(CONFIG_OVERLAY_VULKAN_FILTER) += vf_overlay_vulkan.o vulkan.o
> vulkan_filter.o
> +OBJS-$(CONFIG_OVERLAY_VIDEOTOOLBOX_FILTER) += vf_overlay_videotoolbox.o
> framesync.o \
> +
> metal/vf_overlay_videotoolbox.metallib.o \
> +
Re: [FFmpeg-devel] [PATCH] hwcontext_videotoolbox: add vt_device_derive
Actually, if you examine the `hwcontext_videotoolbox.c` file, you will find
that the current function for `vt_device_create` is essentially a no-op: it
only returns an error if a user attempts to select a device, otherwise it just
returns. This is generally how VideoToolbox works. If the `create_device`
function is already a no-op, then the derive operation will certainly also be a
no-op. All other hardware filters can utilize the derive API, and there are use
cases that depend on this API. Thus, it seems inappropriate to me that
VideoToolbox users cannot use the derive API just because VideoToolbox does not
require any device creation.
> A libavfilter API user will set the correct hw_device_ctx on each filter and
> your use-case will work properly
Can't this just be the modification of the `hwupload` filter? Instead of
derive, the user just set the which initialized hardware to use, as
`-init_hw_device` can already be called multiple times and creating alias for
each hardware.
> On Feb 23, 2024, at 03:50, Mark Thompson wrote:
>
> On 22/02/2024 19:39, ChenLiucheng via ffmpeg-devel wrote:
>>> On Feb 23, 2024, at 03:28, Mark Thompson wrote:
>>>
>>> On 22/02/2024 18:46, gnattu via ffmpeg-devel wrote:
There is no device context to be setup, nor devices to be
selected with VideoToolbox. Just a simple return would allow
us to use derived device in filters like
`hwupload=derive_device=videotoolbox`
Signed-off-by: Gnattu OC
---
libavutil/hwcontext_videotoolbox.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavutil/hwcontext_videotoolbox.c
b/libavutil/hwcontext_videotoolbox.c
index fe469dc161..d13199eca7 100644
--- a/libavutil/hwcontext_videotoolbox.c
+++ b/libavutil/hwcontext_videotoolbox.c
@@ -759,6 +759,14 @@ static int vt_device_create(AVHWDeviceContext *ctx,
const char *device,
return 0;
}
+static int vt_device_derive(AVHWDeviceContext *device_ctx,
+AVHWDeviceContext *src_ctx, AVDictionary
*opts,
+int flags)
+{
+// There is no context to be setup with VT, just return.
+return 0;
+}
+
const HWContextType ff_hwcontext_type_videotoolbox = {
.type = AV_HWDEVICE_TYPE_VIDEOTOOLBOX,
.name = "videotoolbox",
@@ -766,6 +774,7 @@ const HWContextType ff_hwcontext_type_videotoolbox = {
.frames_priv_size = sizeof(VTFramesContext),
.device_create= vt_device_create,
+.device_derive= vt_device_derive,
.frames_hwctx_size= sizeof(AVVTFramesContext),
.frames_init = vt_frames_init,
.frames_get_buffer= vt_get_buffer,
>>>
>>> This derivation behaviour doesn't make any sense inside libavutil.
>>> Features which are only for the ffmpeg utility should be implemented inside
>>> the ffmpeg utility.
>>>
>>> (Also, try -init_hw_device.)
>>>
> > Well this does make sense.
> >
> > If only one type of hardware device is in use, then `-init_hw_device` will
> > suffice. However, if we use hardware filters with different device types,
> > such as OpenCL, and we want to switch to a VideoToolbox filter later in the
> > chain, we will have a issue. Since there is no `hwmap` between OpenCL and
> > VideoToolbox, we need to perform a `hwdownload` followed by a `hwupload`.
> > If the `derive_device` option cannot be used with `hwupload` due to
> > `device_derive` not being implemented, the filter will struggle to find the
> > correct device for uploading. It may attempt to upload to the OpenCL device
> > without `device_derive` set if it comes after an OpenCL filter.
> >
>
> Yes, it is unfortunate that the ffmpeg utility is missing this feature.
>
> A libavfilter API user will set the correct hw_device_ctx on each filter and
> your use-case will work properly, but the ffmpeg utility does not fully
> expose the functionality of libavfilter to be able to do this.
>
> This is mostly for syntax reasons; implementation would be straightforward.
> If you can think of a good way to represent this in options to the ffmpeg
> utility (which doesn't become too horrible with escaping) then I would very
> much welcome suggestions.
>
> Thanks,
>
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
