[FFmpeg-devel] [PATCH 1/2] lavu/hwcontext_qsv: add support for AV_PIX_FMT_VUYX

[Xiang, Haihao]

From: Haihao Xiang 

AV_PIX_FMT_VUYX is used in FFmpeg for 8bit 4:4:4 content on Intel HW,
and MFX_FOURCC_AYUV is used in the SDK
---
 libavutil/hwcontext_qsv.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
index 510f422562..a3350eae0f 100644
--- a/libavutil/hwcontext_qsv.c
+++ b/libavutil/hwcontext_qsv.c
@@ -119,6 +119,8 @@ static const struct {
MFX_FOURCC_YUY2 },
 { AV_PIX_FMT_Y210,
MFX_FOURCC_Y210 },
+{ AV_PIX_FMT_VUYX,
+   MFX_FOURCC_AYUV },
 #endif
 };
 
@@ -1502,6 +1504,12 @@ static int map_frame_to_surface(const AVFrame *frame, 
mfxFrameSurface1 *surface)
 surface->Data.U16 = (mfxU16 *)frame->data[0] + 1;
 surface->Data.V16 = (mfxU16 *)frame->data[0] + 3;
 break;
+case AV_PIX_FMT_VUYX:
+surface->Data.V = frame->data[0];
+surface->Data.U = frame->data[0] + 1;
+surface->Data.Y = frame->data[0] + 2;
+surface->Data.A = frame->data[0] + 3;
+break;
 #endif
 default:
 return MFX_ERR_UNSUPPORTED;
-- 
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".

[FFmpeg-devel] [PATCH 2/2] lavc/qsv: Add support for decoding & encoding 8bit 4:4:4 content

[Xiang, Haihao]

From: Haihao Xiang 

AV_PIX_FMT_VUYX is used in FFmpeg and MFX_FOURCC_AYUV is used in the SDK
---
 libavcodec/qsv.c | 12 
 libavcodec/qsvdec.c  |  2 ++
 libavcodec/qsvenc_hevc.c |  1 +
 libavcodec/qsvenc_vp9.c  |  1 +
 4 files changed, 16 insertions(+)

diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
index 3449789a2c..dbf6c0c1c7 100644
--- a/libavcodec/qsv.c
+++ b/libavcodec/qsv.c
@@ -211,6 +211,7 @@ enum AVPixelFormat ff_qsv_map_fourcc(uint32_t fourcc)
 #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;
 #endif
 }
 return AV_PIX_FMT_NONE;
@@ -243,6 +244,9 @@ int ff_qsv_map_pixfmt(enum AVPixelFormat format, uint32_t 
*fourcc)
 case AV_PIX_FMT_Y210:
 *fourcc = MFX_FOURCC_Y210;
 return AV_PIX_FMT_Y210;
+case AV_PIX_FMT_VUYX:
+*fourcc = MFX_FOURCC_AYUV;
+return AV_PIX_FMT_VUYX;
 #endif
 default:
 return AVERROR(ENOSYS);
@@ -277,6 +281,14 @@ int ff_qsv_map_frame_to_surface(const AVFrame *frame, 
mfxFrameSurface1 *surface)
 surface->Data.U16 = (mfxU16 *)frame->data[0] + 1;
 surface->Data.V16 = (mfxU16 *)frame->data[0] + 3;
 break;
+
+case AV_PIX_FMT_VUYX:
+surface->Data.V = frame->data[0];
+surface->Data.U = frame->data[0] + 1;
+surface->Data.Y = frame->data[0] + 2;
+surface->Data.A = frame->data[0] + 3;
+break;
+
 default:
 return AVERROR(ENOSYS);
 }
diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
index 89ec5dcee8..a95a921bc3 100644
--- a/libavcodec/qsvdec.c
+++ b/libavcodec/qsvdec.c
@@ -141,6 +141,7 @@ static int qsv_get_continuous_buffer(AVCodecContext *avctx, 
AVFrame *frame,
 frame->linesize[0] = 2 * FFALIGN(avctx->width, 128);
 break;
 case AV_PIX_FMT_Y210:
+case AV_PIX_FMT_VUYX:
 frame->linesize[0] = 4 * FFALIGN(avctx->width, 128);
 break;
 default:
@@ -1041,6 +1042,7 @@ const FFCodec ff_##x##_qsv_decoder = { \
 AV_PIX_FMT_P010, \
 AV_PIX_FMT_YUYV422, \
 AV_PIX_FMT_Y210, \
+AV_PIX_FMT_VUYX, \
 AV_PIX_FMT_QSV, \
 AV_PIX_FMT_NONE }, \
 .hw_configs = qsv_hw_configs, \
diff --git a/libavcodec/qsvenc_hevc.c b/libavcodec/qsvenc_hevc.c
index e59747fda3..690e6b7fcd 100644
--- a/libavcodec/qsvenc_hevc.c
+++ b/libavcodec/qsvenc_hevc.c
@@ -314,6 +314,7 @@ const FFCodec ff_hevc_qsv_encoder = {
 AV_PIX_FMT_QSV,
 AV_PIX_FMT_BGRA,
 AV_PIX_FMT_X2RGB10,
+AV_PIX_FMT_VUYX,
 AV_PIX_FMT_NONE },
 .p.priv_class   = &class,
 .defaults   = qsv_enc_defaults,
diff --git a/libavcodec/qsvenc_vp9.c b/libavcodec/qsvenc_vp9.c
index c738da3904..c3df7c522a 100644
--- a/libavcodec/qsvenc_vp9.c
+++ b/libavcodec/qsvenc_vp9.c
@@ -113,6 +113,7 @@ const FFCodec ff_vp9_qsv_encoder = {
 .p.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_HYBRID,
 .p.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_NV12,
 AV_PIX_FMT_P010,
+AV_PIX_FMT_VUYX,
 AV_PIX_FMT_QSV,
 AV_PIX_FMT_NONE },
 .p.priv_class   = &class,
-- 
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 1/2] lavu/hwcontext_qsv: add support for AV_PIX_FMT_VUYX

[James Almer]

On 8/29/2022 4:27 AM, Xiang, Haihao wrote:

From: Haihao Xiang 

AV_PIX_FMT_VUYX is used in FFmpeg for 8bit 4:4:4 content on Intel HW,
and MFX_FOURCC_AYUV is used in the SDK


Sounds like you want the VUYA pixfmt instead.


---
  libavutil/hwcontext_qsv.c | 8 
  1 file changed, 8 insertions(+)

diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
index 510f422562..a3350eae0f 100644
--- a/libavutil/hwcontext_qsv.c
+++ b/libavutil/hwcontext_qsv.c
@@ -119,6 +119,8 @@ static const struct {
 MFX_FOURCC_YUY2 },
  { AV_PIX_FMT_Y210,
 MFX_FOURCC_Y210 },
+{ AV_PIX_FMT_VUYX,
+   MFX_FOURCC_AYUV },
  #endif
  };
  
@@ -1502,6 +1504,12 @@ static int map_frame_to_surface(const AVFrame *frame, mfxFrameSurface1 *surface)

  surface->Data.U16 = (mfxU16 *)frame->data[0] + 1;
  surface->Data.V16 = (mfxU16 *)frame->data[0] + 3;
  break;
+case AV_PIX_FMT_VUYX:
+surface->Data.V = frame->data[0];
+surface->Data.U = frame->data[0] + 1;
+surface->Data.Y = frame->data[0] + 2;
+surface->Data.A = frame->data[0] + 3;


This will go wrong with VUYX. You need to use AV_PIX_FMT_VUYA.


+break;
  #endif
  default:
  return MFX_ERR_UNSUPPORTED;

___
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 v1 2/3] swscale/la: Add yuv2rgb_lasx.c and rgb2rgb_lasx.c files

[Hao Chen]

ffmpeg -i ~/media/1_h264_1080p_30fps_3Mbps.mp4 -f rawvideo -pix_fmt rgb24 -y 
/dev/null -an
before: 178fps
after:  210fps

Signed-off-by: Hao Chen 
---
 libswscale/loongarch/Makefile |   2 +
 libswscale/loongarch/rgb2rgb_lasx.c   |  52 +++
 libswscale/loongarch/swscale_init_loongarch.c |  42 +++
 libswscale/loongarch/swscale_loongarch.h  |  22 ++
 libswscale/loongarch/yuv2rgb_lasx.c   | 329 ++
 libswscale/rgb2rgb.c  |   2 +
 libswscale/rgb2rgb.h  |   1 +
 libswscale/yuv2rgb.c  |   2 +
 8 files changed, 452 insertions(+)
 create mode 100644 libswscale/loongarch/rgb2rgb_lasx.c
 create mode 100644 libswscale/loongarch/yuv2rgb_lasx.c

diff --git a/libswscale/loongarch/Makefile b/libswscale/loongarch/Makefile
index 586a1717b6..4345971514 100644
--- a/libswscale/loongarch/Makefile
+++ b/libswscale/loongarch/Makefile
@@ -1,3 +1,5 @@
 OBJS-$(CONFIG_SWSCALE)  += loongarch/swscale_init_loongarch.o
 LASX-OBJS-$(CONFIG_SWSCALE) += loongarch/swscale_lasx.o \
