Re: [FFmpeg-devel] [PATCH] lavf/sr: fix the segmentation fault caused by incorrect input frame free.
On 2022-07-22 10:52 am, Andreas Rheinhardt wrote: Guo, Yejun: -Original Message- From: ffmpeg-devel On Behalf Of Fu, Ting Sent: 2022年7月21日 17:57 To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] [PATCH] lavf/sr: fix the segmentation fault caused by incorrect input frame free. Kindly ping -Original Message- From: ffmpeg-devel On Behalf Of Paul B Mahol Sent: Monday, June 27, 2022 07:03 PM To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] [PATCH] lavf/sr: fix the segmentation fault caused by incorrect input frame free. lgtm Thanks, and lgtm, will push soon. Fix the commit message when you do: lavf commonly means libavformat; libavfilter is lavfi. This was pushed 5 hours ago, as-is. Regard, Gyan ___ 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] lavf/sr: fix the segmentation fault caused by incorrect input frame free.
Guo, Yejun: > > > -Original Message- > From: ffmpeg-devel On Behalf Of Fu, Ting > Sent: 2022年7月21日 17:57 > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH] lavf/sr: fix the segmentation fault > caused by incorrect input frame free. > > Kindly ping > >> -Original Message- >> From: ffmpeg-devel On Behalf Of Paul >> B Mahol >> Sent: Monday, June 27, 2022 07:03 PM >> To: FFmpeg development discussions and patches >> >> Subject: Re: [FFmpeg-devel] [PATCH] lavf/sr: fix the segmentation >> fault caused by incorrect input frame free. >> >> lgtm > > Thanks, and lgtm, will push soon. Fix the commit message when you do: lavf commonly means libavformat; libavfilter is lavfi. - Andreas ___ 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 v11 10/13] lavu/hwcontext_qsv: make qsv hwdevice works with oneVPL
On Thu, 2022-07-21 at 23:19 +0100, Mark Thompson wrote:
> On 20/07/2022 09:40, Xiang, Haihao wrote:
> > From: Haihao Xiang
> >
> > In oneVPL, MFXLoad() and MFXCreateSession() are required to create a
> > workable mfx session[1]
> >
> > Add config filters for D3D9/D3D11 session (galinart)
> >
> > The default device is changed to d3d11va for oneVPL when both d3d11va
> > and dxva2 are enabled on Microsoft Windows
> >
> > This is in preparation for oneVPL support
> >
> > [1]
> > https://spec.oneapi.io/versions/latest/elements/oneVPL/source/programming_guide/VPL_prg_session.html#onevpl-dispatcher
> >
> > Co-authored-by: galinart
> > Signed-off-by: galinart
> > Signed-off-by: Haihao Xiang
> > ---
> > libavutil/hwcontext_qsv.c | 531 +++---
> > 1 file changed, 493 insertions(+), 38 deletions(-)
> >
> > diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
> > index 21a2a805f8..90b7988dec 100644
> > --- a/libavutil/hwcontext_qsv.c
> > +++ b/libavutil/hwcontext_qsv.c
> > ...
> > +
> > +static int qsv_va_update_config(void *ctx, mfxHDL handle, mfxConfig cfg)
> > +{
> > +#if CONFIG_VAAPI
> > +#if VA_CHECK_VERSION(1, 5, 0)
> > +#define LOCAL_VADISPLAYPCIID VADisplayPCIID
> > +#else
> > +#define LOCAL_VADISPLAYPCIID 21
> > +#endif
>
> This seems to be handling the case where you built the driver against a newer
> version of libva containing the field but then downgraded it before building
> ffmpeg? Who are you expecting to do that?
This should be removed. I was considering the driver and ffmpeg were built in
different environments. BTW the new va-api version should be 1.15, I will fix it
in the next version.
>
> > +mfxStatus sts;
> > +VADisplay dpy = handle;
> > +VAStatus vas;
> > +VADisplayAttribute attr = {
> > +.type = LOCAL_VADISPLAYPCIID
> > +};
> > +mfxVariant impl_value;
> > +
> > +vas = vaGetDisplayAttributes(dpy, , 1);
> > +if (vas == VA_STATUS_SUCCESS && attr.flags !=
> > VA_DISPLAY_ATTRIB_NOT_SUPPORTED) {
> > +impl_value.Type = MFX_VARIANT_TYPE_U16;
> > +impl_value.Data.U16 = (attr.value & 0x);
> > +sts = MFXSetConfigFilterProperty(cfg,
> > + (const mfxU8
> > *)"mfxExtendedDeviceId.DeviceID", impl_value);
> > +if (sts != MFX_ERR_NONE) {
> > +av_log(ctx, AV_LOG_ERROR, "Error adding a MFX configuration"
> > + "DeviceID property: %d.\n", sts);
> > +goto fail;
> > +}
> > +} else {
> > +av_log(ctx, AV_LOG_ERROR, "Failed to get device id from the driver.
> > Please "
> > + "consider to upgrade the driver to support VA-API 1.5.0.
> > \n");
> > +goto fail;
> > +}
>
> The use of the PCI ID doesn't make sense to me here?
>
> A PCI ID tells you the type of the device, not which device it was - given
> that the normal use-case for multiple devices in servers generally has lots of
> idential ones this does not seem helpful.
>
MFXVideoCORE_SetHandle() is still needed after creating a session. here use the
pci id to choose an implementation which can support the given device.
Thanks
Haihao
> > +
> > +return 0;
> > +
> > +fail:
> > +#endif
> > +return AVERROR_UNKNOWN;
> > +}
> > +
> > ...
>
> - 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".
Re: [FFmpeg-devel] [PATCH v10 10/13] lavu/hwcontext_qsv: make qsv hwdevice works with oneVPL
On Thu, 2022-07-21 at 20:30 +, Soft Works wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Xiang, Haihao
> > Sent: Tuesday, July 19, 2022 9:19 AM
> > To: an...@khirnov.net; ffmpeg-devel@ffmpeg.org
> > Cc: Galin, Artem
> > Subject: Re: [FFmpeg-devel] [PATCH v10 10/13] lavu/hwcontext_qsv:
> > make qsv hwdevice works with oneVPL
> >
> > On Mon, 2022-07-18 at 15:02 +0200, Anton Khirnov wrote:
> > > Quoting Xiang, Haihao (2022-07-12 08:27:32)
> > > > +static int qsv_va_update_config(void *ctx, mfxHDL handle,
> >
> > mfxConfig cfg)
> > > > +{
> > > > +#if CONFIG_VAAPI
> > > > +#if VA_CHECK_VERSION(1, 5, 0)
> > > > +#define LOCAL_VADISPLAYPCIID VADisplayPCIID
> > > > +#else
> > > > +#define LOCAL_VADISPLAYPCIID 21
> > > > +#endif
> > > > +mfxStatus sts;
> > > > +VADisplay dpy = handle;
> > > > +VAStatus vas;
> > > > +VADisplayAttribute attr = {
> > > > +.type = LOCAL_VADISPLAYPCIID
> > > > +};
> > > > +mfxVariant impl_value;
> > > > +
> > > > +vas = vaGetDisplayAttributes(dpy, , 1);
> > > > +if (vas == VA_STATUS_SUCCESS && attr.flags !=
> > > > VA_DISPLAY_ATTRIB_NOT_SUPPORTED) {
> > > > +impl_value.Type = MFX_VARIANT_TYPE_U16;
> > > > +impl_value.Data.U16 = (attr.value & 0x);
> > > > +sts = MFXSetConfigFilterProperty(cfg,
> > > > + (const mfxU8
> > > > *)"mfxExtendedDeviceId.DeviceID", impl_value);
> > > > +if (sts != MFX_ERR_NONE) {
> > > > +av_log(ctx, AV_LOG_ERROR, "Error adding a MFX
> >
> > configuration"
> > > > + "DeviceID property: %d.\n", sts);
> > > > +goto fail;
> > > > +}
> > > > +} else
> > > > +av_log(ctx, AV_LOG_WARNING, "Cannot get device id from
> >
> > the driver,
> > > > the default "
> > > > + "MFX implementation will be loaded for this
> >
> > device. Please
> > > > consider to "
> > > > + "upgrade the driver to support VAAPI 1.5.0. \n");
> > >
> > > I would still prefer to fail here. The user requested a specific
> >
> > device,
> > > disregarding that request is evil.
> >
> > Thanks for the comment. There is only one available device for most
> > users, so
> > the default one and the given one from user should be the same,
> > otherwise it
> > won't work. I don't want to make them in trouble if they don't have a
> > driver to
> > support the new interface. However I agree with you it is a little
> > evil to
> > ignore the request. I'll update the patch to return error here.
>
> I'm not a fan of that kind of automagic behavior. Quick success
> experiences are surely desirable in general, but we also need to
> consider the effects of such behavior - in this case, that would
> mean: It doesn't really matter what a user specifies for the parameter,
> because it will always work anyway.
>
> In turn, users may start to think that their wrong command with the
> wrong ID would be right, and then, in a subsequent command
> use that wrong ID again in different context, where it might fail,
> while in turn maximizing confusion.
>
> When it is possible to internally retrieve potentially valid
> values, why not output something useful like: "XXID failed, you
> might want to try A, B or C" (or similar)?
Agree, and this is fixed in the new version.
Thanks
Haihao
___
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] lavf/sr: fix the segmentation fault caused by incorrect input frame free.
-Original Message- From: ffmpeg-devel On Behalf Of Fu, Ting Sent: 2022年7月21日 17:57 To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] [PATCH] lavf/sr: fix the segmentation fault caused by incorrect input frame free. Kindly ping > -Original Message- > From: ffmpeg-devel On Behalf Of Paul > B Mahol > Sent: Monday, June 27, 2022 07:03 PM > To: FFmpeg development discussions and patches > > Subject: Re: [FFmpeg-devel] [PATCH] lavf/sr: fix the segmentation > fault caused by incorrect input frame free. > > lgtm Thanks, and lgtm, will push soon. ___ 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] [PATCH v3 4/4] avfilter/hwmap, hwupload: use new av_hwdevice_ctx_get_or_create_derived method
From: softworkz
Signed-off-by: softworkz
---
libavfilter/vf_hwmap.c| 4 ++--
libavfilter/vf_hwupload.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavfilter/vf_hwmap.c b/libavfilter/vf_hwmap.c
index 2e03dfc1fe..b79cf6732c 100644
--- a/libavfilter/vf_hwmap.c
+++ b/libavfilter/vf_hwmap.c
@@ -82,8 +82,8 @@ static int hwmap_config_output(AVFilterLink *outlink)
goto fail;
}
-err = av_hwdevice_ctx_create_derived(, type,
- hwfc->device_ref, 0);
+err = av_hwdevice_ctx_get_or_create_derived(, type,
+hwfc->device_ref, 0);
if (err < 0) {
av_log(avctx, AV_LOG_ERROR, "Failed to created derived "
"device context: %d.\n", err);
diff --git a/libavfilter/vf_hwupload.c b/libavfilter/vf_hwupload.c
index dbc41734cc..41ee0e43c4 100644
--- a/libavfilter/vf_hwupload.c
+++ b/libavfilter/vf_hwupload.c
@@ -51,7 +51,7 @@ static int hwupload_query_formats(AVFilterContext *avctx)
/* We already have a specified device. */
} else if (avctx->hw_device_ctx) {
if (ctx->device_type) {
-err = av_hwdevice_ctx_create_derived(
+err = av_hwdevice_ctx_get_or_create_derived(
>hwdevice_ref,
av_hwdevice_find_type_by_name(ctx->device_type),
avctx->hw_device_ctx, 0);
--
ffmpeg-codebot
___
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] [PATCH v3 3/4] lavu: bump minor version and add doc/APIchanges entry for av_hwdevice_ctx_get_or_create_derived()
From: softworkz Signed-off-by: softworkz --- doc/APIchanges | 6 ++ libavutil/version.h | 2 +- 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/doc/APIchanges b/doc/APIchanges index b3563cd528..ba21f60953 100644 --- a/doc/APIchanges +++ b/doc/APIchanges @@ -14,6 +14,12 @@ libavutil: 2021-04-27 API changes, most recent first: +2022-07-01 - xx - lavu 57.31.100 - hwcontext.h + Add av_hwdevice_ctx_get_or_create_derived(). + +2022-07-01 - xx - lavu 57.31.100 - buffer.h + Add av_ref_from_buffer(). + 2022-07-xx - xx - lavu 57.30.100 - frame.h Add AVFrame.duration, deprecate AVFrame.pkt_duration. diff --git a/libavutil/version.h b/libavutil/version.h index ee4c531b80..e9eefcdb2c 100644 --- a/libavutil/version.h +++ b/libavutil/version.h @@ -79,7 +79,7 @@ */ #define LIBAVUTIL_VERSION_MAJOR 57 -#define LIBAVUTIL_VERSION_MINOR 30 +#define LIBAVUTIL_VERSION_MINOR 31 #define LIBAVUTIL_VERSION_MICRO 100 #define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \ -- ffmpeg-codebot ___ 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] [PATCH v3 2/4] avutils/hwcontext: add derive-device function which searches for existing devices in both directions
From: softworkz
The test /libavutil/tests/hwdevice checks that when deriving a device
from a source device and then deriving back to the type of the source
device, the result is matching the original source device, i.e. the
derivation mechanism doesn't create a new device in this case.
Previously, this test was usually passed, but only due to two different
kind of flaws:
1. The test covers only a single level of derivation (and back)
It derives device Y from device X and then Y back to the type of X and
checks whether the result matches X.
What it doesn't check for, are longer chains of derivation like:
CUDA1 > OpenCL2 > CUDA3 and then back to OpenCL4
In that case, the second derivation returns the first device (CUDA3 ==
CUDA1), but when deriving OpenCL4, hwcontext.c was creating a new
OpenCL4 context instead of returning OpenCL2, because there was no link
from CUDA1 to OpenCL2 (only backwards from OpenCL2 to CUDA1)
If the test would check for two levels of derivation, it would have
failed.
This patch fixes those (yet untested) cases by introducing forward
references (derived_device) in addition to the existing back references
(source_device).
2. hwcontext_qsv didn't properly set the source_device
In case of QSV, hwcontext_qsv creates a source context internally
(vaapi, dxva2 or d3d11va) without calling av_hwdevice_ctx_create_derived
and without setting source_device.
This way, the hwcontext test ran successful, but what practically
happened, was that - for example - deriving vaapi from qsv didn't return
the original underlying vaapi device and a new one was created instead:
Exactly what the test is intended to detect and prevent. It just
couldn't do so, because the original device was hidden (= not set as the
source_device of the QSV device).
This patch properly makes these setting and fixes all derivation
scenarios.
(at a later stage, /libavutil/tests/hwdevice should be extended to check
longer derivation chains as well)
Signed-off-by: softworkz
---
libavutil/hwcontext.c | 167 +++--
libavutil/hwcontext.h | 20
libavutil/hwcontext_internal.h | 11 +++
libavutil/hwcontext_qsv.c | 11 ++-
4 files changed, 199 insertions(+), 10 deletions(-)
diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
index ab9ad3703e..43e39cb2d3 100644
--- a/libavutil/hwcontext.c
+++ b/libavutil/hwcontext.c
@@ -22,12 +22,17 @@
#include "buffer.h"
#include "common.h"
#include "hwcontext.h"
+
+#include
+
+#include "buffer_internal.h"
#include "hwcontext_internal.h"
#include "imgutils.h"
#include "log.h"
#include "mem.h"
#include "pixdesc.h"
#include "pixfmt.h"
+#include "thread.h"
static const HWContextType * const hw_table[] = {
#if CONFIG_CUDA
@@ -80,6 +85,84 @@ static const char *const hw_type_names[] = {
[AV_HWDEVICE_TYPE_VULKAN] = "vulkan",
};
+#define DEVICE_REGISTRY_SIZE 1024
+
+static AVMutex mutex;
+static int is_mutex_initialized = 0;
+static int max_device_reg_id = 1;
+static AVBuffer *hw_device_registry[DEVICE_REGISTRY_SIZE];
+
+static int register_hw_device(const AVBufferRef *ref)
+{
+AVHWDeviceContext *ctx = (AVHWDeviceContext*)ref->data;
+const int reg_id = max_device_reg_id;
+
+if (ctx == NULL)
+return AVERROR(EINVAL);
+
+if (!is_mutex_initialized) {
+int ret;
+ret = ff_mutex_init(, NULL);
+if (ret) {
+av_log(ctx, AV_LOG_ERROR, "hwcontext: mutex initialization failed!
Error code: %d\n", ret);
+return AVERROR(EINVAL);
+}
+
+is_mutex_initialized = 1;
+}
+
+ff_mutex_lock();
+
+for (int i = 0; i < max_device_reg_id; ++i) {
+if (hw_device_registry[i] != NULL && hw_device_registry[i] ==
ref->buffer) {
+ff_mutex_unlock();
+return i;
+}
+}
+
+if (max_device_reg_id >= DEVICE_REGISTRY_SIZE) {
+ff_mutex_unlock();
+av_log(ctx, AV_LOG_ERROR, "Device registry limit (%d) reached. Please
check for excessive device creation.", DEVICE_REGISTRY_SIZE);
+return AVERROR(ENOMEM);
+}
+
+hw_device_registry[reg_id] = ref->buffer;
+max_device_reg_id++;
+
+ff_mutex_unlock();
+
+return reg_id;
+}
+
+static void unregister_hw_device(const AVHWDeviceContext *ctx)
+{
+if (ctx == NULL || !is_mutex_initialized)
+return;
+
+ff_mutex_lock();
+
+hw_device_registry[ctx->internal->registered_device_id] = NULL;
+
+ff_mutex_unlock();
+}
+
+static AVBufferRef *get_registered_hw_device(int registered_id)
+{
+if (registered_id <= 0 || registered_id >= max_device_reg_id)
+return NULL;
+
+ff_mutex_lock();
+
+if (hw_device_registry[registered_id] != NULL &&
hw_device_registry[registered_id]->data != NULL) {
+AVBufferRef *ref =
av_ref_from_buffer(hw_device_registry[registered_id]);
+return ref;
+}
+
+ff_mutex_unlock();
+
+return NULL;
+}
+
enum AVHWDeviceType av_hwdevice_find_type_by_name(const
[FFmpeg-devel] [PATCH v3 1/4] avutil/buffer: add av_ref_from_buffer() function
From: softworkz
This allows to create AVBufferRef from AVBuffer directly.
Signed-off-by: softworkz
---
libavutil/buffer.c | 16
libavutil/buffer.h | 8
2 files changed, 24 insertions(+)
diff --git a/libavutil/buffer.c b/libavutil/buffer.c
index 54590be566..f9df0ad6ea 100644
--- a/libavutil/buffer.c
+++ b/libavutil/buffer.c
@@ -100,6 +100,22 @@ AVBufferRef *av_buffer_allocz(size_t size)
return ret;
}
+AVBufferRef *av_ref_from_buffer(AVBuffer *buf)
+{
+AVBufferRef *ref = av_mallocz(sizeof(*ref));
+
+if (!ref)
+return NULL;
+
+ref->buffer = buf;
+ref->data = buf->data;
+ref->size = buf->size;
+
+atomic_fetch_add_explicit(>refcount, 1, memory_order_relaxed);
+
+return ref;
+}
+
AVBufferRef *av_buffer_ref(const AVBufferRef *buf)
{
AVBufferRef *ret = av_mallocz(sizeof(*ret));
diff --git a/libavutil/buffer.h b/libavutil/buffer.h
index e1ef5b7f07..491734b9ca 100644
--- a/libavutil/buffer.h
+++ b/libavutil/buffer.h
@@ -139,6 +139,14 @@ AVBufferRef *av_buffer_create(uint8_t *data, size_t size,
*/
void av_buffer_default_free(void *opaque, uint8_t *data);
+/**
+ * Create a new reference to an AVBuffer.
+ *
+ * @return a new AVBufferRef referring to the same AVBuffer as buf or NULL on
+ * failure.
+ */
+AVBufferRef *av_ref_from_buffer(AVBuffer *buf);
+
/**
* Create a new reference to an AVBuffer.
*
--
ffmpeg-codebot
___
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] [PATCH v3 0/4] Add derive-device function which searches for existing devices in both directions
This is an updated version of: [PATCH v4 1/1] avutils/hwcontext: When deriving a hwdevice, search for existing device in both directions There has been an objection that the earlier patchset would change API behavior, and that this change should be limited to ffmpeg cli. To achieve this, the API behavior is left unchanged now and a new function av_hwdevice_ctx_get_or_create_derived() is added and used by the hwupload and hwmap filters. v2: Implemented concept for "weak references" to avoid circular reference lockup. v3: rebased due to conflicts softworkz (4): avutil/buffer: add av_ref_from_buffer() function avutils/hwcontext: add derive-device function which searches for existing devices in both directions lavu: bump minor version and add doc/APIchanges entry for av_hwdevice_ctx_get_or_create_derived() avfilter/hwmap,hwupload: use new av_hwdevice_ctx_get_or_create_derived method doc/APIchanges | 6 ++ libavfilter/vf_hwmap.c | 4 +- libavfilter/vf_hwupload.c | 2 +- libavutil/buffer.c | 16 libavutil/buffer.h | 8 ++ libavutil/hwcontext.c | 167 +++-- libavutil/hwcontext.h | 20 libavutil/hwcontext_internal.h | 11 +++ libavutil/hwcontext_qsv.c | 11 ++- libavutil/version.h| 2 +- 10 files changed, 233 insertions(+), 14 deletions(-) base-commit: f7d510b33ff33d2f5cb096017ee1c00f624cc138 Published-As: https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-25%2Fsoftworkz%2Fderive_devices-v3 Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging-25/softworkz/derive_devices-v3 Pull-Request: https://github.com/ffstaging/FFmpeg/pull/25 Range-diff vs v2: 1: e9c920c237 = 1: b17a72426c avutil/buffer: add av_ref_from_buffer() function 2: bec8ccfcc2 = 2: 5cd017dfa7 avutils/hwcontext: add derive-device function which searches for existing devices in both directions 3: a2c8e79e8a ! 3: 03528fce43 lavu: bump minor version and add doc/APIchanges entry for av_hwdevice_ctx_get_or_create_derived() @@ doc/APIchanges: libavutil: 2021-04-27 API changes, most recent first: -+2022-05-21 - xx - lavu 57.25.100 - hwcontext.h ++2022-07-01 - xx - lavu 57.31.100 - hwcontext.h + Add av_hwdevice_ctx_get_or_create_derived(). + -+2022-04-30 - xx - lavu 57.25.100 - buffer.h ++2022-07-01 - xx - lavu 57.31.100 - buffer.h + Add av_ref_from_buffer(). + - 2022-03-16 - xx - all libraries - version_major.h - Add lib/version_major.h as new installed headers, which only - contain the major version number (and corresponding API deprecation + 2022-07-xx - xx - lavu 57.30.100 - frame.h + Add AVFrame.duration, deprecate AVFrame.pkt_duration. + ## libavutil/version.h ## @@ */ #define LIBAVUTIL_VERSION_MAJOR 57 --#define LIBAVUTIL_VERSION_MINOR 24 --#define LIBAVUTIL_VERSION_MICRO 101 -+#define LIBAVUTIL_VERSION_MINOR 25 -+#define LIBAVUTIL_VERSION_MICRO 100 +-#define LIBAVUTIL_VERSION_MINOR 30 ++#define LIBAVUTIL_VERSION_MINOR 31 + #define LIBAVUTIL_VERSION_MICRO 100 #define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \ -LIBAVUTIL_VERSION_MINOR, \ 4: d0957afde6 = 4: 7ee28b7c25 avfilter/hwmap,hwupload: use new av_hwdevice_ctx_get_or_create_derived method -- ffmpeg-codebot ___ 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 v11 10/13] lavu/hwcontext_qsv: make qsv hwdevice works with oneVPL
On 20/07/2022 09:40, Xiang, Haihao wrote:
From: Haihao Xiang
In oneVPL, MFXLoad() and MFXCreateSession() are required to create a
workable mfx session[1]
Add config filters for D3D9/D3D11 session (galinart)
The default device is changed to d3d11va for oneVPL when both d3d11va
and dxva2 are enabled on Microsoft Windows
This is in preparation for oneVPL support
[1]
https://spec.oneapi.io/versions/latest/elements/oneVPL/source/programming_guide/VPL_prg_session.html#onevpl-dispatcher
Co-authored-by: galinart
Signed-off-by: galinart
Signed-off-by: Haihao Xiang
---
libavutil/hwcontext_qsv.c | 531 +++---
1 file changed, 493 insertions(+), 38 deletions(-)
diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
index 21a2a805f8..90b7988dec 100644
--- a/libavutil/hwcontext_qsv.c
+++ b/libavutil/hwcontext_qsv.c
...
+
+static int qsv_va_update_config(void *ctx, mfxHDL handle, mfxConfig cfg)
+{
+#if CONFIG_VAAPI
+#if VA_CHECK_VERSION(1, 5, 0)
+#define LOCAL_VADISPLAYPCIID VADisplayPCIID
+#else
+#define LOCAL_VADISPLAYPCIID 21
+#endif
This seems to be handling the case where you built the driver against a newer
version of libva containing the field but then downgraded it before building
ffmpeg? Who are you expecting to do that?
+mfxStatus sts;
+VADisplay dpy = handle;
+VAStatus vas;
+VADisplayAttribute attr = {
+.type = LOCAL_VADISPLAYPCIID
+};
+mfxVariant impl_value;
+
+vas = vaGetDisplayAttributes(dpy, , 1);
+if (vas == VA_STATUS_SUCCESS && attr.flags !=
VA_DISPLAY_ATTRIB_NOT_SUPPORTED) {
+impl_value.Type = MFX_VARIANT_TYPE_U16;
+impl_value.Data.U16 = (attr.value & 0x);
+sts = MFXSetConfigFilterProperty(cfg,
+ (const mfxU8
*)"mfxExtendedDeviceId.DeviceID", impl_value);
+if (sts != MFX_ERR_NONE) {
+av_log(ctx, AV_LOG_ERROR, "Error adding a MFX configuration"
+ "DeviceID property: %d.\n", sts);
+goto fail;
+}
+} else {
+av_log(ctx, AV_LOG_ERROR, "Failed to get device id from the driver. Please
"
+ "consider to upgrade the driver to support VA-API 1.5.0. \n");
+goto fail;
+}
The use of the PCI ID doesn't make sense to me here?
A PCI ID tells you the type of the device, not which device it was - given that
the normal use-case for multiple devices in servers generally has lots of
idential ones this does not seem helpful.
+
+return 0;
+
+fail:
+#endif
+return AVERROR_UNKNOWN;
+}
+
...
- 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".
Re: [FFmpeg-devel] [PATCH v5 0/6] Implement SEI parsing for QSV decoders
Xiang, Haihao: > On Fri, 2022-07-01 at 20:48 +, ffmpegagent wrote: >> Missing SEI information has always been a major drawback when using the QSV >> decoders. I used to think that there's no chance to get at the data without >> explicit implementation from the MSDK side (or doing something weird like >> parsing in parallel). It turned out that there's a hardly known api method >> that provides access to all SEI (h264/hevc) or user data (mpeg2video). >> >> This allows to get things like closed captions, frame packing, display >> orientation, HDR data (mastering display, content light level, etc.) without >> having to rely on those data being provided by the MSDK as extended buffers. >> >> The commit "Implement SEI parsing for QSV decoders" includes some hard-coded >> workarounds for MSDK bugs which I reported: >> > https://github.com/Intel-Media-SDK/MediaSDK/issues/2597#issuecomment-1072795311 >> >> But that doesn't help. Those bugs exist and I'm sharing my workarounds, >> which are empirically determined by testing a range of files. If someone is >> interested, I can provide private access to a repository where we have been >> testing this. Alternatively, I could also leave those workarounds out, and >> just skip those SEI types. >> >> In a previous version of this patchset, there was a concern that payload >> data might need to be re-ordered. Meanwhile I have researched this carefully >> and the conclusion is that this is not required. >> >> My detailed analysis can be found here: >> https://gist.github.com/softworkz/36c49586a8610813a32270ee3947a932 >> >> v4 >> >> * add new dependencies in makefile Now, build still works when someone uses >>configure --disable-decoder=h264 --disable-decoder=hevc >>--disable-decoder=mpegvideo --disable-decoder=mpeg1video >>--disable-decoder=mpeg2video --enable-libmfx >> >> v3 >> >> * frame.h: clarify doc text for av_frame_copy_side_data() >> >> v2 >> >> * qsvdec: make error handling consistent and clear >> * qsvdec: remove AV_CODEC_ID_MPEG1VIDEO constants >> * hevcdec: rename function to ff_hevc_set_side_data(), add doc text >> >> v3 >> >> * qsvdec: fix c/p error >> >> softworkz (6): >> avutil/frame: Add av_frame_copy_side_data() and >> av_frame_remove_all_side_data() >> avcodec/vpp_qsv: Copy side data from input to output frame >> avcodec/mpeg12dec: make mpeg_decode_user_data() accessible >> avcodec/hevcdec: make set_side_data() accessible >> avcodec/h264dec: make h264_export_frame_props() accessible >> avcodec/qsvdec: Implement SEI parsing for QSV decoders >> >> doc/APIchanges | 4 + >> libavcodec/Makefile | 6 +- >> libavcodec/h264_slice.c | 98 --- >> libavcodec/h264dec.h | 2 + >> libavcodec/hevcdec.c | 117 +- >> libavcodec/hevcdec.h | 9 ++ >> libavcodec/hevcdsp.c | 4 + >> libavcodec/mpeg12.h | 28 + >> libavcodec/mpeg12dec.c | 40 +- >> libavcodec/qsvdec.c | 234 +++ >> libavfilter/qsvvpp.c | 6 + >> libavfilter/vf_overlay_qsv.c | 19 ++- >> libavutil/frame.c| 67 ++ >> libavutil/frame.h| 32 + >> libavutil/version.h | 2 +- >> 15 files changed, 494 insertions(+), 174 deletions(-) >> >> >> base-commit: 6a82412bf33108111eb3f63076fd5a51349ae114 >> Published-As: >> https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-31%2Fsoftworkz%2Fsubmit_qsv_sei-v5 >> Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging- >> 31/softworkz/submit_qsv_sei-v5 >> Pull-Request: https://github.com/ffstaging/FFmpeg/pull/31 >> >> Range-diff vs v4: >> >> 1: 7656477360 = 1: 7656477360 avutil/frame: Add av_frame_copy_side_data() >> and av_frame_remove_all_side_data() >> 2: 06976606c5 = 2: 06976606c5 avcodec/vpp_qsv: Copy side data from input >> to >> output frame >> 3: 320a8a535c = 3: 320a8a535c avcodec/mpeg12dec: make >> mpeg_decode_user_data() accessible >> 4: e58ad6564f = 4: e58ad6564f avcodec/hevcdec: make set_side_data() >> accessible >> 5: a57bfaebb9 = 5: 4c0b6eb4cb avcodec/h264dec: make >> h264_export_frame_props() accessible >> 6: 3f2588563e ! 6: 19bc00be4d avcodec/qsvdec: Implement SEI parsing for >> QSV >> decoders >> @@ Commit message >> >> Signed-off-by: softworkz >> >> + ## libavcodec/Makefile ## >> +@@ libavcodec/Makefile: OBJS-$(CONFIG_MSS34DSP)+= >> mss34dsp.o >> + OBJS-$(CONFIG_PIXBLOCKDSP) += pixblockdsp.o >> + OBJS-$(CONFIG_QPELDSP) += qpeldsp.o >> + OBJS-$(CONFIG_QSV) += qsv.o >> +-OBJS-$(CONFIG_QSVDEC) += qsvdec.o >> ++OBJS-$(CONFIG_QSVDEC) += qsvdec.o h264_slice.o >> h264_cabac.o h264_cavlc.o \ >> ++ h264_direct.o h264_mb.o >> h264_picture.o
Re: [FFmpeg-devel] [PATCH 2/5] lavc/aarch64: Add neon implementation for sse4
On Fri, 15 Jul 2022, Hubert Mazur wrote:
Provide neon implementation for sse4 function.
Performance comparison tests are shown below.
- sse_2_c: 74.0
- sse_2_neon: 24.0
Benchmarks and tests are run with checkasm tool on AWS Graviton 3.
Signed-off-by: Hubert Mazur
---
libavcodec/aarch64/me_cmp_init_aarch64.c | 3 ++
libavcodec/aarch64/me_cmp_neon.S | 65
2 files changed, 68 insertions(+)
diff --git a/libavcodec/aarch64/me_cmp_init_aarch64.c
b/libavcodec/aarch64/me_cmp_init_aarch64.c
index 3ff5767bd0..72a2062e7e 100644
--- a/libavcodec/aarch64/me_cmp_init_aarch64.c
+++ b/libavcodec/aarch64/me_cmp_init_aarch64.c
@@ -32,6 +32,8 @@ int ff_pix_abs16_x2_neon(MpegEncContext *v, uint8_t *pix1,
uint8_t *pix2,
int sse16_neon(MpegEncContext *v, uint8_t *pix1, uint8_t *pix2,
ptrdiff_t stride, int h);
+int sse4_neon(MpegEncContext *v, uint8_t *pix1, uint8_t *pix2,
+ ptrdiff_t stride, int h);
av_cold void ff_me_cmp_init_aarch64(MECmpContext *c, AVCodecContext *avctx)
{
@@ -44,5 +46,6 @@ av_cold void ff_me_cmp_init_aarch64(MECmpContext *c,
AVCodecContext *avctx)
c->sad[0] = ff_pix_abs16_neon;
c->sse[0] = sse16_neon;
+c->sse[2] = sse4_neon;
}
}
diff --git a/libavcodec/aarch64/me_cmp_neon.S b/libavcodec/aarch64/me_cmp_neon.S
index 88cd335443..bacf151314 100644
--- a/libavcodec/aarch64/me_cmp_neon.S
+++ b/libavcodec/aarch64/me_cmp_neon.S
@@ -360,3 +360,68 @@ function sse16_neon, export=1
ret
endfunc
+
+function sse4_neon, export=1
+// x0 - unused
+// x1 - pix1
+// x2 - pix2
+// x3 - stride
+// w4 - h
+
+movid18, #0
+movid17, #0
+cmp w4, #4
+b.le2f
+
+// make 4 iterations at once
+1:
+
+// res = abs(pix1[0] - pix2[0])
+// res * res
+
+ld1 {v0.4b}, [x1], x3
This fails to assemble for me with essentially all tools I have (old
binutils, moderately recent binutils, current llvm, MS armasm64.exe):
src/libavcodec/aarch64/me_cmp_neon.S:374: Error: operand mismatch -- `ld1
{v0.4b},[x1],x3'
src/libavcodec/aarch64/me_cmp_neon.S:374: Info:did you mean this?
src/libavcodec/aarch64/me_cmp_neon.S:374: Info: ld1 {v0.8b}, [x1], x3
src/libavcodec/aarch64/me_cmp_neon.S:374: Info:other valid variant(s):
src/libavcodec/aarch64/me_cmp_neon.S:374: Info: ld1 {v0.16b}, [x1], x3
src/libavcodec/aarch64/me_cmp_neon.S:374: Info: ld1 {v0.4h}, [x1], x3
src/libavcodec/aarch64/me_cmp_neon.S:374: Info: ld1 {v0.8h}, [x1], x3
src/libavcodec/aarch64/me_cmp_neon.S:374: Info: ld1 {v0.2s}, [x1], x3
src/libavcodec/aarch64/me_cmp_neon.S:374: Info: ld1 {v0.4s}, [x1], x3
src/libavcodec/aarch64/me_cmp_neon.S:374: Info: ld1 {v0.1d}, [x1], x3
src/libavcodec/aarch64/me_cmp_neon.S:374: Info: ld1 {v0.2d}, [x1], x3
I'll follow up with an actual review of the patches later. I'm sorry I
have a bit longer review latency than usual at the moment, as I'm on
vacation.
// Martin
___
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 3/8] avutil/mem: Add av_fast_realloc_array()
tis 2022-07-12 klockan 16:12 +0200 skrev Andreas Rheinhardt:
>
> Anton really dislikes the av_fast_* naming and instead wants this to
> be
> called av_realloc_array_reuse(). I don't care either way. Any more
> opinions on this (or on the patch itself)?
That's going to cause some "impedance mismatch" given that the other
functions are still called fast rather than reuse, and changing that
would requite a major bump.
Ideally we'd come up with a coherent naming scheme for all of these
functions because frankly it's a mess at the moment. I tried
summarizing all functions in a spreadsheet, and there's a lot of gaps
functionality wise. Best solution would be to write the cartesian
product of all features in one go, with an accompanying coherent naming
scheme.
{pointer, pointer-to-pointer} * {don't care what the data is, copy old
data, copy and zero newly allocated memory, zero entire buffer} * {size
in bytes, nelem*elemsize}
/Tomas
___
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 v5 0/6] Implement SEI parsing for QSV decoders
> -Original Message- > From: Xiang, Haihao > Sent: Tuesday, July 19, 2022 8:55 AM > To: ffmpeg-devel@ffmpeg.org > Cc: andreas.rheinha...@outlook.com; kier...@obe.tv; haihao.xiang-at- > intel@ffmpeg.org; softwo...@hotmail.com > Subject: Re: [FFmpeg-devel] [PATCH v5 0/6] Implement SEI parsing for > QSV decoders > > On Fri, 2022-07-01 at 20:48 +, ffmpegagent wrote: > > Missing SEI information has always been a major drawback when using > the QSV > > decoders. I used to think that there's no chance to get at the data > without > > explicit implementation from the MSDK side (or doing something > weird like > > parsing in parallel). It turned out that there's a hardly known api > method > > that provides access to all SEI (h264/hevc) or user data > (mpeg2video). > > > > This allows to get things like closed captions, frame packing, > display > > orientation, HDR data (mastering display, content light level, > etc.) without > > having to rely on those data being provided by the MSDK as extended > buffers. > > > > The commit "Implement SEI parsing for QSV decoders" includes some > hard-coded > > workarounds for MSDK bugs which I reported: > > > https://github.com/Intel-Media-SDK/MediaSDK/issues/2597#issuecomment- > 1072795311 > > > > But that doesn't help. Those bugs exist and I'm sharing my > workarounds, > > which are empirically determined by testing a range of files. If > someone is > > interested, I can provide private access to a repository where we > have been > > testing this. Alternatively, I could also leave those workarounds > out, and > > just skip those SEI types. > > > > In a previous version of this patchset, there was a concern that > payload > > data might need to be re-ordered. Meanwhile I have researched this > carefully > > and the conclusion is that this is not required. > > > > My detailed analysis can be found here: > > https://gist.github.com/softworkz/36c49586a8610813a32270ee3947a932 > > > > v4 > > > > * add new dependencies in makefile Now, build still works when > someone uses > >configure --disable-decoder=h264 --disable-decoder=hevc > >--disable-decoder=mpegvideo --disable-decoder=mpeg1video > >--disable-decoder=mpeg2video --enable-libmfx > > > > v3 > > > > * frame.h: clarify doc text for av_frame_copy_side_data() > > > > v2 > > > > * qsvdec: make error handling consistent and clear > > * qsvdec: remove AV_CODEC_ID_MPEG1VIDEO constants > > * hevcdec: rename function to ff_hevc_set_side_data(), add doc > text > > > > v3 > > > > * qsvdec: fix c/p error > > > > softworkz (6): > > avutil/frame: Add av_frame_copy_side_data() and > > av_frame_remove_all_side_data() > > avcodec/vpp_qsv: Copy side data from input to output frame > > avcodec/mpeg12dec: make mpeg_decode_user_data() accessible > > avcodec/hevcdec: make set_side_data() accessible > > avcodec/h264dec: make h264_export_frame_props() accessible > > avcodec/qsvdec: Implement SEI parsing for QSV decoders > > > > doc/APIchanges | 4 + > > libavcodec/Makefile | 6 +- > > libavcodec/h264_slice.c | 98 --- > > libavcodec/h264dec.h | 2 + > > libavcodec/hevcdec.c | 117 +- > > libavcodec/hevcdec.h | 9 ++ > > libavcodec/hevcdsp.c | 4 + > > libavcodec/mpeg12.h | 28 + > > libavcodec/mpeg12dec.c | 40 +- > > libavcodec/qsvdec.c | 234 > +++ > > libavfilter/qsvvpp.c | 6 + > > libavfilter/vf_overlay_qsv.c | 19 ++- > > libavutil/frame.c| 67 ++ > > libavutil/frame.h| 32 + > > libavutil/version.h | 2 +- > > 15 files changed, 494 insertions(+), 174 deletions(-) > > > > > > base-commit: 6a82412bf33108111eb3f63076fd5a51349ae114 > > Published-As: > > https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging- > 31%2Fsoftworkz%2Fsubmit_qsv_sei-v5 > > Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr- > ffstaging- > > 31/softworkz/submit_qsv_sei-v5 > > Pull-Request: https://github.com/ffstaging/FFmpeg/pull/31 > > > > Range-diff vs v4: > > > > 1: 7656477360 = 1: 7656477360 avutil/frame: Add > av_frame_copy_side_data() > > and av_frame_remove_all_side_data() > > 2: 06976606c5 = 2: 06976606c5 avcodec/vpp_qsv: Copy side data > from input to > > output frame > > 3: 320a8a535c = 3: 320a8a535c avcodec/mpeg12dec: make > > mpeg_decode_user_data() accessible > > 4: e58ad6564f = 4: e58ad6564f avcodec/hevcdec: make > set_side_data() > > accessible > > 5: a57bfaebb9 = 5: 4c0b6eb4cb avcodec/h264dec: make > > h264_export_frame_props() accessible > > 6: 3f2588563e ! 6: 19bc00be4d avcodec/qsvdec: Implement SEI > parsing for QSV > > decoders > > @@ Commit message > > > > Signed-off-by: softworkz > > > > + ## libavcodec/Makefile ## > > +@@ libavcodec/Makefile: OBJS-$(CONFIG_MSS34DSP) > += > > mss34dsp.o > > +
Re: [FFmpeg-devel] [PATCH v2 3/3] hwcontext_vaapi: #if guard VAAPI_DRM specifics
On 20/07/2022 11:56, Emil Velikov wrote: From: Emil Velikov Similar to the VAAPI_X11 bits, guard all the VAAPI_DRM parts behind a compiler guard. Signed-off-by: Emil Velikov --- libavutil/hwcontext_vaapi.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c index 7734a50fc0..7aea3e7b96 100644 --- a/libavutil/hwcontext_vaapi.c +++ b/libavutil/hwcontext_vaapi.c @@ -18,6 +18,10 @@ #include "config.h" +#if !HAVE_VAAPI_X11 && !HAVE_VAAPI_DRM +#error "At least one VAAPI winsys is required X11 or DRM" No it isn't. Originally there wasn't a possibility to link with any winsys here - libavcodec users had to get the device themselves and pass it in. The winsys link was added to the ffmpeg utility initially for command-line use and then moved to libavutil when it was clear that it would be useful to other library users; there isn't any requirement to use it, though. (E.g. disable it and note that programs handling the winsys themselves like mpv and vlc still work perfectly well.) - 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".
Re: [FFmpeg-devel] [PATCH v2 0/3] hwcontext_vaapi: dlopen libva-x11 and libva-drm
On 20/07/2022 17:41, Emil Velikov wrote: On Tue, 19 Jul 2022 at 19:16, Nicolas George wrote: Emil Velikov (12022-07-19): As you may know the libva* set of libraries share an internal ABI between them. In a resent libva commit, the va_fool API was removed. Thus if one is to mix different versions of libva.so and libva-x11.so they will get an error, leading to a crash of the whole stack. The simple solution is ... a configure check. If the person who installs replaces a library with another, it is their responsibility to check they are compatible. While I wholeheartedly agree, it's not so easy to enforce compile time decisions at runtime. In the past, I have debugged and reported issues where Linux distributions do not enforce the above. We do have the typical Linux distribution model (where we have dozens upon distros) and other distribution models. IMHO checking each instance and combination doesn't scale. We could bring awareness to the issue in say distribution/workflow X, which sadly may come as finger-pointing and thus alienating. Hope that makes sense and the team is willing to consider the extra 90 lines worth of code. The argument "libfoo can be broken in some particular configuration, so lets use dlopen() to make errors happen later" seems like it applies to every library. Why is this case so special? Who are the users running into this specific problem and who are stuck with broken versions they can't update? (Also, shouldn't lazy binding save people in this situation if they don't actually use the feature, as they presumably don't if barfing at runtime makes sense?) Tbh I don't think FFmpeg libraries are the right place to be putting this sort of workaround. 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".
Re: [FFmpeg-devel] [PATCH v10 10/13] lavu/hwcontext_qsv: make qsv hwdevice works with oneVPL
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Xiang, Haihao
> Sent: Tuesday, July 19, 2022 9:19 AM
> To: an...@khirnov.net; ffmpeg-devel@ffmpeg.org
> Cc: Galin, Artem
> Subject: Re: [FFmpeg-devel] [PATCH v10 10/13] lavu/hwcontext_qsv:
> make qsv hwdevice works with oneVPL
>
> On Mon, 2022-07-18 at 15:02 +0200, Anton Khirnov wrote:
> > Quoting Xiang, Haihao (2022-07-12 08:27:32)
> > > +static int qsv_va_update_config(void *ctx, mfxHDL handle,
> mfxConfig cfg)
> > > +{
> > > +#if CONFIG_VAAPI
> > > +#if VA_CHECK_VERSION(1, 5, 0)
> > > +#define LOCAL_VADISPLAYPCIID VADisplayPCIID
> > > +#else
> > > +#define LOCAL_VADISPLAYPCIID 21
> > > +#endif
> > > +mfxStatus sts;
> > > +VADisplay dpy = handle;
> > > +VAStatus vas;
> > > +VADisplayAttribute attr = {
> > > +.type = LOCAL_VADISPLAYPCIID
> > > +};
> > > +mfxVariant impl_value;
> > > +
> > > +vas = vaGetDisplayAttributes(dpy, , 1);
> > > +if (vas == VA_STATUS_SUCCESS && attr.flags !=
> > > VA_DISPLAY_ATTRIB_NOT_SUPPORTED) {
> > > +impl_value.Type = MFX_VARIANT_TYPE_U16;
> > > +impl_value.Data.U16 = (attr.value & 0x);
> > > +sts = MFXSetConfigFilterProperty(cfg,
> > > + (const mfxU8
> > > *)"mfxExtendedDeviceId.DeviceID", impl_value);
> > > +if (sts != MFX_ERR_NONE) {
> > > +av_log(ctx, AV_LOG_ERROR, "Error adding a MFX
> configuration"
> > > + "DeviceID property: %d.\n", sts);
> > > +goto fail;
> > > +}
> > > +} else
> > > +av_log(ctx, AV_LOG_WARNING, "Cannot get device id from
> the driver,
> > > the default "
> > > + "MFX implementation will be loaded for this
> device. Please
> > > consider to "
> > > + "upgrade the driver to support VAAPI 1.5.0. \n");
> >
> > I would still prefer to fail here. The user requested a specific
> device,
> > disregarding that request is evil.
>
> Thanks for the comment. There is only one available device for most
> users, so
> the default one and the given one from user should be the same,
> otherwise it
> won't work. I don't want to make them in trouble if they don't have a
> driver to
> support the new interface. However I agree with you it is a little
> evil to
> ignore the request. I'll update the patch to return error here.
I'm not a fan of that kind of automagic behavior. Quick success
experiences are surely desirable in general, but we also need to
consider the effects of such behavior - in this case, that would
mean: It doesn't really matter what a user specifies for the parameter,
because it will always work anyway.
In turn, users may start to think that their wrong command with the
wrong ID would be right, and then, in a subsequent command
use that wrong ID again in different context, where it might fail,
while in turn maximizing confusion.
When it is possible to internally retrieve potentially valid
values, why not output something useful like: "XXID failed, you
might want to try A, B or C" (or similar)?
Kind regards,
softworkz
___
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 5/6] avcodec/ffv1dec: consider run increase in minimal golomb frame size
Michael Niedermayer:
> On Thu, Jul 21, 2022 at 12:17:22AM +0200, Andreas Rheinhardt wrote:
>> Michael Niedermayer:
>>> On Tue, Jul 19, 2022 at 08:37:38AM -0300, James Almer wrote:
On 7/19/2022 8:34 AM, Michael Niedermayer wrote:
> Fixes: Timeout
> Fixes:
> 49160/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FFV1_fuzzer-5672826144686080
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/ffv1dec.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
> index 01ddcaa512..9bdac0be4e 100644
> --- a/libavcodec/ffv1dec.c
> +++ b/libavcodec/ffv1dec.c
> @@ -883,7 +883,11 @@ static int decode_frame(AVCodecContext *avctx,
> AVFrame *rframe,
> if (buf_size < avctx->width * avctx->height / (128*8))
> return AVERROR_INVALIDDATA;
> } else {
> -if (buf_size < avctx->height / 8)
> +int i;
for (int i...
>>>
>>> will apply with that change
>>>
>>> thx
>>>
>>
>> James' suggestion made you use an uninitialized i in the actual check;
>
> yes
>
>
>> and even the original check is wrong, as one can overrun ff_log2_run
>> (unless there is a check that I am not missing).
>
> Theres a check but its too late
>
>
>> So it seems to me that
>> reverting 15785e044ee1265464bb4f3ed727e2a8074f97b4 is appropriate.
>
> not against that but heres a quick fix attempt
>
I thought that it would be easier to backport the fix if it were one
patch; of course it was never my intention to force you to revert this.
>
> Author: Michael Niedermayer
> Date: Thu Jul 21 00:20:41 2022 +0200
>
> avcodec/ffv1dec: Fix AC_GOLOMB_RICE min size check
>
> Found-by: mkver
Please don't use my nickname in the future in commit messages.
>
> Signed-off-by: Michael Niedermayer
>
> diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
> index d71584505d..c6eca3227c 100644
> --- a/libavcodec/ffv1dec.c
> +++ b/libavcodec/ffv1dec.c
> @@ -884,9 +884,14 @@ static int decode_frame(AVCodecContext *avctx, AVFrame
> *rframe,
> return AVERROR_INVALIDDATA;
> } else {
> int w = avctx->width;
> -for (int i = 0; w > (1< +int s = 1 + w / (1<<23);
> +int i;
> +
> +w /= s;
> +
> +for (i = 0; w > (1< w -= ff_log2_run[i];
> -if (buf_size < (avctx->height + i + 6)/ 8)
> +if (buf_size < (avctx->height + s*i + 6)/ 8)
> return AVERROR_INVALIDDATA;
> }
>
>
>
___
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] [PATCH] avfilter/vf_showinfo: remove backspaces
They mess with storing editing and comparing the results Signed-off-by: Michael Niedermayer --- libavfilter/vf_showinfo.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c index 2c8514fc80..9b4a9fc981 100644 --- a/libavfilter/vf_showinfo.c +++ b/libavfilter/vf_showinfo.c @@ -733,12 +733,15 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *frame) av_log(ctx, AV_LOG_INFO, " %08"PRIX32, plane_checksum[plane]); av_log(ctx, AV_LOG_INFO, "] mean:["); for (plane = 0; plane < 4 && frame->data[plane] && frame->linesize[plane]; plane++) -av_log(ctx, AV_LOG_INFO, "%"PRId64" ", (sum[plane] + pixelcount[plane]/2) / pixelcount[plane]); -av_log(ctx, AV_LOG_INFO, "\b] stdev:["); +av_log(ctx, AV_LOG_INFO, "%s%"PRId64, + plane ? " ":"", + (sum[plane] + pixelcount[plane]/2) / pixelcount[plane]); +av_log(ctx, AV_LOG_INFO, "] stdev:["); for (plane = 0; plane < 4 && frame->data[plane] && frame->linesize[plane]; plane++) -av_log(ctx, AV_LOG_INFO, "%3.1f ", +av_log(ctx, AV_LOG_INFO, "%s%3.1f", + plane ? " ":"", sqrt((sum2[plane] - sum[plane]*(double)sum[plane]/pixelcount[plane])/pixelcount[plane])); -av_log(ctx, AV_LOG_INFO, "\b]"); +av_log(ctx, AV_LOG_INFO, "]"); } av_log(ctx, AV_LOG_INFO, "\n"); -- 2.17.1 ___ 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 3/6] avcodec/mss4: Check image size with av_image_check_size2()
On Sun, Jul 03, 2022 at 02:31:49AM +0200, Michael Niedermayer wrote: > Fixes: Timeout > Fixes: > 48418/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MTS2_fuzzer-4834851466903552 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/mss4.c | 4 > 1 file changed, 4 insertions(+) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time. signature.asc Description: PGP signature ___ 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 2/3] avformat/mpc8: Check and propagate more errors
On Mon, Jul 11, 2022 at 11:44:16PM +0200, Michael Niedermayer wrote: > Fixes: Timeout > Fixes: > 48846/clusterfuzz-testcase-minimized-ffmpeg_dem_MPC8_fuzzer-5278532493770752 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/mpc8.c | 40 +--- > 1 file changed, 25 insertions(+), 15 deletions(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Freedom in capitalist society always remains about the same as it was in ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin signature.asc Description: PGP signature ___ 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 3/3] avformat/flvdec: Check for EOF in index reading
On Tue, Jul 12, 2022 at 08:43:22PM +0200, Michael Niedermayer wrote: > Fixes: Timeout > Fixes: > 47992/clusterfuzz-testcase-minimized-ffmpeg_dem_LIVE_FLV_fuzzer-6020443879899136 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/flvdec.c | 2 ++ > 1 file changed, 2 insertions(+) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad signature.asc Description: PGP signature ___ 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 2/3] avformat/nutdec: Check get_packetheader() in mainheader
On Tue, Jul 12, 2022 at 08:43:21PM +0200, Michael Niedermayer wrote: > Fixes; Timeout > Fixes: > 48794/clusterfuzz-testcase-minimized-ffmpeg_dem_NUT_fuzzer-6524604713140224 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/nutdec.c | 2 ++ > 1 file changed, 2 insertions(+) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have often repented speaking, but never of holding my tongue. -- Xenocrates signature.asc Description: PGP signature ___ 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 1/2] avformat/mov: Check for EOF in mov_read_iloc()
On Wed, Jul 20, 2022 at 01:34:18AM +0200, Michael Niedermayer wrote: > Fixes: Timeout > Fixes: > 49216/clusterfuzz-testcase-minimized-ffmpeg_IO_DEMUXER_fuzzer-6563000529584128 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/mov.c | 2 ++ > 1 file changed, 2 insertions(+) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes signature.asc Description: PGP signature ___ 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 6/6] tools/target_dec_fuzzer: Adjust threshold for MWSC
On Tue, Jul 19, 2022 at 01:34:53PM +0200, Michael Niedermayer wrote: > Fixes: Timeout > Fixes: > 49172/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MWSC_fuzzer-5213749102903296 > > Signed-off-by: Michael Niedermayer > --- > tools/target_dec_fuzzer.c | 1 + > 1 file changed, 1 insertion(+) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data signature.asc Description: PGP signature ___ 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 2/6] avcodec/exr: Check x/ysize
On Tue, Jul 19, 2022 at 01:34:49PM +0200, Michael Niedermayer wrote: > Fixes: OOM > Fixes: > 48911/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EXR_fuzzer-6352002510094336 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/exr.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato signature.asc Description: PGP signature ___ 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 4/6] avformat/asfdec_f: Use 64bit for packet start time
On Tue, Jul 19, 2022 at 01:34:51PM +0200, Michael Niedermayer wrote: > Fixes: signed integer overflow: 2147483647 + 32 cannot be represented in type > 'int' > Fixes: > 49014/clusterfuzz-testcase-minimized-ffmpeg_dem_ASF_fuzzer-6314973315334144 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/asfdec_f.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong. signature.asc Description: PGP signature ___ 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] FFmpeg 5.1
On Thu, Jul 07, 2022 at 10:47:57PM +0200, Michael Niedermayer wrote: > On Tue, Jun 07, 2022 at 01:35:00PM +0200, Michael Niedermayer wrote: > > Hi all > > > > As was discussed previously the 5.1 release should be in june/july > > That means in the next weeks probably! > > If you know of any regressions, security issues or other major bugs, > > please help fixing them > > > > Also as was suggested before, this release will get the "LTS" tag > > unless people feel thats a bad idea of course > > i plan to branch 5.1 of master soon (in the next 3-7 days hopefully) > and do the release ~7 days afterwards. This assumes no major issues pop > up > if theres anything you are working on that i should wait for, reply here > and also (that one is important) tell me once you resolved the issue so i > dont have to guess from git commits if an issue got fully resolved its about 7 days since the branch, are there any remaining issues someone is working on ? if not ill make the release after applying and backporting a few more bugfixes that ive posted to the ML but not applied yet thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus signature.asc Description: PGP signature ___ 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 v2 4/4] avformat/argo_cvg: expose loop/reverb/checksum via metadata
On 21/7/22 08:00, Andreas Rheinhardt wrote: +if (av_dict_set_int(>metadata, "loop", ctx->header.loop, 0) < 0) +return AVERROR(ENOMEM); + +if (av_dict_set_int(>metadata, "reverb", ctx->header.reverb, 0) < 0) +return AVERROR(ENOMEM); + +if (av_dict_set_int(>metadata, "checksum", ctx->checksum, 0) < 0) +return AVERROR(ENOMEM); Don't second-guess error codes (unless you have a good reason to). Right, don't know why I did that... I'll apply in a few days (with the fixed return codes). ___ 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] libavformat/movenc: Is packets being more than INT_MAX apart always an error?
Wow! Thanks! That really works. I had no idea we could just play with timescale like that. On Wed, 20 Jul 2022 at 13:41, "zhilizhao(赵志立)" wrote: > > > > On Jul 20, 2022, at 8:18 PM, facefunk wrote: > > > > It's commonly the case with forced subtitle tracks that samples are more > > than INT_MAX microseconds (35m47.48s) apart. This being the case, packet > > duration will be deemed out of range by check_pkt and the packet dts set > to > > an incorrect value, even if pkt->duration is actually valid. > > > > I had begun working out how to inject extra packets to satisfy this check > > but I thought I would ask. Is this check necessary for mov_text packets? > > I think so, it’s still limited by the 32bits sample_delta in stts. > > On the other hand, I have an idea that a timescale like 100 can be used in > that case, which is 2^31/100/3600 = 5965 hours. > > > ___ > > 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". > ___ 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] lavf/sr: fix the segmentation fault caused by incorrect input frame free.
Kindly ping > -Original Message- > From: ffmpeg-devel On Behalf Of Paul B > Mahol > Sent: Monday, June 27, 2022 07:03 PM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH] lavf/sr: fix the segmentation fault caused > by incorrect input frame free. > > lgtm > ___ > 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".
[FFmpeg-devel] [PATCH V2] lavf/dnn: dump OpenVINO model input/output names to OVMdel struct.
Dump all input/output names to OVModel struct. In case other funcs use
them for reporting errors or locating issues.
Signed-off-by: Ting Fu
---
libavfilter/dnn/dnn_backend_openvino.c | 66 +++---
1 file changed, 48 insertions(+), 18 deletions(-)
diff --git a/libavfilter/dnn/dnn_backend_openvino.c
b/libavfilter/dnn/dnn_backend_openvino.c
index cf012aca4c..b494f26f55 100644
--- a/libavfilter/dnn/dnn_backend_openvino.c
+++ b/libavfilter/dnn/dnn_backend_openvino.c
@@ -58,6 +58,8 @@ typedef struct OVModel{
SafeQueue *request_queue; // holds OVRequestItem
Queue *task_queue; // holds TaskItem
Queue *lltask_queue; // holds LastLevelTaskItem
+const char *all_input_names;
+const char *all_output_names;
} OVModel;
// one request for one call to openvino
@@ -211,19 +213,9 @@ static void infer_completion_callback(void *args)
status = ie_infer_request_get_blob(request->infer_request,
task->output_names[0], _blob);
if (status != OK) {
-//incorrect output name
-char *model_output_name = NULL;
-char *all_output_names = NULL;
-size_t model_output_count = 0;
-av_log(ctx, AV_LOG_ERROR, "Failed to get model output data\n");
-status = ie_network_get_outputs_number(ov_model->network,
_output_count);
-for (size_t i = 0; i < model_output_count; i++) {
-status = ie_network_get_output_name(ov_model->network, i,
_output_name);
-APPEND_STRING(all_output_names, model_output_name)
-}
av_log(ctx, AV_LOG_ERROR,
"output \"%s\" may not correct, all output(s) are: \"%s\"\n",
- task->output_names[0], all_output_names);
+ task->output_names[0], ov_model->all_output_names);
return;
}
@@ -336,13 +328,23 @@ static int init_model_ov(OVModel *ov_model, const char
*input_name, const char *
// while we pass NHWC data from FFmpeg to openvino
status = ie_network_set_input_layout(ov_model->network, input_name, NHWC);
if (status != OK) {
-av_log(ctx, AV_LOG_ERROR, "Failed to set layout as NHWC for input
%s\n", input_name);
+if (status == NOT_FOUND) {
+av_log(ctx, AV_LOG_ERROR, "Could not find \"%s\" in model, failed
to set input layout as NHWC, "\
+ "all input(s) are: \"%s\"\n",
input_name, ov_model->all_input_names);
+} else{
+av_log(ctx, AV_LOG_ERROR, "Failed to set layout as NHWC for input
%s\n", input_name);
+}
ret = DNN_GENERIC_ERROR;
goto err;
}
status = ie_network_set_output_layout(ov_model->network, output_name,
NHWC);
if (status != OK) {
-av_log(ctx, AV_LOG_ERROR, "Failed to set layout as NHWC for output
%s\n", output_name);
+if (status == NOT_FOUND) {
+av_log(ctx, AV_LOG_ERROR, "Could not find \"%s\" in model, failed
to set output layout as NHWC, "\
+ "all output(s) are: \"%s\"\n",
input_name, ov_model->all_output_names);
+} else{
+av_log(ctx, AV_LOG_ERROR, "Failed to set layout as NHWC for output
%s\n", output_name);
+}
ret = DNN_GENERIC_ERROR;
goto err;
}
@@ -505,7 +507,6 @@ static int get_input_ov(void *model, DNNData *input, const
char *input_name)
OVModel *ov_model = model;
OVContext *ctx = _model->ctx;
char *model_input_name = NULL;
-char *all_input_names = NULL;
IEStatusCode status;
size_t model_input_count = 0;
dimensions_t dims;
@@ -538,15 +539,12 @@ static int get_input_ov(void *model, DNNData *input,
const char *input_name)
input->width= input_resizable ? -1 : dims.dims[3];
input->dt = precision_to_datatype(precision);
return 0;
-} else {
-//incorrect input name
-APPEND_STRING(all_input_names, model_input_name)
}
ie_network_name_free(_input_name);
}
-av_log(ctx, AV_LOG_ERROR, "Could not find \"%s\" in model, all input(s)
are: \"%s\"\n", input_name, all_input_names);
+av_log(ctx, AV_LOG_ERROR, "Could not find \"%s\" in model, all input(s)
are: \"%s\"\n", input_name, ov_model->all_input_names);
return AVERROR(EINVAL);
}
@@ -729,6 +727,8 @@ DNNModel *ff_dnn_load_model_ov(const char *model_filename,
DNNFunctionType func_
OVModel *ov_model = NULL;
OVContext *ctx = NULL;
IEStatusCode status;
+size_t node_count = 0;
+char *node_name = NULL;
model = av_mallocz(sizeof(DNNModel));
if (!model){
@@ -744,6 +744,8 @@ DNNModel *ff_dnn_load_model_ov(const char *model_filename,
DNNFunctionType func_
ov_model->model = model;
ov_model->ctx.class = _openvino_class;
ctx = _model->ctx;
+ov_model->all_input_names = NULL;
+ov_model->all_output_names = NULL;
//parse options
av_opt_set_defaults(ctx);
@@ -767,6 +769,34 @@ DNNModel
Re: [FFmpeg-devel] [PATCH 5/6] avcodec/ffv1dec: consider run increase in minimal golomb frame size
On Thu, Jul 21, 2022 at 12:46:38AM +0200, Michael Niedermayer wrote:
> On Thu, Jul 21, 2022 at 12:17:22AM +0200, Andreas Rheinhardt wrote:
> > Michael Niedermayer:
> > > On Tue, Jul 19, 2022 at 08:37:38AM -0300, James Almer wrote:
> > >>
> > >>
> > >> On 7/19/2022 8:34 AM, Michael Niedermayer wrote:
> > >>> Fixes: Timeout
> > >>> Fixes:
> > >>> 49160/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FFV1_fuzzer-5672826144686080
> > >>>
> > >>> Found-by: continuous fuzzing process
> > >>> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > >>> Signed-off-by: Michael Niedermayer
> > >>> ---
> > >>> libavcodec/ffv1dec.c | 6 +-
> > >>> 1 file changed, 5 insertions(+), 1 deletion(-)
> > >>>
> > >>> diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
> > >>> index 01ddcaa512..9bdac0be4e 100644
> > >>> --- a/libavcodec/ffv1dec.c
> > >>> +++ b/libavcodec/ffv1dec.c
> > >>> @@ -883,7 +883,11 @@ static int decode_frame(AVCodecContext *avctx,
> > >>> AVFrame *rframe,
> > >>> if (buf_size < avctx->width * avctx->height / (128*8))
> > >>> return AVERROR_INVALIDDATA;
> > >>> } else {
> > >>> -if (buf_size < avctx->height / 8)
> > >>> +int i;
> > >>
> > >> for (int i...
> > >
> > > will apply with that change
> > >
> > > thx
> > >
> >
> > James' suggestion made you use an uninitialized i in the actual check;
>
> yes
>
>
> > and even the original check is wrong, as one can overrun ff_log2_run
> > (unless there is a check that I am not missing).
>
> Theres a check but its too late
>
>
> > So it seems to me that
> > reverting 15785e044ee1265464bb4f3ed727e2a8074f97b4 is appropriate.
>
> not against that but heres a quick fix attempt
>
>
> Author: Michael Niedermayer
> Date: Thu Jul 21 00:20:41 2022 +0200
>
> avcodec/ffv1dec: Fix AC_GOLOMB_RICE min size check
will apply this so the uninitialized read is fixed. If this has
some off by 1 error or something that can be adjusted later
dont want to leave this bug open
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No great genius has ever existed without some touch of madness. -- Aristotle
signature.asc
Description: PGP signature
___
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".
