Re: [FFmpeg-devel] [PATCH] lavc/qsvenc: Set default bitrate to 2M
On Ma, 2023-12-18 at 06:51 +, Xiang, Haihao wrote:
> On Do, 2023-12-07 at 17:59 +0100, Anton Khirnov wrote:
> > Quoting Timo Rothenpieler (2023-12-06 13:26:51)
> > > On 06/12/2023 07:51, Xiang, Haihao wrote:
> > > > On Di, 2023-12-05 at 12:47 +0100, Timo Rothenpieler wrote:
> > > > > On 05.12.2023 09:15, Xiang, Haihao wrote:
> > > > > > From: Haihao Xiang
> > > > > >
> > > > > > 2M is suitable for more cases, e.g. 4K video.
> > > > > >
> > > > > > Signed-off-by: Haihao Xiang
> > > > > > ---
> > > > > > libavcodec/qsvenc_av1.c | 2 +-
> > > > > > libavcodec/qsvenc_h264.c | 2 +-
> > > > > > libavcodec/qsvenc_hevc.c | 2 +-
> > > > > > libavcodec/qsvenc_mpeg2.c | 2 +-
> > > > > > libavcodec/qsvenc_vp9.c | 2 +-
> > > > > > 5 files changed, 5 insertions(+), 5 deletions(-)
> > > > > >
> > > > > > diff --git a/libavcodec/qsvenc_av1.c b/libavcodec/qsvenc_av1.c
> > > > > > index c697845d7b..78c92c1844 100644
> > > > > > --- a/libavcodec/qsvenc_av1.c
> > > > > > +++ b/libavcodec/qsvenc_av1.c
> > > > > > @@ -129,7 +129,7 @@ static const AVClass class = {
> > > > > > };
> > > > > >
> > > > > > static const FFCodecDefault qsv_enc_defaults[] = {
> > > > > > - { "b", "1M" },
> > > > > > + { "b", "2M" },
> > > > >
> > > > > Wouldn't it be better to use a constant quality option as default,
> > > > > rather than a fixed bitrate?
> > > >
> > > > Did you mean change the default bitrate control mode to CQP ? I was
> > > > concerned
> > > > about the impact to current users.
> > >
> > > Yeah, it's technically a breaking change.
> > > Though at least libx264 also at some point changed its default to a
> > > reasonable medium quality crf mode, away from a fixed, rather low,
> > > bitrate.
> > > Not sure if that was done on a major bump, or if it was considered low
> > > impact enough to just push out.
> >
> > FYI we should have a major bump if the next few months (before 7.0).
> >
> > So you could schedule the switch for then, ideally with a runtime
> > warning and perhaps a changelog entry.
>
> Thanks for the info, we'll try to change the default mode.
See https://ffmpeg.org/pipermail/ffmpeg-devel/2024-February/321088.html
Thanks
Haihao
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 8/9] avcodec: add D3D12VA hardware HEVC encoder
>> From: Tong Wu
>>
>> This implementation is based on D3D12 Video Encoding Spec:
>> https://microsoft.github.io/DirectX-Specs/d3d/D3D12VideoEncoding.html
>>
>> Sample command line for transcoding:
>> ffmpeg.exe -hwaccel d3d12va -hwaccel_output_format d3d12 -i input.mp4
>> -c:v hevc_d3d12va output.mp4
>>
>> Signed-off-by: Tong Wu
>> ---
>> configure|6 +
>> libavcodec/Makefile |4 +-
>> libavcodec/allcodecs.c |1 +
>> libavcodec/d3d12va_encode.c | 1441 ++
>> libavcodec/d3d12va_encode.h | 275 ++
>> libavcodec/d3d12va_encode_hevc.c | 1011 +
>> libavcodec/hw_base_encode.h |2 +-
>> 7 files changed, 2738 insertions(+), 2 deletions(-)
>> create mode 100644 libavcodec/d3d12va_encode.c
>> create mode 100644 libavcodec/d3d12va_encode.h
>> create mode 100644 libavcodec/d3d12va_encode_hevc.c
>>
>>
>>+min_cu_size = d3d12va_encode_hevc_map_cusize(ctx-
>>codec_conf.pHEVCConfig->MinLumaCodingUnitSize);
>>+max_cu_size = d3d12va_encode_hevc_map_cusize(ctx-
>>codec_conf.pHEVCConfig->MaxLumaCodingUnitSize);
>>+min_tu_size = d3d12va_encode_hevc_map_tusize(ctx-
>>codec_conf.pHEVCConfig->MinLumaTransformUnitSize);
>>+max_tu_size = d3d12va_encode_hevc_map_tusize(ctx-
>>codec_conf.pHEVCConfig->MaxLumaTransformUnitSize);
>>+
>>+// VPS
>>+
>>+vps->nal_unit_header = (H265RawNALUnitHeader) {
>
>Should this blank line be removed, because the comment is for the codes
>below?
>
>> +vps->vps_timing_info_present_flag = 0;
>> +
>> +// SPS
>> +
>> +sps->nal_unit_header = (H265RawNALUnitHeader) {
>> +.nal_unit_type = HEVC_NAL_SPS,
>> +.nuh_layer_id = 0,
>> +.nuh_temporal_id_plus1 = 1,
>> +};
>The same as above.
>
>> +static uint8_t
>d3d12va_encode_hevc_map_cusize(D3D12_VIDEO_ENCODER_CODEC_CONFI
>GURATION_HEVC_CUSIZE cusize)
>> +{
>> +switch (cusize) {
>> +case
>D3D12_VIDEO_ENCODER_CODEC_CONFIGURATION_HEVC_CUSIZE_8x8:
>return 8;
>> +case
>D3D12_VIDEO_ENCODER_CODEC_CONFIGURATION_HEVC_CUSIZE_16x16:
>return 16;
>> +case
>D3D12_VIDEO_ENCODER_CODEC_CONFIGURATION_HEVC_CUSIZE_32x32:
>return 32;
>> +case
>D3D12_VIDEO_ENCODER_CODEC_CONFIGURATION_HEVC_CUSIZE_64x64:
>return 64;
>> +}
>> +return 0;
>> +}
>> +
>> +static uint8_t
>d3d12va_encode_hevc_map_tusize(D3D12_VIDEO_ENCODER_CODEC_CONFI
>GURATION_HEVC_TUSIZE tusize)
>> +{
>> +switch (tusize) {
>> +case
>D3D12_VIDEO_ENCODER_CODEC_CONFIGURATION_HEVC_TUSIZE_4x4:
>return 4;
>> +case
>D3D12_VIDEO_ENCODER_CODEC_CONFIGURATION_HEVC_TUSIZE_8x8:
>return 8;
>> +case
>D3D12_VIDEO_ENCODER_CODEC_CONFIGURATION_HEVC_TUSIZE_16x16:
>return 16;
>> +case
>D3D12_VIDEO_ENCODER_CODEC_CONFIGURATION_HEVC_TUSIZE_32x32:
>return 32;
>> +}
>> +return 0;
>> +}
>
>A default branch is needed or we can use 8 << cusize and 4 << tusize for
>simplification.
>
>> +hr = ID3D12Device3_QueryInterface(ctx->device3,
>_ID3D12VideoDevice3, (void **)>video_device3);
>> +if (FAILED(hr)) {
>> +err = AVERROR_UNKNOWN;
>> +goto fail;
>> +}
>> +
>> +if (FAILED(ID3D12VideoDevice3_CheckFeatureSupport(ctx-
>>video_device3, D3D12_FEATURE_VIDEO_FEATURE_AREA_SUPPORT,
>> + ,
>> sizeof(support)))
>&& !support.VideoEncodeSupport) {
>> +av_log(avctx, AV_LOG_ERROR, "D3D12 video device has no video
>encoder support");
>> +err = AVERROR(EINVAL);
>> +goto fail;
>> +}
>
>We need to output the log for the ID3D12Device3_QueryInterface call, or the
>user will not know the error is resulting from that,
>the OS and the driver don't support the ID3D12VideoDevice3 interface.
Have updated in v4. Thanks for the review.
BRs,
Tong
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] lavc/qsvenc: update the selection of bitrate control method
From: Haihao Xiang
The default method is changed to CQP
Signed-off-by: Haihao Xiang
---
Changelog | 1 +
doc/encoders.texi | 7 +++--
libavcodec/qsvenc.c | 59 +++
libavcodec/qsvenc_av1.c | 2 +-
libavcodec/qsvenc_h264.c | 2 +-
libavcodec/qsvenc_hevc.c | 2 +-
libavcodec/qsvenc_mpeg2.c | 2 +-
libavcodec/qsvenc_vp9.c | 2 +-
8 files changed, 52 insertions(+), 25 deletions(-)
diff --git a/Changelog b/Changelog
index c5fb21d198..b9e4536233 100644
--- a/Changelog
+++ b/Changelog
@@ -24,6 +24,7 @@ version :
- ffmpeg CLI options may now be used as -/opt , which is equivalent
to -opt >
- showinfo bitstream filter
+- Change the default bitrate control method from VBR to CQP for QSV encoders.
version 6.1:
- libaribcaption decoder
diff --git a/doc/encoders.texi b/doc/encoders.texi
index c9fe6d6143..d1363c2174 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -3332,8 +3332,8 @@ quality range is 1 to 51, with 1 being the best quality.
@end itemize
@item
-Otherwise, a bitrate-based mode is used. For all of those, you should specify
at
-least the desired average bitrate with the @option{b} option.
+Otherwise when the desired average bitrate is specified with the @option{b}
+option, a bitrate-based mode is used.
@itemize @minus
@item
@var{LA} - VBR with lookahead, when the @option{look_ahead} option is
specified.
@@ -3354,6 +3354,9 @@ than the average bitrate.
@option{avbr_accuracy} and @option{avbr_convergence} are set to non-zero. This
mode is available for H264 and HEVC on Windows.
@end itemize
+
+@item
+Otherwise the default ratecontrol method @var{CQP} is used.
@end itemize
Note that depending on your system, a different mode than the one you specified
diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index c63b72e384..8c6414f8ca 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -597,6 +597,12 @@ static int select_rc_mode(AVCodecContext *avctx,
QSVEncContext *q)
else if (want_vcm) {
rc_mode = MFX_RATECONTROL_VCM;
rc_desc = "video conferencing mode (VCM)";
+
+if (!avctx->bit_rate) {
+av_log(avctx, AV_LOG_ERROR, "Using the %s ratecontrol method.
Please "
+ "use the b option to set the desired bitrate.\n", rc_desc);
+return AVERROR(EINVAL);
+}
}
#endif
else if (want_la) {
@@ -606,32 +612,49 @@ static int select_rc_mode(AVCodecContext *avctx,
QSVEncContext *q)
if (avctx->global_quality > 0) {
rc_mode = MFX_RATECONTROL_LA_ICQ;
rc_desc = "intelligent constant quality with lookahead (LA_ICQ)";
+} else if (!avctx->bit_rate) {
+av_log(avctx, AV_LOG_ERROR, "Using the %s ratecontrol method.
Please "
+ "use the b option to set the desired bitrate.\n", rc_desc);
+return AVERROR(EINVAL);
}
}
else if (avctx->global_quality > 0 && !avctx->rc_max_rate) {
rc_mode = MFX_RATECONTROL_ICQ;
rc_desc = "intelligent constant quality (ICQ)";
}
-else if (avctx->rc_max_rate == avctx->bit_rate) {
-rc_mode = MFX_RATECONTROL_CBR;
-rc_desc = "constant bitrate (CBR)";
-}
+else if (avctx->bit_rate) {
+if (avctx->rc_max_rate == avctx->bit_rate) {
+rc_mode = MFX_RATECONTROL_CBR;
+rc_desc = "constant bitrate (CBR)";
+}
#if QSV_HAVE_AVBR
-else if (!avctx->rc_max_rate &&
- (avctx->codec_id == AV_CODEC_ID_H264 || avctx->codec_id ==
AV_CODEC_ID_HEVC) &&
- q->avbr_accuracy &&
- q->avbr_convergence) {
-rc_mode = MFX_RATECONTROL_AVBR;
-rc_desc = "average variable bitrate (AVBR)";
-}
+else if (!avctx->rc_max_rate &&
+ (avctx->codec_id == AV_CODEC_ID_H264 || avctx->codec_id ==
AV_CODEC_ID_HEVC) &&
+ q->avbr_accuracy &&
+ q->avbr_convergence) {
+rc_mode = MFX_RATECONTROL_AVBR;
+rc_desc = "average variable bitrate (AVBR)";
+}
#endif
-else if (avctx->global_quality > 0) {
-rc_mode = MFX_RATECONTROL_QVBR;
-rc_desc = "constant quality with VBR algorithm (QVBR)";
-}
-else {
-rc_mode = MFX_RATECONTROL_VBR;
-rc_desc = "variable bitrate (VBR)";
+else if (avctx->global_quality > 0) {
+rc_mode = MFX_RATECONTROL_QVBR;
+rc_desc = "constant quality with VBR algorithm (QVBR)";
+} else {
+rc_mode = MFX_RATECONTROL_VBR;
+rc_desc = "variable bitrate (VBR)";
+}
+} else {
+rc_mode = MFX_RATECONTROL_CQP;
+rc_desc = "constant quantization parameter (CQP)";
+if (avctx->codec_id == AV_CODEC_ID_AV1)
+avctx->global_quality = FF_QP2LAMBDA * 128;
+else
+avctx->global_quality = FF_QP2LAMBDA * 26;
+av_log(avctx, AV_LOG_WARNING, "Using the
[FFmpeg-devel] [PATCH v4 8/9] avcodec: add D3D12VA hardware HEVC encoder
From: Tong Wu This implementation is based on D3D12 Video Encoding Spec: https://microsoft.github.io/DirectX-Specs/d3d/D3D12VideoEncoding.html Sample command line for transcoding: ffmpeg.exe -hwaccel d3d12va -hwaccel_output_format d3d12 -i input.mp4 -c:v hevc_d3d12va output.mp4 Signed-off-by: Tong Wu --- configure|6 + libavcodec/Makefile |4 +- libavcodec/allcodecs.c |1 + libavcodec/d3d12va_encode.c | 1443 ++ libavcodec/d3d12va_encode.h | 275 ++ libavcodec/d3d12va_encode_hevc.c | 1013 + libavcodec/hw_base_encode.h |2 +- 7 files changed, 2742 insertions(+), 2 deletions(-) create mode 100644 libavcodec/d3d12va_encode.c create mode 100644 libavcodec/d3d12va_encode.h create mode 100644 libavcodec/d3d12va_encode_hevc.c diff --git a/configure b/configure index f72533b7d2..682576aa91 100755 --- a/configure +++ b/configure @@ -2564,6 +2564,7 @@ CONFIG_EXTRA=" tpeldsp vaapi_1 vaapi_encode +d3d12va_encode vc1dsp videodsp vp3dsp @@ -3208,6 +3209,7 @@ wmv3_vaapi_hwaccel_select="vc1_vaapi_hwaccel" wmv3_vdpau_hwaccel_select="vc1_vdpau_hwaccel" # hardware-accelerated codecs +d3d12va_encode_deps="d3d12va ID3D12VideoEncoder d3d12_encoder_feature" mediafoundation_deps="mftransform_h MFCreateAlignedMemoryBuffer" omx_deps="libdl pthreads" omx_rpi_select="omx" @@ -3275,6 +3277,7 @@ h264_v4l2m2m_encoder_deps="v4l2_m2m h264_v4l2_m2m" hevc_amf_encoder_deps="amf" hevc_cuvid_decoder_deps="cuvid" hevc_cuvid_decoder_select="hevc_mp4toannexb_bsf" +hevc_d3d12va_encoder_select="atsc_a53 cbs_h265 d3d12va_encode" hevc_mediacodec_decoder_deps="mediacodec" hevc_mediacodec_decoder_select="hevc_mp4toannexb_bsf hevc_parser" hevc_mediacodec_encoder_deps="mediacodec" @@ -6617,6 +6620,9 @@ check_type "windows.h d3d11.h" "ID3D11VideoDecoder" check_type "windows.h d3d11.h" "ID3D11VideoContext" check_type "windows.h d3d12.h" "ID3D12Device" check_type "windows.h d3d12video.h" "ID3D12VideoDecoder" +check_type "windows.h d3d12video.h" "ID3D12VideoEncoder" +test_code cc "windows.h d3d12video.h" "D3D12_FEATURE_VIDEO feature = D3D12_FEATURE_VIDEO_ENCODER_CODEC" && \ +test_code cc "windows.h d3d12video.h" "D3D12_FEATURE_DATA_VIDEO_ENCODER_RESOURCE_REQUIREMENTS req" && enable d3d12_encoder_feature check_type "windows.h" "DPI_AWARENESS_CONTEXT" -D_WIN32_WINNT=0x0A00 check_type "d3d9.h dxva2api.h" DXVA2_ConfigPictureDecode -D_WIN32_WINNT=0x0602 check_func_headers mfapi.h MFCreateAlignedMemoryBuffer -lmfplat diff --git a/libavcodec/Makefile b/libavcodec/Makefile index 23946f6ea3..50590b34f4 100644 --- a/libavcodec/Makefile +++ b/libavcodec/Makefile @@ -86,6 +86,7 @@ OBJS-$(CONFIG_CBS_MPEG2) += cbs_mpeg2.o OBJS-$(CONFIG_CBS_VP8) += cbs_vp8.o vp8data.o OBJS-$(CONFIG_CBS_VP9) += cbs_vp9.o OBJS-$(CONFIG_CRYSTALHD) += crystalhd.o +OBJS-$(CONFIG_D3D12VA_ENCODE) += d3d12va_encode.o hw_base_encode.o OBJS-$(CONFIG_DEFLATE_WRAPPER) += zlib_wrapper.o OBJS-$(CONFIG_DOVI_RPU)+= dovi_rpu.o OBJS-$(CONFIG_ERROR_RESILIENCE)+= error_resilience.o @@ -437,6 +438,7 @@ OBJS-$(CONFIG_HEVC_DECODER)+= hevcdec.o hevc_mvs.o \ h274.o OBJS-$(CONFIG_HEVC_AMF_ENCODER)+= amfenc_hevc.o OBJS-$(CONFIG_HEVC_CUVID_DECODER) += cuviddec.o +OBJS-$(CONFIG_HEVC_D3D12VA_ENCODER)+= d3d12va_encode_hevc.o OBJS-$(CONFIG_HEVC_MEDIACODEC_DECODER) += mediacodecdec.o OBJS-$(CONFIG_HEVC_MEDIACODEC_ENCODER) += mediacodecenc.o OBJS-$(CONFIG_HEVC_MF_ENCODER) += mfenc.o mf_utils.o @@ -1267,7 +1269,7 @@ SKIPHEADERS+= %_tablegen.h \ SKIPHEADERS-$(CONFIG_AMF) += amfenc.h SKIPHEADERS-$(CONFIG_D3D11VA) += d3d11va.h dxva2_internal.h -SKIPHEADERS-$(CONFIG_D3D12VA) += d3d12va_decode.h +SKIPHEADERS-$(CONFIG_D3D12VA) += d3d12va_decode.h d3d12va_encode.h SKIPHEADERS-$(CONFIG_DXVA2)+= dxva2.h dxva2_internal.h SKIPHEADERS-$(CONFIG_JNI) += ffjni.h SKIPHEADERS-$(CONFIG_LCMS2)+= fflcms2.h diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c index ef8c3a6d7d..9a34974141 100644 --- a/libavcodec/allcodecs.c +++ b/libavcodec/allcodecs.c @@ -865,6 +865,7 @@ extern const FFCodec ff_h264_vaapi_encoder; extern const FFCodec ff_h264_videotoolbox_encoder; extern const FFCodec ff_hevc_amf_encoder; extern const FFCodec ff_hevc_cuvid_decoder; +extern const FFCodec ff_hevc_d3d12va_encoder; extern const FFCodec ff_hevc_mediacodec_decoder; extern const FFCodec ff_hevc_mediacodec_encoder; extern const FFCodec ff_hevc_mf_encoder; diff --git a/libavcodec/d3d12va_encode.c b/libavcodec/d3d12va_encode.c new file mode 100644 index 00..7d9d6b6575 --- /dev/null +++ b/libavcodec/d3d12va_encode.c @@ -0,0 +1,1443 @@ +/*
[FFmpeg-devel] [PATCH v4 9/9] Changelog: add D3D12VA HEVC encoder changelog
From: Tong Wu Signed-off-by: Tong Wu --- Changelog | 1 + 1 file changed, 1 insertion(+) diff --git a/Changelog b/Changelog index c5fb21d198..6923c451c5 100644 --- a/Changelog +++ b/Changelog @@ -24,6 +24,7 @@ version : - ffmpeg CLI options may now be used as -/opt , which is equivalent to -opt > - showinfo bitstream filter +- D3D12VA HEVC encoder version 6.1: - libaribcaption decoder -- 2.41.0.windows.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v4 7/9] avutil/hwcontext_d3d12va: add Flags for resource creation
From: Tong Wu
Flags field is added to support diffferent resource creation.
Signed-off-by: Tong Wu
---
doc/APIchanges| 3 +++
libavutil/hwcontext_d3d12va.c | 2 +-
libavutil/hwcontext_d3d12va.h | 8
libavutil/version.h | 2 +-
4 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 1f5724324a..70fb185fc3 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on 2023-02-09
API changes, most recent first:
+2024-01-xx - xx - lavu 58.37.100 - hwcontext_d3d12va.h
+ Add AVD3D12VAFramesContext.flags
+
2024-02-04 - xx - lavc 60.39.100 - packet.h
Add AV_PKT_DATA_AMBIENT_VIEWING_ENVIRONMENT.
diff --git a/libavutil/hwcontext_d3d12va.c b/libavutil/hwcontext_d3d12va.c
index 3acd5ac43a..b9984a4151 100644
--- a/libavutil/hwcontext_d3d12va.c
+++ b/libavutil/hwcontext_d3d12va.c
@@ -237,7 +237,7 @@ static AVBufferRef *d3d12va_pool_alloc(void *opaque, size_t
size)
.Format = hwctx->format,
.SampleDesc = {.Count = 1, .Quality = 0 },
.Layout = D3D12_TEXTURE_LAYOUT_UNKNOWN,
-.Flags= D3D12_RESOURCE_FLAG_NONE,
+.Flags= hwctx->flags,
};
frame = av_mallocz(sizeof(AVD3D12VAFrame));
diff --git a/libavutil/hwcontext_d3d12va.h b/libavutil/hwcontext_d3d12va.h
index ff06e6f2ef..608dbac97f 100644
--- a/libavutil/hwcontext_d3d12va.h
+++ b/libavutil/hwcontext_d3d12va.h
@@ -129,6 +129,14 @@ typedef struct AVD3D12VAFramesContext {
* If unset, will be automatically set.
*/
DXGI_FORMAT format;
+
+/**
+ * This field is used to specify options for working with resources.
+ * If unset, this will be D3D12_RESOURCE_FLAG_NONE.
+ *
+ * @see:
https://learn.microsoft.com/en-us/windows/win32/api/d3d12/ne-d3d12-d3d12_resource_flags.
+ */
+D3D12_RESOURCE_FLAGS flags;
} AVD3D12VAFramesContext;
#endif /* AVUTIL_HWCONTEXT_D3D12VA_H */
diff --git a/libavutil/version.h b/libavutil/version.h
index 772c4e209c..3ad1a9446c 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
*/
#define LIBAVUTIL_VERSION_MAJOR 58
-#define LIBAVUTIL_VERSION_MINOR 36
+#define LIBAVUTIL_VERSION_MINOR 37
#define LIBAVUTIL_VERSION_MICRO 101
#define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
--
2.41.0.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v4 6/9] avcodec/vaapi_encode: extract a get_recon_format function to base layer
From: Tong Wu
Get constraints and set recon frame format can be shared with other HW
encoder such as D3D12. Extract this part as a new function to base
layer.
Signed-off-by: Tong Wu
---
libavcodec/hw_base_encode.c | 58 +
libavcodec/hw_base_encode.h | 2 ++
libavcodec/vaapi_encode.c | 51 ++--
3 files changed, 63 insertions(+), 48 deletions(-)
diff --git a/libavcodec/hw_base_encode.c b/libavcodec/hw_base_encode.c
index bb9fe70239..7497e0397e 100644
--- a/libavcodec/hw_base_encode.c
+++ b/libavcodec/hw_base_encode.c
@@ -836,6 +836,64 @@ int ff_hw_base_init_gop_structure(AVCodecContext *avctx,
uint32_t ref_l0, uint32
return 0;
}
+int ff_hw_base_get_recon_format(AVCodecContext *avctx, const void *hwconfig,
enum AVPixelFormat *fmt)
+{
+HWBaseEncodeContext *ctx = avctx->priv_data;
+AVHWFramesConstraints *constraints = NULL;
+enum AVPixelFormat recon_format;
+int err, i;
+
+constraints = av_hwdevice_get_hwframe_constraints(ctx->device_ref,
+ hwconfig);
+if (!constraints) {
+err = AVERROR(ENOMEM);
+goto fail;
+}
+
+// Probably we can use the input surface format as the surface format
+// of the reconstructed frames. If not, we just pick the first (only?)
+// format in the valid list and hope that it all works.
+recon_format = AV_PIX_FMT_NONE;
+if (constraints->valid_sw_formats) {
+for (i = 0; constraints->valid_sw_formats[i] != AV_PIX_FMT_NONE; i++) {
+if (ctx->input_frames->sw_format ==
+constraints->valid_sw_formats[i]) {
+recon_format = ctx->input_frames->sw_format;
+break;
+}
+}
+if (recon_format == AV_PIX_FMT_NONE) {
+// No match. Just use the first in the supported list and
+// hope for the best.
+recon_format = constraints->valid_sw_formats[0];
+}
+} else {
+// No idea what to use; copy input format.
+recon_format = ctx->input_frames->sw_format;
+}
+av_log(avctx, AV_LOG_DEBUG, "Using %s as format of "
+ "reconstructed frames.\n", av_get_pix_fmt_name(recon_format));
+
+if (ctx->surface_width < constraints->min_width ||
+ctx->surface_height < constraints->min_height ||
+ctx->surface_width > constraints->max_width ||
+ctx->surface_height > constraints->max_height) {
+av_log(avctx, AV_LOG_ERROR, "Hardware does not support encoding at "
+ "size %dx%d (constraints: width %d-%d height %d-%d).\n",
+ ctx->surface_width, ctx->surface_height,
+ constraints->min_width, constraints->max_width,
+ constraints->min_height, constraints->max_height);
+err = AVERROR(EINVAL);
+goto fail;
+}
+
+*fmt = recon_format;
+err = 0;
+fail:
+av_hwframe_constraints_free();
+return err;
+}
+
int ff_hw_base_encode_init(AVCodecContext *avctx)
{
HWBaseEncodeContext *ctx = avctx->priv_data;
diff --git a/libavcodec/hw_base_encode.h b/libavcodec/hw_base_encode.h
index d6d2fc03c5..3d026ee23e 100644
--- a/libavcodec/hw_base_encode.h
+++ b/libavcodec/hw_base_encode.h
@@ -279,6 +279,8 @@ int ff_hw_base_rc_mode_configure(AVCodecContext *avctx,
const HWBaseEncodeRCMode
int ff_hw_base_init_gop_structure(AVCodecContext *avctx, uint32_t ref_l0,
uint32_t ref_l1,
int flags, int prediction_pre_only);
+int ff_hw_base_get_recon_format(AVCodecContext *avctx, const void *hwconfig,
enum AVPixelFormat *fmt);
+
int ff_hw_base_encode_init(AVCodecContext *avctx);
int ff_hw_base_encode_close(AVCodecContext *avctx);
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 0bce3ce105..84a81559e1 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -1898,9 +1898,8 @@ static av_cold int
vaapi_encode_create_recon_frames(AVCodecContext *avctx)
HWBaseEncodeContext *base_ctx = avctx->priv_data;
VAAPIEncodeContext *ctx = avctx->priv_data;
AVVAAPIHWConfig *hwconfig = NULL;
-AVHWFramesConstraints *constraints = NULL;
enum AVPixelFormat recon_format;
-int err, i;
+int err;
hwconfig = av_hwdevice_hwconfig_alloc(base_ctx->device_ref);
if (!hwconfig) {
@@ -1909,52 +1908,9 @@ static av_cold int
vaapi_encode_create_recon_frames(AVCodecContext *avctx)
}
hwconfig->config_id = ctx->va_config;
-constraints = av_hwdevice_get_hwframe_constraints(base_ctx->device_ref,
- hwconfig);
-if (!constraints) {
-err = AVERROR(ENOMEM);
-goto fail;
-}
-
-// Probably we can use the input surface format as the surface format
-// of the reconstructed frames. If not, we just pick the first (only?)
-// format in the valid list and hope that it all works.
-
[FFmpeg-devel] [PATCH v4 5/9] avcodec/vaapi_encode: extract gop configuration to base layer
From: Tong Wu
Signed-off-by: Tong Wu
---
libavcodec/hw_base_encode.c | 54 +
libavcodec/hw_base_encode.h | 3 +++
libavcodec/vaapi_encode.c | 52 +++
3 files changed, 61 insertions(+), 48 deletions(-)
diff --git a/libavcodec/hw_base_encode.c b/libavcodec/hw_base_encode.c
index c20c47bf55..bb9fe70239 100644
--- a/libavcodec/hw_base_encode.c
+++ b/libavcodec/hw_base_encode.c
@@ -782,6 +782,60 @@ int ff_hw_base_rc_mode_configure(AVCodecContext *avctx,
const HWBaseEncodeRCMode
return 0;
}
+int ff_hw_base_init_gop_structure(AVCodecContext *avctx, uint32_t ref_l0,
uint32_t ref_l1,
+ int flags, int prediction_pre_only)
+{
+HWBaseEncodeContext *ctx = avctx->priv_data;
+
+if (flags & FLAG_INTRA_ONLY || avctx->gop_size <= 1) {
+av_log(avctx, AV_LOG_VERBOSE, "Using intra frames only.\n");
+ctx->gop_size = 1;
+} else if (ref_l0 < 1) {
+av_log(avctx, AV_LOG_ERROR, "Driver does not support any "
+ "reference frames.\n");
+return AVERROR(EINVAL);
+} else if (!(flags & FLAG_B_PICTURES) || ref_l1 < 1 ||
+ avctx->max_b_frames < 1 || prediction_pre_only) {
+if (ctx->p_to_gpb)
+ av_log(avctx, AV_LOG_VERBOSE, "Using intra and B-frames "
+ "(supported references: %d / %d).\n",
+ ref_l0, ref_l1);
+else
+av_log(avctx, AV_LOG_VERBOSE, "Using intra and P-frames "
+ "(supported references: %d / %d).\n", ref_l0, ref_l1);
+ctx->gop_size = avctx->gop_size;
+ctx->p_per_i = INT_MAX;
+ctx->b_per_p = 0;
+} else {
+ if (ctx->p_to_gpb)
+ av_log(avctx, AV_LOG_VERBOSE, "Using intra and B-frames "
+ "(supported references: %d / %d).\n",
+ ref_l0, ref_l1);
+ else
+ av_log(avctx, AV_LOG_VERBOSE, "Using intra, P- and B-frames "
+ "(supported references: %d / %d).\n", ref_l0, ref_l1);
+ctx->gop_size = avctx->gop_size;
+ctx->p_per_i = INT_MAX;
+ctx->b_per_p = avctx->max_b_frames;
+if (flags & FLAG_B_PICTURE_REFERENCES) {
+ctx->max_b_depth = FFMIN(ctx->desired_b_depth,
+ av_log2(ctx->b_per_p) + 1);
+} else {
+ctx->max_b_depth = 1;
+}
+}
+
+if (flags & FLAG_NON_IDR_KEY_PICTURES) {
+ctx->closed_gop = !!(avctx->flags & AV_CODEC_FLAG_CLOSED_GOP);
+ctx->gop_per_idr = ctx->idr_interval + 1;
+} else {
+ctx->closed_gop = 1;
+ctx->gop_per_idr = 1;
+}
+
+return 0;
+}
+
int ff_hw_base_encode_init(AVCodecContext *avctx)
{
HWBaseEncodeContext *ctx = avctx->priv_data;
diff --git a/libavcodec/hw_base_encode.h b/libavcodec/hw_base_encode.h
index 57cfa12e73..d6d2fc03c5 100644
--- a/libavcodec/hw_base_encode.h
+++ b/libavcodec/hw_base_encode.h
@@ -276,6 +276,9 @@ int ff_hw_base_encode_receive_packet(AVCodecContext *avctx,
AVPacket *pkt);
int ff_hw_base_rc_mode_configure(AVCodecContext *avctx, const
HWBaseEncodeRCMode *rc_mode,
int default_quality, HWBaseEncodeRCConfigure
*rc_conf);
+int ff_hw_base_init_gop_structure(AVCodecContext *avctx, uint32_t ref_l0,
uint32_t ref_l1,
+ int flags, int prediction_pre_only);
+
int ff_hw_base_encode_init(AVCodecContext *avctx);
int ff_hw_base_encode_close(AVCodecContext *avctx);
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 30e5deac08..0bce3ce105 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -1443,7 +1443,7 @@ static av_cold int
vaapi_encode_init_gop_structure(AVCodecContext *avctx)
VAStatus vas;
VAConfigAttrib attr = { VAConfigAttribEncMaxRefFrames };
uint32_t ref_l0, ref_l1;
-int prediction_pre_only;
+int prediction_pre_only, err;
vas = vaGetConfigAttributes(ctx->hwctx->display,
ctx->va_profile,
@@ -1507,53 +1507,9 @@ static av_cold int
vaapi_encode_init_gop_structure(AVCodecContext *avctx)
}
#endif
-if (ctx->codec->flags & FLAG_INTRA_ONLY ||
-avctx->gop_size <= 1) {
-av_log(avctx, AV_LOG_VERBOSE, "Using intra frames only.\n");
-base_ctx->gop_size = 1;
-} else if (ref_l0 < 1) {
-av_log(avctx, AV_LOG_ERROR, "Driver does not support any "
- "reference frames.\n");
-return AVERROR(EINVAL);
-} else if (!(ctx->codec->flags & FLAG_B_PICTURES) ||
- ref_l1 < 1 || avctx->max_b_frames < 1 ||
- prediction_pre_only) {
-if (base_ctx->p_to_gpb)
- av_log(avctx, AV_LOG_VERBOSE, "Using intra and B-frames "
- "(supported references: %d / %d).\n",
- ref_l0, ref_l1);
-else
-av_log(avctx, AV_LOG_VERBOSE, "Using intra and
[FFmpeg-devel] [PATCH v4 4/9] avcodec/vaapi_encode: extract rc parameter configuration to base layer
From: Tong Wu
VAAPI and D3D12VA can share rate control configuration codes. Hence, it
can be moved to base layer for simplification.
Signed-off-by: Tong Wu
---
libavcodec/hw_base_encode.c| 151
libavcodec/hw_base_encode.h| 34 ++
libavcodec/vaapi_encode.c | 210 ++---
libavcodec/vaapi_encode.h | 14 +--
libavcodec/vaapi_encode_av1.c | 2 +-
libavcodec/vaapi_encode_h264.c | 2 +-
libavcodec/vaapi_encode_vp9.c | 2 +-
7 files changed, 227 insertions(+), 188 deletions(-)
diff --git a/libavcodec/hw_base_encode.c b/libavcodec/hw_base_encode.c
index f0e4ef9655..c20c47bf55 100644
--- a/libavcodec/hw_base_encode.c
+++ b/libavcodec/hw_base_encode.c
@@ -631,6 +631,157 @@ end:
return 0;
}
+int ff_hw_base_rc_mode_configure(AVCodecContext *avctx, const
HWBaseEncodeRCMode *rc_mode,
+ int default_quality, HWBaseEncodeRCConfigure
*rc_conf)
+{
+HWBaseEncodeContext *ctx = avctx->priv_data;
+
+if (!rc_mode || !rc_conf)
+return -1;
+
+if (rc_mode->bitrate) {
+if (avctx->bit_rate <= 0) {
+av_log(avctx, AV_LOG_ERROR, "Bitrate must be set for %s "
+ "RC mode.\n", rc_mode->name);
+return AVERROR(EINVAL);
+}
+
+if (rc_mode->mode == RC_MODE_AVBR) {
+// For maximum confusion AVBR is hacked into the existing API
+// by overloading some of the fields with completely different
+// meanings.
+
+// Target percentage does not apply in AVBR mode.
+rc_conf->rc_bits_per_second = avctx->bit_rate;
+
+// Accuracy tolerance range for meeting the specified target
+// bitrate. It's very unclear how this is actually intended
+// to work - since we do want to get the specified bitrate,
+// set the accuracy to 100% for now.
+rc_conf->rc_target_percentage = 100;
+
+// Convergence period in frames. The GOP size reflects the
+// user's intended block size for cutting, so reusing that
+// as the convergence period seems a reasonable default.
+rc_conf->rc_window_size = avctx->gop_size > 0 ? avctx->gop_size :
60;
+
+} else if (rc_mode->maxrate) {
+if (avctx->rc_max_rate > 0) {
+if (avctx->rc_max_rate < avctx->bit_rate) {
+av_log(avctx, AV_LOG_ERROR, "Invalid bitrate settings: "
+ "bitrate (%"PRId64") must not be greater than "
+ "maxrate (%"PRId64").\n", avctx->bit_rate,
+ avctx->rc_max_rate);
+return AVERROR(EINVAL);
+}
+rc_conf->rc_bits_per_second = avctx->rc_max_rate;
+rc_conf->rc_target_percentage = (avctx->bit_rate * 100) /
+ avctx->rc_max_rate;
+} else {
+// We only have a target bitrate, but this mode requires
+// that a maximum rate be supplied as well. Since the
+// user does not want this to be a constraint, arbitrarily
+// pick a maximum rate of double the target rate.
+rc_conf->rc_bits_per_second = 2 * avctx->bit_rate;
+rc_conf->rc_target_percentage = 50;
+}
+} else {
+if (avctx->rc_max_rate > avctx->bit_rate) {
+av_log(avctx, AV_LOG_WARNING, "Max bitrate is ignored "
+ "in %s RC mode.\n", rc_mode->name);
+}
+rc_conf->rc_bits_per_second = avctx->bit_rate;
+rc_conf->rc_target_percentage = 100;
+}
+} else {
+rc_conf->rc_bits_per_second = 0;
+rc_conf->rc_target_percentage = 100;
+}
+
+if (rc_mode->quality) {
+if (ctx->explicit_qp) {
+rc_conf->rc_quality = ctx->explicit_qp;
+} else if (avctx->global_quality > 0) {
+rc_conf->rc_quality = avctx->global_quality;
+} else {
+rc_conf->rc_quality = default_quality;
+av_log(avctx, AV_LOG_WARNING, "No quality level set; "
+ "using default (%d).\n", rc_conf->rc_quality);
+}
+} else {
+rc_conf->rc_quality = 0;
+}
+
+if (rc_mode->hrd) {
+if (avctx->rc_buffer_size)
+rc_conf->hrd_buffer_size = avctx->rc_buffer_size;
+else if (avctx->rc_max_rate > 0)
+rc_conf->hrd_buffer_size = avctx->rc_max_rate;
+else
+rc_conf->hrd_buffer_size = avctx->bit_rate;
+if (avctx->rc_initial_buffer_occupancy) {
+if (avctx->rc_initial_buffer_occupancy > rc_conf->hrd_buffer_size)
{
+av_log(avctx, AV_LOG_ERROR, "Invalid RC buffer settings: "
+ "must have initial buffer size (%d) <= "
+ "buffer size
[FFmpeg-devel] [PATCH v4 3/9] avcodec/vaapi_encode: extract set_output_property to base layer
From: Tong Wu
Signed-off-by: Tong Wu
---
libavcodec/hw_base_encode.c | 40 +
libavcodec/hw_base_encode.h | 3 +++
libavcodec/vaapi_encode.c | 44 ++---
3 files changed, 45 insertions(+), 42 deletions(-)
diff --git a/libavcodec/hw_base_encode.c b/libavcodec/hw_base_encode.c
index 62adda2fc3..f0e4ef9655 100644
--- a/libavcodec/hw_base_encode.c
+++ b/libavcodec/hw_base_encode.c
@@ -385,6 +385,46 @@ static int hw_base_encode_clear_old(AVCodecContext *avctx)
return 0;
}
+int ff_hw_base_encode_set_output_property(AVCodecContext *avctx,
+ HWBaseEncodePicture *pic,
+ AVPacket *pkt, int flag_no_delay)
+{
+HWBaseEncodeContext *ctx = avctx->priv_data;
+
+if (pic->type == PICTURE_TYPE_IDR)
+pkt->flags |= AV_PKT_FLAG_KEY;
+
+pkt->pts = pic->pts;
+pkt->duration = pic->duration;
+
+// for no-delay encoders this is handled in generic codec
+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;
+}
+
+if (flag_no_delay) {
+pkt->dts = pkt->pts;
+return 0;
+}
+
+if (ctx->output_delay == 0) {
+pkt->dts = pkt->pts;
+} else if (pic->encode_order < ctx->decode_delay) {
+if (ctx->ts_ring[pic->encode_order] < INT64_MIN + ctx->dts_pts_diff)
+pkt->dts = INT64_MIN;
+else
+pkt->dts = ctx->ts_ring[pic->encode_order] - ctx->dts_pts_diff;
+} else {
+pkt->dts = ctx->ts_ring[(pic->encode_order - ctx->decode_delay) %
+(3 * ctx->output_delay + ctx->async_depth)];
+}
+
+return 0;
+}
+
static int hw_base_encode_check_frame(AVCodecContext *avctx,
const AVFrame *frame)
{
diff --git a/libavcodec/hw_base_encode.h b/libavcodec/hw_base_encode.h
index be4c6b034e..d215d6a32b 100644
--- a/libavcodec/hw_base_encode.h
+++ b/libavcodec/hw_base_encode.h
@@ -237,6 +237,9 @@ typedef struct HWBaseEncodeContext {
AVPacket*tail_pkt;
} HWBaseEncodeContext;
+int ff_hw_base_encode_set_output_property(AVCodecContext *avctx,
HWBaseEncodePicture *pic,
+ AVPacket *pkt, int flag_no_delay);
+
int ff_hw_base_encode_receive_packet(AVCodecContext *avctx, AVPacket *pkt);
int ff_hw_base_encode_init(AVCodecContext *avctx);
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index e2f968c36d..2d839a1202 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -668,47 +668,6 @@ fail_at_end:
return err;
}
-static int vaapi_encode_set_output_property(AVCodecContext *avctx,
-HWBaseEncodePicture *pic,
-AVPacket *pkt)
-{
-HWBaseEncodeContext *base_ctx = avctx->priv_data;
-VAAPIEncodeContext *ctx = avctx->priv_data;
-
-if (pic->type == PICTURE_TYPE_IDR)
-pkt->flags |= AV_PKT_FLAG_KEY;
-
-pkt->pts = pic->pts;
-pkt->duration = pic->duration;
-
-// for no-delay encoders this is handled in generic codec
-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;
-}
-
-if (ctx->codec->flags & FLAG_TIMESTAMP_NO_DELAY) {
-pkt->dts = pkt->pts;
-return 0;
-}
-
-if (base_ctx->output_delay == 0) {
-pkt->dts = pkt->pts;
-} else if (pic->encode_order < base_ctx->decode_delay) {
-if (base_ctx->ts_ring[pic->encode_order] < INT64_MIN +
base_ctx->dts_pts_diff)
-pkt->dts = INT64_MIN;
-else
-pkt->dts = base_ctx->ts_ring[pic->encode_order] -
base_ctx->dts_pts_diff;
-} else {
-pkt->dts = base_ctx->ts_ring[(pic->encode_order -
base_ctx->decode_delay) %
- (3 * base_ctx->output_delay +
base_ctx->async_depth)];
-}
-
-return 0;
-}
-
static int vaapi_encode_get_coded_buffer_size(AVCodecContext *avctx,
VABufferID buf_id)
{
VAAPIEncodeContext *ctx = avctx->priv_data;
@@ -860,7 +819,8 @@ static int vaapi_encode_output(AVCodecContext *avctx,
av_log(avctx, AV_LOG_DEBUG, "Output read for pic %"PRId64"/%"PRId64".\n",
base_pic->display_order, base_pic->encode_order);
-vaapi_encode_set_output_property(avctx, base_pic, pkt_ptr);
+ff_hw_base_encode_set_output_property(avctx, base_pic, pkt_ptr,
+ ctx->codec->flags &
FLAG_TIMESTAMP_NO_DELAY);
end:
ff_refstruct_unref(>output_buffer_ref);
--
2.41.0.windows.1
___
ffmpeg-devel
[FFmpeg-devel] [PATCH v4 1/9] avcodec/vaapi_encode: move pic->input_surface initialization to encode_alloc
From: Tong Wu
When allocating the VAAPIEncodePicture, pic->input_surface can be
initialized right in the place. This movement simplifies the send_frame
logic and is the preparation for moving vaapi_encode_send_frame to the base
layer.
Signed-off-by: Tong Wu
---
libavcodec/vaapi_encode.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 86f4110cd2..38d855fbd4 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -878,7 +878,8 @@ static int vaapi_encode_discard(AVCodecContext *avctx,
return 0;
}
-static VAAPIEncodePicture *vaapi_encode_alloc(AVCodecContext *avctx)
+static VAAPIEncodePicture *vaapi_encode_alloc(AVCodecContext *avctx,
+ const AVFrame *frame)
{
VAAPIEncodeContext *ctx = avctx->priv_data;
VAAPIEncodePicture *pic;
@@ -895,7 +896,7 @@ static VAAPIEncodePicture
*vaapi_encode_alloc(AVCodecContext *avctx)
}
}
-pic->input_surface = VA_INVALID_ID;
+pic->input_surface = (VASurfaceID)(uintptr_t)frame->data[3];
pic->recon_surface = VA_INVALID_ID;
pic->output_buffer = VA_INVALID_ID;
@@ -1332,7 +1333,7 @@ static int vaapi_encode_send_frame(AVCodecContext *avctx,
AVFrame *frame)
if (err < 0)
return err;
-pic = vaapi_encode_alloc(avctx);
+pic = vaapi_encode_alloc(avctx, frame);
if (!pic)
return AVERROR(ENOMEM);
@@ -1345,7 +1346,6 @@ static int vaapi_encode_send_frame(AVCodecContext *avctx,
AVFrame *frame)
if (ctx->input_order == 0 || frame->pict_type == AV_PICTURE_TYPE_I)
pic->force_idr = 1;
-pic->input_surface = (VASurfaceID)(uintptr_t)frame->data[3];
pic->pts = frame->pts;
pic->duration = frame->duration;
--
2.41.0.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
Le 7 février 2024 23:19:41 GMT+02:00, James Almer a écrit : >On 2/7/2024 6:10 PM, Cosmin Stejerean via ffmpeg-devel wrote: >> >> >>> On Feb 7, 2024, at 11:27 AM, Lynne wrote: >>> > > As a compromise, we could start requiring C11 now, and C17 in 7.1. > Or does anyone still care about compilers without even c11 support? > How about C11 now and C17 in a year with ffmpeg 8? >>> >>> Do you have setups and reasons why you can't update them >>> that don't support C17 or are you speculating? >> >> I don't have any personal reasons why I can't support C17 immediately, but >> C11 now / C17 in a year seems like an approach more likely to find consensus >> than C17 immediately (or bumping to C17 in a minor release). It was also >> roughly the approach proposed in person at FOSDEM. > >What are the fixes in c17 that we would benefit from, that compilers from >before 2017 would be affected by? Besides editorial corrections with no practical impact, C17 allows initialising atomics directly, without ATOMIC_VAR_INIT. This shouldn't be a problem for any real C11 compiler, but I haven't checked. Then it also allows atomic load from const-qualified pointers. I don't know if this is relevant to FFmpeg. There may be other small differences that I don't remember or know of. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] libavcodec: add tune_content option also for VP8.
Hi, On Wed, Feb 7, 2024 at 8:04 AM Dariusz Marcinkiewicz via ffmpeg-devel wrote: > > This exposes VP8E_SET_SCREEN_CONTENT_MODE option from libvpx. > For the subject use '(libavcodec|avcodec|lavc)/libvpxenc: ...' to better document what is being changed. See the history of the file for examples. > Changes since v1: > - Put the new param initialzation in the right place, > - Account for cases when the encoder's output is queued up. > This is better left as a comment in the thread. It will lose its meaning when committed. > Co-authored-by: Erik Språng > Signed-off-by: Dariusz Marcinkiewicz > --- > doc/encoders.texi | 7 -- > libavcodec/libvpxenc.c | 56 ++ Please bump LIBAVCODEC_VERSION_MICRO in libavcodec/version.h. > 2 files changed, 56 insertions(+), 7 deletions(-) > > diff --git a/doc/encoders.texi b/doc/encoders.texi > index c9fe6d6143..2a9b38f62a 100644 > --- a/doc/encoders.texi > +++ b/doc/encoders.texi > @@ -2186,6 +2186,11 @@ Enable error resiliency features. > Increase sharpness at the expense of lower PSNR. > The valid range is [0, 7]. > > +@item tune-content Please match the vpxenc command line. They're separate, vp8 has --screen-content-mode. ___ 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] Call for SOWs [due Feb 10 at 23:59 UTC]
Hi all, Below is a proposal for creating a proposal to the STF -- I offered to Michael to help, and here we are. The objective, as I understand it, is to unlock funds for individuals that are interested in contributing to the FFMPEG codebase, subject to the STF criteria [1]. The suggested approach is that interested individuals email me, no later than Feb 10 at 23:59 UTC, a completed SOW using the template at [2]. It is important IMHO that there is a developer and a defined amount attached to each SOW, otherwise it creates uncertainty and thus increases the management burden and reduces the chances that the proposal is accepted. It is also important that the aggregate value of the SOWs is greater than €150,000 (minimum STF funding). This call for SOWs is completely voluntary, there is no guarantee that all SOWs are accepted by SPI, and the chances of success are unknown (to me). The SOWs (minus personal information and amounts) will be published. I am happy to collate the SOWs and forward them to SPI, who would handle the submission to STF and payments to contributors as the case may be. I am also happy to be educated and proven wrong. I am also happy to do nothing. Best, -- Pierre [1] https://www.sovereigntechfund.de/programs/applications#evaluation-criteria [2] https://docs.google.com/document/d/1unVsF5nwvKQ8rKbrEHN9NZIEvL73CV5zpB9OK0DrSG8 ___ 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] vvcdec: Mark as experimental
On Thu, Feb 8, 2024 at 6:55 AM Kieran Kunhya wrote: > On Wed, 7 Feb 2024 at 22:06, Paul B Mahol wrote: > > > On Wed, Feb 7, 2024 at 10:13 PM Kieran Kunhya wrote: > > > > > $subj > > > > > > As discussed at FOSDEM. > > > > > > > Author of this patch above is forced to FUZZ this decoder until > > experimental flag is removed. > > > > Sure, I will set some fuzzers up over the weekend. > Better add something here https://ffmpeg.org/developer.html#New-codecs-or-formats-checklist to explain to people what kind of new codecs should be treated as experimental and how they can graduate from experimental status. > > Kieran > ___ > 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 2/2] Require compilers to support C17.
Hello, On Thu, 8 Feb 2024, at 01:36, Cosmin Stejerean via ffmpeg-devel wrote: >> There were simply no objections to moving to C11. >> The C17 plan came about later because it has important bugfixes. >> It doesn't really matter as compilers backported the new behaviour to C11 >> (or rather, they consistently had the same behaviour, but now it became a >> standard). >> > > There were no objections to C11, however C17 was brought up and there > were objections that it's likely too soon and I believe JB proposed > holding off for a year on C17 (while adopting C11 immediately), which My recommendation is still this: - move to C11 now - activate C17 on some Fate/CI targets - recommend C17 compilers modes - move to C17 at this mid-year when 7.1 is branched (LTS if we follow our plans) -- 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 v2 11/12] lavc/vaapi_decode: use dynamic frame pool for output frames with libva2
On Wo, 2024-01-31 at 02:26 +, Xiang, Haihao wrote:
> On Di, 2024-01-30 at 19:07 +, Mark Thompson wrote:
> > On 30/01/2024 06:30, Xiang, Haihao wrote:
> > > On Ma, 2024-01-29 at 21:58 +, Mark Thompson wrote:
> > > > On 26/01/2024 07:25, Xiang, Haihao wrote:
> > > > > On Wo, 2023-12-20 at 15:10 +0800, Xiang, Haihao wrote:
> > > > > > From: Haihao Xiang
> > > > > >
> > > > > > This allows a downstream element stores more frames from VAAPI
> > > > > > decoders and fixes error in get_buffer()
> > > > > >
> > > > > > $ ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi -i
> > > > > > input_100frames.mp4 \
> > > > > > -vf reverse -an -f null -
> > > > > > ...
> > > > > > [h264 @ 0x557a075a1400] get_buffer() failed
> > > > > > [h264 @ 0x557a075a1400] thread_get_buffer() failed
> > > > > > [h264 @ 0x557a075a1400] decode_slice_header error
> > > > > > [h264 @ 0x557a075a1400] no frame!
> > > > > >
> > > > > > Signed-off-by: Haihao Xiang
> > > > > > ---
> > > > > > libavcodec/vaapi_decode.c | 36 --
> > > > > > --
> > > > > > 1 file changed, 20 insertions(+), 16 deletions(-)
> > > > > >
> > > > > > diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
> > > > > > index ceac769c52..8cc29e96f9 100644
> > > > > > --- a/libavcodec/vaapi_decode.c
> > > > > > +++ b/libavcodec/vaapi_decode.c
> > > > > > @@ -601,22 +601,26 @@ static int
> > > > > > vaapi_decode_make_config(AVCodecContext
> > > > > > *avctx,
> > > > > > if (err < 0)
> > > > > > goto fail;
> > > > > >
> > > > > > - frames->initial_pool_size = 1;
> > > > > > - // Add per-codec number of surfaces used for storing
> > > > > > reference
> > > > > > frames.
> > > > > > - switch (avctx->codec_id) {
> > > > > > - case AV_CODEC_ID_H264:
> > > > > > - case AV_CODEC_ID_HEVC:
> > > > > > - case AV_CODEC_ID_AV1:
> > > > > > - frames->initial_pool_size += 16;
> > > > > > - break;
> > > > > > - case AV_CODEC_ID_VP9:
> > > > > > - frames->initial_pool_size += 8;
> > > > > > - break;
> > > > > > - case AV_CODEC_ID_VP8:
> > > > > > - frames->initial_pool_size += 3;
> > > > > > - break;
> > > > > > - default:
> > > > > > - frames->initial_pool_size += 2;
> > > > > > + if (CONFIG_VAAPI_1)
> > > > > > + frames->initial_pool_size = 0;
> > > > > > + else {
> > > > > > + frames->initial_pool_size = 1;
> > > > > > + // Add per-codec number of surfaces used for storing
> > > > > > reference
> > > > > > frames.
> > > > > > + switch (avctx->codec_id) {
> > > > > > + case AV_CODEC_ID_H264:
> > > > > > + case AV_CODEC_ID_HEVC:
> > > > > > + case AV_CODEC_ID_AV1:
> > > > > > + frames->initial_pool_size += 16;
> > > > > > + break;
> > > > > > + case AV_CODEC_ID_VP9:
> > > > > > + frames->initial_pool_size += 8;
> > > > > > + break;
> > > > > > + case AV_CODEC_ID_VP8:
> > > > > > + frames->initial_pool_size += 3;
> > > > > > + break;
> > > > > > + default:
> > > > > > + frames->initial_pool_size += 2;
> > > > > > + }
> > > > > > }
> > > > > > }
> > > > > >
> > > > >
> > > > > Hi Mark,
> > > > >
> > > > > Do you have any comment about dynamic frame pool used in vaapi ?
> > > >
> > > > Are we completely sure that there are no driver/hardware combinations
> > > > which
> > > > rely on this still used?
> > >
> > > I tested this patch with i965, iHD and radeonsi drivers on Linux and
> > > vaon12
> > > driver on Windows. But honestly I am not sure whether there is a driver
> > > which
> > > works with fixed frame pool only.
> >
> > How does the vaon12 driver work with this given that some D3D12 devices
> > require a fixed array texture?
>
> Honestly I don't know. I don't have such HWs for testing.
>
> >
> > Note that the interesting test here is not the most recent version of any of
> > these things. Rather, it is the older versions which exist in a
> > distribution
> > configuration which we still want to support, for example Ubuntu 20.04.
>
> This patch is based on libva2, FFmpeg still works with libva. For older
> versions
> , user may use libva.
>
> >
> > I'm also unclear to what degree this might depend on the hardware being
> > used.
> > Certainly in D3D12 whether the fixed array texture is required depends on
> > the
> > actual hardware support.
>
> How about add a quirk for workable driver(s) only ? We won't be concerned by
> other drivers.
>
> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> index e6f45f8fde..aecdd55728 100644
> --- a/libavutil/hwcontext_vaapi.c
> +++ b/libavutil/hwcontext_vaapi.c
> @@ -374,7 +374,7 @@ static const struct {
> {
>
Re: [FFmpeg-devel] STF SoWs
On Wed, Feb 07, 2024 at 08:08:34AM -0500, Ronald S. Bultje wrote:
> Hi Michael,
>
> On Wed, Feb 7, 2024 at 7:58 AM Michael Niedermayer
> wrote:
>
> > Theres the person writing a SoW for work he wants to do.
> > Theres the person who accepts the SoW in FFmpeg
> > Theres the person who passes accepted SoW on to SPI/STF
> >
> > Iam sadly involved in more than one role here.
> >
>
> I think this is what Vittorio was referring to when he said this might be
> problematic. This is essentially what conflict-of-interest means. It
> doesn't mean that you're a bad person or doing something wrong, it simply
> means that there's overlapping goals. For example, in this case, there
> might be your personal goals ("get paid for work") vs the project goals
> ("get money for maintenance"). They're (partially) overlapping but not
> equal, because they're different angles of the same situation.
>
> Sometimes there is no ideal solution that satisfies everyone. As I said
> before, that's normal and that's OK.
Yes
To reduce this conflict of interrest problem. I asked Pierre if he can
take over the leading role in the current FFmpeg - STF/SPI thing
He was the only person who contacted me and helped with writing the SoW
example/template. He clearly has a more solid understanding of the SoW
process than i do, so i think that helps beyond just a reduction
of conflict of interrest.
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle
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] FFmpeg 7.0 blocking issues
On 2/7/2024 10:27 PM, Leo Izen wrote: On 2/7/24 13:56, Andreas Rheinhardt wrote: Leo Izen: On 1/23/24 14:22, Michael Niedermayer wrote: Hi all As it was a little difficult for me to not loose track of what is blocking a release. I suggest that for all release blocking issues open a ticket and set Blocking to 7.0 that way this: https://trac.ffmpeg.org/query?blocking=~7.0 or for the ones not closed: https://trac.ffmpeg.org/query?status=new=open=reopened=~7.0 will list all blocking issues Ive added one, for testing that, i intend to add more if i see something What is blocking? (IMHO) * regressions (unless its non possible to fix before release) * crashes * security issues * data loss * privacy issues * anything the commuity agrees should be in the release thx My EXIF overhaul is going to be an ABI break so I'd like to get it in, if and only if we are doing an ABI break with the release. What EXIF overhaul? Since when is EXIF part of the ABI? - Andreas I'm working on a patch to centralize a lot of the exif logic and make it easier for decoders to attach it to an AVFrame as side data, rather than dumping all the key/value pairs into AVFrame.metadata and then hoping that an encoder can serialize them out properly. As for ABI, there's an avpriv in libavcodec/exif.c that is called by the AVI demuxer in avformat. My plan is to expose some of these exif parse routines as a proper av_ API, and replace that avpriv_ call with a call to the new API. I mentioned this to James on IRC and he said it would have to go in during an ABI flexibility period. Removing avpriv_ symbols has to be during a major bump, but they can always just remain in place until the next. If your work can't be finished on time (or reviews end up taking too long), then removing said symbols can wait, so we don't delay 7.0 just for it. - Leo Izen ___ 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] FFmpeg 7.0 blocking issues
On 2/7/24 13:56, Andreas Rheinhardt wrote: Leo Izen: On 1/23/24 14:22, Michael Niedermayer wrote: Hi all As it was a little difficult for me to not loose track of what is blocking a release. I suggest that for all release blocking issues open a ticket and set Blocking to 7.0 that way this: https://trac.ffmpeg.org/query?blocking=~7.0 or for the ones not closed: https://trac.ffmpeg.org/query?status=new=open=reopened=~7.0 will list all blocking issues Ive added one, for testing that, i intend to add more if i see something What is blocking? (IMHO) * regressions (unless its non possible to fix before release) * crashes * security issues * data loss * privacy issues * anything the commuity agrees should be in the release thx My EXIF overhaul is going to be an ABI break so I'd like to get it in, if and only if we are doing an ABI break with the release. What EXIF overhaul? Since when is EXIF part of the ABI? - Andreas I'm working on a patch to centralize a lot of the exif logic and make it easier for decoders to attach it to an AVFrame as side data, rather than dumping all the key/value pairs into AVFrame.metadata and then hoping that an encoder can serialize them out properly. As for ABI, there's an avpriv in libavcodec/exif.c that is called by the AVI demuxer in avformat. My plan is to expose some of these exif parse routines as a proper av_ API, and replace that avpriv_ call with a call to the new API. I mentioned this to James on IRC and he said it would have to go in during an ABI flexibility period. - Leo Izen OpenPGP_signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/6] avcodec: Remove redundant pix_fmts from decoders
Andreas Rheinhardt:
> AVCodec.pix_fmts is only intended for encoders (decoders use
> the get_format callback to let the user choose a pix fmt).
> So remove them for the decoders for which this is possible
> without further complications; keep them for now in the codecs
> that actually use them (by passing avctx->codec->pix_fmts to
> ff_get_formatt()).
>
> Also notice that some of these lists were wrong; e.g.
> 317b7b06fd97cd39feac7df57db22a30550351ff added support for YUV444P16
> for cuviddec, but forgot to add it to pix_fmts.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/crystalhd.c | 1 -
> libavcodec/cuviddec.c | 5 -
> libavcodec/flashsv.c | 2 --
> libavcodec/libdavs2.c | 2 --
> libavcodec/libuavs3d.c | 3 ---
> libavcodec/qsvdec.c| 11 ---
> libavcodec/rkmppdec.c | 2 --
> libavcodec/rv10.c | 8
> libavcodec/rv30.c | 4
> libavcodec/rv40.c | 4
> libavcodec/svq1dec.c | 2 --
> libavcodec/svq3.c | 2 --
> libavcodec/xfacedec.c | 1 -
> 13 files changed, 47 deletions(-)
>
> diff --git a/libavcodec/crystalhd.c b/libavcodec/crystalhd.c
> index 86f6cfa6c1..fb190436f5 100644
> --- a/libavcodec/crystalhd.c
> +++ b/libavcodec/crystalhd.c
> @@ -797,7 +797,6 @@ static int crystalhd_receive_frame(AVCodecContext *avctx,
> AVFrame *frame)
> .p.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AVOID_PROBING |
> AV_CODEC_CAP_HARDWARE, \
> .caps_internal = FF_CODEC_CAP_NOT_INIT_THREADSAFE | \
>FF_CODEC_CAP_SETS_FRAME_PROPS, \
> -.p.pix_fmts = (const enum AVPixelFormat[]){AV_PIX_FMT_YUYV422,
> AV_PIX_FMT_NONE}, \
> .p.wrapper_name = "crystalhd", \
> };
>
> diff --git a/libavcodec/cuviddec.c b/libavcodec/cuviddec.c
> index da37207cf2..84edf5c209 100644
> --- a/libavcodec/cuviddec.c
> +++ b/libavcodec/cuviddec.c
> @@ -1174,11 +1174,6 @@ static const AVCodecHWConfigInternal *const
> cuvid_hw_configs[] = {
> .p.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AVOID_PROBING |
> AV_CODEC_CAP_HARDWARE, \
> .caps_internal = FF_CODEC_CAP_NOT_INIT_THREADSAFE | \
>FF_CODEC_CAP_SETS_FRAME_PROPS, \
> -.p.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_CUDA, \
> -AV_PIX_FMT_NV12, \
> -AV_PIX_FMT_P010, \
> -AV_PIX_FMT_P016, \
> -AV_PIX_FMT_NONE }, \
> .hw_configs = cuvid_hw_configs, \
> .p.wrapper_name = "cuvid", \
> };
> diff --git a/libavcodec/flashsv.c b/libavcodec/flashsv.c
> index 8a01e3a4b6..fe00e529a5 100644
> --- a/libavcodec/flashsv.c
> +++ b/libavcodec/flashsv.c
> @@ -511,7 +511,6 @@ const FFCodec ff_flashsv_decoder = {
> FF_CODEC_DECODE_CB(flashsv_decode_frame),
> .p.capabilities = AV_CODEC_CAP_DR1,
> .caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
> -.p.pix_fmts = (const enum AVPixelFormat[]) { AV_PIX_FMT_BGR24,
> AV_PIX_FMT_NONE },
> };
> #endif /* CONFIG_FLASHSV_DECODER */
>
> @@ -579,6 +578,5 @@ const FFCodec ff_flashsv2_decoder = {
> FF_CODEC_DECODE_CB(flashsv_decode_frame),
> .p.capabilities = AV_CODEC_CAP_DR1,
> .caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
> -.p.pix_fmts = (const enum AVPixelFormat[]) { AV_PIX_FMT_BGR24,
> AV_PIX_FMT_NONE },
> };
> #endif /* CONFIG_FLASHSV2_DECODER */
> diff --git a/libavcodec/libdavs2.c b/libavcodec/libdavs2.c
> index 179d2f4e4b..5a605c36f6 100644
> --- a/libavcodec/libdavs2.c
> +++ b/libavcodec/libdavs2.c
> @@ -234,7 +234,5 @@ const FFCodec ff_libdavs2_decoder = {
> .p.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_OTHER_THREADS,
> .caps_internal = FF_CODEC_CAP_NOT_INIT_THREADSAFE |
>FF_CODEC_CAP_AUTO_THREADS,
> -.p.pix_fmts = (const enum AVPixelFormat[]) { AV_PIX_FMT_YUV420P,
> - AV_PIX_FMT_NONE },
> .p.wrapper_name = "libdavs2",
> };
> diff --git a/libavcodec/libuavs3d.c b/libavcodec/libuavs3d.c
> index 66e8d31001..f5d47f28ed 100644
> --- a/libavcodec/libuavs3d.c
> +++ b/libavcodec/libuavs3d.c
> @@ -274,8 +274,5 @@ const FFCodec ff_libuavs3d_decoder = {
> .caps_internal = FF_CODEC_CAP_NOT_INIT_THREADSAFE |
>FF_CODEC_CAP_AUTO_THREADS,
> .flush = libuavs3d_flush,
> -.p.pix_fmts = (const enum AVPixelFormat[]) { AV_PIX_FMT_YUV420P,
> - AV_PIX_FMT_YUV420P10LE,
> - AV_PIX_FMT_NONE },
> .p.wrapper_name = "libuavs3d",
> };
> diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
> index 559f63698a..812bfd8830 100644
> --- a/libavcodec/qsvdec.c
> +++ b/libavcodec/qsvdec.c
> @@ -1127,17 +1127,6 @@
Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
> On Feb 7, 2024, at 1:48 PM, Lynne wrote: > > Feb 7, 2024, 22:11 by ffmpeg-devel@ffmpeg.org: > >> >> >>> On Feb 7, 2024, at 11:27 AM, Lynne wrote: >>> > > As a compromise, we could start requiring C11 now, and C17 in 7.1. > Or does anyone still care about compilers without even c11 support? > How about C11 now and C17 in a year with ffmpeg 8? >>> >>> Do you have setups and reasons why you can't update them >>> that don't support C17 or are you speculating? >>> >> >> I don't have any personal reasons why I can't support C17 immediately, but >> C11 now / C17 in a year seems like an approach more likely to find consensus >> than C17 immediately (or bumping to C17 in a minor release). It was also >> roughly the approach proposed in person at FOSDEM. >> > > It wasn't? > There were simply no objections to moving to C11. > The C17 plan came about later because it has important bugfixes. > It doesn't really matter as compilers backported the new behaviour to C11 > (or rather, they consistently had the same behaviour, but now it became a > standard). > There were no objections to C11, however C17 was brought up and there were objections that it's likely too soon and I believe JB proposed holding off for a year on C17 (while adopting C11 immediately), which seemed to have consensus. Or at least that's my recollection of the in person discussion. - Cosmin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/2] lavu/hashtable: create generic robin hood hash table
On Tue, Feb 06, 2024 at 02:57:53AM -0800, Connor Worley wrote:
[...]
> new file mode 100644
> index 00..0b38b34c5c
> --- /dev/null
> +++ b/libavutil/tests/hashtable.c
> @@ -0,0 +1,108 @@
> +/*
> + * Generic hashtable tests
> + * Copyright (C) 2024 Connor Worley
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> + */
> +
> +#include "libavutil/avassert.h"
> +#include "libavutil/hashtable.h"
missing stdint.h or inttypes.h
> +
> +int main(void)
> +{
> +struct AVHashtableContext *ctx;
> +uint8_t k;
> +uint64_t v;
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Elect your leaders based on what they did after the last election, not
based on what they say before an election.
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] vvcdec: Mark as experimental
On Wed, 7 Feb 2024 at 22:06, Paul B Mahol wrote: > On Wed, Feb 7, 2024 at 10:13 PM Kieran Kunhya wrote: > > > $subj > > > > As discussed at FOSDEM. > > > > Author of this patch above is forced to FUZZ this decoder until > experimental flag is removed. > Sure, I will set some fuzzers up over the weekend. Kieran ___ 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/nvdec: Constify bitstream pointee
On 07.02.2024 16:04, Andreas Rheinhardt wrote:
Signed-off-by: Andreas Rheinhardt
---
libavcodec/nvdec.c | 2 +-
libavcodec/nvdec.h | 2 +-
libavcodec/nvdec_av1.c | 4 ++--
libavcodec/nvdec_h264.c | 4 ++--
libavcodec/nvdec_hevc.c | 4 ++--
5 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
index d13b790632..553c9bdf18 100644
--- a/libavcodec/nvdec.c
+++ b/libavcodec/nvdec.c
@@ -680,7 +680,7 @@ int ff_nvdec_simple_decode_slice(AVCodecContext *avctx,
const uint8_t *buffer,
ctx->slice_offsets = tmp;
if (!ctx->bitstream)
-ctx->bitstream = (uint8_t*)buffer;
+ctx->bitstream = buffer;
ctx->slice_offsets[ctx->nb_slices] = buffer - ctx->bitstream;
ctx->bitstream_len += size;
diff --git a/libavcodec/nvdec.h b/libavcodec/nvdec.h
index 353e95bf42..555300d27d 100644
--- a/libavcodec/nvdec.h
+++ b/libavcodec/nvdec.h
@@ -56,7 +56,7 @@ typedef struct NVDECContext {
struct NVDECDecoder *decoder; ///< RefStruct reference
-uint8_t *bitstream;
+const uint8_t *bitstream;
int bitstream_len;
unsigned int bitstream_allocated;
uint8_t *bitstream_internal;
diff --git a/libavcodec/nvdec_av1.c b/libavcodec/nvdec_av1.c
index 74b0442177..35f22ebf80 100644
--- a/libavcodec/nvdec_av1.c
+++ b/libavcodec/nvdec_av1.c
@@ -303,7 +303,7 @@ static int nvdec_av1_decode_slice(AVCodecContext *avctx,
const uint8_t *buffer,
/* Shortcut if all tiles are in the same buffer */
if (ctx->nb_slices == s->tg_end - s->tg_start + 1) {
-ctx->bitstream = (uint8_t*)buffer;
+ctx->bitstream = buffer;
ctx->bitstream_len = size;
for (int i = 0; i < ctx->nb_slices; ++i) {
@@ -321,7 +321,7 @@ static int nvdec_av1_decode_slice(AVCodecContext *avctx,
const uint8_t *buffer,
}
ctx->bitstream = ctx->bitstream_internal = tmp;
-memcpy(ctx->bitstream + ctx->bitstream_len, buffer, size);
+memcpy(ctx->bitstream_internal + ctx->bitstream_len, buffer, size);
for (uint32_t tile_num = s->tg_start; tile_num <= s->tg_end; ++tile_num) {
ctx->slice_offsets[tile_num*2] = ctx->bitstream_len +
s->tile_group_info[tile_num].tile_offset;
diff --git a/libavcodec/nvdec_h264.c b/libavcodec/nvdec_h264.c
index 8c72d5f4f7..ea6c1081eb 100644
--- a/libavcodec/nvdec_h264.c
+++ b/libavcodec/nvdec_h264.c
@@ -150,8 +150,8 @@ static int nvdec_h264_decode_slice(AVCodecContext *avctx,
const uint8_t *buffer,
return AVERROR(ENOMEM);
ctx->slice_offsets = tmp;
-AV_WB24(ctx->bitstream + ctx->bitstream_len, 1);
-memcpy(ctx->bitstream + ctx->bitstream_len + 3, buffer, size);
+AV_WB24(ctx->bitstream_internal + ctx->bitstream_len, 1);
+memcpy(ctx->bitstream_internal + ctx->bitstream_len + 3, buffer, size);
ctx->slice_offsets[ctx->nb_slices] = ctx->bitstream_len ;
ctx->bitstream_len += size + 3;
ctx->nb_slices++;
diff --git a/libavcodec/nvdec_hevc.c b/libavcodec/nvdec_hevc.c
index 25319a1328..ff118af04b 100644
--- a/libavcodec/nvdec_hevc.c
+++ b/libavcodec/nvdec_hevc.c
@@ -286,8 +286,8 @@ static int nvdec_hevc_decode_slice(AVCodecContext *avctx,
const uint8_t *buffer,
return AVERROR(ENOMEM);
ctx->slice_offsets = tmp;
-AV_WB24(ctx->bitstream + ctx->bitstream_len, 1);
-memcpy(ctx->bitstream + ctx->bitstream_len + 3, buffer, size);
+AV_WB24(ctx->bitstream_internal + ctx->bitstream_len, 1);
+memcpy(ctx->bitstream_internal + ctx->bitstream_len + 3, buffer, size);
ctx->slice_offsets[ctx->nb_slices] = ctx->bitstream_len ;
ctx->bitstream_len += size + 3;
ctx->nb_slices++;
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 0/2] Remove SDL2 output devices
On Wed, Feb 7, 2024 at 6:40 PM Vittorio Giovara wrote: > On Wed, Feb 7, 2024 at 6:38 PM Nicolas George wrote: > > > Anton Khirnov (12024-02-07): > > > ...so they are precisely broken by design. > > > > Words words words. > > > > Words to try and hide that something used to work for people and now you > > are done with it it no longer works. > > > > Exactly the kind of attitude that killed libav, killing FFmpeg now. > > > > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > -- > Vittorio > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > What about subtitles support, they are also very broken. When subtitles support will be removed soonTM? ___ 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] vvcdec: Mark as experimental
On Wed, Feb 7, 2024 at 10:13 PM Kieran Kunhya wrote: > $subj > > As discussed at FOSDEM. > Author of this patch above is forced to FUZZ this decoder until experimental flag is removed. > > Kieran > ___ > 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 2/2] Require compilers to support C17.
Feb 7, 2024, 22:11 by ffmpeg-devel@ffmpeg.org: > > >> On Feb 7, 2024, at 11:27 AM, Lynne wrote: >> As a compromise, we could start requiring C11 now, and C17 in 7.1. Or does anyone still care about compilers without even c11 support? >>> >>> How about C11 now and C17 in a year with ffmpeg 8? >>> >> >> Do you have setups and reasons why you can't update them >> that don't support C17 or are you speculating? >> > > I don't have any personal reasons why I can't support C17 immediately, but > C11 now / C17 in a year seems like an approach more likely to find consensus > than C17 immediately (or bumping to C17 in a minor release). It was also > roughly the approach proposed in person at FOSDEM. > It wasn't? There were simply no objections to moving to C11. The C17 plan came about later because it has important bugfixes. It doesn't really matter as compilers backported the new behaviour to C11 (or rather, they consistently had the same behaviour, but now it became a standard). I think there is consensus. No need to be careful or conservative, this is a build-time bump. We've had those before, such as cuttting off support for MSVC prior to 2015, and non-C99 compilers (via the horrible C99-to-89 script). Users who have real issues can always leave their opinion here, and if not, we maintain FFmpeg 6 still. ___ 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] Require compilers to support C17.
On 2/7/2024 6:10 PM, Cosmin Stejerean via ffmpeg-devel wrote: On Feb 7, 2024, at 11:27 AM, Lynne wrote: As a compromise, we could start requiring C11 now, and C17 in 7.1. Or does anyone still care about compilers without even c11 support? How about C11 now and C17 in a year with ffmpeg 8? Do you have setups and reasons why you can't update them that don't support C17 or are you speculating? I don't have any personal reasons why I can't support C17 immediately, but C11 now / C17 in a year seems like an approach more likely to find consensus than C17 immediately (or bumping to C17 in a minor release). It was also roughly the approach proposed in person at FOSDEM. What are the fixes in c17 that we would benefit from, that compilers from before 2017 would be affected by? And if we go with Cosmin's suggestion, we could always look for __STDC_VERSION__ >= 201710L where it matters until c17 becomes the minimum version in a year. ___ 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] vvcdec: Mark as experimental
$subj As discussed at FOSDEM. Kieran 0001-vvcdec-Mark-as-experimental.patch Description: Binary data ___ 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] Require compilers to support C17.
> On Feb 7, 2024, at 11:27 AM, Lynne wrote: > >>> >>> As a compromise, we could start requiring C11 now, and C17 in 7.1. >>> Or does anyone still care about compilers without even c11 support? >>> >> >> How about C11 now and C17 in a year with ffmpeg 8? >> > > Do you have setups and reasons why you can't update them > that don't support C17 or are you speculating? I don't have any personal reasons why I can't support C17 immediately, but C11 now / C17 in a year seems like an approach more likely to find consensus than C17 immediately (or bumping to C17 in a minor release). It was also roughly the approach proposed in person at FOSDEM. - Cosmin ___ 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] STF SoWs
On Wed, Feb 07, 2024 at 02:01:35PM -0500, Leo Izen wrote: > On 2/6/24 16:23, Michael Niedermayer wrote: > > Its true anyone of 2000 people could block a patch. This is not neccessary > > for the argument at all though. > > I don't think this is really a fair statement to make. We have lots of > potential reviewers subscribed to this list but very few people actually > review code, and those that do review code are expected to provide some sort > of technical objection or reason why it shouldn't be merged. A random > subscriber without commit access posting "Nak" on a patch without explaining > why isn't grounds to block it. you are correct thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Elect your leaders based on what they did after the last election, not based on what they say before an election. 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/2] Require compilers to support C17.
Feb 7, 2024, 19:52 by ffmpeg-devel@ffmpeg.org: > > >> On Feb 7, 2024, at 1:55 AM, Anton Khirnov wrote: >> >> As a compromise, we could start requiring C11 now, and C17 in 7.1. >> Or does anyone still care about compilers without even c11 support? >> > > How about C11 now and C17 in a year with ffmpeg 8? > Do you have setups and reasons why you can't update them that don't support C17 or are you speculating? ___ 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] FFmpeg 7.0 blocking issues
Leo Izen: > On 1/23/24 14:22, Michael Niedermayer wrote: >> Hi all >> >> As it was a little difficult for me to not loose track of what is >> blocking a release. I suggest that for all release blocking issues >> open a ticket and set Blocking to 7.0 >> that way this: >> https://trac.ffmpeg.org/query?blocking=~7.0 >> >> or for the ones not closed: >> https://trac.ffmpeg.org/query?status=new=open=reopened=~7.0 >> >> will list all blocking issues >> >> Ive added one, for testing that, i intend to add more if i see something >> >> What is blocking? (IMHO) >> * regressions (unless its non possible to fix before release) >> * crashes >> * security issues >> * data loss >> * privacy issues >> * anything the commuity agrees should be in the release >> >> thx >> >> > > My EXIF overhaul is going to be an ABI break so I'd like to get it in, > if and only if we are doing an ABI break with the release. > What EXIF overhaul? Since when is EXIF part of the ABI? - 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 v7 1/2] libavformat/dvdvideo: add DVD-Video demuxer powered by libdvdnav and libdvdread
Marth64:
> Sorry for the quick follow-up to v6, I wanted to get this update out now
> hopefully
> before v6 is actually reviewed. v7 fixes a few documentation typos, options
> descriptions,
> and log messages: nothing major. I also flattened this out to be a 2-patch set
> with subtitle palette support.
>
> This is the result of >1yr of research and I am now very satisfied with it's
> result.
> I will not make any more changes at this point unless it is outcome from a
> review.
> If the community decides to merge it, I am happy to continue to improve it
> with support for
> seeking, probing, and tests.
>
> Thank you so much,
>
>
> Signed-off-by: Marth64
> ---
> Changelog |2 +
> configure |8 +
> doc/demuxers.texi | 129
> libavformat/Makefile |1 +
> libavformat/allformats.c |1 +
> libavformat/dvdvideodec.c | 1410 +
> 6 files changed, 1551 insertions(+)
> create mode 100644 libavformat/dvdvideodec.c
>
> diff --git a/Changelog b/Changelog
> index c5fb21d198..88653bc6d3 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -24,6 +24,8 @@ version :
> - ffmpeg CLI options may now be used as -/opt , which is equivalent
>to -opt >
> - showinfo bitstream filter
> +- DVD-Video demuxer, powered by libdvdnav and libdvdread
> +
>
> version 6.1:
> - libaribcaption decoder
> diff --git a/configure b/configure
> index 68f675a4bc..70c33ec96d 100755
> --- a/configure
> +++ b/configure
> @@ -227,6 +227,8 @@ External library support:
>--enable-libdavs2enable AVS2 decoding via libdavs2 [no]
>--enable-libdc1394 enable IIDC-1394 grabbing using libdc1394
> and libraw1394 [no]
> + --enable-libdvdnav enable libdvdnav, needed for DVD demuxing [no]
> + --enable-libdvdread enable libdvdread, needed for DVD demuxing [no]
>--enable-libfdk-aac enable AAC de/encoding via libfdk-aac [no]
>--enable-libfliteenable flite (voice synthesis) support via
> libflite [no]
>--enable-libfontconfig enable libfontconfig, useful for drawtext filter
> [no]
> @@ -1806,6 +1808,8 @@ EXTERNAL_LIBRARY_GPL_LIST="
> frei0r
> libcdio
> libdavs2
> +libdvdnav
> +libdvdread
> librubberband
> libvidstab
> libx264
> @@ -3520,6 +3524,8 @@ dts_demuxer_select="dca_parser"
> dtshd_demuxer_select="dca_parser"
> dv_demuxer_select="dvprofile"
> dv_muxer_select="dvprofile"
> +dvdvideo_demuxer_select="mpegps_demuxer"
> +dvdvideo_demuxer_deps="libdvdnav libdvdread"
> dxa_demuxer_select="riffdec"
> eac3_demuxer_select="ac3_parser"
> evc_demuxer_select="evc_frame_merge_bsf evc_parser"
> @@ -6761,6 +6767,8 @@ enabled libdav1d && require_pkg_config
> libdav1d "dav1d >= 0.5.0" "dav1d
> enabled libdavs2 && require_pkg_config libdavs2 "davs2 >= 1.6.0"
> davs2.h davs2_decoder_open
> enabled libdc1394 && require_pkg_config libdc1394 libdc1394-2
> dc1394/dc1394.h dc1394_new
> enabled libdrm&& check_pkg_config libdrm libdrm xf86drm.h
> drmGetVersion
> +enabled libdvdnav && require_pkg_config libdvdnav "dvdnav >= 6.1.1"
> dvdnav/dvdnav.h dvdnav_open2
> +enabled libdvdread&& require_pkg_config libdvdread "dvdread >=
> 6.1.2" dvdread/dvd_reader.h DVDOpen2 -ldvdread
> enabled libfdk_aac&& { check_pkg_config libfdk_aac fdk-aac
> "fdk-aac/aacenc_lib.h" aacEncOpen ||
> { require libfdk_aac fdk-aac/aacenc_lib.h
> aacEncOpen -lfdk-aac &&
> warn "using libfdk without pkg-config"; } }
> diff --git a/doc/demuxers.texi b/doc/demuxers.texi
> index e4c5b560a6..ad0906f6ec 100644
> --- a/doc/demuxers.texi
> +++ b/doc/demuxers.texi
> @@ -285,6 +285,135 @@ This demuxer accepts the following option:
>
> @end table
>
> +@section dvdvideo
> +
> +DVD-Video demuxer, powered by libdvdnav and libdvdread.
> +
> +Can directly ingest DVD titles, specifically sequential PGCs,
> +into a conversion pipeline. Menus and seeking are not supported at this time.
> +
> +Block devices (DVD drives), ISO files, and directory structures are accepted.
> +Activate with @code{-f dvdvideo} in front of one of these inputs.
> +
> +Underlying playback is fully handled by libdvdnav, and structure parsing by
> libdvdread.
> +ffmpeg must be built with GPL library support available as well as the
> switches
> +@code{--enable-libdvdnav} and @code{--enable-libdvdread}.
> +
> +You will need to provide either the desired "title number" or exact PGC/PG
> coordinates.
> +Many open-source DVD players and tools can aid in providing this information.
> +If not specified, the demuxer will default to title 1 which works for many
> discs.
> +However, due to the flexibility of DVD-Video, it is recommended to check
> manually.
> +There are many discs that are authored strangely or with invalid headers.
> +
> +If the input is a real DVD drive, please
Re: [FFmpeg-devel] FFmpeg 7.0 blocking issues
> On Jan 23, 2024, at 11:22 AM, Michael Niedermayer > wrote: > > What is blocking? (IMHO) > * regressions (unless its non possible to fix before release) > * crashes > * security issues > * data loss > * privacy issues > * anything the commuity agrees should be in the release Can we get the animated WebP decoding in before this release? - Cosmin ___ 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] Require compilers to support C17.
> On Feb 7, 2024, at 1:55 AM, Anton Khirnov wrote: > > As a compromise, we could start requiring C11 now, and C17 in 7.1. > Or does anyone still care about compilers without even c11 support? How about C11 now and C17 in a year with ffmpeg 8? - Cosmin ___ 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] FFmpeg 7.0 blocking issues
On 1/23/24 14:22, Michael Niedermayer wrote: Hi all As it was a little difficult for me to not loose track of what is blocking a release. I suggest that for all release blocking issues open a ticket and set Blocking to 7.0 that way this: https://trac.ffmpeg.org/query?blocking=~7.0 or for the ones not closed: https://trac.ffmpeg.org/query?status=new=open=reopened=~7.0 will list all blocking issues Ive added one, for testing that, i intend to add more if i see something What is blocking? (IMHO) * regressions (unless its non possible to fix before release) * crashes * security issues * data loss * privacy issues * anything the commuity agrees should be in the release thx My EXIF overhaul is going to be an ABI break so I'd like to get it in, if and only if we are doing an ABI break with the release. - Leo Izen (Traneptora) OpenPGP_signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v7 2/2] libavformat/dvdvideo: add DVD CLUT utilities and enable palette support
Thank you, Andreas. This was very helpful. I will clean it up this evening.
On Wed, Feb 7, 2024 at 12:07 Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Marth64:
> > DVD subtitle palettes, which are natively YUV, are currently carried as
> > a hex string in their respective subtitle streams and have
> > no concept of colorspace tagging. In fact, the convention is to convert
> > them to RGB prior to storage. Common players will only render
> > the palettes properly if they are stored as RGB. Even ffmpeg itself
> > expects this, and already does -in libavformat- the YUV-RGB conversions,
> > specifically in mov.c and movenc.c.
> >
> > The point of this patch is to provide a consolidation of the code
> > that deals with creating the extradata as well as the RGB conversion.
> > That can then (1) enable usable palette support for DVD demuxer if it is
> merged
> > and (2) start the process of consolidating the related conversions in
> > MOV muxer/demuxer and eventually find a way to properly tag
> > the colorspace.
> >
> >
> > Signed-off-by: Marth64
> > ---
> > doc/demuxers.texi | 5 ++
> > libavformat/Makefile | 2 +-
> > libavformat/dvdclut.c | 104 ++
> > libavformat/dvdclut.h | 37 ++
> > libavformat/dvdvideodec.c | 14 +
> > 5 files changed, 161 insertions(+), 1 deletion(-)
> > create mode 100644 libavformat/dvdclut.c
> > create mode 100644 libavformat/dvdclut.h
> >
> > diff --git a/doc/demuxers.texi b/doc/demuxers.texi
> > index ad0906f6ec..9c666a29c1 100644
> > --- a/doc/demuxers.texi
> > +++ b/doc/demuxers.texi
> > @@ -390,6 +390,11 @@ often with junk data intended for controlling a
> real DVD player's
> > buffering speed and with no other material data value.
> > Default is 1, true.
> >
> > +@item clut_rgb
> > +Output subtitle palettes (CLUTs) as RGB, required for Matroska and MP4.
> > +Disable to output the palette in its original YUV colorspace.
> > +Default is 1, true.
> > +
> > @end table
> >
> > @subsection Examples
> > diff --git a/libavformat/Makefile b/libavformat/Makefile
> > index df69734877..8f17e43e49 100644
> > --- a/libavformat/Makefile
> > +++ b/libavformat/Makefile
> > @@ -192,7 +192,7 @@ OBJS-$(CONFIG_DTS_MUXER) += rawenc.o
> > OBJS-$(CONFIG_DV_MUXER) += dvenc.o
> > OBJS-$(CONFIG_DVBSUB_DEMUXER)+= dvbsub.o rawdec.o
> > OBJS-$(CONFIG_DVBTXT_DEMUXER)+= dvbtxt.o rawdec.o
> > -OBJS-$(CONFIG_DVDVIDEO_DEMUXER) += dvdvideodec.o
> > +OBJS-$(CONFIG_DVDVIDEO_DEMUXER) += dvdvideodec.o dvdclut.o
> > OBJS-$(CONFIG_DXA_DEMUXER) += dxa.o
> > OBJS-$(CONFIG_EA_CDATA_DEMUXER) += eacdata.o
> > OBJS-$(CONFIG_EA_DEMUXER)+= electronicarts.o
> > diff --git a/libavformat/dvdclut.c b/libavformat/dvdclut.c
> > new file mode 100644
> > index 00..71fdda7925
> > --- /dev/null
> > +++ b/libavformat/dvdclut.c
> > @@ -0,0 +1,104 @@
> > +/*
> > + * DVD-Video subpicture CLUT (Color Lookup Table) utilities
> > + *
> > + * This file is part of FFmpeg.
> > + *
> > + * FFmpeg is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU Lesser General Public
> > + * License as published by the Free Software Foundation; either
> > + * version 2.1 of the License, or (at your option) any later version.
> > + *
> > + * FFmpeg is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> > + * Lesser General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU Lesser General Public
> > + * License along with FFmpeg; if not, write to the Free Software
> > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301 USA
> > + */
> > +
> > +#include "libavutil/bprint.h"
> > +#include "libavutil/colorspace.h"
> > +#include "libavutil/intreadwrite.h"
>
> Seems unneeded, just like avformat.h.
>
> > +
> > +#include "avformat.h"
> > +#include "dvdclut.h"
> > +#include "internal.h"
> > +
> > +/* crop table for YUV to RGB subpicture palette conversion */
> > +#define FF_DVDCLUT_YUV_NEG_CROP_MAX1024
>
> An FF-prefix for an internal define is not needed.
>
> > +#define times4(x) x, x, x, x
> > +#define times256(x)
> times4(times4(times4(times4(times4(x)
>
> This is actually a times1024 (which matches the size of the LUT).
>
> > +
> > +const uint8_t ff_dvdclut_yuv_crop_tab[256 + 2 *
> FF_DVDCLUT_YUV_NEG_CROP_MAX] = {
> > +times256(0x00),
> >
> +0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0A,0x0B,0x0C,0x0D,0x0E,0x0F,
> >
> +0x10,0x11,0x12,0x13,0x14,0x15,0x16,0x17,0x18,0x19,0x1A,0x1B,0x1C,0x1D,0x1E,0x1F,
> >
> +0x20,0x21,0x22,0x23,0x24,0x25,0x26,0x27,0x28,0x29,0x2A,0x2B,0x2C,0x2D,0x2E,0x2F,
> >
>
Re: [FFmpeg-devel] [PATCH v7 2/2] libavformat/dvdvideo: add DVD CLUT utilities and enable palette support
Marth64:
> DVD subtitle palettes, which are natively YUV, are currently carried as
> a hex string in their respective subtitle streams and have
> no concept of colorspace tagging. In fact, the convention is to convert
> them to RGB prior to storage. Common players will only render
> the palettes properly if they are stored as RGB. Even ffmpeg itself
> expects this, and already does -in libavformat- the YUV-RGB conversions,
> specifically in mov.c and movenc.c.
>
> The point of this patch is to provide a consolidation of the code
> that deals with creating the extradata as well as the RGB conversion.
> That can then (1) enable usable palette support for DVD demuxer if it is
> merged
> and (2) start the process of consolidating the related conversions in
> MOV muxer/demuxer and eventually find a way to properly tag
> the colorspace.
>
>
> Signed-off-by: Marth64
> ---
> doc/demuxers.texi | 5 ++
> libavformat/Makefile | 2 +-
> libavformat/dvdclut.c | 104 ++
> libavformat/dvdclut.h | 37 ++
> libavformat/dvdvideodec.c | 14 +
> 5 files changed, 161 insertions(+), 1 deletion(-)
> create mode 100644 libavformat/dvdclut.c
> create mode 100644 libavformat/dvdclut.h
>
> diff --git a/doc/demuxers.texi b/doc/demuxers.texi
> index ad0906f6ec..9c666a29c1 100644
> --- a/doc/demuxers.texi
> +++ b/doc/demuxers.texi
> @@ -390,6 +390,11 @@ often with junk data intended for controlling a real DVD
> player's
> buffering speed and with no other material data value.
> Default is 1, true.
>
> +@item clut_rgb
> +Output subtitle palettes (CLUTs) as RGB, required for Matroska and MP4.
> +Disable to output the palette in its original YUV colorspace.
> +Default is 1, true.
> +
> @end table
>
> @subsection Examples
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index df69734877..8f17e43e49 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -192,7 +192,7 @@ OBJS-$(CONFIG_DTS_MUXER) += rawenc.o
> OBJS-$(CONFIG_DV_MUXER) += dvenc.o
> OBJS-$(CONFIG_DVBSUB_DEMUXER)+= dvbsub.o rawdec.o
> OBJS-$(CONFIG_DVBTXT_DEMUXER)+= dvbtxt.o rawdec.o
> -OBJS-$(CONFIG_DVDVIDEO_DEMUXER) += dvdvideodec.o
> +OBJS-$(CONFIG_DVDVIDEO_DEMUXER) += dvdvideodec.o dvdclut.o
> OBJS-$(CONFIG_DXA_DEMUXER) += dxa.o
> OBJS-$(CONFIG_EA_CDATA_DEMUXER) += eacdata.o
> OBJS-$(CONFIG_EA_DEMUXER)+= electronicarts.o
> diff --git a/libavformat/dvdclut.c b/libavformat/dvdclut.c
> new file mode 100644
> index 00..71fdda7925
> --- /dev/null
> +++ b/libavformat/dvdclut.c
> @@ -0,0 +1,104 @@
> +/*
> + * DVD-Video subpicture CLUT (Color Lookup Table) utilities
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> + */
> +
> +#include "libavutil/bprint.h"
> +#include "libavutil/colorspace.h"
> +#include "libavutil/intreadwrite.h"
Seems unneeded, just like avformat.h.
> +
> +#include "avformat.h"
> +#include "dvdclut.h"
> +#include "internal.h"
> +
> +/* crop table for YUV to RGB subpicture palette conversion */
> +#define FF_DVDCLUT_YUV_NEG_CROP_MAX1024
An FF-prefix for an internal define is not needed.
> +#define times4(x) x, x, x, x
> +#define times256(x)
> times4(times4(times4(times4(times4(x)
This is actually a times1024 (which matches the size of the LUT).
> +
> +const uint8_t ff_dvdclut_yuv_crop_tab[256 + 2 * FF_DVDCLUT_YUV_NEG_CROP_MAX]
> = {
> +times256(0x00),
> +0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0A,0x0B,0x0C,0x0D,0x0E,0x0F,
> +0x10,0x11,0x12,0x13,0x14,0x15,0x16,0x17,0x18,0x19,0x1A,0x1B,0x1C,0x1D,0x1E,0x1F,
> +0x20,0x21,0x22,0x23,0x24,0x25,0x26,0x27,0x28,0x29,0x2A,0x2B,0x2C,0x2D,0x2E,0x2F,
> +0x30,0x31,0x32,0x33,0x34,0x35,0x36,0x37,0x38,0x39,0x3A,0x3B,0x3C,0x3D,0x3E,0x3F,
> +0x40,0x41,0x42,0x43,0x44,0x45,0x46,0x47,0x48,0x49,0x4A,0x4B,0x4C,0x4D,0x4E,0x4F,
> +0x50,0x51,0x52,0x53,0x54,0x55,0x56,0x57,0x58,0x59,0x5A,0x5B,0x5C,0x5D,0x5E,0x5F,
> +0x60,0x61,0x62,0x63,0x64,0x65,0x66,0x67,0x68,0x69,0x6A,0x6B,0x6C,0x6D,0x6E,0x6F,
> +0x70,0x71,0x72,0x73,0x74,0x75,0x76,0x77,0x78,0x79,0x7A,0x7B,0x7C,0x7D,0x7E,0x7F,
>
Re: [FFmpeg-devel] [PATCH 0/2] Remove SDL2 output devices
On Wed, Feb 7, 2024 at 6:38 PM Nicolas George wrote: > Anton Khirnov (12024-02-07): > > ...so they are precisely broken by design. > > Words words words. > > Words to try and hide that something used to work for people and now you > are done with it it no longer works. > > Exactly the kind of attitude that killed libav, killing FFmpeg now. > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 0/2] Remove SDL2 output devices
Anton Khirnov (12024-02-07): > ...so they are precisely broken by design. Words words words. Words to try and hide that something used to work for people and now you are done with it it no longer works. Exactly the kind of attitude that killed libav, killing FFmpeg now. -- 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] STF SoWs
Hi, On Wed, Feb 7, 2024 at 9:44 AM Michael Niedermayer wrote: > [..] i see as only options left to either do a quick vote on > the finished Coverity bug fixing SoW, so a simple "is this text ok", and if > yes nothing anyone says later can create another problem. > That seems reasonable. Ronald ___ 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 0/2] Remove SDL2 output devices
Quoting Stefano Sabatini (2024-02-05 01:02:20) > This implies a misunderstanding of what these components are. If > they are broken with ffmpeg.c this is not a good reason to remove > them (ffmpeg.c is not the only user). They are broken with _any_ caller that happens to call libavformat from a thread other than the main one. Since libavformat API does not impose any such restrictions on its callers, these devices are broken in general. > Also, it was already suggested some way to fix it There is no way to fix them other than impose new restrictions on callers... > it's not like they are "broken by design", ...so they are precisely broken by design. -- 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 2/2] Require compilers to support C17.
Quoting Devin Heitmueller (2024-02-07 17:15:30) > On Wed, Feb 7, 2024 at 4:50 AM Anton Khirnov wrote: > > Not to mention anonymous unions were standardized in C11 and widely > > available for many years (possibly decades) before that, so it's hardly > > a 'latest whizbang feature'. > > Yeah, I said "anonymous unions" because that was actually the > justification you offered for making C17 the minimum. I wasn't > intending to offer a critique on using any specific language feature, > but rather wanted to make sure everyone agreed on the implications of > changing the minimum compiler version. You misunderstand, the argument for C17 rather than C11 has nothing to do with anonymous unions, as they are available in both. My original proposal was C11, but it was pointed out at FOSDEM that C17 has no new features and is pretty much just "C11 with bugfixes" - some of them important for us - and all reasonably recent compilers should support both. So if we are doing this at all, might as well take the extra step. Nobody had any objections to that, which is why this patch goes with C17. > > > but there's a reason that many projects choose to have > > > relatively old minimum language versions. > > > > > > Now, again, if the developer community all agree that it makes sense > > > to stop supporting an operating system that was shipping as recently > > > as five years ago, then so be it. But this sort of deprecation > > > shouldn't simply be the result of a single developer deciding he wants > > > to use anonymous unions (or some other C17 feature) and thus we drop > > > support for a bunch of operating system versions. > > > > In case you missed it, I didn't just randomly send this out of the blue, > > it was discussed at the FOSDEM dev meeting (and before that on IRC and > > the ML) and literally nobody in the room was against moving to C11. > > Right, so like many people I'm not on the IRC 24x7, and regrettably I > couldn't make the FOSDEM meeting. Perhaps I simply overlooked it, but > I couldn't find anything on the ML other than the patch you sent on > February 3rd changing it to C11. Given the possible implications, I > would have expected to see a discussion on the ML. If such a > discussion did happen on the ML and I overlooked it, then I guess it's > on me for not raising concerns earlier. > > In fact, the FOSDEM discussion and the earlier patch was about C11, > which I actually don't have any objection to. I would argue the same > discussion should be had to assess the impact and conclude whether > it's worth it, but it doesn't effect any of my use cases and (in my > opinion) there are likely to be far fewer users impacted by such a > change. > > This feels like just the sort of thing the TC is meant to > discuss/resolve. And the fact that your position as the developer > submitting the patch is that it's "no big deal" is exactly why it's > the sort of thing that needs agreement from a wider audience. I agree that there needs to be a discussion, and this thread is precisely the place where it's happening. See also my other proposal to switch to C11 for now, and C17 for 7.1. -- 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 2/2] Require compilers to support C17.
Hello Anton, On Wed, Feb 7, 2024 at 4:50 AM Anton Khirnov wrote: > > Now I know that developers *LOVE* to use the latest whizbang language > > features, > > Could we please not have these kinds of caricatures in here? It's not > helpful. Permit me to rephrase: In my 25+ years of experience as a full-time C/C++ developer, I have run across many cases where a developer decided he/she/they wanted to use some relatively new language feature, often without consideration for the availability of compilers across popular platforms used by users. This is not the sort of thing that should be taken lightly, and usually needs discussion with the wider developer community (and in some cases the larger user community, depending on the project). In fact, that single developer often doesn't even have a complete picture of who is impacted by such a proposed change. Which is why we talk about it. Sometimes the answer is simply, "Hell no, we're not going to continue supporting Windows 98!". And sometimes the answer is, "Oh wait, that means these tens of thousands of users will need to upgrade their servers or cross-compile. Perhaps we shouldn't demand that of them just for the benefit of language feature X at this time..." > Not to mention anonymous unions were standardized in C11 and widely > available for many years (possibly decades) before that, so it's hardly > a 'latest whizbang feature'. Yeah, I said "anonymous unions" because that was actually the justification you offered for making C17 the minimum. I wasn't intending to offer a critique on using any specific language feature, but rather wanted to make sure everyone agreed on the implications of changing the minimum compiler version. > > but there's a reason that many projects choose to have > > relatively old minimum language versions. > > > > Now, again, if the developer community all agree that it makes sense > > to stop supporting an operating system that was shipping as recently > > as five years ago, then so be it. But this sort of deprecation > > shouldn't simply be the result of a single developer deciding he wants > > to use anonymous unions (or some other C17 feature) and thus we drop > > support for a bunch of operating system versions. > > In case you missed it, I didn't just randomly send this out of the blue, > it was discussed at the FOSDEM dev meeting (and before that on IRC and > the ML) and literally nobody in the room was against moving to C11. Right, so like many people I'm not on the IRC 24x7, and regrettably I couldn't make the FOSDEM meeting. Perhaps I simply overlooked it, but I couldn't find anything on the ML other than the patch you sent on February 3rd changing it to C11. Given the possible implications, I would have expected to see a discussion on the ML. If such a discussion did happen on the ML and I overlooked it, then I guess it's on me for not raising concerns earlier. In fact, the FOSDEM discussion and the earlier patch was about C11, which I actually don't have any objection to. I would argue the same discussion should be had to assess the impact and conclude whether it's worth it, but it doesn't effect any of my use cases and (in my opinion) there are likely to be far fewer users impacted by such a change. This feels like just the sort of thing the TC is meant to discuss/resolve. And the fact that your position as the developer submitting the patch is that it's "no big deal" is exactly why it's the sort of thing that needs agreement from a wider audience. Devin -- Devin Heitmueller, Senior Software Engineer LTN Global Communications o: +1 (301) 363-1001 w: https://ltnglobal.com e: devin.heitmuel...@ltnglobal.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] libavcodec: add tune_content option also for VP8.
This exposes VP8E_SET_SCREEN_CONTENT_MODE option from libvpx.
Changes since v1:
- Put the new param initialzation in the right place,
- Account for cases when the encoder's output is queued up.
Co-authored-by: Erik Språng
Signed-off-by: Dariusz Marcinkiewicz
---
doc/encoders.texi | 7 --
libavcodec/libvpxenc.c | 56 ++
2 files changed, 56 insertions(+), 7 deletions(-)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index c9fe6d6143..2a9b38f62a 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2186,6 +2186,11 @@ Enable error resiliency features.
Increase sharpness at the expense of lower PSNR.
The valid range is [0, 7].
+@item tune-content
+Set content type.
+For VP8: default (0), screen (1), screen with aggressive rate control (2).
+For VP9: default (0), screen (1), film (2).
+
@item ts-parameters
Sets the temporal scalability configuration using a :-separated list of
key=value pairs. For example, to specify temporal scalability parameters
@@ -2268,8 +2273,6 @@ colorspaces:
@end table
@item row-mt @var{boolean}
Enable row based multi-threading.
-@item tune-content
-Set content type: default (0), screen (1), film (2).
@item corpus-complexity
Corpus VBR mode is a variant of standard VBR where the complexity distribution
midpoint is passed in rather than calculated for a specific clip or chunk.
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 80988a2608..c73c92d49b 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -164,6 +164,7 @@ static const char *const ctlidstr[] = {
[VP8E_SET_MAX_INTRA_BITRATE_PCT] = "VP8E_SET_MAX_INTRA_BITRATE_PCT",
[VP8E_SET_SHARPNESS] = "VP8E_SET_SHARPNESS",
[VP8E_SET_TEMPORAL_LAYER_ID] = "VP8E_SET_TEMPORAL_LAYER_ID",
+[VP8E_SET_SCREEN_CONTENT_MODE] = "VP8E_SET_SCREEN_CONTENT_MODE",
#if CONFIG_LIBVPX_VP9_ENCODER
[VP9E_SET_LOSSLESS]= "VP9E_SET_LOSSLESS",
[VP9E_SET_TILE_COLUMNS]= "VP9E_SET_TILE_COLUMNS",
@@ -1262,6 +1263,16 @@ static av_cold int vpx_init(AVCodecContext *avctx,
#endif
}
#endif
+#ifdef VPX_CTRL_VP8E_SET_SCREEN_CONTENT_MODE
+if (avctx->codec_id == AV_CODEC_ID_VP8 && ctx->tune_content >= 0) {
+ if (ctx->tune_content == 2 && ctx->is_alpha) {
+av_log(avctx, AV_LOG_ERROR,
+ "Transparency encoding with screen mode with aggressive rate
control not supported\n");
+return AVERROR(EINVAL);
+ }
+ codecctl_int(avctx, VP8E_SET_SCREEN_CONTENT_MODE, ctx->tune_content);
+}
+#endif
av_log(avctx, AV_LOG_DEBUG, "Using deadline: %d\n", ctx->deadline);
@@ -1379,14 +1390,15 @@ static int storeframe(AVCodecContext *avctx, struct
FrameListData *cx_frame,
* @return AVERROR(ENOMEM) on coded frame queue data allocation error
*/
static int queue_frames(AVCodecContext *avctx, struct vpx_codec_ctx *encoder,
-struct FrameListData **frame_list, AVPacket *pkt_out)
+struct FrameListData **frame_list, AVPacket *pkt_out,
+int queue_only, int *frame_enc)
{
VPxContext *ctx = avctx->priv_data;
const struct vpx_codec_cx_pkt *pkt;
const void *iter = NULL;
int size = 0;
-if (!ctx->is_alpha && *frame_list) {
+if (!queue_only && *frame_list) {
struct FrameListData *cx_frame = *frame_list;
/* return the leading frame if we've already begun queueing */
size = storeframe(avctx, cx_frame, NULL, pkt_out);
@@ -1401,7 +1413,7 @@ static int queue_frames(AVCodecContext *avctx, struct
vpx_codec_ctx *encoder,
while (pkt = vpx_codec_get_cx_data(encoder, )) {
switch (pkt->kind) {
case VPX_CODEC_CX_FRAME_PKT:
-if (!ctx->is_alpha && !size) {
+if (!queue_only && !size) {
struct FrameListData cx_frame;
/* avoid storing the frame when the list is empty and we
haven't yet
@@ -1411,6 +1423,8 @@ static int queue_frames(AVCodecContext *avctx, struct
vpx_codec_ctx *encoder,
size = storeframe(avctx, _frame, NULL, pkt_out);
if (size < 0)
return size;
+if (size > 0)
+*frame_enc = 1;
} else {
struct FrameListData *cx_frame = av_malloc(sizeof(*cx_frame));
@@ -1430,6 +1444,8 @@ static int queue_frames(AVCodecContext *avctx, struct
vpx_codec_ctx *encoder,
return AVERROR(ENOMEM);
}
memcpy(cx_frame->buf, pkt->data.frame.buf, pkt->data.frame.sz);
+if (pkt->data.frame.sz > 0)
+ *frame_enc = 1;
coded_frame_add(frame_list, cx_frame);
}
break;
@@ -1693,6 +1709,7 @@ static int vpx_encode(AVCodecContext *avctx, AVPacket
*pkt,
vpx_svc_layer_id_t layer_id;
int layer_id_valid = 0;
unsigned long duration = 0;
[FFmpeg-devel] [PATCH] avcodec/nvdec: Constify bitstream pointee
Signed-off-by: Andreas Rheinhardt
---
libavcodec/nvdec.c | 2 +-
libavcodec/nvdec.h | 2 +-
libavcodec/nvdec_av1.c | 4 ++--
libavcodec/nvdec_h264.c | 4 ++--
libavcodec/nvdec_hevc.c | 4 ++--
5 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
index d13b790632..553c9bdf18 100644
--- a/libavcodec/nvdec.c
+++ b/libavcodec/nvdec.c
@@ -680,7 +680,7 @@ int ff_nvdec_simple_decode_slice(AVCodecContext *avctx,
const uint8_t *buffer,
ctx->slice_offsets = tmp;
if (!ctx->bitstream)
-ctx->bitstream = (uint8_t*)buffer;
+ctx->bitstream = buffer;
ctx->slice_offsets[ctx->nb_slices] = buffer - ctx->bitstream;
ctx->bitstream_len += size;
diff --git a/libavcodec/nvdec.h b/libavcodec/nvdec.h
index 353e95bf42..555300d27d 100644
--- a/libavcodec/nvdec.h
+++ b/libavcodec/nvdec.h
@@ -56,7 +56,7 @@ typedef struct NVDECContext {
struct NVDECDecoder *decoder; ///< RefStruct reference
-uint8_t *bitstream;
+const uint8_t *bitstream;
int bitstream_len;
unsigned int bitstream_allocated;
uint8_t *bitstream_internal;
diff --git a/libavcodec/nvdec_av1.c b/libavcodec/nvdec_av1.c
index 74b0442177..35f22ebf80 100644
--- a/libavcodec/nvdec_av1.c
+++ b/libavcodec/nvdec_av1.c
@@ -303,7 +303,7 @@ static int nvdec_av1_decode_slice(AVCodecContext *avctx,
const uint8_t *buffer,
/* Shortcut if all tiles are in the same buffer */
if (ctx->nb_slices == s->tg_end - s->tg_start + 1) {
-ctx->bitstream = (uint8_t*)buffer;
+ctx->bitstream = buffer;
ctx->bitstream_len = size;
for (int i = 0; i < ctx->nb_slices; ++i) {
@@ -321,7 +321,7 @@ static int nvdec_av1_decode_slice(AVCodecContext *avctx,
const uint8_t *buffer,
}
ctx->bitstream = ctx->bitstream_internal = tmp;
-memcpy(ctx->bitstream + ctx->bitstream_len, buffer, size);
+memcpy(ctx->bitstream_internal + ctx->bitstream_len, buffer, size);
for (uint32_t tile_num = s->tg_start; tile_num <= s->tg_end; ++tile_num) {
ctx->slice_offsets[tile_num*2] = ctx->bitstream_len +
s->tile_group_info[tile_num].tile_offset;
diff --git a/libavcodec/nvdec_h264.c b/libavcodec/nvdec_h264.c
index 8c72d5f4f7..ea6c1081eb 100644
--- a/libavcodec/nvdec_h264.c
+++ b/libavcodec/nvdec_h264.c
@@ -150,8 +150,8 @@ static int nvdec_h264_decode_slice(AVCodecContext *avctx,
const uint8_t *buffer,
return AVERROR(ENOMEM);
ctx->slice_offsets = tmp;
-AV_WB24(ctx->bitstream + ctx->bitstream_len, 1);
-memcpy(ctx->bitstream + ctx->bitstream_len + 3, buffer, size);
+AV_WB24(ctx->bitstream_internal + ctx->bitstream_len, 1);
+memcpy(ctx->bitstream_internal + ctx->bitstream_len + 3, buffer, size);
ctx->slice_offsets[ctx->nb_slices] = ctx->bitstream_len ;
ctx->bitstream_len += size + 3;
ctx->nb_slices++;
diff --git a/libavcodec/nvdec_hevc.c b/libavcodec/nvdec_hevc.c
index 25319a1328..ff118af04b 100644
--- a/libavcodec/nvdec_hevc.c
+++ b/libavcodec/nvdec_hevc.c
@@ -286,8 +286,8 @@ static int nvdec_hevc_decode_slice(AVCodecContext *avctx,
const uint8_t *buffer,
return AVERROR(ENOMEM);
ctx->slice_offsets = tmp;
-AV_WB24(ctx->bitstream + ctx->bitstream_len, 1);
-memcpy(ctx->bitstream + ctx->bitstream_len + 3, buffer, size);
+AV_WB24(ctx->bitstream_internal + ctx->bitstream_len, 1);
+memcpy(ctx->bitstream_internal + ctx->bitstream_len + 3, buffer, size);
ctx->slice_offsets[ctx->nb_slices] = ctx->bitstream_len ;
ctx->bitstream_len += size + 3;
ctx->nb_slices++;
--
2.34.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] avcodec/x86/vvc/vvcdsp_init: fix unresolved external symbol on ARCH_X86_32
On Wed, Feb 7, 2024 at 6:00 PM Andreas Rheinhardt < andreas.rheinha...@outlook.com> wrote: > Wu Jianhua: > >> 发件人: ffmpeg-devel 代表 Andreas > Rheinhardt > >> 发送时间: 2024年2月5日 4:06 > >> 收件人: ffmpeg-devel@ffmpeg.org > >> 主题: Re: [FFmpeg-devel] [PATCH] avcodec/x86/vvc/vvcdsp_init: fix > unresolved external symbol on ARCH_X86_32 > >> > >> toq...@outlook.com: > >>> From: Wu Jianhua > >>> > >>> Signed-off-by: Wu Jianhua > >>> --- > >>> libavcodec/x86/vvc/vvcdsp_init.c | 78 > >>> 1 file changed, 40 insertions(+), 38 deletions(-) > >>> > >>> diff --git a/libavcodec/x86/vvc/vvcdsp_init.c > b/libavcodec/x86/vvc/vvcdsp_init.c > >>> index 909ef9f56b..8ee4074350 100644 > >>> --- a/libavcodec/x86/vvc/vvcdsp_init.c > >>> +++ b/libavcodec/x86/vvc/vvcdsp_init.c > >>> @@ -31,6 +31,7 @@ > >>> #include "libavcodec/vvc/vvcdsp.h" > >>> #include "libavcodec/x86/h26x/h2656dsp.h" > >>> > >> > >> Are really all of these functions unavailable for 32bit? > >> > >> - Andreas > > > > Yes. Both libavcodec\x86\vvc\vvc_mc.asm and > libavcodec\x86\h26x\h2656_inter.asm are wrapped in ARCH_X86_64. > > Patch seems ok then. > applied, thank you all > > - 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".
Re: [FFmpeg-devel] FFmpeg 7.0 blocking issues
Hi, On 1/23/2024 7:22 PM, Michael Niedermayer wrote: > What is blocking? (IMHO) > * regressions (unless its non possible to fix before release) > * crashes > * security issues > * data loss > * privacy issues > * anything the commuity agrees should be in the release We discussed it at FOSDEM, but I forgot to mark it as blocking at the time: Curently master is broken when files have both stream and frame level metadata of the same type. We all agreed on the fix, so nothing controversial, though - should be in meeting notes. - Derek ___ 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] STF SoWs
On Wed, Feb 07, 2024 at 08:08:34AM -0500, Ronald S. Bultje wrote:
> Hi Michael,
>
> On Wed, Feb 7, 2024 at 7:58 AM Michael Niedermayer
> wrote:
>
> > Theres the person writing a SoW for work he wants to do.
> > Theres the person who accepts the SoW in FFmpeg
> > Theres the person who passes accepted SoW on to SPI/STF
> >
> > Iam sadly involved in more than one role here.
> >
>
> I think this is what Vittorio was referring to when he said this might be
> problematic. This is essentially what conflict-of-interest means. It
> doesn't mean that you're a bad person or doing something wrong, it simply
> means that there's overlapping goals. For example, in this case, there
> might be your personal goals ("get paid for work") vs the project goals
> ("get money for maintenance"). They're (partially) overlapping but not
> equal, because they're different angles of the same situation.
>
> Sometimes there is no ideal solution that satisfies everyone. As I said
> before, that's normal and that's OK.
Yes, so the question is what do we do here?
Can you accept that "merge to git master" is not a deliverable ?
(at least in the february 2024 iteration)
Alternatively i can offer that i work on merging the code to git master
on a euro per hour rate with a limit. But again the actual merge is
not guranteed
failing that, i see as only options left to either do a quick vote on
the finished Coverity bug fixing SoW, so a simple "is this text ok", and if
yes nothing anyone says later can create another problem.
Or I can resign from my involvement in managing STF in february and someone
else can take that over. I never really wanted to manage it anyway, i was
just trying to help to get 200k€ to FFmpeg developers for their relentless
volunteer maintaince of the project so they would have something in exchange
for all they gave up of their own time
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] avcodec/vulkan_decode: Make Vulkan decode less spammy in verbose logs
On Wed, 7 Feb 2024 at 03:47, Lynne wrote: > > Feb 7, 2024, 03:11 by kaspe...@gmail.com: > > > Drop per frame decode messages to AV_LOG_TRACE level. > > > > Signed-off-by: Kacper Michajłow > > --- > > libavcodec/vulkan_av1.c | 2 +- > > libavcodec/vulkan_h264.c | 2 +- > > libavcodec/vulkan_hevc.c | 2 +- > > 3 files changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/libavcodec/vulkan_av1.c b/libavcodec/vulkan_av1.c > > index 9730e4b08d..c7d5a54012 100644 > > --- a/libavcodec/vulkan_av1.c > > +++ b/libavcodec/vulkan_av1.c > > @@ -530,7 +530,7 @@ static int vk_av1_end_frame(AVCodecContext *avctx) > > rav[i] = ap->ref_src[i]->f; > > } > > > > -av_log(avctx, AV_LOG_VERBOSE, "Decoding frame, %"SIZE_SPECIFIER" > > bytes, %i tiles\n", > > +av_log(avctx, AV_LOG_TRACE, "Decoding frame, %"SIZE_SPECIFIER" bytes, > > %i tiles\n", > > vp->slices_size, ap->tile_list.nb_tiles); > > > > return ff_vk_decode_frame(avctx, pic->f, vp, rav, rvp); > > diff --git a/libavcodec/vulkan_h264.c b/libavcodec/vulkan_h264.c > > index 39c123ddca..c918dbaa13 100644 > > --- a/libavcodec/vulkan_h264.c > > +++ b/libavcodec/vulkan_h264.c > > @@ -529,7 +529,7 @@ static int vk_h264_end_frame(AVCodecContext *avctx) > > rav[i] = hp->ref_src[i]->f; > > } > > > > -av_log(avctx, AV_LOG_VERBOSE, "Decoding frame, %"SIZE_SPECIFIER" > > bytes, %i slices\n", > > +av_log(avctx, AV_LOG_TRACE, "Decoding frame, %"SIZE_SPECIFIER" bytes, > > %i slices\n", > > vp->slices_size, hp->h264_pic_info.sliceCount); > > > > return ff_vk_decode_frame(avctx, pic->f, vp, rav, rvp); > > diff --git a/libavcodec/vulkan_hevc.c b/libavcodec/vulkan_hevc.c > > index 033172cbd6..0f6f2e775b 100644 > > --- a/libavcodec/vulkan_hevc.c > > +++ b/libavcodec/vulkan_hevc.c > > @@ -903,7 +903,7 @@ static int vk_hevc_end_frame(AVCodecContext *avctx) > > rvp[i] = >vp; > > } > > > > -av_log(avctx, AV_LOG_VERBOSE, "Decoding frame, %"SIZE_SPECIFIER" > > bytes, %i slices\n", > > +av_log(avctx, AV_LOG_TRACE, "Decoding frame, %"SIZE_SPECIFIER" bytes, > > %i slices\n", > > vp->slices_size, hp->h265_pic_info.sliceSegmentCount); > > > > return ff_vk_decode_frame(avctx, pic->frame, vp, rav, rvp); > > > > I don't agree with this, without this print, > you have no idea if hardware decoding is even being used. With this print you have no idea either. Unless you know only Vulkan decoder prints those messages, (that alone is a reason to remove them), there is nothing indicative about Vulkan or even hardware decoding in those messages, AVClass item_name is just "h264". [ffmpeg/video] h264: Decoding frame, 15808 bytes, 1 slices [ffmpeg/video] h264: Decoding frame, 17203 bytes, 1 slices [ffmpeg/video] h264: Decoding frame, 16862 bytes, 1 slices [ffmpeg/video] h264: Decoding frame, 15989 bytes, 1 slices Also debugging if something like hw decoding is working is precisely AV_LOG_TRACE or AV_LOG_DEBUG, not AV_LOG_VERBOSE, which in my opinion should be still useful information for the end user, not only for tracing purposes. "Using Vulkan hwdec on device foo" can be printed once at the beginning of decode... "Decoding frame" messages are in general not useful at all. > MP4 parsing is far too noisy than a single print per frame. "They are bad, so I can be bad too." is non-argument. Also I don't see exactly what you are referring to, in my experience MP4 is less noisy than a "Decoding frame" per each frame. It really shadows valid information in the log during decoding. - Kacper ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] x86/tx_float: enable SIMD for sizes over 131072
Feb 6, 2024, 12:14 by one...@gmail.com: > Please push this ASAP, my all private projects depends on it. > Pushed, thanks. ___ 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 00/24] Major library version bump
On 1/25/2024 1:23 PM, James Almer wrote: On 1/25/2024 10:43 AM, James Almer wrote: After this is committed, it will be open ABI season for a few weeks, but no longer than a month. So if you want to do some cleaning (like removing avpriv_ functions, or moving field offsets from public strucs around), now is the time. I was reminded that we got rid of this period, so if anyone has ABI breaking changes they want committed, please send a patch now, so it can be applied immediately before the bump. Reminder to people to submit any ABI breaking changes they want in before this set is 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".
Re: [FFmpeg-devel] STF SoWs
Le 7 février 2024 14:16:51 GMT+02:00, Nicolas George a écrit : >Paul B Mahol (12024-02-06): >> If this is again about SDR, go ahead, merge it. I no longer care. > >You should care. But you should care by being FOR it, not AGAINST. > >The people who oppose SDR are the same libav people who are disgusting >you and me and others away from the project with their authoritarian >attitude, their behaving like on conquered ground, their disregard for >features that only serve a handful of users but are crucial for them >because they cannot be found in any other software than FFmpeg. > >These people are killing the project, we should oppose them whenever we >have the courage. *Yawn*. Sure, go ahead and make your own Democratic People's fork of FFmpeg without the corporate capitalist oppressors. You can even make a downstream of librempeg but with SDR. Win-win-win. ___ 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] STF SoWs
Hi Michael,
On Wed, Feb 7, 2024 at 7:58 AM Michael Niedermayer
wrote:
> Theres the person writing a SoW for work he wants to do.
> Theres the person who accepts the SoW in FFmpeg
> Theres the person who passes accepted SoW on to SPI/STF
>
> Iam sadly involved in more than one role here.
>
I think this is what Vittorio was referring to when he said this might be
problematic. This is essentially what conflict-of-interest means. It
doesn't mean that you're a bad person or doing something wrong, it simply
means that there's overlapping goals. For example, in this case, there
might be your personal goals ("get paid for work") vs the project goals
("get money for maintenance"). They're (partially) overlapping but not
equal, because they're different angles of the same situation.
Sometimes there is no ideal solution that satisfies everyone. As I said
before, that's normal and that's OK.
Ronald
___
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] STF SoWs
On Tue, Feb 06, 2024 at 08:38:13PM -0500, Ronald S. Bultje wrote: > Hi, > > On Tue, Feb 6, 2024 at 6:04 PM Michael Niedermayer > wrote: > > > I think you should sign a SoW that has "Merged in git master" as a > > Deliverable > > > > I already did. It was fine. of course its fine 9 out of 10 times but 1 out of 10 times the customer is unhappy and you are unhappy. I like being transparent and explain this possibility to the customer/buisness partner. because no matter whats written in a contract, sometimes some patches cannot be merged in git master. > > > > PS: do you have a single person willing to sign this Deliverable you > > want ? > > If not, how will the STF thing work ? > > > > You're asking for community input for your proposal, I gave comments as > requested. It's OK to disagree on things, happens all the time. yes, but i was hoping we could find something we both agree on > You can A) > ignore my suggestions and submit the proposal to STF anyway, > B) submit a > proposal to STF as yourself rather than as FFmpeg (but for the same tasks, > on FFmpeg), > C) submit a proposal using another company/non-profit (e.g. > fflabs), > D) not submit a proposal to STF, > or E) something else ??? Its more complex Theres the person writing a SoW for work he wants to do. Theres the person who accepts the SoW in FFmpeg Theres the person who passes accepted SoW on to SPI/STF Iam sadly involved in more than one role here. If everyone including you agree on whats written in the SoW, i think its ok but if you disagree I cannot override or bypass that. That said, we from the point of view of FFmpeg should not promise STF that we can merge code in git master before its written. It could fail and would make the project look bad STF is about maintainance, analyzing bugs, fixing bugs, submitting patches reviewing patches maybe. Promising them that the whole community will accept every change. Which is what "merge to git master" is. Is not needed In fact it might even be counter productive. STF probabyl does not want things to be merged that people do not agree on. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Nations do behave wisely once they have exhausted all other alternatives. -- Abba Eban 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 3/3 v5] fate/mov: test remuxing all stream heif items
Signed-off-by: James Almer --- tests/fate/mov.mak | 2 +- tests/ref/fate/mov-heic-demux-still-image-multiple-items | 7 +++ 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak index 4850c8aa94..1be7a0d15a 100644 --- a/tests/fate/mov.mak +++ b/tests/fate/mov.mak @@ -161,7 +161,7 @@ fate-mov-heic-demux-still-image-1-item: CMD = framemd5 -i $(TARGET_SAMPLES)/heif FATE_MOV_FFMPEG-$(call FRAMEMD5, MOV, HEVC, HEVC_PARSER) \ += fate-mov-heic-demux-still-image-multiple-items -fate-mov-heic-demux-still-image-multiple-items: CMD = framemd5 -i $(TARGET_SAMPLES)/heif-conformance/C003.heic -c:v copy +fate-mov-heic-demux-still-image-multiple-items: CMD = framemd5 -i $(TARGET_SAMPLES)/heif-conformance/C003.heic -c:v copy -map 0 # Resulting remux should have: # 1. first audio stream with AV_DISPOSITION_HEARING_IMPAIRED diff --git a/tests/ref/fate/mov-heic-demux-still-image-multiple-items b/tests/ref/fate/mov-heic-demux-still-image-multiple-items index c850c1ff9c..753cef267a 100644 --- a/tests/ref/fate/mov-heic-demux-still-image-multiple-items +++ b/tests/ref/fate/mov-heic-demux-still-image-multiple-items @@ -2,10 +2,17 @@ #version: 2 #hash: MD5 #extradata 0, 100, 5444bf01e03182c73ae957179d560f4d +#extradata 1, 100, 5444bf01e03182c73ae957179d560f4d #tb 0: 1/1 #media_type 0: video #codec_id 0: hevc #dimensions 0: 1280x720 #sar 0: 0/1 +#tb 1: 1/1 +#media_type 1: video +#codec_id 1: hevc +#dimensions 1: 1280x720 +#sar 1: 0/1 #stream#, dts,pts, duration, size, hash 0, 0, 0,1, 111554, 03ceabfab39afd2e2e796b9362111f32 +1, 0, 0,1, 112393, daa001d351c088a5bc328459e2501c95 -- 2.43.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/3 v6] avformat/mov: add support for tile HEIF still images
Export each tile as its own stream, and the grid information as a Stream Group
of type TILE_GRID.
This also enables exporting other stream items like thumbnails, which may be
present in non tiled HEIF images too. For those, the primary stream will be
tagged with the default disposition.
Based on a patch by Swaraj Hota
Signed-off-by: James Almer
---
Now supporting more samples from the heif conformance set.
libavformat/avformat.c | 8 +
libavformat/avformat.h | 6 +
libavformat/dump.c | 2 +
libavformat/internal.h | 5 +
libavformat/isom.h | 15 +-
libavformat/mov.c | 427 -
6 files changed, 418 insertions(+), 45 deletions(-)
diff --git a/libavformat/avformat.c b/libavformat/avformat.c
index 32ef440207..c60e3fcb9d 100644
--- a/libavformat/avformat.c
+++ b/libavformat/avformat.c
@@ -120,6 +120,14 @@ void ff_remove_stream(AVFormatContext *s, AVStream *st)
ff_free_stream(>streams[ --s->nb_streams ]);
}
+void ff_remove_stream_group(AVFormatContext *s, AVStreamGroup *stg)
+{
+av_assert0(s->nb_stream_groups > 0);
+av_assert0(s->stream_groups[ s->nb_stream_groups - 1 ] == stg);
+
+ff_free_stream_group(>stream_groups[ --s->nb_stream_groups ]);
+}
+
/* XXX: suppress the packet queue */
void ff_flush_packet_queue(AVFormatContext *s)
{
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 0b1c2e46b5..ad95306efb 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -811,6 +811,12 @@ typedef struct AVIndexEntry {
* The video stream contains still images.
*/
#define AV_DISPOSITION_STILL_IMAGE (1 << 20)
+/**
+ * The video stream is intended to be merged with another stream before
+ * presentation.
+ * Used for example to signal the stream contains a tile from a HEIF grid.
+ */
+#define AV_DISPOSITION_TILE (1 << 21)
/**
* @return The AV_DISPOSITION_* flag corresponding to disp or a negative error
diff --git a/libavformat/dump.c b/libavformat/dump.c
index 2c019c36e4..6f6a67d7bc 100644
--- a/libavformat/dump.c
+++ b/libavformat/dump.c
@@ -655,6 +655,8 @@ static void dump_stream_format(const AVFormatContext *ic,
int i,
av_log(NULL, log_level, " (still image)");
if (st->disposition & AV_DISPOSITION_NON_DIEGETIC)
av_log(NULL, log_level, " (non-diegetic)");
+if (st->disposition & AV_DISPOSITION_TILE)
+av_log(NULL, log_level, " (tile)");
av_log(NULL, log_level, "\n");
dump_metadata(NULL, st->metadata, extra_indent, log_level);
diff --git a/libavformat/internal.h b/libavformat/internal.h
index f93832b3c4..9fb5397f27 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -635,6 +635,11 @@ void ff_remove_stream(AVFormatContext *s, AVStream *st);
* is not yet attached to an AVFormatContext.
*/
void ff_free_stream_group(AVStreamGroup **pstg);
+/**
+ * Remove a stream group from its AVFormatContext and free it.
+ * The stream group must be the last stream group of the AVFormatContext.
+ */
+void ff_remove_stream_group(AVFormatContext *s, AVStreamGroup *stg);
unsigned int ff_codec_get_tag(const AVCodecTag *tags, enum AVCodecID id);
diff --git a/libavformat/isom.h b/libavformat/isom.h
index a4cca4c798..ade6d88faf 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -267,15 +267,24 @@ typedef struct MOVStreamContext {
typedef struct HEIFItem {
AVStream *st;
+char *name;
int item_id;
int64_t extent_length;
int64_t extent_offset;
-int64_t size;
+int tile_rows;
+int tile_cols;
int width;
int height;
int type;
+int is_idat_relative;
} HEIFItem;
+typedef struct HEIFGrid {
+HEIFItem *item;
+int16_t *tile_id_list;
+int nb_tiles;
+} HEIFGrid;
+
typedef struct MOVContext {
const AVClass *class; ///< class for private options
AVFormatContext *fc;
@@ -339,6 +348,10 @@ typedef struct MOVContext {
int cur_item_id;
HEIFItem *heif_item;
int nb_heif_item;
+HEIFGrid *heif_grid;
+int nb_heif_grid;
+int thmb_item_id;
+int64_t idat_offset;
int interleaved_read;
} MOVContext;
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 42b0135987..01d6a0543b 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -185,6 +185,30 @@ static int mov_read_mac_string(MOVContext *c, AVIOContext
*pb, int len,
return p - dst;
}
+static AVStream *get_curr_st(MOVContext *c)
+{
+AVStream *st = NULL;
+
+if (c->fc->nb_streams < 1)
+return NULL;
+
+for (int i = 0; i < c->nb_heif_item; i++) {
+HEIFItem *item = >heif_item[i];
+
+if (!item->st)
+continue;
+if (item->st->id != c->cur_item_id)
+continue;
+
+st = item->st;
+break;
+}
+if (!st)
+st = c->fc->streams[c->fc->nb_streams-1];
+
+return st;
+}
+
static int mov_read_covr(MOVContext *c, AVIOContext *pb, int type, int len)
{
AVStream *st;
@@ -1767,9 +1791,9 @@
[FFmpeg-devel] [PATCH 1/3 v8] avformat: add a Tile Grid stream group type
This will be used to support tiled image formats like HEIF.
Signed-off-by: James Almer
---
libavformat/avformat.c | 5 +++
libavformat/avformat.h | 100 +
libavformat/dump.c | 29
libavformat/options.c | 32 +
4 files changed, 166 insertions(+)
diff --git a/libavformat/avformat.c b/libavformat/avformat.c
index 8e8c6fbe55..32ef440207 100644
--- a/libavformat/avformat.c
+++ b/libavformat/avformat.c
@@ -100,6 +100,11 @@ void ff_free_stream_group(AVStreamGroup **pstg)
av_iamf_mix_presentation_free(>params.iamf_mix_presentation);
break;
}
+case AV_STREAM_GROUP_PARAMS_TILE_GRID:
+av_opt_free(stg->params.tile_grid);
+av_freep(>params.tile_grid->offsets);
+av_freep(>params.tile_grid);
+break;
default:
break;
}
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 5d0fe82250..0b1c2e46b5 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1018,10 +1018,109 @@ typedef struct AVStream {
int pts_wrap_bits;
} AVStream;
+/**
+ * AVStreamGroupTileGrid holds information on how to combine several
+ * independent images on a single grid for presentation. None of the tiles may
+ * overlap inside the grid.
+ *
+ * The following is an example of a simple grid with 3 rows and 4 columns:
+ *
+ * +---+---+---+---+
+ * | 0 | 1 | 2 | 3 |
+ * +---+---+---+---+
+ * | 4 | 5 | 6 | 7 |
+ * +---+---+---+---+
+ * | 8 | 9 |10 |11 |
+ * +---+---+---+---+
+ *
+ * Assuming all tiles have a dimension of 512x512, the
+ * @ref AVStreamGroupTileGrid.offsets "offset" of the topleft pixel of
+ * the first @ref AVStreamGroup.streams "stream" in the group is "0,0", the
+ * @ref AVStreamGroupTileGrid.offsets "offset" of the topleft pixel of
+ * the second @ref AVStreamGroup.streams "stream" in the group is "512,0", the
+ * @ref AVStreamGroupTileGrid.offsets "offset" of the topleft pixel of
+ * the fifth @ref AVStreamGroup.streams "stream" in the group is "0,512", the
+ * @ref AVStreamGroupTileGrid.offsets "offset", of the topleft pixel of
+ * the sixth @ref AVStreamGroup.streams "stream" in the group is "512,512",
+ * etc.
+ *
+ * sizeof(AVStreamGroupTileGrid) is not a part of the ABI and may only be
+ * allocated by avformat_stream_group_create().
+ */
+typedef struct AVStreamGroupTileGrid {
+const AVClass *av_class;
+
+/**
+ * Width of the final image in the grid.
+ *
+ * Must be > 0.
+ */
+int coded_width;
+/**
+ * Width of the final image in the grid.
+ *
+ * Must be > 0.
+ */
+int coded_height;
+
+/**
+ * An @ref AVStreamGroup.nb_streams "nb_streams" sized array of offsets in
+ * pixels from the topleft edge of the grid, indicating where each stream
+ * should be placed.
+ * It must be allocated with the av_malloc() family of functions.
+ *
+ * - demuxing: set by libavformat, must not be modified by the caller.
+ * - muxing: set by the caller before avformat_write_header().
+ *
+ * Freed by libavformat in avformat_free_context().
+ */
+struct {
+int x;
+int y;
+} *offsets;
+
+/**
+ * Offset in pixels from the left edge of the grid where the actual image
+ * meant for presentation starts.
+ *
+ * This field must be >= 0 and <= @ref coded_width.
+ */
+int horizontal_offset;
+/**
+ * Offset in pixels from the top edge of the grid where the actual image
+ * meant for presentation starts.
+ *
+ * This field must be >= 0 and <= @ref coded_height.
+ */
+int vertical_offset;
+
+/**
+ * Width of the final image for presentation.
+ *
+ * Must be > 0 and <= (@ref coded_width - @ref horizontal_offset).
+ * When it's not equal to (@ref coded_width - @ref horizontal_offset), the
+ * result of (@ref coded_width - width - @ref horizontal_offset) is the
+ * amount amount of pixels to be cropped from the right edge of the
+ * final image before presentation.
+ */
+int width;
+/**
+ * Height of the final image for presentation.
+ *
+ * Must be > 0 and <= (@ref coded_height - @ref vertical_offset).
+ * When it's not equal to (@ref coded_height - @ref vertical_offset), the
+ * result of (@ref coded_height - height - @ref vertical_offset) is the
+ * amount amount of pixels to be cropped from the bottom edge of the
+ * final image before presentation.
+ */
+int height;
+} AVStreamGroupTileGrid;
+
enum AVStreamGroupParamsType {
AV_STREAM_GROUP_PARAMS_NONE,
AV_STREAM_GROUP_PARAMS_IAMF_AUDIO_ELEMENT,
AV_STREAM_GROUP_PARAMS_IAMF_MIX_PRESENTATION,
+AV_STREAM_GROUP_PARAMS_TILE_GRID,
};
struct AVIAMFAudioElement;
@@ -1062,6 +1161,7 @@ typedef struct AVStreamGroup {
union {
struct AVIAMFAudioElement *iamf_audio_element;
struct AVIAMFMixPresentation *iamf_mix_presentation;
+struct
Re: [FFmpeg-devel] STF SoWs
Paul B Mahol (12024-02-06): > If this is again about SDR, go ahead, merge it. I no longer care. You should care. But you should care by being FOR it, not AGAINST. The people who oppose SDR are the same libav people who are disgusting you and me and others away from the project with their authoritarian attitude, their behaving like on conquered ground, their disregard for features that only serve a handful of users but are crucial for them because they cannot be found in any other software than FFmpeg. These people are killing the project, we should oppose them whenever we have the courage. 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".
Re: [FFmpeg-devel] [PATCH 0/2] Remove SDL2 output devices
Anton Khirnov (12024-02-07): > For instance? What do these devices support that e.g. NUT does not? Returning the latency of the device. > neither should we try. This is the libav mindset we do not want in FFmpeg. -- 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] [PATCH] tests/fate-run: Sanitize test argument
test -z is a binary operator.
Signed-off-by: Andreas Rheinhardt
---
tests/fate-run.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index 8efb1586b8..9257fb368b 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -243,7 +243,7 @@ enc_dec(){
-f $dec_fmt_out -y $tdecfile || return
do_md5sum $decfile
tests/tiny_psnr${HOSTEXECSUF} $srcfile $decfile $cmp_unit $cmp_shift
-test -z $ffprobe_opts || \
+test -z "$ffprobe_opts" || \
run ffprobe${PROGSUF}${EXECSUF} -bitexact $ffprobe_opts $tencfile ||
return
}
@@ -268,7 +268,7 @@ transcode(){
echo $(wc -c $encfile)
ffmpeg $DEC_OPTS $final_decode -i $tencfile $ENC_OPTS $FLAGS $final_encode
\
-f framecrc - || return
-test -z $ffprobe_opts || \
+test -z "$ffprobe_opts" || \
run ffprobe${PROGSUF}${EXECSUF} -bitexact $ffprobe_opts $tencfile ||
return
}
@@ -288,7 +288,7 @@ stream_remux(){
-f $enc_fmt -y $tencfile || return
ffmpeg $DEC_OPTS -i $tencfile $ENC_OPTS $FLAGS $final_decode \
-f framecrc - || return
-test -z $ffprobe_opts || \
+test -z "$ffprobe_opts" || \
run ffprobe${PROGSUF}${EXECSUF} -bitexact $ffprobe_opts $tencfile ||
return
}
--
2.34.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 0/2] Remove SDL2 output devices
It works until move or resize the window. yes, that's right. I didn't notice because I didn't try to move or resize the window. My point is: Removing SDL would break many examples that can be found in the internet. Michael ___ 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 0/2] Remove SDL2 output devices
Quoting Marton Balint (2024-02-04 11:11:12) > > The 'pipe:' output can be used with a real video player such as mpv, vlc, or > > even ffplay. For cases where the user was an application using the API they > > should supply their own renderer. > > Yeah, but I never liked when people piped uncompressed data... Not > everything that the devices support can be serialized, For instance? What do these devices support that e.g. NUT does not? > it is extra CPU, latency of the receiving app reading from pipe is a > question... People keep saying this in defence of these devices, but never support such claims with any data. I have doubts this is an actual problem in practice. > I'd be a lot more happy with this if we'd offer some replacement which has > no issues. Maybe a libplacebo based outdev. I don't think it's possible to have such a replacement, neither should we try. Muxer API is simply the wrong abstraction for playback. -- 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 v2 1/2] lavu/hashtable: create generic robin hood hash table
Connor Worley:
> Signed-off-by: Connor Worley
> ---
> libavutil/Makefile | 2 +
> libavutil/hashtable.c | 183
> libavutil/hashtable.h | 47 +
> libavutil/tests/hashtable.c | 108 +
> 4 files changed, 340 insertions(+)
> create mode 100644 libavutil/hashtable.c
> create mode 100644 libavutil/hashtable.h
> create mode 100644 libavutil/tests/hashtable.c
>
> diff --git a/libavutil/Makefile b/libavutil/Makefile
> index e7709b97d0..be75d464fc 100644
> --- a/libavutil/Makefile
> +++ b/libavutil/Makefile
> @@ -138,6 +138,7 @@ OBJS = adler32.o
> \
> fixed_dsp.o \
> frame.o \
> hash.o \
> + hashtable.o \
> hdr_dynamic_metadata.o \
> hdr_dynamic_vivid_metadata.o \
> hmac.o \
> @@ -251,6 +252,7 @@ TESTPROGS = adler32
> \
> file\
> fifo\
> hash\
> +hashtable \
> hmac\
> hwdevice\
> integer \
> diff --git a/libavutil/hashtable.c b/libavutil/hashtable.c
> new file mode 100644
> index 00..6fa2af8af3
> --- /dev/null
> +++ b/libavutil/hashtable.c
> @@ -0,0 +1,183 @@
> +/*
> + * Generic hashtable
> + * Copyright (C) 2024 Connor Worley
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> + */
> +
> +#include
> +#include
> +
> +#include "crc.h"
> +#include "error.h"
> +#include "mem.h"
> +#include "hashtable.h"
> +
> +struct AVHashtableContext {
> +size_t key_size;
> +size_t val_size;
> +size_t entry_size;
> +size_t max_entries;
> +size_t utilization;
> +const AVCRC *crc;
> +uint8_t *table;
> +uint8_t *swapbuf;
> +};
> +
> +#define ENTRY_PSL(entry) (entry)
> +#define ENTRY_OCC(entry) (ENTRY_PSL(entry) + sizeof(size_t))
> +#define ENTRY_KEY(entry) (ENTRY_OCC(entry) + 4)
> +#define ENTRY_VAL(entry) (ENTRY_KEY(entry) + FFALIGN(ctx->key_size, 4))
> +
It seems you misunderstood what I said about alignment in my last
review. You should align entry_size and not align the size of key and
val fields. The way you are doing it now does not prevent unaligned
accesses: Imagine the common case of size_t having an alignment
requirement of 8 and key_size and val_size being four. Then entry_size
is not a multiple of 8 and therefore of two consecutive entries, only
one can be properly aligned (e.g. the second entry
ctx->table+ctx->entry_size is misaligned).
(For the same reason, the alignment of a struct is a multiple of the
alignment of every member of said struct.)
The way you are doing it also adds FFALIGN to every access to val.
> +#define KEYS_EQUAL(k1, k2) !memcmp(k1, k2, ctx->key_size)
> +
> +int av_hashtable_alloc(struct AVHashtableContext** ctx, size_t key_size,
> size_t val_size, size_t max_entries)
> +{
> +struct AVHashtableContext *res = av_malloc(sizeof(struct
> AVHashtableContext));
> +if (!res)
> +return AVERROR(ENOMEM);
> +res->key_size = key_size;
> +res->val_size = val_size;
You mostly only need key_size and key_size+val_size; val_size is not
used that often, so if you only store two sizes, it should not be stored.
> +res->entry_size = sizeof(size_t) + 4 + FFALIGN(key_size, 4) +
> FFALIGN(val_size, 4);
> +res->max_entries = max_entries;
> +res->utilization = 0;
> +res->crc = av_crc_get_table(AV_CRC_32_IEEE);
> +if (!res->crc)
Re: [FFmpeg-devel] 回复: [PATCH] avcodec/x86/vvc/vvcdsp_init: fix unresolved external symbol on ARCH_X86_32
Wu Jianhua: >> 发件人: ffmpeg-devel 代表 Andreas Rheinhardt >> >> 发送时间: 2024年2月5日 4:06 >> 收件人: ffmpeg-devel@ffmpeg.org >> 主题: Re: [FFmpeg-devel] [PATCH] avcodec/x86/vvc/vvcdsp_init: fix unresolved >> external symbol on ARCH_X86_32 >> >> toq...@outlook.com: >>> From: Wu Jianhua >>> >>> Signed-off-by: Wu Jianhua >>> --- >>> libavcodec/x86/vvc/vvcdsp_init.c | 78 >>> 1 file changed, 40 insertions(+), 38 deletions(-) >>> >>> diff --git a/libavcodec/x86/vvc/vvcdsp_init.c >>> b/libavcodec/x86/vvc/vvcdsp_init.c >>> index 909ef9f56b..8ee4074350 100644 >>> --- a/libavcodec/x86/vvc/vvcdsp_init.c >>> +++ b/libavcodec/x86/vvc/vvcdsp_init.c >>> @@ -31,6 +31,7 @@ >>> #include "libavcodec/vvc/vvcdsp.h" >>> #include "libavcodec/x86/h26x/h2656dsp.h" >>> >> >> Are really all of these functions unavailable for 32bit? >> >> - Andreas > > Yes. Both libavcodec\x86\vvc\vvc_mc.asm and > libavcodec\x86\h26x\h2656_inter.asm are wrapped in ARCH_X86_64. Patch seems ok then. - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] Require compilers to support C17.
Quoting Michael Niedermayer (2024-02-05 21:45:10) > On Mon, Feb 05, 2024 at 09:31:45PM +0100, Anton Khirnov wrote: > > Quoting Michael Niedermayer (2024-02-05 21:27:27) > > > please wait a bit with applying this so we understand better what it > > > affects > > > > Sure, but I'd like it to go in before 7.0. > > This seems to break my stuff > I will upgarde my stuff but that will take time and there are many > things ATM like STF deadline and teh release, i have 0 free time > > IMO you should announce droping support of compilers one release before > doing it so people have time to upgrade. As a compromise, we could start requiring C11 now, and C17 in 7.1. Or does anyone still care about compilers without even c11 support? -- 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 2/2] Require compilers to support C17.
Quoting Niklas Haas (2024-02-05 21:55:04) > On Mon, 05 Feb 2024 21:31:45 +0100 Anton Khirnov wrote: > > Quoting Michael Niedermayer (2024-02-05 21:27:27) > > > please wait a bit with applying this so we understand better what it > > > affects > > > > Sure, but I'd like it to go in before 7.0. > > What is the advantage to having it in 7.0? 7.0 is a "big" API breaking release, while 7.1 is supposed to be a smaller non-breaking release, so it seems better to put this kind of a change in the former rather than the latter. -- 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 2/2] Require compilers to support C17.
Quoting Devin Heitmueller (2024-02-05 21:40:43) > On Mon, Feb 5, 2024 at 3:31 PM Anton Khirnov wrote: > > > > Quoting Devin Heitmueller (2024-02-05 21:13:22) > > > On Mon, Feb 5, 2024 at 2:59 PM Anton Khirnov wrote: > > > > > > > > It should be available in all relevant modern compilers and will allow > > > > us to use features like anonymous unions. > > > > > > Is everybody on board with the implications for this patch in terms of > > > platforms we allow building on? For example, the gcc on Centos7 > > > doesn't support C17, and that isn't *that* old of a platform. > > > > According to Wikipedia, it's almost 10 years old. That counts as *that* > > old in my book. If someone really needs current ffmpeg on such a > > platform, they can still build their own compiler or cross-compile. > > Another way to look at it is that it's what all Centos users used > until Centos8 was shipped in September 2019 (i.e. less than five years > ago). > > Now I know that developers *LOVE* to use the latest whizbang language > features, Could we please not have these kinds of caricatures in here? It's not helpful. Not to mention anonymous unions were standardized in C11 and widely available for many years (possibly decades) before that, so it's hardly a 'latest whizbang feature'. > but there's a reason that many projects choose to have > relatively old minimum language versions. > > Now, again, if the developer community all agree that it makes sense > to stop supporting an operating system that was shipping as recently > as five years ago, then so be it. But this sort of deprecation > shouldn't simply be the result of a single developer deciding he wants > to use anonymous unions (or some other C17 feature) and thus we drop > support for a bunch of operating system versions. In case you missed it, I didn't just randomly send this out of the blue, it was discussed at the FOSDEM dev meeting (and before that on IRC and the ML) and literally nobody in the room was against moving to C11. -- 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/x86/vvc/vvcdsp_init: fix unresolved external symbol on ARCH_X86_32
Andreas Rheinhardt 于2024年2月5日周一 20:04写道：
> toq...@outlook.com:
> > From: Wu Jianhua
> >
> > Signed-off-by: Wu Jianhua
> > ---
> > libavcodec/x86/vvc/vvcdsp_init.c | 78
> > 1 file changed, 40 insertions(+), 38 deletions(-)
> >
> > diff --git a/libavcodec/x86/vvc/vvcdsp_init.c
> b/libavcodec/x86/vvc/vvcdsp_init.c
> > index 909ef9f56b..8ee4074350 100644
> > --- a/libavcodec/x86/vvc/vvcdsp_init.c
> > +++ b/libavcodec/x86/vvc/vvcdsp_init.c
> > @@ -31,6 +31,7 @@
> > #include "libavcodec/vvc/vvcdsp.h"
> > #include "libavcodec/x86/h26x/h2656dsp.h"
> >
> > +#if ARCH_X86_64
> > #define FW_PUT(name, depth, opt) \
> > static void ff_vvc_put_ ## name ## _ ## depth ## _##opt(int16_t *dst,
> const uint8_t *src, ptrdiff_t srcstride, \
> > int height, const
> int8_t *hf, const int8_t *vf, int width)\
> > @@ -204,51 +205,52 @@ AVG_FUNCS(16, 12, avx2)
> > c->inter.avg= bf(avg, bd, opt);
> \
> > c->inter.w_avg = bf(w_avg, bd, opt);
> \
> > } while (0)
> > +#endif
> >
> > void ff_vvc_dsp_init_x86(VVCDSPContext *const c, const int bd)
> > {
> > +#if ARCH_X86_64
> > const int cpu_flags = av_get_cpu_flags();
> >
> > -if (ARCH_X86_64) {
> > -if (bd == 8) {
> > -if (EXTERNAL_SSE4(cpu_flags)) {
> > -MC_LINK_SSE4(8);
> > -}
> > -if (EXTERNAL_AVX2_FAST(cpu_flags)) {
> > -MC_LINKS_AVX2(8);
> > -}
> > -} else if (bd == 10) {
> > -if (EXTERNAL_SSE4(cpu_flags)) {
> > -MC_LINK_SSE4(10);
> > -}
> > -if (EXTERNAL_AVX2_FAST(cpu_flags)) {
> > -MC_LINKS_AVX2(10);
> > -MC_LINKS_16BPC_AVX2(10);
> > -}
> > -} else if (bd == 12) {
> > -if (EXTERNAL_SSE4(cpu_flags)) {
> > -MC_LINK_SSE4(12);
> > -}
> > -if (EXTERNAL_AVX2_FAST(cpu_flags)) {
> > -MC_LINKS_AVX2(12);
> > -MC_LINKS_16BPC_AVX2(12);
> > -}
> > +if (bd == 8) {
> > +if (EXTERNAL_SSE4(cpu_flags)) {
> > +MC_LINK_SSE4(8);
> > }
> > +if (EXTERNAL_AVX2_FAST(cpu_flags)) {
> > +MC_LINKS_AVX2(8);
> > +}
> > +} else if (bd == 10) {
> > +if (EXTERNAL_SSE4(cpu_flags)) {
> > +MC_LINK_SSE4(10);
> > +}
> > +if (EXTERNAL_AVX2_FAST(cpu_flags)) {
> > +MC_LINKS_AVX2(10);
> > +MC_LINKS_16BPC_AVX2(10);
> > +}
> > +} else if (bd == 12) {
> > +if (EXTERNAL_SSE4(cpu_flags)) {
> > +MC_LINK_SSE4(12);
> > +}
> > +if (EXTERNAL_AVX2_FAST(cpu_flags)) {
> > +MC_LINKS_AVX2(12);
> > +MC_LINKS_16BPC_AVX2(12);
> > +}
> > +}
> >
> > -if (EXTERNAL_AVX2(cpu_flags)) {
> > -switch (bd) {
> > -case 8:
> > -AVG_INIT(8, avx2);
> > -break;
> > -case 10:
> > -AVG_INIT(10, avx2);
> > -break;
> > -case 12:
> > -AVG_INIT(12, avx2);
> > -break;
> > -default:
> > -break;
> > -}
> > +if (EXTERNAL_AVX2(cpu_flags)) {
> > +switch (bd) {
> > +case 8:
> > +AVG_INIT(8, avx2);
> > +break;
> > +case 10:
> > +AVG_INIT(10, avx2);
> > +break;
> > +case 12:
> > +AVG_INIT(12, avx2);
> > +break;
> > +default:
> > +break;
> > }
> > }
> > +#endif
> > }
>
> Are really all of these functions unavailable for 32bit?
>
> - Andreas
>
>
http://fate.ffmpeg.org/log.cgi?time=20240207055809=x86_32-msvc14-dll-md-windows-native=compile
___
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 0/2] Remove SDL2 output devices
> On Feb 7, 2024, at 04:51, Michael Koch wrote: > > I didn't notice any problems with -f sdl2. I just tested again with Windows > 11 and the latest FFmpeg build from Gyan, just 2 days old. > > ffmpeg -re -f lavfi -i testsrc2=s=800x600 -t 10 -f sdl2 - > > Works without any problems. It works until move or resize the window. As far as I know, it’s broken on Linux/macOS/Windows, so not “works without any problems”. SDL should be run in main thread, that’s all, although we can do render in separate thread with vulkan. It’s easy to create a video sink filter to do render, and setup a window on fftools/ffmpeg main thread, or implement the whole preview task just inside fftools. Not everyone agrees on the preview feature with ffmpeg, not to mention libSDL. > > Michael > > ___ > 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".