loongarch/input_lasx.o   \
+   loongarch/yuv2rgb_lasx.o \
+   loongarch/rgb2rgb_lasx.o
diff --git a/libswscale/loongarch/rgb2rgb_lasx.c 
b/libswscale/loongarch/rgb2rgb_lasx.c
new file mode 100644
index 00..68684ca595
--- /dev/null
+++ b/libswscale/loongarch/rgb2rgb_lasx.c
@@ -0,0 +1,52 @@
+/*
+ * Copyright (c) 2022 Loongson Technology Corporation Limited
+ * Contributed by Hao Chen(chen...@loongson.cn)
+ *
+ * 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 "swscale_loongarch.h"
+#include "libavutil/loongarch/loongson_intrinsics.h"
+
+void ff_interleave_bytes_lasx(const uint8_t *src1, const uint8_t *src2,
+  uint8_t *dest, int width, int height,
+  int src1Stride, int src2Stride, int dstStride)
+{
+int h;
+int len = width & (0xFFF0);
+
+for (h = 0; h < height; h++) {
+int w, index = 0;
+__m256i src_1, src_2, dst;
+
+for (w = 0; w < len; w += 16) {
+DUP2_ARG2(__lasx_xvld, src1 + w, 0, src2 + w, 0, src_1, src_2);
+src_1 = __lasx_xvpermi_d(src_1, 0xD8);
+src_2 = __lasx_xvpermi_d(src_2, 0xD8);
+dst   = __lasx_xvilvl_b(src_2, src_1);
+__lasx_xvst(dst, dest + index, 0);
+index  += 32;
+}
+for (w = 0; w < width; w++) {
+dest[(w << 1) + 0] = src1[w];
+dest[(w << 1) + 1] = src2[w];
+}
+dest += dstStride;
+src1 += src1Stride;
+src2 += src2Stride;
+}
+}
diff --git a/libswscale/loongarch/swscale_init_loongarch.c 
b/libswscale/loongarch/swscale_init_loongarch.c
index 197dc6e1e7..1e0bb1b116 100644
--- a/libswscale/loongarch/swscale_init_loongarch.c
+++ b/libswscale/loongarch/swscale_init_loongarch.c
@@ -21,6 +21,7 @@
 
 #include "swscale_loongarch.h"
 #include "libswscale/swscale_internal.h"
+#include "libswscale/rgb2rgb.h"
 #include "libavutil/loongarch/cpu.h"
 
 av_cold void ff_sws_init_swscale_loongarch(SwsContext *c)
@@ -48,3 +49,44 @@ av_cold void ff_sws_init_swscale_loongarch(SwsContext *c)
 }
 }
 }
+
+av_cold void rgb2rgb_init_loongarch(void)
+{
+int cpu_flags = av_get_cpu_flags();
+if (have_lasx(cpu_flags))
+interleaveBytes = ff_interleave_bytes_lasx;
+}
+
+av_cold SwsFunc ff_yuv2rgb_init_loongarch(SwsContext *c)
+{
+int cpu_flags = av_get_cpu_flags();
+if (have_lasx(cpu_flags)) {
+switch (c->dstFormat) {
+case AV_PIX_FMT_RGB24:
+return yuv420_rgb24_lasx;
+case AV_PIX_FMT_BGR24:
+return yuv420_bgr24_lasx;
+case AV_PIX_FMT_RGBA:
+if (CONFIG_SWSCALE_ALPHA && isALPHA(c->srcFormat)) {
+break;
+} else
+return yuv420_rgba32_lasx;
+case AV_PIX_FMT_ARGB:
+if (CONFIG_SWSCALE_ALPHA && isALPHA(c->srcFormat)) {
+break;
+} else
+return yuv420_argb32_lasx;
+case AV_PIX_FMT_BGRA:
+if (CONFIG_SWSCALE_ALPHA && isALPH

[FFmpeg-devel] Add loongarch SIMD optimization in swscale lib.

[Hao Chen]

[PATCH v1 1/3] swscale/la: Optimize hscale functions with lasx.
[PATCH v1 2/3] swscale/la: Add yuv2rgb_lasx.c and rgb2rgb_lasx.c
[PATCH v1 3/3] swscale/la: Add output_lasx.c 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] [PATCH v1 1/3] swscale/la: Optimize hscale functions with lasx.

[Hao Chen]

ffmpeg -i ~/media/1_h264_1080p_30fps_3Mbps.mp4 -f rawvideo -s 640x480 -y 
/dev/null -an
before: 101fps
after:  138fps

Signed-off-by: Hao Chen 
---
 libswscale/loongarch/Makefile |   3 +
 libswscale/loongarch/input_lasx.c | 192 
 libswscale/loongarch/swscale_init_loongarch.c |  50 +
 libswscale/loongarch/swscale_lasx.c   | 959 ++
 libswscale/loongarch/swscale_loongarch.h  |  50 +
 libswscale/swscale.c  |   2 +
 libswscale/swscale_internal.h |   2 +
 libswscale/utils.c|  13 +-
 8 files changed, 1270 insertions(+), 1 deletion(-)
 create mode 100644 libswscale/loongarch/Makefile
 create mode 100644 libswscale/loongarch/input_lasx.c
 create mode 100644 libswscale/loongarch/swscale_init_loongarch.c
 create mode 100644 libswscale/loongarch/swscale_lasx.c
 create mode 100644 libswscale/loongarch/swscale_loongarch.h

diff --git a/libswscale/loongarch/Makefile b/libswscale/loongarch/Makefile
new file mode 100644
index 00..586a1717b6
--- /dev/null
+++ b/libswscale/loongarch/Makefile
@@ -0,0 +1,3 @@
+OBJS-$(CONFIG_SWSCALE)  += loongarch/swscale_init_loongarch.o
+LASX-OBJS-$(CONFIG_SWSCALE) += loongarch/swscale_lasx.o \
+   loongarch/input_lasx.o   \
diff --git a/libswscale/loongarch/input_lasx.c 
b/libswscale/loongarch/input_lasx.c
new file mode 100644
index 00..6fcb998bc0
--- /dev/null
+++ b/libswscale/loongarch/input_lasx.c
@@ -0,0 +1,192 @@
+/*
+ * Copyright (C) 2022 Loongson Technology Corporation Limited
+ * Contributed by Hao Chen(chen...@loongson.cn)
+ *
+ * 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 "swscale_loongarch.h"
+#include "libavutil/loongarch/loongson_intrinsics.h"
+
+void planar_rgb_to_uv_lasx(uint8_t *_dstU, uint8_t *_dstV, const uint8_t 
*src[4],
+   int width, int32_t *rgb2yuv)
+{
+int i;
+uint16_t *dstU   = (uint16_t *)_dstU;
+uint16_t *dstV   = (uint16_t *)_dstV;
+int set  = 0x4001 << (RGB2YUV_SHIFT - 7);
+int len  = width - 15;
+int32_t tem_ru   = rgb2yuv[RU_IDX], tem_gu = rgb2yuv[GU_IDX];
+int32_t tem_bu = rgb2yuv[BU_IDX], tem_rv   = rgb2yuv[RV_IDX];
+int32_t tem_gv = rgb2yuv[GV_IDX], tem_bv = rgb2yuv[BV_IDX];
+int shift= RGB2YUV_SHIFT - 6;
+const uint8_t *src0 = src[0], *src1 = src[1], *src2 = src[2];
+__m256i ru, gu, bu, rv, gv, bv;
+__m256i mask = {0x0D0C090805040100, 0x1D1C191815141110,
+0x0D0C090805040100, 0x1D1C191815141110};
+__m256i temp = __lasx_xvreplgr2vr_w(set);
+__m256i sra  = __lasx_xvreplgr2vr_w(shift);
+
+ru = __lasx_xvreplgr2vr_w(tem_ru);
+gu = __lasx_xvreplgr2vr_w(tem_gu);
+bu = __lasx_xvreplgr2vr_w(tem_bu);
+rv = __lasx_xvreplgr2vr_w(tem_rv);
+gv = __lasx_xvreplgr2vr_w(tem_gv);
+bv = __lasx_xvreplgr2vr_w(tem_bv);
+for (i = 0; i < len; i += 16) {
+__m256i _g, _b, _r;
+__m256i g_l, g_h, b_l, b_h, r_l, r_h;
+__m256i v_l, v_h, u_l, u_h, u_lh, v_lh;
+
+DUP2_ARG2(__lasx_xvld, src0 + i, 0, src1 + i, 0, _g, _b);
+_r   = __lasx_xvld(src2 + i, 0);
+g_l = __lasx_vext2xv_wu_bu(_g);
+DUP2_ARG1(__lasx_vext2xv_wu_bu, _b, _r, b_l, r_l);
+_g   = __lasx_xvpermi_d(_g, 0x01);
+_b   = __lasx_xvpermi_d(_b, 0x01);
+_r   = __lasx_xvpermi_d(_r, 0x01);
+g_h = __lasx_vext2xv_wu_bu(_g);
+DUP2_ARG1(__lasx_vext2xv_wu_bu, _b, _r, b_h, r_h);
+u_l  = __lasx_xvmadd_w(temp, ru, r_l);
+u_h  = __lasx_xvmadd_w(temp, ru, r_h);
+v_l  = __lasx_xvmadd_w(temp, rv, r_l);
+v_h  = __lasx_xvmadd_w(temp, rv, r_h);
+u_l  = __lasx_xvmadd_w(u_l, gu, g_l);
+u_l  = __lasx_xvmadd_w(u_l, bu, b_l);
+u_h  = __lasx_xvmadd_w(u_h, gu, g_h);
+u_h  = __lasx_xvmadd_w(u_h, bu, b_h);
+v_l  = __lasx_xvmadd_w(v_l, gv, g_l);
+v_l  = __lasx_xvmadd_w(v_l, bv, b_l);
+v_h  = __lasx_xvmadd_w(v_h, gv, g_h);
+v_h  = __lasx_xvmadd_w(v_h, bv, b_h);
+u_l  = __lasx_xvsra_w(u_l, sra);
+u_h  = __lasx_xvsra_w(u_h, sra);
+v_l  = __lasx_xvsra_w(v_l, sra);
+v_h  = __lasx_xvsra_w(v_h, sra);

[FFmpeg-devel] [PATCH v1 2/3] swscale/la: Add yuv2rgb_lasx.c and rgb2rgb_lasx.c files

[Hao Chen]

ffmpeg -i ~/media/1_h264_1080p_30fps_3Mbps.mp4 -f rawvideo -pix_fmt rgb24 -y 
/dev/null -an
before: 178fps
after:  210fps

Signed-off-by: Hao Chen 
---
 libswscale/loongarch/Makefile |   2 +
 libswscale/loongarch/rgb2rgb_lasx.c   |  52 +++
 libswscale/loongarch/swscale_init_loongarch.c |  42 +++
 libswscale/loongarch/swscale_loongarch.h  |  22 ++
 libswscale/loongarch/yuv2rgb_lasx.c   | 329 ++
 libswscale/rgb2rgb.c  |   2 +
 libswscale/rgb2rgb.h  |   1 +
 libswscale/yuv2rgb.c  |   2 +
 8 files changed, 452 insertions(+)
 create mode 100644 libswscale/loongarch/rgb2rgb_lasx.c
 create mode 100644 libswscale/loongarch/yuv2rgb_lasx.c

diff --git a/libswscale/loongarch/Makefile b/libswscale/loongarch/Makefile
index 586a1717b6..4345971514 100644
--- a/libswscale/loongarch/Makefile
+++ b/libswscale/loongarch/Makefile
@@ -1,3 +1,5 @@
 OBJS-$(CONFIG_SWSCALE)  += loongarch/swscale_init_loongarch.o
 LASX-OBJS-$(CONFIG_SWSCALE) += loongarch/swscale_lasx.o \
loongarch/input_lasx.o   \
+   loongarch/yuv2rgb_lasx.o \
+   loongarch/rgb2rgb_lasx.o
diff --git a/libswscale/loongarch/rgb2rgb_lasx.c 
b/libswscale/loongarch/rgb2rgb_lasx.c
new file mode 100644
index 00..68684ca595
--- /dev/null
+++ b/libswscale/loongarch/rgb2rgb_lasx.c
@@ -0,0 +1,52 @@
+/*
+ * Copyright (c) 2022 Loongson Technology Corporation Limited
+ * Contributed by Hao Chen(chen...@loongson.cn)
+ *
+ * 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 "swscale_loongarch.h"
+#include "libavutil/loongarch/loongson_intrinsics.h"
+
+void ff_interleave_bytes_lasx(const uint8_t *src1, const uint8_t *src2,
+  uint8_t *dest, int width, int height,
+  int src1Stride, int src2Stride, int dstStride)
+{
+int h;
+int len = width & (0xFFF0);
+
+for (h = 0; h < height; h++) {
+int w, index = 0;
+__m256i src_1, src_2, dst;
+
+for (w = 0; w < len; w += 16) {
+DUP2_ARG2(__lasx_xvld, src1 + w, 0, src2 + w, 0, src_1, src_2);
+src_1 = __lasx_xvpermi_d(src_1, 0xD8);
+src_2 = __lasx_xvpermi_d(src_2, 0xD8);
+dst   = __lasx_xvilvl_b(src_2, src_1);
+__lasx_xvst(dst, dest + index, 0);
+index  += 32;
+}
+for (w = 0; w < width; w++) {
+dest[(w << 1) + 0] = src1[w];
+dest[(w << 1) + 1] = src2[w];
+}
+dest += dstStride;
+src1 += src1Stride;
+src2 += src2Stride;
+}
+}
diff --git a/libswscale/loongarch/swscale_init_loongarch.c 
b/libswscale/loongarch/swscale_init_loongarch.c
index 197dc6e1e7..1e0bb1b116 100644
--- a/libswscale/loongarch/swscale_init_loongarch.c
+++ b/libswscale/loongarch/swscale_init_loongarch.c
@@ -21,6 +21,7 @@
 
 #include "swscale_loongarch.h"
 #include "libswscale/swscale_internal.h"
+#include "libswscale/rgb2rgb.h"
 #include "libavutil/loongarch/cpu.h"
 
 av_cold void ff_sws_init_swscale_loongarch(SwsContext *c)
@@ -48,3 +49,44 @@ av_cold void ff_sws_init_swscale_loongarch(SwsContext *c)
 }
 }
 }
+
+av_cold void rgb2rgb_init_loongarch(void)
+{
+int cpu_flags = av_get_cpu_flags();
+if (have_lasx(cpu_flags))
+interleaveBytes = ff_interleave_bytes_lasx;
+}
+
+av_cold SwsFunc ff_yuv2rgb_init_loongarch(SwsContext *c)
+{
+int cpu_flags = av_get_cpu_flags();
+if (have_lasx(cpu_flags)) {
+switch (c->dstFormat) {
+case AV_PIX_FMT_RGB24:
+return yuv420_rgb24_lasx;
+case AV_PIX_FMT_BGR24:
+return yuv420_bgr24_lasx;
+case AV_PIX_FMT_RGBA:
+if (CONFIG_SWSCALE_ALPHA && isALPHA(c->srcFormat)) {
+break;
+} else
+return yuv420_rgba32_lasx;
+case AV_PIX_FMT_ARGB:
+if (CONFIG_SWSCALE_ALPHA && isALPHA(c->srcFormat)) {
+break;
+} else
+return yuv420_argb32_lasx;
+case AV_PIX_FMT_BGRA:
+if (CONFIG_SWSCALE_ALPHA && isALPH

[FFmpeg-devel] [PATCH v1 3/3] swscale/la: Add output_lasx.c file.

[Hao Chen]

ffmpeg -i ~/media/1_h264_1080p_30fps_3Mbps.mp4 -f rawvideo -s 640x480 -pix_fmt
rgb24 -y /dev/null -an
before: 150fps
after:  183fps

Signed-off-by: Hao Chen 
---
 libswscale/loongarch/Makefile |3 +-
 libswscale/loongarch/output_lasx.c| 1982 +
 libswscale/loongarch/swscale_init_loongarch.c |3 +
 libswscale/loongarch/swscale_loongarch.h  |6 +
 4 files changed, 1993 insertions(+), 1 deletion(-)
 create mode 100644 libswscale/loongarch/output_lasx.c

diff --git a/libswscale/loongarch/Makefile b/libswscale/loongarch/Makefile
index 4345971514..54d48b3de0 100644
--- a/libswscale/loongarch/Makefile
+++ b/libswscale/loongarch/Makefile
@@ -2,4 +2,5 @@ OBJS-$(CONFIG_SWSCALE)  += 
loongarch/swscale_init_loongarch.o
 LASX-OBJS-$(CONFIG_SWSCALE) += loongarch/swscale_lasx.o \
loongarch/input_lasx.o   \
loongarch/yuv2rgb_lasx.o \
-   loongarch/rgb2rgb_lasx.o
+   loongarch/rgb2rgb_lasx.o \
+  
loongarch/output_lasx.o
diff --git a/libswscale/loongarch/output_lasx.c 
b/libswscale/loongarch/output_lasx.c
new file mode 100644
index 00..19f82692ff
--- /dev/null
+++ b/libswscale/loongarch/output_lasx.c
@@ -0,0 +1,1982 @@
+/*
+ * Copyright (C) 2022 Loongson Technology Corporation Limited
+ * Contributed by Hao Chen(chen...@loongson.cn)
+ *
+ * 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 "swscale_loongarch.h"
+#include "libavutil/loongarch/loongson_intrinsics.h"
+
+void ff_yuv2planeX_8_lasx(const int16_t *filter, int filterSize,
+  const int16_t **src, uint8_t *dest, int dstW,
+  const uint8_t *dither, int offset)
+{
+int i;
+int len = dstW - 15;
+__m256i mask = {0x1C0C180814041000, 0x1C1814100C080400,
+0x1C0C180814041000, 0x1C1814100C080400};
+__m256i val1, val2, val3;
+uint8_t dither0 = dither[offset & 7];
+uint8_t dither1 = dither[(offset + 1) & 7];
+uint8_t dither2 = dither[(offset + 2) & 7];
+uint8_t dither3 = dither[(offset + 3) & 7];
+uint8_t dither4 = dither[(offset + 4) & 7];
+uint8_t dither5 = dither[(offset + 5) & 7];
+uint8_t dither6 = dither[(offset + 6) & 7];
+uint8_t dither7 = dither[(offset + 7) & 7];
+int val_1[8] = {dither0, dither2, dither4, dither6,
+dither0, dither2, dither4, dither6};
+int val_2[8] = {dither1, dither3, dither5, dither7,
+dither1, dither3, dither5, dither7};
+int val_3[8] = {dither0, dither1, dither2, dither3,
+dither4, dither5, dither6, dither7};
+
+DUP2_ARG2(__lasx_xvld, val_1, 0, val_2, 0, val1, val2);
+val3 = __lasx_xvld(val_3, 0);
+
+for (i = 0; i < len; i += 16) {
+int j;
+__m256i src0, filter0, val;
+__m256i val_ev, val_od;
+
+val_ev = __lasx_xvslli_w(val1, 12);
+val_od = __lasx_xvslli_w(val2, 12);
+
+for (j = 0; j < filterSize; j++) {
+src0  = __lasx_xvld(src[j]+ i, 0);
+filter0 = __lasx_xvldrepl_h((filter + j), 0);
+val_ev = __lasx_xvmaddwev_w_h(val_ev, src0, filter0);
+val_od = __lasx_xvmaddwod_w_h(val_od, src0, filter0);
+}
+val_ev = __lasx_xvsrai_w(val_ev, 19);
+val_od = __lasx_xvsrai_w(val_od, 19);
+val_ev = __lasx_xvclip255_w(val_ev);
+val_od = __lasx_xvclip255_w(val_od);
+val= __lasx_xvshuf_b(val_od, val_ev, mask);
+__lasx_xvstelm_d(val, (dest + i), 0, 0);
+__lasx_xvstelm_d(val, (dest + i), 8, 2);
+}
+if (dstW - i >= 8){
+int j;
+__m256i src0, filter0, val_h;
+__m256i val_l;
+
+val_l = __lasx_xvslli_w(val3, 12);
+
+for (j = 0; j < filterSize; j++) {
+src0  = __lasx_xvld(src[j] + i, 0);
+src0  = __lasx_vext2xv_w_h(src0);
+filter0 = __lasx_xvldrepl_h((filter + j), 0);
+filter0 = __lasx_vext2xv_w_h(filter0);
+val_l = __lasx_xvmadd_w(val_l, src0, filter0);
+}
+val_l = __lasx_xvsrai_w(val_l, 19);
+val_l = __lasx_xvclip255_w(val_

[FFmpeg-devel] Add LoongArch SIMD optimization in swscale lib.

[Hao Chen]

[PATCH v1 1/3] swscale/la: Optimize hscale functions with lasx.
[PATCH v1 2/3] swscale/la: Add yuv2rgb_lasx.c and rgb2rgb_lasx.c
[PATCH v1 3/3] swscale/la: Add output_lasx.c 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] [PATCH v1 1/3] swscale/la: Optimize hscale functions with lasx.

[Hao Chen]

ffmpeg -i ~/media/1_h264_1080p_30fps_3Mbps.mp4 -f rawvideo -s 640x480 -y 
/dev/null -an
before: 101fps
after:  138fps

Signed-off-by: Hao Chen 
---
 libswscale/loongarch/Makefile |   3 +
 libswscale/loongarch/input_lasx.c | 192 
 libswscale/loongarch/swscale_init_loongarch.c |  50 +
 libswscale/loongarch/swscale_lasx.c   | 959 ++
 libswscale/loongarch/swscale_loongarch.h  |  50 +
 libswscale/swscale.c  |   2 +
 libswscale/swscale_internal.h |   2 +
 libswscale/utils.c|  13 +-
 8 files changed, 1270 insertions(+), 1 deletion(-)
 create mode 100644 libswscale/loongarch/Makefile
 create mode 100644 libswscale/loongarch/input_lasx.c
 create mode 100644 libswscale/loongarch/swscale_init_loongarch.c
 create mode 100644 libswscale/loongarch/swscale_lasx.c
 create mode 100644 libswscale/loongarch/swscale_loongarch.h

diff --git a/libswscale/loongarch/Makefile b/libswscale/loongarch/Makefile
new file mode 100644
index 00..586a1717b6
--- /dev/null
+++ b/libswscale/loongarch/Makefile
@@ -0,0 +1,3 @@
+OBJS-$(CONFIG_SWSCALE)  += loongarch/swscale_init_loongarch.o
+LASX-OBJS-$(CONFIG_SWSCALE) += loongarch/swscale_lasx.o \
+   loongarch/input_lasx.o   \
diff --git a/libswscale/loongarch/input_lasx.c 
b/libswscale/loongarch/input_lasx.c
new file mode 100644
index 00..6fcb998bc0
--- /dev/null
+++ b/libswscale/loongarch/input_lasx.c
@@ -0,0 +1,192 @@
+/*
+ * Copyright (C) 2022 Loongson Technology Corporation Limited
+ * Contributed by Hao Chen(chen...@loongson.cn)
+ *
+ * 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 "swscale_loongarch.h"
+#include "libavutil/loongarch/loongson_intrinsics.h"
+
+void planar_rgb_to_uv_lasx(uint8_t *_dstU, uint8_t *_dstV, const uint8_t 
*src[4],
+   int width, int32_t *rgb2yuv)
+{
+int i;
+uint16_t *dstU   = (uint16_t *)_dstU;
+uint16_t *dstV   = (uint16_t *)_dstV;
+int set  = 0x4001 << (RGB2YUV_SHIFT - 7);
+int len  = width - 15;
+int32_t tem_ru   = rgb2yuv[RU_IDX], tem_gu = rgb2yuv[GU_IDX];
+int32_t tem_bu = rgb2yuv[BU_IDX], tem_rv   = rgb2yuv[RV_IDX];
+int32_t tem_gv = rgb2yuv[GV_IDX], tem_bv = rgb2yuv[BV_IDX];
+int shift= RGB2YUV_SHIFT - 6;
+const uint8_t *src0 = src[0], *src1 = src[1], *src2 = src[2];
+__m256i ru, gu, bu, rv, gv, bv;
+__m256i mask = {0x0D0C090805040100, 0x1D1C191815141110,
+0x0D0C090805040100, 0x1D1C191815141110};
+__m256i temp = __lasx_xvreplgr2vr_w(set);
+__m256i sra  = __lasx_xvreplgr2vr_w(shift);
+
+ru = __lasx_xvreplgr2vr_w(tem_ru);
+gu = __lasx_xvreplgr2vr_w(tem_gu);
+bu = __lasx_xvreplgr2vr_w(tem_bu);
+rv = __lasx_xvreplgr2vr_w(tem_rv);
+gv = __lasx_xvreplgr2vr_w(tem_gv);
+bv = __lasx_xvreplgr2vr_w(tem_bv);
+for (i = 0; i < len; i += 16) {
+__m256i _g, _b, _r;
+__m256i g_l, g_h, b_l, b_h, r_l, r_h;
+__m256i v_l, v_h, u_l, u_h, u_lh, v_lh;
+
+DUP2_ARG2(__lasx_xvld, src0 + i, 0, src1 + i, 0, _g, _b);
+_r   = __lasx_xvld(src2 + i, 0);
+g_l = __lasx_vext2xv_wu_bu(_g);
+DUP2_ARG1(__lasx_vext2xv_wu_bu, _b, _r, b_l, r_l);
+_g   = __lasx_xvpermi_d(_g, 0x01);
+_b   = __lasx_xvpermi_d(_b, 0x01);
+_r   = __lasx_xvpermi_d(_r, 0x01);
+g_h = __lasx_vext2xv_wu_bu(_g);
+DUP2_ARG1(__lasx_vext2xv_wu_bu, _b, _r, b_h, r_h);
+u_l  = __lasx_xvmadd_w(temp, ru, r_l);
+u_h  = __lasx_xvmadd_w(temp, ru, r_h);
+v_l  = __lasx_xvmadd_w(temp, rv, r_l);
+v_h  = __lasx_xvmadd_w(temp, rv, r_h);
+u_l  = __lasx_xvmadd_w(u_l, gu, g_l);
+u_l  = __lasx_xvmadd_w(u_l, bu, b_l);
+u_h  = __lasx_xvmadd_w(u_h, gu, g_h);
+u_h  = __lasx_xvmadd_w(u_h, bu, b_h);
+v_l  = __lasx_xvmadd_w(v_l, gv, g_l);
+v_l  = __lasx_xvmadd_w(v_l, bv, b_l);
+v_h  = __lasx_xvmadd_w(v_h, gv, g_h);
+v_h  = __lasx_xvmadd_w(v_h, bv, b_h);
+u_l  = __lasx_xvsra_w(u_l, sra);
+u_h  = __lasx_xvsra_w(u_h, sra);
+v_l  = __lasx_xvsra_w(v_l, sra);
+v_h  = __lasx_xvsra_w(v_h, sra);

[FFmpeg-devel] [PATCH v1 2/3] swscale/la: Add yuv2rgb_lasx.c and rgb2rgb_lasx.c files

[Hao Chen]

ffmpeg -i ~/media/1_h264_1080p_30fps_3Mbps.mp4 -f rawvideo -pix_fmt rgb24 -y 
/dev/null -an
before: 178fps
after:  210fps

Signed-off-by: Hao Chen 
---
 libswscale/loongarch/Makefile |   2 +
 libswscale/loongarch/rgb2rgb_lasx.c   |  52 +++
 libswscale/loongarch/swscale_init_loongarch.c |  42 +++
 libswscale/loongarch/swscale_loongarch.h  |  22 ++
 libswscale/loongarch/yuv2rgb_lasx.c   | 329 ++
 libswscale/rgb2rgb.c  |   2 +
 libswscale/rgb2rgb.h  |   1 +
 libswscale/yuv2rgb.c  |   2 +
 8 files changed, 452 insertions(+)
 create mode 100644 libswscale/loongarch/rgb2rgb_lasx.c
 create mode 100644 libswscale/loongarch/yuv2rgb_lasx.c

diff --git a/libswscale/loongarch/Makefile b/libswscale/loongarch/Makefile
index 586a1717b6..4345971514 100644
--- a/libswscale/loongarch/Makefile
+++ b/libswscale/loongarch/Makefile
@@ -1,3 +1,5 @@
 OBJS-$(CONFIG_SWSCALE)  += loongarch/swscale_init_loongarch.o
 LASX-OBJS-$(CONFIG_SWSCALE) += loongarch/swscale_lasx.o \
loongarch/input_lasx.o   \
+   loongarch/yuv2rgb_lasx.o \
+   loongarch/rgb2rgb_lasx.o
diff --git a/libswscale/loongarch/rgb2rgb_lasx.c 
b/libswscale/loongarch/rgb2rgb_lasx.c
new file mode 100644
index 00..68684ca595
--- /dev/null
+++ b/libswscale/loongarch/rgb2rgb_lasx.c
@@ -0,0 +1,52 @@
+/*
+ * Copyright (c) 2022 Loongson Technology Corporation Limited
+ * Contributed by Hao Chen(chen...@loongson.cn)
+ *
+ * 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 "swscale_loongarch.h"
+#include "libavutil/loongarch/loongson_intrinsics.h"
+
+void ff_interleave_bytes_lasx(const uint8_t *src1, const uint8_t *src2,
+  uint8_t *dest, int width, int height,
+  int src1Stride, int src2Stride, int dstStride)
+{
+int h;
+int len = width & (0xFFF0);
+
+for (h = 0; h < height; h++) {
+int w, index = 0;
+__m256i src_1, src_2, dst;
+
+for (w = 0; w < len; w += 16) {
+DUP2_ARG2(__lasx_xvld, src1 + w, 0, src2 + w, 0, src_1, src_2);
+src_1 = __lasx_xvpermi_d(src_1, 0xD8);
+src_2 = __lasx_xvpermi_d(src_2, 0xD8);
+dst   = __lasx_xvilvl_b(src_2, src_1);
+__lasx_xvst(dst, dest + index, 0);
+index  += 32;
+}
+for (w = 0; w < width; w++) {
+dest[(w << 1) + 0] = src1[w];
+dest[(w << 1) + 1] = src2[w];
+}
+dest += dstStride;
+src1 += src1Stride;
+src2 += src2Stride;
+}
+}
diff --git a/libswscale/loongarch/swscale_init_loongarch.c 
b/libswscale/loongarch/swscale_init_loongarch.c
index 197dc6e1e7..1e0bb1b116 100644
--- a/libswscale/loongarch/swscale_init_loongarch.c
+++ b/libswscale/loongarch/swscale_init_loongarch.c
@@ -21,6 +21,7 @@
 
 #include "swscale_loongarch.h"
 #include "libswscale/swscale_internal.h"
+#include "libswscale/rgb2rgb.h"
 #include "libavutil/loongarch/cpu.h"
 
 av_cold void ff_sws_init_swscale_loongarch(SwsContext *c)
@@ -48,3 +49,44 @@ av_cold void ff_sws_init_swscale_loongarch(SwsContext *c)
 }
 }
 }
+
+av_cold void rgb2rgb_init_loongarch(void)
+{
+int cpu_flags = av_get_cpu_flags();
+if (have_lasx(cpu_flags))
+interleaveBytes = ff_interleave_bytes_lasx;
+}
+
+av_cold SwsFunc ff_yuv2rgb_init_loongarch(SwsContext *c)
+{
+int cpu_flags = av_get_cpu_flags();
+if (have_lasx(cpu_flags)) {
+switch (c->dstFormat) {
+case AV_PIX_FMT_RGB24:
+return yuv420_rgb24_lasx;
+case AV_PIX_FMT_BGR24:
+return yuv420_bgr24_lasx;
+case AV_PIX_FMT_RGBA:
+if (CONFIG_SWSCALE_ALPHA && isALPHA(c->srcFormat)) {
+break;
+} else
+return yuv420_rgba32_lasx;
+case AV_PIX_FMT_ARGB:
+if (CONFIG_SWSCALE_ALPHA && isALPHA(c->srcFormat)) {
+break;
+} else
+return yuv420_argb32_lasx;
+case AV_PIX_FMT_BGRA:
+if (CONFIG_SWSCALE_ALPHA && isALPH

[FFmpeg-devel] [PATCH v1 3/3] swscale/la: Add output_lasx.c file.

[Hao Chen]

ffmpeg -i ~/media/1_h264_1080p_30fps_3Mbps.mp4 -f rawvideo -s 640x480 -pix_fmt
rgb24 -y /dev/null -an
before: 150fps
after:  183fps

Signed-off-by: Hao Chen 
---
 libswscale/loongarch/Makefile |3 +-
 libswscale/loongarch/output_lasx.c| 1982 +
 libswscale/loongarch/swscale_init_loongarch.c |3 +
 libswscale/loongarch/swscale_loongarch.h  |6 +
 4 files changed, 1993 insertions(+), 1 deletion(-)
 create mode 100644 libswscale/loongarch/output_lasx.c

diff --git a/libswscale/loongarch/Makefile b/libswscale/loongarch/Makefile
index 4345971514..54d48b3de0 100644
--- a/libswscale/loongarch/Makefile
+++ b/libswscale/loongarch/Makefile
@@ -2,4 +2,5 @@ OBJS-$(CONFIG_SWSCALE)  += 
loongarch/swscale_init_loongarch.o
 LASX-OBJS-$(CONFIG_SWSCALE) += loongarch/swscale_lasx.o \
loongarch/input_lasx.o   \
loongarch/yuv2rgb_lasx.o \
-   loongarch/rgb2rgb_lasx.o
+   loongarch/rgb2rgb_lasx.o \
+  
loongarch/output_lasx.o
diff --git a/libswscale/loongarch/output_lasx.c 
b/libswscale/loongarch/output_lasx.c
new file mode 100644
index 00..19f82692ff
--- /dev/null
+++ b/libswscale/loongarch/output_lasx.c
@@ -0,0 +1,1982 @@
+/*
+ * Copyright (C) 2022 Loongson Technology Corporation Limited
+ * Contributed by Hao Chen(chen...@loongson.cn)
+ *
+ * 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 "swscale_loongarch.h"
+#include "libavutil/loongarch/loongson_intrinsics.h"
+
+void ff_yuv2planeX_8_lasx(const int16_t *filter, int filterSize,
+  const int16_t **src, uint8_t *dest, int dstW,
+  const uint8_t *dither, int offset)
+{
+int i;
+int len = dstW - 15;
+__m256i mask = {0x1C0C180814041000, 0x1C1814100C080400,
+0x1C0C180814041000, 0x1C1814100C080400};
+__m256i val1, val2, val3;
+uint8_t dither0 = dither[offset & 7];
+uint8_t dither1 = dither[(offset + 1) & 7];
+uint8_t dither2 = dither[(offset + 2) & 7];
+uint8_t dither3 = dither[(offset + 3) & 7];
+uint8_t dither4 = dither[(offset + 4) & 7];
+uint8_t dither5 = dither[(offset + 5) & 7];
+uint8_t dither6 = dither[(offset + 6) & 7];
+uint8_t dither7 = dither[(offset + 7) & 7];
+int val_1[8] = {dither0, dither2, dither4, dither6,
+dither0, dither2, dither4, dither6};
+int val_2[8] = {dither1, dither3, dither5, dither7,
+dither1, dither3, dither5, dither7};
+int val_3[8] = {dither0, dither1, dither2, dither3,
+dither4, dither5, dither6, dither7};
+
+DUP2_ARG2(__lasx_xvld, val_1, 0, val_2, 0, val1, val2);
+val3 = __lasx_xvld(val_3, 0);
+
+for (i = 0; i < len; i += 16) {
+int j;
+__m256i src0, filter0, val;
+__m256i val_ev, val_od;
+
+val_ev = __lasx_xvslli_w(val1, 12);
+val_od = __lasx_xvslli_w(val2, 12);
+
+for (j = 0; j < filterSize; j++) {
+src0  = __lasx_xvld(src[j]+ i, 0);
+filter0 = __lasx_xvldrepl_h((filter + j), 0);
+val_ev = __lasx_xvmaddwev_w_h(val_ev, src0, filter0);
+val_od = __lasx_xvmaddwod_w_h(val_od, src0, filter0);
+}
+val_ev = __lasx_xvsrai_w(val_ev, 19);
+val_od = __lasx_xvsrai_w(val_od, 19);
+val_ev = __lasx_xvclip255_w(val_ev);
+val_od = __lasx_xvclip255_w(val_od);
+val= __lasx_xvshuf_b(val_od, val_ev, mask);
+__lasx_xvstelm_d(val, (dest + i), 0, 0);
+__lasx_xvstelm_d(val, (dest + i), 8, 2);
+}
+if (dstW - i >= 8){
+int j;
+__m256i src0, filter0, val_h;
+__m256i val_l;
+
+val_l = __lasx_xvslli_w(val3, 12);
+
+for (j = 0; j < filterSize; j++) {
+src0  = __lasx_xvld(src[j] + i, 0);
+src0  = __lasx_vext2xv_w_h(src0);
+filter0 = __lasx_xvldrepl_h((filter + j), 0);
+filter0 = __lasx_vext2xv_w_h(filter0);
+val_l = __lasx_xvmadd_w(val_l, src0, filter0);
+}
+val_l = __lasx_xvsrai_w(val_l, 19);
+val_l = __lasx_xvclip255_w(val_

Re: [FFmpeg-devel] [PATCH v1 3/3] swscale/la: Add output_lasx.c file.

[Andreas Rheinhardt]

Hao Chen:
> ffmpeg -i ~/media/1_h264_1080p_30fps_3Mbps.mp4 -f rawvideo -s 640x480 -pix_fmt
> rgb24 -y /dev/null -an
> before: 150fps
> after:  183fps
> 
> Signed-off-by: Hao Chen 
> ---
>  libswscale/loongarch/Makefile |3 +-
>  libswscale/loongarch/output_lasx.c| 1982 +
>  libswscale/loongarch/swscale_init_loongarch.c |3 +
>  libswscale/loongarch/swscale_loongarch.h  |6 +
>  4 files changed, 1993 insertions(+), 1 deletion(-)
>  create mode 100644 libswscale/loongarch/output_lasx.c
> 
> diff --git a/libswscale/loongarch/Makefile b/libswscale/loongarch/Makefile
> index 4345971514..54d48b3de0 100644
> --- a/libswscale/loongarch/Makefile
> +++ b/libswscale/loongarch/Makefile
> @@ -2,4 +2,5 @@ OBJS-$(CONFIG_SWSCALE)  += 
> loongarch/swscale_init_loongarch.o
>  LASX-OBJS-$(CONFIG_SWSCALE) += loongarch/swscale_lasx.o \
> loongarch/input_lasx.o   \
> loongarch/yuv2rgb_lasx.o \
> -   loongarch/rgb2rgb_lasx.o
> +   loongarch/rgb2rgb_lasx.o \
> +
> loongarch/output_lasx.o
> diff --git a/libswscale/loongarch/output_lasx.c 
> b/libswscale/loongarch/output_lasx.c
> new file mode 100644
> index 00..19f82692ff
> --- /dev/null
> +++ b/libswscale/loongarch/output_lasx.c
> @@ -0,0 +1,1982 @@
> +/*
> + * Copyright (C) 2022 Loongson Technology Corporation Limited
> + * Contributed by Hao Chen(chen...@loongson.cn)
> + *
> + * 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 "swscale_loongarch.h"
> +#include "libavutil/loongarch/loongson_intrinsics.h"
> +
> +void ff_yuv2planeX_8_lasx(const int16_t *filter, int filterSize,
> +  const int16_t **src, uint8_t *dest, int dstW,
> +  const uint8_t *dither, int offset)
> +{
> +int i;
> +int len = dstW - 15;
> +__m256i mask = {0x1C0C180814041000, 0x1C1814100C080400,
> +0x1C0C180814041000, 0x1C1814100C080400};
> +__m256i val1, val2, val3;
> +uint8_t dither0 = dither[offset & 7];
> +uint8_t dither1 = dither[(offset + 1) & 7];
> +uint8_t dither2 = dither[(offset + 2) & 7];
> +uint8_t dither3 = dither[(offset + 3) & 7];
> +uint8_t dither4 = dither[(offset + 4) & 7];
> +uint8_t dither5 = dither[(offset + 5) & 7];
> +uint8_t dither6 = dither[(offset + 6) & 7];
> +uint8_t dither7 = dither[(offset + 7) & 7];
> +int val_1[8] = {dither0, dither2, dither4, dither6,
> +dither0, dither2, dither4, dither6};
> +int val_2[8] = {dither1, dither3, dither5, dither7,
> +dither1, dither3, dither5, dither7};
> +int val_3[8] = {dither0, dither1, dither2, dither3,
> +dither4, dither5, dither6, dither7};
> +
> +DUP2_ARG2(__lasx_xvld, val_1, 0, val_2, 0, val1, val2);
> +val3 = __lasx_xvld(val_3, 0);
> +
> +for (i = 0; i < len; i += 16) {
> +int j;
> +__m256i src0, filter0, val;
> +__m256i val_ev, val_od;
> +
> +val_ev = __lasx_xvslli_w(val1, 12);
> +val_od = __lasx_xvslli_w(val2, 12);
> +
> +for (j = 0; j < filterSize; j++) {
> +src0  = __lasx_xvld(src[j]+ i, 0);
> +filter0 = __lasx_xvldrepl_h((filter + j), 0);
> +val_ev = __lasx_xvmaddwev_w_h(val_ev, src0, filter0);
> +val_od = __lasx_xvmaddwod_w_h(val_od, src0, filter0);
> +}
> +val_ev = __lasx_xvsrai_w(val_ev, 19);
> +val_od = __lasx_xvsrai_w(val_od, 19);
> +val_ev = __lasx_xvclip255_w(val_ev);
> +val_od = __lasx_xvclip255_w(val_od);
> +val= __lasx_xvshuf_b(val_od, val_ev, mask);
> +__lasx_xvstelm_d(val, (dest + i), 0, 0);
> +__lasx_xvstelm_d(val, (dest + i), 8, 2);
> +}
> +if (dstW - i >= 8){
> +int j;
> +__m256i src0, filter0, val_h;
> +__m256i val_l;
> +
> +val_l = __lasx_xvslli_w(val3, 12);
> +
> +for (j = 0; j < filterSize; j++) {
> +src0  = __lasx_xvld(src[j] + i, 0);
> +src0  = __lasx_vext2xv_w_h(src0);
> +filter0

Re: [FFmpeg-devel] [PATCH v3] avcodec/videotoolboxenc: Add CBR option to H264 and HEVC encoder

[Rick Kern]

On Sun, Aug 28, 2022 at 4:27 PM Sebastian Beckmann <
beckmann.sebast...@outlook.de> wrote:

> Adds an option to use constant bitrate instead of average bitrate to the
> videotoolbox encoders. This is enabled via -constant_bit_rate true.
> macOS 13 is required for this option to work.
>
> Signed-off-by: Sebastian Beckmann 
> ---
> Removed the hard-coded check for Apple Silicon CPUs.
>
> libavcodec/videotoolboxenc.c | 27 ---
> 1 file changed, 24 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
> index 823e5ad94e..9de86cc4d9 100644
> --- a/libavcodec/videotoolboxenc.c
> +++ b/libavcodec/videotoolboxenc.c
> @@ -101,6 +101,7 @@ static struct{
> CFStringRef kVTCompressionPropertyKey_RealTime;
> CFStringRef kVTCompressionPropertyKey_TargetQualityForAlpha;
> CFStringRef
> kVTCompressionPropertyKey_PrioritizeEncodingSpeedOverQuality;
> +CFStringRef kVTCompressionPropertyKey_ConstantBitRate;
>
> CFStringRef
> kVTVideoEncoderSpecification_EnableHardwareAcceleratedVideoEncoder;
> CFStringRef
> kVTVideoEncoderSpecification_RequireHardwareAcceleratedVideoEncoder;
> @@ -164,6 +165,7 @@ static void loadVTEncSymbols(){
> "TargetQualityForAlpha");
> GET_SYM(kVTCompressionPropertyKey_PrioritizeEncodingSpeedOverQuality,
> "PrioritizeEncodingSpeedOverQuality");
> +GET_SYM(kVTCompressionPropertyKey_ConstantBitRate, "ConstantBitRate");
>
>
> GET_SYM(kVTVideoEncoderSpecification_EnableHardwareAcceleratedVideoEncoder,
> "EnableHardwareAcceleratedVideoEncoder");
> @@ -236,6 +238,7 @@ typedef struct VTEncContext {
> int realtime;
> int frames_before;
> int frames_after;
> +bool constant_bit_rate;
>
> int allow_sw;
> int require_sw;
> @@ -1079,6 +1082,7 @@ static int vtenc_create_encoder(AVCodecContext
>  *avctx,
> CFNumberRef  gamma_level,
> CFDictionaryRef  enc_info,
> CFDictionaryRef  pixel_buffer_info,
> +bool constant_bit_rate,
> VTCompressionSessionRef *session)
> {
> VTEncContext *vtctx = avctx->priv_data;
> @@ -1139,9 +1143,20 @@ static int vtenc_create_encoder(AVCodecContext
>  *avctx,
>   &bit_rate);
> if (!bit_rate_num) return AVERROR(ENOMEM);
>
> -status = VTSessionSetProperty(vtctx->session,
> -
> kVTCompressionPropertyKey_AverageBitRate,
> -  bit_rate_num);
> +if (constant_bit_rate) {
> +status = VTSessionSetProperty(vtctx->session,
> +
> compat_keys.kVTCompressionPropertyKey_ConstantBitRate,
> +  bit_rate_num);
> +if (status == kVTPropertyNotSupportedErr) {
> +av_log(avctx, AV_LOG_ERROR, "Error: -constant_bit_rate
> true is not supported by the encoder.\n");
> +return AVERROR_EXTERNAL;
> +}
> +} else {
> +status = VTSessionSetProperty(vtctx->session,
> +
> kVTCompressionPropertyKey_AverageBitRate,
> +  bit_rate_num);
> +}
> +
> CFRelease(bit_rate_num);
> }
>
> @@ -1530,6 +1545,7 @@ static int vtenc_configure_encoder(AVCodecContext
> *avctx)
>   gamma_level,
>   enc_info,
>   pixel_buffer_info,
> +  vtctx->constant_bit_rate,
>   &vtctx->session);
>
> init_cleanup:
> @@ -2532,6 +2548,7 @@ static int vtenc_populate_extradata(AVCodecContext
>  *avctx,
>   gamma_level,
>   enc_info,
>   pixel_buffer_info,
> +  vtctx->constant_bit_rate,
>   &vtctx->session);
> if (status)
> goto pe_cleanup;
> @@ -2727,6 +2744,8 @@ static const AVOption h264_options[] = {
>
> { "a53cc", "Use A53 Closed Captions (if available)", OFFSET(a53_cc),
> AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, VE },
>
> +{ "constant_bit_rate", "Require constant bit rate (macOS 13 or
> newer)", OFFSET(constant_bit_rate), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1,
> VE },
> +
> COMMON_OPTIONS
> { NULL },
> };
> @@ -2760,6 +2779,8 @@ static const AVOption hevc_options[] = {
>
> { "alpha_quality", "Compression quality for the alpha channel",
> OFFSET(alpha_quality), AV_OPT_TYPE_DOUBLE, { .dbl = 0.0 }, 0.0, 1.0, VE },
>
> +{ "constant_bit_rate", "Require constant bit rate (macOS 13 or
> newer)", OFFSET(constant_bit_rate), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1,
> VE },
> +
> COMMON_OPTIONS
> { NULL },
> };
> --
> 2.37.0 (Apple Git-136)
>

The patch doesn't apply. Can you create a .patch file with git format-patch

Re: [FFmpeg-devel] [PATCH v3] avcodec/videotoolboxenc: Add CBR option to H264 and HEVC encoder

[Sebastian Beckmann]

> The patch doesn't apply. Can you create a .patch file with git format-patch
> and send the file as an attachment? Sometimes email clients/providers
> corrupt inline patches.



v3-0001-avcodec-videotoolboxenc-Add-CBR-option-to-H264-an.patch
Description: v3-0001-avcodec-videotoolboxenc-Add-CBR-option-to-H264-an.patch
___
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] avcodec/videotoolboxenc: Add CBR option to H264 and HEVC encoder

[Rick Kern]

On Mon, Aug 29, 2022 at 9:05 AM Sebastian Beckmann <
beckmann.sebast...@outlook.de> wrote:

>
> > The patch doesn't apply. Can you create a .patch file with git
> format-patch
> > and send the file as an attachment? Sometimes email clients/providers
> > corrupt inline patches.
>

Thanks, pushed.


>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel 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 18/18] avcodec/codec_internal: Add macros for update_thread_context(_for_user)

[Andreas Rheinhardt]

It reduces typing: Before this patch, there were 11 callbacks
that exceeded the 80 char line length limit; now there are zero.
It also allows to remove ONLY_IF_THREADS_ENABLED() in
libavutil/internal.h.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/cfhd.c   |  2 +-
 libavcodec/codec_internal.h | 12 
 libavcodec/ffv1dec.c|  2 +-
 libavcodec/h264dec.c|  4 ++--
 libavcodec/hevcdec.c|  2 +-
 libavcodec/mimic.c  |  2 +-
 libavcodec/mpeg12dec.c  |  2 +-
 libavcodec/mpeg4videodec.c  |  4 ++--
 libavcodec/pngdec.c |  4 ++--
 libavcodec/proresdec2.c |  2 +-
 libavcodec/rv30.c   |  2 +-
 libavcodec/rv40.c   |  2 +-
 libavcodec/takdec.c |  2 +-
 libavcodec/vp3.c|  6 +++---
 libavcodec/vp8.c|  2 +-
 libavcodec/vp9.c|  2 +-
 libavcodec/wavpack.c|  2 +-
 libavutil/internal.h| 11 ---
 18 files changed, 33 insertions(+), 32 deletions(-)

diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
index 9eaac9ecfd..1af9cd44a9 100644
--- a/libavcodec/cfhd.c
+++ b/libavcodec/cfhd.c
@@ -1464,7 +1464,7 @@ const FFCodec ff_cfhd_decoder = {
 .init = cfhd_init,
 .close= cfhd_close,
 FF_CODEC_DECODE_CB(cfhd_decode),
-.update_thread_context = ONLY_IF_THREADS_ENABLED(update_thread_context),
+UPDATE_THREAD_CONTEXT(update_thread_context),
 .p.capabilities   = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
 .caps_internal= FF_CODEC_CAP_INIT_CLEANUP,
 };
diff --git a/libavcodec/codec_internal.h b/libavcodec/codec_internal.h
index 310e243d84..2d9b4f6460 100644
--- a/libavcodec/codec_internal.h
+++ b/libavcodec/codec_internal.h
@@ -264,6 +264,18 @@ typedef struct FFCodec {
 #define CODEC_LONG_NAME(str) .p.long_name = str
 #endif
 
+#if HAVE_THREADS
+#define UPDATE_THREAD_CONTEXT(func) \
+.update_thread_context  = (func)
+#define UPDATE_THREAD_CONTEXT_FOR_USER(func) \
+.update_thread_context_for_user = (func)
+#else
+#define UPDATE_THREAD_CONTEXT(func) \
+.update_thread_context  = NULL
+#define UPDATE_THREAD_CONTEXT_FOR_USER(func) \
+.update_thread_context_for_user = NULL
+#endif
+
 #define FF_CODEC_DECODE_CB(func)  \
 .cb_type   = FF_CODEC_CB_TYPE_DECODE, \
 .cb.decode = (func)
diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
index 2fc8941362..794c58cc40 100644
--- a/libavcodec/ffv1dec.c
+++ b/libavcodec/ffv1dec.c
@@ -1077,7 +1077,7 @@ const FFCodec ff_ffv1_decoder = {
 .init   = decode_init,
 .close  = ff_ffv1_close,
 FF_CODEC_DECODE_CB(decode_frame),
-.update_thread_context = ONLY_IF_THREADS_ENABLED(update_thread_context),
+UPDATE_THREAD_CONTEXT(update_thread_context),
 .p.capabilities = AV_CODEC_CAP_DR1 /*| AV_CODEC_CAP_DRAW_HORIZ_BAND*/ |
   AV_CODEC_CAP_FRAME_THREADS | AV_CODEC_CAP_SLICE_THREADS,
 .caps_internal  = FF_CODEC_CAP_INIT_CLEANUP |
diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index 3cef3f39f5..8f56f3ff92 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec/h264dec.c
@@ -1105,8 +1105,8 @@ const FFCodec ff_h264_decoder = {
 .caps_internal = FF_CODEC_CAP_EXPORTS_CROPPING |
  FF_CODEC_CAP_ALLOCATE_PROGRESS | 
FF_CODEC_CAP_INIT_CLEANUP,
 .flush = h264_decode_flush,
-.update_thread_context = 
ONLY_IF_THREADS_ENABLED(ff_h264_update_thread_context),
-.update_thread_context_for_user = 
ONLY_IF_THREADS_ENABLED(ff_h264_update_thread_context_for_user),
+UPDATE_THREAD_CONTEXT(ff_h264_update_thread_context),
+UPDATE_THREAD_CONTEXT_FOR_USER(ff_h264_update_thread_context_for_user),
 .p.profiles= NULL_IF_CONFIG_SMALL(ff_h264_profiles),
 .p.priv_class  = &h264_class,
 };
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 91bafa2114..90961f87be 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -3854,7 +3854,7 @@ const FFCodec ff_hevc_decoder = {
 .close = hevc_decode_free,
 FF_CODEC_DECODE_CB(hevc_decode_frame),
 .flush = hevc_decode_flush,
-.update_thread_context = 
ONLY_IF_THREADS_ENABLED(hevc_update_thread_context),
+UPDATE_THREAD_CONTEXT(hevc_update_thread_context),
 .p.capabilities= AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY |
  AV_CODEC_CAP_SLICE_THREADS | 
AV_CODEC_CAP_FRAME_THREADS,
 .caps_internal = FF_CODEC_CAP_EXPORTS_CROPPING |
diff --git a/libavcodec/mimic.c b/libavcodec/mimic.c
index c506a42322..1d4f2b85c1 100644
--- a/libavcodec/mimic.c
+++ b/libavcodec/mimic.c
@@ -446,7 +446,7 @@ const FFCodec ff_mimic_decoder = {
 .close = mimic_decode_end,
 FF_CODEC_DECODE_CB(mimic_decode_frame),
 .p.capabilities= AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
-.update_thread_context = 
ONLY_I

Re: [FFmpeg-devel] [PATCH 1/2] lavu/hwcontext_qsv: add support for AV_PIX_FMT_VUYX

[Xiang, Haihao]

On Mon, 2022-08-29 at 08:17 -0300, James Almer wrote:
> On 8/29/2022 4:27 AM, Xiang, Haihao wrote:
> > From: Haihao Xiang 
> > 
> > AV_PIX_FMT_VUYX is used in FFmpeg for 8bit 4:4:4 content on Intel HW,
> > and MFX_FOURCC_AYUV is used in the SDK
> 
> Sounds like you want the VUYA pixfmt instead.

AV_PIX_FMT_VUYX is used for 4:4:4 content in the VAAPI path, AV_PIX_FMT_VUYX is
expected when creating vaapi urface. QSV is based on 
VAAPI under Linux, so AV_PIX_FMT_VUYX is expected too in the QSV path when
creating vaapi surface.

> 
> > ---
> >   libavutil/hwcontext_qsv.c | 8 
> >   1 file changed, 8 insertions(+)
> > 
> > diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
> > index 510f422562..a3350eae0f 100644
> > --- a/libavutil/hwcontext_qsv.c
> > +++ b/libavutil/hwcontext_qsv.c
> > @@ -119,6 +119,8 @@ static const struct {
> >  MFX_FOURCC_YUY2 },
> >   { AV_PIX_FMT_Y210,
> >  MFX_FOURCC_Y210 },
> > +{ AV_PIX_FMT_VUYX,
> > +   MFX_FOURCC_AYUV },
> >   #endif
> >   };
> >   
> > @@ -1502,6 +1504,12 @@ static int map_frame_to_surface(const AVFrame *frame,
> > mfxFrameSurface1 *surface)
> >   surface->Data.U16 = (mfxU16 *)frame->data[0] + 1;
> >   surface->Data.V16 = (mfxU16 *)frame->data[0] + 3;
> >   break;
> > +case AV_PIX_FMT_VUYX:
> > +surface->Data.V = frame->data[0];
> > +surface->Data.U = frame->data[0] + 1;
> > +surface->Data.Y = frame->data[0] + 2;
> > +surface->Data.A = frame->data[0] + 3;
> 
> This will go wrong with VUYX. You need to use AV_PIX_FMT_VUYA.

frame->data[0] + 3 is valid even if alpha channel is ignored in VUYX. Intel HW
doesn't use the data in alpha channel actually, but the SDK uses Microsoft pixel
format AYUV which is the alpha version, here set a valid address to alpha
channel when mapping a VUYX AVFrame to a AYUV mfx surface. 

Thanks
Haihao

> 
> > +break;
> >   #endif
> >   default:
> >   return MFX_ERR_UNSUPPORTED;
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 3/3] lavu/fifo: clarify interaction of AV_FIFO_FLAG_AUTO_GROW with av_fifo_write()

