Re: [FFmpeg-devel] [PATCH 01/11] avdevice/audiotoolbox: fix mixed declaration and code
> On Jul 12, 2024, at 23:44, Marvin Scholz wrote:
>
> Fix a bunch of "mixing declarations and code is incompatible with
> standards before C99" warnings.
Rather than fix the warning, can we disable the check for object-c as it's a
different language?
> ---
> libavdevice/audiotoolbox.m | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/libavdevice/audiotoolbox.m b/libavdevice/audiotoolbox.m
> index 7d95c34593..dd607589b4 100644
> --- a/libavdevice/audiotoolbox.m
> +++ b/libavdevice/audiotoolbox.m
> @@ -77,6 +77,9 @@ static av_cold int at_write_header(AVFormatContext *avctx)
> ATContext *ctx = (ATContext*)avctx->priv_data;
> OSStatus err = noErr;
> CFStringRef device_UID = NULL;
> +const char *stream_name = avctx->url;
> +AVCodecParameters *codecpar = avctx->streams[0]->codecpar;
> +AudioStreamBasicDescription device_format = {0};
> AudioDeviceID *devices;
> int num_devices;
>
> @@ -133,7 +136,6 @@ static av_cold int at_write_header(AVFormatContext *avctx)
>
> // get user-defined device UID or use default device
> // -audio_device_index overrides any URL given
> -const char *stream_name = avctx->url;
> if (stream_name && ctx->audio_device_index == -1) {
> sscanf(stream_name, "%d", &ctx->audio_device_index);
> }
> @@ -163,10 +165,8 @@ static av_cold int at_write_header(AVFormatContext
> *avctx)
> }
>
> av_freep(&devices);
> -AVCodecParameters *codecpar = avctx->streams[0]->codecpar;
>
> // audio format
> -AudioStreamBasicDescription device_format = {0};
> device_format.mSampleRate= codecpar->sample_rate;
> device_format.mFormatID = kAudioFormatLinearPCM;
> device_format.mFormatFlags |= (codecpar->format ==
> AV_SAMPLE_FMT_FLT) ? kLinearPCMFormatFlagIsFloat : 0;
> @@ -237,6 +237,7 @@ static av_cold int at_write_header(AVFormatContext *avctx)
>
> static int at_write_packet(AVFormatContext *avctx, AVPacket *pkt)
> {
> +AudioQueueBufferRef buf;
> ATContext *ctx = (ATContext*)avctx->priv_data;
> OSStatus err = noErr;
>
> @@ -256,7 +257,7 @@ static int at_write_packet(AVFormatContext *avctx,
> AVPacket *pkt)
> }
> }
>
> -AudioQueueBufferRef buf = ctx->buffer[ctx->cur_buf];
> +buf = ctx->buffer[ctx->cur_buf];
>
> // copy audio data into buffer and enqueue the buffer
> memcpy(buf->mAudioData, pkt->data, buf->mAudioDataBytesCapacity);
>
> base-commit: 85706f5136cf7c88f95843b2634dd3f7d7d2cb6d
> --
> 2.39.3 (Apple Git-146)
>
>
> ___
> 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 1/4] avcodec/amfenc: Fixes the color information in the output.
added 10 bit support for amf hevc.
before:
command - ffmpeg.exe -hide_banner -y -hwaccel d3d11va -hwaccel_output_format
d3d11 -i test_10bit_file.mkv -an -c:v h264_amf res.dx11_hw_h264.mkv
output - Format of input frames context (p010le) is not supported by AMF.
command - ffmpeg.exe -hide_banner -y -hwaccel d3d11va -hwaccel_output_format
d3d11 -i test_10bit_file -an -c:v hevc_amf res.dx11_hw_hevc.mkv
output - Format of input frames context (p010le) is not supported by AMF.
after:
command - ffmpeg.exe -hide_banner -y -hwaccel d3d11va -hwaccel_output_format
d3d11 -i test_10bit_file -an -c:v h264_amf res.dx11_hw_h264.mkv
output - 10-bit input video is not supported by AMF H264 encoder
command - ffmpeg.exe -hide_banner -y -hwaccel d3d11va -hwaccel_output_format
d3d11 -i test_10bit_file -an -c:v hevc_amf res.dx11_hw_hevc.mkv
output - 10bit file
v2 - lost line returned in ff_amf_pix_fmts
v3 - fixes after review
v4 - extract duplicated code, fix incorrect processing of 10-bit input for h264
v5 - non-functional changes after review
Co-authored-by: Evgeny Pavlov
---
libavcodec/amfenc.c | 37 +
libavcodec/amfenc.h | 3 +++
libavcodec/amfenc_h264.c | 24
libavcodec/amfenc_hevc.c | 31 ++-
4 files changed, 90 insertions(+), 5 deletions(-)
diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index 061859f85c..0bd15dd812 100644
--- a/libavcodec/amfenc.c
+++ b/libavcodec/amfenc.c
@@ -60,6 +60,7 @@ const enum AVPixelFormat ff_amf_pix_fmts[] = {
#if CONFIG_DXVA2
AV_PIX_FMT_DXVA2_VLD,
#endif
+AV_PIX_FMT_P010,
AV_PIX_FMT_NONE
};
@@ -72,6 +73,7 @@ static const FormatMap format_map[] =
{
{ AV_PIX_FMT_NONE, AMF_SURFACE_UNKNOWN },
{ AV_PIX_FMT_NV12, AMF_SURFACE_NV12 },
+{ AV_PIX_FMT_P010, AMF_SURFACE_P010 },
{ AV_PIX_FMT_BGR0, AMF_SURFACE_BGRA },
{ AV_PIX_FMT_RGB0, AMF_SURFACE_RGBA },
{ AV_PIX_FMT_GRAY8, AMF_SURFACE_GRAY8 },
@@ -785,6 +787,41 @@ int ff_amf_receive_packet(AVCodecContext *avctx, AVPacket
*avpkt)
return ret;
}
+int ff_amf_get_color_profile(AVCodecContext *avctx)
+{
+amf_int64 color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_UNKNOWN;
+if (avctx->color_range == AVCOL_RANGE_JPEG) {
+/// Color Space for Full (JPEG) Range
+switch (avctx->colorspace) {
+case AVCOL_SPC_SMPTE170M:
+color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_FULL_601;
+break;
+case AVCOL_SPC_BT709:
+color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_FULL_709;
+break;
+case AVCOL_SPC_BT2020_NCL:
+case AVCOL_SPC_BT2020_CL:
+color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_FULL_2020;
+break;
+}
+} else {
+/// Color Space for Limited (MPEG) range
+switch (avctx->colorspace) {
+case AVCOL_SPC_SMPTE170M:
+color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_601;
+break;
+case AVCOL_SPC_BT709:
+color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_709;
+break;
+case AVCOL_SPC_BT2020_NCL:
+case AVCOL_SPC_BT2020_CL:
+color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_2020;
+break;
+}
+}
+return color_profile;
+}
+
const AVCodecHWConfigInternal *const ff_amfenc_hw_configs[] = {
#if CONFIG_D3D11VA
HW_CONFIG_ENCODER_FRAMES(D3D11, D3D11VA),
diff --git a/libavcodec/amfenc.h b/libavcodec/amfenc.h
index 2dbd378ef8..62736ef579 100644
--- a/libavcodec/amfenc.h
+++ b/libavcodec/amfenc.h
@@ -21,6 +21,7 @@
#include
+#include
#include
#include
#include
@@ -170,6 +171,8 @@ int ff_amf_receive_packet(AVCodecContext *avctx, AVPacket
*avpkt);
*/
extern const enum AVPixelFormat ff_amf_pix_fmts[];
+int ff_amf_get_color_profile(AVCodecContext *avctx);
+
/**
* Error handling helper
*/
diff --git a/libavcodec/amfenc_h264.c b/libavcodec/amfenc_h264.c
index 32baa8e91a..7caeca748d 100644
--- a/libavcodec/amfenc_h264.c
+++ b/libavcodec/amfenc_h264.c
@@ -200,6 +200,8 @@ static av_cold int amf_encode_init_h264(AVCodecContext
*avctx)
AMFRate framerate;
AMFSize framesize =
AMFConstructSize(avctx->width, avctx->height);
int deblocking_filter = (avctx->flags &
AV_CODEC_FLAG_LOOP_FILTER) ? 1 : 0;
+amf_int64color_profile;
+enum AVPixelFormat pix_fmt;
if (avctx->framerate.num > 0 && avctx->framerate.den > 0) {
framerate = AMFConstructRate(avctx->framerate.num,
avctx->framerate.den);
@@ -270,10 +272,24 @@ FF_ENABLE_DEPRECATION_WARNINGS
AMF_ASSIGN_PROPERTY_RATIO(res, ctx->encoder,
AMF_VIDEO_ENCODER_ASPECT_RATIO, ratio);
}
-/// Color Range (Partial/TV/MPEG or Full/PC/JPEG)
-if (avctx->color_range == AVCO
[FFmpeg-devel] [PATCH 2/4] avcodec/amfenc: HDR metadata.
v2: fixes for indentation
---
libavcodec/amfenc.c | 83 +
1 file changed, 83 insertions(+)
diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index 0bd15dd812..068bb53002 100644
--- a/libavcodec/amfenc.c
+++ b/libavcodec/amfenc.c
@@ -36,6 +36,57 @@
#include "amfenc.h"
#include "encode.h"
#include "internal.h"
+#include "libavutil/mastering_display_metadata.h"
+
+static int amf_save_hdr_metadata(AVCodecContext *avctx, const AVFrame *frame,
AMFHDRMetadata *hdrmeta)
+{
+AVFrameSideData*sd_display;
+AVFrameSideData*sd_light;
+AVMasteringDisplayMetadata *display_meta;
+AVContentLightMetadata *light_meta;
+
+sd_display = av_frame_get_side_data(frame,
AV_FRAME_DATA_MASTERING_DISPLAY_METADATA);
+if (sd_display) {
+display_meta = (AVMasteringDisplayMetadata *)sd_display->data;
+if (display_meta->has_luminance) {
+const unsigned int luma_den = 1;
+hdrmeta->maxMasteringLuminance =
+(amf_uint32)(luma_den * av_q2d(display_meta->max_luminance));
+hdrmeta->minMasteringLuminance =
+FFMIN((amf_uint32)(luma_den *
av_q2d(display_meta->min_luminance)), hdrmeta->maxMasteringLuminance);
+}
+if (display_meta->has_primaries) {
+const unsigned int chroma_den = 5;
+hdrmeta->redPrimary[0] =
+FFMIN((amf_uint16)(chroma_den *
av_q2d(display_meta->display_primaries[0][0])), chroma_den);
+hdrmeta->redPrimary[1] =
+FFMIN((amf_uint16)(chroma_den *
av_q2d(display_meta->display_primaries[0][1])), chroma_den);
+hdrmeta->greenPrimary[0] =
+FFMIN((amf_uint16)(chroma_den *
av_q2d(display_meta->display_primaries[1][0])), chroma_den);
+hdrmeta->greenPrimary[1] =
+FFMIN((amf_uint16)(chroma_den *
av_q2d(display_meta->display_primaries[1][1])), chroma_den);
+hdrmeta->bluePrimary[0] =
+FFMIN((amf_uint16)(chroma_den *
av_q2d(display_meta->display_primaries[2][0])), chroma_den);
+hdrmeta->bluePrimary[1] =
+FFMIN((amf_uint16)(chroma_den *
av_q2d(display_meta->display_primaries[2][1])), chroma_den);
+hdrmeta->whitePoint[0] =
+FFMIN((amf_uint16)(chroma_den *
av_q2d(display_meta->white_point[0])), chroma_den);
+hdrmeta->whitePoint[1] =
+FFMIN((amf_uint16)(chroma_den *
av_q2d(display_meta->white_point[1])), chroma_den);
+}
+
+sd_light = av_frame_get_side_data(frame,
AV_FRAME_DATA_CONTENT_LIGHT_LEVEL);
+if (sd_light) {
+light_meta = (AVContentLightMetadata *)sd_light->data;
+if (light_meta) {
+hdrmeta->maxContentLightLevel = (amf_uint16)light_meta->MaxCLL;
+hdrmeta->maxFrameAverageLightLevel =
(amf_uint16)light_meta->MaxFALL;
+}
+}
+return 0;
+}
+return 1;
+}
#if CONFIG_D3D11VA
#include
@@ -683,6 +734,26 @@ int ff_amf_receive_packet(AVCodecContext *avctx, AVPacket
*avpkt)
frame_ref_storage_buffer->pVtbl->Release(frame_ref_storage_buffer);
}
+// HDR10 metadata
+if (frame->color_trc == AVCOL_TRC_SMPTE2084) {
+AMFBuffer * hdrmeta_buffer = NULL;
+res = ctx->context->pVtbl->AllocBuffer(ctx->context,
AMF_MEMORY_HOST, sizeof(AMFHDRMetadata), &hdrmeta_buffer);
+if (res == AMF_OK) {
+AMFHDRMetadata * hdrmeta =
(AMFHDRMetadata*)hdrmeta_buffer->pVtbl->GetNative(hdrmeta_buffer);
+if (amf_save_hdr_metadata(avctx, frame, hdrmeta) == 0) {
+switch (avctx->codec->id) {
+case AV_CODEC_ID_H264:
+AMF_ASSIGN_PROPERTY_INTERFACE(res, ctx->encoder,
AMF_VIDEO_ENCODER_INPUT_HDR_METADATA, hdrmeta_buffer); break;
+case AV_CODEC_ID_HEVC:
+AMF_ASSIGN_PROPERTY_INTERFACE(res, ctx->encoder,
AMF_VIDEO_ENCODER_HEVC_INPUT_HDR_METADATA, hdrmeta_buffer); break;
+}
+res = amf_set_property_buffer(surface,
L"av_frame_hdrmeta", hdrmeta_buffer);
+AMF_RETURN_IF_FALSE(avctx, res == AMF_OK, AVERROR_UNKNOWN,
"SetProperty failed for \"av_frame_hdrmeta\" with error %d\n", res);
+}
+hdrmeta_buffer->pVtbl->Release(hdrmeta_buffer);
+}
+}
+
surface->pVtbl->SetPts(surface, frame->pts);
AMF_ASSIGN_PROPERTY_INT64(res, surface, PTS_PROP, frame->pts);
@@ -746,6 +817,18 @@ int ff_amf_receive_packet(AVCodecContext *avctx, AVPacket
*avpkt)
}
res_resubmit = AMF_OK;
if (ctx->delayed_surface != NULL) { // try to resubmit frame
+if (ctx->delayed_surface->pVtbl->HasProperty(ctx->delayed_surface,
L"av_frame_hdrmeta")) {
+AMFBuffer * hdrmeta_buffer =
[FFmpeg-devel] [PATCH 3/4] avcodec/amfenc: add 10 bit encoding in av1_amf
v2: refactored after review
Signed-off-by: Evgeny Pavlov
Co-authored-by: Dmitrii Ovchinnikov
---
libavcodec/amfenc.c | 2 ++
libavcodec/amfenc_av1.c | 27 +++
2 files changed, 29 insertions(+)
diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index 068bb53002..f1b76bd6aa 100644
--- a/libavcodec/amfenc.c
+++ b/libavcodec/amfenc.c
@@ -826,6 +826,8 @@ int ff_amf_receive_packet(AVCodecContext *avctx, AVPacket
*avpkt)
AMF_ASSIGN_PROPERTY_INTERFACE(res, ctx->encoder,
AMF_VIDEO_ENCODER_INPUT_HDR_METADATA, hdrmeta_buffer); break;
case AV_CODEC_ID_HEVC:
AMF_ASSIGN_PROPERTY_INTERFACE(res, ctx->encoder,
AMF_VIDEO_ENCODER_HEVC_INPUT_HDR_METADATA, hdrmeta_buffer); break;
+case AV_CODEC_ID_AV1:
+AMF_ASSIGN_PROPERTY_INTERFACE(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_INPUT_HDR_METADATA, hdrmeta_buffer); break;
}
hdrmeta_buffer->pVtbl->Release(hdrmeta_buffer);
}
diff --git a/libavcodec/amfenc_av1.c b/libavcodec/amfenc_av1.c
index d40c71cb33..a8629d74b0 100644
--- a/libavcodec/amfenc_av1.c
+++ b/libavcodec/amfenc_av1.c
@@ -166,6 +166,9 @@ static av_cold int amf_encode_init_av1(AVCodecContext*
avctx)
AMFGuid guid;
AMFRate framerate;
AMFSize framesize = AMFConstructSize(avctx->width,
avctx->height);
+amf_int64 color_depth;
+amf_int64 color_profile;
+enumAVPixelFormat pix_fmt;
@@ -211,6 +214,30 @@ FF_ENABLE_DEPRECATION_WARNINGS
AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_PROFILE, profile);
}
+/// Color profile
+color_profile = ff_amf_get_color_profile(avctx);
+AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_OUTPUT_COLOR_PROFILE, color_profile);
+
+/// Color Depth
+pix_fmt = avctx->hw_frames_ctx ?
((AVHWFramesContext*)avctx->hw_frames_ctx->data)->sw_format
+: avctx->pix_fmt;
+color_depth = AMF_COLOR_BIT_DEPTH_8;
+if (pix_fmt == AV_PIX_FMT_P010) {
+color_depth = AMF_COLOR_BIT_DEPTH_10;
+}
+
+AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_COLOR_BIT_DEPTH, color_depth);
+AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_OUTPUT_COLOR_PROFILE, color_profile);
+if (color_depth == AMF_COLOR_BIT_DEPTH_8) {
+/// Color Transfer Characteristics (AMF matches ISO/IEC)
+AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_OUTPUT_TRANSFER_CHARACTERISTIC,
AMF_COLOR_TRANSFER_CHARACTERISTIC_BT709);
+/// Color Primaries (AMF matches ISO/IEC)
+AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_OUTPUT_COLOR_PRIMARIES, AMF_COLOR_PRIMARIES_BT709);
+} else {
+AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_OUTPUT_TRANSFER_CHARACTERISTIC,
AMF_COLOR_TRANSFER_CHARACTERISTIC_SMPTE2084);
+AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder,
AMF_VIDEO_ENCODER_AV1_OUTPUT_COLOR_PRIMARIES, AMF_COLOR_PRIMARIES_BT2020);
+}
+
profile_level = avctx->level;
if (profile_level == AV_LEVEL_UNKNOWN) {
profile_level = ctx->level;
--
2.45.2.windows.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 4/4] avcodec/amfenc: GPU driver version check
Implemented gpu driver check.
10-bit patch works incorrectly on driver version lower than 23.30.
---
libavcodec/amfenc_av1.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/amfenc_av1.c b/libavcodec/amfenc_av1.c
index a8629d74b0..cfa319f933 100644
--- a/libavcodec/amfenc_av1.c
+++ b/libavcodec/amfenc_av1.c
@@ -223,6 +223,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
: avctx->pix_fmt;
color_depth = AMF_COLOR_BIT_DEPTH_8;
if (pix_fmt == AV_PIX_FMT_P010) {
+AMF_RETURN_IF_FALSE(ctx, ctx->version >= AMF_MAKE_FULL_VERSION(1, 4,
32, 0), AVERROR_UNKNOWN, "HEVC 10-bit encoder is not supported by AMD GPU
drivers versions lower than 23.30.\n");
color_depth = AMF_COLOR_BIT_DEPTH_10;
}
--
2.45.2.windows.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] ffmpeg: don't truncate getmaxrss value
On 2024-07-14 02:14 pm, Gyan Doshi wrote: On 2024-07-11 02:52 pm, Gyan Doshi wrote: Can lead to printing of nonsensical negative memory usage Plan to push in 24h. Pushed as 350146a1ea9d2d0220cc8d024125b77240e3e98d Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/imgutils: av_image_check_size2() ensure width and height fit in 32bit
On Tue, Jul 9, 2024 at 1:44 PM Michael Niedermayer
wrote:
> on "INT is 64bit" systems they may have been false
>
> Signed-off-by: Michael Niedermayer
> ---
> libavutil/imgutils.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavutil/imgutils.c b/libavutil/imgutils.c
> index d2463815637..b738cff37c2 100644
> --- a/libavutil/imgutils.c
> +++ b/libavutil/imgutils.c
> @@ -298,7 +298,7 @@ int av_image_check_size2(unsigned int w, unsigned int
> h, int64_t max_pixels, enu
> stride = 8LL*w;
> stride += 128*8;
>
> -if ((int)w<=0 || (int)h<=0 || stride >= INT_MAX ||
> stride*(uint64_t)(h+128) >= INT_MAX) {
> +if (w==0 || h==0 || w > INT32_MAX || h > INT32_MAX || stride >=
> INT_MAX || stride*(uint64_t)(h+128) >= INT_MAX) {
> av_log(&imgutils, AV_LOG_ERROR, "Picture size %ux%u is
> invalid\n", w, h);
> return AVERROR(EINVAL);
> }
While changing this line, it would be nice to have an explanation on what
the conditions do - for example why is stride multiplied by height+128?
And why is stride checked against INT_MAX and w/h against INT32_MAX?
Thanks
Vittorio
___
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] [OSS-Fuzz] Have you considered enabling memory sanitizer?
On Sun, 14 Jul 2024 at 21:55, Michael Niedermayer wrote: > > On Sat, Jul 13, 2024 at 11:12:40PM +0200, Kacper Michajlow wrote: > > On Thu, 27 Jun 2024 at 02:50, Kacper Michajlow wrote: > > > > > > On Thu, 27 Jun 2024 at 00:45, Michael Niedermayer > > > wrote: > > > > > > > > On Wed, Jun 26, 2024 at 09:07:42PM +0200, Kacper Michajlow wrote: > > > > > Hi, > > > > > > > > > > Like in the topic. I think it would be useful to enable MSAN on > > > > > OSS-Fuzz. We get some tiny issues and it would be probably good to > > > > > have them tracked upstream. All infra is here, so enabling it is as > > > > > simple as adding it to the project.yaml. Except libbz2.so and libz.so > > > > > would have to be built inline instead, looking at the build.sh, they > > > > > are prebuilt. The rest should just work (TM), but needs to be tested. > > > > > You can set an "experimental' flag to have it not create issues on > > > > > monorail, initially. > > > > > > > > I assumed ossfuzz would enable all sanitizers by default > > > > > > They do not do that by default, because MSAN requires all dependencies > > > to be instrumented too. See > > > https://google.github.io/oss-fuzz/getting-started/new-project-guide/#sanitizers > > > > > > Looking at build.sh for ffmpeg, it should be fine to enable it. > > > Obviously I have not tested everything, but I was running some tests > > > locally with MSAN and also tested it with mpv oss-fuzz builds where we > > > build ffmpeg too with MSAN. > > > > > > - Kacper > > > > I've sent a PR to enable MSAN and a few other build improvements. > > Please take a look https://github.com/google/oss-fuzz/pull/12211 > > > > > Also, would it be ok to add myself to auto_ccs for ffmpeg? Mostly to > > monitor what issues are reported upstream, as we get some reports in > > mpv fuzzing and I never know if I should report it upstream (ffmpeg) > > or it is already found by first-party fuzzing and I shouldn't make > > more noise. > > you are welcome to submit bug reports, you are welcome to submit bug fixes > if you find issues in FFmpeg. > > If someones work in FFmpeg or rather FFmpeg benefits from someone having > access to the reports, then (s)he should receive access. This seems not > to apply here I respect your decision. However, saying that anyone's (or my) contribution doesn't benefit FFmpeg is a strange thing to say for an open source project maintainer. It's all about time. I don't get paid to do any of this, so duplicating issues/reports manually from one system to another, if they are already reported, is a monkey's job which I'm not willing to do. This time could be devoted to actually fixing the issues. I'd like to help, but if it is not required, I will focus on other things. It also doesn't help that trac.ffmpeg is a black hole, where only Balling seems to be reading those tickets. Frankly, the review process is not better, as even trivial fixes take months to merge. > Also i expect the number of outstanding ossfuzz issues to decrease now > after the bulk of coverity issues has been dealt with For some class of issues sure, but Coverity bigfixes are most of the time workarounding the static analysis limitations. Fuzzing is more powerful and analyzes the code as a whole, not small snippets of it. - Kacper ___ 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] [OSS-Fuzz] Have you considered enabling memory sanitizer?
On Sun, Jul 14, 2024 at 9:55 PM Michael Niedermayer wrote: > On Sat, Jul 13, 2024 at 11:12:40PM +0200, Kacper Michajlow wrote: > > On Thu, 27 Jun 2024 at 02:50, Kacper Michajlow > wrote: > > > > > > On Thu, 27 Jun 2024 at 00:45, Michael Niedermayer > > > wrote: > > > > > > > > On Wed, Jun 26, 2024 at 09:07:42PM +0200, Kacper Michajlow wrote: > > > > > Hi, > > > > > > > > > > Like in the topic. I think it would be useful to enable MSAN on > > > > > OSS-Fuzz. We get some tiny issues and it would be probably good to > > > > > have them tracked upstream. All infra is here, so enabling it is as > > > > > simple as adding it to the project.yaml. Except libbz2.so and > libz.so > > > > > would have to be built inline instead, looking at the build.sh, > they > > > > > are prebuilt. The rest should just work (TM), but needs to be > tested. > > > > > You can set an "experimental' flag to have it not create issues on > > > > > monorail, initially. > > > > > > > > I assumed ossfuzz would enable all sanitizers by default > > > > > > They do not do that by default, because MSAN requires all dependencies > > > to be instrumented too. See > > > > https://google.github.io/oss-fuzz/getting-started/new-project-guide/#sanitizers > > > > > > Looking at build.sh for ffmpeg, it should be fine to enable it. > > > Obviously I have not tested everything, but I was running some tests > > > locally with MSAN and also tested it with mpv oss-fuzz builds where we > > > build ffmpeg too with MSAN. > > > > > > - Kacper > > > > I've sent a PR to enable MSAN and a few other build improvements. > > Please take a look https://github.com/google/oss-fuzz/pull/12211 > > > > > Also, would it be ok to add myself to auto_ccs for ffmpeg? Mostly to > > monitor what issues are reported upstream, as we get some reports in > > mpv fuzzing and I never know if I should report it upstream (ffmpeg) > > or it is already found by first-party fuzzing and I shouldn't make > > more noise. > > you are welcome to submit bug reports, you are welcome to submit bug fixes > if you find issues in FFmpeg. > > If someones work in FFmpeg or rather FFmpeg benefits from someone having > access to the reports, then (s)he should receive access. This seems not > to apply here > Disagree - this is not the right way to attract new contributors. Also i expect the number of outstanding ossfuzz issues to decrease now > after the bulk of coverity issues has been dealt with > The majority of coverity issues are false positives, I fail to see the relationship here. -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 0/1] Make "File exists" exit w/ non-zero status
I'm not sure if it was by design or just an oversight, but it seems "unexpected" that ffmpeg (without `-y`) to an existing file calls `exit(0)`, even though it prints a "fatal" error... The attached patch itself is trivial, but like I say, maybe there was a reason for the current behavior that I'm just not aware of. Cheers! dabe (1): fftools/ffmpeg_opt: Exit with non-zero status when destination exists fftools/ffmpeg_opt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 2.45.2 ___ 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/1] fftools/ffmpeg_opt: Exit with non-zero status when destination exists
---
fftools/ffmpeg_opt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 2c201c74b2..dddf7c6475 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -604,13 +604,13 @@ int assert_file_overwrite(const char *filename)
signal(SIGINT, SIG_DFL);
if (!read_yesno()) {
av_log(NULL, AV_LOG_FATAL, "Not overwriting - exiting\n");
-return AVERROR_EXIT;
+return AVERROR(EEXIST);
}
term_init();
}
else {
av_log(NULL, AV_LOG_FATAL, "File '%s' already exists.
Exiting.\n", filename);
-return AVERROR_EXIT;
+return AVERROR(EEXIST);
}
}
}
-- 2.45.2
___
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] [OSS-Fuzz] Have you considered enabling memory sanitizer?
On 14 Jul 2024, at 21:55, Michael Niedermayer wrote: > On Sat, Jul 13, 2024 at 11:12:40PM +0200, Kacper Michajlow wrote: >> On Thu, 27 Jun 2024 at 02:50, Kacper Michajlow wrote: >>> >>> On Thu, 27 Jun 2024 at 00:45, Michael Niedermayer >>> wrote: On Wed, Jun 26, 2024 at 09:07:42PM +0200, Kacper Michajlow wrote: > Hi, > > Like in the topic. I think it would be useful to enable MSAN on > OSS-Fuzz. We get some tiny issues and it would be probably good to > have them tracked upstream. All infra is here, so enabling it is as > simple as adding it to the project.yaml. Except libbz2.so and libz.so > would have to be built inline instead, looking at the build.sh, they > are prebuilt. The rest should just work (TM), but needs to be tested. > You can set an "experimental' flag to have it not create issues on > monorail, initially. I assumed ossfuzz would enable all sanitizers by default >>> >>> They do not do that by default, because MSAN requires all dependencies >>> to be instrumented too. See >>> https://google.github.io/oss-fuzz/getting-started/new-project-guide/#sanitizers >>> >>> Looking at build.sh for ffmpeg, it should be fine to enable it. >>> Obviously I have not tested everything, but I was running some tests >>> locally with MSAN and also tested it with mpv oss-fuzz builds where we >>> build ffmpeg too with MSAN. >>> >>> - Kacper >> >> I've sent a PR to enable MSAN and a few other build improvements. >> Please take a look https://github.com/google/oss-fuzz/pull/12211 >> > >> Also, would it be ok to add myself to auto_ccs for ffmpeg? Mostly to >> monitor what issues are reported upstream, as we get some reports in >> mpv fuzzing and I never know if I should report it upstream (ffmpeg) >> or it is already found by first-party fuzzing and I shouldn't make >> more noise. > > you are welcome to submit bug reports, you are welcome to submit bug fixes > if you find issues in FFmpeg. > > If someones work in FFmpeg or rather FFmpeg benefits from someone having > access to the reports, then (s)he should receive access. This seems not > to apply here This seems quite rude… Maybe you did not intend it but thats how it reads to me… > > Also i expect the number of outstanding ossfuzz issues to decrease now > after the bulk of coverity issues has been dealt with > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > The real ebay dictionary, page 1 > "Used only once"- "Some unspecified defect prevented a second use" > "In good condition" - "Can be repaird by experienced expert" > "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." > ___ > 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/1] fftools/ffmpeg_opt: Exit with non-zero status when destination exists
On 2024-07-15 06:26 pm, Dabrien 'Dabe' Murphy wrote:
---
fftools/ffmpeg_opt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 2c201c74b2..dddf7c6475 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -604,13 +604,13 @@ int assert_file_overwrite(const char *filename)
signal(SIGINT, SIG_DFL);
if (!read_yesno()) {
av_log(NULL, AV_LOG_FATAL, "Not overwriting -
exiting\n");
- return AVERROR_EXIT;
+ return AVERROR(EEXIST);
}
term_init();
}
else {
av_log(NULL, AV_LOG_FATAL, "File '%s' already exists.
Exiting.\n", filename);
- return AVERROR_EXIT;
+ return AVERROR(EEXIST);
The former is not an error. The user was asked and the application
behaved as per their reply.
Regards,
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4 1/3] avcodec/jpeg2000dec: Add support for CAP and CPF markers
fre 2024-07-12 klockan 12:51 -0700 skrev Pierre-Anthony Lemieux: > On Thu, Jul 11, 2024 at 10:28 PM Tomas Härdin wrote: > > > > > + if (s->in_tile_headers == 1 && s->isHT && (!s- > > > > Ccap15_b11)) > > > + av_log(s->avctx, AV_LOG_WARNING, "COD marker is > > > found in HOMOGENEOUS HT set\n"); > > > > How bad is this and the other markers being present in this case? > > At the very least, it means that signaling is inconsistent within the > codestream since the standard states that: > """ > The HOMOGENEOUS set is the set of HTJ2K codestreams where: > • none of the functional marker segments, e.g., COD, COC, RGN, QCD, > QCC, and POC, are present in any > tile-part header; and > • no PPT marker segment is present. > """ > > The point of signalling that a codestream is "HOMOGENEOUS" is to > allow > decoders to configure themselves solely based on information > retrieved > entirely from the main header. > > Since, AFAIK, FFMPEG does not rely on the HOMOGENEOUS to short- > circuit > configuration, incorrect HOMOGENEOUS signalling will likely not > impact > FFMPEG. It could happen that information in tile headers contradict information in the main header, right? In such a case it sounds like we can't be sure which decode is the correct one. Much like with broken MXF files I think we should error out because of the potential ambiguity, to discourage broken encoders from proliferating. Else we'll have to deal with them perpetually /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] avformat/hls: Fixed incorrect behaviour of default
CoderVenkat 于2024年7月15日周一 00:07写道： > > Apologies > Correct file attached in this > mail.___ I need more time look at the deep for and if logic. Thanks Steven ___ 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/7] avcodec/utils: apply the same alignment to YUV410 as we do to YUV420 when motion estimation is used
On Tue, Jun 18, 2024 at 07:28:18PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > The snow encoder uses block based motion estimation which can read out of
> > array if
> > insufficient alignment is used
> >
> > Fixes: out of array access
> > Fixes:
> > 68963/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-4979988435632128
> > Fixes:
> > 68969/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-6239933667803136.fuzz
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/utils.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> > index 337c00e789a..7914f799041 100644
> > --- a/libavcodec/utils.c
> > +++ b/libavcodec/utils.c
> > @@ -259,6 +259,9 @@ void avcodec_align_dimensions2(AVCodecContext *s, int
> > *width, int *height,
> > if (s->codec_id == AV_CODEC_ID_SVQ1) {
> > w_align = 64;
> > h_align = 64;
> > +} else if (s->codec_id == AV_CODEC_ID_SNOW) {
> > +w_align = 16;
> > +h_align = 16;
> > }
> > break;
> > case AV_PIX_FMT_RGB555:
>
> avcodec_align_dimensions2() is for decoders and happens to be used by
> ff_encode_alloc_frame(), too. But decoders should not be required to add
> more padding because the decoder needs more. Instead the encoder should
> add more padding itself (by using more than 2 * EDGE_WIDTH).
If you have verified that the decoder alignment is sufficient and 4:1:0 does not
need the alignment that 4:2:0 has for snow, then yes i can mess with some
EDGE_WIDTH uses in snow to fix the encoder crash
Again the snow decoder for 4:2:0 has 16x16 alignment, 4:1:0 has not
and its identical in the encoders
This is why it crashes, the patch corrects this difference.
I do not think thats a great differernce to have
If we keep the 4:2:0 and 4:1:0 difference in alignment then
what should i do about the encoder ?
adjust EDGE_WIDTH for 4:1:0 only ? because 4:2:0 has the buffer dimensions
aligned correctly
so it doesnt need it bumped up?
That would result in 4:2:0 having the alignment from
avcodec_align_dimensions2() for
decoder and encoder
and for 4:1:0 we would achieve something comparable with EDGE_WIDTH encoder
side only
and hope the decoder doesnt need it
This just doesnt sound like a step in the right direction
Also this as a security fix should be simple
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
It is a danger to trust the dream we wish for rather than
the science we have, -- Dr. Kenneth Brown
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/7] avcodec/ratecontrol: Handle wanted bits overflow
On Tue, Jun 18, 2024 at 03:48:22PM +0200, Michael Niedermayer wrote: > Fixes: 5.92611e+20 is outside the range of representable values of type > 'unsigned long' > Fixes: > 68984/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-5155755073273856 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/ratecontrol.c | 10 -- > 1 file changed, 8 insertions(+), 2 deletions(-) will apply patch 3 and 6 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends. -- Gandalf 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 5/5] avformat/iamf: Check substreams in ff_iamf_free_audio_element()
On Mon, Jun 24, 2024 at 01:01:37AM +0200, Michael Niedermayer wrote: > Fixes: member access within null pointer of type 'IAMFSubStream' (aka 'struct > IAMFSubStream') > Fixes: > 69795/clusterfuzz-testcase-minimized-ffmpeg_dem_IAMF_fuzzer-6216287009701888 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/iamf.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 "100% positive feedback" - "All either got their money back or didnt complain" "Best seller ever, very honest" - "Seller refunded buyer after failed scam" 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 v2] avcodec/hevc/hevcdec: Do not allow slices to depend on failed slices
An alternative would be to leave the context unchanged on failure of
hls_slice_header()
Fixes: out of array access
Fixes: NULL pointer dereference
Fixes:
69584/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5931086299856896
Fixes:
69724/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5104066422702080
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/hevc/hevcdec.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
index 0e4b26dad3b..80d59ab1916 100644
--- a/libavcodec/hevc/hevcdec.c
+++ b/libavcodec/hevc/hevcdec.c
@@ -621,6 +621,10 @@ static int hls_slice_header(SliceHeader *sh, const
HEVCContext *s, GetBitContext
if (pps->dependent_slice_segments_enabled_flag)
sh->dependent_slice_segment_flag = get_bits1(gb);
+if (sh->dependent_slice_segment_flag && !s->slice_initialized) {
+av_log(s->avctx, AV_LOG_ERROR, "dependent slice failed\n");
+return AVERROR_INVALIDDATA;
+}
slice_address_length = av_ceil_log2(sps->ctb_width *
sps->ctb_height);
@@ -893,9 +897,6 @@ static int hls_slice_header(SliceHeader *sh, const
HEVCContext *s, GetBitContext
} else {
sh->slice_loop_filter_across_slices_enabled_flag =
pps->seq_loop_filter_across_slices_enabled_flag;
}
-} else if (!s->slice_initialized) {
-av_log(s->avctx, AV_LOG_ERROR, "Independent slice segment missing.\n");
-return AVERROR_INVALIDDATA;
}
sh->num_entry_point_offsets = 0;
@@ -3155,8 +3156,11 @@ static int decode_slice(HEVCContext *s, const H2645NAL
*nal, GetBitContext *gb)
int ret;
ret = hls_slice_header(&s->sh, s, gb);
-if (ret < 0)
+if (ret < 0) {
+//The code is not capable to rewind from an error, the state now is
inconsistant so we cannot use it on depandant slices
+s->slice_initialized = 0;
return ret;
+}
if ((s->avctx->skip_frame >= AVDISCARD_BIDIR && s->sh.slice_type ==
HEVC_SLICE_B) ||
(s->avctx->skip_frame >= AVDISCARD_NONINTRA && s->sh.slice_type !=
HEVC_SLICE_I) ||
--
2.45.2
___
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] avutil/error: Provide better feedback about unknown error codes
AVERROR messages should always be less than zero,
and are usually based on three or four ASCII characters.
For error codes that aren't explicitly handled by error.c (e.g. FFERROR_REDO),
print the ASCII code so the user has a little more information.
If a non-negative number somehow gets passed to this function,
print a message saying this shouldn't happen.
---
libavutil/error.c | 32
1 file changed, 32 insertions(+)
diff --git a/libavutil/error.c b/libavutil/error.c
index 90bab7b9d3..c40b54b1f9 100644
--- a/libavutil/error.c
+++ b/libavutil/error.c
@@ -119,6 +119,38 @@ int av_strerror(int errnum, char *errbuf, size_t
errbuf_size)
}
if (entry) {
av_strlcpy(errbuf, entry->str, errbuf_size);
+} else if (
+-errnum <= 0x
+&& ((-errnum >> 0) & 0xFF) >= 0x20 && ((-errnum >> 0) & 0xFF) <= 0x7F
+&& ((-errnum >> 8) & 0xFF) >= 0x20 && ((-errnum >> 8) & 0xFF) <= 0x7F
+&& ((-errnum >> 16) & 0xFF) >= 0x20 && ((-errnum >> 16) & 0xFF) <= 0x7F
+&& (
+ (((-errnum >> 24) & 0xFF) >= 0x20 && ((-errnum >> 24) & 0xFF) <=
0x7F)
+ || !((-errnum >> 24) & 0xFF)
+)
+) {
+if ((-errnum >> 24) & 0xFF) {
+snprintf(
+errbuf,
+errbuf_size,
+"Unrecognised error code \"%c%c%c%c\" occurred",
+(-errnum >> 0) & 0xFF,
+(-errnum >> 8) & 0xFF,
+(-errnum >> 16) & 0xFF,
+(-errnum >> 24) & 0xFF
+);
+} else {
+snprintf(
+errbuf,
+errbuf_size,
+"Unrecognised error code \"%c%c%c\" occurred",
+(-errnum >> 0) & 0xFF,
+(-errnum >> 8) & 0xFF,
+(-errnum >> 16) & 0xFF
+);
+}
+} else if (errnum >= 0) {
+snprintf(errbuf, errbuf_size, "Impossible: non-negative error number
%d occurred", errnum);
} else {
#if HAVE_STRERROR_R
ret = AVERROR(strerror_r(AVUNERROR(errnum), errbuf, errbuf_size));
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/5] avformat/iamf: Check substreams in ff_iamf_free_audio_element()
On 6/23/2024 8:01 PM, Michael Niedermayer wrote:
Fixes: member access within null pointer of type 'IAMFSubStream' (aka 'struct
IAMFSubStream')
Fixes:
69795/clusterfuzz-testcase-minimized-ffmpeg_dem_IAMF_fuzzer-6216287009701888
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/iamf.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavformat/iamf.c b/libavformat/iamf.c
index 5de70dc0828..364cb60e021 100644
--- a/libavformat/iamf.c
+++ b/libavformat/iamf.c
@@ -74,8 +74,10 @@ void ff_iamf_free_audio_element(IAMFAudioElement
**paudio_element)
if (!audio_element)
return;
-for (int i = 0; i < audio_element->nb_substreams; i++)
-avcodec_parameters_free(&audio_element->substreams[i].codecpar);
+if (audio_element->nb_substreams)
+for (int i = 0; i < audio_element->nb_substreams; i++) {
+avcodec_parameters_free(&audio_element->substreams[i].codecpar);
+}
av_free(audio_element->substreams);
av_free(audio_element->layers);
av_iamf_audio_element_free(&audio_element->element);
Sorry, i missed this.
nb_substreams shouldn't be anything but 0 here if nb_substreams is NULL,
so the following is IMO better:
diff --git a/libavformat/iamf_parse.c b/libavformat/iamf_parse.c
index 9cec12d46f..a69d4a2f3a 100644
--- a/libavformat/iamf_parse.c
+++ b/libavformat/iamf_parse.c
@@ -594,7 +594,7 @@ static int audio_element_obu(void *s, IAMFContext *c,
AVIOContext *pb, int len)
FFIOContext b;
AVIOContext *pbc;
uint8_t *buf;
-unsigned audio_element_id, codec_config_id, num_parameters;
+unsigned audio_element_id, nb_substreams, codec_config_id, num_parameters;
int audio_element_type, ret;
buf = av_malloc(len);
@@ -649,14 +649,15 @@ static int audio_element_obu(void *s, IAMFContext *c,
AVIOContext *pb, int len)
goto fail;
}
-audio_element->nb_substreams = ffio_read_leb(pbc);
+nb_substreams = ffio_read_leb(pbc);
audio_element->codec_config_id = codec_config_id;
audio_element->audio_element_id = audio_element_id;
-audio_element->substreams = av_calloc(audio_element->nb_substreams,
sizeof(*audio_element->substreams));
+audio_element->substreams = av_calloc(nb_substreams,
sizeof(*audio_element->substreams));
if (!audio_element->substreams) {
ret = AVERROR(ENOMEM);
goto fail;
}
+audio_element->nb_substreams = nb_substreams;
element = audio_element->element = av_iamf_audio_element_alloc();
if (!element) {
___
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] avutil/error: Provide better feedback about unknown error codes
On Mon, 15 Jul 2024, Andrew Sayers wrote:
AVERROR messages should always be less than zero,
and are usually based on three or four ASCII characters.
For error codes that aren't explicitly handled by error.c (e.g. FFERROR_REDO),
print the ASCII code so the user has a little more information.
All ffmpeg internal error codes (including the ones having some special
tag representation) should be handled by error.c. The user should never
receive FFERROR_REDO, that is an internal error code, it should never
reach the user. Therefore I see no benefit in disclosing the error bytes,
because that is not the proper fix.
Regards,
Marton
If a non-negative number somehow gets passed to this function,
print a message saying this shouldn't happen.
---
libavutil/error.c | 32
1 file changed, 32 insertions(+)
diff --git a/libavutil/error.c b/libavutil/error.c
index 90bab7b9d3..c40b54b1f9 100644
--- a/libavutil/error.c
+++ b/libavutil/error.c
@@ -119,6 +119,38 @@ int av_strerror(int errnum, char *errbuf, size_t
errbuf_size)
}
if (entry) {
av_strlcpy(errbuf, entry->str, errbuf_size);
+} else if (
+-errnum <= 0x
+&& ((-errnum >> 0) & 0xFF) >= 0x20 && ((-errnum >> 0) & 0xFF) <= 0x7F
+&& ((-errnum >> 8) & 0xFF) >= 0x20 && ((-errnum >> 8) & 0xFF) <= 0x7F
+&& ((-errnum >> 16) & 0xFF) >= 0x20 && ((-errnum >> 16) & 0xFF) <= 0x7F
+&& (
+ (((-errnum >> 24) & 0xFF) >= 0x20 && ((-errnum >> 24) & 0xFF) <=
0x7F)
+ || !((-errnum >> 24) & 0xFF)
+)
+) {
+if ((-errnum >> 24) & 0xFF) {
+snprintf(
+errbuf,
+errbuf_size,
+"Unrecognised error code \"%c%c%c%c\" occurred",
+(-errnum >> 0) & 0xFF,
+(-errnum >> 8) & 0xFF,
+(-errnum >> 16) & 0xFF,
+(-errnum >> 24) & 0xFF
+);
+} else {
+snprintf(
+errbuf,
+errbuf_size,
+"Unrecognised error code \"%c%c%c\" occurred",
+(-errnum >> 0) & 0xFF,
+(-errnum >> 8) & 0xFF,
+(-errnum >> 16) & 0xFF
+);
+}
+} else if (errnum >= 0) {
+snprintf(errbuf, errbuf_size, "Impossible: non-negative error number %d
occurred", errnum);
} else {
#if HAVE_STRERROR_R
ret = AVERROR(strerror_r(AVUNERROR(errnum), errbuf, errbuf_size));
--
2.45.2
___
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] avutil/error: Provide better feedback about unknown error codes
On Mon, Jul 15, 2024 at 05:45:24PM +0200, Marton Balint wrote: > > > On Mon, 15 Jul 2024, Andrew Sayers wrote: > > > AVERROR messages should always be less than zero, > > and are usually based on three or four ASCII characters. > > > > For error codes that aren't explicitly handled by error.c (e.g. > > FFERROR_REDO), > > print the ASCII code so the user has a little more information. > > All ffmpeg internal error codes (including the ones having some special tag > representation) should be handled by error.c. The user should never receive > FFERROR_REDO, that is an internal error code, it should never reach the > user. Therefore I see no benefit in disclosing the error bytes, because that > is not the proper fix. > > Regards, > Marton So it sounds like this patch is addressing two separate issues: 1. any messages caught by the test in the patch represent a bug in FFmpeg * how about I modify this patch to ask the user to report the bug? * would the ASCII error code help with triage? 2. FFERROR_REDO should be added to error.c * let me know if I should submit a separate patch for this ___ 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] avcodec/vvc: Add aarch64 neon optimization for ALF
From: Zhao Zhili vvc_alf_filter_chroma_4x4_8_c: 3.0 vvc_alf_filter_chroma_4x4_8_neon: 1.0 vvc_alf_filter_chroma_4x4_10_c: 2.7 vvc_alf_filter_chroma_4x4_10_neon: 1.0 vvc_alf_filter_chroma_4x4_12_c: 2.7 vvc_alf_filter_chroma_4x4_12_neon: 1.0 vvc_alf_filter_chroma_8x8_8_c: 10.2 vvc_alf_filter_chroma_8x8_8_neon: 3.0 vvc_alf_filter_chroma_8x8_10_c: 10.0 vvc_alf_filter_chroma_8x8_10_neon: 2.5 vvc_alf_filter_chroma_8x8_12_c: 10.0 vvc_alf_filter_chroma_8x8_12_neon: 2.5 vvc_alf_filter_chroma_16x16_8_c: 41.7 vvc_alf_filter_chroma_16x16_8_neon: 11.2 vvc_alf_filter_chroma_16x16_10_c: 39.0 vvc_alf_filter_chroma_16x16_10_neon: 10.0 vvc_alf_filter_chroma_16x16_12_c: 40.2 vvc_alf_filter_chroma_16x16_12_neon: 10.2 vvc_alf_filter_chroma_32x32_8_c: 162.0 vvc_alf_filter_chroma_32x32_8_neon: 45.0 vvc_alf_filter_chroma_32x32_10_c: 155.5 vvc_alf_filter_chroma_32x32_10_neon: 39.5 vvc_alf_filter_chroma_32x32_12_c: 155.5 vvc_alf_filter_chroma_32x32_12_neon: 40.0 vvc_alf_filter_chroma_64x64_8_c: 646.0 vvc_alf_filter_chroma_64x64_8_neon: 175.5 vvc_alf_filter_chroma_64x64_10_c: 708.2 vvc_alf_filter_chroma_64x64_10_neon: 166.7 vvc_alf_filter_chroma_64x64_12_c: 619.2 vvc_alf_filter_chroma_64x64_12_neon: 157.2 vvc_alf_filter_chroma_128x128_8_c: 2611.5 vvc_alf_filter_chroma_128x128_8_neon: 698.2 vvc_alf_filter_chroma_128x128_10_c: 2470.0 vvc_alf_filter_chroma_128x128_10_neon: 616.0 vvc_alf_filter_chroma_128x128_12_c: 2531.5 vvc_alf_filter_chroma_128x128_12_neon: 620.2 vvc_alf_filter_luma_8x8_8_c: 25.2 vvc_alf_filter_luma_8x8_8_neon: 4.2 vvc_alf_filter_luma_8x8_10_c: 18.5 vvc_alf_filter_luma_8x8_10_neon: 4.0 vvc_alf_filter_luma_8x8_12_c: 19.0 vvc_alf_filter_luma_8x8_12_neon: 4.0 vvc_alf_filter_luma_16x16_8_c: 106.5 vvc_alf_filter_luma_16x16_8_neon: 16.2 vvc_alf_filter_luma_16x16_10_c: 75.2 vvc_alf_filter_luma_16x16_10_neon: 14.7 vvc_alf_filter_luma_16x16_12_c: 79.7 vvc_alf_filter_luma_16x16_12_neon: 14.7 vvc_alf_filter_luma_32x32_8_c: 400.5 vvc_alf_filter_luma_32x32_8_neon: 63.2 vvc_alf_filter_luma_32x32_10_c: 299.2 vvc_alf_filter_luma_32x32_10_neon: 57.7 vvc_alf_filter_luma_32x32_12_c: 299.2 vvc_alf_filter_luma_32x32_12_neon: 57.7 vvc_alf_filter_luma_64x64_8_c: 1602.5 vvc_alf_filter_luma_64x64_8_neon: 251.7 vvc_alf_filter_luma_64x64_10_c: 1197.0 vvc_alf_filter_luma_64x64_10_neon: 235.5 vvc_alf_filter_luma_64x64_12_c: 1220.2 vvc_alf_filter_luma_64x64_12_neon: 235.7 vvc_alf_filter_luma_128x128_8_c: 6570.2 vvc_alf_filter_luma_128x128_8_neon: 1007.7 vvc_alf_filter_luma_128x128_10_c: 4822.7 vvc_alf_filter_luma_128x128_10_neon: 936.2 vvc_alf_filter_luma_128x128_12_c: 4791.2 vvc_alf_filter_luma_128x128_12_neon: 938.5 Signed-off-by: Zhao Zhili --- libavcodec/aarch64/vvc/Makefile | 5 + libavcodec/aarch64/vvc/alf.S | 293 ++ libavcodec/aarch64/vvc/alf_template.c | 157 ++ libavcodec/aarch64/vvc/dsp_init.c | 57 + libavcodec/vvc/dsp.c | 4 +- libavcodec/vvc/dsp.h | 1 + 6 files changed, 516 insertions(+), 1 deletion(-) create mode 100644 libavcodec/aarch64/vvc/Makefile create mode 100644 libavcodec/aarch64/vvc/alf.S create mode 100644 libavcodec/aarch64/vvc/alf_template.c create mode 100644 libavcodec/aarch64/vvc/dsp_init.c diff --git a/libavcodec/aarch64/vvc/Makefile b/libavcodec/aarch64/vvc/Makefile new file mode 100644 index 00..58398d6e3d --- /dev/null +++ b/libavcodec/aarch64/vvc/Makefile @@ -0,0 +1,5 @@ +clean:: + $(RM) $(CLEANSUFFIXES:%=libavcodec/aarch64/vvc/%) + +OBJS-$(CONFIG_VVC_DECODER) += aarch64/vvc/dsp_init.o +NEON-OBJS-$(CONFIG_VVC_DECODER)+= aarch64/vvc/alf.o diff --git a/libavcodec/aarch64/vvc/alf.S b/libavcodec/aarch64/vvc/alf.S new file mode 100644 index 00..beb36ac66b --- /dev/null +++ b/libavcodec/aarch64/vvc/alf.S @@ -0,0 +1,293 @@ +/* + * Copyright (c) 2024 Zhao Zhili + * + * 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/aarch64/asm.S" + +.macro alf_luma_filter_pixel index, pix_size, addr1, addr2, offset1, offset2 +.if \pix_size == 1 +ldurd3, [\addr1, #\offset1] +ldurd4, [\addr2, #\offset2] +uxtlv6.8h, v3.8b +uxtlv7.8h, v4.8b
Re: [FFmpeg-devel] [PATCH] avcodec/h264_mp4toannexb: Prepend SPS/PPS to buffering period SEI
On Tue, 9 Jul 2024 at 12:06, Josh Allmann wrote:
>
> Encoders may emit a buffering period SEI without a corresponding
> SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc.
>
> During Annex B conversion, this may result in the SPS/PPS being
> inserted *after* the buffering period SEI but before the IDR NAL.
>
> Since the buffering period SEI references the SPS, the SPS/PPS
> needs to come first.
> ---
>
> Notes:
> v2: Updated FATE test refs
>
> libavcodec/bsf/h264_mp4toannexb.c | 13 +
> tests/ref/fate/h264-bsf-mp4toannexb| 2 +-
> tests/ref/fate/h264_mp4toannexb_ticket2991 | 18 +-
> tests/ref/fate/segment-mp4-to-ts | 12 ++--
> 4 files changed, 29 insertions(+), 16 deletions(-)
>
Ping for review. Looking at the FATE output, this patch fixes a number
of things - see [1] for details
[1] https://ffmpeg.org//pipermail/ffmpeg-devel/2024-July/330964.html
> diff --git a/libavcodec/bsf/h264_mp4toannexb.c
> b/libavcodec/bsf/h264_mp4toannexb.c
> index 92af6a6881..6607f1e91a 100644
> --- a/libavcodec/bsf/h264_mp4toannexb.c
> +++ b/libavcodec/bsf/h264_mp4toannexb.c
> @@ -363,6 +363,19 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx,
> AVPacket *opkt)
> if (!new_idr && unit_type == H264_NAL_IDR_SLICE && (buf[1] &
> 0x80))
> new_idr = 1;
>
> +/* If this is a buffering period SEI without a corresponding
> sps/pps
> + * then prepend any existing sps/pps before the SEI */
> +if (unit_type == H264_NAL_SEI && buf[1] == 0 && !sps_seen &&
> !pps_seen) {
> +if (s->sps_size) {
> +count_or_copy(&out, &out_size, s->sps, s->sps_size,
> PS_OUT_OF_BAND, j);
> +sps_seen = 1;
> +}
> +if (s->pps_size) {
> +count_or_copy(&out, &out_size, s->pps, s->pps_size,
> PS_OUT_OF_BAND, j);
> +pps_seen = 1;
> +}
> +}
> +
> /* prepend only to the first type 5 NAL unit of an IDR picture,
> if no sps/pps are already present */
> if (new_idr && unit_type == H264_NAL_IDR_SLICE && !sps_seen &&
> !pps_seen) {
> if (s->sps_size)
> diff --git a/tests/ref/fate/h264-bsf-mp4toannexb
> b/tests/ref/fate/h264-bsf-mp4toannexb
> index 2049f39701..81ff568f3d 100644
> --- a/tests/ref/fate/h264-bsf-mp4toannexb
> +++ b/tests/ref/fate/h264-bsf-mp4toannexb
> @@ -1 +1 @@
> -5f04c27cc6ee8625fe2405fb0f7da9a3
> +ff2551123909f54c382294baa1bb4364
> diff --git a/tests/ref/fate/h264_mp4toannexb_ticket2991
> b/tests/ref/fate/h264_mp4toannexb_ticket2991
> index f8e3e920d4..9a1fbf2f8c 100644
> --- a/tests/ref/fate/h264_mp4toannexb_ticket2991
> +++ b/tests/ref/fate/h264_mp4toannexb_ticket2991
> @@ -1,4 +1,4 @@
> -05d66e60ab22ee004720e0051af0fe74
> *tests/data/fate/h264_mp4toannexb_ticket2991.h264
> +b6ff5910928ad0b2a7eec481dcc41594
> *tests/data/fate/h264_mp4toannexb_ticket2991.h264
> 1985815 tests/data/fate/h264_mp4toannexb_ticket2991.h264
> #extradata 0: 47, 0x3a590d55
> #tb 0: 1/120
> @@ -6,7 +6,7 @@
> #codec_id 0: h264
> #dimensions 0: 1280x720
> #sar 0: 3/4
> -0, 0, 0,40040,37126, 0xb020184c
> +0, 0, 0,40040,37126, 0x515c184c
> 0, 40040, 40040,40040, 6920, 0x8512361a, F=0x0
> 0, 80081, 80081,40040, 7550, 0x1bc56ed4, F=0x0
> 0, 120121, 120121,40040, 8752, 0xb8c6f0a1, F=0x0
> @@ -21,7 +21,7 @@
> 0, 480485, 480485,40040,11234, 0x83cbd9fd, F=0x0
> 0, 520525, 520525,40040,17616, 0xfdf95104, F=0x0
> 0, 560566, 560566,40040,10689, 0x9633d32b, F=0x0
> -0, 600606, 600606,40040,45291, 0x543c2cf6
> +0, 600606, 600606,40040,45291, 0xa8292cf6
> 0, 640646, 640646,40040,20837, 0x051abfab, F=0x0
> 0, 680687, 680687,40040,21418, 0xe2a59d70, F=0x0
> 0, 720727, 720727,40040,15643, 0x15cf2cec, F=0x0
> @@ -36,7 +36,7 @@
> 0,1081091,1081091,40040,13130, 0xcbb6bb8e, F=0x0
> 0,1121131,1121131,40040,16180, 0x5d188a7a, F=0x0
> 0,1161172,1161172,40040,14961, 0x9ff2f463, F=0x0
> -0,1201212,1201212,40040,54296, 0xe6ec30ed
> +0,1201212,1201212,40040,54296, 0x3ae830ed
> 0,1241252,1241252,40040,11500, 0x8c4852c9, F=0x0
> 0,1281293,1281293,40040,12065, 0xfb7954c3, F=0x0
> 0,1321333,1321333,40040,12532, 0xf0a935d3, F=0x0
> @@ -51,7 +51,7 @@
> 0,1681697,1681697,40040,13250, 0xfed0deb8, F=0x0
> 0,1721737,1721737,40040,13360, 0xbf92d476, F=0x0
> 0,1761778,1761778,40040,11749, 0x3041eaf1, F=0x0
> -0,1801818,1801818,40040,23997, 0xdbe6d5c4
> +0,1801818,1801818,40040,23997, 0x2fe2d5c4
> 0,
Re: [FFmpeg-devel] [PATCH] avcodec/h264_mp4toannexb: Prepend SPS/PPS to buffering period SEI
On Mon, 15 Jul 2024 at 10:48, Josh Allmann wrote: > > On Tue, 9 Jul 2024 at 12:06, Josh Allmann wrote: > > > > Encoders may emit a buffering period SEI without a corresponding > > SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc. > > > > During Annex B conversion, this may result in the SPS/PPS being > > inserted *after* the buffering period SEI but before the IDR NAL. > > > > Since the buffering period SEI references the SPS, the SPS/PPS > > needs to come first. > > --- > > > > Notes: > > v2: Updated FATE test refs > > > > libavcodec/bsf/h264_mp4toannexb.c | 13 + > > tests/ref/fate/h264-bsf-mp4toannexb| 2 +- > > tests/ref/fate/h264_mp4toannexb_ticket2991 | 18 +- > > tests/ref/fate/segment-mp4-to-ts | 12 ++-- > > 4 files changed, 29 insertions(+), 16 deletions(-) > > > > Ping for review. Looking at the FATE output, this patch fixes a number > of things - see [1] for details > > [1] https://ffmpeg.org//pipermail/ffmpeg-devel/2024-July/330964.html Pasted the wrong link - please see this for a review of the FATE test changes https://ffmpeg.org//pipermail/ffmpeg-devel/2024-July/330912.html ___ 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/4] avcodec/cbs_h265: fix range of sps_max_sub_layers_minus1
On 7/13/2024 11:58 AM, James Almer wrote:
The VPS referenced by the SPS must always be present as the max value for
sps_max_sub_layers_minus1 is vps_max_sub_layers_minus1. This replaces a buggy
custom range check for the aforementioned field.
Also, add the missing conformance check for sps_temporal_id_nesting_flag while
at it.
Signed-off-by: James Almer
---
libavcodec/cbs_h265_syntax_template.c | 37 +++
1 file changed, 20 insertions(+), 17 deletions(-)
diff --git a/libavcodec/cbs_h265_syntax_template.c
b/libavcodec/cbs_h265_syntax_template.c
index 86ca00a0c9..c6db439b3b 100644
--- a/libavcodec/cbs_h265_syntax_template.c
+++ b/libavcodec/cbs_h265_syntax_template.c
@@ -788,25 +788,28 @@ static int FUNC(sps)(CodedBitstreamContext *ctx,
RWContext *rw,
ub(4, sps_video_parameter_set_id);
h265->active_vps = vps = h265->vps[current->sps_video_parameter_set_id];
+if (!vps) {
+av_log(ctx->log_ctx, AV_LOG_ERROR, "VPS id %d not available.\n",
+ current->sps_video_parameter_set_id);
+return AVERROR_INVALIDDATA;
+}
-u(3, sps_max_sub_layers_minus1, 0, HEVC_MAX_SUB_LAYERS - 1);
+u(3, sps_max_sub_layers_minus1, 0, vps->vps_max_sub_layers_minus1);
flag(sps_temporal_id_nesting_flag);
-if (vps) {
-if (vps->vps_max_sub_layers_minus1 >
current->sps_max_sub_layers_minus1) {
-av_log(ctx->log_ctx, AV_LOG_ERROR, "Invalid stream: "
- "sps_max_sub_layers_minus1 (%d) must be less than or equal to
"
- "vps_max_sub_layers_minus1 (%d).\n",
- vps->vps_max_sub_layers_minus1,
- current->sps_max_sub_layers_minus1);
-return AVERROR_INVALIDDATA;
-}
-if (vps->vps_temporal_id_nesting_flag &&
-!current->sps_temporal_id_nesting_flag) {
-av_log(ctx->log_ctx, AV_LOG_ERROR, "Invalid stream: "
- "sps_temporal_id_nesting_flag must be 1 if "
- "vps_temporal_id_nesting_flag is 1.\n");
-return AVERROR_INVALIDDATA;
-}
+
+if (vps->vps_temporal_id_nesting_flag &&
+!current->sps_temporal_id_nesting_flag) {
+av_log(ctx->log_ctx, AV_LOG_ERROR, "Invalid stream: "
+ "sps_temporal_id_nesting_flag must be 1 if "
+ "vps_temporal_id_nesting_flag is 1.\n");
+return AVERROR_INVALIDDATA;
+}
+if (current->sps_max_sub_layers_minus1 == 0 &&
+current->sps_temporal_id_nesting_flag != 1) {
+av_log(ctx->log_ctx, AV_LOG_ERROR, "Invalid stream: "
+ "sps_temporal_id_nesting_flag must be 1 if "
+ "sps_max_sub_layers_minus1 is 0.\n");
+return AVERROR_INVALIDDATA;
}
CHECK(FUNC(profile_tier_level)(ctx, rw, ¤t->profile_tier_level,
Will apply set.
___
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/h264dsp: R-V V high-depth idct_add{, intra}16, idct8_add4
As with 8-bit, this tends to be faster, but results are all over the
place due to the variable distribution of non-zero coefficients.
---
libavcodec/riscv/h264dsp_init.c | 77 +
libavcodec/riscv/h264idct_rvv.S | 147 +---
2 files changed, 154 insertions(+), 70 deletions(-)
diff --git a/libavcodec/riscv/h264dsp_init.c b/libavcodec/riscv/h264dsp_init.c
index 4fc695f158..14eea29892 100644
--- a/libavcodec/riscv/h264dsp_init.c
+++ b/libavcodec/riscv/h264dsp_init.c
@@ -40,26 +40,25 @@ void ff_h264_h_loop_filter_luma_8_rvv(uint8_t *pix,
ptrdiff_t stride,
void ff_h264_h_loop_filter_luma_mbaff_8_rvv(uint8_t *pix, ptrdiff_t stride,
int alpha, int beta, int8_t *tc0);
-void ff_h264_idct_add_8_rvv(uint8_t *dst, int16_t *block, int stride);
-void ff_h264_idct8_add_8_rvv(uint8_t *dst, int16_t *block, int stride);
-void ff_h264_idct_add16_8_rvv(uint8_t *dst, const int *blockoffset,
- int16_t *block, int stride,
- const uint8_t nnzc[5 * 8]);
-void ff_h264_idct_add16intra_8_rvv(uint8_t *dst, const int *blockoffset,
- int16_t *block, int stride,
- const uint8_t nnzc[5 * 8]);
-void ff_h264_idct8_add4_8_rvv(uint8_t *dst, const int *blockoffset,
- int16_t *block, int stride,
- const uint8_t nnzc[5 * 8]);
-
-void ff_h264_idct_add_9_rvv(uint8_t *dst, int16_t *block, int stride);
-void ff_h264_idct8_add_9_rvv(uint8_t *dst, int16_t *block, int stride);
-void ff_h264_idct_add_10_rvv(uint8_t *dst, int16_t *block, int stride);
-void ff_h264_idct8_add_10_rvv(uint8_t *dst, int16_t *block, int stride);
-void ff_h264_idct_add_12_rvv(uint8_t *dst, int16_t *block, int stride);
-void ff_h264_idct8_add_12_rvv(uint8_t *dst, int16_t *block, int stride);
-void ff_h264_idct_add_14_rvv(uint8_t *dst, int16_t *block, int stride);
-void ff_h264_idct8_add_14_rvv(uint8_t *dst, int16_t *block, int stride);
+#define IDCT_DEPTH(depth) \
+void ff_h264_idct_add_##depth##_rvv(uint8_t *d, int16_t *s, int stride); \
+void ff_h264_idct8_add_##depth##_rvv(uint8_t *d, int16_t *s, int stride); \
+void ff_h264_idct_add16_##depth##_rvv(uint8_t *d, const int *soffset, \
+ int16_t *s, int stride, \
+ const uint8_t nnzc[5 * 8]); \
+void ff_h264_idct_add16intra_##depth##_rvv(uint8_t *d, const int *soffset, \
+ int16_t *s, int stride, \
+ const uint8_t nnzc[5 * 8]); \
+void ff_h264_idct8_add4_##depth##_rvv(uint8_t *d, const int *soffset, \
+ int16_t *s, int stride, \
+ const uint8_t nnzc[5 * 8]);
+
+IDCT_DEPTH(8)
+IDCT_DEPTH(9)
+IDCT_DEPTH(10)
+IDCT_DEPTH(12)
+IDCT_DEPTH(14)
+#undef IDCT_DEPTH
void ff_h264_add_pixels8_8_rvv(uint8_t *dst, int16_t *block, int stride);
void ff_h264_add_pixels4_8_rvv(uint8_t *dst, int16_t *block, int stride);
@@ -106,26 +105,26 @@ av_cold void ff_h264dsp_init_riscv(H264DSPContext *dsp,
const int bit_depth,
dsp->h264_add_pixels4_clear = ff_h264_add_pixels4_8_rvv;
}
-if (bit_depth == 9) {
-if (zvl128b)
-dsp->h264_idct_add = ff_h264_idct_add_9_rvv;
-dsp->h264_idct8_add = ff_h264_idct8_add_9_rvv;
-}
-if (bit_depth == 10) {
-if (zvl128b)
-dsp->h264_idct_add = ff_h264_idct_add_10_rvv;
-dsp->h264_idct8_add = ff_h264_idct8_add_10_rvv;
-}
-if (bit_depth == 12) {
-if (zvl128b)
-dsp->h264_idct_add = ff_h264_idct_add_12_rvv;
-dsp->h264_idct8_add = ff_h264_idct8_add_12_rvv;
-}
-if (bit_depth == 14) {
-if (zvl128b)
-dsp->h264_idct_add = ff_h264_idct_add_14_rvv;
-dsp->h264_idct8_add = ff_h264_idct8_add_14_rvv;
+#define IDCT_DEPTH(depth) \
+if (bit_depth == depth) { \
+if (zvl128b) \
+dsp->h264_idct_add = ff_h264_idct_add_##depth##_rvv; \
+if (flags & AV_CPU_FLAG_RVB_ADDR) \
+dsp->h264_idct8_add = ff_h264_idct8_add_##depth##_rvv; \
+if (__riscv_xlen == 64 && zvl128b) { \
+dsp->h264_idct_add16 = ff_h264_idct_add16_##depth##_rvv; \
+dsp->h264_idct_add16intra = \
+ff_h264_idct_add16intra_##depth##_rvv; \
+} \
+if (__riscv_xlen == 64 && (flags & AV_CPU_FLAG_RVB_ADDR)) \
+dsp->h264_idct8_add4 = ff_h264_idct8_add4_##depth##_rvv; \
}
+
+IDCT_DEPTH(9)
+IDCT_DEPTH(10)
+IDCT_DEPTH(12)
+IDCT_DEPTH(14)
+
if (bit_depth > 8 && zvl128b) {
dsp->h264_add_pixels8_clear = ff_h264_add_pixels8_16_rvv;
if (flags
Re: [FFmpeg-devel] [PATCH] avutil/error: Provide better feedback about unknown error codes
On Mon, 15 Jul 2024, Andrew Sayers wrote: On Mon, Jul 15, 2024 at 05:45:24PM +0200, Marton Balint wrote: On Mon, 15 Jul 2024, Andrew Sayers wrote: AVERROR messages should always be less than zero, and are usually based on three or four ASCII characters. For error codes that aren't explicitly handled by error.c (e.g. FFERROR_REDO), print the ASCII code so the user has a little more information. All ffmpeg internal error codes (including the ones having some special tag representation) should be handled by error.c. The user should never receive FFERROR_REDO, that is an internal error code, it should never reach the user. Therefore I see no benefit in disclosing the error bytes, because that is not the proper fix. Regards, Marton So it sounds like this patch is addressing two separate issues: 1. any messages caught by the test in the patch represent a bug in FFmpeg * how about I modify this patch to ask the user to report the bug? * would the ASCII error code help with triage? I don't really like adding extra code for this, and from an API point of view any negative error code can be valid, so you can't really warn about them. If you want to make sure that every ffmpeg error code has a text, then add a fate test for checking it. 2. FFERROR_REDO should be added to error.c * let me know if I should submit a separate patch for this FFERROR_REDO is an avformat internal error code, av_strerror() being in avutil cannot properly support it. Regards, 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] libavformat/tls_mbedtls: Changes the return code handling of mbedtls_x509_crt_parse_file
Could do. What level were you thinking? WARN? On 14/07/2024 17:29, Marth64 wrote: av_log(h, AV_LOG_DEBUG, "mbedtls_x509_crt_parse_file skipped %d certificate(s)\n", ret); Is it worth it making this a higher log level? Or is it too much noise? Thinking if it’s important security information to share with the user. ___ 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". 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] libavformat/tls_mbedtls: Changes the return code handling of mbedtls_x509_crt_parse_file
> Could do. What level were you thinking? WARN? How about, ``` av_log(h, AV_LOG_WARNING, "Failed to process %d certificate(s) from the CA bundle, ignoring these certificates\n", ret); ``` Thank you, ___ 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] fate/png: add mDCv and cLLi read and write test
This test confirms that we can write mDCv and cLLi chunks and read them back via the png decoder. It uses an HEVC conformance sample with this metadata as the base source for the side data in the frames. Signed-off-by: Leo Izen Reported-by: Jan Ekström Reviewed-by: Jan Ekström Reviewed-by: Andreas Rheinhardt --- tests/fate/image.mak| 6 ++ tests/ref/fate/png-mdcv | 22 ++ 2 files changed, 28 insertions(+) create mode 100644 tests/ref/fate/png-mdcv diff --git a/tests/fate/image.mak b/tests/fate/image.mak index 753936ec20..042cf6438f 100644 --- a/tests/fate/image.mak +++ b/tests/fate/image.mak @@ -416,6 +416,12 @@ FATE_PNG_PROBE-$(call ALLYES, LCMS2) += fate-png-icc-parse fate-png-icc-parse: CMD = run ffprobe$(PROGSSUF)$(EXESUF) -show_frames \ -flags2 icc_profiles $(TARGET_SAMPLES)/png1/lena-int_rgb24.png +FATE_PNG_TRANSCODE-$(call TRANSCODE, PNG HEVC, IMAGE2PIPE HEVC, \ +IMAGE_PNG_PIPE_DEMUXER HEVC_PARSER PNG_DECODER SCALE_FILTER) += fate-png-mdcv +fate-png-mdcv: CMD = transcode hevc $(TARGET_SAMPLES)/hevc/hdr10_plus_h265_sample.hevc image2pipe \ +"-pix_fmt rgb24 -vf scale -c png" "" \ +"-show_frames -show_entries frame=side_data_list -of flat" + FATE_PNG-$(call DEMDEC, IMAGE2, PNG) += $(FATE_PNG) FATE_PNG_PROBE-$(call DEMDEC, IMAGE2, PNG) += $(FATE_PNG_PROBE) FATE_IMAGE_FRAMECRC += $(FATE_PNG-yes) diff --git a/tests/ref/fate/png-mdcv b/tests/ref/fate/png-mdcv new file mode 100644 index 00..c524a94ded --- /dev/null +++ b/tests/ref/fate/png-mdcv @@ -0,0 +1,22 @@ +fc68fe6c8c72343b96d2695f6913995b *tests/data/fate/png-mdcv.image2pipe +439248 tests/data/fate/png-mdcv.image2pipe +#tb 0: 1/25 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 1280x720 +#sar 0: 0/1 +0, 0, 0,1, 2764800, 0x2bfc7b42 +frames.frame.0.side_data_list.side_data.0.side_data_type="Content light level metadata" +frames.frame.0.side_data_list.side_data.0.max_content=1000 +frames.frame.0.side_data_list.side_data.0.max_average=200 +frames.frame.0.side_data_list.side_data.1.side_data_type="Mastering display metadata" +frames.frame.0.side_data_list.side_data.1.red_x="13250/5" +frames.frame.0.side_data_list.side_data.1.red_y="7500/5" +frames.frame.0.side_data_list.side_data.1.green_x="34000/5" +frames.frame.0.side_data_list.side_data.1.green_y="16000/5" +frames.frame.0.side_data_list.side_data.1.blue_x="2/5" +frames.frame.0.side_data_list.side_data.1.blue_y="0/5" +frames.frame.0.side_data_list.side_data.1.white_point_x="15635/5" +frames.frame.0.side_data_list.side_data.1.white_point_y="16450/5" +frames.frame.0.side_data_list.side_data.1.min_luminance="50/1" +frames.frame.0.side_data_list.side_data.1.max_luminance="1000/1" -- 2.45.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/png: more informative error message for invalid sBIT size
On 7/12/24 3:03 PM, Leo Izen wrote: If the sBIT chunk size is invalid, we should print a more informative error message rather than return an error and print nothing. Signed-off-by: Leo Izen --- libavcodec/pngdec.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) Will merge soon. - Leo Izen (Traneptora) ___ 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] avcodec/vvc: Remove NOP condition check in alf_filter_luma
From: Zhao Zhili
If (y + i == vb_above) or (y + i == vb_below), the if body has no
operation.
---
libavcodec/vvc/filter_template.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vvc/filter_template.c b/libavcodec/vvc/filter_template.c
index 9b3a0e46f7..32777452b7 100644
--- a/libavcodec/vvc/filter_template.c
+++ b/libavcodec/vvc/filter_template.c
@@ -77,7 +77,7 @@ static void FUNC(alf_filter_luma)(uint8_t *_dst, ptrdiff_t
dst_stride, const uin
const int is_near_vb_below = (y + i >= vb_pos) && (y + i <=
vb_pos);
const int is_near_vb = is_near_vb_above || is_near_vb_below;
-if ((y + i < vb_pos) && ((y + i) >= vb_above)) {
+if ((y + i < vb_pos) && ((y + i) > vb_above)) {
p1 = (y + i == vb_pos - 1) ? p0 : p1;
p3 = (y + i >= vb_pos - 2) ? p1 : p3;
p5 = (y + i >= vb_pos - 3) ? p3 : p5;
@@ -85,7 +85,7 @@ static void FUNC(alf_filter_luma)(uint8_t *_dst, ptrdiff_t
dst_stride, const uin
p2 = (y + i == vb_pos - 1) ? p0 : p2;
p4 = (y + i >= vb_pos - 2) ? p2 : p4;
p6 = (y + i >= vb_pos - 3) ? p4 : p6;
-} else if ((y + i >= vb_pos) && ((y + i) <= vb_below)) {
+} else if ((y + i >= vb_pos) && ((y + i) < vb_below)) {
p2 = (y + i == vb_pos) ? p0 : p2;
p4 = (y + i <= vb_pos + 1) ? p2 : p4;
p6 = (y + i <= vb_pos + 2) ? p4 : p6;
--
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 2/2] avcodec/vvc: Remove write-only assignments in alf_filter_chroma
From: Zhao Zhili
---
libavcodec/vvc/filter_template.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/libavcodec/vvc/filter_template.c b/libavcodec/vvc/filter_template.c
index 32777452b7..6dd7310089 100644
--- a/libavcodec/vvc/filter_template.c
+++ b/libavcodec/vvc/filter_template.c
@@ -153,8 +153,6 @@ static void FUNC(alf_filter_chroma)(uint8_t* _dst,
ptrdiff_t dst_stride, const u
const pixel *s2 = s0 - src_stride;
const pixel *s3 = s1 + src_stride;
const pixel *s4 = s2 - src_stride;
-const pixel *s5 = s3 + src_stride;
-const pixel *s6 = s4 - src_stride;
for (int i = 0; i < ALF_BLOCK_SIZE; i++) {
pixel *dst = (pixel *)_dst + (y + i) * dst_stride + x;
@@ -164,8 +162,6 @@ static void FUNC(alf_filter_chroma)(uint8_t* _dst,
ptrdiff_t dst_stride, const u
const pixel *p2 = s2 + i * src_stride;
const pixel *p3 = s3 + i * src_stride;
const pixel *p4 = s4 + i * src_stride;
-const pixel *p5 = s5 + i * src_stride;
-const pixel *p6 = s6 + i * src_stride;
const int is_near_vb_above = (y + i < vb_pos) && (y + i >=
vb_pos - 1);
const int is_near_vb_below = (y + i >= vb_pos) && (y + i <=
vb_pos);
@@ -174,19 +170,15 @@ static void FUNC(alf_filter_chroma)(uint8_t* _dst,
ptrdiff_t dst_stride, const u
if ((y + i < vb_pos) && ((y + i) >= vb_above)) {
p1 = (y + i == vb_pos - 1) ? p0 : p1;
p3 = (y + i >= vb_pos - 2) ? p1 : p3;
-p5 = (y + i >= vb_pos - 3) ? p3 : p5;
p2 = (y + i == vb_pos - 1) ? p0 : p2;
p4 = (y + i >= vb_pos - 2) ? p2 : p4;
-p6 = (y + i >= vb_pos - 3) ? p4 : p6;
} else if ((y + i >= vb_pos) && ((y + i) <= vb_below)) {
p2 = (y + i == vb_pos) ? p0 : p2;
p4 = (y + i <= vb_pos + 1) ? p2 : p4;
-p6 = (y + i <= vb_pos + 2) ? p4 : p6;
p1 = (y + i == vb_pos) ? p0 : p1;
p3 = (y + i <= vb_pos + 1) ? p1 : p3;
-p5 = (y + i <= vb_pos + 2) ? p3 : p5;
}
for (int j = 0; j < ALF_BLOCK_SIZE; j++) {
@@ -212,8 +204,6 @@ static void FUNC(alf_filter_chroma)(uint8_t* _dst,
ptrdiff_t dst_stride, const u
p2++;
p3++;
p4++;
-p5++;
-p6++;
}
}
}
--
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 1/1] fftools/ffmpeg_opt: Exit with non-zero status when destination exists
Gyan: > The former is not an error. The user was asked and the application > behaved as per their reply. Could it make sense to only return the AVERROR(EEXIST) if -nostdin is passed (otherwise current behavior)? I have observed this behavior too and think it's strange only in the -nostdin case. ___ 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] configure: remove TILE-Gx and TILE-Pro due to lack of compiler support
GCC removed support for them in versions >= 13.0, and there was never any acceleration or compat code generated for these targets. --- configure | 5 - 1 file changed, 5 deletions(-) diff --git a/configure b/configure index f84fefeaab..6777fc038f 100755 --- a/configure +++ b/configure @@ -2145,8 +2145,6 @@ ARCH_LIST=" s390 sparc sparc64 -tilegx -tilepro x86 x86_32 x86_64 @@ -5254,9 +5252,6 @@ case "$arch" in sun4*|sparc*) arch="sparc" ;; -tilegx|tile-gx) -arch="tilegx" -;; i[3-6]86*|i86pc|BePC|x86pc|x86_64|x86_32|amd64) arch="x86" ;; -- 2.39.2 ___ 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/1] fftools/ffmpeg_opt: Exit with non-zero status when destination exists
On 2024-07-16 09:40 am, Marth64 wrote: Gyan: The former is not an error. The user was asked and the application behaved as per their reply. Could it make sense to only return the AVERROR(EEXIST) if -nostdin is passed (otherwise current behavior)? Agreed. Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
