[FFmpeg-devel] [PATCH v2.5 10/33] avcodec: remove FF_API_THREAD_SAFE_CALLBACKS

2023-02-06 Thread Anton Khirnov 
From: James Almer 

Signed-off-by: James Almer 
Signed-off-by: Anton Khirnov 
---
Sorry, picked the wrong patch version.
This one does build without pthreads.
---
 fftools/ffmpeg.c  |   5 -
 libavcodec/avcodec.h  |  21 ---
 libavcodec/decode.c   |  13 --
 libavcodec/encode.c   |   7 +-
 libavcodec/frame_thread_encoder.c |  20 ---
 libavcodec/pthread_frame.c| 237 +-
 libavcodec/thread.h   |  12 --
 libavcodec/utils.c|   5 -
 libavcodec/version_major.h|   1 -
 9 files changed, 6 insertions(+), 315 deletions(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 03e29e8834..80ca76ae04 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -2795,11 +2795,6 @@ static int init_input_stream(InputStream *ist, char 
*error, int error_len)
 
 ist->dec_ctx->opaque= ist;
 ist->dec_ctx->get_format= get_format;
-#if LIBAVCODEC_VERSION_MAJOR < 60
-AV_NOWARN_DEPRECATED({
-ist->dec_ctx->thread_safe_callbacks = 1;
-})
-#endif
 
 if (ist->dec_ctx->codec_id == AV_CODEC_ID_DVB_SUBTITLE &&
(ist->decoding_needed & DECODING_FOR_OST)) {
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 3884e52de9..22d7f50649 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1526,27 +1526,6 @@ typedef struct AVCodecContext {
  */
 int active_thread_type;
 
-#if FF_API_THREAD_SAFE_CALLBACKS
-/**
- * Set by the client if its custom get_buffer() callback can be called
- * synchronously from another thread, which allows faster multithreaded 
decoding.
- * draw_horiz_band() will be called from other threads regardless of this 
setting.
- * Ignored if the default get_buffer() is used.
- * - encoding: Set by user.
- * - decoding: Set by user.
- *
- * @deprecated the custom get_buffer2() callback should always be
- *   thread-safe. Thread-unsafe get_buffer2() implementations will be
- *   invalid starting with LIBAVCODEC_VERSION_MAJOR=60; in other words,
- *   libavcodec will behave as if this field was always set to 1.
- *   Callers that want to be forward compatible with future libavcodec
- *   versions should wrap access to this field in
- * `#if LIBAVCODEC_VERSION_MAJOR < 60`
- */
-attribute_deprecated
-int thread_safe_callbacks;
-#endif
-
 /**
  * The codec may call this to execute several independent things.
  * It will return only after finishing all tasks.
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 78bf3ba547..34e67a649b 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1604,19 +1604,6 @@ int ff_decode_preinit(AVCodecContext *avctx)
  * free the already allocated subtitle_header before overwriting it */
 av_freep(>subtitle_header);
 
-#if FF_API_THREAD_SAFE_CALLBACKS
-FF_DISABLE_DEPRECATION_WARNINGS
-if ((avctx->thread_type & FF_THREAD_FRAME) &&
-avctx->get_buffer2 != avcodec_default_get_buffer2 &&
-!avctx->thread_safe_callbacks) {
-av_log(avctx, AV_LOG_WARNING, "Requested frame threading with a "
-   "custom get_buffer2() implementation which is not marked as "
-   "thread safe. This is not supported anymore, make your "
-   "callback thread-safe.\n");
-}
-FF_ENABLE_DEPRECATION_WARNINGS
-#endif
-
 if (avctx->codec->max_lowres < avctx->lowres || avctx->lowres < 0) {
 av_log(avctx, AV_LOG_WARNING, "The maximum value for lowres supported 
by the decoder is %d\n",
avctx->codec->max_lowres);
diff --git a/libavcodec/encode.c b/libavcodec/encode.c
index b0a9625ca9..6499d962ca 100644
--- a/libavcodec/encode.c
+++ b/libavcodec/encode.c
@@ -259,10 +259,9 @@ int ff_encode_encode_cb(AVCodecContext *avctx, AVPacket 
*avpkt,
 unref:
 av_packet_unref(avpkt);
 }
-#if !FF_API_THREAD_SAFE_CALLBACKS
+
 if (frame)
 av_frame_unref(frame);
-#endif
 
 return ret;
 }
@@ -303,10 +302,6 @@ static int encode_simple_internal(AVCodecContext *avctx, 
AVPacket *avpkt)
 ret = ff_thread_video_encode_frame(avctx, avpkt, frame, _packet);
 else {
 ret = ff_encode_encode_cb(avctx, avpkt, frame, _packet);
-#if FF_API_THREAD_SAFE_CALLBACKS
-if (frame)
-av_frame_unref(frame);
-#endif
 }
 
 if (avci->draining && !got_packet)
diff --git a/libavcodec/frame_thread_encoder.c 
b/libavcodec/frame_thread_encoder.c
index 35775ae823..62d9580ad4 100644
--- a/libavcodec/frame_thread_encoder.c
+++ b/libavcodec/frame_thread_encoder.c
@@ -48,9 +48,6 @@ typedef struct{
 
 typedef struct{
 AVCodecContext *parent_avctx;
-#if FF_API_THREAD_SAFE_CALLBACKS
-pthread_mutex_t buffer_mutex;
-#endif
 
 pthread_mutex_t task_fifo_mutex; /* Used to guard (next_)task_index */
 pthread_cond_t task_fifo_cond;
@@ -70,15 +67,9 @@ typedef struct{
 }

[FFmpeg-devel] [PATCH v2 3/3] qsv: remove CONFIG_VAAPI

2023-02-06 Thread Tong Wu 
Make 8-bit, 10-bit, 12-bit YUV 4:2:2 video sources as well as YUV 4:4:4
video sources supported by d3d11va and dxva2 just like what VAAPI does.

Sign-off-by: Tong Wu 
---
 libavcodec/qsv.c  | 4 
 libavutil/hwcontext_qsv.c | 4 
 2 files changed, 8 deletions(-)

diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
index 7af154202c..8eabf46b45 100644
--- a/libavcodec/qsv.c
+++ b/libavcodec/qsv.c
@@ -208,7 +208,6 @@ enum AVPixelFormat ff_qsv_map_fourcc(uint32_t fourcc)
 case MFX_FOURCC_P8:   return AV_PIX_FMT_PAL8;
 case MFX_FOURCC_A2RGB10: return AV_PIX_FMT_X2RGB10;
 case MFX_FOURCC_RGB4: return AV_PIX_FMT_BGRA;
-#if CONFIG_VAAPI
 case MFX_FOURCC_YUY2: return AV_PIX_FMT_YUYV422;
 case MFX_FOURCC_Y210: return AV_PIX_FMT_Y210;
 case MFX_FOURCC_AYUV: return AV_PIX_FMT_VUYX;
@@ -217,7 +216,6 @@ enum AVPixelFormat ff_qsv_map_fourcc(uint32_t fourcc)
 case MFX_FOURCC_P016: return AV_PIX_FMT_P012;
 case MFX_FOURCC_Y216: return AV_PIX_FMT_Y212;
 case MFX_FOURCC_Y416: return AV_PIX_FMT_XV36;
-#endif
 #endif
 }
 return AV_PIX_FMT_NONE;
@@ -245,7 +243,6 @@ int ff_qsv_map_pixfmt(enum AVPixelFormat format, uint32_t 
*fourcc, uint16_t *shi
 *fourcc = MFX_FOURCC_RGB4;
 *shift = 0;
 return AV_PIX_FMT_BGRA;
-#if CONFIG_VAAPI
 case AV_PIX_FMT_YUV422P:
 case AV_PIX_FMT_YUYV422:
 *fourcc = MFX_FOURCC_YUY2;
@@ -277,7 +274,6 @@ int ff_qsv_map_pixfmt(enum AVPixelFormat format, uint32_t 
*fourcc, uint16_t *shi
 *fourcc = MFX_FOURCC_Y416;
 *shift = 1;
 return AV_PIX_FMT_XV36;
-#endif
 #endif
 default:
 return AVERROR(ENOSYS);
diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
index ec0f72b329..ba0ac8cda5 100644
--- a/libavutil/hwcontext_qsv.c
+++ b/libavutil/hwcontext_qsv.c
@@ -115,7 +115,6 @@ static const struct {
 { AV_PIX_FMT_BGRA, MFX_FOURCC_RGB4, 0 },
 { AV_PIX_FMT_P010, MFX_FOURCC_P010, 1 },
 { AV_PIX_FMT_PAL8, MFX_FOURCC_P8,   0 },
-#if CONFIG_VAAPI
 { AV_PIX_FMT_YUYV422,
MFX_FOURCC_YUY2, 0 },
 { AV_PIX_FMT_Y210,
@@ -142,7 +141,6 @@ static const struct {
 { AV_PIX_FMT_XV36,
MFX_FOURCC_Y416, 1 },
 #endif
-#endif
 };
 
 extern int ff_qsv_get_surface_base_handle(mfxFrameSurface1 *surf,
@@ -1524,7 +1522,6 @@ static int map_frame_to_surface(const AVFrame *frame, 
mfxFrameSurface1 *surface)
 surface->Data.R = frame->data[0] + 2;
 surface->Data.A = frame->data[0] + 3;
 break;
-#if CONFIG_VAAPI
 case AV_PIX_FMT_YUYV422:
 surface->Data.Y = frame->data[0];
 surface->Data.U = frame->data[0] + 1;
@@ -1556,7 +1553,6 @@ static int map_frame_to_surface(const AVFrame *frame, 
mfxFrameSurface1 *surface)
 // use the value from the frame.
 surface->Data.A = frame->data[0] + 6;
 break;
-#endif
 default:
 return MFX_ERR_UNSUPPORTED;
 }
-- 
2.39.1.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 v2 2/3] hwcontext_dxva2: add mutiple supported formats

2023-02-06 Thread Tong Wu 
Add support for VUYX, YUYV422, Y210, XV30, P012, Y212, XV36.
The added formats work with qsv acceleration and will not have
impact on dxva2 acceleration(-hwaccel dxva2) since so far
these formats are still not supported by using dxva2 acceleration.

Hwupload and hwdownload can work with the added formats.

Signed-off-by: Tong Wu 
---
 libavutil/hwcontext_dxva2.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/libavutil/hwcontext_dxva2.c b/libavutil/hwcontext_dxva2.c
index 53d00fa815..ea378df720 100644
--- a/libavutil/hwcontext_dxva2.c
+++ b/libavutil/hwcontext_dxva2.c
@@ -82,6 +82,13 @@ static const struct {
 } supported_formats[] = {
 { MKTAG('N', 'V', '1', '2'), AV_PIX_FMT_NV12 },
 { MKTAG('P', '0', '1', '0'), AV_PIX_FMT_P010 },
+{ MKTAG('A', 'Y', 'U', 'V'), AV_PIX_FMT_VUYX },
+{ MKTAG('Y', 'U', 'Y', '2'), AV_PIX_FMT_YUYV422 },
+{ MKTAG('Y', '2', '1', '0'), AV_PIX_FMT_Y210 },
+{ MKTAG('Y', '4', '1', '0'), AV_PIX_FMT_XV30 },
+{ MKTAG('P', '0', '1', '6'), AV_PIX_FMT_P012 },
+{ MKTAG('Y', '2', '1', '6'), AV_PIX_FMT_Y212 },
+{ MKTAG('Y', '4', '1', '6'), AV_PIX_FMT_XV36 },
 { D3DFMT_P8, AV_PIX_FMT_PAL8 },
 { D3DFMT_A8R8G8B8,   AV_PIX_FMT_BGRA },
 };
-- 
2.39.1.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 v2 1/3] hwcontext_d3d11va: add mutiple supported DXGI formats

2023-02-06 Thread Tong Wu 
Add support for VUYX, YUYV422, Y210, XV30, P012, Y212, XV36.

The added formats work with qsv acceleration and will not have
impact on d3d11va acceleration(-hwaccel d3d11va) since so far
these formats are still not supported by using d3d11va acceleration.

Hwupload and hwdownload can work with the added formats.

Signed-off-by: Tong Wu 
---
 libavutil/hwcontext_d3d11va.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index 363ec6a47d..aa50538d64 100644
--- a/libavutil/hwcontext_d3d11va.c
+++ b/libavutil/hwcontext_d3d11va.c
@@ -89,6 +89,13 @@ static const struct {
 { DXGI_FORMAT_B8G8R8A8_UNORM,AV_PIX_FMT_BGRA },
 { DXGI_FORMAT_R10G10B10A2_UNORM, AV_PIX_FMT_X2BGR10 },
 { DXGI_FORMAT_R16G16B16A16_FLOAT, AV_PIX_FMT_RGBAF16 },
+{ DXGI_FORMAT_AYUV, AV_PIX_FMT_VUYX },
+{ DXGI_FORMAT_YUY2, AV_PIX_FMT_YUYV422 },
+{ DXGI_FORMAT_Y210, AV_PIX_FMT_Y210 },
+{ DXGI_FORMAT_Y410, AV_PIX_FMT_XV30 },
+{ DXGI_FORMAT_P016, AV_PIX_FMT_P012 },
+{ DXGI_FORMAT_Y216, AV_PIX_FMT_Y212 },
+{ DXGI_FORMAT_Y416, AV_PIX_FMT_XV36 },
 // Special opaque formats. The pix_fmt is merely a place holder, as the
 // opaque format cannot be accessed directly.
 { DXGI_FORMAT_420_OPAQUE,   AV_PIX_FMT_YUV420P },
-- 
2.39.1.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/3] hwcontext_dxva2: add mutiple supported formats

2023-02-06 Thread Xiang, Haihao 
On Di, 2023-01-31 at 16:41 +0800, Tong Wu wrote:
> Add support for VUYX, YUYV422, Y210, XV30, P012, Y212, XV36.
> The added formats work with qsv acceleration and will not have
> impact on dxva2 acceleration(-hwaccel dxva2) since so far
> these formats are still not supported by using dxva2 acceleration.

hwupload and hwdownload can work with the added formats, please update the
commit log. 

Thanks
Haihao

> 
> Signed-off-by: Tong Wu 
> ---
>  libavutil/hwcontext_dxva2.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/libavutil/hwcontext_dxva2.c b/libavutil/hwcontext_dxva2.c
> index 53d00fa815..ea378df720 100644
> --- a/libavutil/hwcontext_dxva2.c
> +++ b/libavutil/hwcontext_dxva2.c
> @@ -82,6 +82,13 @@ static const struct {
>  } supported_formats[] = {
>  { MKTAG('N', 'V', '1', '2'), AV_PIX_FMT_NV12 },
>  { MKTAG('P', '0', '1', '0'), AV_PIX_FMT_P010 },
> +{ MKTAG('A', 'Y', 'U', 'V'), AV_PIX_FMT_VUYX },
> +{ MKTAG('Y', 'U', 'Y', '2'), AV_PIX_FMT_YUYV422 },
> +{ MKTAG('Y', '2', '1', '0'), AV_PIX_FMT_Y210 },
> +{ MKTAG('Y', '4', '1', '0'), AV_PIX_FMT_XV30 },
> +{ MKTAG('P', '0', '1', '6'), AV_PIX_FMT_P012 },
> +{ MKTAG('Y', '2', '1', '6'), AV_PIX_FMT_Y212 },
> +{ MKTAG('Y', '4', '1', '6'), AV_PIX_FMT_XV36 },
>  { D3DFMT_P8, AV_PIX_FMT_PAL8 },
>  { D3DFMT_A8R8G8B8,   AV_PIX_FMT_BGRA },
>  };
___
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/3] hwcontext_d3d11va: add mutiple supported DXGI formats

2023-02-06 Thread Xiang, Haihao 
On Di, 2023-01-31 at 16:41 +0800, Tong Wu wrote:
> Add support for VUYX, YUYV422, Y210, XV30, P012, Y212, XV36.
> 
> The added formats work with qsv acceleration and will not have
> impact on d3d11va acceleration(-hwaccel d3d11va) since so far
> these formats are still not supported by using d3d11va acceleration.

hwupload and hwdownload can work with the added formats. 

Thanks
Haihao

> 
> Signed-off-by: Tong Wu 
> ---
>  libavutil/hwcontext_d3d11va.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
> index 363ec6a47d..aa50538d64 100644
> --- a/libavutil/hwcontext_d3d11va.c
> +++ b/libavutil/hwcontext_d3d11va.c
> @@ -89,6 +89,13 @@ static const struct {
>  { DXGI_FORMAT_B8G8R8A8_UNORM,AV_PIX_FMT_BGRA },
>  { DXGI_FORMAT_R10G10B10A2_UNORM, AV_PIX_FMT_X2BGR10 },
>  { DXGI_FORMAT_R16G16B16A16_FLOAT, AV_PIX_FMT_RGBAF16 },
> +{ DXGI_FORMAT_AYUV, AV_PIX_FMT_VUYX },
> +{ DXGI_FORMAT_YUY2, AV_PIX_FMT_YUYV422 },
> +{ DXGI_FORMAT_Y210, AV_PIX_FMT_Y210 },
> +{ DXGI_FORMAT_Y410, AV_PIX_FMT_XV30 },
> +{ DXGI_FORMAT_P016, AV_PIX_FMT_P012 },
> +{ DXGI_FORMAT_Y216, AV_PIX_FMT_Y212 },
> +{ DXGI_FORMAT_Y416, AV_PIX_FMT_XV36 },
>  // Special opaque formats. The pix_fmt is merely a place holder, as the
>  // opaque format cannot be accessed directly.
>  { DXGI_FORMAT_420_OPAQUE,   AV_PIX_FMT_YUV420P },
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/2] avfilter: add QSV variants of the stack filters

2023-02-06 Thread Xiang, Haihao 
From: Haihao Xiang 

Include hstack_qsv, vstack_qsv and xstack_qsv. They may accept input
streams with different sizes.

Examples:
$ ffmpeg -hwaccel qsv -hwaccel_output_format qsv -i input.mp4 \
-filter_complex "[0:v][0:v]hstack_qsv" -f null -

$ ffmpeg \
-hwaccel qsv -hwaccel_output_format qsv -i input.mp4 \
-hwaccel qsv -hwaccel_output_format qsv -i input.mp4 \
-hwaccel qsv -hwaccel_output_format qsv -i input.mp4 \
-hwaccel qsv -hwaccel_output_format qsv -i input.mp4 \
-filter_complex 
"[0:v][1:v][2:v][3:v]xstack_qsv=inputs=4:fill=0x00:layout=0_0_1920x1080|w0_0_1920x1080|0_h0_1920x1080|w0_h0_1920x1080"
 \
-f null -

Signed-off-by: Haihao Xiang 
---
 Changelog  |   1 +
 configure  |   6 +
 doc/filters.texi   |  88 +
 libavfilter/Makefile   |   3 +
 libavfilter/allfilters.c   |   3 +
 libavfilter/version.h  |   2 +-
 libavfilter/vf_stack_qsv.c | 254 +
 7 files changed, 356 insertions(+), 1 deletion(-)
 create mode 100644 libavfilter/vf_stack_qsv.c

diff --git a/Changelog b/Changelog
index df9cd69da2..8955934c59 100644
--- a/Changelog
+++ b/Changelog
@@ -39,6 +39,7 @@ version :
 - ffmpeg CLI new option: -fix_sub_duration_heartbeat
 - WavArc decoder and demuxer
 - CrystalHD decoders deprecated
+- hstack_qsv, vstack_qsv and xstack_qsv filters
 
 
 version 5.1:
diff --git a/configure b/configure
index d67855c729..1d535ab425 100755
--- a/configure
+++ b/configure
@@ -3772,6 +3772,12 @@ yadif_videotoolbox_filter_deps="metal corevideo 
videotoolbox"
 hstack_vaapi_filter_deps="vaapi_1"
 vstack_vaapi_filter_deps="vaapi_1"
 xstack_vaapi_filter_deps="vaapi_1"
+hstack_qsv_filter_deps="libmfx"
+hstack_qsv_filter_select="qsvvpp"
+vstack_qsv_filter_deps="libmfx"
+vstack_qsv_filter_select="qsvvpp"
+xstack_qsv_filter_deps="libmfx"
+xstack_qsv_filter_select="qsvvpp"
 
 # examples
 avio_list_dir_deps="avformat avutil"
diff --git a/doc/filters.texi b/doc/filters.texi
index 3a54c68f3e..43c77dc041 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -26772,6 +26772,94 @@ See @ref{xstack}.
 
 @c man end VAAPI VIDEO FILTERS
 
+@chapter QSV Video Filters
+@c man begin QSV VIDEO FILTERS
+
+Below is a description of the currently available QSV video filters.
+
+To enable compilation of these filters you need to configure FFmpeg with
+@code{--enable-libmfx} or @code{--enable-libvpl}.
+
+To use QSV filters, you need to setup the QSV device correctly. For more 
information, please read @url{https://trac.ffmpeg.org/wiki/Hardware/QuickSync}
+
+@section hstack_qsv
+Stack input videos horizontally.
+
+This is the QSV variant of the @ref{hstack} filter, each input stream may
+have different height, this filter will scale down/up each input stream while
+keeping the orignal aspect.
+
+It accepts the following options:
+
+@table @option
+@item inputs
+See @ref{hstack}.
+
+@item shortest
+See @ref{hstack}.
+
+@item height
+Set height of output. If set to 0, this filter will set height of output to
+height of the first input stream. Default value is 0.
+@end table
+
+@section vstack_qsv
+Stack input videos vertically.
+
+This is the QSV variant of the @ref{vstack} filter, each input stream may
+have different width, this filter will scale down/up each input stream while
+keeping the orignal aspect.
+
+It accepts the following options:
+
+@table @option
+@item inputs
+See @ref{vstack}.
+
+@item shortest
+See @ref{vstack}.
+
+@item width
+Set width of output. If set to 0, this filter will set width of output to
+width of the first input stream. Default value is 0.
+@end table
+
+@section xstack_qsv
+Stack video inputs into custom layout.
+
+This is the QSV variant of the @ref{xstack} filter.
+
+It accepts the following options:
+
+@table @option
+@item inputs
+See @ref{xstack}.
+
+@item shortest
+See @ref{xstack}.
+
+@item layout
+See @ref{xstack}.
+Moreover, this permits the user to supply output size for each input stream.
+@example
+xstack_qsv=inputs=4:layout=0_0_1920x1080|0_h0_1920x1080|w0_0_1920x1080|w0_h0_1920x1080
+@end example
+
+@item grid
+See @ref{xstack}.
+
+@item grid_tile_size
+Set output size for each input stream when @option{grid} is set. If this option
+is not set, this filter will set output size by default to the size of the
+first input stream. For the syntax of this option, check the
+@ref{video size syntax,,"Video size" section in the ffmpeg-utils 
manual,ffmpeg-utils}.
+
+@item fill
+See @ref{xstack}.
+@end table
+
+@c man end QSV VIDEO FILTERS
+
 @chapter Video Sources
 @c man begin VIDEO SOURCES
 
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 0173b11870..b3d3d981dd 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -561,6 +561,9 @@ OBJS-$(CONFIG_ZSCALE_FILTER) += vf_zscale.o
 OBJS-$(CONFIG_HSTACK_VAAPI_FILTER)   += vf_stack_vaapi.o framesync.o 
vaapi_vpp.o
 OBJS-$(CONFIG_VSTACK_VAAPI_FILTER)   += vf_stack_vaapi.o framesync.o 
vaapi_vpp.o

[FFmpeg-devel] [PATCH 1/2] lavfi/vf_stack_vaapi: factor out the common code for stack setting

2023-02-06 Thread Xiang, Haihao 
From: Haihao Xiang 

The common code will be used in QSV based stack filters.

Signed-off-by: Haihao Xiang 
---
 libavfilter/stack_internal.c | 355 +++
 libavfilter/stack_internal.h |  60 ++
 libavfilter/vf_stack_vaapi.c | 395 ---
 3 files changed, 452 insertions(+), 358 deletions(-)
 create mode 100644 libavfilter/stack_internal.c
 create mode 100644 libavfilter/stack_internal.h

diff --git a/libavfilter/stack_internal.c b/libavfilter/stack_internal.c
new file mode 100644
index 00..57661e1c97
--- /dev/null
+++ b/libavfilter/stack_internal.c
@@ -0,0 +1,355 @@
+/*
+ * 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
+ */
+
+#define OFFSET(x) offsetof(StackHWContext, x)
+#define FLAGS (AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_FILTERING_PARAM)
+
+#define SET_OUTPUT_REGION(region, rx, ry, rw, rh) do {  \
+region->x = rx; \
+region->y = ry; \
+region->width = rw; \
+region->height = rh;\
+} while (0)
+
+static int init_framesync(AVFilterContext *avctx)
+{
+StackBaseContext *sctx = avctx->priv;
+int ret;
+
+ret = ff_framesync_init(>fs, avctx, avctx->nb_inputs);
+if (ret < 0)
+return ret;
+
+sctx->fs.on_event = process_frame;
+sctx->fs.opaque = sctx;
+
+for (int i = 0; i < sctx->nb_inputs; i++) {
+FFFrameSyncIn *in = >fs.in[i];
+
+in->before = EXT_STOP;
+in->after = sctx->shortest ? EXT_STOP : EXT_INFINITY;
+in->sync = 1;
+in->time_base = avctx->inputs[i]->time_base;
+}
+
+return ff_framesync_configure(>fs);
+}
+
+static int config_comm_output(AVFilterLink *outlink)
+{
+AVFilterContext *avctx = outlink->src;
+StackBaseContext *sctx = avctx->priv;
+AVFilterLink *inlink0 = avctx->inputs[0];
+int width, height, ret;
+
+if (sctx->mode == STACK_H) {
+height = sctx->tile_height;
+width = 0;
+
+if (!height)
+height = inlink0->h;
+
+for (int i = 0; i < sctx->nb_inputs; i++) {
+AVFilterLink *inlink = avctx->inputs[i];
+StackItemRegion *region = >regions[i];
+
+SET_OUTPUT_REGION(region, width, 0, av_rescale(height, inlink->w, 
inlink->h), height);
+width += av_rescale(height, inlink->w, inlink->h);
+}
+} else if (sctx->mode == STACK_V) {
+height = 0;
+width = sctx->tile_width;
+
+if (!width)
+width = inlink0->w;
+
+for (int i = 0; i < sctx->nb_inputs; i++) {
+AVFilterLink *inlink = avctx->inputs[i];
+StackItemRegion *region = >regions[i];
+
+SET_OUTPUT_REGION(region, 0, height, width, av_rescale(width, 
inlink->h, inlink->w));
+height += av_rescale(width, inlink->h, inlink->w);
+}
+} else if (sctx->nb_grid_rows && sctx->nb_grid_columns) {
+int xpos = 0, ypos = 0;
+int ow, oh, k = 0;
+
+ow = sctx->tile_width;
+oh = sctx->tile_height;
+
+if (!ow || !oh) {
+ow = avctx->inputs[0]->w;
+oh = avctx->inputs[0]->h;
+}
+
+for (int i = 0; i < sctx->nb_grid_columns; i++) {
+ypos = 0;
+
+for (int j = 0; j < sctx->nb_grid_rows; j++) {
+StackItemRegion *region = >regions[k++];
+
+SET_OUTPUT_REGION(region, xpos, ypos, ow, oh);
+ypos += oh;
+}
+
+xpos += ow;
+}
+
+width = ow * sctx->nb_grid_columns;
+height = oh * sctx->nb_grid_rows;
+} else {
+char *arg, *p = sctx->layout, *saveptr = NULL;
+char *arg2, *p2, *saveptr2 = NULL;
+char *arg3, *p3, *saveptr3 = NULL;
+int xpos, ypos, size;
+int ow, oh;
+
+width = avctx->inputs[0]->w;
+height = avctx->inputs[0]->h;
+
+for (int i = 0; i < sctx->nb_inputs; i++) {
+AVFilterLink *inlink = avctx->inputs[i];
+StackItemRegion *region = >regions[i];
+
+ow = inlink->w;
+oh = inlink->h;
+
+if (!(arg = av_strtok(p, "|", )))
+return

Re: [FFmpeg-devel] [PATCH] MAINTAINERS: add a separate list for those with push access

2023-02-06 Thread Steven Liu 


> 2023年1月30日 12:22，Stephen Hutchinson  写道：
> 
> On 1/29/23 10:59 PM, Gyan Doshi wrote:
>> On 2023-01-30 09:14 am, Leo Izen wrote:
>>> 
>>> 
>>> On 1/29/23 18:14, Lynne wrote:
 Dec 18, 2022, 07:31 by d...@lynne.ee:
 
 Pushing this in 3 days unless anyone objects.
 ___
>>> 
>>> I recently gained push access. I don't object to this commit as-is, 
>>> although if you can change it to include my name as well that'd be 
>>> appreciated.
>> Mine too.
> 
> Ditto.
Ditto.

Thanks

Steven Liu

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/flvenc: fix EOS tag

2023-02-06 Thread Steven Liu 


> 2023年2月7日 05:25，Zhao Zhili  写道：
> 
> From: Zhao Zhili 
> 
> FLV spec only has AVC end of sequence tag, and the EOS tag has a
> CodecID as other video data packet. MPEG4 doesn't conformance to
> the spec, but it's there for a decade. So only 'fix' the EOS tag
> rather than remove it completely.
> 
> Signed-off-by: Zhao Zhili 
> ---
> libavformat/flvenc.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
> index 128ae8ebc0..8830c03044 100644
> --- a/libavformat/flvenc.c
> +++ b/libavformat/flvenc.c
> @@ -235,13 +235,16 @@ static void put_timestamp(AVIOContext *pb, int64_t ts) {
> avio_w8(pb, (ts >> 24) & 0x7F);
> }
> 
> -static void put_avc_eos_tag(AVIOContext *pb, unsigned ts)
> +static void put_eos_tag(AVIOContext *pb, unsigned ts, enum AVCodecID 
> codec_id)
> {
> +uint32_t tag = ff_codec_get_tag(flv_video_codec_ids, codec_id);
> +/* ub[4] FrameType = 1, ub[4] CodecId */
> +tag |= 1 << 4;
> avio_w8(pb, FLV_TAG_TYPE_VIDEO);
> avio_wb24(pb, 5);   /* Tag Data Size */
> put_timestamp(pb, ts);
> avio_wb24(pb, 0);   /* StreamId = 0 */
> -avio_w8(pb, 23);/* ub[4] FrameType = 1, ub[4] CodecId = 
> 7 */
> +avio_w8(pb, tag);
> avio_w8(pb, 2); /* AVC end of sequence */
> avio_wb24(pb, 0);   /* Always 0 for AVC EOS. */
> avio_wb32(pb, 16);  /* Size of FLV tag */
> @@ -783,7 +786,7 @@ end:
> FLVStreamContext *sc = s->streams[i]->priv_data;
> if (par->codec_type == AVMEDIA_TYPE_VIDEO &&
> (par->codec_id == AV_CODEC_ID_H264 || par->codec_id == 
> AV_CODEC_ID_MPEG4))
> -put_avc_eos_tag(pb, sc->last_ts);
> +put_eos_tag(pb, sc->last_ts, par->codec_id);
> }
> }
> 
> -- 
> 2.25.1
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> 

LGTM


Thanks

Steven Liu

___
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] MAINTAINERS: add a separate list for those with push access

2023-02-06 Thread Michael Niedermayer 
On Mon, Feb 06, 2023 at 02:49:19PM +, Derek Buitenhuis wrote:
> On 2/6/2023 12:10 PM, Lynne wrote:
> > At the FOSDEM meeting yesterday, everyone there agreed that while it's not
> > perfect, it's a step in the right direction, and we should merge this.
> 
> (I have no opinion re: merging.)
> 
> Is it not possible to audit/list who has git push access instead of guessing?

I will send you (and any other developer who wants) the list of git user names
who have write access

I am slightly hesitant to post this list publically as its not really what
people want and posting any username lists may have other "uses"
Also there are people in this list who have not been active in ffmpeg git
and iam not sure if they agree to be listed publically

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If the United States is serious about tackling the national security threats 
related to an insecure 5G network, it needs to rethink the extent to which it
values corporate profits and government espionage over security.-Bruce Schneier


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] MAINTAINERS: add a separate list for those with push access

2023-02-06 Thread Michael Niedermayer 
On Mon, Feb 06, 2023 at 01:10:06PM +0100, Lynne wrote:
> Jan 30, 2023, 20:03 by d...@lynne.ee:
> 
> > Jan 30, 2023, 17:49 by mich...@niedermayer.cc:
> >
> >> On Thu, Dec 15, 2022 at 02:13:49AM +0100, Lynne wrote:
> >>
> >>> This list is incomplete, and just contains those I could see
> >>> while looking at the recent git log. If it looks like I've forgotten you, 
> >>> I definitely haven't!
> >>> We may complete the list at a later date.
> >>>
> >>> This makes it such that those who add themselves to MAINTAINERS do not
> >>> get push access by default, but rather, they have to request it
> >>> explicitly in a different commit. This used to be the situation
> >>> before it was changed at the start of this year and is pretty much what
> >>> everyone expects.
> >>>
> >>> Patch attached.
> >>>
> >>> MAINTAINERS |   15 +++
> >>> 1 file changed, 15 insertions(+)
> >>> 6a083061d75f6655771bde377f96aadad19b21c6  
> >>> 0001-MAINTAINERS-add-a-separate-list-for-those-with-push-.patch
> >>> From 5c353412a25fd46c5077e5cf92ddfd6532eb46cb Mon Sep 17 00:00:00 2001
> >>> From: Lynne 
> >>> Date: Thu, 15 Dec 2022 02:05:00 +0100
> >>> Subject: [PATCH] MAINTAINERS: add a separate list for those with push 
> >>> access
> >>>
> >>> This list is incomplete, and just contains those I could remember
> >>> while looking at the recent git log.
> >>> We may complete the list at a later date.
> >>>
> >>> This makes it such that those who add themselves to MAINTAINERS do not
> >>> get push access by default, but rather, they have to request it
> >>> explicitly in a different commit. This used to be the situation
> >>> before it was changed at the start of this year.
> >>>
> >>
> >> I dont object to you adding a list of people with commit acccess though i
> >> dont think its needed or that useful.
> >> But adding a list that is incomplete, sorted in a odd way and doing so in a
> >> commit that states a past rule which i dont think was true, seems not
> >> ideal
> >>
> >> ATM there are I think 117 keys that have write access (some may belong to
> >> the same developers) and also over 100 maintainers in that MAINTAINERs file
> >> I think. I didnt try to count them too precisely. But the numbers are not
> >> that disimilar. The added list is quite abit more different
> >>
> >
> > My intention was to make this complete after it's accepted (or not, if
> > someone doesn't want to be known for having push access).
> >
> >
> >> Also iam not sure this commit will change that much. People who do not want
> >> write access neither before nor afterwards will not send a ssh key so wont 
> >> get
> >> write access. And people who want write access will push for it and
> >> probably noone will object. Theres the between people who dont push for
> >> it and noone else would push either they might no longer receive write
> >> access. Iam not sure if that is better.
> >>
> >> It makes things more involved but whats really bad is that this extra
> >> step is mainly in your mind, its not docuemnted.
> >> Do i add someone to that new list when i give him write access or do
> >> i give someone write access when a patch adding her is approved. Or do
> >> i just ignore that list because its incomplete anyway ?
> >>
> >> I assume the intend is the 2nd one but How would a contributor know
> >> to add herself to that list and what about people who are quite humble
> >> and who would not push for it yet at the same time would benefit from
> >> write access ?
> >>
> >
> > How would anyone know to maintain something they should add themselves
> > to the list of maintainers?
> > A second list of those with push access doesn't add more roadblocks, it's
> > just a separate list, that's all. You wouldn't have to add yourself to 
> > maintainers
> > to get push access if you don't want to.
> > As for those humble, I do see your point, but it's a one-line diff change,
> > and it can be done in the same commit adding yourself to maintainers,
> > it's not a 2-page personal statement about values.
> >
> >
> >> ATM every maintainer automatically receives the right for write access
> >> After this patch its made more difficult, i cant just post a patch adding
> >> random people either Someone would have to convince them first that they
> >> should post a patch to add themselfs. 
> >>
> >> So what i really dislike on this change is the potential stumbling blocks
> >> it throws before new developers.
> >>
> >> Its important that one has write access to the repository one works in
> >> In FFmpeg that work happens on git master so write access to that is
> >> important for anyone actively working on it.
> >> In other places work and review might happen in developers own repositories
> >> and they get merged regularly. In that case write access to master is not 
> >> needed
> >>
> 
> At the FOSDEM meeting yesterday, everyone there agreed that while it's not
> perfect, it's a step in the right direction, and we should merge this.

Well, i was not there and i do not know

Re: [FFmpeg-devel] Request for assistance with adding new pixel format (NV12_8L128) in FFmpeg

2023-02-06 Thread Kieran Kunhya 
On Mon, 6 Feb 2023 at 15:43, Le Bao Tin Ha 
wrote:

> I hope this email finds you well. I am currently working on the Toradex
> Apalis iMX8QM board and I am trying to perform a hardware decode using the
> Amphion driver with ffmpeg h264_v4l2m2m codec. The decoder outputs a pixel
> format (NV12_8L128, a linear 8x128 NV12 based tiles) that is not supported
> yet by FFmpeg.
>

Hello,

Are you able to provide more information about this nonstandard pixel
format?

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] [PATCH] ffmpeg_opt: move help text for -ab/-b:a to audio category

2023-02-06 Thread Marth64 
Since at least 4.4.3, -ab/-b:a help text was in the video section
of ffmpeg -h, but these are audio options.

Signed-off-by: Marth64 
---
 fftools/ffmpeg_opt.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 204be38c94..799dcf071e 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -1637,8 +1637,6 @@ const OptionDef options[] = {
 { "force_key_frames", OPT_VIDEO | OPT_STRING | HAS_ARG | OPT_EXPERT |
   OPT_SPEC | OPT_OUTPUT,   
  { .off = OFFSET(forced_key_frames) },
 "force key frames at specified timestamps", "timestamps" },
-{ "ab",   OPT_VIDEO | HAS_ARG | OPT_PERFILE | OPT_OUTPUT,  
  { .func_arg = opt_bitrate },
-"audio bitrate (please use -b:a)", "bitrate" },
 { "b",OPT_VIDEO | HAS_ARG | OPT_PERFILE | OPT_OUTPUT,  
  { .func_arg = opt_bitrate },
 "video bitrate (please use -b:v)", "bitrate" },
 { "hwaccel",  OPT_VIDEO | OPT_STRING | HAS_ARG | OPT_EXPERT |
@@ -1680,6 +1678,8 @@ const OptionDef options[] = {
 { "acodec", OPT_AUDIO | HAS_ARG  | OPT_PERFILE |
 OPT_INPUT | OPT_OUTPUT,
{ .func_arg = opt_audio_codec },
 "force audio codec ('copy' to copy stream)", "codec" },
+{ "ab", OPT_AUDIO | HAS_ARG | OPT_PERFILE | OPT_OUTPUT,
{ .func_arg = opt_bitrate },
+"audio bitrate (please use -b:a)", "bitrate" },
 { "atag",   OPT_AUDIO | HAS_ARG  | OPT_EXPERT | OPT_PERFILE |
 OPT_OUTPUT,
{ .func_arg = opt_old2new },
 "force audio tag/fourcc", "fourcc/tag" },
-- 
2.25.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] Request for assistance with adding new pixel format (NV12_8L128) in FFmpeg

2023-02-06 Thread Le Bao Tin Ha 
Dear FFmpeg Community,

I hope this email finds you well. I am currently working on the Toradex Apalis 
iMX8QM board and I am trying to perform a hardware decode using the Amphion 
driver with ffmpeg h264_v4l2m2m codec. The decoder outputs a pixel format 
(NV12_8L128, a linear 8x128 NV12 based tiles) that is not supported yet by 
FFmpeg.

I attempted to add this new pixel format to FFmpeg by adding only the DEFINES 
which are similar to the classical NV12 (or NV12M), but it doesn't seem to be 
working as expected. I was wondering if you could help me with this issue. 
Could you provide me with some guidance on how to proceed and make sure that it 
works correctly? Or could you provide me an other alternative to simplify this?

Any help would be greatly appreciated. Thank you for your time.

Best regards,
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/2 v2] lavfi/vf_colorspace: Add SMPTE ST 2084 support

2023-02-06 Thread Tomas Härdin 
Here's a version of this patch with options for specifying input and
output nits. 32-bit LUTs would make this situation better if
vf_colorspace tracked nits internally. 32-bit would only be necessary
when dealing with HDR. That way SDR colorspace conversion can still use
the 16-bit SIMD.

/Tomas
From c63beb4581bcd3140e122b7a7c5b4a53ae35ec29 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?= 
Date: Fri, 3 Feb 2023 14:00:38 +0100
Subject: [PATCH 2/2] lavfi/vf_colorspace: Add SMPTE ST 2084 support
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Also adds inits and onits options for specifying what 28672
means in terms of nits (cd/m²).
---
 doc/filters.texi| 30 
 libavfilter/vf_colorspace.c | 39 +++--
 2 files changed, 67 insertions(+), 2 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 3a54c68f3e..26d9dfe54b 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -9839,6 +9839,10 @@ BT.2020 for 10-bits content
 @item bt2020-12
 BT.2020 for 12-bits content
 
+@anchor{smpte2084}
+@item smpte2084
+SMPTE ST 2084 (perceptual quantizer) used by BT.2100. See @ref{inits} and @ref{onits}.
+
 @end table
 
 @anchor{primaries}
@@ -9980,6 +9984,32 @@ Override input transfer characteristics. Same accepted values as @ref{trc}.
 @item irange
 Override input color range. Same accepted values as @ref{range}.
 
+@anchor{inits}
+@item inits
+Required when input trc is @ref{smpte2084}.
+Specifies what the peak intermediate level should correspond to in nits (cd/m²).
+Perceptually dequantized values get scaled and clipped so that the range [0,inits] fits in the filter's internal psuedo-restricted 15-bit format.
+For inits < 1 this corresponds to clipping of values outside the [0,inits]³ RGB cube.
+For inits = 1 values are not clipped, but values in the lower range will get truncated to zero due to the internal format's limited range.
+
+With BT.2100 input basic usage is:
+@example
+colorspace=bt709:inits=100
+@end example
+which clips HDR to SDR in BT.709 colorspace.
+
+A more advanced use case is as follows:
+@example
+colorspace=bt709:inits=1:trc=linear:format=yuv444p16,tonemap=hable:peak=0.01
+@end example
+which with BT.2100 input performs very basic tonemapping.
+
+@anchor{onits}
+@item onits
+Used in combination with @ref{smpte2084}, defaults to 1.
+Similar to @ref{inits} but in reverse.
+Specifies how to treat the peak intermediate level in nits (cd/m²) prior to perceptual quantization (PQ) as per SMPTE ST 2084.
+
 @end table
 
 The filter converts the transfer characteristics, color space and color
diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
index 1e1ab5fb34..996c5f4e25 100644
--- a/libavfilter/vf_colorspace.c
+++ b/libavfilter/vf_colorspace.c
@@ -118,6 +118,7 @@ typedef struct ColorSpaceContext {
 enum AVColorTransferCharacteristic in_trc, out_trc, user_trc, user_itrc;
 enum AVColorPrimaries in_prm, out_prm, user_prm, user_iprm;
 enum AVPixelFormat in_format, user_format;
+double user_inits, user_onits;
 int fast_mode;
 enum DitherMode dither;
 enum WhitepointAdaptation wp_adapt;
@@ -173,6 +174,7 @@ static const struct TransferCharacteristics transfer_characteristics[AVCOL_TRC_N
 [AVCOL_TRC_IEC61966_2_4] = { 1.099, 0.018, 0.45, 4.5 },
 [AVCOL_TRC_BT2020_10] = { 1.099,  0.018,  0.45, 4.5 },
 [AVCOL_TRC_BT2020_12] = { 1.0993, 0.0181, 0.45, 4.5 },
+[AVCOL_TRC_SMPTE2084] = { 1.0,0,  0,0 }, // fake entry, actual TRC uses entirely separate formula
 };
 
 static const struct TransferCharacteristics *
@@ -197,6 +199,9 @@ static int fill_gamma_table(ColorSpaceContext *s)
 double in_ialpha = 1.0 / in_alpha, in_igamma = 1.0 / in_gamma, in_idelta = 1.0 / in_delta;
 double out_alpha = s->out_txchr->alpha, out_beta = s->out_txchr->beta;
 double out_gamma = s->out_txchr->gamma, out_delta = s->out_txchr->delta;
+double m1 = 1305.0/8192, m2 = 2523.0/32, c2 = 2413.0/128, c3 = 2392.0/128, c1 = c3 - c2 + 1;
+double im1 = 1.0 / m1, im2 = 1.0 / m2;
+double iscale = 1.0 / s->user_inits, ioscale = s->user_onits / 1.0;
 
 s->lin_lut = av_malloc(sizeof(*s->lin_lut) * 32768 * 2);
 if (!s->lin_lut)
@@ -206,7 +211,15 @@ static int fill_gamma_table(ColorSpaceContext *s)
 double v = (n - 2048.0) / 28672.0, d, l;
 
 // delinearize
-if (v <= -out_beta) {
+if (s->out_trc == AVCOL_TRC_SMPTE2084) {
+// see BT.2100-2
+if (v >= 0) {
+double vm1 = pow(v * ioscale, m1);
+d = pow((c1 + c2 * vm1)/(1 + c3 * vm1), m2);
+} else {
+d = 0;
+}
+} else if (v <= -out_beta) {
 d = -out_alpha * pow(-v, out_gamma) + (out_alpha - 1.0);
 } else if (v < out_beta) {
 d = out_delta * v;
@@ -216,7 +229,19 @@ static int

Re: [FFmpeg-devel] [PATCH] MAINTAINERS: add a separate list for those with push access

2023-02-06 Thread Derek Buitenhuis 
On 2/6/2023 12:10 PM, Lynne wrote:
> At the FOSDEM meeting yesterday, everyone there agreed that while it's not
> perfect, it's a step in the right direction, and we should merge this.

(I have no opinion re: merging.)

Is it not possible to audit/list who has git push access instead of guessing?

This kind of comes back to what we discussed at the December dev meeting - 
we don't even know who has access to our infra... that is insane.

- 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] [PATCH] avfilter: use ff_inlink_make_frame_writable()

2023-02-06 Thread Nicolas George 
Paul B Mahol (12023-02-06):
> Patch attached.

> From 8d2d4d35a54d0a3ddf300ef7196489898c3efc4e Mon Sep 17 00:00:00 2001
> From: Paul B Mahol 
> Date: Mon, 6 Feb 2023 14:57:50 +0100
> Subject: [PATCH] avfilter: use ff_inlink_make_frame_writable()
> 
> Signed-off-by: Paul B Mahol 
> ---
>  libavfilter/avf_abitscope.c   | 11 +--
>  libavfilter/avf_ahistogram.c  |  9 +++--
>  libavfilter/avf_aphasemeter.c |  9 +++--
>  libavfilter/avf_avectorscope.c|  7 ++-
>  libavfilter/avf_showspectrum.c|  5 -
>  libavfilter/avf_showvolume.c  |  6 --
>  libavfilter/f_ebur128.c   | 10 --
>  libavfilter/f_perms.c |  3 ++-
>  libavfilter/framesync.c   |  2 +-
>  libavfilter/vf_cover_rect.c   |  7 +--
>  libavfilter/vf_dedot.c|  2 +-
>  libavfilter/vf_floodfill.c|  3 ++-
>  libavfilter/vf_lensfun.c  |  6 +-
>  libavfilter/vf_overlay_cuda.c |  3 ++-
>  libavfilter/vf_paletteuse.c   |  2 +-
>  libavfilter/vf_photosensitivity.c |  3 ++-
>  libavfilter/vf_repeatfields.c | 13 ++---
>  libavfilter/vf_signalstats.c  | 13 +
>  libavfilter/vf_telecine.c | 13 +++--
>  libavfilter/vf_vidstabdetect.c| 10 +++---
>  20 files changed, 103 insertions(+), 34 deletions(-)
> 
> diff --git a/libavfilter/avf_abitscope.c b/libavfilter/avf_abitscope.c
> index 4fc3c06ecb..782d57e03a 100644
> --- a/libavfilter/avf_abitscope.c
> +++ b/libavfilter/avf_abitscope.c
> @@ -213,6 +213,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
> *insamples)
>  AVFilterLink *outlink = ctx->outputs[0];
>  AudioBitScopeContext *s = ctx->priv;
>  AVFrame *outpicref;
> +int ret;
>  
>  if (s->mode == 0 || !s->outpicref) {
>  outpicref = ff_get_video_buffer(outlink, outlink->w, outlink->h);
> @@ -228,10 +229,16 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
> *insamples)
>  }
>  
>  if (s->mode == 1) {
> -av_frame_make_writable(s->outpicref);
> +ret = ff_inlink_make_frame_writable(outlink, >outpicref);
> +if (ret < 0) {
> +av_frame_free();
> +return ret;
> +}
>  outpicref = av_frame_clone(s->outpicref);
> -if (!outpicref)
> +if (!outpicref) {
> +av_frame_free();
>  return AVERROR(ENOMEM);
> +}
>  }
>  
>  outpicref->pts = av_rescale_q(insamples->pts, inlink->time_base, 
> outlink->time_base);
> diff --git a/libavfilter/avf_ahistogram.c b/libavfilter/avf_ahistogram.c
> index c45493730d..06490192a5 100644
> --- a/libavfilter/avf_ahistogram.c
> +++ b/libavfilter/avf_ahistogram.c
> @@ -209,7 +209,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
>  AudioHistogramContext *s = ctx->priv;
>  const int H = s->histogram_h;
>  const int w = s->w;
> -int c, y, n, p, bin;
> +int c, y, n, p, bin, ret;
>  uint64_t acmax = 1;
>  AVFrame *clone;
>  
> @@ -229,7 +229,12 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
> *in)
>  }
>  }
>  
> -av_frame_make_writable(s->out);
> +ret = ff_inlink_make_frame_writable(outlink, >out);
> +if (ret < 0) {
> +av_frame_free();
> +return ret;
> +}
> +
>  if (s->dmode == SEPARATE) {
>  for (y = 0; y < w; y++) {
>  s->combine_buffer[3 * y] = 0;
> diff --git a/libavfilter/avf_aphasemeter.c b/libavfilter/avf_aphasemeter.c
> index 0f7692982c..bf9f922639 100644
> --- a/libavfilter/avf_aphasemeter.c
> +++ b/libavfilter/avf_aphasemeter.c
> @@ -29,6 +29,7 @@
>  #include "libavutil/parseutils.h"
>  #include "libavutil/timestamp.h"
>  #include "avfilter.h"
> +#include "filters.h"
>  #include "formats.h"
>  #include "audio.h"
>  #include "video.h"
> @@ -246,7 +247,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
>  float fphase = 0;
>  AVFrame *out;
>  uint8_t *dst;
> -int i;
> +int i, ret;
>  int mono_measurement;
>  int out_phase_measurement;
>  float tolerance = 1.0f - s->tolerance;
> @@ -265,8 +266,12 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
> *in)
>  for (i = 0; i < outlink->h; i++)
>  memset(out->data[0] + i * out->linesize[0], 0, outlink->w * 4);
>  } else if (s->do_video) {
> +ret = ff_inlink_make_frame_writable(outlink, >out);
> +if (ret < 0) {
> +av_frame_free();
> +return ret;
> +}
>  out = s->out;
> -av_frame_make_writable(s->out);
>  for (i = outlink->h - 1; i >= 10; i--)
>  memmove(out->data[0] + (i  ) * out->linesize[0],
>  out->data[0] + (i-1) * out->linesize[0],
> diff --git a/libavfilter/avf_avectorscope.c b/libavfilter/avf_avectorscope.c
> index 3927d80b42..6e45fd9575 100644
> --- a/libavfilter/avf_avectorscope.c
> +++ b/libavfilter/avf_avectorscope.c
> @@ -297,6 +297,7 @@ static

[FFmpeg-devel] [PATCH] avfilter: use ff_inlink_make_frame_writable()

2023-02-06 Thread Paul B Mahol 
Patch attached.
From 8d2d4d35a54d0a3ddf300ef7196489898c3efc4e Mon Sep 17 00:00:00 2001
From: Paul B Mahol 
Date: Mon, 6 Feb 2023 14:57:50 +0100
Subject: [PATCH] avfilter: use ff_inlink_make_frame_writable()

Signed-off-by: Paul B Mahol 
---
 libavfilter/avf_abitscope.c   | 11 +--
 libavfilter/avf_ahistogram.c  |  9 +++--
 libavfilter/avf_aphasemeter.c |  9 +++--
 libavfilter/avf_avectorscope.c|  7 ++-
 libavfilter/avf_showspectrum.c|  5 -
 libavfilter/avf_showvolume.c  |  6 --
 libavfilter/f_ebur128.c   | 10 --
 libavfilter/f_perms.c |  3 ++-
 libavfilter/framesync.c   |  2 +-
 libavfilter/vf_cover_rect.c   |  7 +--
 libavfilter/vf_dedot.c|  2 +-
 libavfilter/vf_floodfill.c|  3 ++-
 libavfilter/vf_lensfun.c  |  6 +-
 libavfilter/vf_overlay_cuda.c |  3 ++-
 libavfilter/vf_paletteuse.c   |  2 +-
 libavfilter/vf_photosensitivity.c |  3 ++-
 libavfilter/vf_repeatfields.c | 13 ++---
 libavfilter/vf_signalstats.c  | 13 +
 libavfilter/vf_telecine.c | 13 +++--
 libavfilter/vf_vidstabdetect.c| 10 +++---
 20 files changed, 103 insertions(+), 34 deletions(-)

diff --git a/libavfilter/avf_abitscope.c b/libavfilter/avf_abitscope.c
index 4fc3c06ecb..782d57e03a 100644
--- a/libavfilter/avf_abitscope.c
+++ b/libavfilter/avf_abitscope.c
@@ -213,6 +213,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *insamples)
 AVFilterLink *outlink = ctx->outputs[0];
 AudioBitScopeContext *s = ctx->priv;
 AVFrame *outpicref;
+int ret;
 
 if (s->mode == 0 || !s->outpicref) {
 outpicref = ff_get_video_buffer(outlink, outlink->w, outlink->h);
@@ -228,10 +229,16 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *insamples)
 }
 
 if (s->mode == 1) {
-av_frame_make_writable(s->outpicref);
+ret = ff_inlink_make_frame_writable(outlink, >outpicref);
+if (ret < 0) {
+av_frame_free();
+return ret;
+}
 outpicref = av_frame_clone(s->outpicref);
-if (!outpicref)
+if (!outpicref) {
+av_frame_free();
 return AVERROR(ENOMEM);
+}
 }
 
 outpicref->pts = av_rescale_q(insamples->pts, inlink->time_base, outlink->time_base);
diff --git a/libavfilter/avf_ahistogram.c b/libavfilter/avf_ahistogram.c
index c45493730d..06490192a5 100644
--- a/libavfilter/avf_ahistogram.c
+++ b/libavfilter/avf_ahistogram.c
@@ -209,7 +209,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 AudioHistogramContext *s = ctx->priv;
 const int H = s->histogram_h;
 const int w = s->w;
-int c, y, n, p, bin;
+int c, y, n, p, bin, ret;
 uint64_t acmax = 1;
 AVFrame *clone;
 
@@ -229,7 +229,12 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 }
 }
 
