[FFmpeg-devel] [PATCH] lavu/hwcontext_vaapi: Use vaMapBuffer2 for mapping image buffers
This allows some optimizations in driver, such as not having to read
back the data if write-only mapping is requested.
---
libavutil/hwcontext_vaapi.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 558fed94c6..c3ecd90077 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -882,7 +882,16 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
}
}
+#if VA_CHECK_VERSION(1, 21, 0)
+uint32_t vaflags = 0;
+if (flags & AV_HWFRAME_MAP_READ || !(flags & AV_HWFRAME_MAP_OVERWRITE))
+vaflags |= VA_MAPBUFFER_FLAG_READ;
+if (flags & AV_HWFRAME_MAP_WRITE)
+vaflags |= VA_MAPBUFFER_FLAG_WRITE;
+vas = vaMapBuffer2(hwctx->display, map->image.buf, &address, vaflags);
+#else
vas = vaMapBuffer(hwctx->display, map->image.buf, &address);
+#endif
if (vas != VA_STATUS_SUCCESS) {
av_log(hwfc, AV_LOG_ERROR, "Failed to map image from surface "
"%#x: %d (%s).\n", surface_id, vas, vaErrorStr(vas));
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] lavu/hwcontext_vaapi: Use vaMapBuffer2 for mapping image buffers
This allows some optimizations in driver, such as not having to read
back the data if write-only mapping is requested.
---
v2: Fix warning
libavutil/hwcontext_vaapi.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 558fed94c6..0d16699f66 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -799,6 +799,7 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
VAStatus vas;
void *address = NULL;
int err, i;
+uint32_t vaflags = 0;
surface_id = (VASurfaceID)(uintptr_t)src->data[3];
av_log(hwfc, AV_LOG_DEBUG, "Map surface %#x.\n", surface_id);
@@ -882,7 +883,15 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
}
}
+#if VA_CHECK_VERSION(1, 21, 0)
+if (flags & AV_HWFRAME_MAP_READ || !(flags & AV_HWFRAME_MAP_OVERWRITE))
+vaflags |= VA_MAPBUFFER_FLAG_READ;
+if (flags & AV_HWFRAME_MAP_WRITE)
+vaflags |= VA_MAPBUFFER_FLAG_WRITE;
+vas = vaMapBuffer2(hwctx->display, map->image.buf, &address, vaflags);
+#else
vas = vaMapBuffer(hwctx->display, map->image.buf, &address);
+#endif
if (vas != VA_STATUS_SUCCESS) {
av_log(hwfc, AV_LOG_ERROR, "Failed to map image from surface "
"%#x: %d (%s).\n", surface_id, vas, vaErrorStr(vas));
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3] lavu/hwcontext_vaapi: Use vaMapBuffer2 for mapping image buffers
This allows some optimizations in driver, such as not having to read
back the data if write-only mapping is requested.
---
v3: Fix another warning
libavutil/hwcontext_vaapi.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 558fed94c6..86b0852c12 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -799,6 +799,9 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
VAStatus vas;
void *address = NULL;
int err, i;
+#if VA_CHECK_VERSION(1, 21, 0)
+uint32_t vaflags = 0;
+#endif
surface_id = (VASurfaceID)(uintptr_t)src->data[3];
av_log(hwfc, AV_LOG_DEBUG, "Map surface %#x.\n", surface_id);
@@ -882,7 +885,15 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
}
}
+#if VA_CHECK_VERSION(1, 21, 0)
+if (flags & AV_HWFRAME_MAP_READ || !(flags & AV_HWFRAME_MAP_OVERWRITE))
+vaflags |= VA_MAPBUFFER_FLAG_READ;
+if (flags & AV_HWFRAME_MAP_WRITE)
+vaflags |= VA_MAPBUFFER_FLAG_WRITE;
+vas = vaMapBuffer2(hwctx->display, map->image.buf, &address, vaflags);
+#else
vas = vaMapBuffer(hwctx->display, map->image.buf, &address);
+#endif
if (vas != VA_STATUS_SUCCESS) {
av_log(hwfc, AV_LOG_ERROR, "Failed to map image from surface "
"%#x: %d (%s).\n", surface_id, vas, vaErrorStr(vas));
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] lavu/hwcontext_vaapi: Use vaMapBuffer2 for mapping image buffers
On Fri, Oct 27, 2023 at 7:14 PM Mark Thompson wrote:
>
> On 27/10/2023 11:00, David Rosca wrote:
> > This allows some optimizations in driver, such as not having to read
> > back the data if write-only mapping is requested.
> > ---
> > v3: Fix another warning
> >
> > libavutil/hwcontext_vaapi.c | 11 +++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> > index 558fed94c6..86b0852c12 100644
> > --- a/libavutil/hwcontext_vaapi.c
> > +++ b/libavutil/hwcontext_vaapi.c
> > @@ -799,6 +799,9 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
> > VAStatus vas;
> > void *address = NULL;
> > int err, i;
> > +#if VA_CHECK_VERSION(1, 21, 0)
> > +uint32_t vaflags = 0;
> > +#endif
> >
> > surface_id = (VASurfaceID)(uintptr_t)src->data[3];
> > av_log(hwfc, AV_LOG_DEBUG, "Map surface %#x.\n", surface_id);
> > @@ -882,7 +885,15 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
> > }
> > }
> >
> > +#if VA_CHECK_VERSION(1, 21, 0)
> > +if (flags & AV_HWFRAME_MAP_READ || !(flags & AV_HWFRAME_MAP_OVERWRITE))
> > +vaflags |= VA_MAPBUFFER_FLAG_READ;
>
> I don't understand where the !overwrite has come from in this condition?
This logic is a couple lines ahead in the vaCreateImage path. If
AV_HWFRAME_MAP_OVERWRITE isn't set, it will call vaGetImage to read
the image data. And as vaDeriveImage + vaMapBuffer is read+write
mapping, I think the same logic needs to be applied to vaMapBuffer2
too.
>
> If the user requested write-only but not overwrite then they're expecting to
> write some pixels within the image (such as adding an overlay), but don't
> want to read anything.
Exactly for this case the read is needed. If the user writes only some
(not all) pixels of the image, then the rest of the image will be
invalid if a driver implements the mapping using staging texture
(which is what Mesa does).
>
> > +if (flags & AV_HWFRAME_MAP_WRITE)
> > +vaflags |= VA_MAPBUFFER_FLAG_WRITE;
> > +vas = vaMapBuffer2(hwctx->display, map->image.buf, &address, vaflags);
> > +#else
> > vas = vaMapBuffer(hwctx->display, map->image.buf, &address);
> > +#endif
> > if (vas != VA_STATUS_SUCCESS) {
> > av_log(hwfc, AV_LOG_ERROR, "Failed to map image from surface "
> > "%#x: %d (%s).\n", surface_id, vas, vaErrorStr(vas));
>
> Please add a note that there is a compatibility layer in libva so that
> MapBuffer2 calls MapBuffer if the driver doesn't expose it directly, so this
> does work with older drivers. (The patch looked wrong before I realised
> that.)
>
> Thanks,
>
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v4] lavu/hwcontext_vaapi: Use vaMapBuffer2 for mapping image buffers
This allows some optimizations in driver, such as not having to read
back the data if write-only mapping is requested.
---
v4: overwrite + note about vaMapBuffer libva fallback
libavutil/hwcontext_vaapi.c | 12
1 file changed, 12 insertions(+)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 558fed94c6..435f10a7f3 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -799,6 +799,9 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
VAStatus vas;
void *address = NULL;
int err, i;
+#if VA_CHECK_VERSION(1, 21, 0)
+uint32_t vaflags = 0;
+#endif
surface_id = (VASurfaceID)(uintptr_t)src->data[3];
av_log(hwfc, AV_LOG_DEBUG, "Map surface %#x.\n", surface_id);
@@ -882,7 +885,16 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
}
}
+#if VA_CHECK_VERSION(1, 21, 0)
+if (flags & AV_HWFRAME_MAP_READ)
+vaflags |= VA_MAPBUFFER_FLAG_READ;
+if (flags & AV_HWFRAME_MAP_WRITE)
+vaflags |= VA_MAPBUFFER_FLAG_WRITE;
+// On drivers not implementing vaMapBuffer2 libva calls vaMapBuffer
instead.
+vas = vaMapBuffer2(hwctx->display, map->image.buf, &address, vaflags);
+#else
vas = vaMapBuffer(hwctx->display, map->image.buf, &address);
+#endif
if (vas != VA_STATUS_SUCCESS) {
av_log(hwfc, AV_LOG_ERROR, "Failed to map image from surface "
"%#x: %d (%s).\n", surface_id, vas, vaErrorStr(vas));
--
2.42.0
___
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] lavc/vaapi_encode_av1: Set roi_quant_range
--- libavcodec/vaapi_encode_av1.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavcodec/vaapi_encode_av1.c b/libavcodec/vaapi_encode_av1.c index a46b882ab9..02a31b894d 100644 --- a/libavcodec/vaapi_encode_av1.c +++ b/libavcodec/vaapi_encode_av1.c @@ -155,6 +155,8 @@ static av_cold int vaapi_encode_av1_configure(AVCodecContext *avctx) priv->q_idx_idr = priv->q_idx_p = priv->q_idx_b = 128; } +ctx->roi_quant_range = AV1_MAX_QUANT; + return 0; } -- 2.44.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4] lavu/hwcontext_vaapi: Use vaMapBuffer2 for mapping image buffers
On Fri, Nov 24, 2023 at 8:27 AM Xiang, Haihao wrote:
>
> On Vr, 2023-10-27 at 22:25 +0200, David Rosca wrote:
> > This allows some optimizations in driver, such as not having to read
> > back the data if write-only mapping is requested.
> > ---
> > v4: overwrite + note about vaMapBuffer libva fallback
> >
> > libavutil/hwcontext_vaapi.c | 12
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> > index 558fed94c6..435f10a7f3 100644
> > --- a/libavutil/hwcontext_vaapi.c
> > +++ b/libavutil/hwcontext_vaapi.c
> > @@ -799,6 +799,9 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
> > VAStatus vas;
> > void *address = NULL;
> > int err, i;
> > +#if VA_CHECK_VERSION(1, 21, 0)
> > +uint32_t vaflags = 0;
> > +#endif
> >
> > surface_id = (VASurfaceID)(uintptr_t)src->data[3];
> > av_log(hwfc, AV_LOG_DEBUG, "Map surface %#x.\n", surface_id);
> > @@ -882,7 +885,16 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
> > }
> > }
> >
> > +#if VA_CHECK_VERSION(1, 21, 0)
> > +if (flags & AV_HWFRAME_MAP_READ)
> > +vaflags |= VA_MAPBUFFER_FLAG_READ;
> > +if (flags & AV_HWFRAME_MAP_WRITE)
> > +vaflags |= VA_MAPBUFFER_FLAG_WRITE;
> > +// On drivers not implementing vaMapBuffer2 libva calls vaMapBuffer
> > instead.
> > +vas = vaMapBuffer2(hwctx->display, map->image.buf, &address, vaflags);
> > +#else
> > vas = vaMapBuffer(hwctx->display, map->image.buf, &address);
> > +#endif
> > if (vas != VA_STATUS_SUCCESS) {
> > av_log(hwfc, AV_LOG_ERROR, "Failed to map image from surface "
> > "%#x: %d (%s).\n", surface_id, vas, vaErrorStr(vas));
>
> LGTM, and will apply it when the official libva 2.21 is released.
Ping, libva 2.21 has now been released.
Thanks,
David
>
> 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".
[FFmpeg-devel] [PATCH 1/2] lavc/vaapi_decode: Make it possible to send multiple slice params buffers
---
libavcodec/vaapi_av1.c| 2 +-
libavcodec/vaapi_decode.c | 3 ++-
libavcodec/vaapi_decode.h | 1 +
libavcodec/vaapi_h264.c | 2 +-
libavcodec/vaapi_hevc.c | 4 ++--
libavcodec/vaapi_mjpeg.c | 2 +-
libavcodec/vaapi_mpeg2.c | 2 +-
libavcodec/vaapi_mpeg4.c | 2 +-
libavcodec/vaapi_vc1.c| 2 +-
libavcodec/vaapi_vp8.c| 2 +-
libavcodec/vaapi_vp9.c| 2 +-
11 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/libavcodec/vaapi_av1.c b/libavcodec/vaapi_av1.c
index 1f563483b9..4a90db1e09 100644
--- a/libavcodec/vaapi_av1.c
+++ b/libavcodec/vaapi_av1.c
@@ -409,7 +409,7 @@ static int vaapi_av1_decode_slice(AVCodecContext *avctx,
.tg_end= s->tg_end,
};
-err = ff_vaapi_decode_make_slice_buffer(avctx, pic, &slice_param,
+err = ff_vaapi_decode_make_slice_buffer(avctx, pic, &slice_param, 1,
sizeof(VASliceParameterBufferAV1),
buffer,
size);
diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
index 21b273cd0f..8e9f647c20 100644
--- a/libavcodec/vaapi_decode.c
+++ b/libavcodec/vaapi_decode.c
@@ -63,6 +63,7 @@ int ff_vaapi_decode_make_param_buffer(AVCodecContext *avctx,
int ff_vaapi_decode_make_slice_buffer(AVCodecContext *avctx,
VAAPIDecodePicture *pic,
const void *params_data,
+ int nb_params,
size_t params_size,
const void *slice_data,
size_t slice_size)
@@ -88,7 +89,7 @@ int ff_vaapi_decode_make_slice_buffer(AVCodecContext *avctx,
vas = vaCreateBuffer(ctx->hwctx->display, ctx->va_context,
VASliceParameterBufferType,
- params_size, 1, (void*)params_data,
+ params_size, nb_params, (void*)params_data,
&pic->slice_buffers[index]);
if (vas != VA_STATUS_SUCCESS) {
av_log(avctx, AV_LOG_ERROR, "Failed to create slice "
diff --git a/libavcodec/vaapi_decode.h b/libavcodec/vaapi_decode.h
index 6beda14e52..702171e108 100644
--- a/libavcodec/vaapi_decode.h
+++ b/libavcodec/vaapi_decode.h
@@ -73,6 +73,7 @@ int ff_vaapi_decode_make_param_buffer(AVCodecContext *avctx,
int ff_vaapi_decode_make_slice_buffer(AVCodecContext *avctx,
VAAPIDecodePicture *pic,
const void *params_data,
+ int nb_params,
size_t params_size,
const void *slice_data,
size_t slice_size);
diff --git a/libavcodec/vaapi_h264.c b/libavcodec/vaapi_h264.c
index 55cf5a05ee..b47531ce1c 100644
--- a/libavcodec/vaapi_h264.c
+++ b/libavcodec/vaapi_h264.c
@@ -375,7 +375,7 @@ static int vaapi_h264_decode_slice(AVCodecContext *avctx,
slice_param.chroma_offset_l1);
err = ff_vaapi_decode_make_slice_buffer(avctx, pic,
-&slice_param, sizeof(slice_param),
+&slice_param, 1,
sizeof(slice_param),
buffer, size);
if (err) {
ff_vaapi_decode_cancel(avctx, pic);
diff --git a/libavcodec/vaapi_hevc.c b/libavcodec/vaapi_hevc.c
index 3bdd2dd1b8..3937b7574a 100644
--- a/libavcodec/vaapi_hevc.c
+++ b/libavcodec/vaapi_hevc.c
@@ -353,7 +353,7 @@ static int vaapi_hevc_end_frame(AVCodecContext *avctx)
if (pic->last_size) {
last_slice_param->LongSliceFlags.fields.LastSliceOfPic = 1;
ret = ff_vaapi_decode_make_slice_buffer(avctx, &pic->pic,
-&pic->last_slice_param,
slice_param_size,
+&pic->last_slice_param, 1,
slice_param_size,
pic->last_buffer,
pic->last_size);
if (ret < 0)
goto fail;
@@ -471,7 +471,7 @@ static int vaapi_hevc_decode_slice(AVCodecContext *avctx,
if (!sh->first_slice_in_pic_flag) {
err = ff_vaapi_decode_make_slice_buffer(avctx, &pic->pic,
-&pic->last_slice_param,
slice_param_size,
+&pic->last_slice_param, 1,
slice_param_size,
pic->last_buffer,
pic->last_size);
pic->last_buffer = NULL;
pic->last_size = 0;
diff --git a/libavcodec/vaapi_mjpeg.c b/libavcodec/vaapi_mjpeg.c
index 5b8d47bb2a..9557cf5f9b 100644
--- a/libavcodec/vaapi_mjpeg.c
+++ b/libavcodec/vaapi_mjpeg.c
@@ -131,7 +131,7 @@ static int vaapi_mjpe
[FFmpeg-devel] [PATCH 2/2] lavc/vaapi_av1: Avoid sending the same slice buffer multiple times
When there are multiple tiles in one slice buffer, use multiple slice
params to avoid sending the same slice buffer multiple times and thus
increasing the bitstream size the driver will need to upload to hw.
---
libavcodec/vaapi_av1.c | 37 +++--
1 file changed, 23 insertions(+), 14 deletions(-)
diff --git a/libavcodec/vaapi_av1.c b/libavcodec/vaapi_av1.c
index 4a90db1e09..567f505fbd 100644
--- a/libavcodec/vaapi_av1.c
+++ b/libavcodec/vaapi_av1.c
@@ -19,6 +19,7 @@
*/
#include "libavutil/frame.h"
+#include "libavutil/mem.h"
#include "hwaccel_internal.h"
#include "vaapi_decode.h"
#include "internal.h"
@@ -393,13 +394,17 @@ static int vaapi_av1_decode_slice(AVCodecContext *avctx,
{
const AV1DecContext *s = avctx->priv_data;
VAAPIDecodePicture *pic = s->cur_frame.hwaccel_picture_private;
-VASliceParameterBufferAV1 slice_param;
-int err = 0;
+VASliceParameterBufferAV1 *slice_params;
+int err = 0, nb_params = 0;
-for (int i = s->tg_start; i <= s->tg_end; i++) {
-memset(&slice_param, 0, sizeof(VASliceParameterBufferAV1));
+slice_params = av_calloc(s->tg_end - s->tg_start + 1,
sizeof(*slice_params));
+if (!slice_params) {
+err = AVERROR(ENOMEM);
+goto fail;
+}
-slice_param = (VASliceParameterBufferAV1) {
+for (int i = s->tg_start; i <= s->tg_end; i++) {
+slice_params[nb_params++] = (VASliceParameterBufferAV1) {
.slice_data_size = s->tile_group_info[i].tile_size,
.slice_data_offset = s->tile_group_info[i].tile_offset,
.slice_data_flag = VA_SLICE_DATA_FLAG_ALL,
@@ -408,18 +413,22 @@ static int vaapi_av1_decode_slice(AVCodecContext *avctx,
.tg_start = s->tg_start,
.tg_end= s->tg_end,
};
-
-err = ff_vaapi_decode_make_slice_buffer(avctx, pic, &slice_param, 1,
-
sizeof(VASliceParameterBufferAV1),
-buffer,
-size);
-if (err) {
-ff_vaapi_decode_cancel(avctx, pic);
-return err;
-}
}
+err = ff_vaapi_decode_make_slice_buffer(avctx, pic, slice_params,
nb_params,
+sizeof(VASliceParameterBufferAV1),
+buffer,
+size);
+av_free(slice_params);
+
+if (err)
+goto fail;
+
return 0;
+
+fail:
+ff_vaapi_decode_cancel(avctx, pic);
+return err;
}
const FFHWAccel ff_av1_vaapi_hwaccel = {
--
2.44.0
___
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] lavc/vaapi_h264: Don't try to merge fields in DPB for non-field pics
This path can be hit when there are missing references while decoding
progressive stream and would completely break the DPB contents.
---
libavcodec/vaapi_h264.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/libavcodec/vaapi_h264.c b/libavcodec/vaapi_h264.c
index b47531ce1c..ca0076f57a 100644
--- a/libavcodec/vaapi_h264.c
+++ b/libavcodec/vaapi_h264.c
@@ -98,22 +98,24 @@ static int dpb_add(DPB *dpb, const H264Picture *pic)
if (dpb->size >= dpb->max_size)
return -1;
-for (i = 0; i < dpb->size; i++) {
-VAPictureH264 * const va_pic = &dpb->va_pics[i];
-if (va_pic->picture_id == ff_vaapi_get_surface_id(pic->f)) {
-VAPictureH264 temp_va_pic;
-fill_vaapi_pic(&temp_va_pic, pic, 0);
-
-if ((temp_va_pic.flags ^ va_pic->flags) &
(VA_PICTURE_H264_TOP_FIELD | VA_PICTURE_H264_BOTTOM_FIELD)) {
-va_pic->flags |= temp_va_pic.flags &
(VA_PICTURE_H264_TOP_FIELD | VA_PICTURE_H264_BOTTOM_FIELD);
-/* Merge second field */
-if (temp_va_pic.flags & VA_PICTURE_H264_TOP_FIELD) {
-va_pic->TopFieldOrderCnt= temp_va_pic.TopFieldOrderCnt;
-} else {
-va_pic->BottomFieldOrderCnt =
temp_va_pic.BottomFieldOrderCnt;
+if (pic->field_picture) {
+for (i = 0; i < dpb->size; i++) {
+VAPictureH264 * const va_pic = &dpb->va_pics[i];
+if (va_pic->picture_id == ff_vaapi_get_surface_id(pic->f)) {
+VAPictureH264 temp_va_pic;
+fill_vaapi_pic(&temp_va_pic, pic, 0);
+
+if ((temp_va_pic.flags ^ va_pic->flags) &
(VA_PICTURE_H264_TOP_FIELD | VA_PICTURE_H264_BOTTOM_FIELD)) {
+va_pic->flags |= temp_va_pic.flags &
(VA_PICTURE_H264_TOP_FIELD | VA_PICTURE_H264_BOTTOM_FIELD);
+/* Merge second field */
+if (temp_va_pic.flags & VA_PICTURE_H264_TOP_FIELD) {
+va_pic->TopFieldOrderCnt=
temp_va_pic.TopFieldOrderCnt;
+} else {
+va_pic->BottomFieldOrderCnt =
temp_va_pic.BottomFieldOrderCnt;
+}
}
+return 0;
}
-return 0;
}
}
--
2.45.0
___
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] lavc/vaapi_h264: Fix merging fields in DPB with missing references
If there are missing references, h264 decode does error concealment
by copying previous refs which means there will be duplicated surfaces
and this code would try to merge them instead of correctly appending
to DPB. Make sure the fields were actually merged before early return.
---
libavcodec/vaapi_h264.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/vaapi_h264.c b/libavcodec/vaapi_h264.c
index b47531ce1c..c62a320e97 100644
--- a/libavcodec/vaapi_h264.c
+++ b/libavcodec/vaapi_h264.c
@@ -112,8 +112,9 @@ static int dpb_add(DPB *dpb, const H264Picture *pic)
} else {
va_pic->BottomFieldOrderCnt =
temp_va_pic.BottomFieldOrderCnt;
}
+return 0;
}
-return 0;
+break;
}
}
--
2.45.0
___
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/vaapi_h264: Don't try to merge fields in DPB for non-field pics
On Mon, May 6, 2024 at 9:55 PM Mark Thompson wrote:
>
> On 05/05/2024 17:36, David Rosca wrote:
> > This path can be hit when there are missing references while decoding
> > progressive stream and would completely break the DPB contents.
> > ---
> > libavcodec/vaapi_h264.c | 30 --
> > 1 file changed, 16 insertions(+), 14 deletions(-)
>
> Can you share a stream which does this in a progressive case?
https://github.com/nowrep/chiaki4deck/raw/samples/samples/missingframes.h264
>
> My understanding of this (though I suspect I am missing something) is that we
> are filling from the short/long DPB lists which should not contain duplicates
> (not RefPicListX, which can), so I'm not seeing how this case could be
> triggered.
>
> If you do have two DPB entries which are different frames but refer to the
> same surface then that seems like a bug elsewhere.
It comes from the error concealment in h264dec which copies previous
ref for missing refs. It can actually also happen for interlaced
streams. I've sent a new patch that should fix it for both progressive
and interlaced.
https://github.com/FFmpeg/FFmpeg/blob/b1037d4ebe7b7f9548ce1ed24a2929aedbe9a27a/libavcodec/h264_slice.c#L1520-L1559
Thanks,
David
>
> Thanks,
>
> - Mark
>
>
> > diff --git a/libavcodec/vaapi_h264.c b/libavcodec/vaapi_h264.c
> > index b47531ce1c..ca0076f57a 100644
> > --- a/libavcodec/vaapi_h264.c
> > +++ b/libavcodec/vaapi_h264.c
> > @@ -98,22 +98,24 @@ static int dpb_add(DPB *dpb, const H264Picture *pic)
> > if (dpb->size >= dpb->max_size)
> > return -1;
> >
> > -for (i = 0; i < dpb->size; i++) {
> > -VAPictureH264 * const va_pic = &dpb->va_pics[i];
> > -if (va_pic->picture_id == ff_vaapi_get_surface_id(pic->f)) {
> > -VAPictureH264 temp_va_pic;
> > -fill_vaapi_pic(&temp_va_pic, pic, 0);
> > -
> > -if ((temp_va_pic.flags ^ va_pic->flags) &
> > (VA_PICTURE_H264_TOP_FIELD | VA_PICTURE_H264_BOTTOM_FIELD)) {
> > -va_pic->flags |= temp_va_pic.flags &
> > (VA_PICTURE_H264_TOP_FIELD | VA_PICTURE_H264_BOTTOM_FIELD);
> > -/* Merge second field */
> > -if (temp_va_pic.flags & VA_PICTURE_H264_TOP_FIELD) {
> > -va_pic->TopFieldOrderCnt=
> > temp_va_pic.TopFieldOrderCnt;
> > -} else {
> > -va_pic->BottomFieldOrderCnt =
> > temp_va_pic.BottomFieldOrderCnt;
> > +if (pic->field_picture) {
> > +for (i = 0; i < dpb->size; i++) {
> > +VAPictureH264 * const va_pic = &dpb->va_pics[i];
> > +if (va_pic->picture_id == ff_vaapi_get_surface_id(pic->f)) {
> > +VAPictureH264 temp_va_pic;
> > +fill_vaapi_pic(&temp_va_pic, pic, 0);
> > +
> > +if ((temp_va_pic.flags ^ va_pic->flags) &
> > (VA_PICTURE_H264_TOP_FIELD | VA_PICTURE_H264_BOTTOM_FIELD)) {
> > +va_pic->flags |= temp_va_pic.flags &
> > (VA_PICTURE_H264_TOP_FIELD | VA_PICTURE_H264_BOTTOM_FIELD);
> > +/* Merge second field */
> > +if (temp_va_pic.flags & VA_PICTURE_H264_TOP_FIELD) {
> > +va_pic->TopFieldOrderCnt=
> > temp_va_pic.TopFieldOrderCnt;
> > +} else {
> > +va_pic->BottomFieldOrderCnt =
> > temp_va_pic.BottomFieldOrderCnt;
> > +}
> > }
> > +return 0;
> > }
> > -return 0;
> > }
> > }
> >
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 1/2] lavc/vaapi_decode: Make it possible to send multiple slice params buffers
---
v2: No changes
libavcodec/vaapi_av1.c| 2 +-
libavcodec/vaapi_decode.c | 3 ++-
libavcodec/vaapi_decode.h | 1 +
libavcodec/vaapi_h264.c | 2 +-
libavcodec/vaapi_hevc.c | 4 ++--
libavcodec/vaapi_mjpeg.c | 2 +-
libavcodec/vaapi_mpeg2.c | 2 +-
libavcodec/vaapi_mpeg4.c | 2 +-
libavcodec/vaapi_vc1.c| 2 +-
libavcodec/vaapi_vp8.c| 2 +-
libavcodec/vaapi_vp9.c| 2 +-
11 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/libavcodec/vaapi_av1.c b/libavcodec/vaapi_av1.c
index 1f563483b9..4a90db1e09 100644
--- a/libavcodec/vaapi_av1.c
+++ b/libavcodec/vaapi_av1.c
@@ -409,7 +409,7 @@ static int vaapi_av1_decode_slice(AVCodecContext *avctx,
.tg_end= s->tg_end,
};
-err = ff_vaapi_decode_make_slice_buffer(avctx, pic, &slice_param,
+err = ff_vaapi_decode_make_slice_buffer(avctx, pic, &slice_param, 1,
sizeof(VASliceParameterBufferAV1),
buffer,
size);
diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
index 21b273cd0f..8e9f647c20 100644
--- a/libavcodec/vaapi_decode.c
+++ b/libavcodec/vaapi_decode.c
@@ -63,6 +63,7 @@ int ff_vaapi_decode_make_param_buffer(AVCodecContext *avctx,
int ff_vaapi_decode_make_slice_buffer(AVCodecContext *avctx,
VAAPIDecodePicture *pic,
const void *params_data,
+ int nb_params,
size_t params_size,
const void *slice_data,
size_t slice_size)
@@ -88,7 +89,7 @@ int ff_vaapi_decode_make_slice_buffer(AVCodecContext *avctx,
vas = vaCreateBuffer(ctx->hwctx->display, ctx->va_context,
VASliceParameterBufferType,
- params_size, 1, (void*)params_data,
+ params_size, nb_params, (void*)params_data,
&pic->slice_buffers[index]);
if (vas != VA_STATUS_SUCCESS) {
av_log(avctx, AV_LOG_ERROR, "Failed to create slice "
diff --git a/libavcodec/vaapi_decode.h b/libavcodec/vaapi_decode.h
index 6beda14e52..702171e108 100644
--- a/libavcodec/vaapi_decode.h
+++ b/libavcodec/vaapi_decode.h
@@ -73,6 +73,7 @@ int ff_vaapi_decode_make_param_buffer(AVCodecContext *avctx,
int ff_vaapi_decode_make_slice_buffer(AVCodecContext *avctx,
VAAPIDecodePicture *pic,
const void *params_data,
+ int nb_params,
size_t params_size,
const void *slice_data,
size_t slice_size);
diff --git a/libavcodec/vaapi_h264.c b/libavcodec/vaapi_h264.c
index 55cf5a05ee..b47531ce1c 100644
--- a/libavcodec/vaapi_h264.c
+++ b/libavcodec/vaapi_h264.c
@@ -375,7 +375,7 @@ static int vaapi_h264_decode_slice(AVCodecContext *avctx,
slice_param.chroma_offset_l1);
err = ff_vaapi_decode_make_slice_buffer(avctx, pic,
-&slice_param, sizeof(slice_param),
+&slice_param, 1,
sizeof(slice_param),
buffer, size);
if (err) {
ff_vaapi_decode_cancel(avctx, pic);
diff --git a/libavcodec/vaapi_hevc.c b/libavcodec/vaapi_hevc.c
index 3bdd2dd1b8..3937b7574a 100644
--- a/libavcodec/vaapi_hevc.c
+++ b/libavcodec/vaapi_hevc.c
@@ -353,7 +353,7 @@ static int vaapi_hevc_end_frame(AVCodecContext *avctx)
if (pic->last_size) {
last_slice_param->LongSliceFlags.fields.LastSliceOfPic = 1;
ret = ff_vaapi_decode_make_slice_buffer(avctx, &pic->pic,
-&pic->last_slice_param,
slice_param_size,
+&pic->last_slice_param, 1,
slice_param_size,
pic->last_buffer,
pic->last_size);
if (ret < 0)
goto fail;
@@ -471,7 +471,7 @@ static int vaapi_hevc_decode_slice(AVCodecContext *avctx,
if (!sh->first_slice_in_pic_flag) {
err = ff_vaapi_decode_make_slice_buffer(avctx, &pic->pic,
-&pic->last_slice_param,
slice_param_size,
+&pic->last_slice_param, 1,
slice_param_size,
pic->last_buffer,
pic->last_size);
pic->last_buffer = NULL;
pic->last_size = 0;
diff --git a/libavcodec/vaapi_mjpeg.c b/libavcodec/vaapi_mjpeg.c
index 5b8d47bb2a..9557cf5f9b 100644
--- a/libavcodec/vaapi_mjpeg.c
+++ b/libavcodec/vaapi_mjpeg.c
@@ -131,7 +131,7 @@ stati
[FFmpeg-devel] [PATCH v2 2/2] lavc/vaapi_av1: Avoid sending the same slice buffer multiple times
When there are multiple tiles in one slice buffer, use multiple slice
params to avoid sending the same slice buffer multiple times and thus
increasing the bitstream size the driver will need to upload to hw.
---
v2: Avoid allocations every slice.
libavcodec/vaapi_av1.c | 47 +-
1 file changed, 33 insertions(+), 14 deletions(-)
diff --git a/libavcodec/vaapi_av1.c b/libavcodec/vaapi_av1.c
index 4a90db1e09..4ee33a3ae3 100644
--- a/libavcodec/vaapi_av1.c
+++ b/libavcodec/vaapi_av1.c
@@ -19,6 +19,7 @@
*/
#include "libavutil/frame.h"
+#include "libavutil/mem.h"
#include "hwaccel_internal.h"
#include "vaapi_decode.h"
#include "internal.h"
@@ -42,6 +43,9 @@ typedef struct VAAPIAV1DecContext {
*/
VAAPIAV1FrameRef ref_tab[AV1_NUM_REF_FRAMES];
AVFrame *tmp_frame;
+
+int nb_slice_params;
+VASliceParameterBufferAV1 *slice_params;
} VAAPIAV1DecContext;
static VASurfaceID vaapi_av1_surface_id(AV1Frame *vf)
@@ -97,6 +101,8 @@ static int vaapi_av1_decode_uninit(AVCodecContext *avctx)
for (int i = 0; i < FF_ARRAY_ELEMS(ctx->ref_tab); i++)
av_frame_free(&ctx->ref_tab[i].frame);
+av_freep(&ctx->slice_params);
+
return ff_vaapi_decode_uninit(avctx);
}
@@ -393,13 +399,24 @@ static int vaapi_av1_decode_slice(AVCodecContext *avctx,
{
const AV1DecContext *s = avctx->priv_data;
VAAPIDecodePicture *pic = s->cur_frame.hwaccel_picture_private;
-VASliceParameterBufferAV1 slice_param;
-int err = 0;
+VAAPIAV1DecContext *ctx = avctx->internal->hwaccel_priv_data;
+int err, nb_params;
+
+nb_params = s->tg_end - s->tg_start + 1;
+if (ctx->nb_slice_params < nb_params) {
+ctx->slice_params = av_realloc_array(ctx->slice_params,
+ nb_params,
+ sizeof(*ctx->slice_params));
+if (!ctx->slice_params) {
+ctx->nb_slice_params = 0;
+err = AVERROR(ENOMEM);
+goto fail;
+}
+ctx->nb_slice_params = nb_params;
+}
for (int i = s->tg_start; i <= s->tg_end; i++) {
-memset(&slice_param, 0, sizeof(VASliceParameterBufferAV1));
-
-slice_param = (VASliceParameterBufferAV1) {
+ctx->slice_params[i - s->tg_start] = (VASliceParameterBufferAV1) {
.slice_data_size = s->tile_group_info[i].tile_size,
.slice_data_offset = s->tile_group_info[i].tile_offset,
.slice_data_flag = VA_SLICE_DATA_FLAG_ALL,
@@ -408,18 +425,20 @@ static int vaapi_av1_decode_slice(AVCodecContext *avctx,
.tg_start = s->tg_start,
.tg_end= s->tg_end,
};
-
-err = ff_vaapi_decode_make_slice_buffer(avctx, pic, &slice_param, 1,
-
sizeof(VASliceParameterBufferAV1),
-buffer,
-size);
-if (err) {
-ff_vaapi_decode_cancel(avctx, pic);
-return err;
-}
}
+err = ff_vaapi_decode_make_slice_buffer(avctx, pic, ctx->slice_params,
nb_params,
+sizeof(VASliceParameterBufferAV1),
+buffer,
+size);
+if (err)
+goto fail;
+
return 0;
+
+fail:
+ff_vaapi_decode_cancel(avctx, pic);
+return err;
}
const FFHWAccel ff_av1_vaapi_hwaccel = {
--
2.45.0
___
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] lavc/vaapi_av1: Avoid sending the same slice buffer multiple times
On Tue, May 7, 2024 at 10:01 PM Mark Thompson wrote:
>
> On 28/04/2024 08:26, David Rosca wrote:
> > When there are multiple tiles in one slice buffer, use multiple slice
> > params to avoid sending the same slice buffer multiple times and thus
> > increasing the bitstream size the driver will need to upload to hw.
> > ---
> > libavcodec/vaapi_av1.c | 37 +++--
> > 1 file changed, 23 insertions(+), 14 deletions(-)
>
> Can you confirm that this works on at least iHD (Intel) and Mesa (AMD)? (I
> don't expect any issue, but it's good to check in case of something strange
> going on matching up to what this was previously doing.)
I've tested with Mesa and it works correctly. Gstreamer also does the same.
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/da35ed69164ba8c8599d337b00ba54074215f7e7/subprojects/gst-plugins-bad/sys/va/gstvaav1dec.c#L891-L912
>
> > diff --git a/libavcodec/vaapi_av1.c b/libavcodec/vaapi_av1.c
> > index 4a90db1e09..567f505fbd 100644
> > --- a/libavcodec/vaapi_av1.c
> > +++ b/libavcodec/vaapi_av1.c
> > @@ -19,6 +19,7 @@
> > */
> >
> > #include "libavutil/frame.h"
> > +#include "libavutil/mem.h"
> > #include "hwaccel_internal.h"
> > #include "vaapi_decode.h"
> > #include "internal.h"
> > @@ -393,13 +394,17 @@ static int vaapi_av1_decode_slice(AVCodecContext
> > *avctx,
> > {
> > const AV1DecContext *s = avctx->priv_data;
> > VAAPIDecodePicture *pic = s->cur_frame.hwaccel_picture_private;
> > -VASliceParameterBufferAV1 slice_param;
> > -int err = 0;
> > +VASliceParameterBufferAV1 *slice_params;
> > +int err = 0, nb_params = 0;
>
> Remove the spurious initialisation on err?
Done in v2.
>
> >
> > -for (int i = s->tg_start; i <= s->tg_end; i++) {
> > -memset(&slice_param, 0, sizeof(VASliceParameterBufferAV1));
> > +slice_params = av_calloc(s->tg_end - s->tg_start + 1,
> > sizeof(*slice_params));
>
> I suggest allocating this into VAAPIAV1DecContext to avoid the alloc/free on
> every call. (Only reallocate if it needs to be bigger than the previous
> maximum.)
Done in v2.
Thanks,
David
>
> > +if (!slice_params) {
> > +err = AVERROR(ENOMEM);
> > +goto fail;
> > +}
> >
> > -slice_param = (VASliceParameterBufferAV1) {
> > +for (int i = s->tg_start; i <= s->tg_end; i++) {
> > +slice_params[nb_params++] = (VASliceParameterBufferAV1) {
> > .slice_data_size = s->tile_group_info[i].tile_size,
> > .slice_data_offset = s->tile_group_info[i].tile_offset,
> > .slice_data_flag = VA_SLICE_DATA_FLAG_ALL,
> > @@ -408,18 +413,22 @@ static int vaapi_av1_decode_slice(AVCodecContext
> > *avctx,
> > .tg_start = s->tg_start,
> > .tg_end= s->tg_end,
> > };
> > -
> > -err = ff_vaapi_decode_make_slice_buffer(avctx, pic, &slice_param,
> > 1,
> > -
> > sizeof(VASliceParameterBufferAV1),
> > -buffer,
> > -size);
> > -if (err) {
> > -ff_vaapi_decode_cancel(avctx, pic);
> > -return err;
> > -}
> > }
> >
> > +err = ff_vaapi_decode_make_slice_buffer(avctx, pic, slice_params,
> > nb_params,
> > +
> > sizeof(VASliceParameterBufferAV1),
> > +buffer,
> > +size);
> > +av_free(slice_params);
> > +
> > +if (err)
> > +goto fail;
> > +
> > return 0;
> > +
> > +fail:
> > +ff_vaapi_decode_cancel(avctx, pic);
> > +return err;
> > }
> >
> > const FFHWAccel ff_av1_vaapi_hwaccel = {
>
> It's amusing that this quadratic behaviour was around for so long! (I guess
> people don't use many tiles.)
>
> Thanks,
>
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] lavc/vaapi_h264: Fix merging fields in DPB with missing references
If there are missing references, h264 decode does error concealment
by copying previous refs which means there will be duplicated surfaces.
Check long_ref and frame_idx in addition to surface when looking for
the other field to avoid trying to merge with wrong picture.
Also allow to merge with multiple pictures in case there are duplicates
of the other field.
---
v2: Check long_ref/frame_idx + multiple merge
libavcodec/vaapi_h264.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/libavcodec/vaapi_h264.c b/libavcodec/vaapi_h264.c
index b47531ce1c..398e92568c 100644
--- a/libavcodec/vaapi_h264.c
+++ b/libavcodec/vaapi_h264.c
@@ -93,14 +93,19 @@ typedef struct DPB {
*/
static int dpb_add(DPB *dpb, const H264Picture *pic)
{
-int i;
+int i, pic_frame_idx, merged = 0;
if (dpb->size >= dpb->max_size)
return -1;
+pic_frame_idx = pic->long_ref ? pic->pic_id : pic->frame_num;
+
for (i = 0; i < dpb->size; i++) {
VAPictureH264 * const va_pic = &dpb->va_pics[i];
-if (va_pic->picture_id == ff_vaapi_get_surface_id(pic->f)) {
+int va_pic_long_ref = !!(va_pic->flags &
VA_PICTURE_H264_LONG_TERM_REFERENCE);
+if (va_pic->picture_id == ff_vaapi_get_surface_id(pic->f) &&
+va_pic_long_ref == pic->long_ref &&
+va_pic->frame_idx == pic_frame_idx) {
VAPictureH264 temp_va_pic;
fill_vaapi_pic(&temp_va_pic, pic, 0);
@@ -112,11 +117,14 @@ static int dpb_add(DPB *dpb, const H264Picture *pic)
} else {
va_pic->BottomFieldOrderCnt =
temp_va_pic.BottomFieldOrderCnt;
}
+merged = 1;
}
-return 0;
}
}
+if (merged)
+return 0;
+
fill_vaapi_pic(&dpb->va_pics[dpb->size++], pic, 0);
return 0;
}
--
2.45.0
___
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/vaapi_h264: Fix merging fields in DPB with missing references
On Tue, May 7, 2024 at 10:22 PM Mark Thompson wrote:
>
> On 07/05/2024 07:00, David Rosca wrote:
> > If there are missing references, h264 decode does error concealment
> > by copying previous refs which means there will be duplicated surfaces
> > and this code would try to merge them instead of correctly appending
> > to DPB. Make sure the fields were actually merged before early return.
> > ---
> > libavcodec/vaapi_h264.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/vaapi_h264.c b/libavcodec/vaapi_h264.c
> > index b47531ce1c..c62a320e97 100644
> > --- a/libavcodec/vaapi_h264.c
> > +++ b/libavcodec/vaapi_h264.c
> > @@ -112,8 +112,9 @@ static int dpb_add(DPB *dpb, const H264Picture *pic)
> > } else {
> > va_pic->BottomFieldOrderCnt =
> > temp_va_pic.BottomFieldOrderCnt;
> > }
> > +return 0;
> > }
> > -return 0;
> > +break;
> > }
> > }
> >
>
> I agree that the old code did nasty things, but can you explain a bit more
> about the reasoning for what you've got now?
>
> I'm thinking that given duplication a top field could appear twice, so you'd
> want to merge twice if you have the matching bottom field.
Right, that may be possible.
Also I've looked at vdpau code and there it checks frame_num (in
addition to surface) when searching for the other field, which seems
better to avoid trying to merge when it should not. Posted v2 with
this change + multiple merge.
Thanks,
David
>
> Thanks,
>
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] lavc/vaapi_decode: Reject decoding of frames with no slices
Matches other hwaccels.
---
libavcodec/vaapi_decode.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
index 8e9f647c20..3c4030c073 100644
--- a/libavcodec/vaapi_decode.c
+++ b/libavcodec/vaapi_decode.c
@@ -157,6 +157,11 @@ int ff_vaapi_decode_issue(AVCodecContext *avctx,
VAStatus vas;
int err;
+if (pic->nb_slices <= 0) {
+err = -1;
+goto fail;
+}
+
av_log(avctx, AV_LOG_DEBUG, "Decode to surface %#x.\n",
pic->output_surface);
--
2.45.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] lavc/vaapi_decode: Reject decoding of frames with no slices
Matches other hwaccels.
---
v2: AVERROR
libavcodec/vaapi_decode.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
index 8e9f647c20..7c91d50f7b 100644
--- a/libavcodec/vaapi_decode.c
+++ b/libavcodec/vaapi_decode.c
@@ -157,6 +157,11 @@ int ff_vaapi_decode_issue(AVCodecContext *avctx,
VAStatus vas;
int err;
+if (pic->nb_slices <= 0) {
+err = AVERROR(EINVAL);
+goto fail;
+}
+
av_log(avctx, AV_LOG_DEBUG, "Decode to surface %#x.\n",
pic->output_surface);
--
2.45.0
___
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] lavc/vaapi_encode: Add filler_data option
---
libavcodec/vaapi_encode.c | 1 +
libavcodec/vaapi_encode.h | 9 -
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index bfca315a7a..f161c76304 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -1860,6 +1860,7 @@ rc_mode_found:
#if VA_CHECK_VERSION(1, 3, 0)
.quality_factor = rc_quality,
#endif
+.rc_flags.bits.disable_bit_stuffing = !ctx->filler_data,
};
vaapi_encode_add_global_param(avctx,
VAEncMiscParameterTypeRateControl,
diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
index a1e639f56b..a2170cb8b0 100644
--- a/libavcodec/vaapi_encode.h
+++ b/libavcodec/vaapi_encode.h
@@ -198,6 +198,9 @@ typedef struct VAAPIEncodeContext {
// Max Frame Size
int max_frame_size;
+// Filler Data
+int filler_data;
+
// Explicitly set RC mode (otherwise attempt to pick from
// available modes).
int explicit_rc_mode;
@@ -490,7 +493,11 @@ int ff_vaapi_encode_close(AVCodecContext *avctx);
{ "max_frame_size", \
"Maximum frame size (in bytes)",\
OFFSET(common.max_frame_size), AV_OPT_TYPE_INT, \
- { .i64 = 0 }, 0, INT_MAX, FLAGS }
+ { .i64 = 0 }, 0, INT_MAX, FLAGS }, \
+{ "filler_data", \
+ "Enable filler data", \
+ OFFSET(common.filler_data), AV_OPT_TYPE_BOOL, \
+ { .i64 = 1 }, 0, 1, FLAGS }
#define VAAPI_ENCODE_RC_MODE(name, desc) \
{ #name, desc, 0, AV_OPT_TYPE_CONST, { .i64 = RC_MODE_ ## name }, \
--
2.41.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] lavc/vaapi_encode: Add filler_data option
v2: Add description in encoders.texi
---
doc/encoders.texi | 3 +++
libavcodec/vaapi_encode.c | 1 +
libavcodec/vaapi_encode.h | 9 -
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 25d6b7f09e..f146942aa5 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -3963,6 +3963,9 @@ Set the allowed max size in bytes for each frame. If the
frame size exceeds
the limitation, encoder will adjust the QP value to control the frame size.
Invalid in CQP rate control mode.
+@item filler_data
+Insert filler data in CBR rate control mode to ensure target bitrate.
+
@item rc_mode
Set the rate control mode to use. A given driver may only support a subset of
modes.
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index bfca315a7a..f161c76304 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -1860,6 +1860,7 @@ rc_mode_found:
#if VA_CHECK_VERSION(1, 3, 0)
.quality_factor = rc_quality,
#endif
+.rc_flags.bits.disable_bit_stuffing = !ctx->filler_data,
};
vaapi_encode_add_global_param(avctx,
VAEncMiscParameterTypeRateControl,
diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
index a1e639f56b..a2170cb8b0 100644
--- a/libavcodec/vaapi_encode.h
+++ b/libavcodec/vaapi_encode.h
@@ -198,6 +198,9 @@ typedef struct VAAPIEncodeContext {
// Max Frame Size
int max_frame_size;
+// Filler Data
+int filler_data;
+
// Explicitly set RC mode (otherwise attempt to pick from
// available modes).
int explicit_rc_mode;
@@ -490,7 +493,11 @@ int ff_vaapi_encode_close(AVCodecContext *avctx);
{ "max_frame_size", \
"Maximum frame size (in bytes)",\
OFFSET(common.max_frame_size), AV_OPT_TYPE_INT, \
- { .i64 = 0 }, 0, INT_MAX, FLAGS }
+ { .i64 = 0 }, 0, INT_MAX, FLAGS }, \
+{ "filler_data", \
+ "Enable filler data", \
+ OFFSET(common.filler_data), AV_OPT_TYPE_BOOL, \
+ { .i64 = 1 }, 0, 1, FLAGS }
#define VAAPI_ENCODE_RC_MODE(name, desc) \
{ #name, desc, 0, AV_OPT_TYPE_CONST, { .i64 = RC_MODE_ ## name }, \
--
2.41.0
___
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] lavu/hwcontext_vaapi: Add vaapi_drm_format_map support for x2rgb10
Support for allocating frames with x2rgb10 format was added
in c00264f5013, this adds support for importing DMA-BUFs.
---
libavutil/hwcontext_vaapi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 6c3a227ddd..63544ce476 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -1048,6 +1048,9 @@ static const struct {
#if defined(VA_FOURCC_Y412) && defined(DRM_FORMAT_XVYU12_16161616)
DRM_MAP(Y412, 1, DRM_FORMAT_XVYU12_16161616),
#endif
+#ifdef defined(VA_FOURCC_X2R10G10B10) && defined(DRM_FORMAT_XRGB2101010)
+DRM_MAP(X2R10G10B10, 1, DRM_FORMAT_XRGB2101010),
+#endif
};
#undef DRM_MAP
--
2.41.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] lavu/hwcontext_vaapi: Add vaapi_drm_format_map support for x2rgb10
Support for allocating frames with x2rgb10 format was added
in c00264f5013, this adds support for importing DMA-BUFs.
v2: Fix #ifdef -> #if
---
libavutil/hwcontext_vaapi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 6c3a227ddd..558fed94c6 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -1048,6 +1048,9 @@ static const struct {
#if defined(VA_FOURCC_Y412) && defined(DRM_FORMAT_XVYU12_16161616)
DRM_MAP(Y412, 1, DRM_FORMAT_XVYU12_16161616),
#endif
+#if defined(VA_FOURCC_X2R10G10B10) && defined(DRM_FORMAT_XRGB2101010)
+DRM_MAP(X2R10G10B10, 1, DRM_FORMAT_XRGB2101010),
+#endif
};
#undef DRM_MAP
--
2.41.0
___
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] lavu/hwcontext_vaapi: Add vaapi_drm_format_map support for x2rgb10
On Wed, Aug 9, 2023 at 2:35 PM Rémi Denis-Courmont wrote:
>
>
>
> Le 9 août 2023 15:02:45 GMT+03:00, David Rosca a écrit :
> >Support for allocating frames with x2rgb10 format was added
> >in c00264f5013, this adds support for importing DMA-BUFs.
> >---
> > libavutil/hwcontext_vaapi.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> >diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> >index 6c3a227ddd..63544ce476 100644
> >--- a/libavutil/hwcontext_vaapi.c
> >+++ b/libavutil/hwcontext_vaapi.c
> >@@ -1048,6 +1048,9 @@ static const struct {
> > #if defined(VA_FOURCC_Y412) && defined(DRM_FORMAT_XVYU12_16161616)
> > DRM_MAP(Y412, 1, DRM_FORMAT_XVYU12_16161616),
> > #endif
> >+#ifdef defined(VA_FOURCC_X2R10G10B10) && defined(DRM_FORMAT_XRGB2101010)
> >+DRM_MAP(X2R10G10B10, 1, DRM_FORMAT_XRGB2101010),
> >+#endif
>
> That syntax is ostensibly wrong. Did you test the patch?
Sorry, I missed that when it was just
#ifdef VA_FOURCC_X2R10G10B10
copied from the other place.
Fixed in v2.
>
> > };
> > #undef DRM_MAP
> >
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3] lavu/hwcontext_vaapi: Add vaapi_drm_format_map support for x2rgb10
Support for allocating frames with x2rgb10 format was added
in c00264f5013, this adds support for importing DMA-BUFs.
---
v2: fix #ifdef -> #if
v3: annotate
libavutil/hwcontext_vaapi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 6c3a227ddd..558fed94c6 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -1048,6 +1048,9 @@ static const struct {
#if defined(VA_FOURCC_Y412) && defined(DRM_FORMAT_XVYU12_16161616)
DRM_MAP(Y412, 1, DRM_FORMAT_XVYU12_16161616),
#endif
+#if defined(VA_FOURCC_X2R10G10B10) && defined(DRM_FORMAT_XRGB2101010)
+DRM_MAP(X2R10G10B10, 1, DRM_FORMAT_XRGB2101010),
+#endif
};
#undef DRM_MAP
--
2.41.0
___
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] lavc/vaapi_encode: Add filler_data option
On Tue, Aug 15, 2023 at 9:25 PM Mark Thompson wrote:
>
> On 15/08/2023 20:09, Mark Thompson wrote:
> > On 15/08/2023 09:02, Xiang, Haihao wrote:
> >> On Ma, 2023-08-07 at 09:27 +0200, David Rosca wrote:
> >>> v2: Add description in encoders.texi
> >>> ---
> >>> doc/encoders.texi | 3 +++
> >>> libavcodec/vaapi_encode.c | 1 +
> >>> libavcodec/vaapi_encode.h | 9 -
> >>> 3 files changed, 12 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/doc/encoders.texi b/doc/encoders.texi
> >>> index 25d6b7f09e..f146942aa5 100644
> >>> --- a/doc/encoders.texi
> >>> +++ b/doc/encoders.texi
> >>> @@ -3963,6 +3963,9 @@ Set the allowed max size in bytes for each frame.
> >>> If the
> >>> frame size exceeds
> >>> the limitation, encoder will adjust the QP value to control the frame
> >>> size.
> >>> Invalid in CQP rate control mode.
> >>> +@item filler_data
> >>> +Insert filler data in CBR rate control mode to ensure target bitrate.
> >>> +
> >>> @item rc_mode
> >>> Set the rate control mode to use. A given driver may only support a
> >>> subset
> >>> of
> >>> modes.
> >>> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> >>> index bfca315a7a..f161c76304 100644
> >>> --- a/libavcodec/vaapi_encode.c
> >>> +++ b/libavcodec/vaapi_encode.c
> >>> @@ -1860,6 +1860,7 @@ rc_mode_found:
> >>> #if VA_CHECK_VERSION(1, 3, 0)
> >>> .quality_factor = rc_quality,
> >>> #endif
> >>> +.rc_flags.bits.disable_bit_stuffing = !ctx->filler_data,
> >>> };
> >>> vaapi_encode_add_global_param(avctx,
> >>> VAEncMiscParameterTypeRateControl,
> >>> diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
> >>> index a1e639f56b..a2170cb8b0 100644
> >>> --- a/libavcodec/vaapi_encode.h
> >>> +++ b/libavcodec/vaapi_encode.h
> >>> @@ -198,6 +198,9 @@ typedef struct VAAPIEncodeContext {
> >>> // Max Frame Size
> >>> int max_frame_size;
> >>> +// Filler Data
> >>> +int filler_data;
> >>> +
> >>> // Explicitly set RC mode (otherwise attempt to pick from
> >>> // available modes).
> >>> int explicit_rc_mode;
> >>> @@ -490,7 +493,11 @@ int ff_vaapi_encode_close(AVCodecContext *avctx);
> >>> { "max_frame_size", \
> >>> "Maximum frame size (in bytes)",\
> >>> OFFSET(common.max_frame_size), AV_OPT_TYPE_INT, \
> >>> - { .i64 = 0 }, 0, INT_MAX, FLAGS }
> >>> + { .i64 = 0 }, 0, INT_MAX, FLAGS }, \
> >>> +{ "filler_data", \
> >>> + "Enable filler data", \
> >>> + OFFSET(common.filler_data), AV_OPT_TYPE_BOOL, \
> >>> + { .i64 = 1 }, 0, 1, FLAGS }
> >>> #define VAAPI_ENCODE_RC_MODE(name, desc) \
> >>> { #name, desc, 0, AV_OPT_TYPE_CONST, { .i64 = RC_MODE_ ## name }, \
> >>
> >> Will apply
> >
> > Where does this actually work? Neither of the Intel drivers look at this
> > field - seems like it might be a good idea to note that it is driver
> > dependent and may do nothing, at least.
>
> Right, it got implemented in Mesa not that long ago. So the field got turned
> into "pad all CBR streams with filler unless you set this bit which wasn't
> used before so is obviously zero" - ouch.
>
> Do you have a use for the option, or are you just trying to fix the default?
>
> If you really do want the option, I'm not sure it makes sense as a generic -
> it only makes sense for some codecs. It would be helpful to say how the
> padding works, too (NAL filler, SEI filler, trailing zeroes?).
>
> We should probably patch all of the release branches with
> "disable_bit_stuffing = 1" so they don't pad unexpectedly with new Mesa
> versions, too.
The filler data was always enabled in Mesa, only recently it's
possible to disable it with disable_bit_stuffing = 1. So the use of
this option would be to disable this behavior.
AMD encoder uses NAL filler for H264/H265.
David
>
> Thanks,
>
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] vaapi_encode_h264: Only set pic_order_cnt_type to 0 with B-frames
--- libavcodec/vaapi_encode_h264.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c index dd17be2..d6926c4 100644 --- a/libavcodec/vaapi_encode_h264.c +++ b/libavcodec/vaapi_encode_h264.c @@ -350,7 +350,7 @@ static int vaapi_encode_h264_init_sequence_params(AVCodecContext *avctx) sps->chroma_format_idc= 1; sps->log2_max_frame_num_minus4 = 4; -sps->pic_order_cnt_type= 0; +sps->pic_order_cnt_type= ctx->max_b_depth ? 0 : 2; sps->log2_max_pic_order_cnt_lsb_minus4 = 4; sps->max_num_ref_frames = priv->dpb_frames; -- 2.39.0 ___ 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] vaapi_encode_h264: Only set pic_order_cnt_type to 0 with B-frames
On Mon, Jan 9, 2023 at 3:22 AM Xiang, Haihao wrote: > > On Do, 2022-12-29 at 22:20 +0100, David Rosca wrote: > > --- > > libavcodec/vaapi_encode_h264.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c > > index dd17be2..d6926c4 100644 > > --- a/libavcodec/vaapi_encode_h264.c > > +++ b/libavcodec/vaapi_encode_h264.c > > @@ -350,7 +350,7 @@ static int > > vaapi_encode_h264_init_sequence_params(AVCodecContext *avctx) > > sps->chroma_format_idc= 1; > > > > sps->log2_max_frame_num_minus4 = 4; > > -sps->pic_order_cnt_type= 0; > > +sps->pic_order_cnt_type= ctx->max_b_depth ? 0 : 2; > > > pic_order_cnt_type (0) should work for ctx->max_b_depth == 0. If 2 is > preferred > for your vaapi driver, it would be better to query the capability from the > driver, like as what commit 9f02e033875185409c861846f209b04a3be339d2 did. It's not about an encoder, but rather about decoder. Some decoders (namely the Snapdragon HW decoder) will buffer frames when pic_order_cnt_type == 0 (in case the frames will be reordered?) which results in undesired increased latency. Setting pic_order_cnt_type to 2 will fix this problem, and it is also what libx264 does [0]. Regards, David [0] https://code.videolan.org/videolan/x264/-/blob/master/encoder/set.c#L173 > > Thanks > Haihao > > > sps->log2_max_pic_order_cnt_lsb_minus4 = 4; > > > > sps->max_num_ref_frames = priv->dpb_frames; ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] vaapi_encode_h264: Only set pic_order_cnt_type to 0 with B-frames
v2: frame_num steps by 2
---
libavcodec/vaapi_encode_h264.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index 7a6b54ab6f..8093c47179 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_encode_h264.c
@@ -349,7 +349,7 @@ static int
vaapi_encode_h264_init_sequence_params(AVCodecContext *avctx)
sps->chroma_format_idc= 1;
sps->log2_max_frame_num_minus4 = 4;
-sps->pic_order_cnt_type= 0;
+sps->pic_order_cnt_type= ctx->max_b_depth ? 0 : 2;
sps->log2_max_pic_order_cnt_lsb_minus4 = 4;
sps->max_num_ref_frames = priv->dpb_frames;
@@ -621,7 +621,10 @@ static int
vaapi_encode_h264_init_picture_params(AVCodecContext *avctx,
} else {
av_assert0(prev);
-hpic->frame_num = hprev->frame_num + prev->is_reference;
+hpic->frame_num = hprev->frame_num;
+if (prev->is_reference) {
+hpic->frame_num += ctx->max_b_depth ? 1 : 2;
+}
hpic->last_idr_frame = hprev->last_idr_frame;
hpic->idr_pic_id = hprev->idr_pic_id;
--
2.39.0
___
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] vaapi_encode_h264: Only set pic_order_cnt_type to 0 with B-frames
On Mon, Jan 9, 2023 at 10:11 PM Mark Thompson wrote: > > On 09/01/2023 07:37, David Rosca wrote: > > On Mon, Jan 9, 2023 at 3:22 AM Xiang, Haihao wrote: > >> > >> On Do, 2022-12-29 at 22:20 +0100, David Rosca wrote: > >>> --- > >>> libavcodec/vaapi_encode_h264.c | 2 +- > >>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>> > >>> diff --git a/libavcodec/vaapi_encode_h264.c > >>> b/libavcodec/vaapi_encode_h264.c > >>> index dd17be2..d6926c4 100644 > >>> --- a/libavcodec/vaapi_encode_h264.c > >>> +++ b/libavcodec/vaapi_encode_h264.c > >>> @@ -350,7 +350,7 @@ static int > >>> vaapi_encode_h264_init_sequence_params(AVCodecContext *avctx) > >>> sps->chroma_format_idc= 1; > >>> > >>> sps->log2_max_frame_num_minus4 = 4; > >>> -sps->pic_order_cnt_type= 0; > >>> +sps->pic_order_cnt_type= ctx->max_b_depth ? 0 : 2; > >> > >> > >> pic_order_cnt_type (0) should work for ctx->max_b_depth == 0. If 2 is > >> preferred > >> for your vaapi driver, it would be better to query the capability from the > >> driver, like as what commit 9f02e033875185409c861846f209b04a3be339d2 did. > > > > It's not about an encoder, but rather about decoder. Some decoders > > (namely the Snapdragon HW decoder) > > will buffer frames when pic_order_cnt_type == 0 (in case the frames > > will be reordered?) which results > > in undesired increased latency. Setting pic_order_cnt_type to 2 will > > fix this problem, and it is also what > > libx264 does [0]. > > Has that decoder bug been reported to the vendor so that they can fix it? I haven't and I'm not sure where I would check if it was already reported by someone else. I wasn't even sure it's a bug since all encoders I have tried so far (x264, nvenc, amf) will output pic_order_cnt_type=2 when configured for low latency encoding. > > The decoder should be reading the stream buffering from > max_num_reorder_frames in the VUI parameters, which is set at as expected > <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/vaapi_encode_h264.c;h=dd17be2190ab07331ed69cf830b8cea2584ad353;hb=HEAD#l478>. > > The change to using POC type 2 is not unreasonable to save a few bits, but to > do it you will also need to fix all of the POC values to actually match the > type 2 behaviour (the current type 0 setup steps by 1 on frames because > interlacing is not supported, but type 2 always steps by 2 - see §8.2.1.3). > > - 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".
[FFmpeg-devel] [PATCH v3] vaapi_encode_h264: Only set pic_order_cnt_type to 0 with B-frames
v3: pic_order_cnt steps by 2
---
libavcodec/vaapi_encode_h264.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index f15bcc6..de0951f 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_encode_h264.c
@@ -361,8 +361,10 @@ static int
vaapi_encode_h264_init_sequence_params(AVCodecContext *avctx)
sps->chroma_format_idc= 1;
sps->log2_max_frame_num_minus4 = 4;
-sps->pic_order_cnt_type= 0;
-sps->log2_max_pic_order_cnt_lsb_minus4 = 4;
+sps->pic_order_cnt_type= ctx->max_b_depth ? 0 : 2;
+if (sps->pic_order_cnt_type == 0) {
+sps->log2_max_pic_order_cnt_lsb_minus4 = 4;
+}
sps->max_num_ref_frames = priv->dpb_frames;
@@ -643,6 +645,10 @@ static int
vaapi_encode_h264_init_picture_params(AVCodecContext *avctx,
}
}
hpic->pic_order_cnt = pic->display_order - hpic->last_idr_frame;
+if (priv->raw_sps.pic_order_cnt_type == 2) {
+hpic->pic_order_cnt *= 2;
+}
+
hpic->dpb_delay = pic->display_order - pic->encode_order +
ctx->max_b_depth;
hpic->cpb_delay = pic->encode_order - hpic->last_idr_frame;
--
2.39.0
___
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 v1 6/6] lavc/vaapi_encode: Add VAAPI AV1 encoder
On Mon, Jul 10, 2023 at 9:40 AM Fei Wang
wrote:
>
> Signed-off-by: Fei Wang
> ---
> Changelog |1 +
> configure |3 +
> doc/encoders.texi | 13 +
> libavcodec/Makefile |1 +
> libavcodec/allcodecs.c|1 +
> libavcodec/vaapi_encode.c | 125 +++-
> libavcodec/vaapi_encode.h | 12 +
> libavcodec/vaapi_encode_av1.c | 1228 +
> 8 files changed, 1366 insertions(+), 18 deletions(-)
> create mode 100644 libavcodec/vaapi_encode_av1.c
>
> diff --git a/Changelog b/Changelog
> index 3876082844..7ae9b85d52 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -25,6 +25,7 @@ version :
> - Raw VVC bitstream parser, muxer and demuxer
> - Bitstream filter for editing metadata in VVC streams
> - Bitstream filter for converting VVC from MP4 to Annex B
> +- VAAPI AV1 encoder
>
> version 6.0:
> - Radiance HDR image support
> diff --git a/configure b/configure
> index 0ab0761011..6a1a30aaec 100755
> --- a/configure
> +++ b/configure
> @@ -3323,6 +3323,8 @@ av1_qsv_decoder_select="qsvdec"
> av1_qsv_encoder_select="qsvenc"
> av1_qsv_encoder_deps="libvpl"
> av1_amf_encoder_deps="amf"
> +av1_vaapi_encoder_deps="VAEncPictureParameterBufferAV1"
> +av1_vaapi_encoder_select="cbs_av1 vaapi_encode"
>
> # parsers
> aac_parser_select="adts_header mpeg4audio"
> @@ -7106,6 +7108,7 @@ if enabled vaapi; then
> check_type "va/va.h va/va_enc_jpeg.h" "VAEncPictureParameterBufferJPEG"
> check_type "va/va.h va/va_enc_vp8.h" "VAEncPictureParameterBufferVP8"
> check_type "va/va.h va/va_enc_vp9.h" "VAEncPictureParameterBufferVP9"
> +check_type "va/va.h va/va_enc_av1.h" "VAEncPictureParameterBufferAV1"
> fi
>
> if enabled_all opencl libdrm ; then
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index 25d6b7f09e..fb331ebd8e 100644
> --- a/doc/encoders.texi
> +++ b/doc/encoders.texi
> @@ -3991,6 +3991,19 @@ Average variable bitrate.
> Each encoder also has its own specific options:
> @table @option
>
> +@item av1_vaapi
> +@option{profile} sets the value of @emph{seq_profile}.
> +@option{tier} sets the value of @emph{seq_tier}.
> +@option{level} sets the value of @emph{seq_level_idx}.
> +
> +@table @option
> +@item tiles
> +Set the number of tiles to encode the input video with, as columns x rows.
> +(default is 1x1).
> +@item tile_groups
> +Set tile groups number (default is 1).
> +@end table
> +
> @item h264_vaapi
> @option{profile} sets the value of @emph{profile_idc} and the
> @emph{constraint_set*_flag}s.
> @option{level} sets the value of @emph{level_idc}.
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 3cd5997e64..fe1e6aa99d 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -259,6 +259,7 @@ OBJS-$(CONFIG_AV1_MEDIACODEC_DECODER) += mediacodecdec.o
> OBJS-$(CONFIG_AV1_MEDIACODEC_ENCODER) += mediacodecenc.o
> OBJS-$(CONFIG_AV1_NVENC_ENCODER) += nvenc_av1.o nvenc.o
> OBJS-$(CONFIG_AV1_QSV_ENCODER) += qsvenc_av1.o
> +OBJS-$(CONFIG_AV1_VAAPI_ENCODER) += vaapi_encode_av1.o
> av1_profile_level.o
> OBJS-$(CONFIG_AVRN_DECODER)+= avrndec.o
> OBJS-$(CONFIG_AVRP_DECODER)+= r210dec.o
> OBJS-$(CONFIG_AVRP_ENCODER)+= r210enc.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index 8775d15a4f..c43c1d7b48 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -844,6 +844,7 @@ extern const FFCodec ff_av1_nvenc_encoder;
> extern const FFCodec ff_av1_qsv_decoder;
> extern const FFCodec ff_av1_qsv_encoder;
> extern const FFCodec ff_av1_amf_encoder;
> +extern const FFCodec ff_av1_vaapi_encoder;
> extern const FFCodec ff_libopenh264_encoder;
> extern const FFCodec ff_libopenh264_decoder;
> extern const FFCodec ff_h264_amf_encoder;
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index 2604f12b9e..2907e159fb 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -669,6 +669,15 @@ static int
> vaapi_encode_set_output_timestamp(AVCodecContext *avctx,
> {
> VAAPIEncodeContext *ctx = avctx->priv_data;
>
> +// AV1 packs P frame and next B frame into one pkt, and uses the other
> +// repeat frame header pkt at the display order position of the P frame
> +// to indicate its frame index. Each frame has a corresponding pkt in its
> +// display order position. So don't need to consider delay for AV1
> timestamp.
> +if (avctx->codec_id == AV_CODEC_ID_AV1) {
> +pkt->dts = pkt->pts - ctx->dts_pts_diff;
> +return 0;
> +}
> +
> if (ctx->output_delay == 0) {
> pkt->dts = pkt->pts;
> } else if (pic->encode_order < ctx->decode_delay) {
> @@ -689,9 +698,10 @@ static int vaapi_encode_output(AVCodecContext *avctx,
> {
> VAAPIEncodeContext *ctx = avctx->priv_data;
> VACodedBufferSegment *buf_list, *buf;
> -VAStatus vas;
> +AVPacket *pkt_ptr = pkt;
>
[FFmpeg-devel] [PATCH] lavc/vaapi_encode: add "quality" option to all encoders
Move "quality" option from h264_vaapi to common options.
---
libavcodec/vaapi_encode.c | 3 +++
libavcodec/vaapi_encode.h | 8 +++-
libavcodec/vaapi_encode_h264.c | 5 -
3 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index bfca315a7a..974b805df1 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -2635,6 +2635,9 @@ av_cold int ff_vaapi_encode_init(AVCodecContext *avctx)
if (err < 0)
goto fail;
+if (avctx->compression_level == FF_COMPRESSION_DEFAULT)
+avctx->compression_level = ctx->quality;
+
if (avctx->compression_level >= 0) {
err = vaapi_encode_init_quality(avctx);
if (err < 0)
diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
index a1e639f56b..3e4a8c24d3 100644
--- a/libavcodec/vaapi_encode.h
+++ b/libavcodec/vaapi_encode.h
@@ -364,6 +364,8 @@ typedef struct VAAPIEncodeContext {
AVFifo *encode_fifo;
// Max number of frame buffered in encoder.
int async_depth;
+// Encode quality (trades off against speed, higher is faster)
+int quality;
} VAAPIEncodeContext;
enum {
@@ -490,7 +492,11 @@ int ff_vaapi_encode_close(AVCodecContext *avctx);
{ "max_frame_size", \
"Maximum frame size (in bytes)",\
OFFSET(common.max_frame_size), AV_OPT_TYPE_INT, \
- { .i64 = 0 }, 0, INT_MAX, FLAGS }
+ { .i64 = 0 }, 0, INT_MAX, FLAGS }, \
+{ "quality", \
+ "Set encode quality (trades off against speed, higher is faster)", \
+ OFFSET(common.quality), AV_OPT_TYPE_INT, \
+ { .i64 = -1 }, -1, INT_MAX, FLAGS }
#define VAAPI_ENCODE_RC_MODE(name, desc) \
{ #name, desc, 0, AV_OPT_TYPE_CONST, { .i64 = RC_MODE_ ## name }, \
diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index 9ad017d540..c9629c1fea 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_encode_h264.c
@@ -71,7 +71,6 @@ typedef struct VAAPIEncodeH264Context {
// User options.
int qp;
-int quality;
int coder;
int aud;
int sei;
@@ -1211,8 +1210,6 @@ static av_cold int vaapi_encode_h264_init(AVCodecContext
*avctx)
avctx->profile = priv->profile;
if (avctx->level == FF_LEVEL_UNKNOWN)
avctx->level = priv->level;
-if (avctx->compression_level == FF_COMPRESSION_DEFAULT)
-avctx->compression_level = priv->quality;
// Reject unsupported profiles.
switch (avctx->profile) {
@@ -1282,8 +1279,6 @@ static const AVOption vaapi_encode_h264_options[] = {
{ "qp", "Constant QP (for P-frames; scaled by qfactor/qoffset for I/B)",
OFFSET(qp), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 52, FLAGS },
-{ "quality", "Set encode quality (trades off against speed, higher is
faster)",
- OFFSET(quality), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX, FLAGS },
{ "coder", "Entropy coder type",
OFFSET(coder), AV_OPT_TYPE_INT, { .i64 = 1 }, 0, 1, FLAGS, "coder" },
{ "cavlc", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 0 }, INT_MIN, INT_MAX,
FLAGS, "coder" },
--
2.40.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] hw_base_encode: Free pictures on close
Fixes leaking recon surfaces with VAAPI.
---
libavcodec/hw_base_encode.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/hw_base_encode.c b/libavcodec/hw_base_encode.c
index 7b6ec97d3b..912c707a68 100644
--- a/libavcodec/hw_base_encode.c
+++ b/libavcodec/hw_base_encode.c
@@ -804,6 +804,11 @@ int ff_hw_base_encode_init(AVCodecContext *avctx,
FFHWBaseEncodeContext *ctx)
int ff_hw_base_encode_close(FFHWBaseEncodeContext *ctx)
{
+FFHWBaseEncodePicture *pic;
+
+for (pic = ctx->pic_start; pic; pic = pic->next)
+base_encode_pic_free(pic);
+
av_fifo_freep2(&ctx->encode_fifo);
av_frame_free(&ctx->frame);
--
2.47.0
___
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 2/2] lavc/vaapi_encode_h265: Use surface alignment
This is needed to correctly set conformance window crop with Mesa AMD.
---
libavcodec/vaapi_encode_h265.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index 2283bcc0b4..0f97c9188b 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -951,8 +951,16 @@ static av_cold int
vaapi_encode_h265_get_encoder_caps(AVCodecContext *avctx)
"min CB size %dx%d.\n", priv->ctu_size, priv->ctu_size,
priv->min_cb_size, priv->min_cb_size);
-base_ctx->surface_width = FFALIGN(avctx->width, priv->min_cb_size);
-base_ctx->surface_height = FFALIGN(avctx->height, priv->min_cb_size);
+if (priv->common.surface_alignment_width &&
+priv->common.surface_alignment_height) {
+base_ctx->surface_width =
+FFALIGN(avctx->width, priv->common.surface_alignment_width);
+base_ctx->surface_height =
+FFALIGN(avctx->height, priv->common.surface_alignment_height);
+} else {
+base_ctx->surface_width = FFALIGN(avctx->width, priv->min_cb_size);
+base_ctx->surface_height = FFALIGN(avctx->height, priv->min_cb_size);
+}
base_ctx->slice_block_width = base_ctx->slice_block_height =
priv->ctu_size;
--
2.47.0
___
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/2] lavc/vaapi_encode: Query surface alignment
It needs to create temporary config to query surface attribute.
---
libavcodec/vaapi_encode.c | 66 +++
libavcodec/vaapi_encode.h | 4 +++
2 files changed, 70 insertions(+)
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 16a9a364f0..c8864745a9 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -1133,6 +1133,68 @@ fail:
return err;
}
+static av_cold int vaapi_encode_surface_alignment(av_unused AVCodecContext
*avctx)
+{
+#if VA_CHECK_VERSION(1, 21, 0)
+VAAPIEncodeContext *ctx = avctx->priv_data;
+VASurfaceAttrib *attr_list = NULL;
+unsigned int attr_count = 0;
+VAConfigID va_config;
+VAStatus vas;
+int err = 0;
+
+vas = vaCreateConfig(ctx->hwctx->display,
+ ctx->va_profile, ctx->va_entrypoint,
+ NULL, 0, &va_config);
+if (vas != VA_STATUS_SUCCESS) {
+av_log(avctx, AV_LOG_ERROR, "Failed to create temp encode pipeline "
+ "configuration: %d (%s).\n", vas, vaErrorStr(vas));
+return AVERROR(EIO);
+}
+
+vas = vaQuerySurfaceAttributes(ctx->hwctx->display, va_config,
+ 0, &attr_count);
+if (vas != VA_STATUS_SUCCESS) {
+av_log(avctx, AV_LOG_ERROR, "Failed to query surface attributes: "
+ "%d (%s).\n", vas, vaErrorStr(vas));
+err = AVERROR_EXTERNAL;
+goto fail;
+}
+
+attr_list = av_malloc(attr_count * sizeof(*attr_list));
+if (!attr_list) {
+err = AVERROR(ENOMEM);
+goto fail;
+}
+
+vas = vaQuerySurfaceAttributes(ctx->hwctx->display, va_config,
+ attr_list, &attr_count);
+if (vas != VA_STATUS_SUCCESS) {
+av_log(avctx, AV_LOG_ERROR, "Failed to query surface attributes: "
+ "%d (%s).\n", vas, vaErrorStr(vas));
+err = AVERROR_EXTERNAL;
+goto fail;
+}
+
+for (unsigned int i = 0; i < attr_count; i++) {
+if (attr_list[i].type == VASurfaceAttribAlignmentSize) {
+ctx->surface_alignment_width =
+1 << (attr_list[i].value.value.i & 0xf);
+ctx->surface_alignment_height =
+1 << ((attr_list[i].value.value.i & 0xf0) >> 4);
+break;
+}
+}
+
+fail:
+av_freep(&attr_list);
+vaDestroyConfig(ctx->hwctx->display, va_config);
+return err;
+#else
+return 0;
+#endif
+}
+
static const VAAPIEncodeRCMode vaapi_encode_rc_modes[] = {
// Bitrate Quality
// | Maxrate | HRD/VBV
@@ -2111,6 +2173,10 @@ av_cold int ff_vaapi_encode_init(AVCodecContext *avctx)
if (err < 0)
goto fail;
+err = vaapi_encode_surface_alignment(avctx);
+if (err < 0)
+goto fail;
+
if (ctx->codec->get_encoder_caps) {
err = ctx->codec->get_encoder_caps(avctx);
if (err < 0)
diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
index c4f85397a2..ca5cfe9eca 100644
--- a/libavcodec/vaapi_encode.h
+++ b/libavcodec/vaapi_encode.h
@@ -260,6 +260,10 @@ typedef struct VAAPIEncodeContext {
* This is a RefStruct reference.
*/
VABufferID *coded_buffer_ref;
+
+// Surface alignment required by driver.
+int surface_alignment_width;
+int surface_alignment_height;
} VAAPIEncodeContext;
typedef struct VAAPIEncodeType {
--
2.47.0
___
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] hw_base_enc: inject side data to crop output for AV1
On Sat, Sep 14, 2024 at 8:59 AM Lynne via ffmpeg-devel
wrote:
>
> Unlike H264/H265, AV1 contains no fields to crop encoded output
> to specific sizes.
> AMD's hardware cannot handle encoding of unaligned dimensions for
> AV1, hence it codes 1920x1080 as 1920x1088.
>
> Add side data to crop the output back to the original dimensions.
> There's an AV1-spec extension planned to fix this here:
> https://github.com/AOMediaCodec/av1-spec/pull/346
>
> But it seems to have stuck for now.
> ---
> libavcodec/hw_base_encode.c | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/libavcodec/hw_base_encode.c b/libavcodec/hw_base_encode.c
> index 7b6ec97d3b..c28f1aa91c 100644
> --- a/libavcodec/hw_base_encode.c
> +++ b/libavcodec/hw_base_encode.c
> @@ -22,6 +22,7 @@
> #include "libavutil/log.h"
> #include "libavutil/mem.h"
> #include "libavutil/pixdesc.h"
> +#include "libavutil/intreadwrite.h"
>
> #include "encode.h"
> #include "avcodec.h"
> @@ -551,6 +552,30 @@ int
> ff_hw_base_encode_set_output_property(FFHWBaseEncodeContext *ctx,
> (3 * ctx->output_delay + ctx->async_depth)];
> }
>
> +if ((avctx->codec_id == AV_CODEC_ID_AV1) &&
> +((avctx->coded_width != avctx->width) ||
> + (avctx->coded_height != avctx->height))) {
> +int err;
> +size_t crop_data_size = 4*4;
> +
> +uint8_t *crop_data = av_mallocz(crop_data_size);
> +if (!crop_data) {
> +av_buffer_unref(&pkt->buf);
> +return AVERROR(ENOMEM);
> +}
> +
> +AV_WL32(&crop_data[2], ctx->surface_width - avctx->width);
Should this be avctx->coded_width - avctx->width instead?
Also there is a flag_no_delay early return above in this function, so
this code doesn't run when I try to add support for this in vaapi
encode.
> +AV_WL32(&crop_data[3], ctx->surface_height - avctx->height);
> +
> +err = av_packet_add_side_data(pkt, AV_PKT_DATA_FRAME_CROPPING,
> + crop_data, crop_data_size);
This doesn't seem to be currently picked up by movenc/matroskaenc as
both will only take the side data from avctx->coded_side_data?
> +if (err < 0) {
> +av_buffer_unref(&pkt->buf);
> +av_free(crop_data);
> +return err;
> +}
> +}
> +
> return 0;
> }
>
> --
> 2.45.2.753.g447d99e1c3b
> ___
> 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/2] lavc/vaapi_encode: Query surface alignment
On Tue, Oct 22, 2024 at 5:28 PM David Rosca wrote:
>
> It needs to create temporary config to query surface attribute.
> ---
Ping.
Thanks,
David
> libavcodec/vaapi_encode.c | 66 +++
> libavcodec/vaapi_encode.h | 4 +++
> 2 files changed, 70 insertions(+)
>
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index 16a9a364f0..c8864745a9 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -1133,6 +1133,68 @@ fail:
> return err;
> }
>
> +static av_cold int vaapi_encode_surface_alignment(av_unused AVCodecContext
> *avctx)
> +{
> +#if VA_CHECK_VERSION(1, 21, 0)
> +VAAPIEncodeContext *ctx = avctx->priv_data;
> +VASurfaceAttrib *attr_list = NULL;
> +unsigned int attr_count = 0;
> +VAConfigID va_config;
> +VAStatus vas;
> +int err = 0;
> +
> +vas = vaCreateConfig(ctx->hwctx->display,
> + ctx->va_profile, ctx->va_entrypoint,
> + NULL, 0, &va_config);
> +if (vas != VA_STATUS_SUCCESS) {
> +av_log(avctx, AV_LOG_ERROR, "Failed to create temp encode pipeline "
> + "configuration: %d (%s).\n", vas, vaErrorStr(vas));
> +return AVERROR(EIO);
> +}
> +
> +vas = vaQuerySurfaceAttributes(ctx->hwctx->display, va_config,
> + 0, &attr_count);
> +if (vas != VA_STATUS_SUCCESS) {
> +av_log(avctx, AV_LOG_ERROR, "Failed to query surface attributes: "
> + "%d (%s).\n", vas, vaErrorStr(vas));
> +err = AVERROR_EXTERNAL;
> +goto fail;
> +}
> +
> +attr_list = av_malloc(attr_count * sizeof(*attr_list));
> +if (!attr_list) {
> +err = AVERROR(ENOMEM);
> +goto fail;
> +}
> +
> +vas = vaQuerySurfaceAttributes(ctx->hwctx->display, va_config,
> + attr_list, &attr_count);
> +if (vas != VA_STATUS_SUCCESS) {
> +av_log(avctx, AV_LOG_ERROR, "Failed to query surface attributes: "
> + "%d (%s).\n", vas, vaErrorStr(vas));
> +err = AVERROR_EXTERNAL;
> +goto fail;
> +}
> +
> +for (unsigned int i = 0; i < attr_count; i++) {
> +if (attr_list[i].type == VASurfaceAttribAlignmentSize) {
> +ctx->surface_alignment_width =
> +1 << (attr_list[i].value.value.i & 0xf);
> +ctx->surface_alignment_height =
> +1 << ((attr_list[i].value.value.i & 0xf0) >> 4);
> +break;
> +}
> +}
> +
> +fail:
> +av_freep(&attr_list);
> +vaDestroyConfig(ctx->hwctx->display, va_config);
> +return err;
> +#else
> +return 0;
> +#endif
> +}
> +
> static const VAAPIEncodeRCMode vaapi_encode_rc_modes[] = {
> // Bitrate Quality
> // | Maxrate | HRD/VBV
> @@ -2111,6 +2173,10 @@ av_cold int ff_vaapi_encode_init(AVCodecContext *avctx)
> if (err < 0)
> goto fail;
>
> +err = vaapi_encode_surface_alignment(avctx);
> +if (err < 0)
> +goto fail;
> +
> if (ctx->codec->get_encoder_caps) {
> err = ctx->codec->get_encoder_caps(avctx);
> if (err < 0)
> diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
> index c4f85397a2..ca5cfe9eca 100644
> --- a/libavcodec/vaapi_encode.h
> +++ b/libavcodec/vaapi_encode.h
> @@ -260,6 +260,10 @@ typedef struct VAAPIEncodeContext {
> * This is a RefStruct reference.
> */
> VABufferID *coded_buffer_ref;
> +
> +// Surface alignment required by driver.
> +int surface_alignment_width;
> +int surface_alignment_height;
> } VAAPIEncodeContext;
>
> typedef struct VAAPIEncodeType {
> --
> 2.47.0
>
___
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] vulkan_encode_h264/5: Fix uninitialized return value in write_extra_headers
---
libavcodec/vulkan_encode_h264.c | 1 +
libavcodec/vulkan_encode_h265.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/libavcodec/vulkan_encode_h264.c b/libavcodec/vulkan_encode_h264.c
index cdc87fb4ca..fdd3cc8a55 100644
--- a/libavcodec/vulkan_encode_h264.c
+++ b/libavcodec/vulkan_encode_h264.c
@@ -1311,6 +1311,7 @@ static int write_extra_headers(AVCodecContext *avctx,
if (err < 0)
goto fail;
} else {
+err = 0;
*data_len = 0;
}
diff --git a/libavcodec/vulkan_encode_h265.c b/libavcodec/vulkan_encode_h265.c
index cd50f2f756..8c25cacded 100644
--- a/libavcodec/vulkan_encode_h265.c
+++ b/libavcodec/vulkan_encode_h265.c
@@ -1471,6 +1471,7 @@ static int write_extra_headers(AVCodecContext *avctx,
if (err < 0)
goto fail;
} else {
+err = 0;
*data_len = 0;
}
--
2.47.0
___
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] vulkan: Don't try to early reuse exec context with query
It needs to first get the query before the context can be used again. Fixes getting incorrect values from encode query with async_depth > 1. --- libavutil/vulkan.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libavutil/vulkan.c b/libavutil/vulkan.c index 2c71312d78..8485c54db1 100644 --- a/libavutil/vulkan.c +++ b/libavutil/vulkan.c @@ -489,7 +489,8 @@ FFVkExecContext *ff_vk_exec_get(FFVulkanContext *s, FFVkExecPool *pool) /* Check if last submission has already finished. * If so, don't waste resources and reuse the same buffer. */ -if (vk->GetFenceStatus(s->hwctx->act_dev, e->fence) == VK_SUCCESS) +if (!e->query_data && +vk->GetFenceStatus(s->hwctx->act_dev, e->fence) == VK_SUCCESS) return e; pool->idx = (pool->idx + 1) % pool->pool_size; -- 2.47.0 ___ 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] lavc/vaapi_encode_av1: Always use slot 0 with 1 l0 ref
Don't need to alternate when only one reference is used.
Fixes fail after bf9f921ef7 ("avcodec/hw_base_encode: restrict size of
next_prev")
due to AV1 writer complaining about incorrect ref_order_hint value.
---
libavcodec/vaapi_encode_av1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/vaapi_encode_av1.c b/libavcodec/vaapi_encode_av1.c
index 1b350cd936..aca6c26aa2 100644
--- a/libavcodec/vaapi_encode_av1.c
+++ b/libavcodec/vaapi_encode_av1.c
@@ -504,7 +504,7 @@ static int
vaapi_encode_av1_init_picture_params(AVCodecContext *avctx,
fh->base_q_idx = priv->q_idx_p;
ref = pic->refs[0][pic->nb_refs[0] - 1];
href = ref->codec_priv;
-hpic->slot = !href->slot;
+hpic->slot = ctx->base.ref_l0 > 1 ? !href->slot : 0;
hpic->last_idr_frame = href->last_idr_frame;
fh->refresh_frame_flags = 1 << hpic->slot;
--
2.48.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_av1: Always use slot 0 with 1 l0 ref
On Tue, Mar 4, 2025 at 8:43 AM David Rosca wrote:
>
> On Tue, Mar 4, 2025 at 2:55 AM Wang, Fei W
> wrote:
> >
> > On Mon, 2025-03-03 at 14:47 +0100, David Rosca wrote:
> > > On Wed, Jan 15, 2025 at 10:41 PM David Rosca
> > > wrote:
> > > >
> > > > Don't need to alternate when only one reference is used.
> > > > Fixes fail after bf9f921ef7 ("avcodec/hw_base_encode: restrict size
> > > > of next_prev")
> > > > due to AV1 writer complaining about incorrect ref_order_hint value.
> > >
> > > Ping.
> >
> > Did you encode successful when ctx.base.ref_l0 equals to 1? There is an
> > error with this patch:
> >
> > $ ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi -i input.mp4 -c:v
> > av1_vaapi -y out.mp4
> > ...
> > [av1_vaapi @ 0x6246182df640] frame_type does not match inferred value:
> > 1, but should be 0.
> > [av1_vaapi @ 0x6246182df640] Failed to write unit 0 (type 3).
> > [av1_vaapi @ 0x6246182df640] Failed to write packed header.
>
> I see, it's still broken for L0=1, L1=1 (also broken on master).
> This patch fixes it for L0=1, L1=0 only.
I've sent a new patch that should fix it.
>
> David
> >
> > Thanks
> > Fei
> >
> > >
> > > > ---
> > > > libavcodec/vaapi_encode_av1.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/libavcodec/vaapi_encode_av1.c
> > > > b/libavcodec/vaapi_encode_av1.c
> > > > index 1b350cd936..aca6c26aa2 100644
> > > > --- a/libavcodec/vaapi_encode_av1.c
> > > > +++ b/libavcodec/vaapi_encode_av1.c
> > > > @@ -504,7 +504,7 @@ static int
> > > > vaapi_encode_av1_init_picture_params(AVCodecContext *avctx,
> > > > fh->base_q_idx = priv->q_idx_p;
> > > > ref = pic->refs[0][pic->nb_refs[0] - 1];
> > > > href = ref->codec_priv;
> > > > -hpic->slot = !href->slot;
> > > > +hpic->slot = ctx->base.ref_l0 > 1 ? !href->slot : 0;
> > > > hpic->last_idr_frame = href->last_idr_frame;
> > > > fh->refresh_frame_flags = 1 << hpic->slot;
> > > >
> > > > --
> > > > 2.48.1
> > > >
> > > ___
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@ffmpeg.org
> > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >
> > > To unsubscribe, visit link above, or email
> > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] lavc/vaapi_encode_av1: Fix ref_order_hint value for second slot
We always use two slots, even when only one L0 reference is supported
by the driver. However we still need to set the correct value for the
ref_order_hint of the second slot.
Fixes bf9f921ef7 ("avcodec/hw_base_encode: restrict size of next_prev")
---
libavcodec/vaapi_encode_av1.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/vaapi_encode_av1.c b/libavcodec/vaapi_encode_av1.c
index 1b350cd936..cf0ff53edc 100644
--- a/libavcodec/vaapi_encode_av1.c
+++ b/libavcodec/vaapi_encode_av1.c
@@ -476,6 +476,7 @@ static int
vaapi_encode_av1_init_picture_params(AVCodecContext *avctx,
AV1RawFrameHeader*fh = &fh_obu->obu.frame.header;
VAEncPictureParameterBufferAV1 *vpic = vaapi_pic->codec_picture_params;
CodedBitstreamFragment *obu = &priv->current_obu;
+CodedBitstreamAV1Context *cbctx = priv->cbc->priv_data;
FFHWBaseEncodePicture *ref;
VAAPIEncodeAV1Picture *href;
int slot, i;
@@ -523,6 +524,8 @@ static int
vaapi_encode_av1_init_picture_params(AVCodecContext *avctx,
fh->ref_frame_idx[3] = href->slot;
fh->ref_order_hint[href->slot] = ref->display_order -
href->last_idr_frame;
vpic->ref_frame_ctrl_l0.fields.search_idx1 = AV1_REF_FRAME_GOLDEN;
+} else {
+fh->ref_order_hint[!href->slot] =
cbctx->ref[!href->slot].order_hint;
}
break;
case FF_HW_PICTURE_TYPE_B:
--
2.49.0
___
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] lavu/hwcontext_vaapi: Add direct map quirk for Intel i965 driver
vaGetImage is currently used for all maps when read access is required
because vaDeriveImage is supposed to be very slow on old Intel HW with
i965 driver.
However, this is not the case with modern drivers and vaDeriveImage
is faster also for reading.
Add a new quirk for i965 driver that will keep the old behavior of using
vaGetImage for read access, and prefer vaDeriveImage with other drivers.
---
libavutil/hwcontext_vaapi.c | 8 ++--
libavutil/hwcontext_vaapi.h | 7 +++
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 95aa38d9d2..99148ba5da 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -377,7 +377,7 @@ static const struct {
{
"Intel i965 (Quick Sync)",
"i965",
-AV_VAAPI_DRIVER_QUIRK_RENDER_PARAM_BUFFERS,
+AV_VAAPI_DRIVER_QUIRK_RENDER_PARAM_BUFFERS |
AV_VAAPI_DRIVER_QUIRK_AVOID_DIRECT_MAP_READ,
},
#endif
{
@@ -812,6 +812,7 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
#if VA_CHECK_VERSION(1, 21, 0)
uint32_t vaflags = 0;
#endif
+int use_direct_map;
surface_id = (VASurfaceID)(uintptr_t)src->data[3];
av_log(hwfc, AV_LOG_DEBUG, "Map surface %#x.\n", surface_id);
@@ -854,8 +855,11 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
// faster with a copy routine which is aware of the limitation, but we
// assume for now that the user is not aware of that and would therefore
// prefer not to be given direct-mapped memory if they request read access.
+use_direct_map = !(flags & AV_HWFRAME_MAP_READ) ||
+!(hwctx->driver_quirks & AV_VAAPI_DRIVER_QUIRK_AVOID_DIRECT_MAP_READ);
+
if (ctx->derive_works && dst->format == hwfc->sw_format &&
-((flags & AV_HWFRAME_MAP_DIRECT) || !(flags & AV_HWFRAME_MAP_READ))) {
+((flags & AV_HWFRAME_MAP_DIRECT) || use_direct_map)) {
vas = vaDeriveImage(hwctx->display, surface_id, &map->image);
if (vas != VA_STATUS_SUCCESS) {
av_log(hwfc, AV_LOG_ERROR, "Failed to derive image from "
diff --git a/libavutil/hwcontext_vaapi.h b/libavutil/hwcontext_vaapi.h
index 0b2e071cb3..c08843bed1 100644
--- a/libavutil/hwcontext_vaapi.h
+++ b/libavutil/hwcontext_vaapi.h
@@ -58,6 +58,13 @@ enum {
* and the results of the vaQuerySurfaceAttributes() call will be faked.
*/
AV_VAAPI_DRIVER_QUIRK_SURFACE_ATTRIBUTES = (1 << 3),
+
+/**
+ * The driver does not map memory with fast read access.
+ * The surface map code will prefer vaGetImage instead of vaDeriveImage
+ * for read access, unless direct map was requested.
+ */
+AV_VAAPI_DRIVER_QUIRK_AVOID_DIRECT_MAP_READ = (1 << 4),
};
/**
--
2.49.0
___
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/vaapi_encode_av1: Always use slot 0 with 1 l0 ref
On Wed, Jan 15, 2025 at 10:41 PM David Rosca wrote:
>
> Don't need to alternate when only one reference is used.
> Fixes fail after bf9f921ef7 ("avcodec/hw_base_encode: restrict size of
> next_prev")
> due to AV1 writer complaining about incorrect ref_order_hint value.
Ping.
> ---
> libavcodec/vaapi_encode_av1.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/vaapi_encode_av1.c b/libavcodec/vaapi_encode_av1.c
> index 1b350cd936..aca6c26aa2 100644
> --- a/libavcodec/vaapi_encode_av1.c
> +++ b/libavcodec/vaapi_encode_av1.c
> @@ -504,7 +504,7 @@ static int
> vaapi_encode_av1_init_picture_params(AVCodecContext *avctx,
> fh->base_q_idx = priv->q_idx_p;
> ref = pic->refs[0][pic->nb_refs[0] - 1];
> href = ref->codec_priv;
> -hpic->slot = !href->slot;
> +hpic->slot = ctx->base.ref_l0 > 1 ? !href->slot : 0;
> hpic->last_idr_frame = href->last_idr_frame;
> fh->refresh_frame_flags = 1 << hpic->slot;
>
> --
> 2.48.1
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_av1: Always use slot 0 with 1 l0 ref
On Tue, Mar 4, 2025 at 2:55 AM Wang, Fei W
wrote:
>
> On Mon, 2025-03-03 at 14:47 +0100, David Rosca wrote:
> > On Wed, Jan 15, 2025 at 10:41 PM David Rosca
> > wrote:
> > >
> > > Don't need to alternate when only one reference is used.
> > > Fixes fail after bf9f921ef7 ("avcodec/hw_base_encode: restrict size
> > > of next_prev")
> > > due to AV1 writer complaining about incorrect ref_order_hint value.
> >
> > Ping.
>
> Did you encode successful when ctx.base.ref_l0 equals to 1? There is an
> error with this patch:
>
> $ ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi -i input.mp4 -c:v
> av1_vaapi -y out.mp4
> ...
> [av1_vaapi @ 0x6246182df640] frame_type does not match inferred value:
> 1, but should be 0.
> [av1_vaapi @ 0x6246182df640] Failed to write unit 0 (type 3).
> [av1_vaapi @ 0x6246182df640] Failed to write packed header.
I see, it's still broken for L0=1, L1=1 (also broken on master).
This patch fixes it for L0=1, L1=0 only.
David
>
> Thanks
> Fei
>
> >
> > > ---
> > > libavcodec/vaapi_encode_av1.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/libavcodec/vaapi_encode_av1.c
> > > b/libavcodec/vaapi_encode_av1.c
> > > index 1b350cd936..aca6c26aa2 100644
> > > --- a/libavcodec/vaapi_encode_av1.c
> > > +++ b/libavcodec/vaapi_encode_av1.c
> > > @@ -504,7 +504,7 @@ static int
> > > vaapi_encode_av1_init_picture_params(AVCodecContext *avctx,
> > > fh->base_q_idx = priv->q_idx_p;
> > > ref = pic->refs[0][pic->nb_refs[0] - 1];
> > > href = ref->codec_priv;
> > > -hpic->slot = !href->slot;
> > > +hpic->slot = ctx->base.ref_l0 > 1 ? !href->slot : 0;
> > > hpic->last_idr_frame = href->last_idr_frame;
> > > fh->refresh_frame_flags = 1 << hpic->slot;
> > >
> > > --
> > > 2.48.1
> > >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
> ___
> 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".