[Anton Khirnov]

---
 libavutil/fifo.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavutil/fifo.h b/libavutil/fifo.h
index 89872d0972..70f9376d97 100644
--- a/libavutil/fifo.h
+++ b/libavutil/fifo.h
@@ -124,9 +124,12 @@ int av_fifo_grow2(AVFifo *f, size_t inc);
 /**
  * Write data into a FIFO.
  *
- * In case nb_elems > av_fifo_can_write(f), nothing is written and an error
+ * In case nb_elems > av_fifo_can_write(f) and the AV_FIFO_FLAG_AUTO_GROW flag
+ * was not specified at FIFO creation, nothing is written and an error
  * is returned.
  *
+ * Calling function is guaranteed to succeed if nb_elems <= 
av_fifo_can_write(f).
+ *
  * @param f the FIFO buffer
  * @param buf Data to be written. nb_elems * av_fifo_elem_size(f) bytes will be
  *read from buf on success.
-- 
2.35.1

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

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

[FFmpeg-devel] [PATCH 1/3] lavu/fifo: add the header to its own doxy group

[Anton Khirnov]

Also, drop mentions of it being a circular buffer, as this is an
internal implementation detail that should be invisible to the caller.
---
 libavutil/fifo.h | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/libavutil/fifo.h b/libavutil/fifo.h
index 4eed364afc..6c6bd78842 100644
--- a/libavutil/fifo.h
+++ b/libavutil/fifo.h
@@ -18,7 +18,8 @@
 
 /**
  * @file
- * a very simple circular buffer FIFO implementation
+ * @ingroup lavu_fifo
+ * A generic FIFO API
  */
 
 #ifndef AVUTIL_FIFO_H