-av_frame_make_writable(s->out);
+ret = ff_inlink_make_frame_writable(outlink, >out);
+if (ret < 0) {
+av_frame_free();
+return ret;
+}
+
 if (s->dmode == SEPARATE) {
 for (y = 0; y < w; y++) {
 s->combine_buffer[3 * y] = 0;
diff --git a/libavfilter/avf_aphasemeter.c b/libavfilter/avf_aphasemeter.c
index 0f7692982c..bf9f922639 100644
--- a/libavfilter/avf_aphasemeter.c
+++ b/libavfilter/avf_aphasemeter.c
@@ -29,6 +29,7 @@
 #include "libavutil/parseutils.h"
 #include "libavutil/timestamp.h"
 #include "avfilter.h"
+#include "filters.h"
 #include "formats.h"
 #include "audio.h"
 #include "video.h"
@@ -246,7 +247,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 float fphase = 0;
 AVFrame *out;
 uint8_t *dst;
-int i;
+int i, ret;
 int mono_measurement;
 int out_phase_measurement;
 float tolerance = 1.0f - s->tolerance;
@@ -265,8 +266,12 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 for (i = 0; i < outlink->h; i++)
 memset(out->data[0] + i * out->linesize[0], 0, outlink->w * 4);
 } else if (s->do_video) {
+ret = ff_inlink_make_frame_writable(outlink, >out);
+if (ret < 0) {
+av_frame_free();
+return ret;
+}
 out = s->out;
-av_frame_make_writable(s->out);
 for (i = outlink->h - 1; i >= 10; i--)
 memmove(out->data[0] + (i  ) * out->linesize[0],
 out->data[0] + (i-1) * out->linesize[0],
diff --git a/libavfilter/avf_avectorscope.c b/libavfilter/avf_avectorscope.c
index 3927d80b42..6e45fd9575 100644
--- a/libavfilter/avf_avectorscope.c
+++ b/libavfilter/avf_avectorscope.c
@@ -297,6 +297,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *insamples)
 unsigned x, y;
 unsigned prev_x = s->prev_x, prev_y = s->prev_y;
 double zoom = s->zoom;
+int ret;
 
 if (!s->outpicref || s->outpicref->width  != outlink->w ||
  s->outpicref->height !=

[FFmpeg-devel] [PATCH] avformat/flvenc: fix EOS tag

2023-02-06 Thread Zhao Zhili 
From: Zhao Zhili 

FLV spec only has AVC end of sequence tag, and the EOS tag has a
CodecID as other video data packet. MPEG4 doesn't conformance to
the spec, but it's there for a decade. So only 'fix' the EOS tag
rather than remove it completely.

Signed-off-by: Zhao Zhili 
---
 libavformat/flvenc.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index 128ae8ebc0..8830c03044 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -235,13 +235,16 @@ static void put_timestamp(AVIOContext *pb, int64_t ts) {
 avio_w8(pb, (ts >> 24) & 0x7F);
 }
 
-static void put_avc_eos_tag(AVIOContext *pb, unsigned ts)
+static void put_eos_tag(AVIOContext *pb, unsigned ts, enum AVCodecID codec_id)
 {
+uint32_t tag = ff_codec_get_tag(flv_video_codec_ids, codec_id);
+/* ub[4] FrameType = 1, ub[4] CodecId */
+tag |= 1 << 4;
 avio_w8(pb, FLV_TAG_TYPE_VIDEO);
 avio_wb24(pb, 5);   /* Tag Data Size */
 put_timestamp(pb, ts);
 avio_wb24(pb, 0);   /* StreamId = 0 */
-avio_w8(pb, 23);/* ub[4] FrameType = 1, ub[4] CodecId = 7 
*/
+avio_w8(pb, tag);
 avio_w8(pb, 2); /* AVC end of sequence */
 avio_wb24(pb, 0);   /* Always 0 for AVC EOS. */
 avio_wb32(pb, 16);  /* Size of FLV tag */
@@ -783,7 +786,7 @@ end:
 FLVStreamContext *sc = s->streams[i]->priv_data;
 if (par->codec_type == AVMEDIA_TYPE_VIDEO &&
 (par->codec_id == AV_CODEC_ID_H264 || par->codec_id == 
AV_CODEC_ID_MPEG4))
-put_avc_eos_tag(pb, sc->last_ts);
+put_eos_tag(pb, sc->last_ts, par->codec_id);
 }
 }
 
-- 
2.25.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] MAINTAINERS: add a separate list for those with push access

2023-02-06 Thread Lynne 
Jan 30, 2023, 20:03 by d...@lynne.ee:

> Jan 30, 2023, 17:49 by mich...@niedermayer.cc:
>
>> On Thu, Dec 15, 2022 at 02:13:49AM +0100, Lynne wrote:
>>
>>> This list is incomplete, and just contains those I could see
>>> while looking at the recent git log. If it looks like I've forgotten you, I 
>>> definitely haven't!
>>> We may complete the list at a later date.
>>>
>>> This makes it such that those who add themselves to MAINTAINERS do not
>>> get push access by default, but rather, they have to request it
>>> explicitly in a different commit. This used to be the situation
>>> before it was changed at the start of this year and is pretty much what
>>> everyone expects.
>>>
>>> Patch attached.
>>>
>>> MAINTAINERS |   15 +++
>>> 1 file changed, 15 insertions(+)
>>> 6a083061d75f6655771bde377f96aadad19b21c6  
>>> 0001-MAINTAINERS-add-a-separate-list-for-those-with-push-.patch
>>> From 5c353412a25fd46c5077e5cf92ddfd6532eb46cb Mon Sep 17 00:00:00 2001
>>> From: Lynne 
>>> Date: Thu, 15 Dec 2022 02:05:00 +0100
>>> Subject: [PATCH] MAINTAINERS: add a separate list for those with push access
>>>
>>> This list is incomplete, and just contains those I could remember
>>> while looking at the recent git log.
>>> We may complete the list at a later date.
>>>
>>> This makes it such that those who add themselves to MAINTAINERS do not
>>> get push access by default, but rather, they have to request it
>>> explicitly in a different commit. This used to be the situation
>>> before it was changed at the start of this year.
>>>
>>
>> I dont object to you adding a list of people with commit acccess though i
>> dont think its needed or that useful.
>> But adding a list that is incomplete, sorted in a odd way and doing so in a
>> commit that states a past rule which i dont think was true, seems not
>> ideal
>>
>> ATM there are I think 117 keys that have write access (some may belong to
>> the same developers) and also over 100 maintainers in that MAINTAINERs file
>> I think. I didnt try to count them too precisely. But the numbers are not
>> that disimilar. The added list is quite abit more different
>>
>
> My intention was to make this complete after it's accepted (or not, if
> someone doesn't want to be known for having push access).
>
>
>> Also iam not sure this commit will change that much. People who do not want
>> write access neither before nor afterwards will not send a ssh key so wont 
>> get
>> write access. And people who want write access will push for it and
>> probably noone will object. Theres the between people who dont push for
>> it and noone else would push either they might no longer receive write
>> access. Iam not sure if that is better.
>>
>> It makes things more involved but whats really bad is that this extra
>> step is mainly in your mind, its not docuemnted.
>> Do i add someone to that new list when i give him write access or do
>> i give someone write access when a patch adding her is approved. Or do
>> i just ignore that list because its incomplete anyway ?
>>
>> I assume the intend is the 2nd one but How would a contributor know
>> to add herself to that list and what about people who are quite humble
>> and who would not push for it yet at the same time would benefit from
>> write access ?
>>
>
> How would anyone know to maintain something they should add themselves
> to the list of maintainers?
> A second list of those with push access doesn't add more roadblocks, it's
> just a separate list, that's all. You wouldn't have to add yourself to 
> maintainers
> to get push access if you don't want to.
> As for those humble, I do see your point, but it's a one-line diff change,
> and it can be done in the same commit adding yourself to maintainers,
> it's not a 2-page personal statement about values.
>
>
>> ATM every maintainer automatically receives the right for write access
>> After this patch its made more difficult, i cant just post a patch adding
>> random people either Someone would have to convince them first that they
>> should post a patch to add themselfs. 
>>
>> So what i really dislike on this change is the potential stumbling blocks
>> it throws before new developers.
>>
>> Its important that one has write access to the repository one works in
>> In FFmpeg that work happens on git master so write access to that is
>> important for anyone actively working on it.
>> In other places work and review might happen in developers own repositories
>> and they get merged regularly. In that case write access to master is not 
>> needed
>>

At the FOSDEM meeting yesterday, everyone there agreed that while it's not
perfect, it's a step in the right direction, and we should merge this.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Hardware purchase request Apple M2

2023-02-06 Thread Thilo Borgmann 

Hi,


the M2 chip recently made it from the laptops into the mini as well.
It's the generation of the Chip, I think we should buy one and have that 
running FATE as well.

Kieran agreed on hosting this one like he does for the existing M1 machines.
There are currently two M1 machines running at Kieran's, one of which runs FATE 
and the other is basically idle.

So I propose to

a) spend funding on buying one new M2 to run FATE at Kieran's and
b) retire the idle M1 machine and have that send to me to replace my Core i7 
mini from 2014.

