[FFmpeg-devel] [PATCH 1/3] hwcontext_d3d11va: add mutiple supported DXGI formats
Add support for VUYX, YUYV422, Y210, XV30, P012, Y212, XV36.
The added formats work with qsv acceleration and will not have
impact on d3d11va acceleration(-hwaccel d3d11va) since so far
these formats are still not supported by using d3d11va acceleration.
Signed-off-by: Tong Wu
---
libavutil/hwcontext_d3d11va.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index 363ec6a47d..aa50538d64 100644
--- a/libavutil/hwcontext_d3d11va.c
+++ b/libavutil/hwcontext_d3d11va.c
@@ -89,6 +89,13 @@ static const struct {
{ DXGI_FORMAT_B8G8R8A8_UNORM,AV_PIX_FMT_BGRA },
{ DXGI_FORMAT_R10G10B10A2_UNORM, AV_PIX_FMT_X2BGR10 },
{ DXGI_FORMAT_R16G16B16A16_FLOAT, AV_PIX_FMT_RGBAF16 },
+{ DXGI_FORMAT_AYUV, AV_PIX_FMT_VUYX },
+{ DXGI_FORMAT_YUY2, AV_PIX_FMT_YUYV422 },
+{ DXGI_FORMAT_Y210, AV_PIX_FMT_Y210 },
+{ DXGI_FORMAT_Y410, AV_PIX_FMT_XV30 },
+{ DXGI_FORMAT_P016, AV_PIX_FMT_P012 },
+{ DXGI_FORMAT_Y216, AV_PIX_FMT_Y212 },
+{ DXGI_FORMAT_Y416, AV_PIX_FMT_XV36 },
// Special opaque formats. The pix_fmt is merely a place holder, as the
// opaque format cannot be accessed directly.
{ DXGI_FORMAT_420_OPAQUE, AV_PIX_FMT_YUV420P },
--
2.35.1.windows.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 2/3] hwcontext_dxva2: add mutiple supported formats
Add support for VUYX, YUYV422, Y210, XV30, P012, Y212, XV36.
The added formats work with qsv acceleration and will not have
impact on dxva2 acceleration(-hwaccel dxva2) since so far
these formats are still not supported by using dxva2 acceleration.
Signed-off-by: Tong Wu
---
libavutil/hwcontext_dxva2.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/libavutil/hwcontext_dxva2.c b/libavutil/hwcontext_dxva2.c
index 53d00fa815..ea378df720 100644
--- a/libavutil/hwcontext_dxva2.c
+++ b/libavutil/hwcontext_dxva2.c
@@ -82,6 +82,13 @@ static const struct {
} supported_formats[] = {
{ MKTAG('N', 'V', '1', '2'), AV_PIX_FMT_NV12 },
{ MKTAG('P', '0', '1', '0'), AV_PIX_FMT_P010 },
+{ MKTAG('A', 'Y', 'U', 'V'), AV_PIX_FMT_VUYX },
+{ MKTAG('Y', 'U', 'Y', '2'), AV_PIX_FMT_YUYV422 },
+{ MKTAG('Y', '2', '1', '0'), AV_PIX_FMT_Y210 },
+{ MKTAG('Y', '4', '1', '0'), AV_PIX_FMT_XV30 },
+{ MKTAG('P', '0', '1', '6'), AV_PIX_FMT_P012 },
+{ MKTAG('Y', '2', '1', '6'), AV_PIX_FMT_Y212 },
+{ MKTAG('Y', '4', '1', '6'), AV_PIX_FMT_XV36 },
{ D3DFMT_P8, AV_PIX_FMT_PAL8 },
{ D3DFMT_A8R8G8B8, AV_PIX_FMT_BGRA },
};
--
2.35.1.windows.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 3/3] qsv: remove CONFIG_VAAPI
Make 8-bit, 10-bit, 12-bit YUV 4:2:2 video sources as well as YUV 4:4:4
video sources supported by d3d11va and dxva2 just like what VAAPI does.
Sign-off-by: Tong Wu
---
libavcodec/qsv.c | 4
libavutil/hwcontext_qsv.c | 4
2 files changed, 8 deletions(-)
diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
index 7af154202c..8eabf46b45 100644
--- a/libavcodec/qsv.c
+++ b/libavcodec/qsv.c
@@ -208,7 +208,6 @@ enum AVPixelFormat ff_qsv_map_fourcc(uint32_t fourcc)
case MFX_FOURCC_P8: return AV_PIX_FMT_PAL8;
case MFX_FOURCC_A2RGB10: return AV_PIX_FMT_X2RGB10;
case MFX_FOURCC_RGB4: return AV_PIX_FMT_BGRA;
-#if CONFIG_VAAPI
case MFX_FOURCC_YUY2: return AV_PIX_FMT_YUYV422;
case MFX_FOURCC_Y210: return AV_PIX_FMT_Y210;
case MFX_FOURCC_AYUV: return AV_PIX_FMT_VUYX;
@@ -217,7 +216,6 @@ enum AVPixelFormat ff_qsv_map_fourcc(uint32_t fourcc)
case MFX_FOURCC_P016: return AV_PIX_FMT_P012;
case MFX_FOURCC_Y216: return AV_PIX_FMT_Y212;
case MFX_FOURCC_Y416: return AV_PIX_FMT_XV36;
-#endif
#endif
}
return AV_PIX_FMT_NONE;
@@ -245,7 +243,6 @@ int ff_qsv_map_pixfmt(enum AVPixelFormat format, uint32_t
*fourcc, uint16_t *shi
*fourcc = MFX_FOURCC_RGB4;
*shift = 0;
return AV_PIX_FMT_BGRA;
-#if CONFIG_VAAPI
case AV_PIX_FMT_YUV422P:
case AV_PIX_FMT_YUYV422:
*fourcc = MFX_FOURCC_YUY2;
@@ -277,7 +274,6 @@ int ff_qsv_map_pixfmt(enum AVPixelFormat format, uint32_t
*fourcc, uint16_t *shi
*fourcc = MFX_FOURCC_Y416;
*shift = 1;
return AV_PIX_FMT_XV36;
-#endif
#endif
default:
return AVERROR(ENOSYS);
diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
index ec0f72b329..ba0ac8cda5 100644
--- a/libavutil/hwcontext_qsv.c
+++ b/libavutil/hwcontext_qsv.c
@@ -115,7 +115,6 @@ static const struct {
{ AV_PIX_FMT_BGRA, MFX_FOURCC_RGB4, 0 },
{ AV_PIX_FMT_P010, MFX_FOURCC_P010, 1 },
{ AV_PIX_FMT_PAL8, MFX_FOURCC_P8, 0 },
-#if CONFIG_VAAPI
{ AV_PIX_FMT_YUYV422,
MFX_FOURCC_YUY2, 0 },
{ AV_PIX_FMT_Y210,
@@ -142,7 +141,6 @@ static const struct {
{ AV_PIX_FMT_XV36,
MFX_FOURCC_Y416, 1 },
#endif
-#endif
};
extern int ff_qsv_get_surface_base_handle(mfxFrameSurface1 *surf,
@@ -1524,7 +1522,6 @@ static int map_frame_to_surface(const AVFrame *frame,
mfxFrameSurface1 *surface)
surface->Data.R = frame->data[0] + 2;
surface->Data.A = frame->data[0] + 3;
break;
-#if CONFIG_VAAPI
case AV_PIX_FMT_YUYV422:
surface->Data.Y = frame->data[0];
surface->Data.U = frame->data[0] + 1;
@@ -1556,7 +1553,6 @@ static int map_frame_to_surface(const AVFrame *frame,
mfxFrameSurface1 *surface)
// use the value from the frame.
surface->Data.A = frame->data[0] + 6;
break;
-#endif
default:
return MFX_ERR_UNSUPPORTED;
}
--
2.35.1.windows.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] add media100 bsf and use it
Patch attached.
From c9ec824211cccb745b3a4ab014d6be726c8ef1b9 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Tue, 31 Jan 2023 10:18:17 +0100
Subject: [PATCH] avcodec: add media100_to_mjpegb bitstream filter and use it
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile | 3 +-
libavcodec/bitstream_filters.c| 1 +
.../{media100.c => media100_to_mjpegb_bsf.c} | 112 +++---
libavcodec/mjpegbdec.c| 15 +++
4 files changed, 61 insertions(+), 70 deletions(-)
rename libavcodec/{media100.c => media100_to_mjpegb_bsf.c} (65%)
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index df76d37598..4971832ff4 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -485,7 +485,7 @@ OBJS-$(CONFIG_MACE6_DECODER) += mace.o
OBJS-$(CONFIG_MAGICYUV_DECODER)+= magicyuv.o
OBJS-$(CONFIG_MAGICYUV_ENCODER)+= magicyuvenc.o
OBJS-$(CONFIG_MDEC_DECODER)+= mdec.o mpeg12.o mpeg12data.o
-OBJS-$(CONFIG_MEDIA100_DECODER)+= media100.o
+OBJS-$(CONFIG_MEDIA100_DECODER)+= mjpegbdec.o
OBJS-$(CONFIG_METASOUND_DECODER) += metasound.o twinvq.o
OBJS-$(CONFIG_MICRODVD_DECODER)+= microdvddec.o ass.o
OBJS-$(CONFIG_MIMIC_DECODER) += mimic.o
@@ -1221,6 +1221,7 @@ OBJS-$(CONFIG_HEVC_METADATA_BSF) += h265_metadata_bsf.o h265_profile_le
h2645data.o
OBJS-$(CONFIG_HEVC_MP4TOANNEXB_BSF) += hevc_mp4toannexb_bsf.o
OBJS-$(CONFIG_IMX_DUMP_HEADER_BSF)+= imx_dump_header_bsf.o
+OBJS-$(CONFIG_MEDIA100_TO_MJPEGB_BSF) += media100_to_mjpegb_bsf.o
OBJS-$(CONFIG_MJPEG2JPEG_BSF) += mjpeg2jpeg_bsf.o
OBJS-$(CONFIG_MJPEGA_DUMP_HEADER_BSF) += mjpega_dump_header_bsf.o
OBJS-$(CONFIG_MPEG4_UNPACK_BFRAMES_BSF) += mpeg4_unpack_bframes_bsf.o
diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
index a3bebefe5f..e8216819ca 100644
--- a/libavcodec/bitstream_filters.c
+++ b/libavcodec/bitstream_filters.c
@@ -43,6 +43,7 @@ extern const FFBitStreamFilter ff_hapqa_extract_bsf;
extern const FFBitStreamFilter ff_hevc_metadata_bsf;
extern const FFBitStreamFilter ff_hevc_mp4toannexb_bsf;
extern const FFBitStreamFilter ff_imx_dump_header_bsf;
+extern const FFBitStreamFilter ff_media100_to_mjpegb_bsf;
extern const FFBitStreamFilter ff_mjpeg2jpeg_bsf;
extern const FFBitStreamFilter ff_mjpega_dump_header_bsf;
extern const FFBitStreamFilter ff_mp3_header_decompress_bsf;
diff --git a/libavcodec/media100.c b/libavcodec/media100_to_mjpegb_bsf.c
similarity index 65%
rename from libavcodec/media100.c
rename to libavcodec/media100_to_mjpegb_bsf.c
index 37b98c9a57..dafb65a0ad 100644
--- a/libavcodec/media100.c
+++ b/libavcodec/media100_to_mjpegb_bsf.c
@@ -1,6 +1,6 @@
/*
- * Media 100 decoder
- * Copyright (c) 2022 Paul B Mahol
+ * Media 100 to MJPEGB bitstream filter
+ * Copyright (c) 2023 Paul B Mahol
*
* This file is part of FFmpeg.
*
@@ -21,55 +21,34 @@
/**
* @file
- * Media 100 decoder.
+ * Media 100 to MJPEGB bitstream filter.
*/
#include
+#include "bsf.h"
+#include "bsf_internal.h"
#include "libavutil/intreadwrite.h"
-#include "avcodec.h"
#include "bytestream.h"
-#include "codec_internal.h"
typedef struct Media100Context {
-AVCodecContext *avctx; // wrapper context for mjpegb
AVPacket *pkt;
} Media100Context;
-static av_cold int media100_decode_init(AVCodecContext *avctx)
+static av_cold int init(AVBSFContext *ctx)
{
-Media100Context *ctx = avctx->priv_data;
-const AVCodec *codec;
-int ret;
-
-codec = avcodec_find_decoder(AV_CODEC_ID_MJPEGB);
-if (!codec)
-return AVERROR_BUG;
-ctx->avctx = avcodec_alloc_context3(codec);
-if (!ctx->avctx)
-return AVERROR(ENOMEM);
-ctx->avctx->thread_count = 1;
-ctx->avctx->flags = avctx->flags;
-ctx->avctx->flags2 = avctx->flags2;
-ctx->avctx->width = ctx->avctx->coded_width = avctx->width;
-ctx->avctx->height = ctx->avctx->coded_height = avctx->height;
-
-ret = avcodec_open2(ctx->avctx, codec, NULL);
-if (ret < 0)
-return ret;
+Media100Context *s = ctx->priv_data;
-ctx->pkt = av_packet_alloc();
-if (!ctx->pkt)
+s->pkt = av_packet_alloc();
+if (!s->pkt)
return AVERROR(ENOMEM);
return 0;
}
-static int media100_decode_frame(AVCodecContext *avctx,
- AVFrame *frame, int *got_frame,
- AVPacket *avpkt)
+static int filter(AVBSFContext *ctx, AVPacket *avpkt)
{
-Media100Context *ctx = avctx->priv_data;
+Media100Context *s = ctx->priv_data;
unsigned second_field_offset = 0;
unsigned next_field = 0;
unsigned dht_offset[2];
@@ -83,18 +62,20 @@ static int media100_decode_frame(AVCodecContext *avctx,
AVPacket *pkt;
int ret;
-if (avpkt->size + 1024 > ctx->pkt->size) {
-ret = av_grow_packet(ctx->pkt, avpkt
[FFmpeg-devel] [PATCH 2/2] avformat/assenc: fix strstr calls on non-string
In the write_header function of the ASS encoder, extradata is searched for a substring using the strstr function. strstr expects a null terminated C string as its first parameter, but extradata is (notionally) not one of these, meaning that the calls to strstr only happen to work because (presumably) they encounter a 0 byte somewhere downstream of extradata. I say notionally because often extradata will in fact be null terminated (which causes other problems, see parent commit). Signed-off-by: Tim Angus --- libavformat/assenc.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/libavformat/assenc.c b/libavformat/assenc.c index 4c9ea6f982..f6f5293bb7 100644 --- a/libavformat/assenc.c +++ b/libavformat/assenc.c @@ -83,12 +83,12 @@ static int write_header(AVFormatContext *s) if (header_string[strlen(header_string) - 1] != '\n') avio_printf(s->pb, "\r\n"); -av_free(header_string); - -ass->ssa_mode = !strstr(par->extradata, "\n[V4+ Styles]"); -if (!strstr(par->extradata, "\n[Events]")) +ass->ssa_mode = !strstr(header_string, "\n[V4+ Styles]"); +if (!strstr(header_string, "\n[Events]")) avio_printf(s->pb, "[Events]\r\nFormat: %s, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text\r\n", ass->ssa_mode ? "Marked" : "Layer"); + +av_free(header_string); } return 0; -- 2.25.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] add media100 bsf and use it
Paul B Mahol:
> -static int media100_decode_frame(AVCodecContext *avctx,
> - AVFrame *frame, int *got_frame,
> - AVPacket *avpkt)
> +static int filter(AVBSFContext *ctx, AVPacket *avpkt)
> {
> -Media100Context *ctx = avctx->priv_data;
> +Media100Context *s = ctx->priv_data;
> unsigned second_field_offset = 0;
> unsigned next_field = 0;
> unsigned dht_offset[2];
> @@ -83,18 +62,20 @@ static int media100_decode_frame(AVCodecContext *avctx,
> AVPacket *pkt;
> int ret;
>
> -if (avpkt->size + 1024 > ctx->pkt->size) {
> -ret = av_grow_packet(ctx->pkt, avpkt->size + 1024 - ctx->pkt->size);
> -if (ret < 0)
> -return ret;
> -}
> +ret = ff_bsf_get_packet_ref(ctx, avpkt);
The avpkt here is destined for output; you should use s->pkt to get the
new input packet. This will allow to avoid the av_packet_move_ref() below.
> +if (ret < 0)
> +return ret;
>
> -ret = av_packet_make_writable(ctx->pkt);
> +ret = av_new_packet(s->pkt, avpkt->size + 1024);
> +if (ret < 0)
> +return ret;
> +
> +ret = av_packet_make_writable(s->pkt);
av_new_packet() always returns writable packets.
> if (ret < 0)
> return ret;
>
> bytestream2_init(&gb, avpkt->data, avpkt->size);
> -bytestream2_init_writer(&pb, ctx->pkt->data, ctx->pkt->size);
> +bytestream2_init_writer(&pb, s->pkt->data, s->pkt->size);
>
> second_field:
> bytestream2_put_be32(&pb, 0);
> @@ -107,8 +88,8 @@ second_field:
> sof_offset[field] = bytestream2_tell_p(&pb);
> bytestream2_put_be16(&pb, 17);
> bytestream2_put_byte(&pb, 8);
> -bytestream2_put_be16(&pb, avctx->height / 2);
> -bytestream2_put_be16(&pb, avctx->width);
> +bytestream2_put_be16(&pb, ctx->par_in->height / 2);
> +bytestream2_put_be16(&pb, ctx->par_in->width);
> bytestream2_put_byte(&pb, 3);
> bytestream2_put_byte(&pb, 1);
> bytestream2_put_byte(&pb, 0x21);
> @@ -164,7 +145,7 @@ second_field:
> goto second_field;
> }
>
> -pkt = ctx->pkt;
> +pkt = s->pkt;
>
> AV_WB32(pkt->data + 8, second_field_offset);
> AV_WB32(pkt->data + 12, second_field_offset);
> @@ -186,40 +167,33 @@ second_field:
>
> pkt->size = bytestream2_tell_p(&pb);
>
> -ret = avcodec_send_packet(ctx->avctx, pkt);
> -if (ret < 0) {
> -av_log(avctx, AV_LOG_ERROR, "Error submitting a packet for
> decoding\n");
> -return ret;
> -}
> +av_packet_copy_props(pkt, avpkt);
> +av_packet_unref(avpkt);
> +av_packet_move_ref(avpkt, s->pkt);
>
> -ret = avcodec_receive_frame(ctx->avctx, frame);
> -if (ret < 0)
> -return ret;
> +return 0;
> +}
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] avformat/lafdec: Check if all data was read
Michael Niedermayer: > Fixes: OOM > Fixes: > 54572/clusterfuzz-testcase-minimized-ffmpeg_dem_LAF_fuzzer-4974038870523904 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/lafdec.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/libavformat/lafdec.c b/libavformat/lafdec.c > index d02b479c4d..b78ec3649c 100644 > --- a/libavformat/lafdec.c > +++ b/libavformat/lafdec.c > @@ -208,6 +208,8 @@ again: > ret = avio_read(pb, s->data, st_count * st->codecpar->sample_rate * > bpp); > if (ret < 0) > return ret; > +if (ret != st_count * st->codecpar->sample_rate * bpp) > +return AVERROR_INVALIDDATA; > } > > st = ctx->streams[s->index]; ffio_read() - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/3] libavformat/lafdec: free data
Michael Niedermayer:
> Fixes: memleak
>
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/lafdec.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/libavformat/lafdec.c b/libavformat/lafdec.c
> index b78ec3649c..f6d2d5f235 100644
> --- a/libavformat/lafdec.c
> +++ b/libavformat/lafdec.c
> @@ -253,6 +253,15 @@ again:
> return 0;
> }
>
> +static int laf_read_close(AVFormatContext *ctx)
> +{
> +LAFContext *s = ctx->priv_data;
> +
> +av_freep(&s->data);
> +
> +return 0;
> +}
> +
> static int laf_read_seek(AVFormatContext *ctx, int stream_index,
> int64_t timestamp, int flags)
> {
> @@ -270,6 +279,7 @@ const AVInputFormat ff_laf_demuxer = {
> .read_probe = laf_probe,
> .read_header= laf_read_header,
> .read_packet= laf_read_packet,
> +.read_close = laf_read_close,
> .read_seek = laf_read_seek,
> .extensions = "laf",
> .flags = AVFMT_GENERIC_INDEX,
Needs the FF_FMT_INIT_CLEANUP flag, too (otherwise it will leak in case
of avformat_new_stream() failure).
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/mlpdec: parse and use substream_info bits
Paul B Mahol: > +///< Which substream of substreams carry 16-channel presentation > +uint8_t extended_substream_info; > + > +///< Which substream of substreams carry 2/6/8-channel presentation > +uint8_t substream_info; > + Sure about the '<' in ///https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/mlpdec: parse and use substream_info bits
On 1/31/23, Andreas Rheinhardt wrote: > Paul B Mahol: >> +///< Which substream of substreams carry 16-channel presentation >> +uint8_t extended_substream_info; >> + >> +///< Which substream of substreams carry 2/6/8-channel presentation >> +uint8_t substream_info; >> + > > Sure about the '<' in /// applies to the entity directly before the ///<. I copied from other lines. > > - Andreas > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] lavc/decode: allow using AV_CODEC_FLAG_COPY_OPAQUE for decoding
Use it to propagate AVPacket.opaque[_ref] to corresponding AVFrame
fields. This is a more convenient alternative to reordered_opaque.
---
doc/APIchanges| 3 +++
libavcodec/avcodec.h | 9 +
libavcodec/decode.c | 12 ++--
libavcodec/decode.h | 3 ++-
libavcodec/libdav1d.c | 31 +++
libavcodec/version.h | 2 +-
6 files changed, 48 insertions(+), 12 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index bc52a07964..4b3934b82c 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -14,6 +14,9 @@ libavutil: 2021-04-27
API changes, most recent first:
+2023-0x-xx - xx - lavc 59.60.100
+ Allow AV_CODEC_FLAG_COPY_OPAQUE to be used with decoders.
+
2023-01-29 - xx - lavc 59.59.100 - avcodec.h
Add AV_CODEC_FLAG_COPY_OPAQUE and AV_CODEC_FLAG_FRAME_DURATION.
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 90b437ccbe..eba9ea73d7 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -242,9 +242,15 @@ typedef struct RcOverride{
*/
#define AV_CODEC_FLAG_RECON_FRAME (1 << 6)
/**
+ * @par decoding
+ * Request the decoder to propagate each packets AVPacket.opaque and
+ * AVPacket.opaque_ref to its corresponding output AVFrame.
+ *
+ * @par encoding:
* Request the encoder to propagate each frame's AVFrame.opaque and
* AVFrame.opaque_ref values to its corresponding output AVPacket.
*
+ * @par
* May only be set on encoders that have the
* @ref AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE capability flag.
*
@@ -265,6 +271,9 @@ typedef struct RcOverride{
* .
* When an output packet contains multiple frames, the opaque values will be
* taken from the first of those.
+ *
+ * @note
+ * The converse holds for decoders, with frames and packets switched.
*/
#define AV_CODEC_FLAG_COPY_OPAQUE (1 << 7)
/**
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 0abc88737b..17b398e933 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1291,7 +1291,8 @@ static int add_metadata_from_side_data(const AVPacket
*avpkt, AVFrame *frame)
return av_packet_unpack_dictionary(side_metadata, size, frame_md);
}
-int ff_decode_frame_props_from_pkt(AVFrame *frame, const AVPacket *pkt)
+int ff_decode_frame_props_from_pkt(const AVCodecContext *avctx,
+ AVFrame *frame, const AVPacket *pkt)
{
static const struct {
enum AVPacketSideDataType packet;
@@ -1336,6 +1337,13 @@ int ff_decode_frame_props_from_pkt(AVFrame *frame, const
AVPacket *pkt)
frame->flags = (frame->flags & ~AV_FRAME_FLAG_DISCARD);
}
+if (avctx->flags & AV_CODEC_FLAG_COPY_OPAQUE) {
+int ret = av_buffer_replace(&frame->opaque_ref, pkt->opaque_ref);
+if (ret < 0)
+return ret;
+frame->opaque = pkt->opaque;
+}
+
return 0;
}
@@ -1344,7 +1352,7 @@ int ff_decode_frame_props(AVCodecContext *avctx, AVFrame
*frame)
const AVPacket *pkt = avctx->internal->last_pkt_props;
if (!(ffcodec(avctx->codec)->caps_internal &
FF_CODEC_CAP_SETS_FRAME_PROPS)) {
-int ret = ff_decode_frame_props_from_pkt(frame, pkt);
+int ret = ff_decode_frame_props_from_pkt(avctx, frame, pkt);
if (ret < 0)
return ret;
frame->pkt_size = (int)(intptr_t)pkt->opaque;
diff --git a/libavcodec/decode.h b/libavcodec/decode.h
index 906122b4a7..8430ffbd66 100644
--- a/libavcodec/decode.h
+++ b/libavcodec/decode.h
@@ -72,7 +72,8 @@ int ff_decode_get_packet(AVCodecContext *avctx, AVPacket
*pkt);
/**
* Set various frame properties from the provided packet.
*/
-int ff_decode_frame_props_from_pkt(AVFrame *frame, const AVPacket *pkt);
+int ff_decode_frame_props_from_pkt(const AVCodecContext *avctx,
+ AVFrame *frame, const AVPacket *pkt);
/**
* Set various frame properties from the codec context / packet data.
diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c
index b43af03732..f7d75f9439 100644
--- a/libavcodec/libdav1d.c
+++ b/libavcodec/libdav1d.c
@@ -288,6 +288,11 @@ static void libdav1d_flush(AVCodecContext *c)
dav1d_flush(dav1d->c);
}
+typedef struct OpaqueData {
+void*pkt_orig_opaque;
+int64_t reordered_opaque;
+} OpaqueData;
+
static void libdav1d_data_free(const uint8_t *data, void *opaque) {
AVBufferRef *buf = opaque;
@@ -307,6 +312,7 @@ static int libdav1d_receive_frame(AVCodecContext *c,
AVFrame *frame)
Dav1dData *data = &dav1d->data;
Dav1dPicture pic = { 0 }, *p = &pic;
AVPacket *pkt;
+OpaqueData *od = NULL;
#if FF_DAV1D_VERSION_AT_LEAST(5,1)
enum Dav1dEventFlags event_flags = 0;
#endif
@@ -333,17 +339,19 @@ static int libdav1d_receive_frame(AVCodecContext *c,
AVFrame *frame)
}
pkt->buf = NULL;
-pkt->opaque = NULL;
-if (c->reordered_opaque != AV_NOPTS_VALUE) {
-pkt->opaque = av_memdup(&c->reordered_opaque,
-
[FFmpeg-devel] [PATCH 2/2] lavu/frame: deprecate reordered_opaque
It is only used in libavcodec, where it's been superseded by
AV_CODEC_CAP_COPY_OPAQUE.
---
libavcodec/avcodec.h| 5 +
libavcodec/codec.h | 6 +++---
libavcodec/decode.c | 4
libavcodec/encode.c | 4
libavcodec/libdav1d.c | 15 ++-
libavcodec/librav1e.c | 10 ++
libavcodec/libwebpenc_animencoder.c | 10 ++
libavcodec/libx264.c| 14 ++
libavcodec/libx265.c| 17 -
libavcodec/nvenc.c | 10 ++
libavcodec/options.c| 4
libavcodec/pthread_frame.c | 4
libavutil/frame.c | 4
libavutil/frame.h | 5 +
libavutil/version.h | 1 +
15 files changed, 108 insertions(+), 5 deletions(-)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index eba9ea73d7..755e543fac 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1392,6 +1392,7 @@ typedef struct AVCodecContext {
*/
int err_recognition;
+#if FF_API_REORDERED_OPAQUE
/**
* opaque 64-bit number (generally a PTS) that will be reordered and
* output in AVFrame.reordered_opaque
@@ -1400,8 +1401,12 @@ typedef struct AVCodecContext {
* supported by encoders with the
* AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE capability.
* - decoding: Set by user.
+ *
+ * @deprecated Use AV_CODEC_FLAG_COPY_OPAQUE instead
*/
+attribute_deprecated
int64_t reordered_opaque;
+#endif
/**
* Hardware accelerator in use
diff --git a/libavcodec/codec.h b/libavcodec/codec.h
index 77a1a3f5a2..67f9120b44 100644
--- a/libavcodec/codec.h
+++ b/libavcodec/codec.h
@@ -169,9 +169,9 @@
#define AV_CODEC_CAP_HYBRID (1 << 19)
/**
- * This codec takes the reordered_opaque field from input AVFrames
- * and returns it in the corresponding field in AVCodecContext after
- * encoding.
+ * This encoder can reorder user opaque values from input AVFrames and return
+ * them with corresponding output packets.
+ * @see AV_CODEC_FLAG_COPY_OPAQUE
*/
#define AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE (1 << 20)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 17b398e933..03ae27ecdf 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1357,7 +1357,11 @@ int ff_decode_frame_props(AVCodecContext *avctx, AVFrame
*frame)
return ret;
frame->pkt_size = (int)(intptr_t)pkt->opaque;
}
+#if FF_API_REORDERED_OPAQUE
+FF_DISABLE_DEPRECATION_WARNINGS
frame->reordered_opaque = avctx->reordered_opaque;
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
if (frame->color_primaries == AVCOL_PRI_UNSPECIFIED)
frame->color_primaries = avctx->color_primaries;
diff --git a/libavcodec/encode.c b/libavcodec/encode.c
index c92beaf8e1..b0a9625ca9 100644
--- a/libavcodec/encode.c
+++ b/libavcodec/encode.c
@@ -193,7 +193,11 @@ int ff_encode_get_frame(AVCodecContext *avctx, AVFrame
*frame)
int ff_encode_reordered_opaque(AVCodecContext *avctx,
AVPacket *pkt, const AVFrame *frame)
{
+#if FF_API_REORDERED_OPAQUE
+FF_DISABLE_DEPRECATION_WARNINGS
avctx->reordered_opaque = frame->reordered_opaque;
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
if (avctx->flags & AV_CODEC_FLAG_COPY_OPAQUE) {
int ret = av_buffer_replace(&pkt->opaque_ref, frame->opaque_ref);
diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c
index f7d75f9439..2488a709c7 100644
--- a/libavcodec/libdav1d.c
+++ b/libavcodec/libdav1d.c
@@ -290,7 +290,9 @@ static void libdav1d_flush(AVCodecContext *c)
typedef struct OpaqueData {
void*pkt_orig_opaque;
+#if FF_API_REORDERED_OPAQUE
int64_t reordered_opaque;
+#endif
} OpaqueData;
static void libdav1d_data_free(const uint8_t *data, void *opaque) {
@@ -340,7 +342,11 @@ static int libdav1d_receive_frame(AVCodecContext *c,
AVFrame *frame)
pkt->buf = NULL;
-if (c->reordered_opaque != AV_NOPTS_VALUE ||
+FF_DISABLE_DEPRECATION_WARNINGS
+if (
+#if FF_API_REORDERED_OPAQUE
+c->reordered_opaque != AV_NOPTS_VALUE ||
+#endif
(pkt->opaque && (c->flags & AV_CODEC_FLAG_COPY_OPAQUE))) {
od = av_mallocz(sizeof(*od));
if (!od) {
@@ -349,7 +355,10 @@ static int libdav1d_receive_frame(AVCodecContext *c,
AVFrame *frame)
return AVERROR(ENOMEM);
}
od->pkt_orig_opaque = pkt->opaque;
+#if FF_API_REORDERED_OPAQUE
od->reordered_opaque = c->reordered_opaque;
+#endif
+FF_ENABLE_DEPRECATION_WARNINGS
}
pkt->opaque = od;
@@ -432,10 +441,14 @@ static int libdav1d_receive_frame(AVCodecContext *c,
AVFrame *frame)
pkt = (AVPacket *)p->m.user_data.data;
od = pkt->opaque;
+#if FF_API
[FFmpeg-devel] [PATCH] lavc: deprecate CrystalHD decoders
The hardware is old and not relevant today. The decoders also have many special quirks and are effectively unmaintained. --- Philip confirmed on IRC that he no longer has the hardware for maintaining this and does not believe it is relevant today. --- Changelog | 1 + MAINTAINERS| 2 -- configure | 4 +++- libavcodec/crystalhd.c | 4 libavcodec/version_major.h | 3 +++ 5 files changed, 11 insertions(+), 3 deletions(-) diff --git a/Changelog b/Changelog index aa0dad13a1..323effec05 100644 --- a/Changelog +++ b/Changelog @@ -35,6 +35,7 @@ version : - ffmpeg CLI new options: -enc_stats_pre[_fmt], -enc_stats_post[_fmt] - hstack_vaapi, vstack_vaapi and xstack_vaapi filters - XMD ADPCM decoder and demuxer +- CrystalHD decoders deprecated version 5.1: diff --git a/MAINTAINERS b/MAINTAINERS index 48e2ec4fd4..f87d43fce5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -151,7 +151,6 @@ Codecs: ccaption_dec.cAnshul Maheshwari, Aman Gupta cljr Alex Beregszaszi cpia.cStephan Hilb - crystalhd.c Philip Langdale cscd.cReimar Doeffinger cuviddec.cTimo Rothenpieler dca* foo86 @@ -265,7 +264,6 @@ Codecs: xwd* Paul B Mahol Hardware acceleration: - crystalhd.c Philip Langdale dxva2*Hendrik Leppkes, Laurent Aimar, Steve Lhomme d3d11va* Steve Lhomme mediacodec* Matthieu Bouron, Aman Gupta diff --git a/configure b/configure index 47790d10f5..a4ce3b5b32 100755 --- a/configure +++ b/configure @@ -6999,7 +6999,9 @@ enabled vdpau && enabled vdpau && check_lib vdpau_x11 "vdpau/vdpau.h vdpau/vdpau_x11.h" vdp_device_create_x11 -lvdpau -lX11 -enabled crystalhd && check_lib crystalhd "stdint.h libcrystalhd/libcrystalhd_if.h" DtsCrystalHDVersion -lcrystalhd +enabled crystalhd && check_lib crystalhd "stdint.h libcrystalhd/libcrystalhd_if.h" DtsCrystalHDVersion -lcrystalhd && \ +warn "CrystalHD support is deprecated and will be removed, please contact the developers if you are interested" \ + "in maintaining it." if enabled vulkan; then check_pkg_config_header_only vulkan "vulkan >= 1.2.189" "vulkan/vulkan.h" "defined VK_VERSION_1_2" || diff --git a/libavcodec/crystalhd.c b/libavcodec/crystalhd.c index 8673a491d4..688cdffbcb 100644 --- a/libavcodec/crystalhd.c +++ b/libavcodec/crystalhd.c @@ -329,6 +329,10 @@ static av_cold int init(AVCodecContext *avctx) av_log(avctx, AV_LOG_VERBOSE, "CrystalHD Init for %s\n", avctx->codec->name); +av_log(avctx, AV_LOG_WARNING, "CrystalHD support is deprecated and will " + "be removed. Please contact the developers if you are interested in " + "maintaining it.\n"); + avctx->pix_fmt = AV_PIX_FMT_YUYV422; /* Initialize the library */ diff --git a/libavcodec/version_major.h b/libavcodec/version_major.h index 2c0443c4c8..f38566f62c 100644 --- a/libavcodec/version_major.h +++ b/libavcodec/version_major.h @@ -55,4 +55,7 @@ #define FF_API_VT_HWACCEL_CONTEXT (LIBAVCODEC_VERSION_MAJOR < 60) #define FF_API_AVCODEC_CHROMA_POS (LIBAVCODEC_VERSION_MAJOR < 60) +// reminder to remove CrystalHD decoders on next major bump +#define FF_CODEC_CRYSTAL_HD(LIBAVCODEC_VERSION_MAJOR < 61) + #endif /* AVCODEC_VERSION_MAJOR_H */ -- 2.35.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] avformat/assenc: fix incorrect copy of null terminator
> On Jan 18, 2023, at 22:31, Tim Angus wrote: > > When writing a subtitle SSA/ASS subtitle file, the > AVCodecParameters::extradata buffer is written directly to the output, > potentially including a null terminating character, which is sometimes > present. The result is the output having a null character in the middle; > this is addressed here by avoiding copying it. > > Signed-off-by: Tim Angus > --- > libavformat/assenc.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/libavformat/assenc.c b/libavformat/assenc.c > index 1600f0a02b..5e74b84575 100644 > --- a/libavformat/assenc.c > +++ b/libavformat/assenc.c > @@ -69,6 +69,11 @@ static int write_header(AVFormatContext *s) > ass->trailer = trailer; > } > > +/* extradata may or may not be null terminated; in the case where > + * it is, avoid copying a null into the middle of the buffer */ > +while (header_size > 0 && par->extradata[header_size - 1] == '\0') > +header_size--; > + The comment is misleading. extradata is always null terminated, although those paddings don’t count in extradata_size. > avio_write(s->pb, par->extradata, header_size); > if (par->extradata[header_size - 1] != '\n') > avio_write(s->pb, "\r\n", 2); > -- > 2.25.1 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavu/video_enc_params: Avoid relying on an undefined C construct
On Wed, 18 Jan 2023, Anton Khirnov wrote:
Quoting Martin Storsjö (2023-01-15 23:47:41)
The construct of using offsetof on a (potentially anonymous) struct
defined within the offsetof expression, while supported by all
current compilers, has been declared explicitly undefined by the
C standards committee [1].
Current Clang git main got a patch [2] which changed this construct
into a hard error. It seems like this will be softened into a
warning [3] soon though, as it did break a fair number of projects.
Nevertheless - in this particular case, it's trivial to fix the
code not to rely on the construct that the standards committee has
explicitly called out as undefined.
[1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2350.htm
[2]
https://github.com/llvm/llvm-project/commit/e327b52766ed497e4779f4e652b9ad237dfda8e6
[3] https://reviews.llvm.org/D133574#4053647
Signed-off-by: Martin Storsjö
---
libavutil/video_enc_params.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavutil/video_enc_params.c b/libavutil/video_enc_params.c
index 54bfed0ed9..33592dc128 100644
--- a/libavutil/video_enc_params.c
+++ b/libavutil/video_enc_params.c
@@ -27,11 +27,11 @@
AVVideoEncParams *av_video_enc_params_alloc(enum AVVideoEncParamsType type,
unsigned int nb_blocks, size_t
*out_size)
{
-const size_t blocks_offset = offsetof(
-struct {
-AVVideoEncParams p;
-AVVideoBlockParams b;
-}, b);
+struct TestStruct {
+AVVideoEncParams p;
+AVVideoBlockParams b;
+};
+const size_t blocks_offset = offsetof(struct TestStruct, b);
size_t size = blocks_offset;
AVVideoEncParams *par;
--
2.34.1
LGTM
Thanks, pushed now.
// Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] mov: Reduce the verbosity of the warning about fragmented MP4 vs advanced edit lists
On Mon, 23 Jan 2023, Derek Buitenhuis wrote: On 1/17/2023 9:31 AM, Martin Storsjö wrote: Only warn if the advanced_editlist option is enabled (it is enabled by default though) so we don't print one warning for each track, and demote the warning to AV_LOG_LEVEL_VERBOSE; this message does get generated whenever parsing a fragmented MP4 file, regardless of whether the file actually uses multiple edits or not. Later when parsing the mov structures, the demuxer does warn if the file did contain multiple edits which would require the advanced_editlist option enabled for decoding correctly. Adjust the warning message for the case when the file seemed like it actually would have needed handling of advanced edit lists, to reflect the fact that it doesn't help to try set the option as it has been automatically disabled. --- libavformat/isom.h | 1 + libavformat/mov.c | 20 ++-- 2 files changed, 15 insertions(+), 6 deletions(-) LGTM. Pushed now, thanks! // Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] libavformat/mpegtsenc.c -- correctly re-emit extradata ahead of IDR pictures
This replaces and obsoletes the earlier version of this patch, which had a bug.
Thanks to Marton Balint for spotting it.
This fixes https://trac.ffmpeg.org/ticket/10148, it ensures that each IDR frame
is prefixed with SPS/PPS.
Tested manually, with inputs containing AUDs (x264's aud=1 mode) and also
without (aud=0) to confirm it still inserts AUDs when necessary, and not
otherwise.
---
libavformat/mpegtsenc.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 48d39e6a7d..64948f4d75 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -1877,6 +1877,7 @@ static int mpegts_write_packet_internal(AVFormatContext
*s, AVPacket *pkt)
if (st->codecpar->codec_id == AV_CODEC_ID_H264) {
const uint8_t *p = buf, *buf_end = p + size;
+uint8_t found_aud = 0;
uint32_t state = -1;
int extradd = (pkt->flags & AV_PKT_FLAG_KEY) ?
st->codecpar->extradata_size : 0;
int ret = ff_check_h264_startcode(s, st, pkt);
@@ -1886,17 +1887,25 @@ static int mpegts_write_packet_internal(AVFormatContext
*s, AVPacket *pkt)
if (extradd && AV_RB24(st->codecpar->extradata) > 1)
extradd = 0;
+// Ensure that all pictures are prefixed with an AUD, and that
+// IDR pictures are also prefixed with SPS and PPS. SPS and PPS
+// are assumed to be available in 'extradata' if not found in-band.
do {
p = avpriv_find_start_code(p, buf_end, &state);
av_log(s, AV_LOG_TRACE, "nal %"PRId32"\n", state & 0x1f);
-if ((state & 0x1f) == 7)
+if ((state & 0x1f) == 7) // SPS NAL
extradd = 0;
-} while (p < buf_end && (state & 0x1f) != 9 &&
- (state & 0x1f) != 5 && (state & 0x1f) != 1);
-
-if ((state & 0x1f) != 5)
+if ((state & 0x1f) == 9) // AUD
+found_aud = 1;
+} while (p < buf_end
+ && (state & 0x1f) != 5 // IDR picture
+ && (state & 0x1f) != 1 // non-IDR picture
+ && (extradd > 0 || !found_aud));
+if ((state & 0x1f) != 5) {
+// Did not find IDR picture; do not emit extradata.
extradd = 0;
-if ((state & 0x1f) != 9) { // AUD NAL
+}
+if (extradd > 0 || !found_aud) {
data = av_malloc(pkt->size + 6 + extradd);
if (!data)
return AVERROR(ENOMEM);
--
2.39.1.456.gfc5497dd1b-goog
___
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] add media100 bsf and use it
Quoting Paul B Mahol (2023-01-31 11:18:52)
> Patch attached.
>
> From c9ec824211cccb745b3a4ab014d6be726c8ef1b9 Mon Sep 17 00:00:00 2001
> From: Paul B Mahol
> Date: Tue, 31 Jan 2023 10:18:17 +0100
> Subject: [PATCH] avcodec: add media100_to_mjpegb bitstream filter and use it
>
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/Makefile | 3 +-
> libavcodec/bitstream_filters.c| 1 +
> .../{media100.c => media100_to_mjpegb_bsf.c} | 112 +++---
> libavcodec/mjpegbdec.c| 15 +++
> 4 files changed, 61 insertions(+), 70 deletions(-)
> rename libavcodec/{media100.c => media100_to_mjpegb_bsf.c} (65%)
Needs media100_decoder_select="media100_to_mjpegb_bsf" in configure and
a changelog entry.
> -static av_cold int media100_decode_init(AVCodecContext *avctx)
> +static av_cold int init(AVBSFContext *ctx)
> {
> -Media100Context *ctx = avctx->priv_data;
> -const AVCodec *codec;
> -int ret;
> -
> -codec = avcodec_find_decoder(AV_CODEC_ID_MJPEGB);
> -if (!codec)
> -return AVERROR_BUG;
> -ctx->avctx = avcodec_alloc_context3(codec);
> -if (!ctx->avctx)
> -return AVERROR(ENOMEM);
> -ctx->avctx->thread_count = 1;
> -ctx->avctx->flags = avctx->flags;
> -ctx->avctx->flags2 = avctx->flags2;
> -ctx->avctx->width = ctx->avctx->coded_width = avctx->width;
> -ctx->avctx->height = ctx->avctx->coded_height = avctx->height;
> -
> -ret = avcodec_open2(ctx->avctx, codec, NULL);
> -if (ret < 0)
> -return ret;
> +Media100Context *s = ctx->priv_data;
>
> -ctx->pkt = av_packet_alloc();
> -if (!ctx->pkt)
> +s->pkt = av_packet_alloc();
> +if (!s->pkt)
> return AVERROR(ENOMEM);
Should set ctx->par_out->codec_id to AV_CODEC_ID_MJPEGB, so people can
use this bsf standalone.
>
> return 0;
> }
>
> -static int media100_decode_frame(AVCodecContext *avctx,
> - AVFrame *frame, int *got_frame,
> - AVPacket *avpkt)
> +static int filter(AVBSFContext *ctx, AVPacket *avpkt)
> {
> -Media100Context *ctx = avctx->priv_data;
> +Media100Context *s = ctx->priv_data;
> unsigned second_field_offset = 0;
> unsigned next_field = 0;
> unsigned dht_offset[2];
> @@ -83,18 +62,20 @@ static int media100_decode_frame(AVCodecContext *avctx,
> AVPacket *pkt;
> int ret;
>
> -if (avpkt->size + 1024 > ctx->pkt->size) {
> -ret = av_grow_packet(ctx->pkt, avpkt->size + 1024 - ctx->pkt->size);
> -if (ret < 0)
> -return ret;
> -}
> +ret = ff_bsf_get_packet_ref(ctx, avpkt);
> +if (ret < 0)
> +return ret;
>
> -ret = av_packet_make_writable(ctx->pkt);
> +ret = av_new_packet(s->pkt, avpkt->size + 1024);
> +if (ret < 0)
> +return ret;
> +
> +ret = av_packet_make_writable(s->pkt);
> if (ret < 0)
> return ret;
>
> bytestream2_init(&gb, avpkt->data, avpkt->size);
> -bytestream2_init_writer(&pb, ctx->pkt->data, ctx->pkt->size);
> +bytestream2_init_writer(&pb, s->pkt->data, s->pkt->size);
>
> second_field:
> bytestream2_put_be32(&pb, 0);
> @@ -107,8 +88,8 @@ second_field:
> sof_offset[field] = bytestream2_tell_p(&pb);
> bytestream2_put_be16(&pb, 17);
> bytestream2_put_byte(&pb, 8);
> -bytestream2_put_be16(&pb, avctx->height / 2);
> -bytestream2_put_be16(&pb, avctx->width);
> +bytestream2_put_be16(&pb, ctx->par_in->height / 2);
> +bytestream2_put_be16(&pb, ctx->par_in->width);
> bytestream2_put_byte(&pb, 3);
> bytestream2_put_byte(&pb, 1);
> bytestream2_put_byte(&pb, 0x21);
> @@ -164,7 +145,7 @@ second_field:
> goto second_field;
> }
>
> -pkt = ctx->pkt;
> +pkt = s->pkt;
>
> AV_WB32(pkt->data + 8, second_field_offset);
> AV_WB32(pkt->data + 12, second_field_offset);
> @@ -186,40 +167,33 @@ second_field:
>
> pkt->size = bytestream2_tell_p(&pb);
>
> -ret = avcodec_send_packet(ctx->avctx, pkt);
> -if (ret < 0) {
> -av_log(avctx, AV_LOG_ERROR, "Error submitting a packet for
> decoding\n");
> -return ret;
> -}
> +av_packet_copy_props(pkt, avpkt);
check the return value
A FATE test would be nice.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] lavc/vaapi_encode: fix propagating durations and opaques
input_image is freed by the time the output packet is constructed, so we
need to store copies in VAAPIEncodePicture.
---
Is this better?
---
libavcodec/vaapi_encode.c | 22 +-
libavcodec/vaapi_encode.h | 4
2 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 6787b90e8d6..bfca315a7ad 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -695,7 +695,7 @@ static int vaapi_encode_output(AVCodecContext *avctx,
pkt->flags |= AV_PKT_FLAG_KEY;
pkt->pts = pic->pts;
-pkt->duration = pic->input_image->duration;
+pkt->duration = pic->duration;
vas = vaUnmapBuffer(ctx->hwctx->display, pic->output_buffer);
if (vas != VA_STATUS_SUCCESS) {
@@ -706,10 +706,11 @@ static int vaapi_encode_output(AVCodecContext *avctx,
}
// for no-delay encoders this is handled in generic codec
-if (avctx->codec->capabilities & AV_CODEC_CAP_DELAY) {
-err = ff_encode_reordered_opaque(avctx, pkt, pic->input_image);
-if (err < 0)
-goto fail;
+if (avctx->codec->capabilities & AV_CODEC_CAP_DELAY &&
+avctx->flags & AV_CODEC_FLAG_COPY_OPAQUE) {
+pkt->opaque = pic->opaque;
+pkt->opaque_ref = pic->opaque_ref;
+pic->opaque_ref = NULL;
}
av_buffer_unref(&pic->output_buffer_ref);
@@ -785,6 +786,8 @@ static int vaapi_encode_free(AVCodecContext *avctx,
av_frame_free(&pic->input_image);
av_frame_free(&pic->recon_image);
+av_buffer_unref(&pic->opaque_ref);
+
av_freep(&pic->param_buffers);
av_freep(&pic->slices);
// Output buffer should already be destroyed.
@@ -1152,6 +1155,15 @@ static int vaapi_encode_send_frame(AVCodecContext
*avctx, AVFrame *frame)
pic->input_surface = (VASurfaceID)(uintptr_t)frame->data[3];
pic->pts = frame->pts;
+pic->duration = frame->duration;
+
+if (avctx->flags & AV_CODEC_FLAG_COPY_OPAQUE) {
+err = av_buffer_replace(&pic->opaque_ref, frame->opaque_ref);
+if (err < 0)
+goto fail;
+
+pic->opaque = frame->opaque;
+}
av_frame_move_ref(pic->input_image, frame);
diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
index 359f954..a1e639f56b0 100644
--- a/libavcodec/vaapi_encode.h
+++ b/libavcodec/vaapi_encode.h
@@ -75,8 +75,12 @@ typedef struct VAAPIEncodePicture {
int64_t display_order;
int64_t encode_order;
int64_t pts;
+int64_t duration;
int force_idr;
+void *opaque;
+AVBufferRef*opaque_ref;
+
#if VA_CHECK_VERSION(1, 0, 0)
// ROI regions.
VAEncROI *roi;
--
2.35.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] mfenc: Fix double frees on init errors
Make mf_close safe to call multiple times; it currently isn't
called more than once, but for clarity, make it safe to call
more than once.
If there are failures in ff_instantiate_mf, that function
calls uninit_com_mf() on its own. Make sure that the second
call to uninit_com_mf from ff_free_mf (from mf_close) is a
no-op in that case.
Signed-off-by: Martin Storsjö
---
libavcodec/mf_utils.c | 6 --
libavcodec/mfenc.c| 2 ++
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavcodec/mf_utils.c b/libavcodec/mf_utils.c
index 48e3a63efc..50b9fdb2c4 100644
--- a/libavcodec/mf_utils.c
+++ b/libavcodec/mf_utils.c
@@ -642,8 +642,10 @@ error_uninit_mf:
void ff_free_mf(MFFunctions *f, IMFTransform **mft)
{
-if (*mft)
-IMFTransform_Release(*mft);
+if (!*mft)
+return;
+
+IMFTransform_Release(*mft);
*mft = NULL;
uninit_com_mf(f);
}
diff --git a/libavcodec/mfenc.c b/libavcodec/mfenc.c
index f3415df10b..e3b5fb1600 100644
--- a/libavcodec/mfenc.c
+++ b/libavcodec/mfenc.c
@@ -1184,9 +1184,11 @@ static int mf_close(AVCodecContext *avctx)
if (c->codec_api)
ICodecAPI_Release(c->codec_api);
+c->codec_api = NULL;
if (c->async_events)
IMFMediaEventGenerator_Release(c->async_events);
+c->async_events = NULL;
#if !HAVE_UWP
if (c->library)
--
2.37.1 (Apple Git-137.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] avformat/assenc: fix incorrect copy of null terminator
On 31/01/2023 12:37, "zhilizhao(赵志立)" wrote: +/* extradata may or may not be null terminated; in the case where + * it is, avoid copying a null into the middle of the buffer */ +while (header_size > 0 && par->extradata[header_size - 1] == '\0') +header_size--; + The comment is misleading. extradata is always null terminated, although those paddings don’t count in extradata_size. That's a bit pedantic, but I take your point. "The contents of extradata may or may..." would be better. Following some discussion on IRC, I've actually submitted another patch that solves the problem in a different way, but I don't think anyone has looked at it yet... http://ffmpeg.org/pipermail/ffmpeg-devel/2023-January/306017.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 2/2] avformat/assenc: fix strstr calls on non-string
On 31/01/2023 11:13, Tim Angus wrote: In the write_header function of the ASS encoder, extradata is searched for a substring using the strstr function. strstr expects a null terminated C string as its first parameter, but extradata is (notionally) not one of these, meaning that the calls to strstr only happen to work because (presumably) they encounter a 0 byte somewhere downstream of extradata. I say notionally because often extradata will in fact be null terminated (which causes other problems, see parent commit). Signed-off-by: Tim Angus --- libavformat/assenc.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/libavformat/assenc.c b/libavformat/assenc.c index 4c9ea6f982..f6f5293bb7 100644 --- a/libavformat/assenc.c +++ b/libavformat/assenc.c @@ -83,12 +83,12 @@ static int write_header(AVFormatContext *s) if (header_string[strlen(header_string) - 1] != '\n') avio_printf(s->pb, "\r\n"); -av_free(header_string); - -ass->ssa_mode = !strstr(par->extradata, "\n[V4+ Styles]"); -if (!strstr(par->extradata, "\n[Events]")) +ass->ssa_mode = !strstr(header_string, "\n[V4+ Styles]"); +if (!strstr(header_string, "\n[Events]")) avio_printf(s->pb, "[Events]\r\nFormat: %s, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text\r\n", ass->ssa_mode ? "Marked" : "Layer"); + +av_free(header_string); } return 0; Apparently extradata is padded with zeroes, so this is probably unnecessary, strictly speaking. Having said that, reasoning about why the code works is less obscure with the patch applied. ___ 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] lavfi: get rid of FF_INTERNAL_FIELDS
Quoting Nicolas George (2023-01-30 13:40:06) > Anton Khirnov (12023-01-30): > > This hack is used to limit the visibility of some AVFilterLink fields to > > only certain files. Replace it with the same pattern that is used e.g. > > in lavf AVStream/FFstream and avoid exposing these internal fields in a > > public header completely. > > --- > > libavfilter/avfilter.c | 191 +-- > > libavfilter/avfilter.h | 45 - > > libavfilter/avfiltergraph.c | 9 +- > > libavfilter/buffersink.c | 8 +- > > libavfilter/link_internal.h | 69 + > > libavfilter/tests/filtfmts.c | 9 +- > > 6 files changed, 196 insertions(+), 135 deletions(-) > > create mode 100644 libavfilter/link_internal.h > > This makes the code more verbose, less readable and harder to maintain, I find this a significant improvement in code quality, making it easier to maintain. > so no thanks. > > If you find a solution that does not require us to remember which field > is private and with field is public to prefix them with link-> or li->, > it would not have this issue; avoiding this requirement was a prime goal > of the current implementation. At least you did not add an indirection > like on some other places. Making it obvious which field is private and which is public is a feature, not a bug. I'll also note that - we've been switching to this precise pattern everywhere else in the project - the most prolific lavfi contributor recently (Paul) has no objections to this patch - the second most prolific lavfi contributor recently (Andreas) told me on IRC he planned to write this same patch himself So if you insist on objecting to this patch, it seems to me that a vote would be in order. -- Anton Khirnov ___ 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] lavfi: get rid of FF_INTERNAL_FIELDS
Anton Khirnov (12023-01-31): > I find this a significant improvement in code quality, making it easier > to maintain. You can say that, you do not maintain it. > Making it obvious which field is private and which is public is a > feature, not a bug. Then I do not want this feature. Making people expend effort for no reason at all. > I'll also note that > - we've been switching to this precise pattern everywhere else in the > project Well, too bad. > - the most prolific lavfi contributor recently (Paul) has no objections > to this patch > - the second most prolific lavfi contributor recently (Andreas) told me > on IRC he planned to write this same patch himself It is not a matter of volume, it is a matter of complexity. Since Stefano is no longer involved in the coding, I am the only one who knows how the tricky bits of libavfilter work. > So if you insist on objecting to this patch, it seems to me that a vote > would be in order. Well, go ahead, but please be aware that a vote cannot force me to maintain that code. If this project goes over my objections “that patch makes my maintenance work harder”, then be very careful to involve in your plans “find somebody else willing to debug the code of libavfilter”. Good luck. In fact, I think I will take it very easy with maintenance duty until further notice. I am really fed up with the direction this project is taking. Authoritarianism, that was the other side of the fork, and we all know what happened there. And who is to blame. -- Nicolas George ___ 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] lavfi: get rid of FF_INTERNAL_FIELDS
On 1/31/23, Nicolas George wrote: > Anton Khirnov (12023-01-31): >> I find this a significant improvement in code quality, making it easier >> to maintain. > > You can say that, you do not maintain it. > >> Making it obvious which field is private and which is public is a >> feature, not a bug. > > Then I do not want this feature. Making people expend effort for no > reason at all. > >> I'll also note that >> - we've been switching to this precise pattern everywhere else in the >> project > > Well, too bad. > >> - the most prolific lavfi contributor recently (Paul) has no objections >> to this patch >> - the second most prolific lavfi contributor recently (Andreas) told me >> on IRC he planned to write this same patch himself > > It is not a matter of volume, it is a matter of complexity. Since > Stefano is no longer involved in the coding, I am the only one who knows > how the tricky bits of libavfilter work. No, you do not. Calling your libavfilter framework code "complex" is disgrace to really complex code in non-framework part of libavfilter or else in FFmpeg libraries. libavfilter framework needs serious overhaul. It have numerous limitations and other stuff too much exposed to user, that really should not be. You do not maintain code at all, you just block patches and never contribute anymore anything useful besides blocking patches. > >> So if you insist on objecting to this patch, it seems to me that a vote >> would be in order. > > Well, go ahead, but please be aware that a vote cannot force me to > maintain that code. > > If this project goes over my objections “that patch makes my maintenance > work harder”, then be very careful to involve in your plans “find > somebody else willing to debug the code of libavfilter”. Good luck. > > In fact, I think I will take it very easy with maintenance duty until > further notice. I am really fed up with the direction this project is > taking. Authoritarianism, that was the other side of the fork, and we > all know what happened there. And who is to blame. > > -- > Nicolas George > ___ > 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] lavfi: get rid of FF_INTERNAL_FIELDS
Quoting Nicolas George (2023-01-31 15:03:34) > Anton Khirnov (12023-01-31): > > I find this a significant improvement in code quality, making it easier > > to maintain. > > You can say that, you do not maintain it. Do you? You keep implying in your emails that you are the authority on lavfi, but I see no objective support for this claim. MAINTAINERS only lists you as the maintainer for graphdump.c and two filters. And taken e.g. by the number of commits touching libavfilter/, mine is similar to yours, and both are far behind other people. > > - the most prolific lavfi contributor recently (Paul) has no objections > > to this patch > > - the second most prolific lavfi contributor recently (Andreas) told me > > on IRC he planned to write this same patch himself > > It is not a matter of volume, it is a matter of complexity. Since > Stefano is no longer involved in the coding, I am the only one who knows > how the tricky bits of libavfilter work. Maybe someone should replace those tricky bits with something simpler then. > > So if you insist on objecting to this patch, it seems to me that a vote > > would be in order. > > Well, go ahead, but please be aware that a vote cannot force me to > maintain that code. > > If this project goes over my objections “that patch makes my maintenance > work harder”, then be very careful to involve in your plans “find > somebody else willing to debug the code of libavfilter”. Good luck. > > In fact, I think I will take it very easy with maintenance duty until > further notice. I am really fed up with the direction this project is > taking. Authoritarianism, that was the other side of the fork, and we > all know what happened there. And who is to blame. Ah yes, preventing one person from enforcing his opinion over those of multiple other people is "authoritarianism". I don't think that word means what you think it means. So take your pick - either stop opposing this patch or we have a vote over it and see what other people think. -- Anton Khirnov ___ 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] lavfi: get rid of FF_INTERNAL_FIELDS
Anton Khirnov (12023-01-31): > Do you? > > You keep implying in your emails that you are the authority on lavfi, > but I see no objective support for this claim. MAINTAINERS only lists > you as the maintainer for graphdump.c and two filters. > And taken e.g. by the number of commits touching libavfilter/, mine is > similar to yours, and both are far behind other people. I know the code, how it works. I know how the code needs to evolve to achieve new features without breaking existing. I review and apply patches to fix bugs when they come; fortunately it does not happen frequently. > Maybe someone should replace those tricky bits with something simpler > then. Yes, do that, and I will laugh. The code is tricky because the needs are tricky. “Something simpler” is precisely what came from libav and I needed to fix a decade ago. > Ah yes, preventing one person from enforcing his opinion over those of > multiple other people is "authoritarianism". I don't think that word > means what you think it means. > > So take your pick - either stop opposing this patch or we have a vote > over it and see what other people think. Go ahead, have a vote. I no longer care. If it goes against me, that will make one less thing to consider my responsibility. We should never have asked ourselves “how should we change to entice forkers back”, we should have asked “how must the forkers change if they want to be accepted back”. You did not change. -- Nicolas George ___ 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] lavfi: get rid of FF_INTERNAL_FIELDS
Paul B Mahol (12023-01-31): > No, you do not. Calling your libavfilter framework code "complex" is disgrace > to really complex code in non-framework part of libavfilter or else in > FFmpeg libraries. > > libavfilter framework needs serious overhaul. > It have numerous limitations and other stuff too much exposed to user, > that really should not be. > > You do not maintain code at all, you just block patches and never > contribute anymore anything useful besides blocking patches. … says the person who does not know that the duration between pts=3 and pts=5 must be 2. This is a bad joke. -- Nicolas George ___ 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] lavfi: get rid of FF_INTERNAL_FIELDS
On 1/31/23, Nicolas George wrote: > Paul B Mahol (12023-01-31): >> No, you do not. Calling your libavfilter framework code "complex" is >> disgrace >> to really complex code in non-framework part of libavfilter or else in >> FFmpeg libraries. >> >> libavfilter framework needs serious overhaul. >> It have numerous limitations and other stuff too much exposed to user, >> that really should not be. >> >> You do not maintain code at all, you just block patches and never >> contribute anymore anything useful besides blocking patches. > > … says the person who does not know that the duration between pts=3 and > pts=5 must be 2. > > This is a bad joke. The patch just returned duration of frame from framesync and not actual duration of frame. And I have not tested it extensively at all or even thought about it much. Why? Because I find whole API including libavfilter very silly and broken and limited. At least I contributed numerous filters used in production, otherwise libavfilter would probably not exist today at all in this form at least. It would be already rewritten several times and/or whole idea abandoned completely because of lack of interest to develop it or poor usage. ___ 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] avformat/mxfenc: SMPTE RDD 48:2018 Amd 1:2022 (FFV1 in MXF) support
sön 2023-01-29 klockan 11:36 -0500 skrev Dave Rice: > > > > On Jan 20, 2023, at 10:17 AM, Tomas Härdin wrote: > > > > ons 2023-01-18 klockan 15:15 +0100 skrev Jerome Martinez: > > > On 18/01/2023 14:40, Tomas Härdin wrote: > > > > Creating a new subthread because I just noticed something > > > > > > I am a bit lost there because the line of code below is not part > > > of > > > this > > > FFV1 patch. > > > Additionally, none on my patches (FFV1 of MXF > > > stored/sampled/displayed > > > fix) modifies the discussed behavior (FFmpeg behavior would be > > > same > > > before and after this patch for MPEG-2 and AVC), so should not > > > block > > > any > > > of them, and a potential fix for that should have its own patch > > > as it > > > would be a separate issue. > > > > True, it doesn't need to hold up this patch. But some discussion is > > warranted I think. I might create a separate patchset for this. > > > > > > > > Anyway: > > > > > > > > > > > > > > > + //Stored height > > > > > mxf_write_local_tag(s, 4, 0x3202); > > > > > avio_wb32(pb, stored_height>>sc->interlaced); > > > > > > > > > Won't this be incorrect for files whose dimensions are > > > > multiples of > > > > 16 > > > > but not multiples of 32? Isn't each field stored separately > > > > with > > > > dimensions a multiple of 16? So while for 1080p we'll have > > > > > > > > StoredHeight = 1088 > > > > SampledHeight = 1080 > > > > > > > > and 1080i: > > > > > > > > StoredHeight = 544 > > > > SampledHeight = 540 > > > > > > > > Where 544 is a multiple of 16, for say 720p we have > > > > > > > > StoredHeight = 720 > > > > SampledHeight = 720 > > > > > > > > but for a hypothetical 720i we'd get > > > > > > > > StoredHeight = 360 > > > > SampledHeight = 360 > > > > > > > > whereas the correct values should be > > > > > > > > StoredHeight = 368 > > > > SampledHeight = 360 > > > > > > AFAIK, it would depend about if the stream has a > > > picture_structure > > > frame > > > (16x16 applies to the frame?) of field (16x16 applies to the > > > field?), > > > but I really don't know enough there for having a relevant > > > opinion. > > > > > > I can just say that I don't change the behavior of FFmpeg in your > > > use > > > case, I found the issues when I tried a random width and height > > > of > > > FFV1 > > > stream then checked with MPEG-2 Video and the sampled width was > > > wrong > > > for sure e.g. sampled width of 1920 for a stream having a width > > > of > > > 1912, > > > with current FFmpeg code, and for your use case I am sure about > > > nothing > > > so I don't change the behavior with my patch, IMO if there is an > > > issue > > > with 720i MPEG-2 Video it should be in a separate topic and patch > > > as > > > it > > > would modify the "stored_height = (st->codecpar- > > > >height+15)/16*16" > > > current code (in my patch I just move this code), unless we are > > > sure > > > of > > > what should be changed on this side and apply a fix on the way. > > > Better > > > to fix 1 issue and let 1 open with no change than fixing no issue > > > because we wouldn't be sure for 1 of the 2. > > > > I suspect we are lucky because 720i doesn't really exist in the > > real > > world, and 576i and 480i are both multiples of 32. > > > > IMO mxfenc shouldn't lie, but looking at S377m StoredWidth/Height > > are > > "best effort" and thus shall be encoded. Their values will depend > > on > > FrameLayout which in turn depends on what you say - how exactly the > > interlacing is done. > > > > TL;DR: this patchset doesn't need to be held up by this. > > I'm just nudging on the consideration of merging this patch. I've > been testing it over the last week with ffv1/mxf content and have > found this demuxing support very helpful. Surely you mean muxing? Some FATE tests would be nice. /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] avcodec/mlpdec: parse and use substream_info bits
On 1/31/23, Paul B Mahol wrote: > On 1/31/23, Andreas Rheinhardt wrote: >> Paul B Mahol: >>> +///< Which substream of substreams carry 16-channel presentation >>> +uint8_t extended_substream_info; >>> + >>> +///< Which substream of substreams carry 2/6/8-channel presentation >>> +uint8_t substream_info; >>> + >> >> Sure about the '<' in ///> applies to the entity directly before the ///<. > > I copied from other lines. Will apply with this fixed. ___ 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] configure: add -fno-semantic-interposition to optflags
Anton Khirnov:
> Gcc flag -fsemantic-interposition, which is on by default with current
> gcc versions, makes the compiler assume exported symbols can be
> interposed by the linker, which prevents various kinds of optimization.
>
> Since we do not support such interposition and disable it with
> -Bsymbolic, explicitly disable this assumption.
> ---
> configure | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/configure b/configure
> index cb895cf9ac..6f702bfb64 100755
> --- a/configure
> +++ b/configure
> @@ -7174,6 +7174,7 @@ check_optflags(){
> check_optflags $optflags
> check_optflags -fno-math-errno
> check_optflags -fno-signed-zeros
> +check_optflags -fno-semantic-interposition
>
> if enabled lto; then
> test "$cc_type" != "$ld_type" && die "LTO requires same compiler and
> linker"
This will add lots of dead HEVC functions in x86/hevcdsp_init.c; at
least it did this last time I checked: Several of these functions are
then inlined and because there are no callers outside of it, these
functions are dead code. Of course marking them as static would be
preferable, but that easier said than done with these macros.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavfi: get rid of FF_INTERNAL_FIELDS
Quoting Nicolas George (2023-01-31 15:31:44) > Anton Khirnov (12023-01-31): > > Do you? > > > > You keep implying in your emails that you are the authority on lavfi, > > but I see no objective support for this claim. MAINTAINERS only lists > > you as the maintainer for graphdump.c and two filters. > > And taken e.g. by the number of commits touching libavfilter/, mine is > > similar to yours, and both are far behind other people. > > I know the code, how it works. > > I know how the code needs to evolve to achieve new features without > breaking existing. > > I review and apply patches to fix bugs when they come; fortunately it > does not happen frequently. I still see no objective facts supporting your claim of exclusive maintainership over the entirety of lavfi generic code and public API. Considering yourself the maintainer in your own head is not enough. So to avoid any further pointless bickering, I'm hereby asking the TC to resolve this. To summarize my view, this patch is an improvement because: * it prevents filterlink internals from being visible in a public header, where they have no business being * it is a step towards hiding more of lavfi internals from public headers * the same pattern is already and ever more widely used in the other libraries and ffmpeg CLI * it is supported by Andreas (who submitted a more general analogue of this patch over a year ago) and Paul * I am not aware of anyone other than Nicolas being against it -- Anton Khirnov ___ 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] add media100 bsf and use it
Improved patch attached.
From ef7436580ce401917abab5114ff2ff8a1fdd9d61 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Tue, 31 Jan 2023 10:18:17 +0100
Subject: [PATCH] avcodec: add media100_to_mjpegb bitstream filter and use it
Signed-off-by: Paul B Mahol
---
configure | 1 +
libavcodec/Makefile | 3 +-
libavcodec/bitstream_filters.c | 1 +
libavcodec/media100.c | 224
libavcodec/media100_to_mjpegb_bsf.c | 170 +
libavcodec/mjpegbdec.c | 15 ++
6 files changed, 189 insertions(+), 225 deletions(-)
delete mode 100644 libavcodec/media100.c
create mode 100644 libavcodec/media100_to_mjpegb_bsf.c
diff --git a/configure b/configure
index 47790d10f5..174ae5c894 100755
--- a/configure
+++ b/configure
@@ -2850,6 +2850,7 @@ lscr_decoder_select="inflate_wrapper"
magicyuv_decoder_select="llviddsp"
magicyuv_encoder_select="llvidencdsp"
mdec_decoder_select="blockdsp bswapdsp idctdsp"
+media100_decoder_select="media100_to_mjpegb_bsf"
metasound_decoder_select="lsp sinewin"
mimic_decoder_select="blockdsp bswapdsp hpeldsp idctdsp"
mjpeg_decoder_select="blockdsp hpeldsp exif idctdsp jpegtables"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index df76d37598..4971832ff4 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -485,7 +485,7 @@ OBJS-$(CONFIG_MACE6_DECODER) += mace.o
OBJS-$(CONFIG_MAGICYUV_DECODER)+= magicyuv.o
OBJS-$(CONFIG_MAGICYUV_ENCODER)+= magicyuvenc.o
OBJS-$(CONFIG_MDEC_DECODER)+= mdec.o mpeg12.o mpeg12data.o
-OBJS-$(CONFIG_MEDIA100_DECODER)+= media100.o
+OBJS-$(CONFIG_MEDIA100_DECODER)+= mjpegbdec.o
OBJS-$(CONFIG_METASOUND_DECODER) += metasound.o twinvq.o
OBJS-$(CONFIG_MICRODVD_DECODER)+= microdvddec.o ass.o
OBJS-$(CONFIG_MIMIC_DECODER) += mimic.o
@@ -1221,6 +1221,7 @@ OBJS-$(CONFIG_HEVC_METADATA_BSF) += h265_metadata_bsf.o h265_profile_le
h2645data.o
OBJS-$(CONFIG_HEVC_MP4TOANNEXB_BSF) += hevc_mp4toannexb_bsf.o
OBJS-$(CONFIG_IMX_DUMP_HEADER_BSF)+= imx_dump_header_bsf.o
+OBJS-$(CONFIG_MEDIA100_TO_MJPEGB_BSF) += media100_to_mjpegb_bsf.o
OBJS-$(CONFIG_MJPEG2JPEG_BSF) += mjpeg2jpeg_bsf.o
OBJS-$(CONFIG_MJPEGA_DUMP_HEADER_BSF) += mjpega_dump_header_bsf.o
OBJS-$(CONFIG_MPEG4_UNPACK_BFRAMES_BSF) += mpeg4_unpack_bframes_bsf.o
diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
index a3bebefe5f..e8216819ca 100644
--- a/libavcodec/bitstream_filters.c
+++ b/libavcodec/bitstream_filters.c
@@ -43,6 +43,7 @@ extern const FFBitStreamFilter ff_hapqa_extract_bsf;
extern const FFBitStreamFilter ff_hevc_metadata_bsf;
extern const FFBitStreamFilter ff_hevc_mp4toannexb_bsf;
extern const FFBitStreamFilter ff_imx_dump_header_bsf;
+extern const FFBitStreamFilter ff_media100_to_mjpegb_bsf;
extern const FFBitStreamFilter ff_mjpeg2jpeg_bsf;
extern const FFBitStreamFilter ff_mjpega_dump_header_bsf;
extern const FFBitStreamFilter ff_mp3_header_decompress_bsf;
diff --git a/libavcodec/media100.c b/libavcodec/media100.c
deleted file mode 100644
index fdfce2cac1..00
--- a/libavcodec/media100.c
+++ /dev/null
@@ -1,224 +0,0 @@
-/*
- * Media 100 decoder
- * Copyright (c) 2022 Paul B Mahol
- *
- * 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
- */
-
-/**
- * @file
- * Media 100 decoder.
- */
-
-#include
-
-#include "libavutil/intreadwrite.h"
-#include "avcodec.h"
-#include "bytestream.h"
-#include "codec_internal.h"
-
-typedef struct Media100Context {
-AVCodecContext *avctx; // wrapper context for mjpegb
-AVPacket *pkt;
-} Media100Context;
-
-static av_cold int media100_decode_init(AVCodecContext *avctx)
-{
-Media100Context *ctx = avctx->priv_data;
-const AVCodec *codec;
-int ret;
-
-codec = avcodec_find_decoder(AV_CODEC_ID_MJPEGB);
-if (!codec)
-return AVERROR_BUG;
-ctx->avctx = avcodec_alloc_context3(codec);
-if (!ctx->avctx)
-return AVERROR(ENOMEM);
-ctx->avctx->thread_count = 1;
-ctx->avctx->flags = avctx->flags;
-ctx->avctx->flags2 = avctx->flags2;
-ctx->avctx->width = ctx->avctx->coded_
Re: [FFmpeg-devel] [PATCH] avcodec/libjxl: respect AVCodecContext->bits_per_raw_sample
On 1/30/23 11:53, Leo Izen wrote: On 1/27/23 07:18, Leo Izen wrote: libjxl only accepts 16-bit buffers with its API, but it can accept 9-bit to 15-bit input via a 16-bit buffer, provided the flag is set declaring the buffer to be of the respective significant depth. Likewise, it can only provide pixel data on decode as a 16-bit buffer (if higher than 8) but does provide the metadata tagging the actual bit depth. This commit causes libjxlenc.c and libjxldec.c to respect this metadata and tag/read it accordingly from AVCodecContext->bits_per_raw_sample. Signed-off-by: Leo Izen --- libavcodec/libjxldec.c | 17 + libavcodec/libjxlenc.c | 10 +- 2 files changed, 22 insertions(+), 5 deletions(-) Will merge soon if there are no objections - Leo Izen (thebombzen) Pushed. - Leo Izen (thebombzen) ___ 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] sws/utils.c: Do not uselessly call initFilter() when unscaling
Passes FATE
/Tomas
From 485b779b06085ca0b51eaf33a56f6ddade05b3c1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Tue, 31 Jan 2023 16:33:21 +0100
Subject: [PATCH] sws/utils.c: Do not uselessly call initFilter() when
unscaling
---
libswscale/utils.c | 62 +++---
1 file changed, 31 insertions(+), 31 deletions(-)
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 90734f66ef..925c536bf1 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -1701,6 +1701,37 @@ static av_cold int sws_init_single_context(SwsContext *c, SwsFilter *srcFilter,
}
}
+/* alpha blend special case, note this has been split via cascaded contexts if its scaled */
+if (unscaled && !usesHFilter && !usesVFilter &&
+c->alphablend != SWS_ALPHA_BLEND_NONE &&
+isALPHA(srcFormat) &&
+(c->srcRange == c->dstRange || isAnyRGB(dstFormat)) &&
+alphaless_fmt(srcFormat) == dstFormat
+) {
+c->convert_unscaled = ff_sws_alphablendaway;
+
+if (flags & SWS_PRINT_INFO)
+av_log(c, AV_LOG_INFO,
+"using alpha blendaway %s -> %s special converter\n",
+av_get_pix_fmt_name(srcFormat), av_get_pix_fmt_name(dstFormat));
+return 0;
+}
+
+/* unscaled special cases */
+if (unscaled && !usesHFilter && !usesVFilter &&
+(c->srcRange == c->dstRange || isAnyRGB(dstFormat) ||
+ isFloat(srcFormat) || isFloat(dstFormat))){
+ff_get_unscaled_swscale(c);
+
+if (c->convert_unscaled) {
+if (flags & SWS_PRINT_INFO)
+av_log(c, AV_LOG_INFO,
+ "using unscaled %s -> %s special converter\n",
+ av_get_pix_fmt_name(srcFormat), av_get_pix_fmt_name(dstFormat));
+return 0;
+}
+}
+
#if HAVE_MMAP && HAVE_MPROTECT && defined(MAP_ANONYMOUS)
#define USE_MMAP 1
#else
@@ -1905,37 +1936,6 @@ static av_cold int sws_init_single_context(SwsContext *c, SwsFilter *srcFilter,
c->chrXInc, c->chrYInc);
}
-/* alpha blend special case, note this has been split via cascaded contexts if its scaled */
-if (unscaled && !usesHFilter && !usesVFilter &&
-c->alphablend != SWS_ALPHA_BLEND_NONE &&
-isALPHA(srcFormat) &&
-(c->srcRange == c->dstRange || isAnyRGB(dstFormat)) &&
-alphaless_fmt(srcFormat) == dstFormat
-) {
-c->convert_unscaled = ff_sws_alphablendaway;
-
-if (flags & SWS_PRINT_INFO)
-av_log(c, AV_LOG_INFO,
-"using alpha blendaway %s -> %s special converter\n",
-av_get_pix_fmt_name(srcFormat), av_get_pix_fmt_name(dstFormat));
-return 0;
-}
-
-/* unscaled special cases */
-if (unscaled && !usesHFilter && !usesVFilter &&
-(c->srcRange == c->dstRange || isAnyRGB(dstFormat) ||
- isFloat(srcFormat) || isFloat(dstFormat))){
-ff_get_unscaled_swscale(c);
-
-if (c->convert_unscaled) {
-if (flags & SWS_PRINT_INFO)
-av_log(c, AV_LOG_INFO,
- "using unscaled %s -> %s special converter\n",
- av_get_pix_fmt_name(srcFormat), av_get_pix_fmt_name(dstFormat));
-return 0;
-}
-}
-
ff_sws_init_scale(c);
return ff_init_filters(c);
--
2.30.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] lavfi: get rid of FF_INTERNAL_FIELDS
Anton Khirnov (12023-01-31): > I still see no objective facts supporting your claim of exclusive > maintainership over the entirety of lavfi generic code and public API. The fact is very simple: I am the only one who understand how this code works. > So to avoid any further pointless bickering, I'm hereby asking the TC to > resolve this. Just so we are clear: you are a party in this, you can therefore not be a judge. > To summarize my view, this patch is an improvement because: > * it prevents filterlink internals from being visible in a > public header, where they have no business being > * it is a step towards hiding more of lavfi internals from public > headers > * the same pattern is already and ever more widely used in the other > libraries and ffmpeg CLI > * it is supported by Andreas (who submitted a more general analogue of > this patch over a year ago) and Paul > * I am not aware of anyone other than Nicolas being against it It is a worsening because: * It requires the developers to remember which field is public and which field is private, which is not something relevant here (is is relevant elsewhere). Of course, if you think about it two seconds, you realize it affects the person who knows the code very well and used/wants to work on it intensively more than the developers who move from one part of the code to another and have to re-learn everything. But thinking two seconds how your changes affects other people does not seem like your forte either. Therefore, I add this point: * If this change is applied, FFmpeg needs to find somebody else to maintain the core of libavfilter. (And I predict you will not.) -- Nicolas George 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] avcodec: add ACC_NON_HE decoder
As ACC decoder but with HE and HEv2 disabled.
Signed-off-by: Kristofer Björkström
---
Changelog| 1 +
configure| 1 +
libavcodec/Makefile | 3 +++
libavcodec/aacdec.c | 21 +
libavcodec/aacdec_template.c | 8
libavcodec/aactab.c | 2 +-
libavcodec/aarch64/Makefile | 4
libavcodec/allcodecs.c | 1 +
libavcodec/arm/Makefile | 4
libavcodec/mips/Makefile | 4
libavcodec/version.h | 2 +-
libavcodec/x86/Makefile | 4
tests/checkasm/Makefile | 2 ++
tests/checkasm/checkasm.c| 2 +-
14 files changed, 56 insertions(+), 3 deletions(-)
diff --git a/Changelog b/Changelog
index aa0dad13a1..a9f5b54baa 100644
--- a/Changelog
+++ b/Changelog
@@ -35,6 +35,7 @@ version :
- ffmpeg CLI new options: -enc_stats_pre[_fmt], -enc_stats_post[_fmt]
- hstack_vaapi, vstack_vaapi and xstack_vaapi filters
- XMD ADPCM decoder and demuxer
+- ACC NON HE decoder
version 5.1:
diff --git a/configure b/configure
index 47790d10f5..7a06c1a34c 100755
--- a/configure
+++ b/configure
@@ -2746,6 +2746,7 @@ rdft_select="fft"
# decoders / encoders
aac_decoder_select="adts_header mpeg4audio sinewin"
+aac_non_he_decoder_select="adts_header mpeg4audio sinewin"
aac_fixed_decoder_select="adts_header mpeg4audio"
aac_encoder_select="audio_frame_queue iirfilter lpc sinewin"
aac_latm_decoder_select="aac_decoder aac_latm_parser"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 304c2bc2e3..43d86e1899 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -180,6 +180,9 @@ OBJS-$(CONFIG_A64MULTI5_ENCODER) += a64multienc.o
elbg.o
OBJS-$(CONFIG_AAC_DECODER) += aacdec.o aactab.o aacsbr.o
aacps_common.o aacps_float.o \
kbdwin.o \
sbrdsp.o aacpsdsp_float.o cbrt_data.o
+OBJS-$(CONFIG_AAC_NON_HE_DECODER) += aacdec.o aactab.o aacsbr.o
aacps_common.o aacps_float.o \
+ kbdwin.o \
+ sbrdsp.o aacpsdsp_float.o cbrt_data.o
OBJS-$(CONFIG_AAC_FIXED_DECODER) += aacdec_fixed.o aactab.o
aacsbr_fixed.o aacps_common.o aacps_fixed.o \
kbdwin.o \
sbrdsp_fixed.o aacpsdsp_fixed.o
cbrt_data_fixed.o
diff --git a/libavcodec/aacdec.c b/libavcodec/aacdec.c
index ca31540d3c..b55de9e180 100644
--- a/libavcodec/aacdec.c
+++ b/libavcodec/aacdec.c
@@ -571,6 +571,27 @@ const FFCodec ff_aac_decoder = {
.p.profiles = NULL_IF_CONFIG_SMALL(ff_aac_profiles),
};
+const FFCodec ff_aac_non_he_decoder = {
+.p.name = "aac",
+CODEC_LONG_NAME("AAC (Advanced Audio Coding)"),
+.p.type = AVMEDIA_TYPE_AUDIO,
+.p.id= AV_CODEC_ID_AAC,
+.priv_data_size = sizeof(AACContext),
+.init= aac_decode_init,
+.close = aac_decode_close,
+FF_CODEC_DECODE_CB(aac_decode_frame),
+.p.sample_fmts = (const enum AVSampleFormat[]) {
+AV_SAMPLE_FMT_FLTP, AV_SAMPLE_FMT_NONE
+},
+.p.capabilities = AV_CODEC_CAP_CHANNEL_CONF | AV_CODEC_CAP_DR1,
+.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
+CODEC_OLD_CHANNEL_LAYOUTS_ARRAY(aac_channel_layout)
+.p.ch_layouts= aac_ch_layout,
+.flush = flush,
+.p.priv_class= &aac_decoder_class,
+.p.profiles = NULL_IF_CONFIG_SMALL(ff_aac_profiles),
+};
+
/*
Note: This decoder filter is intended to decode LATM streams transferred
in MPEG transport streams which only contain one program.
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 444dc4fa9d..bdadecac54 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -93,6 +93,7 @@
#include "libavutil/thread.h"
#include "decode.h"
#include "internal.h"
+#include "config_components.h"
static VLC vlc_scalefactors;
static VLC vlc_spectral[11];
@@ -1019,7 +1020,14 @@ static int decode_audio_specific_config_gb(AACContext
*ac,
*m4ac = m4ac_bak;
return AVERROR_INVALIDDATA;
}
+#if CONFIG_AAC_NON_HE_DECODER
+if (m4ac->ps > 0 || m4ac->sbr > 0 || avctx->profile >= FF_PROFILE_AAC_HE) {
+av_log(avctx, AV_LOG_ERROR, "HE-AAC is not supported\n");
+
+return AVERROR_INVALIDDATA;
+}
+#endif
skip_bits_long(gb, i);
switch (m4ac->object_type) {
diff --git a/libavcodec/aactab.c b/libavcodec/aactab.c
index 0f4941d5df..cf75904958 100644
--- a/libavcodec/aactab.c
+++ b/libavcodec/aactab.c
@@ -39,7 +39,7 @@
float ff_aac_pow2sf_tab[428];
float ff_aac_pow34sf_tab[428];
-#if CONFIG_AAC_ENCODER || CONFIG_AAC_DECODER
+#if CONFIG_AAC_ENCODER || CONFIG_AAC_DECODER || CONFIG_AAC_NON_HE_DECODER
#include "kbdwin.h"
#include "sinewin.h"
diff --git a/libavcodec/aarch64/Makefile b/libavcodec/aarch64/Makefile
index 02fb51c3ab..016371a1
Re: [FFmpeg-devel] [PATCH] lavfi: get rid of FF_INTERNAL_FIELDS
Nicolas George (12023-01-31): > > * it prevents filterlink internals from being visible in a > > public header, where they have no business being > > * it is a step towards hiding more of lavfi internals from public > > headers > > * the same pattern is already and ever more widely used in the other Note to the TC who will decide: I do not oppose the efforts mentioned in these two points (that are actually the same points twice), I only oppose this particular solution because of this drawback: > * It requires the developers to remember which field is public and which > field is private, which is not something relevant here (is is relevant > elsewhere). Without looking very far, I can think of several different ways of hiding the internal fields better without requiring changes to the implementation. I would not oppose such a change. -- Nicolas George ___ 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: deprecate CrystalHD decoders
On Tue, 31 Jan 2023, at 13:17, Anton Khirnov wrote: > The hardware is old and not relevant today. The decoders also have many > special quirks and are effectively unmaintained. Yes. LGTM. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ 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] Waveform Archiver decoder and demuxer
On 1/29/23, Paul B Mahol wrote: > Patches attached > will apply soon ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec: add ACC_NON_HE decoder
Jan 31, 2023, 17:34 by kristofer.bjorkst...@axis.com: > As ACC decoder but with HE and HEv2 disabled. > > Signed-off-by: Kristofer Björkström > --- > Changelog| 1 + > configure| 1 + > libavcodec/Makefile | 3 +++ > libavcodec/aacdec.c | 21 + > libavcodec/aacdec_template.c | 8 > libavcodec/aactab.c | 2 +- > libavcodec/aarch64/Makefile | 4 > libavcodec/allcodecs.c | 1 + > libavcodec/arm/Makefile | 4 > libavcodec/mips/Makefile | 4 > libavcodec/version.h | 2 +- > libavcodec/x86/Makefile | 4 > tests/checkasm/Makefile | 2 ++ > tests/checkasm/checkasm.c| 2 +- > 14 files changed, 56 insertions(+), 3 deletions(-) > > diff --git a/Changelog b/Changelog > index aa0dad13a1..a9f5b54baa 100644 > --- a/Changelog > +++ b/Changelog > @@ -35,6 +35,7 @@ version : > - ffmpeg CLI new options: -enc_stats_pre[_fmt], -enc_stats_post[_fmt] > - hstack_vaapi, vstack_vaapi and xstack_vaapi filters > - XMD ADPCM decoder and demuxer > +- ACC NON HE decoder > Why? Also, why a separate decoder rather than a --disable-he-aac config option? ___ 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] Waveform Archiver decoder and demuxer
Quoting Paul B Mahol (2023-01-31 18:11:10) > On 1/29/23, Paul B Mahol wrote: > > Patches attached > > > > will apply soon needs FATE tests -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec: add ACC_NON_HE decoder
Kristofer Björkström:
> As ACC decoder but with HE and HEv2 disabled.
>
> Signed-off-by: Kristofer Björkström
> ---
> Changelog| 1 +
> configure| 1 +
> libavcodec/Makefile | 3 +++
> libavcodec/aacdec.c | 21 +
> libavcodec/aacdec_template.c | 8
> libavcodec/aactab.c | 2 +-
> libavcodec/aarch64/Makefile | 4
> libavcodec/allcodecs.c | 1 +
> libavcodec/arm/Makefile | 4
> libavcodec/mips/Makefile | 4
> libavcodec/version.h | 2 +-
> libavcodec/x86/Makefile | 4
> tests/checkasm/Makefile | 2 ++
> tests/checkasm/checkasm.c| 2 +-
> 14 files changed, 56 insertions(+), 3 deletions(-)
>
> diff --git a/Changelog b/Changelog
> index aa0dad13a1..a9f5b54baa 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -35,6 +35,7 @@ version :
> - ffmpeg CLI new options: -enc_stats_pre[_fmt], -enc_stats_post[_fmt]
> - hstack_vaapi, vstack_vaapi and xstack_vaapi filters
> - XMD ADPCM decoder and demuxer
> +- ACC NON HE decoder
What is the aim of this? Is it patents?
>
>
> version 5.1:
> diff --git a/configure b/configure
> index 47790d10f5..7a06c1a34c 100755
> --- a/configure
> +++ b/configure
> @@ -2746,6 +2746,7 @@ rdft_select="fft"
>
> # decoders / encoders
> aac_decoder_select="adts_header mpeg4audio sinewin"
> +aac_non_he_decoder_select="adts_header mpeg4audio sinewin"
> aac_fixed_decoder_select="adts_header mpeg4audio"
> aac_encoder_select="audio_frame_queue iirfilter lpc sinewin"
> aac_latm_decoder_select="aac_decoder aac_latm_parser"
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 304c2bc2e3..43d86e1899 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -180,6 +180,9 @@ OBJS-$(CONFIG_A64MULTI5_ENCODER) += a64multienc.o
> elbg.o
> OBJS-$(CONFIG_AAC_DECODER) += aacdec.o aactab.o aacsbr.o
> aacps_common.o aacps_float.o \
>kbdwin.o \
>sbrdsp.o aacpsdsp_float.o
> cbrt_data.o
> +OBJS-$(CONFIG_AAC_NON_HE_DECODER) += aacdec.o aactab.o aacsbr.o
> aacps_common.o aacps_float.o \
> + kbdwin.o \
> + sbrdsp.o aacpsdsp_float.o
> cbrt_data.o
This will require keeping both these lists and all similar lists in all
arch-specific Makefiles in sync. This is maintainence work and prone to
fail; the usual way to achieve this aim is by making a decoder select
another one in configure.
> OBJS-$(CONFIG_AAC_FIXED_DECODER) += aacdec_fixed.o aactab.o
> aacsbr_fixed.o aacps_common.o aacps_fixed.o \
>kbdwin.o \
>sbrdsp_fixed.o aacpsdsp_fixed.o
> cbrt_data_fixed.o
> diff --git a/libavcodec/aacdec.c b/libavcodec/aacdec.c
> index ca31540d3c..b55de9e180 100644
> --- a/libavcodec/aacdec.c
> +++ b/libavcodec/aacdec.c
> @@ -571,6 +571,27 @@ const FFCodec ff_aac_decoder = {
> .p.profiles = NULL_IF_CONFIG_SMALL(ff_aac_profiles),
> };
>
> +const FFCodec ff_aac_non_he_decoder = {
> +.p.name = "aac",
> +CODEC_LONG_NAME("AAC (Advanced Audio Coding)"),
> +.p.type = AVMEDIA_TYPE_AUDIO,
> +.p.id= AV_CODEC_ID_AAC,
> +.priv_data_size = sizeof(AACContext),
> +.init= aac_decode_init,
> +.close = aac_decode_close,
> +FF_CODEC_DECODE_CB(aac_decode_frame),
> +.p.sample_fmts = (const enum AVSampleFormat[]) {
> +AV_SAMPLE_FMT_FLTP, AV_SAMPLE_FMT_NONE
> +},
> +.p.capabilities = AV_CODEC_CAP_CHANNEL_CONF | AV_CODEC_CAP_DR1,
> +.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
> +CODEC_OLD_CHANNEL_LAYOUTS_ARRAY(aac_channel_layout)
> +.p.ch_layouts= aac_ch_layout,
> +.flush = flush,
> +.p.priv_class= &aac_decoder_class,
> +.p.profiles = NULL_IF_CONFIG_SMALL(ff_aac_profiles),
> +};
> +
> /*
> Note: This decoder filter is intended to decode LATM streams transferred
> in MPEG transport streams which only contain one program.
> diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
> index 444dc4fa9d..bdadecac54 100644
> --- a/libavcodec/aacdec_template.c
> +++ b/libavcodec/aacdec_template.c
> @@ -93,6 +93,7 @@
> #include "libavutil/thread.h"
> #include "decode.h"
> #include "internal.h"
> +#include "config_components.h"
>
> static VLC vlc_scalefactors;
> static VLC vlc_spectral[11];
> @@ -1019,7 +1020,14 @@ static int decode_audio_specific_config_gb(AACContext
> *ac,
> *m4ac = m4ac_bak;
> return AVERROR_INVALIDDATA;
> }
> +#if CONFIG_AAC_NON_HE_DECODER
> +if (m4ac->ps > 0 || m4ac->sbr > 0 || avctx->profile >=
> FF_PROFILE_AAC_HE) {
>
> +av_log(avctx, AV_LOG_ERROR, "HE-AAC is not supported\n");
> +
> +return AVERROR_INVALIDDATA;
> +}
> +#e
Re: [FFmpeg-devel] [PATCH 2/3] avformat/lafdec: Check if all data was read
On Tue, Jan 31, 2023 at 12:21:24PM +0100, Andreas Rheinhardt wrote: > Michael Niedermayer: > > Fixes: OOM > > Fixes: > > 54572/clusterfuzz-testcase-minimized-ffmpeg_dem_LAF_fuzzer-4974038870523904 > > > > Found-by: continuous fuzzing process > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > Signed-off-by: Michael Niedermayer > > --- > > libavformat/lafdec.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/libavformat/lafdec.c b/libavformat/lafdec.c > > index d02b479c4d..b78ec3649c 100644 > > --- a/libavformat/lafdec.c > > +++ b/libavformat/lafdec.c > > @@ -208,6 +208,8 @@ again: > > ret = avio_read(pb, s->data, st_count * st->codecpar->sample_rate > > * bpp); > > if (ret < 0) > > return ret; > > +if (ret != st_count * st->codecpar->sample_rate * bpp) > > +return AVERROR_INVALIDDATA; > > } > > > > st = ctx->streams[s->index]; > > ffio_read() I assume you mean ffio_read_size(), will use that thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have often repented speaking, but never of holding my tongue. -- Xenocrates signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] avformat/lafdec: Check if all data was read
Michael Niedermayer: > On Tue, Jan 31, 2023 at 12:21:24PM +0100, Andreas Rheinhardt wrote: >> Michael Niedermayer: >>> Fixes: OOM >>> Fixes: >>> 54572/clusterfuzz-testcase-minimized-ffmpeg_dem_LAF_fuzzer-4974038870523904 >>> >>> Found-by: continuous fuzzing process >>> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg >>> Signed-off-by: Michael Niedermayer >>> --- >>> libavformat/lafdec.c | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/libavformat/lafdec.c b/libavformat/lafdec.c >>> index d02b479c4d..b78ec3649c 100644 >>> --- a/libavformat/lafdec.c >>> +++ b/libavformat/lafdec.c >>> @@ -208,6 +208,8 @@ again: >>> ret = avio_read(pb, s->data, st_count * st->codecpar->sample_rate >>> * bpp); >>> if (ret < 0) >>> return ret; >>> +if (ret != st_count * st->codecpar->sample_rate * bpp) >>> +return AVERROR_INVALIDDATA; >>> } >>> >>> st = ctx->streams[s->index]; >> >> ffio_read() > > I assume you mean ffio_read_size(), will use that > Yeah, I meant that. Sorry. - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/3] libavformat/lafdec: free data
On Tue, Jan 31, 2023 at 12:25:25PM +0100, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > Fixes: memleak
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavformat/lafdec.c | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/libavformat/lafdec.c b/libavformat/lafdec.c
> > index b78ec3649c..f6d2d5f235 100644
> > --- a/libavformat/lafdec.c
> > +++ b/libavformat/lafdec.c
> > @@ -253,6 +253,15 @@ again:
> > return 0;
> > }
> >
> > +static int laf_read_close(AVFormatContext *ctx)
> > +{
> > +LAFContext *s = ctx->priv_data;
> > +
> > +av_freep(&s->data);
> > +
> > +return 0;
> > +}
> > +
> > static int laf_read_seek(AVFormatContext *ctx, int stream_index,
> > int64_t timestamp, int flags)
> > {
> > @@ -270,6 +279,7 @@ const AVInputFormat ff_laf_demuxer = {
> > .read_probe = laf_probe,
> > .read_header= laf_read_header,
> > .read_packet= laf_read_packet,
> > +.read_close = laf_read_close,
> > .read_seek = laf_read_seek,
> > .extensions = "laf",
> > .flags = AVFMT_GENERIC_INDEX,
>
> Needs the FF_FMT_INIT_CLEANUP flag, too (otherwise it will leak in case
> of avformat_new_stream() failure).
ok, will apply with this
thx
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
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] lavfi: get rid of FF_INTERNAL_FIELDS
Nicolas George:
> Nicolas George (12023-01-31):
>>> * it prevents filterlink internals from being visible in a
>>> public header, where they have no business being
>>> * it is a step towards hiding more of lavfi internals from public
>>> headers
>>> * the same pattern is already and ever more widely used in the other
>
> Note to the TC who will decide: I do not oppose the efforts mentioned in
> these two points (that are actually the same points twice), I only
> oppose this particular solution because of this drawback:
>
>> * It requires the developers to remember which field is public and which
>> field is private, which is not something relevant here (is is relevant
>> elsewhere).
>
> Without looking very far, I can think of several different ways of
> hiding the internal fields better without requiring changes to the
> implementation. I would not oppose such a change.
>
Details please. I can only think of the following:
a) Allow the use of -fms-extensions. This allows structs with tags and
typedefs thereof to be used as unnamed struct members with the members
of the unnamed structure being treated as members of the enclosing
structure. One could then use a pointer to the big internal structure
internally and one does not need to remember whether a field is internal
or not. There is still a problem, though: One needs to cast from
AVFilterContext.(inputs|outputs). This should be done via dedicated
inlined getters, but this is a bit more typing. E.g.
"input_from_ctx(ctx, i)" instead of "ctx->inputs[i]". Of course, it
might also be shorter if someone has a short name.
GCC, Clang, MSVC and the IIRC the intel compilers support this.
b) Add a big #define AVFILTERLINK in avfilter.h that expands to the
public part of AVFilterLink and change the declaration of AVFilterLink
to "struct AVFilterLink { AVFILTERLINK };" and use declare the internal
struct via
"struct FilterLinkInternal {
AVFILTERLINK
/* actual internal fields */
};"
This has the downside of actually being an aliasing violation and of
adding considerable ugliness to avfilter.h, in particular during
deprecations (like with FF_API_OLD_CHANNEL_LAYOUT -- you can't check via
#if in the implementation of a macro). I also don't know whether it
plays nicely with tools that deal with source code annotations.
c) Wrap the internal part in an #ifdef HAVE_AV_CONFIG_H, optionally
using #if defined(HAVE_AV_CONFIG_H) && defined(BUILDING_avfilter).
d) Same as c), but strip this stuff from installed headers.
I consider b)-d) as inferior to a), which I consider superior to Anton's
proposal, but the big drawback is its reliance on a compiler extension.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavfi: get rid of FF_INTERNAL_FIELDS
Andreas Rheinhardt (12023-01-31):
> Details please.
I was not going to spend time explaining unless I had assurance it was
because the issue of requiring changes in the internal implementation
and developers habits just to hide some fields was taken into account.
Coming from somebody else, I would have expected the question to be only
to find the first excuses to shoot the proposal down.
But you more or less found the same ideas I did anyway.
> I can only think of the following:
> a) Allow the use of -fms-extensions. This allows structs with tags and
> typedefs thereof to be used as unnamed struct members with the members
> of the unnamed structure being treated as members of the enclosing
> structure. One could then use a pointer to the big internal structure
> internally and one does not need to remember whether a field is internal
> or not. There is still a problem, though: One needs to cast from
> AVFilterContext.(inputs|outputs). This should be done via dedicated
> inlined getters, but this is a bit more typing. E.g.
> "input_from_ctx(ctx, i)" instead of "ctx->inputs[i]". Of course, it
> might also be shorter if someone has a short name.
> GCC, Clang, MSVC and the IIRC the intel compilers support this.
>
> b) Add a big #define AVFILTERLINK in avfilter.h that expands to the
> public part of AVFilterLink and change the declaration of AVFilterLink
> to "struct AVFilterLink { AVFILTERLINK };" and use declare the internal
> struct via
> "struct FilterLinkInternal {
> AVFILTERLINK
> /* actual internal fields */
> };"
> This has the downside of actually being an aliasing violation and of
> adding considerable ugliness to avfilter.h, in particular during
> deprecations (like with FF_API_OLD_CHANNEL_LAYOUT -- you can't check via
> #if in the implementation of a macro). I also don't know whether it
> plays nicely with tools that deal with source code annotations.
Or use a “#include "avfilter_link_internal_fields.h" instead of a macro.
> c) Wrap the internal part in an #ifdef HAVE_AV_CONFIG_H, optionally
> using #if defined(HAVE_AV_CONFIG_H) && defined(BUILDING_avfilter).
> d) Same as c), but strip this stuff from installed headers.
>
> I consider b)-d) as inferior to a), which I consider superior to Anton's
> proposal, but the big drawback is its reliance on a compiler extension.
Once and for all: If the solution requires changing things in the
internal implementation C files and changing the habits of the people
who work on these files (that goes together), then it is inferior to a
solution that does not require that.
Your solution (a) has this flaw, plus relies on an extension that is
probably not available on all supported platforms (Microsoft I am
looking at you).
My favor goes to (d). Probably with a stricter test for the (c) part
because the internal fields are not necessary for the filters and
therefore could be hidden there too.
Regards,
--
Nicolas George
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] avcodec/pngdec: warn when reading tv-range cICP chunks
FFmpeg doesn't support tv-range RGB pixel data, so if we see a cICP
chunk that marks its RGB data as tv-range, we should print a warning
instead of setting it to AVCOL_RANGE_MPEG and having things possibly
mess up later down the line.
Signed-off-by: Leo Izen
---
libavcodec/pngdec.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index 0d969decf2..384ae97177 100644
--- a/libavcodec/pngdec.c
+++ b/libavcodec/pngdec.c
@@ -1511,8 +1511,10 @@ static int output_frame(PNGDecContext *s, AVFrame *f)
av_log(avctx, AV_LOG_WARNING, "unrecognized cICP transfer\n");
else
avctx->color_trc = f->color_trc = s->cicp_trc;
-avctx->color_range = f->color_range =
-s->cicp_range == 0 ? AVCOL_RANGE_MPEG : AVCOL_RANGE_JPEG;
+/* we don't support tv-range RGB */
+avctx->color_range = f->color_range = AVCOL_RANGE_JPEG;
+if (s->cicp_range == 0)
+av_log(avctx, AV_LOG_WARNING, "unsupported tv-range cICP chunk\n");
} else if (s->iccp_data) {
AVFrameSideData *sd = av_frame_new_side_data(f,
AV_FRAME_DATA_ICC_PROFILE, s->iccp_data_len);
if (!sd) {
--
2.39.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] lavfi: get rid of FF_INTERNAL_FIELDS
Nicolas George:
> Andreas Rheinhardt (12023-01-31):
>> Details please.
>
> I was not going to spend time explaining unless I had assurance it was
> because the issue of requiring changes in the internal implementation
> and developers habits just to hide some fields was taken into account.
> Coming from somebody else, I would have expected the question to be only
> to find the first excuses to shoot the proposal down.
>
> But you more or less found the same ideas I did anyway.
>
>> I can only think of the following:
>> a) Allow the use of -fms-extensions. This allows structs with tags and
>> typedefs thereof to be used as unnamed struct members with the members
>> of the unnamed structure being treated as members of the enclosing
>> structure. One could then use a pointer to the big internal structure
>> internally and one does not need to remember whether a field is internal
>> or not. There is still a problem, though: One needs to cast from
>> AVFilterContext.(inputs|outputs). This should be done via dedicated
>> inlined getters, but this is a bit more typing. E.g.
>> "input_from_ctx(ctx, i)" instead of "ctx->inputs[i]". Of course, it
>> might also be shorter if someone has a short name.
>> GCC, Clang, MSVC and the IIRC the intel compilers support this.
>>
>> b) Add a big #define AVFILTERLINK in avfilter.h that expands to the
>> public part of AVFilterLink and change the declaration of AVFilterLink
>> to "struct AVFilterLink { AVFILTERLINK };" and use declare the internal
>> struct via
>> "struct FilterLinkInternal {
>> AVFILTERLINK
>> /* actual internal fields */
>> };"
>> This has the downside of actually being an aliasing violation and of
>> adding considerable ugliness to avfilter.h, in particular during
>> deprecations (like with FF_API_OLD_CHANNEL_LAYOUT -- you can't check via
>> #if in the implementation of a macro). I also don't know whether it
>> plays nicely with tools that deal with source code annotations.
>
> Or use a “#include "avfilter_link_internal_fields.h" instead of a macro.
>
>> c) Wrap the internal part in an #ifdef HAVE_AV_CONFIG_H, optionally
>> using #if defined(HAVE_AV_CONFIG_H) && defined(BUILDING_avfilter).
>> d) Same as c), but strip this stuff from installed headers.
>>
>> I consider b)-d) as inferior to a), which I consider superior to Anton's
>> proposal, but the big drawback is its reliance on a compiler extension.
>
> Once and for all: If the solution requires changing things in the
> internal implementation C files and changing the habits of the people
> who work on these files (that goes together), then it is inferior to a
> solution that does not require that.
>
> Your solution (a) has this flaw, plus relies on an extension that is
> probably not available on all supported platforms (Microsoft I am
> looking at you).
>
It's called -fms-extensions for a reason.
> My favor goes to (d). Probably with a stricter test for the (c) part
> because the internal fields are not necessary for the filters and
> therefore could be hidden there too.
>
This can be accomplished with a), too. All one has to do is use multiple
levels of extensions.
- Andreas
PS: Upon rethinking, it is not only b) that contains undefined
behaviour; it is b)-d) as well as the current code. The reason is that
the type of AVFilterLink as seen in the files with FF_INTERNAL_FIELDS is
not compatible with the type of AVFilterLink from the files without
FF_INTERNAL_FIELDS. This also makes derived types, like the types of
function declarations containing pointers to AVFilterLink incompatible
and this is a violation of 6.2.7(2) of C11. I wonder if this will become
a real problem with lto someday.
___
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] x86: replace explicit REP_RETs with RETs
>From x86inc: > On AMD cpus <=K10, an ordinary ret is slow if it immediately follows either > a branch or a branch target. So switch to a 2-byte form of ret in that case. > We can automatically detect "follows a branch", but not a branch target. > (SSSE3 is a sufficient condition to know that your cpu doesn't have this > problem.) x86inc can automatically determine whether to use REP_RET rather than REP in most of these cases, so impact is minimal. Additionally, a few REP_RETs were used unnecessary, despite the return being nowhere near a branch. The only CPUs affected were AMD K10s, made between 2007 and 2011, 16 years ago and 12 years ago, respectively. In the future, everyone involved with x86inc should consider dropping REP_RETs altogether. Patch attached. >From bad08f738715805024ae13dbd1118f4cebc4fb68 Mon Sep 17 00:00:00 2001 From: Lynne Date: Wed, 1 Feb 2023 02:26:20 +0100 Subject: [PATCH] x86: replace explicit REP_RETs with RETs >From x86inc: > On AMD cpus <=K10, an ordinary ret is slow if it immediately follows either > a branch or a branch target. So switch to a 2-byte form of ret in that case. > We can automatically detect "follows a branch", but not a branch target. > (SSSE3 is a sufficient condition to know that your cpu doesn't have this problem.) x86inc can automatically determine whether to use REP_RET rather than REP in most of these cases, so impact is minimal. Additionally, a few REP_RETs were used unnecessary, despite the return being nowhere near a branch. The only CPUs affected were AMD K10s, made between 2007 and 2011, 16 years ago and 12 years ago, respectively. In the future, everyone involved with x86inc should consider dropping REP_RETs altogether. --- libavcodec/x86/aacpsdsp.asm | 10 - libavcodec/x86/ac3dsp.asm | 6 +++--- libavcodec/x86/alacdsp.asm | 4 ++-- libavcodec/x86/audiodsp.asm | 2 +- libavcodec/x86/dirac_dwt.asm| 14 ++--- libavcodec/x86/fft.asm | 8 +++ libavcodec/x86/flacdsp.asm | 8 +++ libavcodec/x86/h264_chromamc.asm| 18 libavcodec/x86/h264_chromamc_10bit.asm | 10 - libavcodec/x86/h264_deblock_10bit.asm | 6 +++--- libavcodec/x86/h264_idct.asm| 10 - libavcodec/x86/h264_idct_10bit.asm | 8 +++ libavcodec/x86/h264_intrapred.asm | 24 ++--- libavcodec/x86/h264_intrapred_10bit.asm | 16 +++--- libavcodec/x86/h264_qpel_10bit.asm | 2 +- libavcodec/x86/h264_qpel_8bit.asm | 26 +++ libavcodec/x86/h264_weight.asm | 12 +-- libavcodec/x86/h264_weight_10bit.asm| 12 +-- libavcodec/x86/hevc_sao.asm | 2 +- libavcodec/x86/hevc_sao_10bit.asm | 2 +- libavcodec/x86/hpeldsp.asm | 20 +- libavcodec/x86/hpeldsp_vp3.asm | 4 ++-- libavcodec/x86/huffyuvdsp.asm | 2 +- libavcodec/x86/jpeg2000dsp.asm | 4 ++-- libavcodec/x86/lossless_videodsp.asm| 2 +- libavcodec/x86/lossless_videoencdsp.asm | 2 +- libavcodec/x86/me_cmp.asm | 2 +- libavcodec/x86/pngdsp.asm | 2 +- libavcodec/x86/qpel.asm | 6 +++--- libavcodec/x86/qpeldsp.asm | 12 +-- libavcodec/x86/rv34dsp.asm | 2 +- libavcodec/x86/rv40dsp.asm | 10 - libavcodec/x86/sbrdsp.asm | 12 +-- libavcodec/x86/takdsp.asm | 8 +++ libavcodec/x86/utvideodsp.asm | 4 ++-- libavcodec/x86/v210.asm | 2 +- libavcodec/x86/vc1dsp_mc.asm| 2 +- libavcodec/x86/videodsp.asm | 2 +- libavcodec/x86/vp8dsp.asm | 28 - libavfilter/x86/af_volume.asm | 6 +++--- libavfilter/x86/avf_showcqt.asm | 4 ++-- libavfilter/x86/scene_sad.asm | 2 +- libavfilter/x86/vf_blend.asm| 2 +- libavfilter/x86/vf_framerate.asm| 2 +- libavfilter/x86/vf_gradfun.asm | 6 +++--- libavfilter/x86/vf_hqdn3d.asm | 2 +- libavfilter/x86/vf_interlace.asm| 6 +++--- libavfilter/x86/vf_maskedmerge.asm | 2 +- libavfilter/x86/vf_stereo3d.asm | 2 +- libavfilter/x86/vf_w3fdif.asm | 10 - libavutil/x86/float_dsp.asm | 18 libavutil/x86/lls.asm | 4 ++-- libswresample/x86/audio_convert.asm | 12 +-- libswresample/x86/rematrix.asm | 8 +++ libswscale/x86/input.asm| 14 ++--- libswscale/x86/output.asm | 10 - libswscale/x86/scale.asm| 2 +- libswscale/x86/scale_avx2.asm | 2 +- libswscale/x86/yuv2yuvX.asm | 2 +- libswscale/x86/yuv_2_rgb.asm| 2 +- tests/checkasm/x86/checkasm.asm | 2 +- 61
Re: [FFmpeg-devel] [PATCH] x86: replace explicit REP_RETs with RETs
lgtm ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode: fix propagating durations and opaques
On Di, 2023-01-31 at 14:14 +0100, Anton Khirnov wrote:
> input_image is freed by the time the output packet is constructed, so we
> need to store copies in VAAPIEncodePicture.
> ---
> Is this better?
> ---
> libavcodec/vaapi_encode.c | 22 +-
> libavcodec/vaapi_encode.h | 4
> 2 files changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index 6787b90e8d6..bfca315a7ad 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -695,7 +695,7 @@ static int vaapi_encode_output(AVCodecContext *avctx,
> pkt->flags |= AV_PKT_FLAG_KEY;
>
> pkt->pts = pic->pts;
> -pkt->duration = pic->input_image->duration;
> +pkt->duration = pic->duration;
>
> vas = vaUnmapBuffer(ctx->hwctx->display, pic->output_buffer);
> if (vas != VA_STATUS_SUCCESS) {
> @@ -706,10 +706,11 @@ static int vaapi_encode_output(AVCodecContext *avctx,
> }
>
> // for no-delay encoders this is handled in generic codec
> -if (avctx->codec->capabilities & AV_CODEC_CAP_DELAY) {
> -err = ff_encode_reordered_opaque(avctx, pkt, pic->input_image);
> -if (err < 0)
> -goto fail;
> +if (avctx->codec->capabilities & AV_CODEC_CAP_DELAY &&
> +avctx->flags & AV_CODEC_FLAG_COPY_OPAQUE) {
> +pkt->opaque = pic->opaque;
> +pkt->opaque_ref = pic->opaque_ref;
> +pic->opaque_ref = NULL;
> }
>
> av_buffer_unref(&pic->output_buffer_ref);
> @@ -785,6 +786,8 @@ static int vaapi_encode_free(AVCodecContext *avctx,
> av_frame_free(&pic->input_image);
> av_frame_free(&pic->recon_image);
>
> +av_buffer_unref(&pic->opaque_ref);
> +
> av_freep(&pic->param_buffers);
> av_freep(&pic->slices);
> // Output buffer should already be destroyed.
> @@ -1152,6 +1155,15 @@ static int vaapi_encode_send_frame(AVCodecContext
> *avctx, AVFrame *frame)
>
> pic->input_surface = (VASurfaceID)(uintptr_t)frame->data[3];
> pic->pts = frame->pts;
> +pic->duration = frame->duration;
> +
> +if (avctx->flags & AV_CODEC_FLAG_COPY_OPAQUE) {
> +err = av_buffer_replace(&pic->opaque_ref, frame->opaque_ref);
> +if (err < 0)
> +goto fail;
> +
> +pic->opaque = frame->opaque;
> +}
>
> av_frame_move_ref(pic->input_image, frame);
>
> diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
> index 359f954..a1e639f56b0 100644
> --- a/libavcodec/vaapi_encode.h
> +++ b/libavcodec/vaapi_encode.h
> @@ -75,8 +75,12 @@ typedef struct VAAPIEncodePicture {
> int64_t display_order;
> int64_t encode_order;
> int64_t pts;
> +int64_t duration;
> int force_idr;
>
> +void *opaque;
> +AVBufferRef*opaque_ref;
> +
> #if VA_CHECK_VERSION(1, 0, 0)
> // ROI regions.
> VAEncROI *roi;
LGTM and the command for transcoding with vaapi works well now.
BRs
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] x86: replace explicit REP_RETs with RETs
Feb 1, 2023, 03:00 by hen...@gramner.com: > lgtm > Thanks, pushed. ___ 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/2] PNG sBIT chunk support
Add support to the PNG decoder and encoder to support sBIT chunks. Leo Izen (2): avcodec/pngdec: support sBIT chunks avcodec/pngenc: write sBIT chunks libavcodec/pngdec.c | 57 + libavcodec/pngenc.c | 7 ++ 2 files changed, 64 insertions(+) -- 2.39.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 1/2] avcodec/pngdec: support sBIT chunks
Add support for reading sBIT chunks, which mark the significant
bit depth of the PNG file. This passes the metadata using the field
bits_per_raw_sample of AVCodecContext.
Signed-off-by: Leo Izen
---
libavcodec/pngdec.c | 57 +
1 file changed, 57 insertions(+)
diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index 0d969decf2..48313db671 100644
--- a/libavcodec/pngdec.c
+++ b/libavcodec/pngdec.c
@@ -97,6 +97,7 @@ typedef struct PNGDecContext {
int bpp;
int has_trns;
uint8_t transparent_color_be[6];
+int significant_bits;
uint32_t palette[256];
uint8_t *crow_buf;
@@ -916,6 +917,55 @@ fail:
return ret;
}
+static int decode_sbit_chunk(AVCodecContext *avctx, PNGDecContext *s,
+ GetByteContext *gb)
+{
+int bits = 0;
+
+if (!(s->hdr_state & PNG_IHDR)) {
+av_log(avctx, AV_LOG_ERROR, "sBIT before IHDR\n");
+return AVERROR_INVALIDDATA;
+}
+
+switch (s->color_type) {
+case 0:
+bits = bytestream2_get_byteu(gb);
+break;
+case 2:
+case 3: {
+int r = bytestream2_get_byteu(gb);
+int g = bytestream2_get_byteu(gb);
+int b = bytestream2_get_byteu(gb);
+bits = FFMAX3(r, g, b);
+break;
+}
+case 4: {
+int y = bytestream2_get_byteu(gb);
+int a = bytestream2_get_byteu(gb);
+bits = FFMAX(y, a);
+break;
+}
+case 6: {
+int r = bytestream2_get_byteu(gb);
+int g = bytestream2_get_byteu(gb);
+int b = bytestream2_get_byteu(gb);
+int a = bytestream2_get_byteu(gb);
+bits = FFMAX(FFMAX3(r, g, b), a);
+break;
+}
+default:
+return AVERROR_INVALIDDATA;
+}
+
+if (bits < 0 || bits > s->bit_depth) {
+av_log(avctx, AV_LOG_ERROR, "Invalid significant bits: %d\n", bits);
+return AVERROR_INVALIDDATA;
+}
+s->significant_bits = bits;
+
+return 0;
+}
+
static void handle_small_bpp(PNGDecContext *s, AVFrame *p)
{
if (s->bits_per_pixel == 1 && s->color_type == PNG_COLOR_TYPE_PALETTE) {
@@ -1355,6 +1405,9 @@ static int decode_frame_common(AVCodecContext *avctx,
PNGDecContext *s,
break;
}
+case MKTAG('s', 'B', 'I', 'T'):
+decode_sbit_chunk(avctx, s, &gb_chunk);
+break;
case MKTAG('g', 'A', 'M', 'A'): {
AVBPrint bp;
char *gamma_str;
@@ -1560,6 +1613,10 @@ static int output_frame(PNGDecContext *s, AVFrame *f)
stereo3d->flags = s->stereo_mode ? 0 : AV_STEREO3D_FLAG_INVERT;
}
+/* tRNS sets alpha depth to full, so we ignore sBIT if set */
+if (!s->has_trns && s->significant_bits > 0)
+avctx->bits_per_raw_sample = s->significant_bits;
+
FFSWAP(AVDictionary*, f->metadata, s->frame_metadata);
return 0;
--
2.39.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/2] avcodec/pngenc: write sBIT chunks
Add support for writing sBIT chunks, which mark the significant
bit depth of the PNG file. This obtains the metadata using the field
bits_per_raw_sample of AVCodecContext.
Signed-off-by: Leo Izen
---
libavcodec/pngenc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/libavcodec/pngenc.c b/libavcodec/pngenc.c
index 2393161c3b..0961125f0a 100644
--- a/libavcodec/pngenc.c
+++ b/libavcodec/pngenc.c
@@ -432,6 +432,13 @@ static int encode_headers(AVCodecContext *avctx, const
AVFrame *pict)
if (png_get_gama(pict->color_trc, s->buf))
png_write_chunk(&s->bytestream, MKTAG('g', 'A', 'M', 'A'), s->buf, 4);
+if (avctx->bits_per_raw_sample > 0 && avctx->bits_per_raw_sample <
s->bit_depth) {
+size_t len = s->color_type == 0 ? 1 : s->color_type == 2 ||
s->color_type == 3 ? 3 :
+ s->color_type == 4 ? 2 : 4;
+memset(s->buf, avctx->bits_per_raw_sample, len);
+png_write_chunk(&s->bytestream, MKTAG('s', 'B', 'I', 'T'), s->buf,
len);
+}
+
side_data = av_frame_get_side_data(pict, AV_FRAME_DATA_ICC_PROFILE);
if ((ret = png_write_iccp(s, side_data)))
return ret;
--
2.39.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/5] lavfi: add a new filtergraph parsing API
Quoting Nicolas George (2023-01-30 13:59:44)
> > +static unsigned
> > +find_linklabel(AVFilterGraphSegment *seg, const char *label,
> > + int output, size_t idx_chain, size_t idx_filter,
> > + AVFilterParams **pp)
> > +{
> > +for (; idx_chain < seg->nb_chains; idx_chain++) {
> > +AVFilterChain *ch = seg->chains[idx_chain];
> > +
> > +for (; idx_filter < ch->nb_filters; idx_filter++) {
> > +AVFilterParams *p = ch->filters[idx_filter];
> > +AVFilterPadParams **io = output ? p->outputs: p->inputs;
> > +unsigned nb_io = output ? p->nb_outputs : p->nb_inputs;
> > +AVFilterLink **l;
> > +unsigned nb_l;
> > +
> > +if (!p->filter)
> > +continue;
> > +
> > +l= output ? p->filter->outputs: p->filter->inputs;
> > +nb_l = output ? p->filter->nb_outputs : p->filter->nb_inputs;
> > +
> > +for (unsigned i = 0; i < FFMIN(nb_io, nb_l); i++)
> > +if (!l[i] && io[i]->label && !strcmp(io[i]->label, label))
> > {
> > +*pp = p;
> > +return i;
> > +}
> > +}
> > +
> > +idx_filter = 0;
> > +}
> > +
> > +*pp = NULL;
> > +return 0;
> > +}
>
> If I read this code correctly, it will only find link labels that are
> defined later in the chain or in a later chain. But referring to earlier
> link labels is supported. Even cycles are meant to be supported at
> parsing level (format negotiation will likely fail, though, but being
> able to make cycles was a goal from the start).
The earlier filters have already been processed at this point, so if an
earlier filter had a link label that would match this one, then it's
already been linked. So there's no point in considering earlier filters.
--
Anton Khirnov
___
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] lavfi: get rid of FF_INTERNAL_FIELDS
Andreas Rheinhardt (12023-02-01): > PS: Upon rethinking, it is not only b) that contains undefined > behaviour; it is b)-d) as well as the current code. The reason is that > the type of AVFilterLink as seen in the files with FF_INTERNAL_FIELDS is > not compatible with the type of AVFilterLink from the files without > FF_INTERNAL_FIELDS. This also makes derived types, like the types of > function declarations containing pointers to AVFilterLink incompatible > and this is a violation of 6.2.7(2) of C11. I wonder if this will become > a real problem with lto someday. No: read the second half of the previous paragraph: two structures with common first fields are compatible types. What we have been using is a deliberately supported construct. Regards, -- Nicolas George ___ 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".