@@ -30,6 +31,14 @@
 #include "attributes.h"
 #include "version.h"
 
+/**
+ * @defgroup lavu_fifo AVFifo
+ * @ingroup lavu_data
+ *
+ * @{
+ * A generic FIFO API
+ */
+
 typedef struct AVFifo AVFifo;
 
 /**
@@ -423,4 +432,8 @@ static inline uint8_t *av_fifo_peek2(const AVFifoBuffer *f, 
int offs)
 #endif
 #endif
 
+/**
+ * @}
+ */
+
 #endif /* AVUTIL_FIFO_H */
-- 
2.35.1

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

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

[FFmpeg-devel] [PATCH 2/3] lavu/fifo: clarify interaction of AV_FIFO_FLAG_AUTO_GROW with av_fifo_can_write()

[Anton Khirnov]

---
 libavutil/fifo.h | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/libavutil/fifo.h b/libavutil/fifo.h
index 6c6bd78842..89872d0972 100644
--- a/libavutil/fifo.h
+++ b/libavutil/fifo.h
@@ -97,7 +97,13 @@ void av_fifo_auto_grow_limit(AVFifo *f, size_t max_elems);
 size_t av_fifo_can_read(const AVFifo *f);
 
 /**
- * @return number of elements that can be written into the given FIFO.
+ * @return Number of elements that can be written into the given FIFO without
+ * growing it.
+ *
+ * In other words, this number of elements or less is guaranteed to fit
+ * into the FIFO. More data may be written when the
+ * AV_FIFO_FLAG_AUTO_GROW flag was specified at FIFO creation, but this
+ * may involve memory allocation, which can fail.
  */
 size_t av_fifo_can_write(const AVFifo *f);
 
-- 
2.35.1

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

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

[FFmpeg-devel] Matroska and output_ts_offset

[Peter Zebühr]

Hello,

I noticed the other day that if I try to mux opus in webm with a timestamp 
offset set I don't get the expected timestamps out on my packets. Example:

ffmpeg -f lavfi -i "sine=frequency=1000:duration=60" -output_ts_offset 
200ms -c:a libopus sine_200ms_offset.webm

Now if I inspect the packets with ffprobe on the produced output the first 
packet has a PTS of 186. My expectation would be that it would be: 200 - 6.5 
(opus encoder delay) ~= 193.
Looking at the output with mkvinfo also indicates that it starts at 193ms (186 
+ encoder delay I assume here).

At first I thought it looked like the encoder delay gets added twice, but after 
some more pondering I think what is happening here is:

1. Opus outputs packets starting with the priming samples, that ends up with a 
negative PTS (rounded to -7)
2. In mux.c the output_ts_offset takes effect before the call to 
"handle_avoid_negative_ts"
3. PTS -7 gets shifter by the requested ts_offset to 193
4. Matroska muxer writes the side data about encoder delay. 
5. The produced stream now effectively starts one encoder delay distance too 
early.

I played around locally with moving the call to "handle_avoid_negative_ts" in 
mux.c/write_packet to right before the ts_offset handling instead of right 
after and that seems to fix this particular problem. But, I am unsure what 
other potential consequences that would have. Would appreciate if someone more 
familiar with this can help fix this issue.

Regards,
Peter
___
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] Matroska and output_ts_offset

[Andreas Rheinhardt]