If nobody objects, Kieran will buy the new machine and requests reimbursement 
here.


Martin pointed out we don't need an M2 for FATE as the instruction sets are 
equal on both machines.

So I change this request to just buy me an M2 mini then for ffwork.
Also saves some trouble sending the machines around and possible customs coming 
from the UK.

Paul's complaint I use it only for my personal use is of course wrong.
Also he is not using it for benching atm - though others might but with just 
buying a new M2 nothing changes for anyone with access to the existing machines.

I'd need another OK for this change of plans, of course.

Thanks,
Thilo
___
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 V5 2/3] lavfi/dnn: Modified DNN native backend related tools and docs.

2023-02-06 Thread Ting Fu 
Deleted the native backend related files in 'tools' dir. Modify its'
docs and codes mentioned in such docs.

Signed-off-by: Ting Fu 
---
 doc/filters.texi|  43 +-
 libavfilter/vf_derain.c |   2 +-
 libavfilter/vf_dnn_processing.c |   2 +-
 libavfilter/vf_sr.c |   2 +-
 tools/python/convert.py |  56 ---
 tools/python/convert_from_tensorflow.py | 607 
 tools/python/convert_header.py  |  26 -
 7 files changed, 7 insertions(+), 731 deletions(-)
 delete mode 100644 tools/python/convert.py
 delete mode 100644 tools/python/convert_from_tensorflow.py
 delete mode 100644 tools/python/convert_header.py

