Re: [FFmpeg-devel] [PATCH 2/2] avcodec/h2645_parse: Check HEVC NAL size
On Sat, Apr 30, 2022 at 12:18:26AM +0200, Michael Niedermayer wrote: > Fixes: Assertion failure it was this av_assert1((get_bits_count(gb) % 8) == 0); that failed IIRC [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Rewriting code that is poorly written but fully understood is good. Rewriting code that one doesnt understand is a sign that one is less smart than the original author, trying to rewrite it will not make it better. 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 v11 1/6] libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and utf8toansi
> -Original Message- > From: ffmpeg-devel On Behalf Of nil- > admir...@mailo.com > Sent: Friday, April 29, 2022 8:52 PM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH v11 1/6] > libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and > utf8toansi > > > A code change for which no use case exists and does not provide > > any benefit is not relevant. That's my point. > > You've deleted me saying > > >> You're talking as if MAX_PATH limited library loader is self- > evidently > >> superior, and it is the loader that has no such limitation that has > to justify > >> its existence. As far as I'm concerned it just the other way > around. > > and now claim that code change is irrelevant. Yes, because there is no realistic case in which ffmpeg will need to load any dll from a long path. I've asked you multiple times to give an example. > > Imagine, you are creating a software (no matter whether you're big > or small, > > open or closed source, targeting business or home users, using a > custom or > > public built ffmpeg) and you bundle ffmpeg.exe with your software > like many > > are doing. Now, re-read my comments, maybe it will make more sense > to you. > > They do not. Customer ask for long path support and gets two > responses: > > 1. Enable long path support via registry once, and never care about it > again. > 2. Convert path to absolute and prefix it with \\?\ every time you use > our software. > > I don't see how second workaround can be any good at all. With the > first option, > customers can at least pressure Microsoft into making it a default So, ffmpeg should implement something that doesn't work without a registry change in order to "pressure Microsoft" to change it at some point in the future? > , if > registry tweak > is too much a hassle for them; with the second they're stuck with > workarounds—forever. I apologize when I have created the impression that ffmpeg should be left as is and users should continue adding the long path prefix themselves. I'm not opposed to adding support for long paths, I'm just opposed to the method. Implementing long path support by adding the prefix is not a "workaround". Those kinds of paths are part of OS functionality since Windows NT and will still work in Windows 20 or whatever may come. What IS a workaround is having to add the prefix manually to paths when using ffmpeg. You wrote > with the second they're stuck with > workarounds—forever. But it's just the other way round: Because with the first, you cannot rely that long paths are working, you would be stuck needing to continue prefixing paths manually "forever". (to also cover cases where it's not working) > > ffmpeg is already working pretty well in handling long file paths > (also with > > Unicode characters) when pre-fixing paths with \\?\ > > It handles them most of the time, but not always. I already mentioned > that the code from > https://ffmpeg.org/pipermail/ffmpeg-devel/2022-April/295568.html > explicitly converts all backslashes into forward slashes for unknown > reasons, > and that code will not work with \\?\ paths because //?/ is not a > valid prefix. IIRC this code is handling code paths relative to the executable path, and the executable doesn't run from a long path anyway. Nonetheless it might make sense to adjust that slash replacement for Windows. Same like you, I don't know why it has been added. > > This patchset does not provide reliable behavior. > > Actually it does. > > > This way, you won't be able to use long paths with ffmpeg within the > next 5-8 years at minimum, > > Long paths can be used since August, 2 2016. Some ~6 years have > already passed. You know what I meant: it's not activated by default. > > because even in the latest versions of Windows 11, this is not > enabled by > > default in the operating system. > > FFmpeg isn't bundled by default either. And not everyone has rights to > download and run arbitrary software on their machines. That's right, but that's not a question that matters because that's not in the hands of ffmpeg. What is in the hands of ffmpeg though, is requiring a change which needs administrative privileges or not. > > What is the value of adding a capability where it will be a lottery > > game whether it will work or not on each system? > > Windows 10 > 1607 + registry key = it works. Otherwise it doesn't. > There is no lottery. I don't want to argue about the term lottery. What I'm saying is that a solution is preferable which doesn't have an "Otherwise it doesn't" part. Best 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 v2 1/5] avutil/hwcontext_d3d11va: fix the uninitialized texture bindflag
> -Original Message- > From: ffmpeg-devel On Behalf Of > Hendrik Leppkes > Sent: Saturday, April 30, 2022 12:02 AM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH v2 1/5] avutil/hwcontext_d3d11va: > fix the uninitialized texture bindflag > > On Fri, Apr 29, 2022 at 12:45 PM Tong Wu > wrote: > > > > When uploading rawvideos using d3d11va hardware framecontext, the > bindflag > > is not initialized and will cause creating texture failure. Now fix > it, > > assign it the value of D3D11_BIND_RENDER_TARGET. > > > > As with similar fixes of this nature, this implicit behavior to fix > one particular bug does not seem fitting inside the hwcontext itself. > There can be a large list of usages of the hwcontext that all require > different BindFlags, but we can only define one default - why this one > specifically? I agree that this change is not ideal. On one side, it is "safe" in a way that a texture is practically unusable for video processing without having at least one of the flags (decoder, encoder or render_target), so this wouldn't "hurt" anybody. > So rather: > > Where is the context created? Looking at the command line in the commit message, this is about standalone D3D11 context creation. > Why is a required flag not set there? That would be better, because > that knows what flags it needs. There doesn't really exist an appropriate "there". I see two options 1. Add a generic internal device creation parameter to the dictionary in ffmpeg_hw.c like "standalone=1" (for all devices created via init_hw_device) Some time ago, I had another case where I thought this could be useful. Then, this could be used in d3d11va_device_create() to set an internal field 'default_bindflags' which would be used as condition in d3d11va_frames_init. The situation would remain similar though, as that when the device is used by a decoder (which sets the decoder flag) this needs to override the default. 2. Use a device parameter specific to the D3D11 hwcontext This would need to be specified in the command line. Everything else like in #1 What do you think? Best 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 v2 2/5] avutil/hwcontext_qsv: derive QSV frames to D3D11VA frames
> -Original Message-
> From: ffmpeg-devel On Behalf Of Tong
> Wu
> Sent: Friday, April 29, 2022 12:45 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Tong Wu
> Subject: [FFmpeg-devel] [PATCH v2 2/5] avutil/hwcontext_qsv: derive
> QSV frames to D3D11VA frames
>
> Fixes:
> $ ffmpeg.exe -y -hwaccel qsv -init_hw_device d3d11va=d3d11 \
> -init_hw_device qsv=qsv@d3d11 -c:v h264_qsv -i input.h264 \
> -vf "hwmap=derive_device=d3d11va,format=d3d11" -f null -
>
> Signed-off-by: Tong Wu
> ---
> libavutil/hwcontext_qsv.c | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
> index 66c0e38955..d9d05e936a 100644
> --- a/libavutil/hwcontext_qsv.c
> +++ b/libavutil/hwcontext_qsv.c
> @@ -808,12 +808,23 @@ static int
> qsv_frames_derive_from(AVHWFramesContext *dst_ctx,
> #if CONFIG_D3D11VA
> case AV_HWDEVICE_TYPE_D3D11VA:
> {
> +dst_ctx->initial_pool_size = src_ctx->initial_pool_size;
> AVD3D11VAFramesContext *dst_hwctx = dst_ctx->hwctx;
> -mfxHDLPair *pair = (mfxHDLPair*)src_hwctx-
> >surfaces[i].Data.MemId;
> -dst_hwctx->texture = (ID3D11Texture2D*)pair->first;
> +dst_hwctx->texture_infos = av_calloc(src_hwctx-
> >nb_surfaces,
> + sizeof(*dst_hwctx-
> >texture_infos));
> if (src_hwctx->frame_type & MFX_MEMTYPE_SHARED_RESOURCE)
> dst_hwctx->MiscFlags = D3D11_RESOURCE_MISC_SHARED;
> dst_hwctx->BindFlags =
> qsv_get_d3d11va_bind_flags(src_hwctx->frame_type);
> +for (i = 0; i < src_hwctx->nb_surfaces; i++) {
> +mfxHDLPair* pair = (mfxHDLPair*)src_hwctx-
> >surfaces[i].Data.MemId;
> +dst_hwctx->texture_infos[i].texture =
> (ID3D11Texture2D*)pair->first;
> +if (dst_hwctx->BindFlags & D3D11_BIND_RENDER_TARGET)
> {
> +dst_hwctx->texture_infos[i].index = 0;
> +}
> +else {
> +dst_hwctx->texture_infos[i].index =
> (intptr_t)pair->second;
> +}
> +}
> }
> break;
> #endif
> --
LGTM.
This has always been incomplete and untested since my original patchset.
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 v2 3/5] avutil/hwcontext_d3d11va: add a format check for staging texture
> -Original Message-
> From: ffmpeg-devel On Behalf Of Tong
> Wu
> Sent: Friday, April 29, 2022 12:45 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Tong Wu
> Subject: [FFmpeg-devel] [PATCH v2 3/5] avutil/hwcontext_d3d11va: add a
> format check for staging texture
>
> The texDesc.Format needs to be filled in with a corresponding format.
> I
> add a format check to initialize the format in case sometimes the
> ctx->internal->priv is not initialized, such as during the hwmap
> process.
ctx->internal->priv is D3D11VAFramesContext. When it wouldn't be
initialized, then hwmap couldn't work.
D3D11VAFramesContext.format is set during d3d11va_frames_init.
You would need to find out whether init is not called or
whether AVHWFramesContext.sw_format is not (yet) set during
init.
If that doesn't work out for some reason, I think the next best
solution would be to add a 'format parameter' to
d3d11va_create_staging_texture() and in d3d11va_transfer_data()
(the only caller) do ID3D11Texture2D_GetDesc() on the frame
texture ('texture' variable) and pass the returned format to
d3d11va_create_staging_texture()
Kind regards,
softworkz
>
> $ ffmpeg.exe -y -hwaccel qsv -init_hw_device d3d11va=d3d11 \
> -init_hw_device qsv=qsv@d3d11 -c:v h264_qsv \
> -i input.h264 -vf
> "hwmap=derive_device=d3d11va,format=d3d11,hwdownload,format=nv12" \
> -f null -
>
> Signed-off-by: Tong Wu
> ---
> libavutil/hwcontext_d3d11va.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/libavutil/hwcontext_d3d11va.c
> b/libavutil/hwcontext_d3d11va.c
> index db529acbb4..0ec0e07d3a 100644
> --- a/libavutil/hwcontext_d3d11va.c
> +++ b/libavutil/hwcontext_d3d11va.c
> @@ -349,6 +349,8 @@ static int
> d3d11va_create_staging_texture(AVHWFramesContext *ctx)
> AVD3D11VADeviceContext *device_hwctx = ctx->device_ctx->hwctx;
> D3D11VAFramesContext *s = ctx->internal->priv;
> HRESULT hr;
> +int i;
> +
> D3D11_TEXTURE2D_DESC texDesc = {
> .Width = ctx->width,
> .Height = ctx->height,
> @@ -360,6 +362,20 @@ static int
> d3d11va_create_staging_texture(AVHWFramesContext *ctx)
> .CPUAccessFlags = D3D11_CPU_ACCESS_READ |
> D3D11_CPU_ACCESS_WRITE,
> };
>
> +if (!texDesc.Format) {
> +for (i = 0; i < FF_ARRAY_ELEMS(supported_formats); i++) {
> +if (ctx->sw_format == supported_formats[i].pix_fmt) {
> +texDesc.Format = supported_formats[i].d3d_format;
> +break;
> +}
> +}
> +if (i == FF_ARRAY_ELEMS(supported_formats)) {
> +av_log(ctx, AV_LOG_ERROR, "Unsupported pixel format:
> %s\n",
> +av_get_pix_fmt_name(ctx->sw_format));
> +return AVERROR(EINVAL);
> +}
> +}
> +
> hr = ID3D11Device_CreateTexture2D(device_hwctx->device, &texDesc,
> NULL, &s->staging_texture);
> if (FAILED(hr)) {
> av_log(ctx, AV_LOG_ERROR, "Could not create the staging
> texture (%lx)\n", (long)hr);
___
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 v6 1/2] lavc/vaapi_encode: add support for maxframesize
On 29/04/2022 08:31, Fei Wang wrote:
From: Linjie Fu
Add support for max frame size:
- max_frame_size (bytes) to indicate the max allowed size for frame.
If the frame size exceeds the limitation, encoder will to control the frame
size by adjusting QP value.
ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -f rawvideo \
-v verbose -s:v 352x288 -i ./input.yuv -vf format=nv12,hwupload \
-c:v h264_vaapi -profile:v main -g 30 -rc_mode VBR -b:v 500k \
-bf 3 -max_frame_size 4 -vframes 100 -y ./max_frame_size.h264
Can you give some more explanation of the circumstances in which this is
expected to work in?
For example, I tried a simple test I gave the Intel (gen9, iHD) H.264 encoder
white noise.
At QP 51 I get:
$ ./ffmpeg_g -v 55 -y -f rawvideo -video_size 1280x720 -pixel_format nv12 -framerate
30 -i /dev/urandom -an -init_hw_device vaapi:/dev/dri/renderD128 -vf hwupload -c:v
h264_vaapi -g 0 -qp 51 -f null - 2>&1 | grep 'Output buffer:'
[h264_vaapi @ 0x557de0809640] Output buffer: 190975 bytes (status 0133).
[h264_vaapi @ 0x557de0809640] Output buffer: 191265 bytes (status 0133).
[h264_vaapi @ 0x557de0809640] Output buffer: 191825 bytes (status 0133).
[h264_vaapi @ 0x557de0809640] Output buffer: 191893 bytes (status 0133).
[h264_vaapi @ 0x557de0809640] Output buffer: 191746 bytes (status 0133).
So I should be able to set the max_frame_size to 20 (with a corresponding
bitrate target of 30*20*8 = 48M) and it will respect that?
$ ./ffmpeg_g -v 55 -y -f rawvideo -video_size 1280x720 -pixel_format nv12 -framerate
30 -i /dev/urandom -an -init_hw_device vaapi:/dev/dri/renderD128 -vf hwupload -c:v
h264_vaapi -g 0 -b:v 48M -max_frame_size 20 -f null - 2>&1 | grep 'Output
buffer:'
[h264_vaapi @ 0x5566f49b7580] Output buffer: 204360 bytes (status 0433).
[h264_vaapi @ 0x5566f49b7580] Output buffer: 201899 bytes (status 0433).
[h264_vaapi @ 0x5566f49b7580] Output buffer: 194869 bytes (status 0233).
[h264_vaapi @ 0x5566f49b7580] Output buffer: 191128 bytes (status 0133).
[h264_vaapi @ 0x5566f49b7580] Output buffer: 191348 bytes (status 0133).
But it still has some convergence delay, which really isn't what I expect from
an absolute option like max_frame_size.
(The 0400 in 0433 is VA_CODED_BUF_STATUS_NUMBER_PASSES_MASK
(0xf00), indicating that it took four (!) passes across the frame and still
didn't achieve the target we know is possible from the previous test.)
For a less artificial setup, I tried some 4K test streams. For example:
$ ./ffmpeg_g -v 55 -y -i ~/video/test/LG\ New\ York\ HDR\ UHD\ 4K\ Demo.ts -an
-init_hw_device vaapi:/dev/dri/renderD128 -vf 'format=nv12,hwupload' -c:v h264_vaapi
-b:v 24M -max_frame_size 10 out.mp4 2>&1 | grep 'Output buffer:' | nl | tee
out
...
$ cat out | awk '{ if ($7 > 10) { print } }'
308 [h264_vaapi @ 0x5653126613c0] Output buffer: 118390 bytes (status
0433).
361 [h264_vaapi @ 0x5653126613c0] Output buffer: 139404 bytes (status
042d).
481 [h264_vaapi @ 0x5653126613c0] Output buffer: 117728 bytes (status
0433).
601 [h264_vaapi @ 0x5653126613c0] Output buffer: 117328 bytes (status
0432).
721 [h264_vaapi @ 0x5653126613c0] Output buffer: 124737 bytes (status
042d).
841 [h264_vaapi @ 0x5653126613c0] Output buffer: 109479 bytes (status
042a).
961 [h264_vaapi @ 0x5653126613c0] Output buffer: 128128 bytes (status
042b).
1081 [h264_vaapi @ 0x5653126613c0] Output buffer: 103071 bytes (status
0431).
1201 [h264_vaapi @ 0x5653126613c0] Output buffer: 115270 bytes (status
0430).
1321 [h264_vaapi @ 0x5653126613c0] Output buffer: 154613 bytes (status
0430).
1406 [h264_vaapi @ 0x5653126613c0] Output buffer: 114548 bytes (status
0432).
1441 [h264_vaapi @ 0x5653126613c0] Output buffer: 133374 bytes (status
0433).
1561 [h264_vaapi @ 0x5653126613c0] Output buffer: 150675 bytes (status
042f).
1681 [h264_vaapi @ 0x5653126613c0] Output buffer: 119443 bytes (status
042a).
(With average QPs there indicating that it's usually nowhere near 51 when it
misses the target. Most of those failures are on GOP-start intra frames
(default GOP size is 120), but not all of them.)
Max frame size was enabled since VA-API version (0, 33, 0), but query is
available
since (1, 5, 0). It will be passed as a parameter in picParam and should be set
for each frame.
Signed-off-by: Linjie Fu
Signed-off-by: Fei Wang
---
update:
Set ctx->max_frame_size to 0 in CQP mode to avoid to pass
VAEncMiscParameterTypeMaxFrameSize type VABuffer.
libavcodec/vaapi_encode.c | 72 +++
libavcodec/vaapi_encode.h | 10 +-
2 files changed, 81 insertions(+), 1 deletion(-)
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 0e2f5ed447..3b96d4c671 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -365,6
Re: [FFmpeg-devel] [PATCH v2 4/5] avutil/hwcontext_qsv: map QSV frames to D3D11VA frames
> -Original Message-
> From: ffmpeg-devel On Behalf Of Tong
> Wu
> Sent: Friday, April 29, 2022 12:45 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Tong Wu
> Subject: [FFmpeg-devel] [PATCH v2 4/5] avutil/hwcontext_qsv: map QSV
> frames to D3D11VA frames
>
> When input is a rawvideo, after mapping QSV frames to D3D11VA frames,
> the output will have green frames. Now fix it.
>
> Fixes:
> $ ffmpeg.exe -y -init_hw_device d3d11va=d3d11 \
> -init_hw_device qsv=qsv@d3d11 -s:v WxH -pix_fmt nv12 -i input.yuv \
> -vf "format=nv12,hwupload=extra_hw_frames=16,\
> hwmap=derive_device=d3d11va,format=d3d11,hwdownload,format=nv12" \
> -f rawvideo output.yuv
>
> Signed-off-by: Tong Wu
> ---
> libavutil/hwcontext_qsv.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
> index d9d05e936a..6bc920ef59 100644
> --- a/libavutil/hwcontext_qsv.c
> +++ b/libavutil/hwcontext_qsv.c
> @@ -915,7 +915,7 @@ static int qsv_map_from(AVHWFramesContext *ctx,
> if (child_frames_ctx->device_ctx->type ==
> AV_HWDEVICE_TYPE_D3D11VA) {
> mfxHDLPair *pair = (mfxHDLPair*)surf->Data.MemId;
> dst->data[0] = pair->first;
> -dst->data[1] = pair->second;
> +dst->data[1] = pair->second == (mfxMemId)MFX_INFINITE ?
> (uint8_t *)0 : pair->second;
> } else {
> dst->data[3] = child_data;
> }
> @@ -945,7 +945,7 @@ static int qsv_map_from(AVHWFramesContext *ctx,
> if (child_frames_ctx->device_ctx->type ==
> AV_HWDEVICE_TYPE_D3D11VA) {
> mfxHDLPair *pair = (mfxHDLPair*)surf->Data.MemId;
> dummy->data[0] = pair->first;
> -dummy->data[1] = pair->second;
> +dummy->data[1] = pair->second == (mfxMemId)MFX_INFINITE ?
> (uint8_t *)0 : pair->second;
> } else {
> dummy->data[3] = child_data;
> }
> --
LGTM.
The command line might not make much sense this way, but yes, this
change is required for mapping non-array textures.
Thanks,
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 v2 5/5] avutil/hwcontext_qsv: map D3D11VA frames to QSV frames
> -Original Message-
> From: ffmpeg-devel On Behalf Of Tong
> Wu
> Sent: Friday, April 29, 2022 12:45 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Tong Wu
> Subject: [FFmpeg-devel] [PATCH v2 5/5] avutil/hwcontext_qsv: map
> D3D11VA frames to QSV frames
>
> Fixes:
> $ ffmpeg.exe -init_hw_device d3d11va=d3d11 -f lavfi -i
> yuvtestsrc -vf
> "format=nv12,hwupload=extra_hw_frames=16,hwmap=derive_device=qsv,forma
> t=qsv
> ,hwdownload,format=nv12" -f null -
>
> Signed-off-by: Tong Wu
> ---
> libavutil/hwcontext_qsv.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
> index 6bc920ef59..1bdffee4a4 100644
> --- a/libavutil/hwcontext_qsv.c
> +++ b/libavutil/hwcontext_qsv.c
> @@ -1363,7 +1363,8 @@ static int qsv_map_to(AVHWFramesContext
> *dst_ctx,
> {
> mfxHDLPair *pair = (mfxHDLPair*)hwctx-
> >surfaces[i].Data.MemId;
> if (pair->first == src->data[0]
> -&& pair->second == src->data[1]) {
> +&& (pair->second == src->data[1]
> +|| (pair->second == (mfxMemId)MFX_INFINITE &&
> src->data[1] == (uint8_t *)0))) {
> index = i;
> break;
> }
> --
LGTM.
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 v08 09/10] qsv: use a new method to create mfx session when using oneVPL
On 28/04/2022 10:23, Haihao Xiang wrote:
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
---
libavcodec/qsv.c | 197 ++--
libavcodec/qsv_internal.h| 1 +
libavcodec/qsvdec.c | 10 +
libavcodec/qsvenc.h | 3 +
libavcodec/qsvenc_h264.c | 1 -
libavcodec/qsvenc_hevc.c | 1 -
libavcodec/qsvenc_jpeg.c | 1 -
libavcodec/qsvenc_mpeg2.c| 1 -
libavcodec/qsvenc_vp9.c | 1 -
libavfilter/qsvvpp.c | 113 ++-
libavfilter/qsvvpp.h | 5 +
libavfilter/vf_deinterlace_qsv.c | 14 +-
libavfilter/vf_scale_qsv.c | 12 +-
libavutil/hwcontext_d3d11va.c| 7 +
libavutil/hwcontext_qsv.c| 515 ---
libavutil/hwcontext_qsv.h| 1 +
libavutil/hwcontext_vaapi.c | 13 +
libavutil/hwcontext_vaapi.h | 4 +
18 files changed, 812 insertions(+), 88 deletions(-)
...
diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index 8ab96bad25..fd5fedbdac 100644
--- a/libavutil/hwcontext_d3d11va.c
+++ b/libavutil/hwcontext_d3d11va.c
@@ -525,6 +525,11 @@ static void d3d11va_device_uninit(AVHWDeviceContext *hwdev)
}
}
+static void d3d11va_device_free(AVHWDeviceContext *ctx)
+{
+AVD3D11VADeviceContext *hwctx = ctx->hwctx;
+}
+
static int d3d11va_device_create(AVHWDeviceContext *ctx, const char *device,
AVDictionary *opts, int flags)
{
@@ -537,6 +542,8 @@ static int d3d11va_device_create(AVHWDeviceContext *ctx,
const char *device,
int is_debug = !!av_dict_get(opts, "debug", NULL, 0);
int ret;
+ctx->free = d3d11va_device_free;
+
// (On UWP we can't check this.)
#if !HAVE_UWP
if (!LoadLibrary("d3d11_1sdklayers.dll"))
This change doesn't do anything.
...
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index c3a98bc4b1..cb714df934 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -1572,6 +1572,7 @@ static void vaapi_device_free(AVHWDeviceContext *ctx)
if (priv->drm_fd >= 0)
close(priv->drm_fd);
+av_free(hwctx->device_name);
av_freep(&priv);
}
@@ -1620,6 +1621,7 @@ static int vaapi_device_connect(AVHWDeviceContext *ctx,
static int vaapi_device_create(AVHWDeviceContext *ctx, const char *device,
AVDictionary *opts, int flags)
{
+AVVAAPIDeviceContext *hwctx = ctx->hwctx;
VAAPIDevicePriv *priv;
VADisplay display = NULL;
const AVDictionaryEntry *ent;
@@ -1665,6 +1667,11 @@ static int vaapi_device_create(AVHWDeviceContext *ctx,
const char *device,
"DRM device node.\n", device);
break;
}
+
+hwctx->device_name = av_strdup(device);
+
+if (!hwctx->device_name)
+return AVERROR(ENOMEM);
} else {
char path[64];
int n, max_devices = 8;
@@ -1705,6 +1712,12 @@ static int vaapi_device_create(AVHWDeviceContext *ctx,
const char *device,
av_log(ctx, AV_LOG_VERBOSE, "Trying to use "
"DRM render node for device %d.\n", n);
}
+
+hwctx->device_name = av_strdup(path);
+
+if (!hwctx->device_name)
+return AVERROR(ENOMEM);
+
break;
}
if (n >= max_devices)
diff --git a/libavutil/hwcontext_vaapi.h b/libavutil/hwcontext_vaapi.h
index 0b2e071cb3..3e0b54f5e9 100644
--- a/libavutil/hwcontext_vaapi.h
+++ b/libavutil/hwcontext_vaapi.h
@@ -78,6 +78,10 @@ typedef struct AVVAAPIDeviceContext {
* operations using VAAPI with the same VADisplay.
*/
unsigned int driver_quirks;
+/**
+ * The string for the used device
+ */
+char *device_name;
This new user-facing API field needs a lot more explanation. The only example
you've got is for simple creation via DRM, which sets it to a device path.
There are other ways to make a device:
* Created via X11 (like ":0").
* Derived from a DRM device (e.g. from kmsgrab).
* Manually created by the user (who need not have any path even if they did
open via DRM, because they could have given the fd by something else like DRI3).
What happens for existing users who have build against the current API without
this field and expect it to continue working?
I am generally very sceptical that hacking the library A
Re: [FFmpeg-devel] [PATCH v7 05/10] qsv: build audio related code when MFX_VERSION < 2.0
> -Original Message- > From: ffmpeg-devel On Behalf Of > Xiang, Haihao > Sent: Wednesday, April 6, 2022 5:38 AM > To: an...@khirnov.net; ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH v7 05/10] qsv: build audio related > code when MFX_VERSION < 2.0 > > On Tue, 2022-04-05 at 13:50 +0200, Anton Khirnov wrote: > > Quoting Xiang, Haihao (2022-03-11 09:16:25) > > > From: Haihao Xiang > > > > > > Audio isn't supported for MFX_VERSION >= 2.0[1][2]. This is in > > > preparation for oneVPL support > > > > > > [1]: > > > > https://spec.oneapi.io/versions/latest/elements/oneVPL/source/VPL_inte > l_media_sdk.html#msdk-full-name-feature-removals > > > [2]: https://github.com/oneapi-src/oneVPL > > > --- > > > libavcodec/qsv.c | 5 + > > > libavfilter/qsvvpp.c | 6 ++ > > > libavfilter/qsvvpp.h | 2 ++ > > > 3 files changed, 13 insertions(+) > > > > Why not just remove this completely? > > None of our QSV code does anything with audio. > > It was removed in an older version, however someone objected the > removal of > this. See > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200819061023.44330 > 4-2-haihao.xi...@intel.com/ I think this was a misunderstanding. I see not objection. One was just asking "why" and the other one had missed the point that audio has never been functional. I agree with Anton that the audio stuff should be removed completely - ideally even beforehand in a separate patch. 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] avcodec/cbs_jpeg: Fix size of huffman symbol table array
On 08/02/2022 09:41, Andreas Rheinhardt wrote: L[i] can be in the range of 0-255, see table B.5 of ITU T.81. Signed-off-by: Andreas Rheinhardt --- libavcodec/cbs_jpeg.h | 2 +- libavcodec/cbs_jpeg_syntax_template.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) Do you have a valid file showing this? Not all values are allowed. I guess I must have written it, but I have no idea where 224 came from. As far as I know the worst case is in AC tables: 10 category values * 16 run lengths + 2 special cases = 162 (which could indeed all be dumped in the same code length if you want to be pathological). - 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 5/7] avcodec/cbs_sei: refactor to use avutil/uuid
On 24/04/2022 11:14, Zane van Iperen wrote:
From: Pierre-Anthony Lemieux
---
libavcodec/cbs_sei.h | 3 ++-
libavcodec/vaapi_encode_h264.c | 8
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/libavcodec/cbs_sei.h b/libavcodec/cbs_sei.h
index c7a7a95be0..67c6e6cbbd 100644
--- a/libavcodec/cbs_sei.h
+++ b/libavcodec/cbs_sei.h
@@ -23,6 +23,7 @@
#include
#include "libavutil/buffer.h"
+#include "libavutil/uuid.h"
#include "cbs.h"
#include "sei.h"
@@ -41,7 +42,7 @@ typedef struct SEIRawUserDataRegistered {
} SEIRawUserDataRegistered;
typedef struct SEIRawUserDataUnregistered {
-uint8_t uuid_iso_iec_11578[16];
+AVUUID uuid_iso_iec_11578;
uint8_t *data;
AVBufferRef *data_ref;
size_t data_length;
This feels like a step backwards? The syntax template files are explicitly
relying on this being uint8_t[16], so giving it a different name is confusing.
diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index 7a6b54ab6f..b3105d6ccc 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_encode_h264.c
@@ -25,6 +25,7 @@
#include "libavutil/common.h"
#include "libavutil/internal.h"
#include "libavutil/opt.h"
+#include "libavutil/uuid.h"
#include "avcodec.h"
#include "cbs.h"
@@ -43,7 +44,7 @@ enum {
};
// Random (version 4) ISO 11578 UUID.
-static const uint8_t vaapi_encode_h264_sei_identifier_uuid[16] = {
+static const AVUUID vaapi_encode_h264_sei_identifier_uuid = {
0x59, 0x94, 0x8b, 0x28, 0x11, 0xec, 0x45, 0xaf,
0x96, 0x75, 0x19, 0xd4, 0x1f, 0xea, 0xa9, 0x4d,
};
@@ -1089,9 +1090,8 @@ static av_cold int
vaapi_encode_h264_configure(AVCodecContext *avctx)
const char *driver;
int len;
-memcpy(priv->sei_identifier.uuid_iso_iec_11578,
- vaapi_encode_h264_sei_identifier_uuid,
- sizeof(priv->sei_identifier.uuid_iso_iec_11578));
+av_uuid_copy(priv->sei_identifier.uuid_iso_iec_11578,
+ vaapi_encode_h264_sei_identifier_uuid);
driver = vaQueryVendorString(ctx->hwctx->display);
if (!driver)
This is fair.
- 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] libavcodec/cbs_av1: Add size check before parse obu
On 29/03/2022 09:29, Wenbin Chen wrote:
cbs_av1_write_unit() check pbc size after parsing obu frame, and return
AVERROR(ENOSPC) if pbc is small. pbc will be reallocated and this obu
frame will be parsed again, but this may cause error because
CodedBitstreamAV1Context has already been updated, for example
ref_order_hint is updated and will not match the same obu frame. Now size
check is added before parsing obu frame to avoid this error.
Signed-off-by: Wenbin Chen
---
libavcodec/cbs_av1.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/cbs_av1.c b/libavcodec/cbs_av1.c
index 1229480567..29e7bc16df 100644
--- a/libavcodec/cbs_av1.c
+++ b/libavcodec/cbs_av1.c
@@ -1075,6 +1075,9 @@ static int cbs_av1_write_obu(CodedBitstreamContext *ctx,
put_bits32(pbc, 0);
}
+if (8 * (unit->data_size + obu->obu_size) > put_bits_left(pbc))
+return AVERROR(ENOSPC);
unit->data_size is not usefully set when we are writing here (it might be the
size of the old bitstream in editing cases, or it might just be zero).
+
td = NULL;
start_pos = put_bits_count(pbc);
@@ -1196,9 +1199,6 @@ static int cbs_av1_write_obu(CodedBitstreamContext *ctx,
flush_put_bits(pbc);
av_assert0(data_pos <= start_pos);
-if (8 * obu->obu_size > put_bits_left(pbc))
-return AVERROR(ENOSPC);
-
if (obu->obu_size > 0) {
memmove(pbc->buf + data_pos,
pbc->buf + start_pos, header_size);
So, this doesn't work? The header hasn't been written that point, so you don't
know if there is enough space for both the OBU header and the OBU data.
Having the check in both places would be fine (the newly-added one being a way
to bail early when there definitely isn't enough space), but that wouldn't do
what you want.
I'm not sure what the right answer is here. Do we need some way to unwind the
written header? The initial buffer size is 1MB and gets doubled each time, so
this is not going to be hit very often.
- 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 5/7] avcodec/cbs_sei: refactor to use avutil/uuid
On Sat, Apr 30, 2022 at 10:31 AM Mark Thompson wrote:
>
> On 24/04/2022 11:14, Zane van Iperen wrote:
> > From: Pierre-Anthony Lemieux
> >
> > ---
> > libavcodec/cbs_sei.h | 3 ++-
> > libavcodec/vaapi_encode_h264.c | 8
> > 2 files changed, 6 insertions(+), 5 deletions(-)
> >
> > diff --git a/libavcodec/cbs_sei.h b/libavcodec/cbs_sei.h
> > index c7a7a95be0..67c6e6cbbd 100644
> > --- a/libavcodec/cbs_sei.h
> > +++ b/libavcodec/cbs_sei.h
> > @@ -23,6 +23,7 @@
> > #include
> >
> > #include "libavutil/buffer.h"
> > +#include "libavutil/uuid.h"
> >
> > #include "cbs.h"
> > #include "sei.h"
> > @@ -41,7 +42,7 @@ typedef struct SEIRawUserDataRegistered {
> > } SEIRawUserDataRegistered;
> >
> > typedef struct SEIRawUserDataUnregistered {
> > -uint8_t uuid_iso_iec_11578[16];
> > +AVUUID uuid_iso_iec_11578;
> > uint8_t *data;
> > AVBufferRef *data_ref;
> > size_t data_length;
>
> This feels like a step backwards? The syntax template files are explicitly
> relying on this being uint8_t[16], so giving it a different name is confusing.
What/where are the syntax template files?
>
> > diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
> > index 7a6b54ab6f..b3105d6ccc 100644
> > --- a/libavcodec/vaapi_encode_h264.c
> > +++ b/libavcodec/vaapi_encode_h264.c
> > @@ -25,6 +25,7 @@
> > #include "libavutil/common.h"
> > #include "libavutil/internal.h"
> > #include "libavutil/opt.h"
> > +#include "libavutil/uuid.h"
> >
> > #include "avcodec.h"
> > #include "cbs.h"
> > @@ -43,7 +44,7 @@ enum {
> > };
> >
> > // Random (version 4) ISO 11578 UUID.
> > -static const uint8_t vaapi_encode_h264_sei_identifier_uuid[16] = {
> > +static const AVUUID vaapi_encode_h264_sei_identifier_uuid = {
> > 0x59, 0x94, 0x8b, 0x28, 0x11, 0xec, 0x45, 0xaf,
> > 0x96, 0x75, 0x19, 0xd4, 0x1f, 0xea, 0xa9, 0x4d,
> > };
> > @@ -1089,9 +1090,8 @@ static av_cold int
> > vaapi_encode_h264_configure(AVCodecContext *avctx)
> > const char *driver;
> > int len;
> >
> > -memcpy(priv->sei_identifier.uuid_iso_iec_11578,
> > - vaapi_encode_h264_sei_identifier_uuid,
> > - sizeof(priv->sei_identifier.uuid_iso_iec_11578));
> > +av_uuid_copy(priv->sei_identifier.uuid_iso_iec_11578,
> > + vaapi_encode_h264_sei_identifier_uuid);
> >
> > driver = vaQueryVendorString(ctx->hwctx->display);
> > if (!driver)
>
> This is fair.
>
> - 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] avcodec/cbs_jpeg: Fix size of huffman symbol table array
Mark Thompson: > On 08/02/2022 09:41, Andreas Rheinhardt wrote: >> L[i] can be in the range of 0-255, see table B.5 of ITU T.81. >> >> Signed-off-by: Andreas Rheinhardt >> --- >> libavcodec/cbs_jpeg.h | 2 +- >> libavcodec/cbs_jpeg_syntax_template.c | 4 ++-- >> 2 files changed, 3 insertions(+), 3 deletions(-) > > Do you have a valid file showing this? Not all values are allowed. > Where is this said in the spec? The file jpg/12bpp.jpg from the FATE-suite triggers this. It has a Huffman table with 226 entries. (Sorry, should have mentioned the sample in the commit message.) > I guess I must have written it, but I have no idea where 224 came from. > As far as I know the worst case is in AC tables: 10 category values * 16 > run lengths + 2 special cases = 162 (which could indeed all be dumped in > the same code length if you want to be pathological). I have never heard of these restrictions. Would you care to elaborate which part of the spec they refer to? Anyway, IIRC there is no restriction against duplicates in the Huffman table, so one could use even more than 256 values (i.e. there might be spec-compliant pictures that are not supported by both our decoder and the current version of cbs_jpeg); it just makes no sense. Notice that the sample mentioned above has no duplicate values in any Huffman table. - 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 2/2] avcodec/cbs_av1: also copy the last frame header's decomposed content when parsing redundant frame headers
On 28/03/2022 02:08, James Almer wrote:
This prevents CBS from propagating zeroed AV1RawFrameHeader units in reading
scenarios.
Writing scenarios remain unaffected as the content of these units is not used
to assemble the bitstream.
Signed-off-by: James Almer
---
libavcodec/cbs_av1.c | 11 +++
libavcodec/cbs_av1.h | 2 ++
libavcodec/cbs_av1_syntax_template.c | 6 ++
3 files changed, 19 insertions(+)
I took me a while to work out what the issue was here, maybe make it a bit
clearer that the problematic thing is that decomposed unit content for the
redundant frame header OBU isn't filled if there was a frame header (in which
case that content is never used, but someone could technically look at it if
they wanted and observe that it is wrong).
diff --git a/libavcodec/cbs_av1.c b/libavcodec/cbs_av1.c
index ecd775ea2a..6cb832210c 100644
--- a/libavcodec/cbs_av1.c
+++ b/libavcodec/cbs_av1.c
@@ -969,6 +969,15 @@ static int cbs_av1_read_unit(CodedBitstreamContext *ctx,
unit->data_ref);
if (err < 0)
return err;
+
+if (priv->frame_header)
+break;
+
+av_buffer_unref(&priv->frame_header_ref);
+priv->frame_header_ref = av_buffer_ref(unit->content_ref);
+if (!priv->frame_header_ref)
+return AVERROR(ENOMEM);
+priv->frame_header = &obu->obu.frame_header;
}
break;
case AV1_OBU_TILE_GROUP:
@@ -1251,6 +1260,7 @@ static void cbs_av1_flush(CodedBitstreamContext *ctx)
av_buffer_unref(&priv->frame_header_data_ref);
priv->sequence_header = NULL;
+priv->frame_header = NULL;
priv->frame_header_data = NULL;
memset(priv->ref, 0, sizeof(priv->ref));
@@ -1264,6 +1274,7 @@ static void cbs_av1_close(CodedBitstreamContext *ctx)
CodedBitstreamAV1Context *priv = ctx->priv_data;
av_buffer_unref(&priv->sequence_header_ref);
+av_buffer_unref(&priv->frame_header_ref);
av_buffer_unref(&priv->frame_header_data_ref);
}
diff --git a/libavcodec/cbs_av1.h b/libavcodec/cbs_av1.h
index d4776b7a30..138b273470 100644
--- a/libavcodec/cbs_av1.h
+++ b/libavcodec/cbs_av1.h
@@ -431,6 +431,8 @@ typedef struct CodedBitstreamAV1Context {
AVBufferRef *sequence_header_ref;
int seen_frame_header;
+AVBufferRef *frame_header_ref;
+AV1RawFrameHeader *frame_header;
AVBufferRef *frame_header_data_ref;
uint8_t *frame_header_data;
size_t frame_header_data_size;
diff --git a/libavcodec/cbs_av1_syntax_template.c
b/libavcodec/cbs_av1_syntax_template.c
index bd50cfbe38..aadfa34b3c 100644
--- a/libavcodec/cbs_av1_syntax_template.c
+++ b/libavcodec/cbs_av1_syntax_template.c
@@ -1708,6 +1708,11 @@ static int FUNC(frame_header_obu)(CodedBitstreamContext
*ctx, RWContext *rw,
xf(b, frame_header_copy[i],
val, val, val, 1, i / 8);
}
+
+#ifdef READ
+av_assert0(priv->frame_header_ref && priv->frame_header);
+memcpy(current, priv->frame_header, sizeof(*current));
+#endif
}
} else {
if (redundant)
@@ -1730,6 +1735,7 @@ static int FUNC(frame_header_obu)(CodedBitstreamContext
*ctx, RWContext *rw,
} else {
priv->seen_frame_header = 1;
+priv->frame_header = NULL;
av_buffer_unref(&priv->frame_header_data_ref);
#ifdef READ
LGTM in any case. (Previous patch fine too given this one.)
- 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] FATE Errors
Hi, is it a known issue that the current head of the master branch has FATE errors? I get the same locally as well as on the automated GitHub build. One is this: --- ./tests/ref/vsynth/vsynth2-mpeg2-422 2022-04-30 14:23:44.330424058 + +++ tests/data/fate/vsynth2-mpeg2-422 2022-04-30 14:38:41.071678201 + @@ -1,4 +1,4 @@ -b2fa9b73c3547191ecc01b8163abd4e5 *tests/data/fate/vsynth2-mpeg2-422.mpeg2video -379164 tests/data/fate/vsynth2-mpeg2-422.mpeg2video -704f6a96f93c2409219bd48b74169041 *tests/data/fate/vsynth2-mpeg2-422.out.rawvideo -stddev: 4.17 PSNR: 35.73 MAXDIFF: 70 bytes: 7603200/ 7603200 +8f6d565723ccf879ab2b5aa910b7ce21 *tests/data/fate/vsynth2-mpeg2-422.mpeg2video +380544 tests/data/fate/vsynth2-mpeg2-422.mpeg2video +0797fddea4835687dedddebbbe98fa8f *tests/data/fate/vsynth2-mpeg2-422.out.rawvideo +stddev: 4.16 PSNR: 35.73 MAXDIFF: 75 bytes: 7603200/ 7603200 Test vsynth2-mpeg2-422 failed. Look at tests/data/fate/vsynth2-mpeg2-422.err for details. make: *** [tests/Makefile:277: fate-vsynth2-mpeg2-422] Error 1 Is anybody seeing the same? Thanks, sw ___ 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] FATE Errors
I’ve been getting the same locally, assumed an issue had already been opened. -Fclc > On Apr 30, 2022, at 14:54, Soft Works wrote: > > Hi, > > is it a known issue that the current head of the master branch has > FATE errors? > > I get the same locally as well as on the automated GitHub build. > One is this: > > --- ./tests/ref/vsynth/vsynth2-mpeg2-422 2022-04-30 14:23:44.330424058 + > +++ tests/data/fate/vsynth2-mpeg2-422 2022-04-30 14:38:41.071678201 + > @@ -1,4 +1,4 @@ > -b2fa9b73c3547191ecc01b8163abd4e5 > *tests/data/fate/vsynth2-mpeg2-422.mpeg2video > -379164 tests/data/fate/vsynth2-mpeg2-422.mpeg2video > -704f6a96f93c2409219bd48b74169041 > *tests/data/fate/vsynth2-mpeg2-422.out.rawvideo > -stddev: 4.17 PSNR: 35.73 MAXDIFF: 70 bytes: 7603200/ 7603200 > +8f6d565723ccf879ab2b5aa910b7ce21 > *tests/data/fate/vsynth2-mpeg2-422.mpeg2video > +380544 tests/data/fate/vsynth2-mpeg2-422.mpeg2video > +0797fddea4835687dedddebbbe98fa8f > *tests/data/fate/vsynth2-mpeg2-422.out.rawvideo > +stddev: 4.16 PSNR: 35.73 MAXDIFF: 75 bytes: 7603200/ 7603200 > Test vsynth2-mpeg2-422 failed. Look at tests/data/fate/vsynth2-mpeg2-422.err > for details. > make: *** [tests/Makefile:277: fate-vsynth2-mpeg2-422] Error 1 > > > Is anybody seeing the same? > > Thanks, > sw > ___ > 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] FATE Errors
Soft Works: > Hi, > > is it a known issue that the current head of the master branch has > FATE errors? > > I get the same locally as well as on the automated GitHub build. > One is this: > > --- ./tests/ref/vsynth/vsynth2-mpeg2-422 2022-04-30 14:23:44.330424058 + > +++ tests/data/fate/vsynth2-mpeg2-422 2022-04-30 14:38:41.071678201 + > @@ -1,4 +1,4 @@ > -b2fa9b73c3547191ecc01b8163abd4e5 > *tests/data/fate/vsynth2-mpeg2-422.mpeg2video > -379164 tests/data/fate/vsynth2-mpeg2-422.mpeg2video > -704f6a96f93c2409219bd48b74169041 > *tests/data/fate/vsynth2-mpeg2-422.out.rawvideo > -stddev: 4.17 PSNR: 35.73 MAXDIFF: 70 bytes: 7603200/ 7603200 > +8f6d565723ccf879ab2b5aa910b7ce21 > *tests/data/fate/vsynth2-mpeg2-422.mpeg2video > +380544 tests/data/fate/vsynth2-mpeg2-422.mpeg2video > +0797fddea4835687dedddebbbe98fa8f > *tests/data/fate/vsynth2-mpeg2-422.out.rawvideo > +stddev: 4.16 PSNR: 35.73 MAXDIFF: 75 bytes: 7603200/ 7603200 > Test vsynth2-mpeg2-422 failed. Look at tests/data/fate/vsynth2-mpeg2-422.err > for details. > make: *** [tests/Makefile:277: fate-vsynth2-mpeg2-422] Error 1 > > > Is anybody seeing the same? > > Thanks, > sw http://fate.ffmpeg.org/ doesn't show recent regressions and FATE is fine for me locally. I recently made changes to FATE (namely the test requirements, vcodec.mak (where the vsynth-tests reside) among the files affected), so I am interested in whether the failing tests are concentrated on the files recently changed by me (it would obviously not haved pushed them if I knew them to cause issues; also patchwork was fine). Are these issues reproducible? Can you bisect them? - 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] FATE Errors
> -Original Message- > From: ffmpeg-devel On Behalf Of > Felix LeClair > Sent: Saturday, April 30, 2022 9:01 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] FATE Errors > > I’ve been getting the same locally, assumed an issue had already been > opened. The weird thing is that the patchwork builds don't show any error: https://patchwork.ffmpeg.org/project/ffmpeg/list/ ..which would be expected for a specific commit that might fix this, but none of the commits is showing such error. That's why I was wondering whether it's something on my side (2 sides). Thanks for letting me know that you're seeing the same! sw ___ 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] FATE Errors
On 4/30/2022 4:06 PM, Andreas Rheinhardt wrote: Soft Works: Hi, is it a known issue that the current head of the master branch has FATE errors? I get the same locally as well as on the automated GitHub build. One is this: --- ./tests/ref/vsynth/vsynth2-mpeg2-422 2022-04-30 14:23:44.330424058 + +++ tests/data/fate/vsynth2-mpeg2-422 2022-04-30 14:38:41.071678201 + @@ -1,4 +1,4 @@ -b2fa9b73c3547191ecc01b8163abd4e5 *tests/data/fate/vsynth2-mpeg2-422.mpeg2video -379164 tests/data/fate/vsynth2-mpeg2-422.mpeg2video -704f6a96f93c2409219bd48b74169041 *tests/data/fate/vsynth2-mpeg2-422.out.rawvideo -stddev: 4.17 PSNR: 35.73 MAXDIFF: 70 bytes: 7603200/ 7603200 +8f6d565723ccf879ab2b5aa910b7ce21 *tests/data/fate/vsynth2-mpeg2-422.mpeg2video +380544 tests/data/fate/vsynth2-mpeg2-422.mpeg2video +0797fddea4835687dedddebbbe98fa8f *tests/data/fate/vsynth2-mpeg2-422.out.rawvideo +stddev: 4.16 PSNR: 35.73 MAXDIFF: 75 bytes: 7603200/ 7603200 Test vsynth2-mpeg2-422 failed. Look at tests/data/fate/vsynth2-mpeg2-422.err for details. make: *** [tests/Makefile:277: fate-vsynth2-mpeg2-422] Error 1 Is anybody seeing the same? Thanks, sw http://fate.ffmpeg.org/ doesn't show recent regressions and FATE is fine for me locally. I recently made changes to FATE (namely the test requirements, vcodec.mak (where the vsynth-tests reside) among the files affected), so I am interested in whether the failing tests are concentrated on the files recently changed by me (it would obviously not haved pushed them if I knew them to cause issues; also patchwork was fine). Are these issues reproducible? Can you bisect them? - Andreas This may be the alignment issue introduced in lavfi in https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=17a59a634c39b00a680c6ebbaea58db95594d13d assuming it was not fixed. I think it only affected targets where av_cpu_max_align() returned 64. ___ 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] FATE Errors
> -Original Message- > From: ffmpeg-devel On Behalf Of > Andreas Rheinhardt > Sent: Saturday, April 30, 2022 9:07 PM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] FATE Errors > > Soft Works: > > Hi, > > > > is it a known issue that the current head of the master branch has > > FATE errors? > > > > I get the same locally as well as on the automated GitHub build. > > One is this: > > > > --- ./tests/ref/vsynth/vsynth2-mpeg2-422 2022-04-30 > 14:23:44.330424058 + > > +++ tests/data/fate/vsynth2-mpeg2-422 2022-04-30 14:38:41.071678201 > + > > @@ -1,4 +1,4 @@ > > -b2fa9b73c3547191ecc01b8163abd4e5 *tests/data/fate/vsynth2-mpeg2- > 422.mpeg2video > > -379164 tests/data/fate/vsynth2-mpeg2-422.mpeg2video > > -704f6a96f93c2409219bd48b74169041 *tests/data/fate/vsynth2-mpeg2- > 422.out.rawvideo > > -stddev: 4.17 PSNR: 35.73 MAXDIFF: 70 bytes: 7603200/ 7603200 > > +8f6d565723ccf879ab2b5aa910b7ce21 *tests/data/fate/vsynth2-mpeg2- > 422.mpeg2video > > +380544 tests/data/fate/vsynth2-mpeg2-422.mpeg2video > > +0797fddea4835687dedddebbbe98fa8f *tests/data/fate/vsynth2-mpeg2- > 422.out.rawvideo > > +stddev: 4.16 PSNR: 35.73 MAXDIFF: 75 bytes: 7603200/ 7603200 > > Test vsynth2-mpeg2-422 failed. Look at tests/data/fate/vsynth2- > mpeg2-422.err for details. > > make: *** [tests/Makefile:277: fate-vsynth2-mpeg2-422] Error 1 > > > > > > Is anybody seeing the same? > > > > Thanks, > > sw > > http://fate.ffmpeg.org/ doesn't show recent regressions and FATE is > fine > for me locally. That's weird. I got the same errors locally and from the GitHub CI build. Here's the output: https://dev.azure.com/githubsync/ffmpeg/_build/results?buildId=1&view=logs&j=275f1d19-1bd8-5591-b06b-07d489ea915a&t=704ea7c9-8eb0-53b9-6b30-87d5a7befe2c 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] avcodec/cbs_jpeg: Fix size of huffman symbol table array
On 30/04/2022 19:38, Andreas Rheinhardt wrote: Mark Thompson: On 08/02/2022 09:41, Andreas Rheinhardt wrote: L[i] can be in the range of 0-255, see table B.5 of ITU T.81. Signed-off-by: Andreas Rheinhardt --- libavcodec/cbs_jpeg.h | 2 +- libavcodec/cbs_jpeg_syntax_template.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) Do you have a valid file showing this? Not all values are allowed. Where is this said in the spec? The file jpg/12bpp.jpg from the FATE-suite triggers this. It has a Huffman table with 226 entries. (Sorry, should have mentioned the sample in the commit message.) I guess I must have written it, but I have no idea where 224 came from. As far as I know the worst case is in AC tables: 10 category values * 16 run lengths + 2 special cases = 162 (which could indeed all be dumped in the same code length if you want to be pathological). I have never heard of these restrictions. Would you care to elaborate which part of the spec they refer to? Urgh. I was thinking of F.1.2.2.1, defining 10 categories (figure F.1 illustrates the 162 possible values). F.1.5.2 for 12-bit extends that with four additional categories for a total of 226 values. Maybe that's where 224 came from, except typoed. Anyway, IIRC there is no restriction against duplicates in the Huffman table, so one could use even more than 256 values (i.e. there might be spec-compliant pictures that are not supported by both our decoder and the current version of cbs_jpeg); it just makes no sense. Notice that the sample mentioned above has no duplicate values in any Huffman table. If duplicates were allowed then the whole thing could have a lot more than 256 entries (e.g. 255 entries in each of 9-16 bit length (covering ~half the remaining space in each case) is 2040). I feel like there must be a prohibition against this somewhere, though I don't see it. - 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] FATE Errors
> -Original Message- > From: ffmpeg-devel On Behalf Of > James Almer > Sent: Saturday, April 30, 2022 9:10 PM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] FATE Errors > > > > On 4/30/2022 4:06 PM, Andreas Rheinhardt wrote: > > Soft Works: > >> Hi, > >> > >> is it a known issue that the current head of the master branch has > >> FATE errors? > >> > >> I get the same locally as well as on the automated GitHub build. > >> One is this: > >> > >> --- ./tests/ref/vsynth/vsynth2-mpeg2-422 2022-04-30 > 14:23:44.330424058 + > >> +++ tests/data/fate/vsynth2-mpeg2-422 2022-04-30 14:38:41.071678201 > + > >> @@ -1,4 +1,4 @@ > >> -b2fa9b73c3547191ecc01b8163abd4e5 *tests/data/fate/vsynth2-mpeg2- > 422.mpeg2video > >> -379164 tests/data/fate/vsynth2-mpeg2-422.mpeg2video > >> -704f6a96f93c2409219bd48b74169041 *tests/data/fate/vsynth2-mpeg2- > 422.out.rawvideo > >> -stddev: 4.17 PSNR: 35.73 MAXDIFF: 70 bytes: 7603200/ 7603200 > >> +8f6d565723ccf879ab2b5aa910b7ce21 *tests/data/fate/vsynth2-mpeg2- > 422.mpeg2video > >> +380544 tests/data/fate/vsynth2-mpeg2-422.mpeg2video > >> +0797fddea4835687dedddebbbe98fa8f *tests/data/fate/vsynth2-mpeg2- > 422.out.rawvideo > >> +stddev: 4.16 PSNR: 35.73 MAXDIFF: 75 bytes: 7603200/ 7603200 > >> Test vsynth2-mpeg2-422 failed. Look at tests/data/fate/vsynth2- > mpeg2-422.err for details. > >> make: *** [tests/Makefile:277: fate-vsynth2-mpeg2-422] Error 1 > >> > >> > >> Is anybody seeing the same? > >> > >> Thanks, > >> sw > > > > http://fate.ffmpeg.org/ doesn't show recent regressions and FATE is > fine > > for me locally. I recently made changes to FATE (namely the test > > requirements, vcodec.mak (where the vsynth-tests reside) among the > files > > affected), so I am interested in whether the failing tests are > > concentrated on the files recently changed by me (it would obviously > not > > haved pushed them if I knew them to cause issues; also patchwork was > fine). > > Are these issues reproducible? Can you bisect them? > > > > - Andreas > > This may be the alignment issue introduced in lavfi in > https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=17a59a634c39b00a > 680c6ebbaea58db95594d13d > assuming it was not fixed. > I think it only affected targets where av_cpu_max_align() returned 64. My local build is run on Ubuntu in Hyper-V VM on Windows. The GitHub CI build runs on Azure DevOps which is also an Ubuntu VM (not sure about the host). AFAIC, Patchwork runs in a Docker container only. Not sure whether that could be the difference.. 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] FATE Errors
Both times I’ve encountered were on PopOS (think Debian/Ubuntu meets arch like timing release) Currently pulling to a macOS machine and seeing if it can be replicated there. -FCLC > On Apr 30, 2022, at 15:19, Soft Works wrote: > > > >> -Original Message- >> From: ffmpeg-devel On Behalf Of >> James Almer >> Sent: Saturday, April 30, 2022 9:10 PM >> To: ffmpeg-devel@ffmpeg.org >> Subject: Re: [FFmpeg-devel] FATE Errors >> >> >> >>> On 4/30/2022 4:06 PM, Andreas Rheinhardt wrote: >>> Soft Works: Hi, is it a known issue that the current head of the master branch has FATE errors? I get the same locally as well as on the automated GitHub build. One is this: --- ./tests/ref/vsynth/vsynth2-mpeg2-422 2022-04-30 >> 14:23:44.330424058 + +++ tests/data/fate/vsynth2-mpeg2-422 2022-04-30 14:38:41.071678201 >> + @@ -1,4 +1,4 @@ -b2fa9b73c3547191ecc01b8163abd4e5 *tests/data/fate/vsynth2-mpeg2- >> 422.mpeg2video -379164 tests/data/fate/vsynth2-mpeg2-422.mpeg2video -704f6a96f93c2409219bd48b74169041 *tests/data/fate/vsynth2-mpeg2- >> 422.out.rawvideo -stddev: 4.17 PSNR: 35.73 MAXDIFF: 70 bytes: 7603200/ 7603200 +8f6d565723ccf879ab2b5aa910b7ce21 *tests/data/fate/vsynth2-mpeg2- >> 422.mpeg2video +380544 tests/data/fate/vsynth2-mpeg2-422.mpeg2video +0797fddea4835687dedddebbbe98fa8f *tests/data/fate/vsynth2-mpeg2- >> 422.out.rawvideo +stddev: 4.16 PSNR: 35.73 MAXDIFF: 75 bytes: 7603200/ 7603200 Test vsynth2-mpeg2-422 failed. Look at tests/data/fate/vsynth2- >> mpeg2-422.err for details. make: *** [tests/Makefile:277: fate-vsynth2-mpeg2-422] Error 1 Is anybody seeing the same? Thanks, sw >>> >>> http://fate.ffmpeg.org/ doesn't show recent regressions and FATE is >> fine >>> for me locally. I recently made changes to FATE (namely the test >>> requirements, vcodec.mak (where the vsynth-tests reside) among the >> files >>> affected), so I am interested in whether the failing tests are >>> concentrated on the files recently changed by me (it would obviously >> not >>> haved pushed them if I knew them to cause issues; also patchwork was >> fine). >>> Are these issues reproducible? Can you bisect them? >>> >>> - Andreas >> >> This may be the alignment issue introduced in lavfi in >> https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=17a59a634c39b00a >> 680c6ebbaea58db95594d13d >> assuming it was not fixed. >> I think it only affected targets where av_cpu_max_align() returned 64. > > My local build is run on Ubuntu in Hyper-V VM on Windows. The GitHub > CI build runs on Azure DevOps which is also an Ubuntu VM (not sure > about the host). > > AFAIC, Patchwork runs in a Docker container only. Not sure whether > that could be the difference.. > > 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". ___ 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] FATE Errors
> -Original Message- > From: ffmpeg-devel On Behalf Of > Felix LeClair > Sent: Saturday, April 30, 2022 9:22 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] FATE Errors > > Both times I’ve encountered were on PopOS (think Debian/Ubuntu meets > arch like timing release) VM or bare metal installation? PS: The people here don't like top-posting Thanks, 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 v2 5/7] avcodec/cbs_sei: refactor to use avutil/uuid
On 30/04/2022 18:53, Pierre-Anthony Lemieux wrote:
On Sat, Apr 30, 2022 at 10:31 AM Mark Thompson wrote:
On 24/04/2022 11:14, Zane van Iperen wrote:
From: Pierre-Anthony Lemieux
---
libavcodec/cbs_sei.h | 3 ++-
libavcodec/vaapi_encode_h264.c | 8
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/libavcodec/cbs_sei.h b/libavcodec/cbs_sei.h
index c7a7a95be0..67c6e6cbbd 100644
--- a/libavcodec/cbs_sei.h
+++ b/libavcodec/cbs_sei.h
@@ -23,6 +23,7 @@
#include
#include "libavutil/buffer.h"
+#include "libavutil/uuid.h"
#include "cbs.h"
#include "sei.h"
@@ -41,7 +42,7 @@ typedef struct SEIRawUserDataRegistered {
} SEIRawUserDataRegistered;
typedef struct SEIRawUserDataUnregistered {
-uint8_t uuid_iso_iec_11578[16];
+AVUUID uuid_iso_iec_11578;
uint8_t *data;
AVBufferRef *data_ref;
size_t data_length;
This feels like a step backwards? The syntax template files are explicitly
relying on this being uint8_t[16], so giving it a different name is confusing.
What/where are the syntax template files?
(It's included twice by cbs_h2645.c for read/write with different macro setups.)
- 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] lavc/flacdec: Increase residual limit from INT_MAX to UINT_MAX
On Fri, Apr 29, 2022 at 04:48:23PM +0200, Martijn van Beurden wrote:
> Op wo 6 apr. 2022 om 09:12 schreef Martijn van Beurden :
> >
> > Op di 5 apr. 2022 om 15:37 schreef Martijn van Beurden :
> > >
> > > ---
> > > libavcodec/flacdec.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/libavcodec/flacdec.c b/libavcodec/flacdec.c
> > > index dd6026f9de..cb32d7cae8 100644
> > > --- a/libavcodec/flacdec.c
> > > +++ b/libavcodec/flacdec.c
> > > @@ -260,7 +260,7 @@ static int decode_residuals(FLACContext *s, int32_t
> > > *decoded, int pred_order)
> > > for (; i < samples; i++)
> > > *decoded++ = get_sbits_long(&gb, tmp);
> > > } else {
> > > -int real_limit = tmp ? (INT_MAX >> tmp) + 2 : INT_MAX;
> > > +int real_limit = (tmp > 1) ? (INT_MAX >> (tmp - 1)) + 2 :
> > > INT_MAX;
> > > for (; i < samples; i++) {
> > > int v = get_sr_golomb_flac(&gb, tmp, real_limit, 1);
> > > if (v == 0x8000){
> > > --
> > > 2.30.2
> > >
> >
> > A file needing this patch to decode properly can be found here:
> > https://github.com/ktmf01/flac-test-files/blob/main/subset/63%20-%20predictor%20overflow%20check%2C%2024-bit.flac
> >
> > Kind regards, Martijn van Beurden
>
> Hereby I'd like to once more bring this patch to the attention of the
> mailinglist.
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Take away the freedom of one citizen and you will be jailed, take away
the freedom of all citizens and you will be congratulated by your peers
in Parliament.
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] FATE Errors
> On Apr 30, 2022, at 15:25, Soft Works wrote: > > > >> -Original Message- >> From: ffmpeg-devel On Behalf Of >> Felix LeClair >> Sent: Saturday, April 30, 2022 9:22 PM >> To: FFmpeg development discussions and patches > de...@ffmpeg.org> >> Subject: Re: [FFmpeg-devel] FATE Errors >> >> Both times I’ve encountered were on PopOS (think Debian/Ubuntu meets >> arch like timing release) > > VM or bare metal installation? > > PS: The people here don't like top-posting > > Thanks, > 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". It’s a bare metal installation, intel x86 12th gen, ecores disabled, AVX512 enabled (instructions include ice lake + FP16), kernel 5.18rc3. I don’t believe it matters in this case, but one was with a bare config, another with a fair few external libs enabled. Both resulted in the same. Re top posting: My bad! Currently on mobile, using an ssh app to get to my Mac. ___ 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] FATE Errors
On 4/30/2022 4:31 PM, Felix LeClair wrote: On Apr 30, 2022, at 15:25, Soft Works wrote: -Original Message- From: ffmpeg-devel On Behalf Of Felix LeClair Sent: Saturday, April 30, 2022 9:22 PM To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] FATE Errors Both times I’ve encountered were on PopOS (think Debian/Ubuntu meets arch like timing release) VM or bare metal installation? PS: The people here don't like top-posting Thanks, 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". It’s a bare metal installation, intel x86 12th gen, ecores disabled, AVX512 enabled (instructions include ice lake + FP16), kernel 5.18rc3. Then i was right. AVX512 support means av_cpu_max_align() returns 64. I don’t believe it matters in this case, but one was with a bare config, another with a fair few external libs enabled. Both resulted in the same. Re top posting: My bad! Currently on mobile, using an ssh app to get to my Mac. ___ 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] FATE Errors
> -Original Message- > From: ffmpeg-devel On Behalf Of > James Almer > Sent: Saturday, April 30, 2022 9:33 PM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] FATE Errors > > > > On 4/30/2022 4:31 PM, Felix LeClair wrote: > > > > > >> On Apr 30, 2022, at 15:25, Soft Works > wrote: > >> > >> > >> > >>> -Original Message- > >>> From: ffmpeg-devel On Behalf Of > >>> Felix LeClair > >>> Sent: Saturday, April 30, 2022 9:22 PM > >>> To: FFmpeg development discussions and patches >>> de...@ffmpeg.org> > >>> Subject: Re: [FFmpeg-devel] FATE Errors > >>> > >>> Both times I’ve encountered were on PopOS (think Debian/Ubuntu > meets > >>> arch like timing release) > >> > >> VM or bare metal installation? > >> > >> PS: The people here don't like top-posting > >> > >> Thanks, > >> 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". > > > > It’s a bare metal installation, intel x86 12th gen, ecores > disabled, AVX512 enabled (instructions include ice lake + FP16), > kernel 5.18rc3. > > Then i was right. AVX512 support means av_cpu_max_align() returns 64. Makes sense. Mine is 11 gen and I looked at the CI build history (https://dev.azure.com/githubsync/ffmpeg/_build?definitionId=9&_a=summary) which shows some runs have passed and some failed during the recent past - probably depending on the host machine type that gets the job. 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] FATE Errors
James Almer: > > > On 4/30/2022 4:06 PM, Andreas Rheinhardt wrote: >> Soft Works: >>> Hi, >>> >>> is it a known issue that the current head of the master branch has >>> FATE errors? >>> >>> I get the same locally as well as on the automated GitHub build. >>> One is this: >>> >>> --- ./tests/ref/vsynth/vsynth2-mpeg2-422 2022-04-30 >>> 14:23:44.330424058 + >>> +++ tests/data/fate/vsynth2-mpeg2-422 2022-04-30 14:38:41.071678201 >>> + >>> @@ -1,4 +1,4 @@ >>> -b2fa9b73c3547191ecc01b8163abd4e5 >>> *tests/data/fate/vsynth2-mpeg2-422.mpeg2video >>> -379164 tests/data/fate/vsynth2-mpeg2-422.mpeg2video >>> -704f6a96f93c2409219bd48b74169041 >>> *tests/data/fate/vsynth2-mpeg2-422.out.rawvideo >>> -stddev: 4.17 PSNR: 35.73 MAXDIFF: 70 bytes: 7603200/ 7603200 >>> +8f6d565723ccf879ab2b5aa910b7ce21 >>> *tests/data/fate/vsynth2-mpeg2-422.mpeg2video >>> +380544 tests/data/fate/vsynth2-mpeg2-422.mpeg2video >>> +0797fddea4835687dedddebbbe98fa8f >>> *tests/data/fate/vsynth2-mpeg2-422.out.rawvideo >>> +stddev: 4.16 PSNR: 35.73 MAXDIFF: 75 bytes: 7603200/ 7603200 >>> Test vsynth2-mpeg2-422 failed. Look at >>> tests/data/fate/vsynth2-mpeg2-422.err for details. >>> make: *** [tests/Makefile:277: fate-vsynth2-mpeg2-422] Error 1 >>> >>> >>> Is anybody seeing the same? >>> >>> Thanks, >>> sw >> >> http://fate.ffmpeg.org/ doesn't show recent regressions and FATE is fine >> for me locally. I recently made changes to FATE (namely the test >> requirements, vcodec.mak (where the vsynth-tests reside) among the files >> affected), so I am interested in whether the failing tests are >> concentrated on the files recently changed by me (it would obviously not >> haved pushed them if I knew them to cause issues; also patchwork was >> fine). >> Are these issues reproducible? Can you bisect them? >> >> - Andreas > > This may be the alignment issue introduced in lavfi in > https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=17a59a634c39b00a680c6ebbaea58db95594d13d > assuming it was not fixed. > I think it only affected targets where av_cpu_max_align() returned 64. You are completely right: Just making av_cpu_max_align return 64 allows to reproduce the issue. And it has nothing to do with my recent FATE patches (545e87f49dc9fa5b880e330fc4e1854df68cc0f1 would be the only contender for changes). - 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".
[FFmpeg-devel] [PATCH 0/3] 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. softworkz (3): 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 | 3 ++ libavfilter/vf_hwmap.c | 4 +- libavfilter/vf_hwupload.c | 2 +- libavutil/hwcontext.c | 72 +++--- libavutil/hwcontext.h | 20 ++ libavutil/hwcontext_internal.h | 6 +++ libavutil/hwcontext_qsv.c | 13 -- libavutil/version.h| 4 +- 8 files changed, 110 insertions(+), 14 deletions(-) base-commit: eef652ca9c893a84c6430fcdd53eed186c299d82 Published-As: https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-25%2Fsoftworkz%2Fderive_devices-v1 Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging-25/softworkz/derive_devices-v1 Pull-Request: https://github.com/ffstaging/FFmpeg/pull/25 -- 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 1/3] 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 | 72 +++---
libavutil/hwcontext.h | 20 ++
libavutil/hwcontext_internal.h | 6 +++
libavutil/hwcontext_qsv.c | 13 --
4 files changed, 102 insertions(+), 9 deletions(-)
diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
index ab9ad3703e..1aea7dd5c3 100644
--- a/libavutil/hwcontext.c
+++ b/libavutil/hwcontext.c
@@ -123,6 +123,7 @@ static const AVClass hwdevice_ctx_class = {
static void hwdevice_ctx_free(void *opaque, uint8_t *data)
{
AVHWDeviceContext *ctx = (AVHWDeviceContext*)data;
+int i;
/* uninit might still want access the hw context and the user
* free() callback might destroy it, so uninit has to be called first */
@@ -133,6 +134,8 @@ static void hwdevice_ctx_free(void *opaque, uint8_t *data)
ctx->free(ctx);
av_buffer_unref(&ctx->internal->source_device);
+for (i = 0; i < AV_HWDEVICE_TYPE_NB; i++)
+av_buffer_unref(&ctx->internal->derived_devices[i]);
av_freep(&ctx->hwctx);
av_freep(&ctx->internal->priv);
@@ -644,10 +647,31 @@ fail:
return ret;
}
-int av_hwdevice_ctx_create_derived_opts(AVBufferRef **dst_ref_ptr,
-enum AVHWDeviceType type,
-AVBufferRef *src_ref,
-AVDictionary *options, int flags)
+static AVBufferRef* find_derived_hwdevice_ctx(AVBufferRef *src_ref, enum
AVHWDeviceType type)
+{
+AVBufferRef *tmp_ref;
+AVHWDeviceContext *src_ctx;
+int i;
+
+src_ctx = (AVHWDeviceContext*)src_ref->data;
+if (src_ctx->type == type)
+return src_ref;
+
+for (i = 0; i < AV_HWDEVICE_TYPE_NB; i++)
+if (src_ctx->internal->derived_devices[i]) {
+tmp_ref =
find_derived_hwdevice_ctx(src_ctx->internal->derived_devices[i], type);
+if (tmp_ref)
+return tmp_ref;
+}
+
+return NULL;
+}
+
+static int hwdevice_ctx_create_derived(AVBufferRef **dst_ref_ptr,
+ enum AVHWDeviceType type,
+ AVBufferRef *src_ref,
+ AVDictionary *options, int flags,
+ int get_existing)
{
AVBufferRef *dst_ref = NULL, *tmp_ref;
AVHWDeviceContext *dst_ctx, *tmp_ctx;
@@ -667,6 +691,18 @@ int av_hwdevice_ctx_create_derived_opts(AVBufferRef
**dst_ref_ptr,
tmp_ref = tmp_ctx->internal->source_device;
}
+if (get_existing) {
+tmp_ref = find_derived_hwdevice_ctx(src_ref, type);
+if (tmp_ref) {
+dst_ref = av_buffer_ref(tmp_ref);
+if (!dst_ref) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
+goto done;
+}
+}
+
dst_ref = av_hwdevice_ctx_alloc(type);
if (!dst_ref) {
ret = AVERROR(ENOMEM);
@@ -688,6 +724,13 @@ int av_hwdevic
[FFmpeg-devel] [PATCH 2/3] 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 | 3 +++ libavutil/version.h | 4 ++-- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/doc/APIchanges b/doc/APIchanges index 1a9f0a303e..3d467bd3d6 100644 --- a/doc/APIchanges +++ b/doc/APIchanges @@ -14,6 +14,9 @@ libavutil: 2021-04-27 API changes, most recent first: +2022-04-30 - xx - lavu 57.25.100 - hwcontext.h + Add av_hwdevice_ctx_get_or_create_derived(). + 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 diff --git a/libavutil/version.h b/libavutil/version.h index 6735c20090..dd7d20a9fa 100644 --- a/libavutil/version.h +++ b/libavutil/version.h @@ -79,8 +79,8 @@ */ #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_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \ LIBAVUTIL_VERSION_MINOR, \ -- 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 3/3] 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(&device, type,
- hwfc->device_ref, 0);
+err = av_hwdevice_ctx_get_or_create_derived(&device, 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(
&ctx->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".
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/h2645_parse: Check HEVC NAL size
Michael Niedermayer:
> Fixes: Assertion failure
> Fixes:
> 46662/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-4947860854013952
>
> This also results in more frames to be decoded from fate samples
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/h2645_parse.c | 2 +-
> .../ref/fate/hevc-conformance-NoOutPrior_A_Qualcomm_1 | 10 ++
> tests/ref/fate/hevc-conformance-RAP_B_Bossen_1 | 3 +++
> 3 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
> index 03780680c6..78ab22b76e 100644
> --- a/libavcodec/h2645_parse.c
> +++ b/libavcodec/h2645_parse.c
> @@ -292,7 +292,7 @@ static int hevc_parse_nal_header(H2645NAL *nal, void
> *logctx)
> {
> GetBitContext *gb = &nal->gb;
>
> -if (get_bits1(gb) != 0)
> +if (get_bits_left(gb) < 16 || get_bits1(gb) != 0)
> return AVERROR_INVALIDDATA;
>
> nal->type = get_bits(gb, 6);
> diff --git a/tests/ref/fate/hevc-conformance-NoOutPrior_A_Qualcomm_1
> b/tests/ref/fate/hevc-conformance-NoOutPrior_A_Qualcomm_1
> index 0c930f6556..3283925e38 100644
> --- a/tests/ref/fate/hevc-conformance-NoOutPrior_A_Qualcomm_1
> +++ b/tests/ref/fate/hevc-conformance-NoOutPrior_A_Qualcomm_1
> @@ -25,6 +25,16 @@
> 0, 19, 19,1, 599040, 0x4227009b
> 0, 20, 20,1, 599040, 0x1bda8be4
> 0, 21, 21,1, 599040, 0xd1d5dcb4
> +0, 22, 22,1, 599040, 0x58b2edb3
> +0, 23, 23,1, 599040, 0xd1f795d8
> +0, 24, 24,1, 599040, 0x3331d5e6
> +0, 25, 25,1, 599040, 0x5e5ec2c9
> +0, 26, 26,1, 599040, 0x3b907bf5
> +0, 27, 27,1, 599040, 0xefcbf471
> +0, 28, 28,1, 599040, 0x2769a578
> +0, 29, 29,1, 599040, 0x812ce986
> +0, 30, 30,1, 599040, 0xf07c212c
> +0, 31, 31,1, 599040, 0xb5476890
> 0, 32, 32,1, 599040, 0x00a0249f
> 0, 33, 33,1, 599040, 0x7263f7cf
> 0, 34, 34,1, 599040, 0x47054be4
> diff --git a/tests/ref/fate/hevc-conformance-RAP_B_Bossen_1
> b/tests/ref/fate/hevc-conformance-RAP_B_Bossen_1
> index e661ff245e..776267b59c 100644
> --- a/tests/ref/fate/hevc-conformance-RAP_B_Bossen_1
> +++ b/tests/ref/fate/hevc-conformance-RAP_B_Bossen_1
> @@ -70,6 +70,9 @@
> 0, 64, 64,1, 149760, 0x3362678b
> 0, 65, 65,1, 149760, 0x6e7fc851
> 0, 66, 66,1, 149760, 0x33f96449
> +0, 67, 67,1, 149760, 0xd9d05007
> +0, 75, 75,1, 149760, 0x477f2cf2
> +0, 76, 76,1, 149760, 0xe1f9ccd0
> 0, 77, 77,1, 149760, 0xb3ba8cfb
> 0, 78, 78,1, 149760, 0x64787995
> 0, 79, 79,1, 149760, 0xc10de4c4
get_bit_length currently presumes every NALU to contain
rbsp_trailing_bits. Yet this is not true for the End of
Sequence/Bitstream units which are just headers without RBSP. For these
units, get_bit_length might truncate them -- it does so for end of
sequence units in H.264. It would not be a serious issue for H.265, as
the semantics of nuh_temporal_id_plus1 require nuh_temporal_id_plus1 to
be 1 for End of Sequence/Bitstream units. Nevertheless I think this
should be coupled with a patch that does not truncate the NAL unit if it
is just a header.
- 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 v2 5/7] avcodec/cbs_sei: refactor to use avutil/uuid
On Sat, Apr 30, 2022 at 12:26 PM Mark Thompson wrote:
>
> On 30/04/2022 18:53, Pierre-Anthony Lemieux wrote:
> > On Sat, Apr 30, 2022 at 10:31 AM Mark Thompson wrote:
> >>
> >> On 24/04/2022 11:14, Zane van Iperen wrote:
> >>> From: Pierre-Anthony Lemieux
> >>>
> >>> ---
> >>>libavcodec/cbs_sei.h | 3 ++-
> >>>libavcodec/vaapi_encode_h264.c | 8
> >>>2 files changed, 6 insertions(+), 5 deletions(-)
> >>>
> >>> diff --git a/libavcodec/cbs_sei.h b/libavcodec/cbs_sei.h
> >>> index c7a7a95be0..67c6e6cbbd 100644
> >>> --- a/libavcodec/cbs_sei.h
> >>> +++ b/libavcodec/cbs_sei.h
> >>> @@ -23,6 +23,7 @@
> >>>#include
> >>>
> >>>#include "libavutil/buffer.h"
> >>> +#include "libavutil/uuid.h"
> >>>
> >>>#include "cbs.h"
> >>>#include "sei.h"
> >>> @@ -41,7 +42,7 @@ typedef struct SEIRawUserDataRegistered {
> >>>} SEIRawUserDataRegistered;
> >>>
> >>>typedef struct SEIRawUserDataUnregistered {
> >>> -uint8_t uuid_iso_iec_11578[16];
> >>> +AVUUID uuid_iso_iec_11578;
> >>>uint8_t *data;
> >>>AVBufferRef *data_ref;
> >>>size_t data_length;
> >>
> >> This feels like a step backwards? The syntax template files are
> >> explicitly relying on this being uint8_t[16], so giving it a different
> >> name is confusing.
> >
> > What/where are the syntax template files?
>
>
>
> (It's included twice by cbs_h2645.c for read/write with different macro
> setups.)
Ok. Thanks. Are you concerned that the following line assumes that
uuid_iso_iec_11578 is uint8_t[16] instead of being the opaque AVUUID?
us(8, uuid_iso_iec_11578[i], 0x00, 0xff, 1, i);
Did I get this right? If so, couple of options come to mind:
(a) revert the change
(b) define a macro to access individual bytes of AVUUID, thereby
keeping AVUUID opaque
(c) not handle AVUUID as opaque, but instead always as uint8_t[16]
Maybe additional options exist.
I do not have a definitive opinion. Some folks expressed strong
interest in having a consistent scheme for manipulating UUIDs.
>
> - 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 1/3] avutils/hwcontext: add derive-device function which searches for existing devices in both directions
On 30/04/2022 21:07, softworkz wrote:
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 | 72 +++---
libavutil/hwcontext.h | 20 ++
libavutil/hwcontext_internal.h | 6 +++
libavutil/hwcontext_qsv.c | 13 --
4 files changed, 102 insertions(+), 9 deletions(-)
Yeah, something like this seems fair.
Some general comments:
* Whenever you use derivation it creates a circular reference, so the instances
can never be freed in the current implementation.
* The thread-safety properties of the hwcontext API have been lost - you can no
longer operate on devices independently across threads (insofar as the
underlying API allows that).
Maybe there is an argument that derivation is something which should happen
early on and therefore documenting it as thread-unsafe is ok, but when
hwupload/hwmap can use it inside filtergraphs that just isn't going to happen
(and will be violated in the FFmpeg utility if filters get threaded, as is
being worked on).
* I'm not sure that it is reasonable to ignore options. If an unrelated
component derived a device before you with special options, you might get that
device even if you have incompatible different options.
diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
index ab9ad3703e..1aea7dd5c3 100644
--- a/libavutil/hwcontext.c
+++ b/libavutil/hwcontext.c
@@ -123,6 +123,7 @@ static const AVClass hwdevice_ctx_class = {
static void hwdevice_ctx_free(void *opaque, uint8_t *data)
{
AVHWDeviceContext *ctx = (AVHWDeviceContext*)data;
+int i;
/* uninit might still want access the hw context and the user
* free() callback might destroy it, so uninit has to be called first */
@@ -133,6 +134,8 @@ static void hwdevice_ctx_free(void *opaque, uint8_t *data)
ctx->free(ctx);
av_buffer_unref(&ctx->internal->source_device);
+for (i = 0; i < AV_HWDEVICE_TYPE_NB; i++)
+av_buffer_unref(&ctx->internal->derived_devices[i]);
av_freep(&ctx->hwctx);
av_freep(&ctx->internal->priv);
@@ -644,10 +647,31 @@ fail:
return ret;
}
-int av_hwdevice_ctx_create_derived_opts(AVBufferRef **dst_ref_ptr,
-enum AVHWDeviceType type,
-AVBufferRef *src_ref,
-AVDictionary *options, int flags)
+static AVBufferRef* find_derived_hwdevice_ctx(AVBufferRef *src_ref, enum
AVHWDeviceType type)
+{
+AVBufferRef *tmp_ref;
+AVHWDeviceContext *src_ctx;
+int i;
+
+src_ctx = (AVHWDeviceContext*)src_ref->data;
+if (src_ctx->type == type)
+return src_ref;
+
+for (i = 0; i < AV_HWDEVICE_TYPE_NB; i++)
+if (src_ctx->internal->derived_devices[i]) {
+tmp_ref =
find_derived_hwdevice_ctx(src_ctx->internal->derived_devices[i], type);
+if (tmp_ref)
+return tmp_ref;
+}
+
+return NULL;
+}
+
+static int hwdevice_ctx_create_de
Re: [FFmpeg-devel] [PATCH 4/7] avcodec/codec_internal: Use union for FFCodec decode/encode callbacks
On Thu, Mar 31, 2022 at 12:49:55AM +0200, Andreas Rheinhardt wrote: > This is possible, because every given FFCodec has to implement > exactly one of these. Doing so decreases sizeof(FFCodec) and > therefore decreases the size of the binary. > Notice that in case of position-independent code the decrease > is in .data.rel.ro, so that this translates to decreased > memory consumption. by how much did the space requirement decrease ? iam asking because while a single such change isnt a issue if we accumulate alot of this in the API, the API may become actually hard to understand by new developers [...] thx -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "Nothing to hide" only works if the folks in power share the values of you and everyone you know entirely and always will -- Tom Scott 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/3] avutils/hwcontext: add derive-device function which searches for existing devices in both directions
> -Original Message-
> From: ffmpeg-devel On Behalf Of Mark
> Thompson
> Sent: Saturday, April 30, 2022 11:39 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 1/3] avutils/hwcontext: add derive-
> device function which searches for existing devices in both directions
>
> On 30/04/2022 21:07, softworkz wrote:
> > 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 | 72
> +++---
> > libavutil/hwcontext.h | 20 ++
> > libavutil/hwcontext_internal.h | 6 +++
> > libavutil/hwcontext_qsv.c | 13 --
> > 4 files changed, 102 insertions(+), 9 deletions(-)
>
> Yeah, something like this seems fair.
:-)
> Some general comments:
>
> * Whenever you use derivation it creates a circular reference, so the
> instances can never be freed in the current implementation.
It's been a while...I thought there wasn't, but looking at it now,
it seems you are right.
How would you solve it?
> * The thread-safety properties of the hwcontext API have been lost -
> you can no longer operate on devices independently across threads
> (insofar as the underlying API allows that).
>Maybe there is an argument that derivation is something which
> should happen early on and therefore documenting it as thread-unsafe
> is ok, but when hwupload/hwmap can use it inside filtergraphs that
> just isn't going to happen (and will be violated in the FFmpeg utility
> if filters get threaded, as is being worked on).
>From my understanding there will be a single separate thread which
handles all filtergraph operations.
I don't think it would even be possible (without massive changes)
to arbitrate filter processing in parallel.
But even if this would be implemented: the filtergraph setup (init,
uninit, query_formats, etc.) would surely happen on a single thread.
> * I'm not sure that it is reasonable to ignore options. If an
> unrelated component derived a device before you with special options,
> you might get that device even if you have incompatible different
> options.
I understand what you mean, but this is outside the scope of
this patchset, because when you would want to do this, it
would need to be implemented for derivation in general, not
in this patchset which only adds reverse-search to the
existing derivation functionality.
> > diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
> > index ab9ad3703e..1aea7dd5c3 100644
> > --- a/libavutil/hwcontext.c
> > +++ b/libavutil/hwcontext.c
> > @@ -123,6 +123,7 @@ static const AVClass hwdevice_ctx_class = {
> > static void hwdevice_ctx_free(void *opaque, uint8_t *data)
> > {
> > AVHWDeviceContext *ctx = (AVHWDeviceContext*)data;
> > +int i;
> >
> > /* uninit might still want access the hw context and the user
Re: [FFmpeg-devel] [PATCH v7 05/10] qsv: build audio related code when MFX_VERSION < 2.0
On Sat, 2022-04-30 at 16:51 +, Soft Works wrote: > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Xiang, Haihao > > Sent: Wednesday, April 6, 2022 5:38 AM > > To: an...@khirnov.net; ffmpeg-devel@ffmpeg.org > > Subject: Re: [FFmpeg-devel] [PATCH v7 05/10] qsv: build audio related > > code when MFX_VERSION < 2.0 > > > > On Tue, 2022-04-05 at 13:50 +0200, Anton Khirnov wrote: > > > Quoting Xiang, Haihao (2022-03-11 09:16:25) > > > > From: Haihao Xiang > > > > > > > > Audio isn't supported for MFX_VERSION >= 2.0[1][2]. This is in > > > > preparation for oneVPL support > > > > > > > > [1]: > > > > > > > > https://spec.oneapi.io/versions/latest/elements/oneVPL/source/VPL_inte > > l_media_sdk.html#msdk-full-name-feature-removals > > > > [2]: https://github.com/oneapi-src/oneVPL > > > > --- > > > > libavcodec/qsv.c | 5 + > > > > libavfilter/qsvvpp.c | 6 ++ > > > > libavfilter/qsvvpp.h | 2 ++ > > > > 3 files changed, 13 insertions(+) > > > > > > Why not just remove this completely? > > > None of our QSV code does anything with audio. > > > > It was removed in an older version, however someone objected the > > removal of > > this. See > > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200819061023.44330 > > 4-2-haihao.xi...@intel.com/ > > I think this was a misunderstanding. I see not objection. One was > just asking "why" and the other one had missed the point that audio > has never been functional. Please find the comment below in the original thread "This seems like a generic translation from the library errors to FF error codes. So even if we'll never touch the audio functionality of it, I'd prefer to have that struct complete already" So my understanding was that the reviewer preferred to keep the audio stuff unchanged for libmfx. > > I agree with Anton that the audio stuff should be removed > completely - ideally even beforehand in a separate patch. Actually I prefer to remove the audio stuff too. I may submit a separate patch if no more comments. 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 v7 05/10] qsv: build audio related code when MFX_VERSION < 2.0
> -Original Message- > From: ffmpeg-devel On Behalf Of > Xiang, Haihao > Sent: Sunday, May 1, 2022 4:16 AM > To: an...@khirnov.net; ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH v7 05/10] qsv: build audio related > code when MFX_VERSION < 2.0 > > On Sat, 2022-04-30 at 16:51 +, Soft Works wrote: > > > -Original Message- > > > From: ffmpeg-devel On Behalf Of > > > Xiang, Haihao > > > Sent: Wednesday, April 6, 2022 5:38 AM > > > To: an...@khirnov.net; ffmpeg-devel@ffmpeg.org > > > Subject: Re: [FFmpeg-devel] [PATCH v7 05/10] qsv: build audio > related > > > code when MFX_VERSION < 2.0 > > > > > > On Tue, 2022-04-05 at 13:50 +0200, Anton Khirnov wrote: > > > > Quoting Xiang, Haihao (2022-03-11 09:16:25) > > > > > From: Haihao Xiang > > > > > > > > > > Audio isn't supported for MFX_VERSION >= 2.0[1][2]. This is in > > > > > preparation for oneVPL support > > > > > > > > > > [1]: > > > > > > > > > > > > https://spec.oneapi.io/versions/latest/elements/oneVPL/source/VPL_inte > > > l_media_sdk.html#msdk-full-name-feature-removals > > > > > [2]: https://github.com/oneapi-src/oneVPL > > > > > --- > > > > > libavcodec/qsv.c | 5 + > > > > > libavfilter/qsvvpp.c | 6 ++ > > > > > libavfilter/qsvvpp.h | 2 ++ > > > > > 3 files changed, 13 insertions(+) > > > > > > > > Why not just remove this completely? > > > > None of our QSV code does anything with audio. > > > > > > It was removed in an older version, however someone objected the > > > removal of > > > this. See > > > > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200819061023.44330 > > > 4-2-haihao.xi...@intel.com/ > > > > I think this was a misunderstanding. I see not objection. One was > > just asking "why" and the other one had missed the point that audio > > has never been functional. > > Please find the comment below in the original thread > > "This seems like a generic translation from the library errors to FF > error > codes. So even if we'll never touch the audio functionality of it, I'd > prefer > to have that struct complete already" > > So my understanding was that the reviewer preferred to keep the audio > stuff > unchanged for libmfx. Hm, I hadn't see that here: https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200819061023.443304-2-haihao.xi...@intel.com/ Considering the text again: > "This seems like a generic translation from the library errors to FF > error > codes. So even if we'll never touch the audio functionality of it, I'd > prefer > to have that struct complete already" I understand the idea. Normally those lines wouldn't hurt. But now, that we're facing some kind of "#ifdef hell" anyway, I think it would be much better to minimize this as much as possible, and there's really no point in translating audio error codes. Also, the struct has never been really complete. Instead of retaining unused audio error codes, we should better add those that are missing (like -21, -22 and others) and relevant. @Thilo - can we get you warm with that? As an alternative, we could simply replace the two audio definitions with plain integer values (MFX_ERR_INVALID_AUDIO_PARAM >> -19) This is a small bit only, but before adding the oneVPL stuff, I think we should consolidate the conditional stuff as much as possible. As discussed before, we also need to settle for a minimum libmfx SDK version (compile-time, not runtime!). This will allow to drop quite an amount of conditional code, and this cleanup should be done before getting to oneVPL. Another thing that is a bit unfortunate is that we are duplicating this error mapping struct in qsv.c and qsvvpp.c. I don't mean that it should be linked as an external between avfilter and avcodec, but it should come (be included) from a single file. 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 v08 09/10] qsv: use a new method to create mfx session when using oneVPL
On Sat, 2022-04-30 at 17:14 +0100, Mark Thompson wrote:
> On 28/04/2022 10:23, Haihao Xiang wrote:
> > 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
> > ---
> > libavcodec/qsv.c | 197 ++--
> > libavcodec/qsv_internal.h| 1 +
> > libavcodec/qsvdec.c | 10 +
> > libavcodec/qsvenc.h | 3 +
> > libavcodec/qsvenc_h264.c | 1 -
> > libavcodec/qsvenc_hevc.c | 1 -
> > libavcodec/qsvenc_jpeg.c | 1 -
> > libavcodec/qsvenc_mpeg2.c| 1 -
> > libavcodec/qsvenc_vp9.c | 1 -
> > libavfilter/qsvvpp.c | 113 ++-
> > libavfilter/qsvvpp.h | 5 +
> > libavfilter/vf_deinterlace_qsv.c | 14 +-
> > libavfilter/vf_scale_qsv.c | 12 +-
> > libavutil/hwcontext_d3d11va.c| 7 +
> > libavutil/hwcontext_qsv.c| 515 ---
> > libavutil/hwcontext_qsv.h| 1 +
> > libavutil/hwcontext_vaapi.c | 13 +
> > libavutil/hwcontext_vaapi.h | 4 +
> > 18 files changed, 812 insertions(+), 88 deletions(-)
> >
> > ...
> > diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
> > index 8ab96bad25..fd5fedbdac 100644
> > --- a/libavutil/hwcontext_d3d11va.c
> > +++ b/libavutil/hwcontext_d3d11va.c
> > @@ -525,6 +525,11 @@ static void d3d11va_device_uninit(AVHWDeviceContext
> > *hwdev)
> > }
> > }
> >
> > +static void d3d11va_device_free(AVHWDeviceContext *ctx)
> > +{
> > +AVD3D11VADeviceContext *hwctx = ctx->hwctx;
> > +}
> > +
> > static int d3d11va_device_create(AVHWDeviceContext *ctx, const char
> > *device,
> >AVDictionary *opts, int flags)
> > {
> > @@ -537,6 +542,8 @@ static int d3d11va_device_create(AVHWDeviceContext *ctx,
> > const char *device,
> > int is_debug = !!av_dict_get(opts, "debug", NULL, 0);
> > int ret;
> >
> > +ctx->free = d3d11va_device_free;
> > +
> > // (On UWP we can't check this.)
> > #if !HAVE_UWP
> > if (!LoadLibrary("d3d11_1sdklayers.dll"))
>
> This change doesn't do anything.
thanks, this callback is not used and should be removed.
>
> > ...
> > diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> > index c3a98bc4b1..cb714df934 100644
> > --- a/libavutil/hwcontext_vaapi.c
> > +++ b/libavutil/hwcontext_vaapi.c
> > @@ -1572,6 +1572,7 @@ static void vaapi_device_free(AVHWDeviceContext *ctx)
> > if (priv->drm_fd >= 0)
> > close(priv->drm_fd);
> >
> > +av_free(hwctx->device_name);
> > av_freep(&priv);
> > }
> >
> > @@ -1620,6 +1621,7 @@ static int vaapi_device_connect(AVHWDeviceContext
> > *ctx,
> > static int vaapi_device_create(AVHWDeviceContext *ctx, const char *device,
> > AVDictionary *opts, int flags)
> > {
> > +AVVAAPIDeviceContext *hwctx = ctx->hwctx;
> > VAAPIDevicePriv *priv;
> > VADisplay display = NULL;
> > const AVDictionaryEntry *ent;
> > @@ -1665,6 +1667,11 @@ static int vaapi_device_create(AVHWDeviceContext
> > *ctx, const char *device,
> > "DRM device node.\n", device);
> > break;
> > }
> > +
> > +hwctx->device_name = av_strdup(device);
> > +
> > +if (!hwctx->device_name)
> > +return AVERROR(ENOMEM);
> > } else {
> > char path[64];
> > int n, max_devices = 8;
> > @@ -1705,6 +1712,12 @@ static int vaapi_device_create(AVHWDeviceContext
> > *ctx, const char *device,
> > av_log(ctx, AV_LOG_VERBOSE, "Trying to use "
> > "DRM render node for device %d.\n", n);
> > }
> > +
> > +hwctx->device_name = av_strdup(path);
> > +
> > +if (!hwctx->device_name)
> > +return AVERROR(ENOMEM);
> > +
> > break;
> > }
> > if (n >= max_devices)
> > diff --git a/libavutil/hwcontext_vaapi.h b/libavutil/hwcontext_vaapi.h
> > index 0b2e071cb3..3e0b54f5e9 100644
> > --- a/libavutil/hwcontext_vaapi.h
> > +++ b/libavutil/hwcontext_vaapi.h
> > @@ -78,6 +78,10 @@ typedef struct AVVAAPIDeviceContext {
> >* operations using VAAPI with the same VADisplay.
> >*/
> > unsigned int driver_quirks;
> > +/**
> > + * The string for the used device
> > + */
> > +char *device_name;
>
Re: [FFmpeg-devel] [PATCH v2 1/5] avutil/hwcontext_d3d11va: fix the uninitialized texture bindflag
On Sat, 2022-04-30 at 13:59 +, Soft Works wrote: > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Hendrik Leppkes > > Sent: Saturday, April 30, 2022 12:02 AM > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [PATCH v2 1/5] avutil/hwcontext_d3d11va: > > fix the uninitialized texture bindflag > > > > On Fri, Apr 29, 2022 at 12:45 PM Tong Wu > > wrote: > > > > > > When uploading rawvideos using d3d11va hardware framecontext, the > > > > bindflag > > > is not initialized and will cause creating texture failure. Now fix > > > > it, > > > assign it the value of D3D11_BIND_RENDER_TARGET. > > > > > > > As with similar fixes of this nature, this implicit behavior to fix > > one particular bug does not seem fitting inside the hwcontext itself. > > There can be a large list of usages of the hwcontext that all require > > different BindFlags, but we can only define one default - why this one > > specifically? > > I agree that this change is not ideal. On one side, it is "safe" in a way > that a texture is practically unusable for video processing without having > at least one of the flags (decoder, encoder or render_target), > so this wouldn't "hurt" anybody. > > > So rather: > > > > Where is the context created? > > Looking at the command line in the commit message, this is about > standalone D3D11 context creation. > > > Why is a required flag not set there? That would be better, because > > that knows what flags it needs. > > There doesn't really exist an appropriate "there". I see two options > > 1. Add a generic internal device creation parameter to the dictionary >in ffmpeg_hw.c like "standalone=1" >(for all devices created via init_hw_device) > > Some time ago, I had another case where I thought this could be useful. > Then, this could be used in d3d11va_device_create() to set an internal > field 'default_bindflags' which would be used as condition in > d3d11va_frames_init. The situation would remain similar though, as that > when the device is used by a decoder (which sets the decoder flag) > this needs to override the default. > > 2. Use a device parameter specific to the D3D11 > hwcontextD3D11_BIND_RENDER_TARGET > > This would need to be specified in the command line. > Everything else like in #1 > > What do you think? There aren't extra parameters for other standalone hwcontext creation. May we take BindFlags=0 as the default setting and set texDesc.BindFlags to D3D11_BIND_RENDER_TARGET directly ? 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 v7 05/10] qsv: build audio related code when MFX_VERSION < 2.0
On Sun, 2022-05-01 at 03:10 +, Soft Works wrote: > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Xiang, Haihao > > Sent: Sunday, May 1, 2022 4:16 AM > > To: an...@khirnov.net; ffmpeg-devel@ffmpeg.org > > Subject: Re: [FFmpeg-devel] [PATCH v7 05/10] qsv: build audio related > > code when MFX_VERSION < 2.0 > > > > On Sat, 2022-04-30 at 16:51 +, Soft Works wrote: > > > > -Original Message- > > > > From: ffmpeg-devel On Behalf Of > > > > Xiang, Haihao > > > > Sent: Wednesday, April 6, 2022 5:38 AM > > > > To: an...@khirnov.net; ffmpeg-devel@ffmpeg.org > > > > Subject: Re: [FFmpeg-devel] [PATCH v7 05/10] qsv: build audio > > > > related > > > > code when MFX_VERSION < 2.0 > > > > > > > > On Tue, 2022-04-05 at 13:50 +0200, Anton Khirnov wrote: > > > > > Quoting Xiang, Haihao (2022-03-11 09:16:25) > > > > > > From: Haihao Xiang > > > > > > > > > > > > Audio isn't supported for MFX_VERSION >= 2.0[1][2]. This is in > > > > > > preparation for oneVPL support > > > > > > > > > > > > [1]: > > > > > > > > > > > > > > > > > > https://spec.oneapi.io/versions/latest/elements/oneVPL/source/VPL_inte > > > > l_media_sdk.html#msdk-full-name-feature-removals > > > > > > [2]: https://github.com/oneapi-src/oneVPL > > > > > > --- > > > > > > libavcodec/qsv.c | 5 + > > > > > > libavfilter/qsvvpp.c | 6 ++ > > > > > > libavfilter/qsvvpp.h | 2 ++ > > > > > > 3 files changed, 13 insertions(+) > > > > > > > > > > Why not just remove this completely? > > > > > None of our QSV code does anything with audio. > > > > > > > > It was removed in an older version, however someone objected the > > > > removal of > > > > this. See > > > > > > > > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200819061023.44330 > > > > 4-2-haihao.xi...@intel.com/ > > > > > > I think this was a misunderstanding. I see not objection. One was > > > just asking "why" and the other one had missed the point that audio > > > has never been functional. > > > > Please find the comment below in the original thread > > > > "This seems like a generic translation from the library errors to FF > > error > > codes. So even if we'll never touch the audio functionality of it, I'd > > prefer > > to have that struct complete already" > > > > So my understanding was that the reviewer preferred to keep the audio > > stuff > > unchanged for libmfx. > > Hm, I hadn't see that here: > > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200819061023.443304-2-haihao.xi...@intel.com/ > > Considering the text again: > > > "This seems like a generic translation from the library errors to FF > > error > > codes. So even if we'll never touch the audio functionality of it, I'd > > prefer > > to have that struct complete already" > > I understand the idea. Normally those lines wouldn't hurt. But now, that > we're facing some kind of "#ifdef hell" anyway, I think it would be much > better to minimize this as much as possible, and there's really no point > in translating audio error codes. > Also, the struct has never been really complete. Instead of retaining > unused audio error codes, we should better add those that are missing > (like -21, -22 and others) and relevant. > > @Thilo - can we get you warm with that? > > As an alternative, we could simply replace the two audio definitions with > plain integer values (MFX_ERR_INVALID_AUDIO_PARAM >> -19) > > > This is a small bit only, but before adding the oneVPL stuff, I think > we should consolidate the conditional stuff as much as possible. > > As discussed before, we also need to settle for a minimum libmfx SDK > version (compile-time, not runtime!). This will allow to drop quite > an amount of conditional code, and this cleanup should be done before > getting to oneVPL. Sure, I'll submit a patch for it. > > Another thing that is a bit unfortunate is that we are duplicating this > error mapping struct in qsv.c and qsvvpp.c. > I don't mean that it should be linked as an external between avfilter > and avcodec, but it should come (be included) from a single file. We moved the static error table to a .h in the past however it resulted in link error when building FFmpeg with static libraries. 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 v2 1/5] avutil/hwcontext_d3d11va: fix the uninitialized texture bindflag
> -Original Message- > From: ffmpeg-devel On Behalf Of > Xiang, Haihao > Sent: Sunday, May 1, 2022 6:15 AM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH v2 1/5] avutil/hwcontext_d3d11va: > fix the uninitialized texture bindflag > > On Sat, 2022-04-30 at 13:59 +, Soft Works wrote: > > > -Original Message- > > > From: ffmpeg-devel On Behalf Of > > > Hendrik Leppkes > > > Sent: Saturday, April 30, 2022 12:02 AM > > > To: FFmpeg development discussions and patches > > de...@ffmpeg.org> > > > Subject: Re: [FFmpeg-devel] [PATCH v2 1/5] > avutil/hwcontext_d3d11va: > > > fix the uninitialized texture bindflag > > > > > > On Fri, Apr 29, 2022 at 12:45 PM Tong Wu > > > wrote: > > > > > > > > When uploading rawvideos using d3d11va hardware framecontext, > the > > > > > > bindflag > > > > is not initialized and will cause creating texture failure. Now > fix > > > > > > it, > > > > assign it the value of D3D11_BIND_RENDER_TARGET. > > > > > > > > > > As with similar fixes of this nature, this implicit behavior to > fix > > > one particular bug does not seem fitting inside the hwcontext > itself. > > > There can be a large list of usages of the hwcontext that all > require > > > different BindFlags, but we can only define one default - why this > one > > > specifically? > > > > I agree that this change is not ideal. On one side, it is "safe" in > a way > > that a texture is practically unusable for video processing without > having > > at least one of the flags (decoder, encoder or render_target), > > so this wouldn't "hurt" anybody. > > > > > So rather: > > > > > > Where is the context created? > > > > Looking at the command line in the commit message, this is about > > standalone D3D11 context creation. > > > > > Why is a required flag not set there? That would be better, > because > > > that knows what flags it needs. > > > > There doesn't really exist an appropriate "there". I see two options > > > > 1. Add a generic internal device creation parameter to the > dictionary > >in ffmpeg_hw.c like "standalone=1" > >(for all devices created via init_hw_device) > > > > Some time ago, I had another case where I thought this could be > useful. > > Then, this could be used in d3d11va_device_create() to set an > internal > > field 'default_bindflags' which would be used as condition in > > d3d11va_frames_init. The situation would remain similar though, as > that > > when the device is used by a decoder (which sets the decoder flag) > > this needs to override the default. > > > > 2. Use a device parameter specific to the D3D11 > > hwcontextD3D11_BIND_RENDER_TARGET > > > > This would need to be specified in the command line. > > Everything else like in #1 > > > > What do you think? > > There aren't extra parameters for other standalone hwcontext creation. > May we > take BindFlags=0 as the default setting and set texDesc.BindFlags to > D3D11_BIND_RENDER_TARGET directly ? The ffmpeg cli is not the only way how ffmpeg libs are being used. That's why we shouldn't make assumptions which might apply when used in the context of ffmpeg cli. I think that's what Hendrik wanted to point out as far as I understood. 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 v7 05/10] qsv: build audio related code when MFX_VERSION < 2.0
> -Original Message- > From: ffmpeg-devel On Behalf Of > Xiang, Haihao > Sent: Sunday, May 1, 2022 6:52 AM > To: an...@khirnov.net; ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH v7 05/10] qsv: build audio related > code when MFX_VERSION < 2.0 > > On Sun, 2022-05-01 at 03:10 +, Soft Works wrote: > > > -Original Message- > > > From: ffmpeg-devel On Behalf Of > > > Xiang, Haihao > > > Sent: Sunday, May 1, 2022 4:16 AM > > > To: an...@khirnov.net; ffmpeg-devel@ffmpeg.org > > > Subject: Re: [FFmpeg-devel] [PATCH v7 05/10] qsv: build audio > related > > > code when MFX_VERSION < 2.0 > > > > > > On Sat, 2022-04-30 at 16:51 +, Soft Works wrote: > > > > > -Original Message- > > > > > From: ffmpeg-devel On Behalf > Of > > > > > Xiang, Haihao > > > > > Sent: Wednesday, April 6, 2022 5:38 AM > > > > > To: an...@khirnov.net; ffmpeg-devel@ffmpeg.org > > > > > Subject: Re: [FFmpeg-devel] [PATCH v7 05/10] qsv: build audio > > > > > > related > > > > > code when MFX_VERSION < 2.0 > > > > > > > > > > On Tue, 2022-04-05 at 13:50 +0200, Anton Khirnov wrote: > > > > > > Quoting Xiang, Haihao (2022-03-11 09:16:25) > > > > > > > From: Haihao Xiang > > > > > > > > > > > > > > Audio isn't supported for MFX_VERSION >= 2.0[1][2]. This > is in > > > > > > > preparation for oneVPL support > > > > > > > > > > > > > > [1]: > > > > > > > > > > > > > > > > > > > > > > > > https://spec.oneapi.io/versions/latest/elements/oneVPL/source/VPL_inte > > > > > l_media_sdk.html#msdk-full-name-feature-removals > > > > > > > [2]: https://github.com/oneapi-src/oneVPL > > > > > > > --- > > > > > > > libavcodec/qsv.c | 5 + > > > > > > > libavfilter/qsvvpp.c | 6 ++ > > > > > > > libavfilter/qsvvpp.h | 2 ++ > > > > > > > 3 files changed, 13 insertions(+) > > > > > > > > > > > > Why not just remove this completely? > > > > > > None of our QSV code does anything with audio. > > > > > > > > > > It was removed in an older version, however someone objected > the > > > > > removal of > > > > > this. See > > > > > > > > > > > > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200819061023.44330 > > > > > 4-2-haihao.xi...@intel.com/ > > > > > > > > I think this was a misunderstanding. I see not objection. One > was > > > > just asking "why" and the other one had missed the point that > audio > > > > has never been functional. > > > > > > Please find the comment below in the original thread > > > > > > "This seems like a generic translation from the library errors to > FF > > > error > > > codes. So even if we'll never touch the audio functionality of it, > I'd > > > prefer > > > to have that struct complete already" > > > > > > So my understanding was that the reviewer preferred to keep the > audio > > > stuff > > > unchanged for libmfx. > > > > Hm, I hadn't see that here: > > > > > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200819061023.44330 > 4-2-haihao.xi...@intel.com/ > > > > Considering the text again: > > > > > "This seems like a generic translation from the library errors to > FF > > > error > > > codes. So even if we'll never touch the audio functionality of it, > I'd > > > prefer > > > to have that struct complete already" > > > > I understand the idea. Normally those lines wouldn't hurt. But now, > that > > we're facing some kind of "#ifdef hell" anyway, I think it would be > much > > better to minimize this as much as possible, and there's really no > point > > in translating audio error codes. > > Also, the struct has never been really complete. Instead of > retaining > > unused audio error codes, we should better add those that are > missing > > (like -21, -22 and others) and relevant. > > > > @Thilo - can we get you warm with that? > > > > As an alternative, we could simply replace the two audio definitions > with > > plain integer values (MFX_ERR_INVALID_AUDIO_PARAM >> -19) > > > > > > This is a small bit only, but before adding the oneVPL stuff, I > think > > we should consolidate the conditional stuff as much as possible. > > > > As discussed before, we also need to settle for a minimum libmfx SDK > > version (compile-time, not runtime!). This will allow to drop quite > > an amount of conditional code, and this cleanup should be done > before > > getting to oneVPL. > > Sure, I'll submit a patch for it. > > > > > Another thing that is a bit unfortunate is that we are duplicating > this > > error mapping struct in qsv.c and qsvvpp.c. > > I don't mean that it should be linked as an external between > avfilter > > and avcodec, but it should come (be included) from a single file. > > We moved the static error table to a .h in the past however it > resulted in link > error when building FFmpeg with static libraries. That's why I said that it doesn't need to be exported - just a single file that can be included/inlined in both cases where it is used (lavcodec, lavfilter). Best, softworkz ___ ffmpeg-devel mailing list