Peter Zebühr:
> Hello,
> 
> I noticed the other day that if I try to mux opus in webm with a timestamp 
> offset set I don't get the expected timestamps out on my packets. Example:
> 
>   ffmpeg -f lavfi -i "sine=frequency=1000:duration=60" -output_ts_offset 
> 200ms -c:a libopus sine_200ms_offset.webm
> 
> Now if I inspect the packets with ffprobe on the produced output the first 
> packet has a PTS of 186. My expectation would be that it would be: 200 - 6.5 
> (opus encoder delay) ~= 193.
> Looking at the output with mkvinfo also indicates that it starts at 193ms 
> (186 + encoder delay I assume here).
> 
> At first I thought it looked like the encoder delay gets added twice, but 
> after some more pondering I think what is happening here is:
> 
> 1. Opus outputs packets starting with the priming samples, that ends up with 
> a negative PTS (rounded to -7)
> 2. In mux.c the output_ts_offset takes effect before the call to 
> "handle_avoid_negative_ts"
> 3. PTS -7 gets shifter by the requested ts_offset to 193
> 4. Matroska muxer writes the side data about encoder delay. 
> 5. The produced stream now effectively starts one encoder delay distance too 
> early.
> 
> I played around locally with moving the call to "handle_avoid_negative_ts" in 
> mux.c/write_packet to right before the ts_offset handling instead of right 
> after and that seems to fix this particular problem. But, I am unsure what 
> other potential consequences that would have. Would appreciate if someone 
> more familiar with this can help fix this issue.
> 

The Matroska muxer is buggy wrt. to the ts_offset relating to codec
delay. You can see it in lines 1839-1841 which are commented out.
Commenting them out happened in commit
82e4f39883932c1b1e5c7792a1be12dec6ab603d, merging the libav commit that
implemented it (namely
https://github.com/FFmpeg/FFmpeg/commit/a1aa37dd0b96710d4a17718198a3f56aea2040c1).
It mentions "assertion failures and av sync errors". I can only think of
one way that it could have led to assertion failures, but this should
have been fixed in 4ebeab15b037a21f195696cef1f7522daf42f3ee (and since
then I wondered whether it can't be enabled).

- 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] [PATCH 1/2] avformat/file: Add a specialized url_check callback for pipe protocol

[Neil Roberts]

Using file_check for the pipe protocol doesn't make sense. For example,
for a URL like “pipe:0” it would end up checking whether the “pipe:0”
file exists. This patch instead makes it check the access modes on the
corresponding file descriptor using fcntl.

Signed-off-by: Neil Roberts 
---
 libavformat/file.c | 40 +---
 1 file changed, 37 insertions(+), 3 deletions(-)

diff --git a/libavformat/file.c b/libavformat/file.c
index 98c9e81bcb..f17d219cb2 100644
--- a/libavformat/file.c
+++ b/libavformat/file.c
@@ -375,9 +375,8 @@ const URLProtocol ff_file_protocol = {
 
 #if CONFIG_PIPE_PROTOCOL
 
-static int pipe_open(URLContext *h, const char *filename, int flags)
+static int pipe_get_fd(const char *filename, int flags)
 {
-FileContext *c = h->priv_data;
 int fd;
 char *final;
 av_strstart(filename, "pipe:", &filename);
@@ -390,6 +389,14 @@ static int pipe_open(URLContext *h, const char *filename, 
int flags)
 fd = 0;
 }
 }
+
+return fd;
+}
+
+static int pipe_open(URLContext *h, const char *filename, int flags)
+{
+FileContext *c = h->priv_data;
+int fd = pipe_get_fd(filename, flags);
 #if HAVE_SETMODE
 setmode(fd, O_BINARY);
 #endif
@@ -398,13 +405,40 @@ static int pipe_open(URLContext *h, const char *filename, 
int flags)
 return 0;
 }
 
+static int pipe_check(URLContext *h, int mask)
+{
+int fd = pipe_get_fd(h->filename, mask);
+int status_flags = fcntl(fd, F_GETFL);
+int access;
+
+if (status_flags == -1)
+return AVERROR(errno);
+
+switch (status_flags & O_ACCMODE) {
+case O_RDONLY:
+access = AVIO_FLAG_READ;
+break;
+case O_WRONLY:
+access = AVIO_FLAG_WRITE;
+break;
+case O_RDWR:
+access = AVIO_FLAG_READ | AVIO_FLAG_WRITE;
+break;
+default:
+access = 0;
+break;
+}
+
+return access & mask;
+}
+
 const URLProtocol ff_pipe_protocol = {
 .name= "pipe",
 .url_open= pipe_open,
 .url_read= file_read,
 .url_write   = file_write,
 .url_get_file_handle = file_get_handle,
-.url_check   = file_check,
+.url_check   = pipe_check,
 .priv_data_size  = sizeof(FileContext),
 .priv_data_class = &pipe_class,
 .default_whitelist   = "crypto,data"
-- 
2.37.2

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

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

[FFmpeg-devel] [PATCH 2/2] avformat/tests: Add a test for avio_check with the pipe protocol

[Neil Roberts]

Creates a UNIX pipe and then verifies that avio_check returns the right
access flags for the two ends of the pipe.

Signed-off-by: Neil Roberts 
---
 libavformat/Makefile |   1 +
 libavformat/tests/.gitignore |   1 +
 libavformat/tests/pipe.c | 101 +++
 tests/fate/libavformat.mak   |   5 ++
 4 files changed, 108 insertions(+)
 create mode 100644 libavformat/tests/pipe.c

diff --git a/libavformat/Makefile b/libavformat/Makefile
index f67a99f839..9c681c58c5 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -732,6 +732,7 @@ TESTPROGS-$(CONFIG_MOV_MUXER)+= movenc
 TESTPROGS-$(CONFIG_NETWORK)  += noproxy
 TESTPROGS-$(CONFIG_SRTP) += srtp
 TESTPROGS-$(CONFIG_IMF_DEMUXER)  += imf
+TESTPROGS-$(CONFIG_PIPE_PROTOCOL)+= pipe
 
 TOOLS = aviocat \
 ismindex\
diff --git a/libavformat/tests/.gitignore b/libavformat/tests/.gitignore
index cdd0cce061..567d6f9e40 100644
--- a/libavformat/tests/.gitignore
+++ b/libavformat/tests/.gitignore
@@ -7,3 +7,4 @@
 /srtp
 /url
 /seek_utils
+/pipe
diff --git a/libavformat/tests/pipe.c b/libavformat/tests/pipe.c
new file mode 100644
index 00..68540c1a8c
--- /dev/null
+++ b/libavformat/tests/pipe.c
@@ -0,0 +1,101 @@
+/*
+ * Copyright (c) 2022 Neil Roberts
+ *
+ * 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 
+#include 
+#include 
+#include "libavformat/avio.h"
+#include "libavutil/error.h"
+
+static int check_pipe(const char *url, int mask, int expected)
+{
+int flags = avio_check(url, mask);
+
+if (flags < 0) {
+fprintf(stderr,
+"avio_check for %s with mask 0x%x failed: %s\n",
+url,
+mask,
+av_err2str(flags));
+return 0;
+}
+
+if (flags != expected) {
+fprintf(stderr,
+"Wrong result returned from avio_check for %s with mask 0x%x. "
+"Expected 0x%x but received 0x%x\n",
+url,
+mask,
+flags,
+expected);
+return 0;
+}
+
+return 1;
+}
+
+int main(int argc, char **argv)
+{
+int ret = 0;
+int pipe_fds[2];
+char read_url[20], write_url[20];
+int check_invalid_ret;
+
+if (pipe(pipe_fds) == -1) {
+fprintf(stderr, "error creating pipe: %s\n", strerror(errno));
+return 1;
+}
+
+snprintf(read_url, sizeof(read_url), "pipe:%d", pipe_fds[0]);
+snprintf(write_url, sizeof(write_url), "pipe:%d", pipe_fds[1]);
+
+if (!check_pipe(read_url,
+AVIO_FLAG_READ | AVIO_FLAG_WRITE,
+AVIO_FLAG_READ))
+ret = 1;
+
+if (!check_pipe(write_url,
+AVIO_FLAG_READ | AVIO_FLAG_WRITE,
+AVIO_FLAG_WRITE))
+ret = 1;
+
+/* Ensure that we don't get flags that we didn't ask for */
+if (!check_pipe(read_url, AVIO_FLAG_WRITE, 0))
+ret = 1;
+
+close(pipe_fds[0]);
+close(pipe_fds[1]);
+
+/* An invalid fd should return EBADF */
+check_invalid_ret = avio_check(read_url, AVIO_FLAG_READ);
+
+if (check_invalid_ret != AVERROR(EBADF)) {
+fprintf(stderr,
+"avio_check on invalid FD expected to return %i "
+"but %i was received\n",
+AVERROR(EBADF),
+check_invalid_ret);
+ret = 1;
+}
+
+return ret;
+}
diff --git a/tests/fate/libavformat.mak b/tests/fate/libavformat.mak
index d2acb4c9e0..7a22f54c04 100644
--- a/tests/fate/libavformat.mak
+++ b/tests/fate/libavformat.mak
@@ -26,6 +26,11 @@ FATE_LIBAVFORMAT-$(CONFIG_IMF_DEMUXER) += fate-imf
 fate-imf: libavformat/tests/imf$(EXESUF)
 fate-imf: CMD = run libavformat/tests/imf$(EXESUF)
 
+FATE_LIBAVFORMAT-$(CONFIG_PIPE_PROTOCOL) += fate-pipe
+fate-pipe: libavformat/tests/pipe$(EXESUF)
+fate-pipe: CMD = run libavformat/tests/pipe$(EXESUF)
+fate-pipe: CMP = null
+
 FATE_LIBAVFORMAT += fate-seek_utils
 fate-seek_utils: libavformat/tests/seek_utils$(EXESUF)
 fate-seek_utils: CMD = run libavformat/tests/seek_utils$(EXESUF)
-- 
2.37.2

__

Re: [FFmpeg-devel] Matroska and output_ts_offset

[Peter Zebühr]

> On 29 Aug 2022, at 16:37, Andreas Rheinhardt  
> wrote:
> 
> The Matroska muxer is buggy wrt. to the ts_offset relating to codec
> delay. You can see it in lines 1839-1841 which are commented out.
> Commenting them out happened in commit
> 82e4f39883932c1b1e5c7792a1be12dec6ab603d, merging the libav commit that
> implemented it (namely
> https://github.com/FFmpeg/FFmpeg/commit/a1aa37dd0b96710d4a17718198a3f56aea2040c1
>  
> ).
> It mentions "assertion failures and av sync errors". I can only think of
> one way that it could have led to assertion failures, but this should
> have been fixed in 4ebeab15b037a21f195696cef1f7522daf42f3ee (and since
> then I wondered whether it can't be enabled).
> 
> - Andreas

Interesting,

It does look like re-enabling that commented out section would indeed shift my 
teimstamps forward by the encoder dalay and work with my ts_offset setting. 
I do wonder though, would that not also mean that for the cases where the 
stream should start at 0 it would result in streams starting 7ms in due to the 
handle_avoid_negative_ts already having shifted the first packets PTS from -7 
to 0? And that would end up being shifted once again for the inital_padding?

/ Peter
___
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] lavu/fifo: clarify interaction of AV_FIFO_FLAG_AUTO_GROW with av_fifo_can_write()

[James Almer]

On 8/29/2022 11:07 AM, Anton Khirnov wrote:

---
  libavutil/fifo.h | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/libavutil/fifo.h b/libavutil/fifo.h
index 6c6bd78842..89872d0972 100644
--- a/libavutil/fifo.h
+++ b/libavutil/fifo.h
@@ -97,7 +97,13 @@ void av_fifo_auto_grow_limit(AVFifo *f, size_t max_elems);
  size_t av_fifo_can_read(const AVFifo *f);
  
  /**

- * @return number of elements that can be written into the given FIFO.
+ * @return Number of elements that can be written into the given FIFO without
+ * growing it.
+ *
+ * In other words, this number of elements or less is guaranteed to fit
+ * into the FIFO. More data may be written when the
+ * AV_FIFO_FLAG_AUTO_GROW flag was specified at FIFO creation, but this
+ * may involve memory allocation, which can fail.


This patch is an API break, because before it i was told 
av_fifo_can_write() would tell me the amount of elements i could write 
into the FIFO, regardless of how it was created, but now it legitimates 
the one scenario where it was not reliable. An scenario i stumbled upon 
in my code by following the documentation, which is in at least one 
release, the LTS one.


Instead of changing the documentation to fit the behavior, the behavior 
should match the documentation. This means that if a call to 
av_fifo_write() can succeed, then av_fifo_can_write() should reflect that.


That said, it would be great if making av_fifo_can_write() tell the real 
amount of elements one can write into the FIFO was possible without 
breaking anything, but the doxy for av_fifo_grow2() says "On success, 
the FIFO will be large enough to hold exactly inc + av_fifo_can_read() + 
av_fifo_can_write()", a line that was obviously aware of the fact 
av_fifo_can_write() ignored the autogrow feature, and would no longer be 
true if said function is fixed.


This could have been avoided if we added an av_fifo_size2() function 
that returned nb_elems, so the line above may have been replaced by one 
simply referring the user to it. But as is, we're breaking the API no 
matter what we do.



   */
  size_t av_fifo_can_write(const AVFifo *f);
  

___
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] Matroska and output_ts_offset

[Andreas Rheinhardt]

Peter Zebühr:
>> On 29 Aug 2022, at 16:37, Andreas Rheinhardt 
>>  wrote:
>>
>> The Matroska muxer is buggy wrt. to the ts_offset relating to codec
>> delay. You can see it in lines 1839-1841 which are commented out.
>> Commenting them out happened in commit
>> 82e4f39883932c1b1e5c7792a1be12dec6ab603d, merging the libav commit that
>> implemented it (namely
>> https://github.com/FFmpeg/FFmpeg/commit/a1aa37dd0b96710d4a17718198a3f56aea2040c1
>>  
>> ).
>> It mentions "assertion failures and av sync errors". I can only think of
>> one way that it could have led to assertion failures, but this should
>> have been fixed in 4ebeab15b037a21f195696cef1f7522daf42f3ee (and since
>> then I wondered whether it can't be enabled).
>>
>> - Andreas
> 
> Interesting,
> 
> It does look like re-enabling that commented out section would indeed shift 
> my teimstamps forward by the encoder dalay and work with my ts_offset 
> setting. 
> I do wonder though, would that not also mean that for the cases where the 
> stream should start at 0 it would result in streams starting 7ms in due to 
> the handle_avoid_negative_ts already having shifted the first packets PTS 
> from -7 to 0? And that would end up being shifted once again for the 
> inital_padding?
> 

Yes, the shifting code in libavformat/mux.c does not yet know about the
Matroska muxer's ability to shift by initial_padding samples. But at
least it will shift all packets, thereby preserving sync in case there
are multiple streams. This is not done currently.

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

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

Re: [FFmpeg-devel] [PATCH] avcodec/vpx_rac: Adjust vpx_rac_is_end) threshold