diff --git a/doc/filters.texi b/doc/filters.texi
index 3a54c68f3e..6fcb506b38 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -11275,9 +11275,6 @@ See 
@url{http://openaccess.thecvf.com/content_ECCV_2018/papers/Xia_Li_Recurrent_
 Training as well as model generation scripts are provided in
 the repository at @url{https://github.com/XueweiMeng/derain_filter.git}.
 
-Native model files (.model) can be generated from TensorFlow model
-files (.pb) by using tools/python/convert.py
-
 The filter accepts the following options:
 
 @table @option
@@ -11298,21 +11295,16 @@ Specify which DNN backend to use for model loading 
and execution. This option ac
 the following values:
 
 @table @samp
-@item native
-Native implementation of DNN loading and execution.
-
 @item tensorflow
 TensorFlow backend. To enable this backend you
 need to install the TensorFlow for C library (see
 @url{https://www.tensorflow.org/install/lang_c}) and configure FFmpeg with
 @code{--enable-libtensorflow}
 @end table
-Default value is @samp{native}.
 
 @item model
 Set path to model file specifying network architecture and its parameters.
-Note that different backends use different file formats. TensorFlow and native
-backend can load files for only its format.
+Note that different backends use different file formats. TensorFlow can load 
files for only its format.
 @end table
 
 To get full functionality (such as async execution), please use the 
@ref{dnn_processing} filter.
@@ -11636,9 +11628,6 @@ Specify which DNN backend to use for model loading and 
execution. This option ac
 the following values:
 
 @table @samp
-@item native
-Native implementation of DNN loading and execution.
-
 @item tensorflow
 TensorFlow backend. To enable this backend you
 need to install the TensorFlow for C library (see
@@ -11654,14 +11643,9 @@ be needed if the header files and libraries are not 
installed into system path)
 
 @end table
 
-Default value is @samp{native}.
-
 @item model
 Set path to model file specifying network architecture and its parameters.
-Note that different backends use different file formats. TensorFlow, OpenVINO 
and native
-backend can load files for only its format.
-
-Native model file (.model) can be generated from TensorFlow model file (.pb) 
by using tools/python/convert.py
+Note that different backends use different file formats. TensorFlow, OpenVINO 
backend can load files for only its format.
 
 @item input
 Set the input name of the dnn network.
@@ -11687,12 +11671,6 @@ Remove rain in rgb24 frame with can.pb (see 
@ref{derain} filter):
 ./ffmpeg -i rain.jpg -vf 
format=rgb24,dnn_processing=dnn_backend=tensorflow:model=can.pb:input=x:output=y
 derain.jpg
 @end example
 
-@item
-Halve the pixel value of the frame with format gray32f:
-@example
-ffmpeg -i input.jpg -vf 
format=grayf32,dnn_processing=model=halve_gray_float.model:input=dnn_in:output=dnn_out:dnn_backend=native
 -y out.native.png
-@end example
-
 @item
 Handle the Y channel with srcnn.pb (see @ref{sr} filter) for frame with 
yuv420p (planar YUV formats supported):
 @example
@@ -21702,13 +21680,6 @@ Efficient Sub-Pixel Convolutional Neural Network model 
(ESPCN).
 See @url{https://arxiv.org/abs/1609.05158}.
 @end itemize
 
-Training scripts as well as scripts for model file (.pb) saving can be found at
-@url{https://github.com/XueweiMeng/sr/tree/sr_dnn_native}. Original repository
-is at @url{https://github.com/HighVoltageRocknRoll/sr.git}.
-
-Native model files (.model) can be generated from TensorFlow model
-files (.pb) by using tools/python/convert.py
-
 The filter accepts the following options:
 
 @table @option
@@ -21717,9 +21688,6 @@ Specify which DNN backend to use for model loading and 
execution. This option ac
 the following values:
 
 @table @samp
-@item native
-Native implementation of DNN loading and execution.
-
 @item tensorflow
 TensorFlow backend. To enable this backend you
 need to install the TensorFlow for C library (see
@@ -21727,13 +21695,10 @@ need to install the TensorFlow for C library (see
 @code{--enable-libtensorflow}
 @end table
 
-Default value is @samp{native}.
-
 @item model
 Set path to model file specifying network architecture and its parameters.
-Note that different backends use different file formats. TensorFlow

[FFmpeg-devel] [PATCH V5 1/3] lavfi/dnn: Mark native backend as unsupported

2023-02-06 Thread Ting Fu 
Native is deprecated value for backed_type option. Modify related error
message.

Signed-off-by: Ting Fu 
---
 libavfilter/dnn/dnn_interface.c | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/libavfilter/dnn/dnn_interface.c b/libavfilter/dnn/dnn_interface.c
index 554a36b0dc..5b1695a1dd 100644
--- a/libavfilter/dnn/dnn_interface.c
+++ b/libavfilter/dnn/dnn_interface.c
@@ -24,7 +24,6 @@
  */
 
 #include "../dnn_interface.h"
-#include "dnn_backend_native.h"
 #include "dnn_backend_tf.h"
 #include "dnn_backend_openvino.h"
 #include "libavutil/mem.h"
@@ -39,13 +38,6 @@ DNNModule *ff_get_dnn_module(DNNBackendType backend_type)
 }
 
 switch(backend_type){
-case DNN_NATIVE:
-dnn_module->load_model = _dnn_load_model_native;
-dnn_module->execute_model = _dnn_execute_model_native;
-dnn_module->get_result = _dnn_get_result_native;
-dnn_module->flush = _dnn_flush_native;
-dnn_module->free_model = _dnn_free_model_native;
-break;
 case DNN_TF:
 #if (CONFIG_LIBTENSORFLOW == 1)
 dnn_module->load_model = _dnn_load_model_tf;
@@ -71,7 +63,7 @@ DNNModule *ff_get_dnn_module(DNNBackendType backend_type)
 #endif
 break;
 default:
-av_log(NULL, AV_LOG_ERROR, "Module backend_type is not native or 
tensorflow\n");
+av_log(NULL, AV_LOG_ERROR, "Module backend_type is not supported or 
enabled.\n");
 av_freep(_module);
 return NULL;
 }
-- 
2.17.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] lavfi/vf_colorspace: Add SMPTE ST 2084 support

2023-02-06 Thread Tomas Härdin 
mån 2023-02-06 klockan 10:35 +0100 skrev Tomas Härdin:
> fre 2023-02-03 klockan 08:29 -0800 skrev Pierre-Anthony Lemieux:
> > On Fri, Feb 3, 2023 at 7:54 AM Tomas Härdin  wrote:
> > > 
> > > We need something better for proper tonemap support, but this is
> > > at
> > > least useful for getting the HDR discussion going.
> > 
> > Below is a demonstration of two tonemap methods:
> > 
> > https://www.sandflow.com/public/tone-mapping/index.html
> 
> Does not work in Firefox. But it does work in Chromium. Looks like it
> could be static images only.
> 
> Anyway what I feel bears discussion is whether we should add a field
> to
> AVCodecContext like "nits" that says how many nits the max values of
> integer pixel formats correspond to, and similarly for float formats
> what 1.0 corresponds to. The latter is usually 203 cd/m² but is it
> always? The link you posted appears to use 100 cd/m²:
> 
> > l_sdr = 100;

Another thing: we probably need a float YUV format

/Tomas

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] lavfi/vf_colorspace: Add SMPTE ST 2084 support

2023-02-06 Thread Tomas Härdin 
fre 2023-02-03 klockan 08:29 -0800 skrev Pierre-Anthony Lemieux:
> On Fri, Feb 3, 2023 at 7:54 AM Tomas Härdin  wrote:
> > 
> > We need something better for proper tonemap support, but this is at
> > least useful for getting the HDR discussion going.
> 
> Below is a demonstration of two tonemap methods:
> 
> https://www.sandflow.com/public/tone-mapping/index.html

Does not work in Firefox. But it does work in Chromium. Looks like it
could be static images only.

Anyway what I feel bears discussion is whether we should add a field to
AVCodecContext like "nits" that says how many nits the max values of
integer pixel formats correspond to, and similarly for float formats
what 1.0 corresponds to. The latter is usually 203 cd/m² but is it
always? The link you posted appears to use 100 cd/m²:

> l_sdr = 100;

/Tomas

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avfilter: add QSV variants of the stack filters

2023-02-06 Thread Paul B Mahol 
On 2/6/23, Xiang, Haihao  wrote:
> On Ma, 2023-01-30 at 09:48 +0100, Paul B Mahol wrote:
>> On 1/30/23, Xiang, Haihao  wrote:
>> > From: Haihao Xiang 
>> >
>> > Include hstack_qsv, vstack_qsv and xstack_qsv. They may accept input
>> > streams with different sizes.
>> >
>> > Examples:
>> > $ ffmpeg -hwaccel qsv -hwaccel_output_format qsv -i input.mp4 \
>> > -filter_complex "[0:v][0:v]hstack_qsv" -f null -
>> >
>> > $ ffmpeg \
>> > -hwaccel qsv -hwaccel_output_format qsv -i input.mp4 \
>> > -hwaccel qsv -hwaccel_output_format qsv -i input.mp4 \
>> > -hwaccel qsv -hwaccel_output_format qsv -i input.mp4 \
>> > -hwaccel qsv -hwaccel_output_format qsv -i input.mp4 \
>> > -filter_complex
>> > "[0:v][1:v][2:v][3:v]xstack_qsv=inputs=4:fill=0x00:layout=0_0_1920x1080|
>> > w0_0_1920x1080|0_h0_1920x1080|w0_h0_1920x1080"
>> > \
>> > -f null -
>> >
>> > Signed-off-by: Haihao Xiang 
>> > ---
>> >  Changelog  |   1 +
>> >  configure  |   6 +
>> >  doc/filters.texi   |  88 ++
>> >  libavfilter/Makefile   |   3 +
>> >  libavfilter/allfilters.c   |   3 +
>> >  libavfilter/version.h  |   2 +-
>> >  libavfilter/vf_stack_qsv.c | 563 +
>> >  7 files changed, 665 insertions(+), 1 deletion(-)
>> >  create mode 100644 libavfilter/vf_stack_qsv.c
>> >
>> > diff --git a/Changelog b/Changelog
>> > index a0f1ad7211..0d700320fd 100644
>> > --- a/Changelog
>> > +++ b/Changelog
>> > @@ -34,6 +34,7 @@ version :
>> >  - ssim360 video filter
>> >  - ffmpeg CLI new options: -enc_stats_pre[_fmt], -enc_stats_post[_fmt]
>> >  - hstack_vaapi, vstack_vaapi and xstack_vaapi filters
>> > +- hstack_qsv, vstack_qsv and xstack_qsv filters
>> >
>> >
>> >  version 5.1:
>> > diff --git a/configure b/configure
>> > index 47790d10f5..037a47f2ab 100755
>> > --- a/configure
>> > +++ b/configure
>> > @@ -3770,6 +3770,12 @@ yadif_videotoolbox_filter_deps="metal corevideo
>> > videotoolbox"
>> >  hstack_vaapi_filter_deps="vaapi_1"
>> >  vstack_vaapi_filter_deps="vaapi_1"
>> >  xstack_vaapi_filter_deps="vaapi_1"
>> > +hstack_qsv_filter_deps="libmfx"
>> > +hstack_qsv_filter_select="qsvvpp"
>> > +vstack_qsv_filter_deps="libmfx"
>> > +vstack_qsv_filter_select="qsvvpp"
>> > +xstack_qsv_filter_deps="libmfx"
>> > +xstack_qsv_filter_select="qsvvpp"
>> >
>> >  # examples
>> >  avio_list_dir_deps="avformat avutil"
>> > diff --git a/doc/filters.texi b/doc/filters.texi
>> > index 3a54c68f3e..43c77dc041 100644
>> > --- a/doc/filters.texi
>> > +++ b/doc/filters.texi
>> > @@ -26772,6 +26772,94 @@ See @ref{xstack}.
>> >
>> >  @c man end VAAPI VIDEO FILTERS
>> >
>> > +@chapter QSV Video Filters
>> > +@c man begin QSV VIDEO FILTERS
>> > +
>> > +Below is a description of the currently available QSV video filters.
>> > +
>> > +To enable compilation of these filters you need to configure FFmpeg
>> > with
>> > +@code{--enable-libmfx} or @code{--enable-libvpl}.
>> > +
>> > +To use QSV filters, you need to setup the QSV device correctly. For
>> > more
>> > information, please read
>> > @url{https://trac.ffmpeg.org/wiki/Hardware/QuickSync}
>> > +
>> > +@section hstack_qsv
>> > +Stack input videos horizontally.
>> > +
>> > +This is the QSV variant of the @ref{hstack} filter, each input stream
>> > may
>> > +have different height, this filter will scale down/up each input
>> > stream
>> > while
>> > +keeping the orignal aspect.
>> > +
>> > +It accepts the following options:
>> > +
>> > +@table @option
>> > +@item inputs
>> > +See @ref{hstack}.
>> > +
>> > +@item shortest
>> > +See @ref{hstack}.
>> > +
>> > +@item height
>> > +Set height of output. If set to 0, this filter will set height of
>> > output
>> > to
>> > +height of the first input stream. Default value is 0.
>> > +@end table
>> > +
>> > +@section vstack_qsv
>> > +Stack input videos vertically.
>> > +
>> > +This is the QSV variant of the @ref{vstack} filter, each input stream
>> > may
>> > +have different width, this filter will scale down/up each input stream
>> > while
>> > +keeping the orignal aspect.
>> > +
>> > +It accepts the following options:
>> > +
>> > +@table @option
>> > +@item inputs
>> > +See @ref{vstack}.
>> > +
>> > +@item shortest
>> > +See @ref{vstack}.
>> > +
>> > +@item width
>> > +Set width of output. If set to 0, this filter will set width of output
>> > to
>> > +width of the first input stream. Default value is 0.
>> > +@end table
>> > +
>> > +@section xstack_qsv
>> > +Stack video inputs into custom layout.
>> > +
>> > +This is the QSV variant of the @ref{xstack} filter.
>> > +
>> > +It accepts the following options:
>> > +
>> > +@table @option
>> > +@item inputs
>> > +See @ref{xstack}.
>> > +
>> > +@item shortest
>> > +See @ref{xstack}.
>> > +
>> > +@item layout
>> > +See @ref{xstack}.
>> > +Moreover, this permits the user to supply output size for each input
>> > stream.
>> > +@example
>> > +xstack_qsv=inputs=4:layout=0_0_1920x1080|0_h0_1920x1080|w0_0_1920x1080|w0_h
>> > 0_1920x1080
>> > +@end example
>> > +
>> >

Re: [FFmpeg-devel] Hardware purchase request Apple M2

2023-02-06 Thread Paul B Mahol 
On 2/6/23, Thilo Borgmann  wrote:
> Hi,
>
> the M2 chip recently made it from the laptops into the mini as well.
> It's the generation of the Chip, I think we should buy one and have that
> running FATE as well.
>
> Kieran agreed on hosting this one like he does for the existing M1
> machines.
> There are currently two M1 machines running at Kieran's, one of which runs
> FATE and the other is basically idle.
>
> So I propose to
>
> a) spend funding on buying one new M2 to run FATE at Kieran's and
> b) retire the idle M1 machine and have that send to me to replace my Core i7
> mini from 2014.
>
> If nobody objects, Kieran will buy the new machine and requests
> reimbursement here.
>

I use 'idle' machine for benchmarks.

For personal computer you buy it on own.

> Thanks,
> Thilo
> ___
> 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 v14 9/9] avcodec/evc: Changes in Changelog and MAINTAINERS files

2023-02-06 Thread Dawid Kozinski/Multimedia (PLT) /SRPOL/Staff Engineer/Samsung Electronics 


Michael, could you review Lynne's policy change on maintainership?
It's essential for us to move EVC case one step forward.


-Original Message-
From: ffmpeg-devel  On Behalf Of Lynne
Sent: poniedziałek, 30 stycznia 2023 00:18
To: FFmpeg development discussions and patches 
Subject: Re: [FFmpeg-devel] [PATCH v14 9/9] avcodec/evc: Changes in
Changelog and MAINTAINERS files

Jan 29, 2023, 10:57 by mich...@niedermayer.cc:

> Hi
>
> On Fri, Jan 27, 2023 at 01:03:00PM +0100, Dawid Kozinski/Multimedia (PLT)
/SRPOL/Staff Engineer/Samsung Electronics wrote:
>
>> Hi,
>> It's been almost a month since we submitted our latest changes to the
FFmpeg patchwork. I know that EVC implementation isn't the only thing you
are working on at the moment but we'd like to do another step forward,
toward merging our implementation into the master branch of the FFmpeg
repository. 
>> The contribution is something that we take seriously so we'd like to
finally do some progress.
>> We would like to merge it as soon as it is enough good and it meets the
expected quality. Continual synchronization of our changes with the latest
FFmpeg changes and splitting our changes into patches is, let's say a
painstaking job. It would be much easier to develop and refine the code if
we could skip that hard splitting on patches step that we have to do each
time we do any, even small change.
>> We know that the new FFmpeg version will be released soon and you may be
absorbed and overwhelmed with the work related to the new release. However,
we'd be grateful if you found a little time and take a look at our latest
changes.
>> Last but not least. Do you have any plans related to including such
changes as our EVC implementation in the next release?
>>
>
> I cannot speak for others but ATM for me its difficult to add this 
> patchset to my todo list. If someone reviews and applies it it could 
> make it in for the release but will anyone, i do not know.
> What i can say is that if a patch which adds you to MAINTAINERS is 
> applied ping me and ill give you git write (unless there are some new 
> standing objections), and once you have that you can work on this code
with less pain.
> But i will leave applying the MAINTAINERS change to others too as some 
> people seemed not happy anout it and i think in such case its better 
> if a 2nd developer does that
>
> PS: Maybe you can troll the people who didnt like your MAINTAINERS 
> addition into reviewing & applying your patchset. Its not an 
> unreasonable request because if you dont have git write someone else 
> has to apply changes
>

I assign myself to personally review the patchset and push it, if you review
my policy change on maintainership. As I said, I have no objection on who
gets maintainership, just that it is done explicitly via a separate list in
the maintainers file.
___
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] Hardware purchase request Apple M2

2023-02-06 Thread Jean-Baptiste Kempf 
On Mon, 6 Feb 2023, at 04:17, Thilo Borgmann wrote:
> Kieran agreed on hosting this one like he does for the existing M1 
> machines.
> There are currently two M1 machines running at Kieran's, one of which 
> runs FATE and the other is basically idle.
>
> So I propose to
>
> a) spend funding on buying one new M2 to run FATE at Kieran's and
> b) retire the idle M1 machine and have that send to me to replace my 
> Core i7 mini from 2014.

OK.

-- 
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".