Re: [FFmpeg-devel] [PATCH 1/2] lavc/qsvdec: fix keyframes
On Vr, 2024-05-24 at 13:20 +0800, Xiang, Haihao wrote:
> From: Haihao Xiang
>
> MFX_FRAMETYPE_IDR is ORed to the frame type for AVC and HEVC keyframes,
> and MFX_FRAMETYPE_I is taken as keyframe flag for other codecs when
> getting the output surface from the SDK, hence we may mark the output
> frame as keyframe accordingly.
>
> Signed-off-by: Haihao Xiang
> ---
> libavcodec/qsvdec.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
> index df0d49bc10..6ffd498456 100644
> --- a/libavcodec/qsvdec.c
> +++ b/libavcodec/qsvdec.c
> @@ -885,12 +885,18 @@ static int qsv_decode(AVCodecContext *avctx, QSVContext
> *q,
> frame->flags |= AV_FRAME_FLAG_INTERLACED *
> !(outsurf->Info.PicStruct & MFX_PICSTRUCT_PROGRESSIVE);
> frame->pict_type = ff_qsv_map_pictype(aframe.frame-
> >dec_info.FrameType);
> - //Key frame is IDR frame is only suitable for H264. For HEVC, IRAPs
> are key frames.
> - if (avctx->codec_id == AV_CODEC_ID_H264) {
> +
> + if (avctx->codec_id == AV_CODEC_ID_H264 ||
> + avctx->codec_id == AV_CODEC_ID_HEVC) {
> if (aframe.frame->dec_info.FrameType & MFX_FRAMETYPE_IDR)
> frame->flags |= AV_FRAME_FLAG_KEY;
> else
> frame->flags &= ~AV_FRAME_FLAG_KEY;
> + } else {
> + if (aframe.frame->dec_info.FrameType & MFX_FRAMETYPE_I)
> + frame->flags |= AV_FRAME_FLAG_KEY;
> + else
> + frame->flags &= ~AV_FRAME_FLAG_KEY;
> }
>
> /* update the surface properties */
Will apply,
-Haihao
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 07/17] qsv: Initialize impl_value
On Ma, 2024-05-27 at 01:52 +0200, Michael Niedermayer wrote:
> Fixes: The warnings from CID1598553 Uninitialized scalar variable
>
> Passing partly initialized structs is ugly and asking for hard to reproduce
> bugs,
> I do not know if this actually fixes a bug or just avoids the uninitialized
> fields
LGTM, it might avoid issue in the future. Fortunately the uninitialized field is
not used in the corresponding function call.
Thanks
Haihao
>
> Sponsored-by: Sovereign Tech Fund
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/qsv.c | 2 +-
> libavutil/hwcontext_qsv.c | 8
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
> index 6bbfe2a5a95..0c6fbd0dc09 100644
> --- a/libavcodec/qsv.c
> +++ b/libavcodec/qsv.c
> @@ -496,7 +496,7 @@ static int qsv_new_mfx_loader(AVCodecContext *avctx,
> mfxStatus sts;
> mfxLoader loader = NULL;
> mfxConfig cfg;
> - mfxVariant impl_value;
> + mfxVariant impl_value = {0};
>
> loader = MFXLoad();
> if (!loader) {
> diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
> index f3d919daea1..7cec3474786 100644
> --- a/libavutil/hwcontext_qsv.c
> +++ b/libavutil/hwcontext_qsv.c
> @@ -839,7 +839,7 @@ static int qsv_d3d11_update_config(void *ctx, mfxHDL
> handle, mfxConfig cfg)
> IDXGIDevice *pDXGIDevice = NULL;
> HRESULT hr;
> ID3D11Device *device = handle;
> - mfxVariant impl_value;
> + mfxVariant impl_value = {0};
>
> hr = ID3D11Device_QueryInterface(device, _IDXGIDevice,
> (void**));
> if (SUCCEEDED(hr)) {
> @@ -913,7 +913,7 @@ static int qsv_d3d9_update_config(void *ctx, mfxHDL
> handle, mfxConfig cfg)
> LUID luid;
> D3DDEVICE_CREATION_PARAMETERS params;
> HRESULT hr;
> - mfxVariant impl_value;
> + mfxVariant impl_value = {0};
>
> hr = IDirect3DDeviceManager9_OpenDeviceHandle(devmgr, _handle);
> if (FAILED(hr)) {
> @@ -995,7 +995,7 @@ static int qsv_va_update_config(void *ctx, mfxHDL handle,
> mfxConfig cfg)
> VADisplayAttribute attr = {
> .type = VADisplayPCIID,
> };
> - mfxVariant impl_value;
> + mfxVariant impl_value = {0};
>
> vas = vaGetDisplayAttributes(dpy, , 1);
> if (vas == VA_STATUS_SUCCESS && attr.flags !=
> VA_DISPLAY_ATTRIB_NOT_SUPPORTED) {
> @@ -1036,7 +1036,7 @@ static int qsv_new_mfx_loader(void *ctx,
> mfxStatus sts;
> mfxLoader loader = NULL;
> mfxConfig cfg;
> - mfxVariant impl_value;
> + mfxVariant impl_value = {0};
>
> *ploader = NULL;
> loader = MFXLoad();
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v11 07/14] avcodec/vaapi_encode: extract the init and close function to base layer
On 27/05/2024 02:35, Wu, Tong1 wrote:
From: ffmpeg-devel On Behalf Of Lynne
via ffmpeg-devel
Sent: Saturday, May 25, 2024 10:07 PM
To: ffmpeg-devel@ffmpeg.org
Cc: Lynne
Subject: Re: [FFmpeg-devel] [PATCH v11 07/14] avcodec/vaapi_encode: extract
the init and close function to base layer
On 25/05/2024 12:30, tong1.wu-at-intel@ffmpeg.org wrote:
From: Tong Wu
Related parameters such as device context, frame context are also moved
to base layer.
Signed-off-by: Tong Wu
---
libavcodec/hw_base_encode.c | 49 ++
libavcodec/hw_base_encode.h | 17 +++
libavcodec/vaapi_encode.c | 90 +++--
libavcodec/vaapi_encode.h | 10
libavcodec/vaapi_encode_av1.c | 2 +-
libavcodec/vaapi_encode_h264.c | 2 +-
libavcodec/vaapi_encode_h265.c | 2 +-
libavcodec/vaapi_encode_mjpeg.c | 6 ++-
8 files changed, 102 insertions(+), 76 deletions(-)
diff --git a/libavcodec/hw_base_encode.c b/libavcodec/hw_base_encode.c
index 16afaa37be..c4789380b6 100644
--- a/libavcodec/hw_base_encode.c
+++ b/libavcodec/hw_base_encode.c
@@ -592,3 +592,52 @@ end:
return 0;
}
+
+int ff_hw_base_encode_init(AVCodecContext *avctx)
+{
+FFHWBaseEncodeContext *ctx = avctx->priv_data;
This is the issue I was talking about, this requires that
FFHWBaseEncodeContext is always the main context.
Could you change it so everything takes FFHWBaseEncodeContext as an
argument, rather than AVCodecContext (apart from where the function
absolutely must read some data from it)?
I'm trying to understand it more.
In ff_hw_base_encode_init we also have the following code:
if (!avctx->hw_frames_ctx) {
av_log(avctx, AV_LOG_ERROR, "A hardware frames reference is "
"required to associate the encoding device.\n");
return AVERROR(EINVAL);
}
In this scenario we still need avctx right? So maybe this is the "must read data
from it" situation and we keep AVCodecContext as the main context?
Yup. My point is that FFHWBaseEncodeContext doesn't become the primary
context that must be used, but a separate component other users can use
standalone.
Plus I have this av_log concern which is there's indeed some function that the
only use of avctx is its av_log's context. Do you think I should instead use
FFHWBaseEncodeContext as the main context and pass it to av_log for this
situation while keeping AVCodecContext as the main context for other functions
which actually read from AVCodecContext. That might lead to different av_log
context in the same file.
Just save a pointer to avctx on init in FFHWBaseEncodeContext. That's
what most of our code does.
Do you think the callbacks in FFHWEncodePictureOperation should be changed too?
Or only all the functions in hw_base_encode.c should be concerned. Thank you.
No, the callbacks should stay as-is. Users need to retrieve their own
context via avctx. That's also a reason why you should keep a pointer to
avctx on init.
Thanks
OpenPGP_0xA2FEA5F03F034464.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v11 07/14] avcodec/vaapi_encode: extract the init and close function to base layer
>From: ffmpeg-devel On Behalf Of Lynne
>via ffmpeg-devel
>Sent: Saturday, May 25, 2024 10:07 PM
>To: ffmpeg-devel@ffmpeg.org
>Cc: Lynne
>Subject: Re: [FFmpeg-devel] [PATCH v11 07/14] avcodec/vaapi_encode: extract
>the init and close function to base layer
>
>On 25/05/2024 12:30, tong1.wu-at-intel@ffmpeg.org wrote:
>> From: Tong Wu
>>
>> Related parameters such as device context, frame context are also moved
>> to base layer.
>>
>> Signed-off-by: Tong Wu
>> ---
>> libavcodec/hw_base_encode.c | 49 ++
>> libavcodec/hw_base_encode.h | 17 +++
>> libavcodec/vaapi_encode.c | 90 +++--
>> libavcodec/vaapi_encode.h | 10
>> libavcodec/vaapi_encode_av1.c | 2 +-
>> libavcodec/vaapi_encode_h264.c | 2 +-
>> libavcodec/vaapi_encode_h265.c | 2 +-
>> libavcodec/vaapi_encode_mjpeg.c | 6 ++-
>> 8 files changed, 102 insertions(+), 76 deletions(-)
>>
>> diff --git a/libavcodec/hw_base_encode.c b/libavcodec/hw_base_encode.c
>> index 16afaa37be..c4789380b6 100644
>> --- a/libavcodec/hw_base_encode.c
>> +++ b/libavcodec/hw_base_encode.c
>> @@ -592,3 +592,52 @@ end:
>>
>> return 0;
>> }
>> +
>> +int ff_hw_base_encode_init(AVCodecContext *avctx)
>> +{
>> +FFHWBaseEncodeContext *ctx = avctx->priv_data;
>
>This is the issue I was talking about, this requires that
>FFHWBaseEncodeContext is always the main context.
>
>Could you change it so everything takes FFHWBaseEncodeContext as an
>argument, rather than AVCodecContext (apart from where the function
>absolutely must read some data from it)?
I'm trying to understand it more.
In ff_hw_base_encode_init we also have the following code:
if (!avctx->hw_frames_ctx) {
av_log(avctx, AV_LOG_ERROR, "A hardware frames reference is "
"required to associate the encoding device.\n");
return AVERROR(EINVAL);
}
In this scenario we still need avctx right? So maybe this is the "must read
data from it" situation and we keep AVCodecContext as the main context?
Plus I have this av_log concern which is there's indeed some function that the
only use of avctx is its av_log's context. Do you think I should instead use
FFHWBaseEncodeContext as the main context and pass it to av_log for this
situation while keeping AVCodecContext as the main context for other functions
which actually read from AVCodecContext. That might lead to different av_log
context in the same file.
Do you think the callbacks in FFHWEncodePictureOperation should be changed too?
Or only all the functions in hw_base_encode.c should be concerned. Thank you.
-Tong
___
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 01/17] avcodec/dxva2: Initialize dxva_size and check it
On Mon, May 27, 2024 at 01:52:13AM +0200, Michael Niedermayer wrote: > Fixes: CID1591878 Uninitialized scalar variable > Fixes: CID1591928 Uninitialized pointer read > > Sponsored-by: Sovereign Tech Fund > Signed-off-by: Michael Niedermayer > --- > libavcodec/dxva2.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Also all the dshow, windows, dxva ... stuff is untested due to lack of a box with such OS so the respective patches should be reviewed with that in mind! thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Democracy is the form of government in which you can choose your dictator signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 17/17] avdevice/dshow_filter: Use wcscpy_s()
Fixes: CID1591929 Copy into fixed size buffer Sponsored-by: Sovereign Tech Fund Signed-off-by: Michael Niedermayer --- libavdevice/dshow_filter.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavdevice/dshow_filter.c b/libavdevice/dshow_filter.c index 4642ac077c5..2122c846262 100644 --- a/libavdevice/dshow_filter.c +++ b/libavdevice/dshow_filter.c @@ -135,7 +135,7 @@ long WINAPI ff_dshow_filter_JoinFilterGraph(DShowFilter *this, IFilterGraph *gra this->info.pGraph = graph; if (name) -wcscpy(this->info.achName, name); +wcscpy_s(this->info.achName, sizeof(this->info.achName) / sizeof(wchar_t), name); return S_OK; } -- 2.45.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 10/17] avdevice/dshow: Remove NULL check on pin
The pointer is used before the check Fixes: CID1591884 Dereference before null check Sponsored-by: Sovereign Tech Fund Signed-off-by: Michael Niedermayer --- libavdevice/dshow.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c index 0330d1d0b6c..8942c0c499a 100644 --- a/libavdevice/dshow.c +++ b/libavdevice/dshow.c @@ -432,8 +432,8 @@ dshow_get_device_media_types(AVFormatContext *avctx, enum dshowDeviceType devtyp IEnumMediaTypes_Release(types); if (p) IKsPropertySet_Release(p); -if (pin) -IPin_Release(pin); + +IPin_Release(pin); } IEnumPins_Release(pins); -- 2.45.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 16/17] avdevice/dshow: Initialize 2 pointers
Coverity claims these are used uninitilaized in CID1598561 Uninitialized
pointer write and CID1598565 Uninitialized pointer write
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavdevice/dshow.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c
index 403e56fe135..5947096cb29 100644
--- a/libavdevice/dshow.c
+++ b/libavdevice/dshow.c
@@ -898,8 +898,8 @@ dshow_cycle_formats(AVFormatContext *avctx, enum
dshowDeviceType devtype,
if (devtype == VideoDevice) {
VIDEO_STREAM_CONFIG_CAPS *vcaps = caps;
-BITMAPINFOHEADER *bih;
-int64_t *fr;
+BITMAPINFOHEADER *bih = NULL;
+int64_t *fr = NULL;
#if DSHOWDEBUG
ff_print_VIDEO_STREAM_CONFIG_CAPS(vcaps);
#endif
--
2.45.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 15/17] avdevice/dshow: check ff_dshow_pin_ConnectionMediaType() for failure
Maybe Fixes: CID1598557 Explicit null dereferenced
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavdevice/dshow.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c
index 645c33ea2e6..403e56fe135 100644
--- a/libavdevice/dshow.c
+++ b/libavdevice/dshow.c
@@ -1546,7 +1546,10 @@ dshow_add_device(AVFormatContext *avctx,
ctx->capture_filter[devtype]->stream_index = st->index;
-ff_dshow_pin_ConnectionMediaType(ctx->capture_pin[devtype], );
+if (ff_dshow_pin_ConnectionMediaType(ctx->capture_pin[devtype], ) !=
S_OK) {
+ret = AVERROR(EIO);
+goto error;
+}
fmt_info = dshow_get_format_info();
if (!fmt_info) {
ret = AVERROR(EIO);
--
2.45.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 09/17] avcodec/vp8: Check cond init
Fixes: CID1598563 Unchecked return value
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavcodec/vp8.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
index 3e1f67172ae..d6df018655c 100644
--- a/libavcodec/vp8.c
+++ b/libavcodec/vp8.c
@@ -252,7 +252,11 @@ int update_dimensions(VP8Context *s, int width, int
height, int is_vp7)
free_buffers(s);
return AVERROR(ret);
}
-pthread_cond_init(>thread_data[i].cond, NULL);
+ret = pthread_cond_init(>thread_data[i].cond, NULL);
+if (ret) {
+free_buffers(s);
+return AVERROR(ret);
+}
#endif
}
--
2.45.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 14/17] avdevice/dshow: Cleanup also on av_log case
Fixes: CID1598550 Resource leak Sponsored-by: Sovereign Tech Fund Signed-off-by: Michael Niedermayer --- libavdevice/dshow.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c index 557cf33161e..645c33ea2e6 100644 --- a/libavdevice/dshow.c +++ b/libavdevice/dshow.c @@ -1001,7 +1001,7 @@ dshow_cycle_formats(AVFormatContext *avctx, enum dshowDeviceType devtype, " ch=%2u, bits=%2u, rate=%6lu\n", fx->nChannels, fx->wBitsPerSample, fx->nSamplesPerSec ); -continue; +goto next; } if ( (requested_sample_rate && requested_sample_rate != fx->nSamplesPerSec) || -- 2.45.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 08/17] avcodec/vp8: Check mutex init
Fixes: CID1598556 Unchecked return value
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavcodec/vp8.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
index 8e91613068a..3e1f67172ae 100644
--- a/libavcodec/vp8.c
+++ b/libavcodec/vp8.c
@@ -247,7 +247,11 @@ int update_dimensions(VP8Context *s, int width, int
height, int is_vp7)
return AVERROR(ENOMEM);
}
#if HAVE_THREADS
-pthread_mutex_init(>thread_data[i].lock, NULL);
+ret = pthread_mutex_init(>thread_data[i].lock, NULL);
+if (ret) {
+free_buffers(s);
+return AVERROR(ret);
+}
pthread_cond_init(>thread_data[i].cond, NULL);
#endif
}
--
2.45.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 13/17] avdevice/dshow: Check ICaptureGraphBuilder2_SetFiltergraph() for failure
Fixes: CID1591939 Logically dead code
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavdevice/dshow.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c
index 911b0ecc078..557cf33161e 100644
--- a/libavdevice/dshow.c
+++ b/libavdevice/dshow.c
@@ -1465,7 +1465,7 @@ dshow_open_device(AVFormatContext *avctx, ICreateDevEnum
*devenum,
av_log(avctx, AV_LOG_ERROR, "Could not create CaptureGraphBuilder2\n");
goto error;
}
-ICaptureGraphBuilder2_SetFiltergraph(graph_builder2, graph);
+r = ICaptureGraphBuilder2_SetFiltergraph(graph_builder2, graph);
if (r != S_OK) {
av_log(avctx, AV_LOG_ERROR, "Could not set graph for
CaptureGraphBuilder2\n");
goto error;
--
2.45.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 07/17] qsv: Initialize impl_value
Fixes: The warnings from CID1598553 Uninitialized scalar variable
Passing partly initialized structs is ugly and asking for hard to reproduce
bugs,
I do not know if this actually fixes a bug or just avoids the uninitialized
fields
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavcodec/qsv.c | 2 +-
libavutil/hwcontext_qsv.c | 8
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
index 6bbfe2a5a95..0c6fbd0dc09 100644
--- a/libavcodec/qsv.c
+++ b/libavcodec/qsv.c
@@ -496,7 +496,7 @@ static int qsv_new_mfx_loader(AVCodecContext *avctx,
mfxStatus sts;
mfxLoader loader = NULL;
mfxConfig cfg;
-mfxVariant impl_value;
+mfxVariant impl_value = {0};
loader = MFXLoad();
if (!loader) {
diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
index f3d919daea1..7cec3474786 100644
--- a/libavutil/hwcontext_qsv.c
+++ b/libavutil/hwcontext_qsv.c
@@ -839,7 +839,7 @@ static int qsv_d3d11_update_config(void *ctx, mfxHDL
handle, mfxConfig cfg)
IDXGIDevice *pDXGIDevice = NULL;
HRESULT hr;
ID3D11Device *device = handle;
-mfxVariant impl_value;
+mfxVariant impl_value = {0};
hr = ID3D11Device_QueryInterface(device, _IDXGIDevice,
(void**));
if (SUCCEEDED(hr)) {
@@ -913,7 +913,7 @@ static int qsv_d3d9_update_config(void *ctx, mfxHDL handle,
mfxConfig cfg)
LUID luid;
D3DDEVICE_CREATION_PARAMETERS params;
HRESULT hr;
-mfxVariant impl_value;
+mfxVariant impl_value = {0};
hr = IDirect3DDeviceManager9_OpenDeviceHandle(devmgr, _handle);
if (FAILED(hr)) {
@@ -995,7 +995,7 @@ static int qsv_va_update_config(void *ctx, mfxHDL handle,
mfxConfig cfg)
VADisplayAttribute attr = {
.type = VADisplayPCIID,
};
-mfxVariant impl_value;
+mfxVariant impl_value = {0};
vas = vaGetDisplayAttributes(dpy, , 1);
if (vas == VA_STATUS_SUCCESS && attr.flags !=
VA_DISPLAY_ATTRIB_NOT_SUPPORTED) {
@@ -1036,7 +1036,7 @@ static int qsv_new_mfx_loader(void *ctx,
mfxStatus sts;
mfxLoader loader = NULL;
mfxConfig cfg;
-mfxVariant impl_value;
+mfxVariant impl_value = {0};
*ploader = NULL;
loader = MFXLoad();
--
2.45.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 12/17] avdevice/dshow: Check device_filter_unique_name before use
Fixes: CID1591931 Explicit null dereferenced
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavdevice/dshow.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c
index fd9027b1787..911b0ecc078 100644
--- a/libavdevice/dshow.c
+++ b/libavdevice/dshow.c
@@ -1373,7 +1373,7 @@ dshow_open_device(AVFormatContext *avctx, ICreateDevEnum
*devenum,
if (ctx->device_filter[otherDevType]) {
// avoid adding add two instances of the same device to the graph, one
for video, one for audio
// a few devices don't support this (could also do this check earlier
to avoid double crossbars, etc. but they seem OK)
-if (strcmp(device_filter_unique_name,
ctx->device_unique_name[otherDevType]) == 0) {
+if (!device_filter_unique_name || strcmp(device_filter_unique_name,
ctx->device_unique_name[otherDevType]) == 0) {
av_log(avctx, AV_LOG_DEBUG, "reusing previous graph capture
filter... %s\n", device_filter_unique_name);
IBaseFilter_Release(device_filter);
device_filter = ctx->device_filter[otherDevType];
--
2.45.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 06/17] avcodec/mfenc: check IMFSample_ConvertToContiguousBuffer() for failure
Fixes: CID1591911 Logically dead code Sponsored-by: Sovereign Tech Fund Signed-off-by: Michael Niedermayer --- libavcodec/mfenc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/mfenc.c b/libavcodec/mfenc.c index 2c68adbdc73..b8f8a25f434 100644 --- a/libavcodec/mfenc.c +++ b/libavcodec/mfenc.c @@ -249,7 +249,7 @@ static int mf_sample_to_avpacket(AVCodecContext *avctx, IMFSample *sample, AVPac if ((ret = ff_get_encode_buffer(avctx, avpkt, len, 0)) < 0) return ret; -IMFSample_ConvertToContiguousBuffer(sample, ); +hr = IMFSample_ConvertToContiguousBuffer(sample, ); if (FAILED(hr)) return AVERROR_EXTERNAL; -- 2.45.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 11/17] avdevice/dshow: fix badly indented line
Signed-off-by: Michael Niedermayer
---
libavdevice/dshow.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c
index 8942c0c499a..fd9027b1787 100644
--- a/libavdevice/dshow.c
+++ b/libavdevice/dshow.c
@@ -1370,7 +1370,7 @@ dshow_open_device(AVFormatContext *avctx, ICreateDevEnum
*devenum,
goto error;
}
}
-if (ctx->device_filter[otherDevType]) {
+if (ctx->device_filter[otherDevType]) {
// avoid adding add two instances of the same device to the graph, one
for video, one for audio
// a few devices don't support this (could also do this check earlier
to avoid double crossbars, etc. but they seem OK)
if (strcmp(device_filter_unique_name,
ctx->device_unique_name[otherDevType]) == 0) {
--
2.45.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 05/17] avcodec/dxva2_*: Initialize dxva_data_ptr
Fixes: CID1591888 Uninitialized scalar variable
Fixes: CID1591925 Uninitialized pointer read
Fixes: CID1591933 Uninitialized scalar variable
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavcodec/dxva2_av1.c | 4 ++--
libavcodec/dxva2_hevc.c | 5 -
libavcodec/dxva2_mpeg2.c | 5 -
libavcodec/dxva2_vc1.c | 5 -
libavcodec/dxva2_vp9.c | 4 ++--
5 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/libavcodec/dxva2_av1.c b/libavcodec/dxva2_av1.c
index 1b555106599..ea97fcb87e5 100644
--- a/libavcodec/dxva2_av1.c
+++ b/libavcodec/dxva2_av1.c
@@ -354,7 +354,7 @@ static int commit_bitstream_and_slice_buffer(AVCodecContext
*avctx,
const AV1DecContext *h = avctx->priv_data;
AVDXVAContext *ctx = DXVA_CONTEXT(avctx);
struct av1_dxva2_picture_context *ctx_pic =
h->cur_frame.hwaccel_picture_private;
-void *dxva_data_ptr;
+void *dxva_data_ptr = NULL;
uint8_t *dxva_data;
unsigned dxva_size;
unsigned padding;
@@ -382,7 +382,7 @@ static int commit_bitstream_and_slice_buffer(AVCodecContext
*avctx,
dxva_data = dxva_data_ptr;
-if (ctx_pic->bitstream_size > dxva_size) {
+if (!dxva_data || ctx_pic->bitstream_size > dxva_size) {
av_log(avctx, AV_LOG_ERROR, "Bitstream size exceeds hardware buffer");
return -1;
}
diff --git a/libavcodec/dxva2_hevc.c b/libavcodec/dxva2_hevc.c
index 31d74a7164d..5eb166c3075 100644
--- a/libavcodec/dxva2_hevc.c
+++ b/libavcodec/dxva2_hevc.c
@@ -248,7 +248,7 @@ static int commit_bitstream_and_slice_buffer(AVCodecContext
*avctx,
const HEVCFrame *current_picture = h->ref;
struct hevc_dxva2_picture_context *ctx_pic =
current_picture->hwaccel_picture_private;
DXVA_Slice_HEVC_Short *slice = NULL;
-void *dxva_data_ptr;
+void *dxva_data_ptr = NULL;
uint8_t *dxva_data, *current, *end;
unsigned dxva_size;
void *slice_data;
@@ -278,6 +278,9 @@ static int commit_bitstream_and_slice_buffer(AVCodecContext
*avctx,
}
#endif
+if (!dxva_data_ptr)
+return -1;
+
dxva_data = dxva_data_ptr;
current = dxva_data;
end = dxva_data + dxva_size;
diff --git a/libavcodec/dxva2_mpeg2.c b/libavcodec/dxva2_mpeg2.c
index d31a8bb8724..5de062e5308 100644
--- a/libavcodec/dxva2_mpeg2.c
+++ b/libavcodec/dxva2_mpeg2.c
@@ -160,7 +160,7 @@ static int commit_bitstream_and_slice_buffer(AVCodecContext
*avctx,
s->current_picture_ptr->hwaccel_picture_private;
const int is_field = s->picture_structure != PICT_FRAME;
const unsigned mb_count = s->mb_width * (s->mb_height >> is_field);
-void *dxva_data_ptr;
+void *dxva_data_ptr = NULL;
uint8_t *dxva_data, *current, *end;
unsigned dxva_size;
unsigned i;
@@ -186,6 +186,9 @@ static int commit_bitstream_and_slice_buffer(AVCodecContext
*avctx,
}
#endif
+if (!dxva_data_ptr)
+return -1;
+
dxva_data = dxva_data_ptr;
current = dxva_data;
end = dxva_data + dxva_size;
diff --git a/libavcodec/dxva2_vc1.c b/libavcodec/dxva2_vc1.c
index f7513b2b153..04f26ddff66 100644
--- a/libavcodec/dxva2_vc1.c
+++ b/libavcodec/dxva2_vc1.c
@@ -197,7 +197,7 @@ static int commit_bitstream_and_slice_buffer(AVCodecContext
*avctx,
const unsigned start_code_size = avctx->codec_id == AV_CODEC_ID_VC1 ?
sizeof(start_code) : 0;
const unsigned mb_count = s->mb_width * (s->mb_height >> v->field_mode);
DXVA_SliceInfo *slice = NULL;
-void *dxva_data_ptr;
+void *dxva_data_ptr = NULL;
uint8_t *dxva_data, *current, *end;
unsigned dxva_size;
unsigned padding;
@@ -224,6 +224,9 @@ static int commit_bitstream_and_slice_buffer(AVCodecContext
*avctx,
}
#endif
+if (!dxva_data_ptr)
+return -1;
+
dxva_data = dxva_data_ptr;
current = dxva_data;
end = dxva_data + dxva_size;
diff --git a/libavcodec/dxva2_vp9.c b/libavcodec/dxva2_vp9.c
index ca8b3b136da..f4ab91c580b 100644
--- a/libavcodec/dxva2_vp9.c
+++ b/libavcodec/dxva2_vp9.c
@@ -172,7 +172,7 @@ static int commit_bitstream_and_slice_buffer(AVCodecContext
*avctx,
const VP9SharedContext *h = avctx->priv_data;
AVDXVAContext *ctx = DXVA_CONTEXT(avctx);
struct vp9_dxva2_picture_context *ctx_pic =
h->frames[CUR_FRAME].hwaccel_picture_private;
-void *dxva_data_ptr;
+void *dxva_data_ptr = NULL;
uint8_t *dxva_data;
unsigned dxva_size;
unsigned padding;
@@ -200,7 +200,7 @@ static int commit_bitstream_and_slice_buffer(AVCodecContext
*avctx,
dxva_data = dxva_data_ptr;
-if (ctx_pic->slice.SliceBytesInBuffer > dxva_size) {
+if (!dxva_data || ctx_pic->slice.SliceBytesInBuffer > dxva_size) {
av_log(avctx, AV_LOG_ERROR, "Failed to build bitstream");
return -1;
}
--
2.45.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To
[FFmpeg-devel] [PATCH 04/17] avcodec/dxva2: initialize hr in ff_dxva2_common_end_frame()
Fixes: CID1591924 Uninitialized scalar variable Fixes: CID1591938 Uninitialized scalar variable Sponsored-by: Sovereign Tech Fund Signed-off-by: Michael Niedermayer --- libavcodec/dxva2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c index 1a33c8bbac7..22ecd5acafe 100644 --- a/libavcodec/dxva2.c +++ b/libavcodec/dxva2.c @@ -906,7 +906,7 @@ int ff_dxva2_common_end_frame(AVCodecContext *avctx, AVFrame *frame, #endif DECODER_BUFFER_DESC *buffer = NULL, *buffer_slice = NULL; int result, runs = 0; -HRESULT hr; +HRESULT hr = -1; unsigned type; FFDXVASharedContext *sctx = DXVA_SHARED_CONTEXT(avctx); -- 2.45.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 03/17] avcodec/dxva2: initialize validate
Fixes: CID1591915 Uninitialized scalar variable
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavcodec/dxva2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
index 550369ba51f..1a33c8bbac7 100644
--- a/libavcodec/dxva2.c
+++ b/libavcodec/dxva2.c
@@ -269,7 +269,7 @@ static int dxva_get_decoder_guid(AVCodecContext *avctx,
void *service, void *sur
*decoder_guid = ff_GUID_NULL;
for (i = 0; dxva_modes[i].guid; i++) {
const dxva_mode *mode = _modes[i];
-int validate;
+int validate = 0;
if (!dxva_check_codec_compatibility(avctx, mode))
continue;
--
2.45.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 02/17] avcodec/dxva2: Initialize ConfigBitstreamRaw
Fixes: CID1591894 Uninitialized scalar variable
Fixes: CID1591906 Uninitialized scalar variable
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavcodec/dxva2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
index 75ca84d0fe0..550369ba51f 100644
--- a/libavcodec/dxva2.c
+++ b/libavcodec/dxva2.c
@@ -118,7 +118,7 @@ static int dxva_get_decoder_configuration(AVCodecContext
*avctx,
for (i = 0; i < cfg_count; i++) {
unsigned score;
-UINT ConfigBitstreamRaw;
+UINT ConfigBitstreamRaw = 0;
GUID guidConfigBitstreamEncryption;
#if CONFIG_D3D11VA
--
2.45.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 01/17] avcodec/dxva2: Initialize dxva_size and check it
Fixes: CID1591878 Uninitialized scalar variable
Fixes: CID1591928 Uninitialized pointer read
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavcodec/dxva2.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
index 6eb66c02e40..75ca84d0fe0 100644
--- a/libavcodec/dxva2.c
+++ b/libavcodec/dxva2.c
@@ -806,7 +806,7 @@ int ff_dxva2_commit_buffer(AVCodecContext *avctx,
unsigned type, const void *data, unsigned size,
unsigned mb_count)
{
-void *dxva_data;
+void *dxva_data = NULL;
unsigned dxva_size;
int result;
HRESULT hr = 0;
@@ -828,7 +828,7 @@ int ff_dxva2_commit_buffer(AVCodecContext *avctx,
type, (unsigned)hr);
return -1;
}
-if (size <= dxva_size) {
+if (dxva_data && size <= dxva_size) {
memcpy(dxva_data, data, size);
#if CONFIG_D3D11VA
--
2.45.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 v2] avformat/hls: update current segment reference before use
Kacper Michajłow writes:
> It may be invalidated by the time it is used.
>
> Fixes use after free when accessing current segment.
>
> Fixes: #10825
> Signed-off-by: Kacper Michajłow
> ---
> libavformat/hls.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index 214a99c7ba..62473a15dd 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -2099,6 +2099,7 @@ static int hls_read_header(AVFormatContext *s)
> * If encryption scheme is SAMPLE-AES and audio setup information is
> present in external audio track,
> * use that information to find the media format, otherwise probe
> input data
> */
> +seg = current_segment(pls);
> if (seg && seg->key_type == KEY_SAMPLE_AES &&
> pls->is_id3_timestamped &&
> pls->audio_setup_info.codec_id != AV_CODEC_ID_NONE) {
> av_assert1(pls->audio_setup_info.codec_id == AV_CODEC_ID_AAC ||
> @@ -2127,6 +2128,7 @@ static int hls_read_header(AVFormatContext *s)
> av_free(url);
> }
>
> +seg = current_segment(pls);
> if (seg && seg->key_type == KEY_SAMPLE_AES) {
> if (strstr(in_fmt->name, "mov")) {
> char key[33];
> @@ -2173,6 +2175,7 @@ static int hls_read_header(AVFormatContext *s)
> * on us if they want to.
> */
> if (pls->is_id3_timestamped || (pls->n_renditions > 0 &&
> pls->renditions[0]->type == AVMEDIA_TYPE_AUDIO)) {
> +seg = current_segment(pls);
> if (seg && seg->key_type == KEY_SAMPLE_AES &&
> pls->audio_setup_info.setup_data_length > 0 &&
> pls->ctx->nb_streams == 1)
> ret =
> ff_hls_senc_parse_audio_setup_info(pls->ctx->streams[0],
> >audio_setup_info);
This fixes several twitch.tv streams which crash for me, same as in the
ticket. If no one has any comments I will push on Tuesday.
--
jd
___
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 01/10] channel_layout: add new channel positions supported by xHE-AAC
On 26/05/2024 22:51, Marton Balint wrote:
On Sun, 26 May 2024, Lynne via ffmpeg-devel wrote:
On 25/05/2024 08:10, Marton Balint wrote:
On Sat, 25 May 2024, Lynne via ffmpeg-devel wrote:
apichanges will be updated upon merging, as well as a version bump.
---
libavutil/channel_layout.h | 4
1 file changed, 4 insertions(+)
diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
index 8a078d1601..4e19bbbd9e 100644
--- a/libavutil/channel_layout.h
+++ b/libavutil/channel_layout.h
@@ -79,6 +79,10 @@ enum AVChannel {
AV_CHAN_BOTTOM_FRONT_CENTER,
AV_CHAN_BOTTOM_FRONT_LEFT,
AV_CHAN_BOTTOM_FRONT_RIGHT,
+ AV_CHAN_SURROUND_LEFT,
+ AV_CHAN_SURROUND_RIGHT,
You want to add a channel ID for Surround or Side Surround? Because
based
on the subsequent AAC patch you want to add it for side surround,
but then
the AV_CHAN_SURROUND name is confusing, since we are mapping
Surround to
AV_CHAN_SIDE. So I suggest using AV_CHAN_SIDE_SURROUND_LEFT/RIGHT
instead.
+ AV_CHAN_TOP_SURROUND_LEFT,
+ AV_CHAN_TOP_SURROUND_RIGHT,
You will need to extend the channel_names[] array in
channel_layout.c with
the newly added channel IDs.
Thanks, changed locally.
Planning on merging this in 2 days unless there are more comments.
Can you post the updated version of this patch? It is not entirely clear
what you added, or e.g. what abbriviation you planning to use for the
new channel IDs. Also I noticed one more thing, you also need to add the
AV_CH_* variants for the new IDs.
Sure, posted.
I went with exactly what you wrote.
3 days for new API such as this is a bit short, and if your AAC patches
depend on it, I suggest you wait a few more days.
...its an enum entry. Do you want a design document and a proposal?
You could talk to the person who did the research about it, JEEB.
Why wait at all? There's only you and JEEB that care about channel
layouts, you can review it and give it an LGTM. There's no reason to
wait for days, that is not how reviewing is supposed to work.
The decoder doesn't depend on it, I have fallback code. I've been
waiting for the channel layout situation to be resolved.
OpenPGP_0xA2FEA5F03F034464.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v4 01/10] channel_layout: add new channel positions supported by xHE-AAC
apichanges will be updated upon merging, as well as a version bump.
---
libavutil/channel_layout.c | 4
libavutil/channel_layout.h | 8
2 files changed, 12 insertions(+)
diff --git a/libavutil/channel_layout.c b/libavutil/channel_layout.c
index 98839b7250..2d6963b6df 100644
--- a/libavutil/channel_layout.c
+++ b/libavutil/channel_layout.c
@@ -75,6 +75,10 @@ static const struct channel_name channel_names[] = {
[AV_CHAN_BOTTOM_FRONT_CENTER ] = { "BFC", "bottom front center" },
[AV_CHAN_BOTTOM_FRONT_LEFT] = { "BFL", "bottom front left" },
[AV_CHAN_BOTTOM_FRONT_RIGHT ] = { "BFR", "bottom front right"},
+[AV_CHAN_SIDE_SURROUND_LEFT ] = { "SSL", "side surround left"},
+[AV_CHAN_SIDE_SURROUND_RIGHT ] = { "SSR", "side surround right" },
+[AV_CHAN_TOP_SURROUND_LEFT] = { "TTL", "top surround left" },
+[AV_CHAN_TOP_SURROUND_RIGHT ] = { "TTR", "top surround right"},
};
void av_channel_name_bprint(AVBPrint *bp, enum AVChannel channel_id)
diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
index b26b601065..6625313cc5 100644
--- a/libavutil/channel_layout.h
+++ b/libavutil/channel_layout.h
@@ -79,6 +79,10 @@ enum AVChannel {
AV_CHAN_BOTTOM_FRONT_CENTER,
AV_CHAN_BOTTOM_FRONT_LEFT,
AV_CHAN_BOTTOM_FRONT_RIGHT,
+AV_CHAN_SIDE_SURROUND_LEFT,
+AV_CHAN_SIDE_SURROUND_RIGHT,
+AV_CHAN_TOP_SURROUND_LEFT,
+AV_CHAN_TOP_SURROUND_RIGHT,
/** Channel is empty can be safely skipped. */
AV_CHAN_UNUSED = 0x200,
@@ -195,6 +199,10 @@ enum AVChannelOrder {
#define AV_CH_BOTTOM_FRONT_CENTER(1ULL << AV_CHAN_BOTTOM_FRONT_CENTER )
#define AV_CH_BOTTOM_FRONT_LEFT (1ULL << AV_CHAN_BOTTOM_FRONT_LEFT)
#define AV_CH_BOTTOM_FRONT_RIGHT (1ULL << AV_CHAN_BOTTOM_FRONT_RIGHT )
+#define AV_CH_SIDE_SURROUND_LEFT (1ULL << AV_CHAN_SIDE_SURROUND_LEFT )
+#define AV_CH_SIDE_SURROUND_RIGHT(1ULL << AV_CHAN_SIDE_SURROUND_RIGHT )
+#define AV_CH_TOP_SURROUND_LEFT (1ULL << AV_CHAN_TOP_SURROUND_LEFT)
+#define AV_CH_TOP_SURROUND_RIGHT (1ULL << AV_CHAN_TOP_SURROUND_RIGHT )
/**
* @}
--
2.43.0.381.gb435a96ce8
___
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] fate: add tests for xHE-AAC
Starting off small with a few features. Samples and reference decoded files copied from the official ISO reference suite. FATE files: https://files.lynne.ee/xhe_refs/ --- tests/fate/aac.mak | 8 1 file changed, 8 insertions(+) diff --git a/tests/fate/aac.mak b/tests/fate/aac.mak index 817944773d..ff58392ad9 100644 --- a/tests/fate/aac.mak +++ b/tests/fate/aac.mak @@ -62,6 +62,14 @@ FATE_AAC += fate-aac-ap05_48 fate-aac-ap05_48: CMD = pcm -i $(TARGET_SAMPLES)/aac/ap05_48.mp4 fate-aac-ap05_48: REF = $(SAMPLES)/aac/ap05_48.s16 +FATE_AAC += fate-aac-fd_2_c1_ms_0x01 +fate-aac-fd_2_c1_ms_0x01: CMD = pcm -i $(TARGET_SAMPLES)/aac/Fd_2_c1_Ms_0x01.mp4 +fate-aac-fd_2_c1_ms_0x01: REF = $(SAMPLES)/aac/Fd_2_c1_Ms_0x01.s16 + +FATE_AAC += fate-aac-fd_2_c1_ms_0x04 +fate-aac-fd_2_c1_ms_0x04: CMD = pcm -i $(TARGET_SAMPLES)/aac/Fd_2_c1_Ms_0x04.mp4 +fate-aac-fd_2_c1_ms_0x04: REF = $(SAMPLES)/aac/Fd_2_c1_Ms_0x04.s16 + FATE_AAC += fate-aac-er_ad6000np_44_ep0 fate-aac-er_ad6000np_44_ep0: CMD = pcm -i $(TARGET_SAMPLES)/aac/er_ad6000np_44_ep0.mp4 fate-aac-er_ad6000np_44_ep0: REF = $(SAMPLES)/aac/er_ad6000np_44.s16 -- 2.43.0.381.gb435a96ce8 ___ 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 01/10] channel_layout: add new channel positions supported by xHE-AAC
On Sun, 26 May 2024, Lynne via ffmpeg-devel wrote:
On 25/05/2024 08:10, Marton Balint wrote:
On Sat, 25 May 2024, Lynne via ffmpeg-devel wrote:
apichanges will be updated upon merging, as well as a version bump.
---
libavutil/channel_layout.h | 4
1 file changed, 4 insertions(+)
diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
index 8a078d1601..4e19bbbd9e 100644
--- a/libavutil/channel_layout.h
+++ b/libavutil/channel_layout.h
@@ -79,6 +79,10 @@ enum AVChannel {
AV_CHAN_BOTTOM_FRONT_CENTER,
AV_CHAN_BOTTOM_FRONT_LEFT,
AV_CHAN_BOTTOM_FRONT_RIGHT,
+ AV_CHAN_SURROUND_LEFT,
+ AV_CHAN_SURROUND_RIGHT,
You want to add a channel ID for Surround or Side Surround? Because based
on the subsequent AAC patch you want to add it for side surround, but then
the AV_CHAN_SURROUND name is confusing, since we are mapping Surround to
AV_CHAN_SIDE. So I suggest using AV_CHAN_SIDE_SURROUND_LEFT/RIGHT instead.
+ AV_CHAN_TOP_SURROUND_LEFT,
+ AV_CHAN_TOP_SURROUND_RIGHT,
You will need to extend the channel_names[] array in channel_layout.c with
the newly added channel IDs.
Thanks, changed locally.
Planning on merging this in 2 days unless there are more comments.
Can you post the updated version of this patch? It is not entirely clear
what you added, or e.g. what abbriviation you planning to use for the new
channel IDs. Also I noticed one more thing, you also need to add the
AV_CH_* variants for the new IDs.
3 days for new API such as this is a bit short, and if your AAC
patches depend on it, I suggest you wait a few more days.
Thanks,
Marton
___
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] checkasm/lpc: test compute_autocorr
Le lauantaina 25. toukokuuta 2024, 14.58.53 EEST Rémi Denis-Courmont a écrit :
> --
> Change since previous version:
> - Disable test on x86, since the x86 optimisation fails
> with a suspiciously large and regular error with 10-20% probability.
> ---
> tests/checkasm/lpc.c | 54 ++--
> 1 file changed, 52 insertions(+), 2 deletions(-)
>
> diff --git a/tests/checkasm/lpc.c b/tests/checkasm/lpc.c
> index 592e34c03d..38810325ac 100644
> --- a/tests/checkasm/lpc.c
> +++ b/tests/checkasm/lpc.c
> @@ -16,6 +16,7 @@
> * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> */
>
> +#include "libavutil/avassert.h"
> #include "libavutil/mem_internal.h"
>
> #include "libavcodec/lpc.h"
> @@ -57,10 +58,50 @@ static void test_window(int len)
> bench_new(src, len, dst1);
> }
>
> +#if !ARCH_X86
> +static void test_compute_autocorr(ptrdiff_t len, int lag)
> +{
> +LOCAL_ALIGNED(32, double, src, [5000 + 2 + MAX_LPC_ORDER]);
> +LOCAL_ALIGNED(16, double, dst0, [MAX_LPC_ORDER + 1]);
> +LOCAL_ALIGNED(16, double, dst1, [MAX_LPC_ORDER + 1]);
> +
> +declare_func(void, const double *in, ptrdiff_t len, int lag, double
> *out); +
> +av_assert0(lag >= 0 && lag <= MAX_LPC_ORDER);
> +
> +for (int i = 0; i < MAX_LPC_ORDER; i++)
> +src[i] = 0.;
> +
> +src += MAX_LPC_ORDER;
> +
> +for (ptrdiff_t i = 0; i < len; i++) {
> +src[i] = (double)rnd() / (double)UINT_MAX;
> +}
> +
> +call_ref(src, len, lag, dst0);
> +call_new(src, len, lag, dst1);
> +
> +for (size_t i = 0; i < lag; i++) {
Should also check dst[lag] AFAIU.
> +if (!double_near_abs_eps(dst0[i], dst1[i], EPS)) {
> +fprintf(stderr, "%zu: %- .12f - %- .12f = % .12g\n",
> +i, dst0[i], dst1[i], dst0[i] - dst1[i]);
> +fail();
> +break;
> +}
> +}
> +
> +bench_new(src, len, lag, dst1);
> +}
> +#endif
> +
> void checkasm_check_lpc(void)
> {
> LPCContext ctx;
> -int len = rnd() % 5000;
> +int len = 2000 + (rnd() % 3000);
> +#if !ARCH_X86
> +static const int lags[] = { 10, 30, 32 };
> +#endif
> +
> ff_lpc_init(, 32, 16, FF_LPC_TYPE_DEFAULT);
>
> if (check_func(ctx.lpc_apply_welch_window, "apply_welch_window_even"))
> { @@ -72,6 +113,15 @@ void checkasm_check_lpc(void)
> test_window(len | 1);
> }
> report("apply_welch_window_odd");
> -
> ff_lpc_end();
> +
> +#if !ARCH_X86
> +for (size_t i = 0; i < FF_ARRAY_ELEMS(lags); i++) {
> +ff_lpc_init(, len, lags[i], FF_LPC_TYPE_DEFAULT);
> +if (check_func(ctx.lpc_compute_autocorr, "autocorr_%d", lags[i]))
> +test_compute_autocorr(len, lags[i]);
> +report("compute_autocorr_%d", lags[i]);
> +ff_lpc_end();
> +}
> +#endif
> }
--
レミ・デニ-クールモン
http://www.remlab.net/
___
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] lpc: rewrite lpc_compute_autocorr in external asm
On Sun, May 26, 2024 at 03:42:01AM +0200, Lynne via ffmpeg-devel wrote: > The inline asm function had issues running under checkasm. > So I came to finish what I started, and wrote the last part > of LPC computation in assembly. > --- > libavcodec/x86/lpc.asm| 91 +++ > libavcodec/x86/lpc_init.c | 87 - > 2 files changed, 100 insertions(+), 78 deletions(-) seems to break fate make: *** [tests/Makefile:311: fate-lavf-ogg] Error 1 make: *** [tests/Makefile:311: fate-iamf-stereo] Error 1 make: *** [tests/Makefile:311: fate-mov-mp4-iamf-stereo] Error 1 make: *** [tests/Makefile:311: fate-iamf-ambisonic_1] Error 1 make: *** [tests/Makefile:310: fate-mov-mp4-iamf-ambisonic_1] Error 1 make: *** [tests/Makefile:311: fate-mov-mp4-iamf-5_1_4] Error 1 make: *** [tests/Makefile:311: fate-iamf-5_1_4] Error 1 make: *** [tests/Makefile:311: fate-iamf-7_1_4] Error 1 make: *** [tests/Makefile:311: fate-mov-mp4-iamf-7_1_4] Error 1 make: *** [tests/Makefile:311: fate-cover-art-flac-remux] Error 1 thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you fake or manipulate statistics in a paper in physics you will never get a job again. If you fake or manipulate statistics in a paper in medicin you will get a job for life at the pharma industry. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 01/10] channel_layout: add new channel positions supported by xHE-AAC
On 25/05/2024 08:10, Marton Balint wrote:
On Sat, 25 May 2024, Lynne via ffmpeg-devel wrote:
apichanges will be updated upon merging, as well as a version bump.
---
libavutil/channel_layout.h | 4
1 file changed, 4 insertions(+)
diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
index 8a078d1601..4e19bbbd9e 100644
--- a/libavutil/channel_layout.h
+++ b/libavutil/channel_layout.h
@@ -79,6 +79,10 @@ enum AVChannel {
AV_CHAN_BOTTOM_FRONT_CENTER,
AV_CHAN_BOTTOM_FRONT_LEFT,
AV_CHAN_BOTTOM_FRONT_RIGHT,
+ AV_CHAN_SURROUND_LEFT,
+ AV_CHAN_SURROUND_RIGHT,
You want to add a channel ID for Surround or Side Surround? Because
based on the subsequent AAC patch you want to add it for side surround,
but then the AV_CHAN_SURROUND name is confusing, since we are mapping
Surround to AV_CHAN_SIDE. So I suggest using
AV_CHAN_SIDE_SURROUND_LEFT/RIGHT instead.
+ AV_CHAN_TOP_SURROUND_LEFT,
+ AV_CHAN_TOP_SURROUND_RIGHT,
You will need to extend the channel_names[] array in channel_layout.c
with the newly added channel IDs.
Thanks, changed locally.
Planning on merging this in 2 days unless there are more comments.
OpenPGP_0xA2FEA5F03F034464.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 01/12] avutil/avassert: Add av_unreachable and av_assume() macros
Hi On Sun, May 26, 2024 at 02:59:35AM +0200, Andreas Rheinhardt wrote: > Michael Niedermayer: > > Hi > > > > On Fri, May 24, 2024 at 11:58:21PM +0200, Andreas Rheinhardt wrote: > >> Useful to let the compiler and static analyzers know that > >> something is unreachable without adding an av_assert > >> (which would be either dead for the compiler or add runtime > >> overhead) for this. > >> > >> Signed-off-by: Andreas Rheinhardt > >> --- > >> I can add more macros if it is desired to differentiate between > >> ASSERT_LEVEL == 1 and ASSERT_LEVEL > 1. > >> > >> doc/APIchanges | 3 +++ > >> libavutil/avassert.h | 33 + > >> 2 files changed, 36 insertions(+) > >> > >> diff --git a/doc/APIchanges b/doc/APIchanges > >> index 60f056b863..5a3ae37999 100644 > >> --- a/doc/APIchanges > >> +++ b/doc/APIchanges > >> @@ -2,6 +2,9 @@ The last version increases of all libraries were on > >> 2024-03-07 > >> > >> API changes, most recent first: > >> > >> +2024-05-24 - xx - lavu 59.xx.100 - avassert.h > >> + Add av_unreachable and av_assume() macros. > >> + > >> 2024-05-23 - xx - lavu 59.20.100 - channel_layout.h > >>Add av_channel_layout_ambisonic_order(). > >> > >> diff --git a/libavutil/avassert.h b/libavutil/avassert.h > >> index 1895fb7551..41e29c7687 100644 > >> --- a/libavutil/avassert.h > >> +++ b/libavutil/avassert.h > >> @@ -31,6 +31,7 @@ > >> #ifdef HAVE_AV_CONFIG_H > >> # include "config.h" > >> #endif > >> +#include "attributes.h" > >> #include "log.h" > >> #include "macros.h" > >> > >> @@ -68,6 +69,38 @@ > >> #define av_assert2_fpu() ((void)0) > >> #endif > >> > >> +/** > >> + * Asserts that are used as compiler optimization hints depending > >> + * upon ASSERT_LEVEL and NBDEBUG. > >> + * > >> + * Undefined behaviour occurs if execution reaches a point marked > >> + * with av_unreachable or if a condition used with av_assume() > >> + * is false. > >> + * > >> + * The condition used with av_assume() should not have side-effects > >> + * and should be visible to the compiler. > >> + */ > > > > this feels wrong > > > > We have 3 assert functions > > > > one for security relevant code or other things we always want to check and > > not play around > > > > one for speed relevant code where we dont want to check in production code. > > But may want > > to do checks if we are debuging. > > > > and one for the cases between > > > > > > What is an assert ? Its a statement about a condition that is true unless > > the code > > is broken. Its never correct to use an assert to check for a condition that > > is known > > to be false for some input. > > So a assert really already is either > > > > A. Check, print, abort > > or > > B. undefined if false > > > > But if an assert already is "undefined if false" then what you add is not > > usefull, just add the compiler specific "assume" code to the disabled > > asserts > > 1. So you want me to change the disabled asserts into a "if (!(cond)) > __builtin_unreachable();" (like dav1d does)? This is problematic, > because asserts (as they are used right now) contain no requirement at > all that the condition be visible to the compiler; > it may contain > function calls that the compiler cannot elide (unless it is an LTO > compiler, but even they stop at library boundaries). would that break anything ? > While we could of > course look through our own asserts and change them, we must not simply > do so for our users. the feature can be delayed outside our code until the next API bump > (The PutBits API has checks for the buffer being too small: > av_log(NULL, AV_LOG_ERROR, "Internal error, put_bits buffer > too small\n"); > av_assert2(0); > If the av_assert2 is changed into an __builtin_unreachable() in case the > latter assert is disabled, then this defeats the purpose of this check. indeed but finding this now, gives the oppertunity to improve this code > This shows that all our asserts need to be checked and be potentially > changed to be consistent with using them as optimization hints.) maybe but introducing a redundant "assert" isnt avoiding that. You still either check everything or you dont check and you either use unchecked cases for optimization or only checked cases. Its just more assert like macros > > 2. It is useful, it is just a different usecase: Here the focus is not > on correctness, but on telling the compiler something that is presumed > to be beneficial for performance. > > > This would also keep the API simpler > > IMO using av_unreachable instead of av_assertX(0) expresses the intent > better (so for me the current usage feels wrong). Same for av_assume > (see 2. for the intent). I dont agree if we do add av_unreachable() we will for debuging need a way to disabled it and print something, same as av_assert*() already does so it really is a av_assert*() just with a different name about the name, well we already use
Re: [FFmpeg-devel] [PATCH 1/2] libavfilter/signature_lookup: fix possible division by zero
On Sun, May 26, 2024 at 05:08:09PM +0200, Gerion Entrup wrote:
> Am Freitag, 24. Mai 2024, 23:03:37 MESZ schrieb Michael Niedermayer:
> > On Fri, May 24, 2024 at 12:33:11PM +0200, Gerion Entrup wrote:
> > > Am Dienstag, 7. Mai 2024, 19:46:28 MESZ schrieb Michael Niedermayer:
> > > > On Mon, May 06, 2024 at 12:30:39AM +0200, Gerion Entrup wrote:
> > > > > ---
> > > > > libavfilter/signature_lookup.c | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/libavfilter/signature_lookup.c
> > > > > b/libavfilter/signature_lookup.c
> > > > > index a0ca818a9b..b39a3e225b 100644
> > > > > --- a/libavfilter/signature_lookup.c
> > > > > +++ b/libavfilter/signature_lookup.c
> > > > > @@ -128,7 +128,7 @@ static int get_jaccarddist(SignatureContext *sc,
> > > > > CoarseSignature *first, CoarseS
> > > > > int jaccarddist, i, composdist = 0, cwthcount = 0;
> > > > > for (i = 0; i < 5; i++) {
> > > > > if ((jaccarddist = intersection_word(first->data[i],
> > > > > second->data[i])) > 0) {
> > > > > -jaccarddist /= union_word(first->data[i],
> > > > > second->data[i]);
> > > > > +jaccarddist /= FFMAX(union_word(first->data[i],
> > > > > second->data[i]), 1);
> > > > > }
> > > >
> > > > for which input data does this cause a division by 0 ?
> > >
> > > Sorry for the late answer. I missed your mail somehow.
> > > union_word counts the amount of one bits that are created when you are
> > > "or"ing
> > > the course signatures. So, when the underlying videos are so different
> > > that all
> > > bits of the created signatures are different, the "or"-operator will
> > > always
> > > return 0 and so also its sum (I have not tested this).
> >
> > the division only occurs if jaccarddist > 0
> >
> > basically what iam asking is for which A and B do we have
> > (A) != 0 && (A|B) == 0
> > or am i misreading the code ?
>
> Hmm, valid point. Then, this patch should be unnecessary.
> Should I send 2/2 again without 1/2 then?
I didnt compare the code to the specification but if its a bugfix
then yes of course
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] libavfilter/signature_lookup: fix possible division by zero
Am Freitag, 24. Mai 2024, 23:03:37 MESZ schrieb Michael Niedermayer:
> On Fri, May 24, 2024 at 12:33:11PM +0200, Gerion Entrup wrote:
> > Am Dienstag, 7. Mai 2024, 19:46:28 MESZ schrieb Michael Niedermayer:
> > > On Mon, May 06, 2024 at 12:30:39AM +0200, Gerion Entrup wrote:
> > > > ---
> > > > libavfilter/signature_lookup.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/libavfilter/signature_lookup.c
> > > > b/libavfilter/signature_lookup.c
> > > > index a0ca818a9b..b39a3e225b 100644
> > > > --- a/libavfilter/signature_lookup.c
> > > > +++ b/libavfilter/signature_lookup.c
> > > > @@ -128,7 +128,7 @@ static int get_jaccarddist(SignatureContext *sc,
> > > > CoarseSignature *first, CoarseS
> > > > int jaccarddist, i, composdist = 0, cwthcount = 0;
> > > > for (i = 0; i < 5; i++) {
> > > > if ((jaccarddist = intersection_word(first->data[i],
> > > > second->data[i])) > 0) {
> > > > -jaccarddist /= union_word(first->data[i], second->data[i]);
> > > > +jaccarddist /= FFMAX(union_word(first->data[i],
> > > > second->data[i]), 1);
> > > > }
> > >
> > > for which input data does this cause a division by 0 ?
> >
> > Sorry for the late answer. I missed your mail somehow.
> > union_word counts the amount of one bits that are created when you are
> > "or"ing
> > the course signatures. So, when the underlying videos are so different that
> > all
> > bits of the created signatures are different, the "or"-operator will always
> > return 0 and so also its sum (I have not tested this).
>
> the division only occurs if jaccarddist > 0
>
> basically what iam asking is for which A and B do we have
> (A) != 0 && (A|B) == 0
> or am i misreading the code ?
Hmm, valid point. Then, this patch should be unnecessary.
Should I send 2/2 again without 1/2 then?
Gerion
signature.asc
Description: This is a digitally signed message part.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/5] lavc/vp9dsp: R-V V mc bilin h v
Le tiistaina 21. toukokuuta 2024, 21.36.33 EEST flow gg a écrit : > Do macros definition also need a comma? Indeed not. I'd rather be safe than sorry though. -- レミ・デニ-クールモン http://www.remlab.net/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/5] lavc/vp9dsp: R-V V mc avg
Le sunnuntaina 26. toukokuuta 2024, 15.27.55 EEST flow gg a écrit : > Hi, maybe we can prioritize this revert: > https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/0c1304ae11b0361ede055ee8ffc6 > e83529468c73 Using [PATCH v2 1/5] lavc/vp9dsp: R-V V mc avg to avoid > conflicts with other patches. You can revert the patch and then provide a better version in a patch series. However it may be prefereable to squash the revert and the improved version (and describe the improvements in the commit log). -- Rémi Denis-Courmont http://www.remlab.net/ ___ 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] checkasm: add h263dsp.{h,v}_loop_filter
Le lauantaina 25. toukokuuta 2024, 19.30.44 EEST James Almer a écrit :
> On 5/18/2024 3:44 PM, Rémi Denis-Courmont wrote:
> > ---
> >
> > tests/checkasm/Makefile | 1 +
> > tests/checkasm/checkasm.c | 3 ++
> > tests/checkasm/checkasm.h | 1 +
> > tests/checkasm/h263dsp.c | 62 +++
> > tests/fate/checkasm.mak | 1 +
> > 5 files changed, 68 insertions(+)
> > create mode 100644 tests/checkasm/h263dsp.c
> >
> > diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
> > index 92624aab0a..1dc770e9da 100644
> > --- a/tests/checkasm/Makefile
> > +++ b/tests/checkasm/Makefile
> > @@ -7,6 +7,7 @@ AVCODECOBJS-$(CONFIG_BSWAPDSP) += bswapdsp.o
> >
> > AVCODECOBJS-$(CONFIG_FDCTDSP) += fdctdsp.o
> > AVCODECOBJS-$(CONFIG_FMTCONVERT)+= fmtconvert.o
> > AVCODECOBJS-$(CONFIG_G722DSP) += g722dsp.o
> >
> > +AVCODECOBJS-$(CONFIG_H263DSP) += h263dsp.o
> >
> > AVCODECOBJS-$(CONFIG_H264CHROMA)+= h264chroma.o
> > AVCODECOBJS-$(CONFIG_H264DSP) += h264dsp.o
> > AVCODECOBJS-$(CONFIG_H264PRED) += h264pred.o
> >
> > diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
> > index 31ca9f6e2b..92c9e44df7 100644
> > --- a/tests/checkasm/checkasm.c
> > +++ b/tests/checkasm/checkasm.c
> > @@ -118,6 +118,9 @@ static const struct {
> >
> > #if CONFIG_G722DSP
> >
> > { "g722dsp", checkasm_check_g722dsp },
> >
> > #endif
> >
> > +#if CONFIG_H263DSP
> > +{ "h263dsp", checkasm_check_h263dsp },
> > +#endif
> >
> > #if CONFIG_H264CHROMA
> >
> > { "h264chroma", checkasm_check_h264chroma },
> >
> > #endif
> >
> > diff --git a/tests/checkasm/checkasm.h b/tests/checkasm/checkasm.h
> > index 07fcc751ff..334fb79734 100644
> > --- a/tests/checkasm/checkasm.h
> > +++ b/tests/checkasm/checkasm.h
> > @@ -91,6 +91,7 @@ void checkasm_check_flacdsp(void);
> >
> > void checkasm_check_float_dsp(void);
> > void checkasm_check_fmtconvert(void);
> > void checkasm_check_g722dsp(void);
> >
> > +void checkasm_check_h263dsp(void);
> >
> > void checkasm_check_h264chroma(void);
> > void checkasm_check_h264dsp(void);
> > void checkasm_check_h264pred(void);
> >
> > diff --git a/tests/checkasm/h263dsp.c b/tests/checkasm/h263dsp.c
> > new file mode 100644
> > index 00..2d0957a90b
> > --- /dev/null
> > +++ b/tests/checkasm/h263dsp.c
> > @@ -0,0 +1,62 @@
> > +/*
> > + * Copyright (c) 2024 Rémi Denis-Courmont
> > + *
> > + * This file is part of FFmpeg.
> > + *
> > + * FFmpeg is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + *
> > + * FFmpeg is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public License
> > along
> > + * with FFmpeg; if not, write to the Free Software Foundation, Inc.,
> > + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> > + */
> > +
> > +#include
> > +
> > +#include "checkasm.h"
> > +
> > +#include "libavcodec/h263dsp.h"
> > +#include "libavutil/mem.h"
> > +#include "libavutil/mem_internal.h"
> > +
> > +typedef void (*filter)(uint8_t *src, int stride, int qscale);
> > +
> > +static void check_loop_filter(char dim, filter func)
> > +{
> > +LOCAL_ALIGNED_16(uint8_t, buf0, [32 * 32]);
> > +LOCAL_ALIGNED_16(uint8_t, buf1, [32 * 32]);
> > +int qscale = rnd() % 32;
> > +
> > +declare_func_emms(AV_CPU_FLAG_MMX, void, uint8_t *, int, int);
> > +
> > +for (size_t y = 0; y < 32; y++)
> > +for (size_t x = 0; x < 32; x++)
> > +buf0[y * 32 + x] = buf1[y * 32 + x] = rnd();
>
> for (size_t i = 0; i < 32 * 32; i += 4) {
> uint32_t r = rnd();
> AV_WN32A(buf0 + i, r);
> AV_WN32A(buf1 + i, r);
> }
I can do it but is this really a good idea? Optimising test cases feels kinda
vain to me. But more importantly, a better and less random test would
presumably need to deal with invididual sample values, so this is actually
adding one more hurdle to improving the code later. Not that I'd know any
volunteer to do that.
--
レミ・デニ-クールモン
http://www.remlab.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/5] lavc/vp9dsp: R-V V mc avg
Hi, maybe we can prioritize this revert: https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/0c1304ae11b0361ede055ee8ffc6e83529468c73 Using [PATCH v2 1/5] lavc/vp9dsp: R-V V mc avg to avoid conflicts with other patches. flow gg 于2024年5月24日周五 14:13写道： > I want to update the VP9 bilin load, just like you did with VP8, but it > seems like this patch（[PATCH v2 1/5] lavc/vp9dsp: R-V V mc avg） doesn't > merge the current updates here but merges the previous version instead, so > the subsequent patches will have conflicts. > > flow gg 于2024年5月22日周三 01:15写道： > >> > Please put commas between operands. >> > This should probably be ff_avg_vp9 or something slightly more specific. >> >> Updated here. >> >> 于2024年5月22日周三 01:14写道： >> >>> From: sunyuechi >>> >>> C908: >>> vp9_avg4_8bpp_c: 1.2 >>> vp9_avg4_8bpp_rvv_i64: 1.0 >>> vp9_avg8_8bpp_c: 3.7 >>> vp9_avg8_8bpp_rvv_i64: 1.5 >>> vp9_avg16_8bpp_c: 14.7 >>> vp9_avg16_8bpp_rvv_i64: 3.5 >>> vp9_avg32_8bpp_c: 57.7 >>> vp9_avg32_8bpp_rvv_i64: 10.0 >>> vp9_avg64_8bpp_c: 229.0 >>> vp9_avg64_8bpp_rvv_i64: 31.7 >>> --- >>> libavcodec/riscv/Makefile | 3 +- >>> libavcodec/riscv/vp9_mc_rvv.S | 58 ++ >>> libavcodec/riscv/vp9dsp.h | 4 +-- >>> libavcodec/riscv/vp9dsp_init.c | 18 +++ >>> 4 files changed, 80 insertions(+), 3 deletions(-) >>> create mode 100644 libavcodec/riscv/vp9_mc_rvv.S >>> >>> diff --git a/libavcodec/riscv/Makefile b/libavcodec/riscv/Makefile >>> index 07d5c2915d..67e198d754 100644 >>> --- a/libavcodec/riscv/Makefile >>> +++ b/libavcodec/riscv/Makefile >>> @@ -69,6 +69,7 @@ RVV-OBJS-$(CONFIG_VP8DSP) += riscv/vp8dsp_rvv.o >>> OBJS-$(CONFIG_VP9_DECODER) += riscv/vp9dsp_init.o >>> RV-OBJS-$(CONFIG_VP9_DECODER) += riscv/vp9_intra_rvi.o \ >>> riscv/vp9_mc_rvi.o >>> -RVV-OBJS-$(CONFIG_VP9_DECODER) += riscv/vp9_intra_rvv.o >>> +RVV-OBJS-$(CONFIG_VP9_DECODER) += riscv/vp9_intra_rvv.o \ >>> + riscv/vp9_mc_rvv.o >>> OBJS-$(CONFIG_VORBIS_DECODER) += riscv/vorbisdsp_init.o >>> RVV-OBJS-$(CONFIG_VORBIS_DECODER) += riscv/vorbisdsp_rvv.o >>> diff --git a/libavcodec/riscv/vp9_mc_rvv.S >>> b/libavcodec/riscv/vp9_mc_rvv.S >>> new file mode 100644 >>> index 00..7cb38ec94a >>> --- /dev/null >>> +++ b/libavcodec/riscv/vp9_mc_rvv.S >>> @@ -0,0 +1,58 @@ >>> +/* >>> + * Copyright (c) 2024 Institue of Software Chinese Academy of Sciences >>> (ISCAS). >>> + * >>> + * This file is part of FFmpeg. >>> + * >>> + * FFmpeg is free software; you can redistribute it and/or >>> + * modify it under the terms of the GNU Lesser General Public >>> + * License as published by the Free Software Foundation; either >>> + * version 2.1 of the License, or (at your option) any later version. >>> + * >>> + * FFmpeg is distributed in the hope that it will be useful, >>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU >>> + * Lesser General Public License for more details. >>> + * >>> + * You should have received a copy of the GNU Lesser General Public >>> + * License along with FFmpeg; if not, write to the Free Software >>> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA >>> 02110-1301 USA >>> + */ >>> + >>> +#include "libavutil/riscv/asm.S" >>> + >>> +.macro vsetvlstatic8 len an maxlen mn=m4 >>> +.if \len == 4 >>> +vsetivlizero, \len, e8, mf4, ta, ma >>> +.elseif \len == 8 >>> +vsetivlizero, \len, e8, mf2, ta, ma >>> +.elseif \len == 16 >>> +vsetivlizero, \len, e8, m1, ta, ma >>> +.elseif \len == 32 >>> +li \an, \len >>> +vsetvli zero, \an, e8, m2, ta, ma >>> +.elseif \len == 64 >>> +li \an, \maxlen >>> +vsetvli zero, \an, e8, \mn, ta, ma >>> +.endif >>> +.endm >>> + >>> +.macro copy_avg len >>> +func ff_vp9_avg\len\()_rvv, zve32x >>> +csrwi vxrm, 0 >>> +vsetvlstatic8 \len, t0, 64 >>> +1: >>> +vle8.v v8, (a2) >>> +vle8.v v16, (a0) >>> +vaaddu.vv v8, v8, v16 >>> +addia4, a4, -1 >>> +vse8.v v8, (a0) >>> +add a2, a2, a3 >>> +add a0, a0, a1 >>> +bneza4, 1b >>> +ret >>> +endfunc >>> +.endm >>> + >>> +.irp len, 64, 32, 16, 8, 4 >>> +copy_avg \len >>> +.endr >>> diff --git a/libavcodec/riscv/vp9dsp.h b/libavcodec/riscv/vp9dsp.h >>> index 79330b4968..ff8431591c 100644 >>> --- a/libavcodec/riscv/vp9dsp.h >>> +++ b/libavcodec/riscv/vp9dsp.h >>> @@ -138,11 +138,11 @@ void ff_avg_bilin_##SIZE##hv_rvv(uint8_t *dst, >>> ptrdiff_t dststride,\ >>> int h, int mx, int my); >>> >>> #define VP9_COPY_AVG_RISCV_RVV_FUNC(SIZE) \ >>> -void ff_copy##SIZE##_rvv(uint8_t *dst, ptrdiff_t dststride,\ >>> +void
[FFmpeg-devel] [PATCH] lavc/vp8dsp: disable EPEL HV on RV128
RV128 is mostly scifi at this point, so we can just disable it here (the EPEL HV prologue/epilogue do not save 128-bit registers). --- libavcodec/riscv/vp8dsp_init.c | 3 ++- libavcodec/riscv/vp8dsp_rvv.S | 2 ++ 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/libavcodec/riscv/vp8dsp_init.c b/libavcodec/riscv/vp8dsp_init.c index 86927907e0..92e3366290 100644 --- a/libavcodec/riscv/vp8dsp_init.c +++ b/libavcodec/riscv/vp8dsp_init.c @@ -97,7 +97,7 @@ av_cold void ff_vp78dsp_init_riscv(VP8DSPContext *c) c->put_vp8_epel_pixels_tab[0][1][0] = ff_put_vp8_epel16_v4_rvv; c->put_vp8_epel_pixels_tab[1][1][0] = ff_put_vp8_epel8_v4_rvv; c->put_vp8_epel_pixels_tab[2][1][0] = ff_put_vp8_epel4_v4_rvv; - +#if __riscv_xlen <= 64 c->put_vp8_epel_pixels_tab[0][2][2] = ff_put_vp8_epel16_h6v6_rvv; c->put_vp8_epel_pixels_tab[1][2][2] = ff_put_vp8_epel8_h6v6_rvv; c->put_vp8_epel_pixels_tab[2][2][2] = ff_put_vp8_epel4_h6v6_rvv; @@ -110,6 +110,7 @@ av_cold void ff_vp78dsp_init_riscv(VP8DSPContext *c) c->put_vp8_epel_pixels_tab[0][1][2] = ff_put_vp8_epel16_h6v4_rvv; c->put_vp8_epel_pixels_tab[1][1][2] = ff_put_vp8_epel8_h6v4_rvv; c->put_vp8_epel_pixels_tab[2][1][2] = ff_put_vp8_epel4_h6v4_rvv; +#endif } #endif #endif diff --git a/libavcodec/riscv/vp8dsp_rvv.S b/libavcodec/riscv/vp8dsp_rvv.S index c79a8afacf..292e5951e9 100644 --- a/libavcodec/riscv/vp8dsp_rvv.S +++ b/libavcodec/riscv/vp8dsp_rvv.S @@ -321,8 +321,10 @@ epel \len 6 h epel \len 4 h epel \len 6 v epel \len 4 v +#if __riscv_xlen <= 64 epel_hv \len 6 6 epel_hv \len 4 4 epel_hv \len 6 4 epel_hv \len 4 6 +#endif .endr -- 2.45.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 v4 1/4] doc: Explain what "context" means
It feels like we've got through most of the mid-level "how FFmpeg works" stuff, and now we're left with language choices (e.g "options" vs. "introspection") and philosophical discussions (e.g. the relationship between contexts and OOP). It's probably best to philosophise first, then come back to language. This message has been sent as a reply to one specific message, but is actually springboarding off messages from two sub-threads. Hopefully that will keep the big questions contained in one place. On Sat, May 25, 2024 at 11:49:48AM +0200, Stefano Sabatini wrote: > What perplexes me is that "context" is not part of the standard OOP > jargon, so this is probably adding more to the confusion. This actually speaks to a more fundamental issue about how we learn. To be clear, everything I'm about to describe applies every human that ever lived, but starting with this message makes it easier to explain (for reasons that will hopefully become obvious). When you ask why "context" is not part of OOP jargon, one could equally ask why "object" isn't part of FFmpeg jargon. The document hints at some arguments: their lifetime stages are different, their rules are enforced at the language vs. community level, OOP encourages homogenous interfaces while FFmpeg embraces unique interfaces that precisely suit each use case, and so on. But the honest answer is much simpler - humans are lazy, and we want the things we learn today to resemble the things we learnt yesterday. Put another way - if we had infinite time every day, we could probably write an object-oriented interface to FFmpeg. But our time is sadly finite so we stick with the thing that's proven to work. Similarly, if our readers had infinite free time every day, they could probably learn a completely new approach to programming. But their time is finite, so they stick to what they know. That means people reading this document aren't just passively soaking up information, they're looking for shortcuts that fit their assumptions. And as anyone that's ever seen a political discussion can tell you, humans are *really good* at finding shortcuts that fit their assumptions. For example, when an OOP developer sees the words "alloc" and "init", they will assume these map precisely to OOP allocators and initializers. One reason for the long section about context lifetimes is because it needs to meet them where they are, then walk them step-by-step to a better place. Aside: if FFmpeg had a blog, I could turn this discussion into a great post called something like "reflections on object- vs. context-oriented development". But the project's voice is more objective than that, so this document is limited to discussing the subset of issues that relate specifically to the FFmpeg API. On Sat, May 25, 2024 at 01:00:14PM +0200, Stefano Sabatini wrote: > > +Some functions fit awkwardly within FFmpeg's context idiom. For example, > > +av_ambient_viewing_environment_create_side_data() creates an > > +AVAmbientViewingEnvironment context, then adds it to the side-data of an > > +AVFrame context. > > To go back to this unfitting example, can you state what would be > fitting in this case? "Awkwardly" probably isn't the right word to use, but that's a language choice we can come back to. The problem with FFmpeg's interface isn't that any one part is illogical, it's that different parts of the interface follow incompatible logic. It's hard to give specific examples, because any given learner's journey looks like a random walk through the API, and you can always say "well nobody else would have that problem". But if everyone has a different problem, that means everyone has *a* problem, even though there's no localised code fix. For sake of argument, let's imagine a user who was a world-leading expert in Microsoft QBasic in the eighties, then fell into a forty-year coma and woke up in front of the FFmpeg documentation. In other words, a highly adept programmer with zero knowledge of programming conventions more recent than "a function is a special type of subroutine for returning a value". Their journey might look like... 1. there's this thing called "context", and some functions "have" contexts 2. sws_init_context() says "Initialize the swscaler context sws_context", and `sws_context` is a `SwsContext *`, so I think it has a SwsContext context 3. sws_alloc_context() says "Allocate an empty SwsContext", and it returns a `SwsContext *`, so I think it has the same context as sws_init_context() 4. avio_alloc_context() and avio_open2() are both variations on this theme, so I should look for creative ways to interpret things as "having" contexts 5. av_alloc_format_context() puts the type in the middle of the function name, so I should only treat prefixes as a weak signal 6. av_ambient_viewing_environment_create_side_data() allocates like an alloc, so I think the return value is the context; but it also operates on AVFrame in a way that affects related
Re: [FFmpeg-devel] [PATCH] configure: enable ffnvcodec, nvenc, nvdec for FreeBSD
On 26.05.2024 07:22, Brad Smith wrote: On 2024-05-19 7:24 a.m., Timo Rothenpieler wrote: On 19.05.2024 02:00, Brad Smith wrote: configure: enable ffnvcodec, nvenc, nvdec for FreeBSD Signed-off-by: Brad Smith --- configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index b16722d83d..96b181fd21 100755 --- a/configure +++ b/configure @@ -7350,7 +7350,7 @@ fi if enabled x86; then case $target_os in - mingw32*|mingw64*|win32|win64|linux|cygwin*) + freebsd|mingw32*|mingw64*|win32|win64|linux|cygwin*) Does this actually work? Everything I find online indicates that the FreeBSD driver is lacking support for CUDA, nvenc and most of anything compute related. According to the commits and bug report requesting support it does appear to work. The CUDA bits are not native. They're using Linux emulation for that. The display driver is native. If it actually is confirmed to work, this change LGTM. I have no way to test or verify that though. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/3] lavc/vp7dsp: R-V V vp7_idct_add
Most of the code is shared with DC, thanks to minor earlier changes.
vp7_idct_add_c: 5.2
vp7_idct_add_rvv_i32: 2.5
---
libavcodec/riscv/vp7dsp_init.c | 2 ++
libavcodec/riscv/vp7dsp_rvv.S | 29 +
2 files changed, 31 insertions(+)
diff --git a/libavcodec/riscv/vp7dsp_init.c b/libavcodec/riscv/vp7dsp_init.c
index 1406eb1c6a..ae7f2d4277 100644
--- a/libavcodec/riscv/vp7dsp_init.c
+++ b/libavcodec/riscv/vp7dsp_init.c
@@ -26,6 +26,7 @@
#include "libavcodec/vp8dsp.h"
void ff_vp7_luma_dc_wht_rvv(int16_t block[4][4][16], int16_t dc[16]);
+void ff_vp7_idct_add_rvv(uint8_t *dst, int16_t block[16], ptrdiff_t stride);
av_cold void ff_vp7dsp_init_riscv(VP8DSPContext *c)
{
@@ -37,6 +38,7 @@ av_cold void ff_vp7dsp_init_riscv(VP8DSPContext *c)
#if __riscv_xlen >= 64
c->vp8_luma_dc_wht = ff_vp7_luma_dc_wht_rvv;
#endif
+c->vp8_idct_add = ff_vp7_idct_add_rvv;
}
#endif
}
diff --git a/libavcodec/riscv/vp7dsp_rvv.S b/libavcodec/riscv/vp7dsp_rvv.S
index 06e251f5ce..2a4c404bbb 100644
--- a/libavcodec/riscv/vp7dsp_rvv.S
+++ b/libavcodec/riscv/vp7dsp_rvv.S
@@ -97,4 +97,33 @@ func ff_vp7_luma_dc_wht_rvv, zve32x
vnclip.wi v7, v3, 18
jr t0
endfunc
+
+func ff_vp7_idct_add_rvv, zve32x
+jal t0, 1b
+csrwi vxrm, 2
+vsetvli zero, zero, e8, mf4, ta, ma
+vle8.v v12, (a0)
+vle8.v v13, (t1)
+vwaddu.wv v4, v4, v12
+vle8.v v14, (t2)
+vwaddu.wv v5, v5, v13
+vle8.v v15, (t3)
+vwaddu.wv v6, v6, v14
+vwaddu.wv v7, v7, v15
+vsetvli zero, zero, e16, mf2, ta, ma
+vmax.vx v4, v4, zero
+vmax.vx v5, v5, zero
+vmax.vx v6, v6, zero
+vmax.vx v7, v7, zero
+vsetvli zero, zero, e8, mf4, ta, ma
+vnclipu.wi v0, v4, 0
+vnclipu.wi v1, v5, 0
+vse8.v v0, (a0)
+vnclipu.wi v2, v6, 0
+vse8.v v1, (t1)
+vnclipu.wi v3, v7, 0
+vse8.v v2, (t2)
+vse8.v v3, (t3)
+ret
+endfunc
#endif
--
2.45.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 2/3] lavc/vp7dsp: revector ff_vp7_dc_wht_rvv
This prepares for some code reuse.
---
libavcodec/riscv/vp7dsp_init.c | 3 ++-
libavcodec/riscv/vp7dsp_rvv.S | 23 ++-
2 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/libavcodec/riscv/vp7dsp_init.c b/libavcodec/riscv/vp7dsp_init.c
index 5a57a39d0b..1406eb1c6a 100644
--- a/libavcodec/riscv/vp7dsp_init.c
+++ b/libavcodec/riscv/vp7dsp_init.c
@@ -32,7 +32,8 @@ av_cold void ff_vp7dsp_init_riscv(VP8DSPContext *c)
#if HAVE_RVV
int flags = av_get_cpu_flags();
-if ((flags & AV_CPU_FLAG_RVV_I32) && ff_rv_vlen_least(128)) {
+if ((flags & AV_CPU_FLAG_RVV_I32) && (flags & AV_CPU_FLAG_RVB_ADDR) &&
+ff_rv_vlen_least(128)) {
#if __riscv_xlen >= 64
c->vp8_luma_dc_wht = ff_vp7_luma_dc_wht_rvv;
#endif
diff --git a/libavcodec/riscv/vp7dsp_rvv.S b/libavcodec/riscv/vp7dsp_rvv.S
index 819d2056dc..06e251f5ce 100644
--- a/libavcodec/riscv/vp7dsp_rvv.S
+++ b/libavcodec/riscv/vp7dsp_rvv.S
@@ -22,6 +22,15 @@
#if __riscv_xlen >= 64
func ff_vp7_luma_dc_wht_rvv, zve32x
+li a2, 4 * 16 * 2
+li a7, 16 * 2
+jal t0, 1f
+vsse16.vv4, (a0), a7
+vsse16.vv5, (t1), a7
+vsse16.vv6, (t2), a7
+vsse16.vv7, (t3), a7
+ret
+1:
csrwi vxrm, 0
li t4, 12540
vsetivlizero, 4, e16, mf2, ta, ma
@@ -58,14 +67,14 @@ func ff_vp7_luma_dc_wht_rvv, zve32x
vle16.v v2, (t2)
vle16.v v3, (t3)
vwmul.vxv8, v1, t4
-li t0, 16 * 2
vwmul.vxv9, v3, t6
-addit1, a0, 1 * 4 * 16 * 2
+add t1, a2, a0
vwmul.vxv10, v1, t6
-addit2, a0, 2 * 4 * 16 * 2
+sh1add t2, a2, a0
vwmul.vxv11, v3, t4
-addit3, a0, 3 * 4 * 16 * 2
+sh1add a2, a2, a2 # a2 *= 3
vwadd.vvv4, v0, v2
+add t3, a2, a0
vwsub.vvv5, v0, v2
vsetvli zero, zero, e32, m1, ta, ma
vmul.vx v4, v4, t5
@@ -86,10 +95,6 @@ func ff_vp7_luma_dc_wht_rvv, zve32x
vnclip.wi v5, v1, 18
vnclip.wi v6, v2, 18
vnclip.wi v7, v3, 18
-vsse16.vv4, (a0), t0
-vsse16.vv5, (t1), t0
-vsse16.vv6, (t2), t0
-vsse16.vv7, (t3), t0
-ret
+jr t0
endfunc
#endif
--
2.45.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] lavc/vp7dsp: add R-V V vp7_luma_dc_wht
This works out a bit more favourably than VP8's due to:
- additional multiplications that can be vectored,
- hardware-supported fixed-point rounding mode.
vp7_luma_dc_wht_c: 3.2
vp7_luma_dc_wht_rvv_i64: 2.0
---
libavcodec/riscv/Makefile | 2 +
libavcodec/riscv/vp7dsp_init.c | 41 +++
libavcodec/riscv/vp7dsp_rvv.S | 96 ++
libavcodec/vp8dsp.c| 4 ++
libavcodec/vp8dsp.h| 2 +
5 files changed, 145 insertions(+)
create mode 100644 libavcodec/riscv/vp7dsp_init.c
create mode 100644 libavcodec/riscv/vp7dsp_rvv.S
diff --git a/libavcodec/riscv/Makefile b/libavcodec/riscv/Makefile
index e608436aa4..590655f829 100644
--- a/libavcodec/riscv/Makefile
+++ b/libavcodec/riscv/Makefile
@@ -65,6 +65,8 @@ RVV-OBJS-$(CONFIG_UTVIDEO_DECODER) += riscv/utvideodsp_rvv.o
OBJS-$(CONFIG_VC1DSP) += riscv/vc1dsp_init.o
RV-OBJS-$(CONFIG_VC1DSP) += riscv/vc1dsp_rvi.o
RVV-OBJS-$(CONFIG_VC1DSP) += riscv/vc1dsp_rvv.o
+OBJS-$(CONFIG_VP7_DECODER) += riscv/vp7dsp_init.o
+RVV-OBJS-$(CONFIG_VP7_DECODER) += riscv/vp7dsp_rvv.o
OBJS-$(CONFIG_VP8DSP) += riscv/vp8dsp_init.o
RV-OBJS-$(CONFIG_VP8DSP) += riscv/vp8dsp_rvi.o
RVV-OBJS-$(CONFIG_VP8DSP) += riscv/vp8dsp_rvv.o
diff --git a/libavcodec/riscv/vp7dsp_init.c b/libavcodec/riscv/vp7dsp_init.c
new file mode 100644
index 00..6d9aba43d9
--- /dev/null
+++ b/libavcodec/riscv/vp7dsp_init.c
@@ -0,0 +1,41 @@
+/*
+ * Copyright (c) 2024 Rémi Denis-Courmont.
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "config.h"
+
+#include "libavutil/attributes.h"
+#include "libavutil/cpu.h"
+#include "libavutil/riscv/cpu.h"
+#include "libavcodec/vp8dsp.h"
+
+void ff_vp7_luma_dc_wht_rvv(int16_t block[4][4][16], int16_t dc[16]);
+
+av_cold void ff_vp7dsp_init_riscv(VP8DSPContext *c)
+{
+#if HAVE_RVV
+int flags = av_get_cpu_flags();
+
+if (flags & AV_CPU_FLAG_RVV_I32 && ff_rv_vlen_least(128)) {
+#if __riscv_xlen >= 64
+c->vp8_luma_dc_wht = ff_vp7_luma_dc_wht_rvv;
+#endif
+}
+#endif
+}
diff --git a/libavcodec/riscv/vp7dsp_rvv.S b/libavcodec/riscv/vp7dsp_rvv.S
new file mode 100644
index 00..fb21e9a595
--- /dev/null
+++ b/libavcodec/riscv/vp7dsp_rvv.S
@@ -0,0 +1,96 @@
+/*
+ * Copyright (c) 2024 Rémi Denis-Courmont.
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/riscv/asm.S"
+
+#if __riscv_xlen >= 64
+func ff_vp7_luma_dc_wht_rvv, zve32x
+csrwi vxrm, 0
+li t4, 12540
+vsetivlizero, 4, e16, mf2, ta, ma
+vlseg4e16.v v0, (a1)
+li t6, 30274
+vwmul.vxv8, v1, t4
+li t5, 23170
+vwmul.vxv9, v3, t6
+addit1, sp, -12 * 2
+vwmul.vxv10, v1, t6
+addit2, sp, -8 * 2
+vwmul.vxv11, v3, t4
+addit3, sp, -4 * 2
+vwadd.vvv4, v0, v2
+addisp, sp, -16 * 2
+vwsub.vvv5, v0, v2
+vsetvli zero, zero, e32, m1, ta, ma
+vadd.vv v7, v10, v11
+vmul.vx v4, v4, t5
+vsub.vv v6, v8, v9
+vmul.vx v5, v5, t5
+vadd.vv v0, v4, v7
+vsub.vv v3, v4, v7
+vadd.vv v1, v5, v6
+vsub.vv v2, v5, v6
+vsetvli zero, zero, e16, mf2, ta, ma
+vnsra.wiv4, v0, 14
+vnsra.wiv7, v3, 14
+vnsra.wiv5, v1, 14
+vnsra.wiv6, v2, 14
+vsseg4e16.v v4, (sp)
+vle16.v v0, (sp)
+vle16.v v1, (t1)
[FFmpeg-devel] [PATCH] lavc/vvc: Validate temporal MVP references
Per VVCv3 p. 157, the collocated reference picture used in temporal
motion vector prediction must have RprConstraintsActiveFlag equal to
zero and the same CTU size as the current picture. Add these checks,
fixing crashes decoding some fuzzed bitstreams.
Additionally, only set up the collocated reference picture if it is
actually going to be used (i.e. if ph_temporal_mvp_enabled_flag is 1),
else legal RPR bitstreams will fail the new checks.
Co-authored-by: Nuo Mi
Signed-off-by: Frank Plowman
---
libavcodec/vvc/refs.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/libavcodec/vvc/refs.c b/libavcodec/vvc/refs.c
index fb42963034..8b7ba639a3 100644
--- a/libavcodec/vvc/refs.c
+++ b/libavcodec/vvc/refs.c
@@ -506,9 +506,14 @@ int ff_vvc_slice_rpl(VVCContext *s, VVCFrameContext *fc,
SliceContext *sc)
return ret;
}
}
-if ((!rsh->sh_collocated_from_l0_flag) == lx &&
-rsh->sh_collocated_ref_idx < rpl->nb_refs)
-fc->ref->collocated_ref =
rpl->refs[rsh->sh_collocated_ref_idx].ref;
+if (ph->r->ph_temporal_mvp_enabled_flag &&
+(!rsh->sh_collocated_from_l0_flag) == lx &&
+rsh->sh_collocated_ref_idx < rpl->nb_refs) {
+const VVCRefPic *refp = rpl->refs + rsh->sh_collocated_ref_idx;
+if (refp->is_scaled || refp->ref->sps->ctb_log2_size_y !=
sps->ctb_log2_size_y)
+return AVERROR_INVALIDDATA;
+fc->ref->collocated_ref = refp->ref;
+}
}
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] lavc/vp8dsp: R-V V vp8_luma_dc_wht
Le sunnuntaina 26. toukokuuta 2024, 10.29.02 EEST Rémi Denis-Courmont a écrit
:
> diff --git a/libavcodec/riscv/vp8dsp_init.c b/libavcodec/riscv/vp8dsp_init.c
> index 2413fbf449..d48fe08560 100644
> --- a/libavcodec/riscv/vp8dsp_init.c
> +++ b/libavcodec/riscv/vp8dsp_init.c
> @@ -26,6 +26,7 @@
> #include "libavcodec/vp8dsp.h"
> #include "vp8dsp.h"
>
> +void ff_vp8_luma_dc_wht_rvv(int16_t block[4][4][16], int16_t dc[16]);
> void ff_vp8_idct_dc_add_rvv(uint8_t *dst, int16_t block[16], ptrdiff_t
> stride); void ff_vp8_idct_dc_add4y_rvv(uint8_t *dst, int16_t block[4][16],
> ptrdiff_t stride); void ff_vp8_idct_dc_add4uv_rvv(uint8_t *dst, int16_t
> block[4][16], ptrdiff_t stride); @@ -110,6 +111,7 @@ av_cold void
> ff_vp8dsp_init_riscv(VP8DSPContext *c) int flags = av_get_cpu_flags();
>
> if (flags & AV_CPU_FLAG_RVV_I32 && ff_rv_vlen_least(128)) {
> +c->vp8_luma_dc_wht = ff_vp8_luma_dc_wht_rvv;
Missing XLEN check.
> c->vp8_idct_dc_add = ff_vp8_idct_dc_add_rvv;
> c->vp8_idct_dc_add4y = ff_vp8_idct_dc_add4y_rvv;
> if (flags & AV_CPU_FLAG_RVB_ADDR) {
--
Rémi Denis-Courmont
http://www.remlab.net/
___
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/vp8dsp: R-V V vp8_luma_dc_wht
This is not great as transposition is poorly supported, but it works:
vp8_luma_dc_wht_c: 2.5
vp8_luma_dc_wht_rvv_i32: 1.7
---
libavcodec/riscv/vp8dsp_init.c | 2 ++
libavcodec/riscv/vp8dsp_rvv.S | 55 ++
2 files changed, 57 insertions(+)
diff --git a/libavcodec/riscv/vp8dsp_init.c b/libavcodec/riscv/vp8dsp_init.c
index 2413fbf449..d48fe08560 100644
--- a/libavcodec/riscv/vp8dsp_init.c
+++ b/libavcodec/riscv/vp8dsp_init.c
@@ -26,6 +26,7 @@
#include "libavcodec/vp8dsp.h"
#include "vp8dsp.h"
+void ff_vp8_luma_dc_wht_rvv(int16_t block[4][4][16], int16_t dc[16]);
void ff_vp8_idct_dc_add_rvv(uint8_t *dst, int16_t block[16], ptrdiff_t stride);
void ff_vp8_idct_dc_add4y_rvv(uint8_t *dst, int16_t block[4][16], ptrdiff_t
stride);
void ff_vp8_idct_dc_add4uv_rvv(uint8_t *dst, int16_t block[4][16], ptrdiff_t
stride);
@@ -110,6 +111,7 @@ av_cold void ff_vp8dsp_init_riscv(VP8DSPContext *c)
int flags = av_get_cpu_flags();
if (flags & AV_CPU_FLAG_RVV_I32 && ff_rv_vlen_least(128)) {
+c->vp8_luma_dc_wht = ff_vp8_luma_dc_wht_rvv;
c->vp8_idct_dc_add = ff_vp8_idct_dc_add_rvv;
c->vp8_idct_dc_add4y = ff_vp8_idct_dc_add4y_rvv;
if (flags & AV_CPU_FLAG_RVB_ADDR) {
diff --git a/libavcodec/riscv/vp8dsp_rvv.S b/libavcodec/riscv/vp8dsp_rvv.S
index 21c8985b04..f57852c82b 100644
--- a/libavcodec/riscv/vp8dsp_rvv.S
+++ b/libavcodec/riscv/vp8dsp_rvv.S
@@ -32,6 +32,61 @@
.endif
.endm
+#if __riscv_xlen >= 64
+func ff_vp8_luma_dc_wht_rvv, zve64x
+vsetivlizero, 1, e64, m1, ta, ma
+vlseg4e64.v v4, (a1)
+vsetivlizero, 4, e16, mf2, ta, ma
+vwadd.vvv1, v5, v6
+addit1, sp, -48
+vwadd.vvv0, v4, v7
+addit2, sp, -32
+vwsub.vvv2, v5, v6
+addit3, sp, -16
+vwsub.vvv3, v4, v7
+addisp, sp, -64
+vsetvli zero, zero, e32, m1, ta, ma
+vadd.vv v4, v0, v1
+vadd.vv v5, v3, v2
+vse32.v v4, (sp)
+vsub.vv v6, v0, v1
+vse32.v v5, (t1)
+vsub.vv v7, v3, v2
+vse32.v v6, (t2)
+vse32.v v7, (t3)
+vlseg4e32.v v4, (sp)
+vadd.vv v0, v4, v7
+sd zero, (a1)
+vadd.vv v1, v5, v6
+sd zero, 8(a1)
+vsub.vv v2, v5, v6
+sd zero, 16(a1)
+vsub.vv v3, v4, v7
+sd zero, 24(a1)
+vadd.vi v0, v0, 3 # rounding mode not supported, do it manually
+li t0, 4 * 16 * 2
+vadd.vi v3, v3, 3
+addit1, a0, 16 * 2
+vadd.vv v4, v0, v1
+addit2, a0, 16 * 2 * 2
+vadd.vv v5, v3, v2
+addit3, a0, 16 * 2 * 3
+vsub.vv v6, v0, v1
+vsub.vv v7, v3, v2
+vsetvli zero, zero, e16, mf2, ta, ma
+vnsra.wiv0, v4, 3
+addisp, sp, 64
+vnsra.wiv1, v5, 3
+vsse16.vv0, (a0), t0
+vnsra.wiv2, v6, 3
+vsse16.vv1, (t1), t0
+vnsra.wiv3, v7, 3
+vsse16.vv2, (t2), t0
+vsse16.vv3, (t3), t0
+ret
+endfunc
+#endif
+
.macro vp8_idct_dc_add
vlse32.v v0, (a0), a2
lha5, 0(a1)
--
2.45.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".