[Andreas Rheinhardt]

Michael Niedermayer:
> A threshold of 180 is needed and sufficient for the sample, twice this is 
> used to
> cover potentially worse samples
> 
> fate/vp5 changes as the sample file is truncated and the damaged part is 
> handled
> differently
> 
> Fixes: ticket #9754
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/vpx_rac.h | 2 +-
>  tests/ref/fate/vp5   | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/vpx_rac.h b/libavcodec/vpx_rac.h
> index b158cc0754..2f5486f501 100644
> --- a/libavcodec/vpx_rac.h
> +++ b/libavcodec/vpx_rac.h
> @@ -52,7 +52,7 @@ static av_always_inline int vpx_rac_is_end(VPXRangeCoder *c)
>  {
>  if (c->end <= c->buffer && c->bits >= 0)
>  c->end_reached ++;
> -return c->end_reached > 10;
> +return c->end_reached > 360;

Is the file from #9754 defective? Or is it our decoder that is
overcautious? Your commit message sounds as if it were the latter. Is it
guaranteed that is now enough for all spec-compliant samples? Does the
answer depend upon the codec? (vpx_rac_is_end() is shared between
several VPx codecs.); I presume you can't give any guarantees.

>  }
>  
>  static av_always_inline unsigned int vpx_rac_renorm(VPXRangeCoder *c)
> diff --git a/tests/ref/fate/vp5 b/tests/ref/fate/vp5
> index 09ebe62b25..2116fb9b81 100644
> --- a/tests/ref/fate/vp5
> +++ b/tests/ref/fate/vp5
> @@ -249,4 +249,4 @@
>  0,243,243,1,   233472, 0x6f530ac6
>  0,244,244,1,   233472, 0x94f7466c
>  0,245,245,1,   233472, 0xa8c1d365
> -0,246,246,1,   233472, 0x4f3ef38c
> +0,246,246,1,   233472, 0xedcff050


___
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] lavu/fifo: clarify interaction of AV_FIFO_FLAG_AUTO_GROW with av_fifo_can_write()

[James Almer]

On 8/29/2022 12:00 PM, James Almer wrote:

On 8/29/2022 11:07 AM, Anton Khirnov wrote:

---
  libavutil/fifo.h | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/libavutil/fifo.h b/libavutil/fifo.h
index 6c6bd78842..89872d0972 100644
--- a/libavutil/fifo.h
+++ b/libavutil/fifo.h
@@ -97,7 +97,13 @@ void av_fifo_auto_grow_limit(AVFifo *f, size_t 
max_elems);

  size_t av_fifo_can_read(const AVFifo *f);
  /**
- * @return number of elements that can be written into the given FIFO.
+ * @return Number of elements that can be written into the given FIFO 
without

+ * growing it.
+ *
+ * In other words, this number of elements or less is 
guaranteed to fit

+ * into the FIFO. More data may be written when the
+ * AV_FIFO_FLAG_AUTO_GROW flag was specified at FIFO 
creation, but this

+ * may involve memory allocation, which can fail.


This patch is an API break, because before it i was told 
av_fifo_can_write() would tell me the amount of elements i could write 
into the FIFO, regardless of how it was created, but now it legitimates 
the one scenario where it was not reliable. An scenario i stumbled upon 
in my code by following the documentation, which is in at least one 
release, the LTS one.


Instead of changing the documentation to fit the behavior, the behavior 
should match the documentation. This means that if a call to 
av_fifo_write() can succeed, then av_fifo_can_write() should reflect that.


That said, it would be great if making av_fifo_can_write() tell the real 
amount of elements one can write into the FIFO was possible without 
breaking anything, but the doxy for av_fifo_grow2() says "On success, 
the FIFO will be large enough to hold exactly inc + av_fifo_can_read() + 
av_fifo_can_write()", a line that was obviously aware of the fact 
av_fifo_can_write() ignored the autogrow feature, and would no longer be 
true if said function is fixed.


This could have been avoided if we added an av_fifo_size2() function 
that returned nb_elems, so the line above may have been replaced by one 
simply referring the user to it. But as is, we're breaking the API no 
matter what we do.


Something like the following is the alternative. It's going to be a 
break in one way or another no matter what we do.



diff --git a/libavutil/fifo.c b/libavutil/fifo.c
index 51a5af6f39..3fc76b4247 100644
--- a/libavutil/fifo.c
+++ b/libavutil/fifo.c
@@ -79,6 +79,11 @@ void av_fifo_auto_grow_limit(AVFifo *f, size_t max_elems)
 f->auto_grow_limit = max_elems;
 }

+size_t av_fifo_size2(const AVFifo *f)
+{
+return f->nb_elems;
+}
+
 size_t av_fifo_elem_size(const AVFifo *f)
 {
 return f->elem_size;
@@ -93,7 +98,14 @@ size_t av_fifo_can_read(const AVFifo *f)

 size_t av_fifo_can_write(const AVFifo *f)
 {
-return f->nb_elems - av_fifo_can_read(f);
+size_t nb_elems = f->nb_elems;
+
+if (f->flags & AV_FIFO_FLAG_AUTO_GROW) {
+size_t autogrow = f->auto_grow_limit > nb_elems ?
+  f->auto_grow_limit - nb_elems : 0;
+nb_elems += autogrow;
+}
+return nb_elems - av_fifo_can_read(f);
 }

 int av_fifo_grow2(AVFifo *f, size_t inc)
diff --git a/libavutil/fifo.h b/libavutil/fifo.h
index 4eed364afc..0f909aac55 100644
--- a/libavutil/fifo.h
+++ b/libavutil/fifo.h
@@ -70,6 +70,11 @@ typedef int AVFifoCB(void *opaque, void *buf, size_t 
*nb_elems);
 AVFifo *av_fifo_alloc2(size_t elems, size_t elem_size,
unsigned int flags);

+/**
+ * @return Total number of elements the given FIFO can currently hold.
+ */
+size_t av_fifo_size2(const AVFifo *f);
+
 /**
  * @return Element size for FIFO operations. This element size is set at
  * FIFO allocation and remains constant during its lifetime
@@ -89,20 +94,22 @@ size_t av_fifo_can_read(const AVFifo *f);

 /**
  * @return number of elements that can be written into the given FIFO.
+ * @note   If the given FIFO was allocated with AV_FIFO_FLAG_AUTO_GROW, the
+ * result of av_fifo_size2(f) - av_fifo_can_read(f) is the amount
+ * of elements that can be written into it without the chance of
+ * failure.
  */
 size_t av_fifo_can_write(const AVFifo *f);

 /**
  * Enlarge an AVFifo.
  *
- * On success, the FIFO will be large enough to hold exactly
- * inc + av_fifo_can_read() + av_fifo_can_write()
- * elements. In case of failure, the old FIFO is kept unchanged.
- *
  * @param f AVFifo to resize
  * @param inc number of elements to allocate for, in addition to the current
  *allocated size
- * @return a non-negative number on success, a negative error code on failure
+ * @return a non-negative number on success, a negative error code on failure.
+ * In case of failure, the old FIFO is kept unchanged.
+ * @see av_fifo_size2()
  */
 int av_fifo_grow2(AVFifo *f, size_t inc);

@@ -112,6 +119,9 @@ int av_fifo_grow2(AVFifo *f, size_t inc);
  * In case nb_elems > av_fifo_can_write(f), nothing is written and an e

Re: [FFmpeg-devel] [PATCH 1/3] lavu/fifo: add the header to its own doxy group

[Michael Niedermayer]

On Mon, Aug 29, 2022 at 04:07:15PM +0200, Anton Khirnov wrote:
> Also, drop mentions of it being a circular buffer, as this is an
> internal implementation detail that should be invisible to the caller.
> ---
>  libavutil/fifo.h | 15 ++-
>  1 file changed, 14 insertions(+), 1 deletion(-)

agree

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

Re: [FFmpeg-devel] [PATCH 2/3] lavu/fifo: clarify interaction of AV_FIFO_FLAG_AUTO_GROW with av_fifo_can_write()

[Marvin Scholz]

On 29 Aug 2022, at 18:03, James Almer wrote:

> On 8/29/2022 12:00 PM, James Almer wrote:
>> On 8/29/2022 11:07 AM, Anton Khirnov wrote:
>>> ---
>>>   libavutil/fifo.h | 8 +++-
>>>   1 file changed, 7 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/libavutil/fifo.h b/libavutil/fifo.h
>>> index 6c6bd78842..89872d0972 100644
>>> --- a/libavutil/fifo.h
>>> +++ b/libavutil/fifo.h
>>> @@ -97,7 +97,13 @@ void av_fifo_auto_grow_limit(AVFifo *f, size_t 
>>> max_elems);
>>>   size_t av_fifo_can_read(const AVFifo *f);
>>>   /**
>>> - * @return number of elements that can be written into the given FIFO.
>>> + * @return Number of elements that can be written into the given FIFO 
>>> without
>>> + * growing it.
>>> + *
>>> + * In other words, this number of elements or less is guaranteed 
>>> to fit
>>> + * into the FIFO. More data may be written when the
>>> + * AV_FIFO_FLAG_AUTO_GROW flag was specified at FIFO creation, but 
>>> this
>>> + * may involve memory allocation, which can fail.
>>
>> This patch is an API break, because before it i was told av_fifo_can_write() 
>> would tell me the amount of elements i could write into the FIFO, regardless 
>> of how it was created, but now it legitimates the one scenario where it was 
>> not reliable. An scenario i stumbled upon in my code by following the 
>> documentation, which is in at least one release, the LTS one.
>>
>> Instead of changing the documentation to fit the behavior, the behavior 
>> should match the documentation. This means that if a call to av_fifo_write() 
>> can succeed, then av_fifo_can_write() should reflect that.
>>
>> That said, it would be great if making av_fifo_can_write() tell the real 
>> amount of elements one can write into the FIFO was possible without breaking 
>> anything, but the doxy for av_fifo_grow2() says "On success, the FIFO will 
>> be large enough to hold exactly inc + av_fifo_can_read() + 
>> av_fifo_can_write()", a line that was obviously aware of the fact 
>> av_fifo_can_write() ignored the autogrow feature, and would no longer be 
>> true if said function is fixed.
>>
>> This could have been avoided if we added an av_fifo_size2() function that 
>> returned nb_elems, so the line above may have been replaced by one simply 
>> referring the user to it. But as is, we're breaking the API no matter what 
>> we do.
>
> Something like the following is the alternative. It's going to be a break in 
> one way or another no matter what we do.
>
>> diff --git a/libavutil/fifo.c b/libavutil/fifo.c
>> index 51a5af6f39..3fc76b4247 100644
>> --- a/libavutil/fifo.c
>> +++ b/libavutil/fifo.c
>> @@ -79,6 +79,11 @@ void av_fifo_auto_grow_limit(AVFifo *f, size_t max_elems)
>>  f->auto_grow_limit = max_elems;
>>  }
>>
>> +size_t av_fifo_size2(const AVFifo *f)
>> +{
>> +return f->nb_elems;
>> +}
>> +
>>  size_t av_fifo_elem_size(const AVFifo *f)
>>  {
>>  return f->elem_size;
>> @@ -93,7 +98,14 @@ size_t av_fifo_can_read(const AVFifo *f)
>>
>>  size_t av_fifo_can_write(const AVFifo *f)
>>  {
>> -return f->nb_elems - av_fifo_can_read(f);
>> +size_t nb_elems = f->nb_elems;
>> +
>> +if (f->flags & AV_FIFO_FLAG_AUTO_GROW) {
>> +size_t autogrow = f->auto_grow_limit > nb_elems ?
>> +  f->auto_grow_limit - nb_elems : 0;
>> +nb_elems += autogrow;
>> +}
>> +return nb_elems - av_fifo_can_read(f);
>>  }
>>
>>  int av_fifo_grow2(AVFifo *f, size_t inc)
>> diff --git a/libavutil/fifo.h b/libavutil/fifo.h
>> index 4eed364afc..0f909aac55 100644
>> --- a/libavutil/fifo.h
>> +++ b/libavutil/fifo.h
>> @@ -70,6 +70,11 @@ typedef int AVFifoCB(void *opaque, void *buf, size_t 
>> *nb_elems);
>>  AVFifo *av_fifo_alloc2(size_t elems, size_t elem_size,
>> unsigned int flags);
>>
>> +/**
>> + * @return Total number of elements the given FIFO can currently hold.
>> + */
>> +size_t av_fifo_size2(const AVFifo *f);

IIUC this is about the total space in the FIFO, so maybe
av_fifo_capacity would be a better name?

>> +
>>  /**
>>   * @return Element size for FIFO operations. This element size is set at
>>   * FIFO allocation and remains constant during its lifetime
>> @@ -89,20 +94,22 @@ size_t av_fifo_can_read(const AVFifo *f);
>>
>>  /**
>>   * @return number of elements that can be written into the given FIFO.
>> + * @note   If the given FIFO was allocated with AV_FIFO_FLAG_AUTO_GROW, the
>> + * result of av_fifo_size2(f) - av_fifo_can_read(f) is the amount
>> + * of elements that can be written into it without the chance of
>> + * failure.
>>   */
>>  size_t av_fifo_can_write(const AVFifo *f);
>>
>>  /**
>>   * Enlarge an AVFifo.
>>   *
>> - * On success, the FIFO will be large enough to hold exactly
>> - * inc + av_fifo_can_read() + av_fifo_can_write()
>> - * elements. In case of failure, the old FIFO is kept unchanged.
>> - *
>>   * @param f AVFifo to resize
>>   * @param inc number of elements to all

Re: [FFmpeg-devel] [PATCH 1/2] avformat/file: Add a specialized url_check callback for pipe protocol

[Michael Niedermayer]

On Mon, Aug 29, 2022 at 04:43:19PM +0200, Neil Roberts wrote:
> Using file_check for the pipe protocol doesn't make sense. For example,
> for a URL like “pipe:0” it would end up checking whether the “pipe:0”
> file exists. This patch instead makes it check the access modes on the
> corresponding file descriptor using fcntl.
> 
> Signed-off-by: Neil Roberts 
> ---
>  libavformat/file.c | 40 +---
>  1 file changed, 37 insertions(+), 3 deletions(-)

breaks on mingw64

src/libavformat/file.c: In function ‘pipe_check’:
src/libavformat/file.c:411:24: error: implicit declaration of function ‘fcntl’; 
did you mean ‘rintl’? [-Werror=implicit-function-declaration]
 int status_flags = fcntl(fd, F_GETFL);
^
rintl
src/libavformat/file.c:411:34: error: ‘F_GETFL’ undeclared (first use in this 
function)
 int status_flags = fcntl(fd, F_GETFL);
  ^~~
src/libavformat/file.c:411:34: note: each undeclared identifier is reported 
only once for each function it appears in
cc1: some warnings being treated as errors

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

There will always be a question for which you do not know the correct answer.


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/vpx_rac: Adjust vpx_rac_is_end) threshold

[Michael Niedermayer]

On Mon, Aug 29, 2022 at 05:29:03PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > A threshold of 180 is needed and sufficient for the sample, twice this is 
> > used to
> > cover potentially worse samples
> > 
> > fate/vp5 changes as the sample file is truncated and the damaged part is 
> > handled
> > differently
> > 
> > Fixes: ticket #9754
> > 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/vpx_rac.h | 2 +-
> >  tests/ref/fate/vp5   | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/libavcodec/vpx_rac.h b/libavcodec/vpx_rac.h
> > index b158cc0754..2f5486f501 100644
> > --- a/libavcodec/vpx_rac.h
> > +++ b/libavcodec/vpx_rac.h
> > @@ -52,7 +52,7 @@ static av_always_inline int vpx_rac_is_end(VPXRangeCoder 
> > *c)
> >  {
> >  if (c->end <= c->buffer && c->bits >= 0)
> >  c->end_reached ++;
> > -return c->end_reached > 10;
> > +return c->end_reached > 360;
> 
> Is the file from #9754 defective? Or is it our decoder that is
> overcautious? 
> Your commit message sounds as if it were the latter. Is it
> guaranteed that is now enough for all spec-compliant samples? Does the
> answer depend upon the codec? (vpx_rac_is_end() is shared between
> several VPx codecs.); I presume you can't give any guarantees.

The file in question is VP8
looking at rfc6386, i see no obvious end of data check in the AC decoder
in the RFC that would hint toward defective but the renorm code only tries
reading once over the end.
Our large threshold is the result of avoiding adding code in the ac reader
itself

It would require more investigation to be really sure though.
Looking at this with the reference decoder and some instrumentation in it
to see if it overreads too for example. 
But as the awnser to this wouldnt really affect the solution i think thats
wasted time.

Also heres a better looking fix:
sadly i cannot replicate most of the timeouts with git master
also i do not remember why i did not choose this simpler solution originally


Author: Michael Niedermayer 
Date:   Mon Aug 29 23:43:41 2022 +0200

libavcodec/vpx_rac: Change end detection logic

fate/vp5 changes as the sample file is truncated and the damaged part is 
handled
differently

Fixes: ticket #9754

This is a different and simpler solution to 
b6b9ac5698c8f911841b469af77199153278c55c

Signed-off-by: Michael Niedermayer 

diff --git a/libavcodec/vpx_rac.c b/libavcodec/vpx_rac.c
index cf02e9a19c9..bbfc829431c 100644
--- a/libavcodec/vpx_rac.c
+++ b/libavcodec/vpx_rac.c
@@ -45,7 +45,6 @@ int ff_vpx_init_range_decoder(VPXRangeCoder *c, const uint8_t 
*buf, int buf_size
 c->bits = -16;
 c->buffer = buf;
 c->end = buf + buf_size;
-c->end_reached = 0;
 if (buf_size < 1)
 return AVERROR_INVALIDDATA;
 c->code_word = bytestream_get_be24(&c->buffer);
diff --git a/libavcodec/vpx_rac.h b/libavcodec/vpx_rac.h
index b158cc0754d..392e59904bd 100644
--- a/libavcodec/vpx_rac.h
+++ b/libavcodec/vpx_rac.h
@@ -39,7 +39,6 @@ typedef struct VPXRangeCoder {
 const uint8_t *buffer;
 const uint8_t *end;
 unsigned int code_word;
-int end_reached;
 } VPXRangeCoder;
 
 extern const uint8_t ff_vpx_norm_shift[256];
@@ -50,9 +49,7 @@ int ff_vpx_init_range_decoder(VPXRangeCoder *c, const uint8_t 
*buf, int buf_size
  */
 static av_always_inline int vpx_rac_is_end(VPXRangeCoder *c)
 {
-if (c->end <= c->buffer && c->bits >= 0)
-c->end_reached ++;
-return c->end_reached > 10;
+return c->end <= c->buffer && c->bits >= 1;
 }
 
 static av_always_inline unsigned int vpx_rac_renorm(VPXRangeCoder *c)
diff --git a/tests/ref/fate/vp5 b/tests/ref/fate/vp5
index 09ebe62b25e..2469a3ec21a 100644
--- a/tests/ref/fate/vp5
+++ b/tests/ref/fate/vp5
@@ -249,4 +249,4 @@
 0,243,243,1,   233472, 0x6f530ac6
 0,244,244,1,   233472, 0x94f7466c
 0,245,245,1,   233472, 0xa8c1d365
-0,246,246,1,   233472, 0x4f3ef38c
+0,246,246,1,   233472, 0xbf73f1b7

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes


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] Converting build to CMake

[Jaime Rios]

I might take a look at the dependencies and see what projects could be
converted to CMake first, before even thinking about ffmpeg.



On Sun, Aug 28, 2022 at 10:15 PM Martijn van Beurden 
wrote:

> Op ma 29 aug. 2022 om 01:17 schreef Jaime Rios :
>
> > The reason I ask is that I am not a fan of having to install MinGW just
> to
> > build on Windows
> >
>
> There's no need to install MinGW, just MSYS will do:
> https://trac.ffmpeg.org/wiki/CompilationGuide/MSVC
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH] avcodec: add a bsf to reorder DTS into PTS

[James Almer]

Starting with an h264 implementation. Can be extended to support other codecs.

Addresses ticket #502.

Signed-off-by: James Almer 
---
 configure  |   1 +
 libavcodec/Makefile|   1 +
 libavcodec/bitstream_filters.c |   1 +
 libavcodec/dts2pts_bsf.c   | 477 +
 4 files changed, 480 insertions(+)
 create mode 100644 libavcodec/dts2pts_bsf.c

diff --git a/configure b/configure
index 932ea5b553..91ee5eb303 100755
--- a/configure
+++ b/configure
@@ -3275,6 +3275,7 @@ aac_adtstoasc_bsf_select="adts_header mpeg4audio"
 av1_frame_merge_bsf_select="cbs_av1"
 av1_frame_split_bsf_select="cbs_av1"
 av1_metadata_bsf_select="cbs_av1"
+dts2pts_bsf_select="cbs_h264 h264parse"
 eac3_core_bsf_select="ac3_parser"
 filter_units_bsf_select="cbs"
 h264_metadata_bsf_deps="const_nan"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index cb80f73d99..858e110b79 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1176,6 +1176,7 @@ OBJS-$(CONFIG_AV1_FRAME_SPLIT_BSF)+= 
av1_frame_split_bsf.o
 OBJS-$(CONFIG_CHOMP_BSF)  += chomp_bsf.o
 OBJS-$(CONFIG_DUMP_EXTRADATA_BSF) += dump_extradata_bsf.o
 OBJS-$(CONFIG_DCA_CORE_BSF)   += dca_core_bsf.o
+OBJS-$(CONFIG_DTS2PTS_BSF)+= dts2pts_bsf.o
 OBJS-$(CONFIG_DV_ERROR_MARKER_BSF)+= dv_error_marker_bsf.o
 OBJS-$(CONFIG_EAC3_CORE_BSF)  += eac3_core_bsf.o
 OBJS-$(CONFIG_EXTRACT_EXTRADATA_BSF)  += extract_extradata_bsf.o\
diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
index 23ae93..a3bebefe5f 100644
--- a/libavcodec/bitstream_filters.c
+++ b/libavcodec/bitstream_filters.c
@@ -31,6 +31,7 @@ extern const FFBitStreamFilter ff_av1_metadata_bsf;
 extern const FFBitStreamFilter ff_chomp_bsf;
 extern const FFBitStreamFilter ff_dump_extradata_bsf;
 extern const FFBitStreamFilter ff_dca_core_bsf;
+extern const FFBitStreamFilter ff_dts2pts_bsf;
 extern const FFBitStreamFilter ff_dv_error_marker_bsf;
 extern const FFBitStreamFilter ff_eac3_core_bsf;
 extern const FFBitStreamFilter ff_extract_extradata_bsf;
diff --git a/libavcodec/dts2pts_bsf.c b/libavcodec/dts2pts_bsf.c
new file mode 100644
index 00..f600150a6b
--- /dev/null
+++ b/libavcodec/dts2pts_bsf.c
@@ -0,0 +1,477 @@
+/*
+ * Copyright (c) 2022 James Almer
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * Derive PTS by reordering DTS from supported streams
+ */
+
+#include "libavutil/avassert.h"
+#include "libavutil/eval.h"
+#include "libavutil/fifo.h"
+#include "libavutil/opt.h"
+#include "libavutil/tree.h"
+
+#include "bsf.h"
+#include "bsf_internal.h"
+#include "cbs.h"
+#include "cbs_h264.h"
+#include "h264_parse.h"
+#include "h264_ps.h"
+
+typedef struct DTS2PTSNode {
+int64_t  dts;
+int64_t duration;
+int  poc;
+} DTS2PTSNode;
+
+typedef struct DTS2PTSFrame {
+AVPacket*pkt;
+int  poc;
+int poc_diff;
+} DTS2PTSFrame;
+
+typedef struct DTS2PTSH264Context {
+H264POCContext poc;
+SPS sps;
+int last_poc;
+int highest_poc;
+int picture_structure;
+} DTS2PTSH264Context;
+
+typedef struct DTS2PTSContext {
+struct AVTreeNode *root;
+AVFifo *fifo;
+
+// Codec specific function pointers
+int (*init)(AVBSFContext *ctx);
+int (*filter)(AVBSFContext *ctx);
+void (*flush)(AVBSFContext *ctx);
+
+CodedBitstreamContext *cbc;
+CodedBitstreamFragment au;
+
+union {
+DTS2PTSH264Context h264;
+} u;
+
+int nb_frame;
+int eof;
+} DTS2PTSContext;
+
+// AVTreeNode callbacks
+static int cmp_insert(const void *key, const void *node)
+{
+return ((const DTS2PTSNode *) key)->poc - ((const DTS2PTSNode *) 
node)->poc;
+}
+
+static int cmp_find(const void *key, const void *node)
+{
+return *(const int *)key - ((const DTS2PTSNode *) node)->poc;
+}
+
+static int dec_poc(void *opaque, void *elem)
+{
+DTS2PTSNode *node = elem;
+int dec = *(int *)opaque;
+node->poc -= dec;
+return 0;
+}
+
+static int free_node(void *opaque, void *elem)
+{
+DTS2PTSNode *node = elem;
+av_free(node);
+return 0;
+}
+
+// Shared functions
+static int alloc_and_insert_node(AVBSFContext *ctx, int64_t ts, 

Re: [FFmpeg-devel] [PATCH 2/3] lavu/fifo: clarify interaction of AV_FIFO_FLAG_AUTO_GROW with av_fifo_can_write()

[Anton Khirnov]

Quoting James Almer (2022-08-29 17:00:54)
> On 8/29/2022 11:07 AM, Anton Khirnov wrote:
> > ---
> >   libavutil/fifo.h | 8 +++-
> >   1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/libavutil/fifo.h b/libavutil/fifo.h
> > index 6c6bd78842..89872d0972 100644
> > --- a/libavutil/fifo.h
> > +++ b/libavutil/fifo.h
> > @@ -97,7 +97,13 @@ void av_fifo_auto_grow_limit(AVFifo *f, size_t 
> > max_elems);
> >   size_t av_fifo_can_read(const AVFifo *f);
> >   
> >   /**
> > - * @return number of elements that can be written into the given FIFO.
> > + * @return Number of elements that can be written into the given FIFO 
> > without
> > + * growing it.
> > + *
> > + * In other words, this number of elements or less is guaranteed 
> > to fit
> > + * into the FIFO. More data may be written when the
> > + * AV_FIFO_FLAG_AUTO_GROW flag was specified at FIFO creation, but 
> > this
> > + * may involve memory allocation, which can fail.
> 
> This patch is an API break, because before it i was told 
> av_fifo_can_write() would tell me the amount of elements i could write 
> into the FIFO, regardless of how it was created, but now it legitimates 
> the one scenario where it was not reliable. An scenario i stumbled upon 
> in my code by following the documentation, which is in at least one 
> release, the LTS one.
> 
> Instead of changing the documentation to fit the behavior, the behavior 
> should match the documentation. This means that if a call to 
> av_fifo_write() can succeed, then av_fifo_can_write() should reflect that.
> 
> That said, it would be great if making av_fifo_can_write() tell the real 
> amount of elements one can write into the FIFO was possible without 
> breaking anything, but the doxy for av_fifo_grow2() says "On success, 
> the FIFO will be large enough to hold exactly inc + av_fifo_can_read() + 
> av_fifo_can_write()", a line that was obviously aware of the fact 
> av_fifo_can_write() ignored the autogrow feature, and would no longer be 
> true if said function is fixed.

I disagree that this is a break.

The issue in my view is that 'can be written' is ambiguous here, so we
are interpreting it differently. Your interpretation is apparently
'maximum number of elements for which a write can possibly succeeed',
whereas my intended interpretation was 'maximum number of elements for
which a write is always guaranteed to succeed'.
One of these interpretations is correct, because it matches the actual
behaviour. So the right solution IMO is to clarify the documentation so
it is no longer ambiguous, but I do not consider this an API break.

More generally:
- a FIFO conceptually has a well-defined size at any given moment
- that size is can_read() + can_write()
- you can change the size by growing the FIFO
- AV_FIFO_FLAG_AUTO_GROW does not fundamentally change the above
  concepts, it merely calls av_fifo_grow2() when a write would
  otherwise fail

Now we can introduce a function for 'maximum number that can possibly
succeed' if you think it's useful - something like av_fifo_max_write().

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