[FFmpeg-devel] Add support for ICMV audio in wav

2022-08-23 Thread Paul B Mahol
Hi,

patch attached.
From 7d421f86b3f1f8fcb8effba04dc37d724caa2455 Mon Sep 17 00:00:00 2001
From: Paul B Mahol 
Date: Tue, 23 Aug 2022 10:11:55 +0200
Subject: [PATCH] avformat: add support for ICMV files

Signed-off-by: Paul B Mahol 
---
 libavformat/riff.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/riff.c b/libavformat/riff.c
index 7a97cf1ccf..6c06ad2d60 100644
--- a/libavformat/riff.c
+++ b/libavformat/riff.c
@@ -579,6 +579,7 @@ const AVCodecTag ff_codec_wav_tags[] = {
 { AV_CODEC_ID_DTS, 0x2001 },
 { AV_CODEC_ID_SONIC,   0x2048 },
 { AV_CODEC_ID_SONIC_LS,0x2048 },
+{ AV_CODEC_ID_G729,0x },
 { AV_CODEC_ID_PCM_MULAW,   0x6c75 },
 { AV_CODEC_ID_AAC, 0x706d },
 { AV_CODEC_ID_AAC, 0x4143 },
-- 
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 v3 1/3] lavc/decode: Warp get_hw_config function

2022-08-23 Thread Fei Wang
From: Linjie Fu 

Wrap the procedure of getting the hardware config from a pixel format
into a function.

Signed-off-by: Linjie Fu 
Signed-off-by: Fei Wang 
---
 libavcodec/decode.c | 31 +++
 1 file changed, 19 insertions(+), 12 deletions(-)

diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 75373989c6..3b69426c09 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1156,6 +1156,24 @@ static void hwaccel_uninit(AVCodecContext *avctx)
 av_buffer_unref(&avctx->hw_frames_ctx);
 }
 
+static const AVCodecHWConfigInternal *get_hw_config(AVCodecContext *avctx, 
enum AVPixelFormat fmt)
+{
+const AVCodecHWConfigInternal *hw_config;
+
+if (!ffcodec(avctx->codec)->hw_configs)
+return NULL;
+
+for (int i = 0;; i++) {
+hw_config = ffcodec(avctx->codec)->hw_configs[i];
+if (!hw_config)
+return NULL;
+if (hw_config->public.pix_fmt == fmt)
+return hw_config;
+}
+
+return NULL;
+}
+
 int ff_get_format(AVCodecContext *avctx, const enum AVPixelFormat *fmt)
 {
 const AVPixFmtDescriptor *desc;
@@ -1213,18 +1231,7 @@ int ff_get_format(AVCodecContext *avctx, const enum 
AVPixelFormat *fmt)
 break;
 }
 
-if (ffcodec(avctx->codec)->hw_configs) {
-for (i = 0;; i++) {
-hw_config = ffcodec(avctx->codec)->hw_configs[i];
-if (!hw_config)
-break;
-if (hw_config->public.pix_fmt == user_choice)
-break;
-}
-} else {
-hw_config = NULL;
-}
-
+hw_config = get_hw_config(avctx, user_choice);
 if (!hw_config) {
 // No config available, so no extra setup required.
 ret = user_choice;
-- 
2.25.1

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

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


[FFmpeg-devel] [PATCH v3 2/3] lavc/decode: Add internal surface re-allocate method for hwaccel

2022-08-23 Thread Fei Wang
From: Linjie Fu 

Add HWACCEL_CAP_INTERNAL_ALLOC flag to indicate hwaccels are able to
re-allocate surface internally through ff_decode_get_hw_frames_ctx.
So that hwaccels don't need to reinitialize all hw related configs
when decode resolution change, just need to re-allocate new surface
by using new resolution.

Signed-off-by: Linjie Fu 
Signed-off-by: Fei Wang 
---
 libavcodec/decode.c   | 36 
 libavcodec/hwconfig.h |  1 +
 2 files changed, 37 insertions(+)

diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 3b69426c09..6a22627036 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1174,6 +1174,33 @@ static const AVCodecHWConfigInternal 
*get_hw_config(AVCodecContext *avctx, enum
 return NULL;
 }
 
+static int hwaccel_realloc_surface(AVCodecContext *avctx)
+{
+const AVCodecHWConfigInternal *hw_config;
+int ret;
+
+if (avctx->hw_frames_ctx)
+av_buffer_unref(&avctx->hw_frames_ctx);
+
+hw_config = get_hw_config(avctx, avctx->pix_fmt);
+if (!hw_config)
+return AV_PIX_FMT_NONE;
+
+if (avctx->hw_device_ctx &&
+hw_config->public.methods & AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX) {
+const AVHWDeviceContext *device_ctx =
+(AVHWDeviceContext*)avctx->hw_device_ctx->data;
+ret = ff_decode_get_hw_frames_ctx(avctx, device_ctx->type);
+if (ret < 0) {
+av_log(avctx, AV_LOG_WARNING, "Failed to re-allocate hwaccel 
surface internally.\n");
+return AV_PIX_FMT_NONE;
+}
+} else
+return AV_PIX_FMT_NONE;
+
+return hw_config->public.pix_fmt;
+}
+
 int ff_get_format(AVCodecContext *avctx, const enum AVPixelFormat *fmt)
 {
 const AVPixFmtDescriptor *desc;
@@ -1200,6 +1227,15 @@ int ff_get_format(AVCodecContext *avctx, const enum 
AVPixelFormat *fmt)
 return AV_PIX_FMT_NONE;
 
 for (;;) {
+if (avctx->internal->hwaccel_priv_data &&
+avctx->hwaccel->caps_internal & HWACCEL_CAP_INTERNAL_ALLOC) {
+err = hwaccel_realloc_surface(avctx);
+if (err < 0)
+av_log(avctx, AV_LOG_WARNING, "Try to re-initialize all.\n");
+else
+return err;
+}
+
 // Remove the previous hwaccel, if there was one.
 hwaccel_uninit(avctx);
 
diff --git a/libavcodec/hwconfig.h b/libavcodec/hwconfig.h
index 721424912c..7405c66c07 100644
--- a/libavcodec/hwconfig.h
+++ b/libavcodec/hwconfig.h
@@ -24,6 +24,7 @@
 
 
 #define HWACCEL_CAP_ASYNC_SAFE  (1 << 0)
+#define HWACCEL_CAP_INTERNAL_ALLOC  (1 << 1)
 
 
 typedef struct AVCodecHWConfigInternal {
-- 
2.25.1

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

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


[FFmpeg-devel] [PATCH v3 3/3] lavc/vaapi_vp9: add surface internal re-allocation capability

2022-08-23 Thread Fei Wang
From: Linjie Fu 

Surfaces need to bound to a vaContext when context is created before
VAAPI 1.0.0, it need to reset context if surface change. So re-allocation
capability only available after VAAPI 1.0.0.

Detail changes in VAAPI:
https://github.com/intel/libva/commit/492b692005ccd0d8da190209d5b3ae7b7825f4b8

Signed-off-by: Linjie Fu 
Signed-off-by: Fei Wang 
---
update:
1. add va check version 1.0.0

 libavcodec/vaapi_vp9.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavcodec/vaapi_vp9.c b/libavcodec/vaapi_vp9.c
index 776382f683..7dce0250a0 100644
--- a/libavcodec/vaapi_vp9.c
+++ b/libavcodec/vaapi_vp9.c
@@ -181,5 +181,9 @@ const AVHWAccel ff_vp9_vaapi_hwaccel = {
 .uninit   = ff_vaapi_decode_uninit,
 .frame_params = ff_vaapi_common_frame_params,
 .priv_data_size   = sizeof(VAAPIDecodeContext),
+#if VA_CHECK_VERSION(1, 0, 0)
+.caps_internal= HWACCEL_CAP_ASYNC_SAFE | 
HWACCEL_CAP_INTERNAL_ALLOC,
+#else
 .caps_internal= HWACCEL_CAP_ASYNC_SAFE,
+#endif
 };
-- 
2.25.1

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

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


[FFmpeg-devel] [PATCH v3] libavfilter/x86/vf_convolution: add sobel filter optimization and unit test with intel AVX512 VNNI

2022-08-23 Thread bin . wang-at-intel . com
From: bwang30 

This commit enabled assembly code with intel AVX512 VNNI and added unit test 
for sobel filter

sobel_c: 4537
sobel_avx512icl 2470

Signed-off-by: bwang30 
---
 libavfilter/convolution.h |   2 +
 libavfilter/vf_convolution.c  |  23 
 libavfilter/x86/vf_convolution.asm| 162 ++
 libavfilter/x86/vf_convolution_init.c |  18 +++
 tests/checkasm/Makefile   |   1 +
 tests/checkasm/checkasm.c |   3 +
 tests/checkasm/checkasm.h |   1 +
 tests/checkasm/vf_convolution.c   | 103 
 8 files changed, 313 insertions(+)
 create mode 100644 tests/checkasm/vf_convolution.c

diff --git a/libavfilter/convolution.h b/libavfilter/convolution.h
index 88aabe9a20..4520ad13e0 100644
--- a/libavfilter/convolution.h
+++ b/libavfilter/convolution.h
@@ -61,4 +61,6 @@ typedef struct ConvolutionContext {
 } ConvolutionContext;
 
 void ff_convolution_init_x86(ConvolutionContext *s);
+void ff_sobel_init_x86(ConvolutionContext *s);
+void ff_convolution_init(ConvolutionContext *s, const char *filter_name);
 #endif
diff --git a/libavfilter/vf_convolution.c b/libavfilter/vf_convolution.c
index 9a9c099e6d..0eeaaa9fc3 100644
--- a/libavfilter/vf_convolution.c
+++ b/libavfilter/vf_convolution.c
@@ -874,6 +874,9 @@ static int param_init(AVFilterContext *ctx)
 if (s->depth > 8)
 for (p = 0; p < s->nb_planes; p++)
 s->filter[p] = filter16_sobel;
+#if CONFIG_CONVOLUTION_FILTER && ARCH_X86_64
+ff_sobel_init_x86(s);
+#endif
 } else if (!strcmp(ctx->filter->name, "kirsch")) {
 if (s->depth > 8)
 for (p = 0; p < s->nb_planes; p++)
@@ -887,6 +890,26 @@ static int param_init(AVFilterContext *ctx)
 return 0;
 }
 
+void ff_convolution_init(ConvolutionContext *s, const char *filter_name)
+{
+if (!strcmp(filter_name, "sobel")) {
+for (int i = 0; i < 4; i++) {
+s->filter[i] = filter_sobel;
+s->copy[i] = !((1 << i) & s->planes);
+s->size[i] = 3;
+s->setup[i] = setup_3x3;
+s->rdiv[i] = s->scale;
+s->bias[i] = s->delta;
+}
+if (s->depth > 8)
+for (int i = 0; i < 4; i++)
+s->filter[i] = filter16_sobel;
+#if CONFIG_CONVOLUTION_FILTER && ARCH_X86_64
+ff_sobel_init_x86(s);
+#endif
+}
+}
+
 static int config_input(AVFilterLink *inlink)
 {
 AVFilterContext *ctx = inlink->dst;
diff --git a/libavfilter/x86/vf_convolution.asm 
b/libavfilter/x86/vf_convolution.asm
index 754d4d1064..8ad2452418 100644
--- a/libavfilter/x86/vf_convolution.asm
+++ b/libavfilter/x86/vf_convolution.asm
@@ -22,6 +22,10 @@
 
 SECTION_RODATA
 half:   dd 0.5
+data_p1: dd  1
+data_n1: dd -1
+data_p2: dd  2
+data_n2: dd -2
 
 SECTION .text
 
@@ -154,3 +158,161 @@ cglobal filter_3x3, 4, 15, 7, dst, width, rdiv, bias, 
matrix, ptr, c0, c1, c2, c
 INIT_XMM sse4
 FILTER_3X3
 %endif
+
+
+%macro SOBEL_MUL_16 3
+movd xmm2, [%2]
+VPBROADCASTD m2, xmm2
+movdqu xmm3, [c%1q + xq]
+vpmovzxbd m3, xmm3
+vpdpbusd  m%3, m3, m2
+%endmacro
+
+%macro SOBEL_ADD_16 2
+movdqu xmm3, [c%1q + xq]
+vpmovzxbd m3, xmm3
+vpaddd  m%2, m3
+%endmacro
+
+
+%macro SOBEL_MUL 2
+movzx ptrd, byte [c%1q + xq]
+imul  ptrd, [%2]
+add   rd, ptrd
+%endmacro
+
+%macro SOBEL_ADD 1
+movzx ptrd, byte [c%1q + xq]
+add   rd, ptrd
+%endmacro
+
+; void filter_sobel_avx512(uint8_t *dst, int width,
+;  float scale, float delta, const int *const matrix,
+;  const uint8_t *c[], int peak, int radius,
+;  int dstride, int stride)
+%macro FILTER_SOBEL 0
+%if UNIX64
+cglobal filter_sobel, 4, 15, 7, dst, width, matrix, ptr, c0, c1, c2, c3, c4, 
c5, c6, c7, c8, r, x
+%else
+cglobal filter_sobel, 4, 15, 7, dst, width, rdiv, bias, matrix, ptr, c0, c1, 
c2, c3, c4, c5, c6, c7, c8, r, x
+%endif
+%if WIN64
+SWAP xmm0, xmm2
+SWAP xmm1, xmm3
+mov  r2q, matrixmp
+mov  r3q, ptrmp
+DEFINE_ARGS dst, width, matrix, ptr, c0, c1, c2, c3, c4, c5, c6, c7, c8, 
r, x
+%endif
+movsxdifnidn widthq, widthd
+VBROADCASTSS m0, xmm0
+VBROADCASTSS m1, xmm1
+pxor  m6, m6
+mov   c0q, [ptrq + 0*gprsize]
+mov   c1q, [ptrq + 1*gprsize]
+mov   c2q, [ptrq + 2*gprsize]
+mov   c3q, [ptrq + 3*gprsize]
+mov   c4q, [ptrq + 4*gprsize]
+mov   c5q, [ptrq + 5*gprsize]
+mov   c6q, [ptrq + 6*gprsize]
+mov   c7q, [ptrq + 7*gprsize]
+mov   c8q, [ptrq + 8*gprsize]
+
+xor   xq, xq
+cmp   widthq, mmsize/4
+jl .loop2
+
+mov   rq, widthq
+and   rq, mmsize/4-1
+sub   widthq, rq
+
+.loop1:
+pxor m4, m4
+pxor m5, m5
+
+;Gx
+SOBEL_MUL_16 0, data_n1, 4
+SOBEL_MUL_16 1, data_n2, 4
+SOBEL_MUL_16 2, data_n1, 4
+SOBEL_ADD_16 6, 4
+SOBEL_MUL_16 7, data_p2, 4
+SOBEL_ADD_16 8, 4
+
+cvtdq2ps  m4, m4
+mulps m4, m4
+
+;Gy
+SOBEL_MUL_1

[FFmpeg-devel] [PATCH] avcodec/gif: fix duration of last packet/frame

2022-08-23 Thread Paul B Mahol
Hi,

patch attached.
From f126c6ef9e5fa8b51272508af6603f05c26a3f26 Mon Sep 17 00:00:00 2001
From: Paul B Mahol 
Date: Tue, 23 Aug 2022 11:51:24 +0200
Subject: [PATCH] avcodec/gif: fix duration of last packet/frame

Fixes #6294

Signed-off-by: Paul B Mahol 
---
 libavcodec/gif.c  |  2 ++
 libavformat/gif.c | 33 +++--
 2 files changed, 9 insertions(+), 26 deletions(-)

diff --git a/libavcodec/gif.c b/libavcodec/gif.c
index 8e84b79b8c..2484cc92e2 100644
--- a/libavcodec/gif.c
+++ b/libavcodec/gif.c
@@ -513,6 +513,8 @@ static int gif_encode_frame(AVCodecContext *avctx, AVPacket *pkt,
 return ret;
 }
 
+pkt->duration = av_rescale_q(pict->duration, (AVRational){ 1, 100 },
+ avctx->time_base);
 pkt->size   = outbuf_ptr - pkt->data;
 if (s->image || !avctx->frame_number)
 pkt->flags |= AV_PKT_FLAG_KEY;
diff --git a/libavformat/gif.c b/libavformat/gif.c
index b52ff4dd39..afb5767541 100644
--- a/libavformat/gif.c
+++ b/libavformat/gif.c
@@ -36,7 +36,6 @@ typedef struct GIFContext {
 int duration;
 int64_t last_pos;
 int have_end;
-AVPacket *prev_pkt;
 } GIFContext;
 
 static int gif_write_header(AVFormatContext *s)
@@ -81,28 +80,20 @@ static int gif_parse_packet(AVFormatContext *s, const uint8_t *data, int size)
 return 0;
 }
 
-static int gif_get_delay(GIFContext *gif, AVPacket *prev, AVPacket *new)
+static int gif_get_delay(GIFContext *gif, AVPacket *pkt)
 {
-if (new && new->pts != AV_NOPTS_VALUE)
-gif->duration = av_clip_uint16(new->pts - prev->pts);
-else if (!new && gif->last_delay >= 0)
+if (pkt->duration != 0)
+gif->duration = av_clip_uint16(pkt->duration);
+else if (!pkt && gif->last_delay >= 0)
 gif->duration = gif->last_delay;
 
 return gif->duration;
 }
 
-static int gif_write_packet(AVFormatContext *s, AVPacket *new_pkt)
+static int gif_write_packet(AVFormatContext *s, AVPacket *pkt)
 {
 GIFContext *gif = s->priv_data;
 AVIOContext *pb = s->pb;
-AVPacket *pkt = gif->prev_pkt;
-
-if (!gif->prev_pkt) {
-gif->prev_pkt = av_packet_alloc();
-if (!gif->prev_pkt)
-return AVERROR(ENOMEM);
-return av_packet_ref(gif->prev_pkt, new_pkt);
-}
 
 gif->last_pos = avio_tell(pb);
 if (pkt->size > 0)
@@ -144,7 +135,7 @@ static int gif_write_packet(AVFormatContext *s, AVPacket *new_pkt)
 delay_pos = gif_parse_packet(s, pkt->data + off, pkt->size - off);
 if (delay_pos > 0 && delay_pos < pkt->size - off - 2) {
 avio_write(pb, pkt->data + off, delay_pos);
-avio_wl16(pb, gif_get_delay(gif, pkt, new_pkt));
+avio_wl16(pb, gif_get_delay(gif, pkt));
 avio_write(pb, pkt->data + off + delay_pos + 2, pkt->size - off - delay_pos - 2);
 } else {
 avio_write(pb, pkt->data + off, pkt->size - off);
@@ -154,17 +145,13 @@ static int gif_write_packet(AVFormatContext *s, AVPacket *new_pkt)
 
 if (delay_pos > 0 && delay_pos < pkt->size - 2) {
 avio_write(pb, pkt->data, delay_pos);
-avio_wl16(pb, gif_get_delay(gif, pkt, new_pkt));
+avio_wl16(pb, gif_get_delay(gif, pkt));
 avio_write(pb, pkt->data + delay_pos + 2, pkt->size - delay_pos - 2);
 } else {
 avio_write(pb, pkt->data, pkt->size);
 }
 }
 
-av_packet_unref(gif->prev_pkt);
-if (new_pkt)
-return av_packet_ref(gif->prev_pkt, new_pkt);
-
 return 0;
 }
 
@@ -173,14 +160,8 @@ static int gif_write_trailer(AVFormatContext *s)
 GIFContext *gif = s->priv_data;
 AVIOContext *pb = s->pb;
 
-if (!gif->prev_pkt)
-return AVERROR(EINVAL);
-
-gif_write_packet(s, NULL);
-
 if (!gif->have_end)
 avio_w8(pb, GIF_TRAILER);
-av_packet_free(&gif->prev_pkt);
 
 return 0;
 }
-- 
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".


Re: [FFmpeg-devel] [PATCH] avcodec/libsvtav1: properly initialize the flush EbBufferHeaderType struct

2022-08-23 Thread James Almer

On 8/22/2022 12:06 AM, James Almer wrote:

Should fix ticket #9834

Signed-off-by: James Almer 
---
  libavcodec/libsvtav1.c | 7 ++-
  1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index 234c24ca7a..4c403a98d4 100644
--- a/libavcodec/libsvtav1.c
+++ b/libavcodec/libsvtav1.c
@@ -424,11 +424,8 @@ static int eb_send_frame(AVCodecContext *avctx, const 
AVFrame *frame)
  if (svt_enc->eos_flag == EOS_SENT)
  return 0;
  
-headerPtrLast.n_alloc_len   = 0;

-headerPtrLast.n_filled_len  = 0;
-headerPtrLast.n_tick_count  = 0;
-headerPtrLast.p_app_private = NULL;
-headerPtrLast.p_buffer  = NULL;
+memset(&headerPtrLast, 0, sizeof(headerPtrLast));
+headerPtrLast.pic_type  = EB_AV1_INVALID_PICTURE;
  headerPtrLast.flags = EB_BUFFERFLAG_EOS;
  
  svt_av1_enc_send_picture(svt_enc->svt_handle, &headerPtrLast);


Will apply.
___
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/gif: fix duration of last packet/frame

2022-08-23 Thread Andreas Rheinhardt
Paul B Mahol:
> Hi,
> 
> patch attached.
> 
>  return ret;
>  }
>  
> +pkt->duration = av_rescale_q(pict->duration, (AVRational){ 1, 100 },
> + avctx->time_base);
>  pkt->size   = outbuf_ptr - pkt->data;
>  if (s->image || !avctx->frame_number)
>  pkt->flags |= AV_PKT_FLAG_KEY;

Where does the magic 1/100 timebase come from? For encoding, the
AVFrame's time base is supposed to be AVCodecContext.time_base. This
could actually be done generically for all video-encoders without delay.
(I know that AVFrame has a time_base of its own that is currently unset
and unused.)

- 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] fftools/ffmpeg_opt: try to propagate the requested output channel layout

2022-08-23 Thread James Almer

On 8/21/2022 5:42 PM, James Almer wrote:

Don't silently replace it with the default layout for the amount of channels
from the requested layout.

Should fix ticket #9869

Signed-off-by: James Almer 
---
  fftools/ffmpeg_opt.c | 38 +-
  1 file changed, 37 insertions(+), 1 deletion(-)

diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 30ca5cd609..3a555c4c16 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -2865,6 +2865,42 @@ static void of_add_metadata(AVFormatContext *oc, const 
OptionsContext *o)
  }
  }
  }
+static void set_channel_layout(OutputFilter *f, OutputStream *ost)
+{
+int i, err;
+
+if (ost->enc_ctx->ch_layout.order != AV_CHANNEL_ORDER_UNSPEC) {
+/* Pass the layout through for all orders but UNSPEC */
+err = av_channel_layout_copy(&f->ch_layout, &ost->enc_ctx->ch_layout);
+if (err < 0)
+exit_program(1);
+return;
+}
+
+/* Requested layout is of order UNSPEC */
+if (!ost->enc->ch_layouts) {
+/* Use the default native layout for the requested amount of channels 
when the
+   encoder doesn't have a list of supported layouts */
+av_channel_layout_default(&f->ch_layout, 
ost->enc_ctx->ch_layout.nb_channels);
+return;
+}
+/* Encoder has a list of supported layouts. Pick the first layout in it 
with the
+   same amount of channels as the requested layout */
+for (i = 0; ost->enc->ch_layouts[i].nb_channels; i++) {
+if (ost->enc->ch_layouts[i].nb_channels == 
ost->enc_ctx->ch_layout.nb_channels)
+break;
+}
+if (ost->enc->ch_layouts[i].nb_channels) {
+/* Use it if one is found */
+err = av_channel_layout_copy(&f->ch_layout, &ost->enc->ch_layouts[i]);
+if (err < 0)
+exit_program(1);
+return;
+}
+/* If no layout for the amount of channels requested was found, use the 
default
+   native layout for it. */
+av_channel_layout_default(&f->ch_layout, 
ost->enc_ctx->ch_layout.nb_channels);
+}
  
  static int open_output_file(OptionsContext *o, const char *filename)

  {
@@ -3055,7 +3091,7 @@ static int open_output_file(OptionsContext *o, const char 
*filename)
  f->sample_rates = ost->enc->supported_samplerates;
  }
  if (ost->enc_ctx->ch_layout.nb_channels) {
-av_channel_layout_default(&f->ch_layout, 
ost->enc_ctx->ch_layout.nb_channels);
+set_channel_layout(f, ost);
  } else if (ost->enc->ch_layouts) {
  f->ch_layouts = ost->enc->ch_layouts;
  }


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

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


Re: [FFmpeg-devel] [PATCH] avcodec/gif: fix duration of last packet/frame

2022-08-23 Thread Paul B Mahol
On Tue, Aug 23, 2022 at 2:18 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:

> Paul B Mahol:
> > Hi,
> >
> > patch attached.
> >
> >  return ret;
> >  }
> >
> > +pkt->duration = av_rescale_q(pict->duration, (AVRational){ 1, 100 },
> > + avctx->time_base);
> >  pkt->size   = outbuf_ptr - pkt->data;
> >  if (s->image || !avctx->frame_number)
> >  pkt->flags |= AV_PKT_FLAG_KEY;
>
> Where does the magic 1/100 timebase come from? For encoding, the
> AVFrame's time base is supposed to be AVCodecContext.time_base. This
> could actually be done generically for all video-encoders without delay.
> (I know that AVFrame has a time_base of its own that is currently unset
> and unused.)
>
> It is from gif demuxer/"container", it uses 1/100 timebase.

Similar thing is done for audio encoders.



> - Andreas
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


Re: [FFmpeg-devel] [PATCH 02/10] avcodec/wmalosslessdec: Remove unnecessary emms_c()

2022-08-23 Thread Andreas Rheinhardt
Andreas Rheinhardt:
> Possible since 6feea076e98512d78c8d735509ab6b5e9a71ca1c.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/wmalosslessdec.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/libavcodec/wmalosslessdec.c b/libavcodec/wmalosslessdec.c
> index 614b6135f5..6ba9f04d25 100644
> --- a/libavcodec/wmalosslessdec.c
> +++ b/libavcodec/wmalosslessdec.c
> @@ -783,7 +783,6 @@ static void revert_cdlms ## bits (WmallDecodeCtx *s, int 
> ch, \
>  s->channel_residues[ch][icoef] = input; \
>  } \
>  } \
> -if (bits <= 16) emms_c(); \
>  }
>  
>  CD_LMS(16, WMALL_COEFF_PAD_SIZE)

Will apply the rest of this patchset tomorrow unless there are objections.

- 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/gif: fix duration of last packet/frame

2022-08-23 Thread Andreas Rheinhardt
Andreas Rheinhardt:
> Paul B Mahol:
>> Hi,
>>
>> patch attached.
>>
>>  return ret;
>>  }
>>  
>> +pkt->duration = av_rescale_q(pict->duration, (AVRational){ 1, 100 },
>> + avctx->time_base);
>>  pkt->size   = outbuf_ptr - pkt->data;
>>  if (s->image || !avctx->frame_number)
>>  pkt->flags |= AV_PKT_FLAG_KEY;
> 
> Where does the magic 1/100 timebase come from? For encoding, the
> AVFrame's time base is supposed to be AVCodecContext.time_base. This
> could actually be done generically for all video-encoders without delay.
> (I know that AVFrame has a time_base of its own that is currently unset
> and unused.)
> 

Strangely, if I do exactly as above, the gifenc tests show weird
durations like:

+0,  0,  0,   10, 1368, 0x6cf0befd

+0,  1,  1,   10,  158, 0xcd173bb4, F=0x0

+0,  2,  2,   10,  163, 0x4f7a451d, F=0x0

+0,  3,  3,   10,  152, 0x17723839, F=0x0

+0,  4,  4,   10,  160, 0x67854056, F=0x0


So somewhere a timebase is wrong or AVFrame.duration is not converted to
a new timebase somewhere.

- 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] ipfsgateway: Remove default gateway

2022-08-23 Thread Ronald S. Bultje
Hi,

On Mon, Aug 22, 2022 at 5:52 AM Nicolas George  wrote:

> Tomas Härdin (12022-08-22):
> > I'd actually argue that in that case we should link a library that
> > implements IPFS, not split developer effort by trying to implement it
> > ourselves.
>
> Is FFmpeg meant to be just a convenient set of wrappers for existing
> libraries, then?
>
> If not, what is your criterion to decide when splitting developer effort
> is worth including a native version in FFmpeg.
>

I think it usually comes down to a developer wanting to, you know, spend
time on it.

As an example: if Tomas (or anyone) wants to write native IPFS: great.
Otherwise, we can accept an external lib for it.

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

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


Re: [FFmpeg-devel] [PATCH] ipfsgateway: Remove default gateway

2022-08-23 Thread Nicolas George
Ronald S. Bultje (12022-08-23):
> I think it usually comes down to a developer wanting to, you know, spend
> time on it.

Sure, it can be that. But not only. I have seen people, including Tomas
himself, oppose code in favor of using a library.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


Re: [FFmpeg-devel] [PATCH] avcodec/gif: fix duration of last packet/frame

2022-08-23 Thread Andreas Rheinhardt
Paul B Mahol:
> diff --git a/libavformat/gif.c b/libavformat/gif.c
> index b52ff4dd39..afb5767541 100644
> --- a/libavformat/gif.c
> +++ b/libavformat/gif.c
> @@ -36,7 +36,6 @@ typedef struct GIFContext {
>  int duration;
>  int64_t last_pos;
>  int have_end;
> -AVPacket *prev_pkt;
>  } GIFContext;
>  
>  static int gif_write_header(AVFormatContext *s)
> @@ -81,28 +80,20 @@ static int gif_parse_packet(AVFormatContext *s, const 
> uint8_t *data, int size)
>  return 0;
>  }
>  
> -static int gif_get_delay(GIFContext *gif, AVPacket *prev, AVPacket *new)
> +static int gif_get_delay(GIFContext *gif, AVPacket *pkt)
>  {
> -if (new && new->pts != AV_NOPTS_VALUE)
> -gif->duration = av_clip_uint16(new->pts - prev->pts);
> -else if (!new && gif->last_delay >= 0)
> +if (pkt->duration != 0)
> +gif->duration = av_clip_uint16(pkt->duration);
> +else if (!pkt && gif->last_delay >= 0)

pkt is always non-NULL here. Muxers that don't have the
AVFMT_ALLOW_FLUSH flag set never get NULL packets.
Adding said flag would require more changes in this muxer (it would
actually need to handle the case in which pkt is NULL). Anyway, this
patch as-is breaks muxing for people who don't set pkt->duration, but
rely on the final_delay option.

Anyway, you can modify gif_get_delay() to take AVPacket.duration into
account if it is set. As soon as we manage to properly set
AVPacket.duration in avcodec/the fftools, we can deprecate the
final_delay option.

>  gif->duration = gif->last_delay;
>  
>  return gif->duration;
>  }
>  
> -static int gif_write_packet(AVFormatContext *s, AVPacket *new_pkt)
> +static int gif_write_packet(AVFormatContext *s, AVPacket *pkt)
>  {
>  GIFContext *gif = s->priv_data;
>  AVIOContext *pb = s->pb;
> -AVPacket *pkt = gif->prev_pkt;
> -
> -if (!gif->prev_pkt) {
> -gif->prev_pkt = av_packet_alloc();
> -if (!gif->prev_pkt)
> -return AVERROR(ENOMEM);
> -return av_packet_ref(gif->prev_pkt, new_pkt);
> -}
>  
>  gif->last_pos = avio_tell(pb);
>  if (pkt->size > 0)
> @@ -144,7 +135,7 @@ static int gif_write_packet(AVFormatContext *s, AVPacket 
> *new_pkt)
>  delay_pos = gif_parse_packet(s, pkt->data + off, pkt->size - off);
>  if (delay_pos > 0 && delay_pos < pkt->size - off - 2) {
>  avio_write(pb, pkt->data + off, delay_pos);
> -avio_wl16(pb, gif_get_delay(gif, pkt, new_pkt));
> +avio_wl16(pb, gif_get_delay(gif, pkt));
>  avio_write(pb, pkt->data + off + delay_pos + 2, pkt->size - off 
> - delay_pos - 2);
>  } else {
>  avio_write(pb, pkt->data + off, pkt->size - off);
> @@ -154,17 +145,13 @@ static int gif_write_packet(AVFormatContext *s, 
> AVPacket *new_pkt)
>  
>  if (delay_pos > 0 && delay_pos < pkt->size - 2) {
>  avio_write(pb, pkt->data, delay_pos);
> -avio_wl16(pb, gif_get_delay(gif, pkt, new_pkt));
> +avio_wl16(pb, gif_get_delay(gif, pkt));
>  avio_write(pb, pkt->data + delay_pos + 2, pkt->size - delay_pos 
> - 2);
>  } else {
>  avio_write(pb, pkt->data, pkt->size);
>  }
>  }
>  
> -av_packet_unref(gif->prev_pkt);
> -if (new_pkt)
> -return av_packet_ref(gif->prev_pkt, new_pkt);
> -
>  return 0;
>  }
>  
> @@ -173,14 +160,8 @@ static int gif_write_trailer(AVFormatContext *s)
>  GIFContext *gif = s->priv_data;
>  AVIOContext *pb = s->pb;
>  
> -if (!gif->prev_pkt)
> -return AVERROR(EINVAL);
> -
> -gif_write_packet(s, NULL);
> -
>  if (!gif->have_end)
>  avio_w8(pb, GIF_TRAILER);
> -av_packet_free(&gif->prev_pkt);
>  
>  return 0;
>  }


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

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


[FFmpeg-devel] [PATCH] avcodec/gif: Remove unnecessary headers

2022-08-23 Thread Andreas Rheinhardt
The gif encoder uses the bytestream API, not the PutBit-API.

Signed-off-by: Andreas Rheinhardt 
---
Will apply this tonight unless there are objections.

 libavcodec/gif.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/libavcodec/gif.c b/libavcodec/gif.c
index 8e84b79b8c..c120b4b8fd 100644
--- a/libavcodec/gif.c
+++ b/libavcodec/gif.c
@@ -32,7 +32,6 @@
 
 #define BITSTREAM_WRITER_LE
 #include "libavutil/opt.h"
-#include "libavutil/imgutils.h"
 #include "avcodec.h"
 #include "bytestream.h"
 #include "codec_internal.h"
@@ -40,8 +39,6 @@
 #include "lzw.h"
 #include "gif.h"
 
-#include "put_bits.h"
-
 #define DEFAULT_TRANSPARENCY_INDEX 0x1f
 
 typedef struct GIFContext {
-- 
2.34.1

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

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


Re: [FFmpeg-devel] [PATCH] swscale/x86/rgb2_rgb: Empty MMX state in ff_shuffle_bytes_2103_mmxext

2022-08-23 Thread Michael Niedermayer
On Mon, Aug 22, 2022 at 11:59:17PM +0200, Andreas Rheinhardt wrote:
> Andreas Rheinhardt:
> > Fixes FATE-failures with the the filter-2xbr filter-3xbr filter-4xbr
> > filter-ep2x filter-ep3x filter-hq2x filter-hq3x filter-hq4x
> > filter-paletteuse-bayer filter-paletteuse-bayer0
> > filter-paletteuse-nodither and filter-paletteuse-sierra2_4a tests
> > when using 32bit x86 with CPUFLAGS ranging from "mmx+mmxext" to
> > "mmx+mmxext+sse+sse2+sse3" (the relevant function is only overwritten
> > when using SSSE3).
> > 
> > Signed-off-by: Andreas Rheinhardt 
> > ---
> >  libswscale/x86/rgb_2_rgb.asm | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/libswscale/x86/rgb_2_rgb.asm b/libswscale/x86/rgb_2_rgb.asm
> > index c695c61d5c..76ca1eec03 100644
> > --- a/libswscale/x86/rgb_2_rgb.asm
> > +++ b/libswscale/x86/rgb_2_rgb.asm
> > @@ -104,6 +104,7 @@ jge .end
> >  jl .loop_simd
> >  
> >  .end:
> > +emms
> >  RET
> >  
> >  
> > ;--
> 
> I'd really love if someone with x86 assembly skills could look over this
> trivial patch and confirm whether it is indeed correct. All I currently
> know is that is works for me.

emms needs to be called between MMX and float code, as far outside of loops
as possible
that would suggest outside the for() loops in rgbToRgbWrapper() and any
other code using it. 

thats what we did and what is most efficient. One can make an argument that
emms must be called before returning to C code when its needed. That though
would imply also that all uses of emms_c() are wrong

Above assumes iam not missing something

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
than the original author, trying to rewrite it will not make it better.


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] swscale/x86/rgb2_rgb: Empty MMX state in ff_shuffle_bytes_2103_mmxext

2022-08-23 Thread Andreas Rheinhardt
Michael Niedermayer:
> On Mon, Aug 22, 2022 at 11:59:17PM +0200, Andreas Rheinhardt wrote:
>> Andreas Rheinhardt:
>>> Fixes FATE-failures with the the filter-2xbr filter-3xbr filter-4xbr
>>> filter-ep2x filter-ep3x filter-hq2x filter-hq3x filter-hq4x
>>> filter-paletteuse-bayer filter-paletteuse-bayer0
>>> filter-paletteuse-nodither and filter-paletteuse-sierra2_4a tests
>>> when using 32bit x86 with CPUFLAGS ranging from "mmx+mmxext" to
>>> "mmx+mmxext+sse+sse2+sse3" (the relevant function is only overwritten
>>> when using SSSE3).
>>>
>>> Signed-off-by: Andreas Rheinhardt 
>>> ---
>>>  libswscale/x86/rgb_2_rgb.asm | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/libswscale/x86/rgb_2_rgb.asm b/libswscale/x86/rgb_2_rgb.asm
>>> index c695c61d5c..76ca1eec03 100644
>>> --- a/libswscale/x86/rgb_2_rgb.asm
>>> +++ b/libswscale/x86/rgb_2_rgb.asm
>>> @@ -104,6 +104,7 @@ jge .end
>>>  jl .loop_simd
>>>  
>>>  .end:
>>> +emms
>>>  RET
>>>  
>>>  
>>> ;--
>>
>> I'd really love if someone with x86 assembly skills could look over this
>> trivial patch and confirm whether it is indeed correct. All I currently
>> know is that is works for me.
> 
> emms needs to be called between MMX and float code, as far outside of loops
> as possible
> that would suggest outside the for() loops in rgbToRgbWrapper() and any
> other code using it.

But there is another aspect that the above is missing: Namely that if
emms_c() is put outside of MMX functions, then it will be called even
when it is unnecessary. In this case it is unnecessary for all modern
CPUs, as this function is overridden when SSSE3 is available.

> 
> thats what we did and what is most efficient. One can make an argument that
> emms must be called before returning to C code when its needed. That though
> would imply also that all uses of emms_c() are wrong
> 

Well, e.g. the x64 psABI contains this clause: "The CPU shall be in x87
mode upon entry to a function. Therefore, every
 function that uses the MMX registers is required to issue an emms or femms
 instruction after using MMX registers, before returning or calling
another function."
So using emms_c() is ABI-incompliant. If I add an av_assert0_fpu() at
the beginning of av_log_default_callback (a function that may be
overridden by a user-defined callback that actually relies on us
conforming to the ABI), several FATE tests fail. I am sure that there
are lots of av_logs or other functions that are in parts of the code
where the CPU is not in x87 mode and that are just not executed in fate
because they are error logs.

- Andreas

PS: On the brighter side: fate.ffmpeg.org now contains three more green
boxes!
___
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] swscale/x86/rgb2_rgb: Empty MMX state in ff_shuffle_bytes_2103_mmxext

2022-08-23 Thread Michael Niedermayer
On Tue, Aug 23, 2022 at 07:28:19PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Mon, Aug 22, 2022 at 11:59:17PM +0200, Andreas Rheinhardt wrote:
> >> Andreas Rheinhardt:
> >>> Fixes FATE-failures with the the filter-2xbr filter-3xbr filter-4xbr
> >>> filter-ep2x filter-ep3x filter-hq2x filter-hq3x filter-hq4x
> >>> filter-paletteuse-bayer filter-paletteuse-bayer0
> >>> filter-paletteuse-nodither and filter-paletteuse-sierra2_4a tests
> >>> when using 32bit x86 with CPUFLAGS ranging from "mmx+mmxext" to
> >>> "mmx+mmxext+sse+sse2+sse3" (the relevant function is only overwritten
> >>> when using SSSE3).
> >>>
> >>> Signed-off-by: Andreas Rheinhardt 
> >>> ---
> >>>  libswscale/x86/rgb_2_rgb.asm | 1 +
> >>>  1 file changed, 1 insertion(+)
> >>>
> >>> diff --git a/libswscale/x86/rgb_2_rgb.asm b/libswscale/x86/rgb_2_rgb.asm
> >>> index c695c61d5c..76ca1eec03 100644
> >>> --- a/libswscale/x86/rgb_2_rgb.asm
> >>> +++ b/libswscale/x86/rgb_2_rgb.asm
> >>> @@ -104,6 +104,7 @@ jge .end
> >>>  jl .loop_simd
> >>>  
> >>>  .end:
> >>> +emms
> >>>  RET
> >>>  
> >>>  
> >>> ;--
> >>
> >> I'd really love if someone with x86 assembly skills could look over this
> >> trivial patch and confirm whether it is indeed correct. All I currently
> >> know is that is works for me.
> > 
> > emms needs to be called between MMX and float code, as far outside of loops
> > as possible
> > that would suggest outside the for() loops in rgbToRgbWrapper() and any
> > other code using it.
> 
> But there is another aspect that the above is missing: Namely that if
> emms_c() is put outside of MMX functions, then it will be called even
> when it is unnecessary. In this case it is unnecessary for all modern
> CPUs, as this function is overridden when SSSE3 is available.

If you dont like that,
dont call it when its not needed or call it a few hundread times unnecessary
like your patch does.
or write only code that doesnt need emms 
maybe there are more options ...

thx

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

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.


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/pthread_frame: update the main avctx from the current, ThreadContext

2022-08-23 Thread Michael Niedermayer
On Fri, Aug 19, 2022 at 10:07:54AM +0200, Steve Lhomme wrote:
> Hi,
> 
> On 2022-08-02 16:19, Anton Khirnov wrote:
> > Why are you not resubmitting your original patch that stops copying
> > hwaccel_priv_data to the user-facing context?
> > 
> > It seemed more correct to me, since the user-facing context should never
> > see any hwaccel data. Or does it not fix the issue fully?
> 
> The original patch is not fixing it properly. With that patch and
> avcodec-threads > 1, the uninit of the hardware decoder is not called
> anymore. So it will replace a crash fix with a (big) resource leak.
> 
> For reference, this it the patch we're talking about
> https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg94274.html

Should we maybe add something to the release notes if this bug is
unfixed in the next minor release ?

thx

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

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin


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 v2] doc/git-howto.texi: Document commit signing

2022-08-23 Thread Michael Niedermayer
On Wed, Aug 10, 2022 at 12:19:02AM +0200, Michael Niedermayer wrote:
> On Tue, Aug 09, 2022 at 04:38:56PM -0300, James Almer wrote:
> > On 8/9/2022 4:34 PM, Michael Niedermayer wrote:
> > > From: Michael Niedermayer 
[...]
> 
> > 
> > > +github consider mismatches a reason to declare such commits unverified. 
> > > After generating a key you
> > > +can add it to the MAINTAINER file and upload it to a keyserver.
> > 
> > Maybe link some external documentation about gpg keys, explaining the
> > difference between public and private keys, 
> 
> what do you recommend ?

ping ?
we could link to the gpg docs but that seems kind of silly


> 
> 
> > how to encrypt the private one
> > with a passphrase, etc.
> 
> Have you tried to generate a gpg key without a passphrase ?
> I just tried, and failed, gpg keeps asking for a passphrase until you enter
> one or kill it. It kept haunting me and asking for a passphrase even after
> trying ctrl-c 
> 
> 
> > Sites like gitlab tell you to not attempt to upload private keys, 
> 
> ok
> 
> 
> > so i
> > imagine quite a lot of people have mistakenly done so in the past.
> 
> imagine?
> 
> but what do you suggest? we can document how someone can create a key
> upload it and so on. You can provide me with a url that describes a
> working documentation for that, i surely do not have one. alot of
> documentations are somewhat bad. Many keyservers have died recently
> some existing keys like DSA seem to have some affinity to SHA1, and
> SHA1 is rejected today while at the same time still default on many
> setups, the one documentation i saw today to fix that DSA/SHA1 issue
> requires you to have a backup as it breaks your keys and is wrong.




[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship: All citizens are under surveillance, all their steps and
actions recorded, for the politicians to enforce control.
Democracy: All politicians are under surveillance, all their steps and
actions recorded, for the citizens to enforce control.


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] tools/target_dec_fuzzer: Adjust threshold for NUV

2022-08-23 Thread Michael Niedermayer
On Sat, Aug 13, 2022 at 12:40:27AM +0200, Michael Niedermayer wrote:
> Fixes: Timeout
> Fixes: 
> 49286/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_NUV_fuzzer-5856252655173632
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  tools/target_dec_fuzzer.c | 1 +
>  1 file changed, 1 insertion(+)

will apply

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

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


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 1/5] tools/target_dec_fuzzer: Adjust threshold for VMDVIDEO

2022-08-23 Thread Michael Niedermayer
On Sat, Aug 13, 2022 at 11:50:31PM +0200, Michael Niedermayer wrote:
> Fixes: Timeout
> Fixes: 
> 49350/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VMDVIDEO_fuzzer-4554761801695232
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  tools/target_dec_fuzzer.c | 1 +
>  1 file changed, 1 insertion(+)

will apply patchset

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

The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."


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 v2] doc/git-howto.texi: Document commit signing

2022-08-23 Thread James Almer

On 8/23/2022 3:00 PM, Michael Niedermayer wrote:

On Wed, Aug 10, 2022 at 12:19:02AM +0200, Michael Niedermayer wrote:

On Tue, Aug 09, 2022 at 04:38:56PM -0300, James Almer wrote:

On 8/9/2022 4:34 PM, Michael Niedermayer wrote:

From: Michael Niedermayer 

[...]





+github consider mismatches a reason to declare such commits unverified. After 
generating a key you
+can add it to the MAINTAINER file and upload it to a keyserver.


Maybe link some external documentation about gpg keys, explaining the
difference between public and private keys,


what do you recommend ?


ping ?
we could link to the gpg docs but that seems kind of silly


I have no recommendation.








how to encrypt the private one
with a passphrase, etc.


Have you tried to generate a gpg key without a passphrase ?


I probably mixed it in my mind with ssh keys, where you can store a 
private key unencrypted.



I just tried, and failed, gpg keeps asking for a passphrase until you enter
one or kill it. It kept haunting me and asking for a passphrase even after
trying ctrl-c



Sites like gitlab tell you to not attempt to upload private keys,


ok



so i
imagine quite a lot of people have mistakenly done so in the past.


imagine?


"Every sign has a story". If Gitlab tells you to make sure to not 
attempt to upload a private key, then it could be that it has happened 
at some point.




but what do you suggest? we can document how someone can create a key
upload it and so on. You can provide me with a url that describes a
working documentation for that, i surely do not have one. alot of
documentations are somewhat bad. Many keyservers have died recently
some existing keys like DSA seem to have some affinity to SHA1, and
SHA1 is rejected today while at the same time still default on many
setups, the one documentation i saw today to fix that DSA/SHA1 issue
requires you to have a backup as it breaks your keys and is wrong.


If there's no good documentation or tutorial for this, then lets not 
bother with it. Your patch should be fine as is.







[...]


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

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

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

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


Re: [FFmpeg-devel] [PATCH] swscale/x86/rgb2_rgb: Empty MMX state in ff_shuffle_bytes_2103_mmxext

2022-08-23 Thread Andreas Rheinhardt
Michael Niedermayer:
> On Tue, Aug 23, 2022 at 07:28:19PM +0200, Andreas Rheinhardt wrote:
>> Michael Niedermayer:
>>> On Mon, Aug 22, 2022 at 11:59:17PM +0200, Andreas Rheinhardt wrote:
 Andreas Rheinhardt:
> Fixes FATE-failures with the the filter-2xbr filter-3xbr filter-4xbr
> filter-ep2x filter-ep3x filter-hq2x filter-hq3x filter-hq4x
> filter-paletteuse-bayer filter-paletteuse-bayer0
> filter-paletteuse-nodither and filter-paletteuse-sierra2_4a tests
> when using 32bit x86 with CPUFLAGS ranging from "mmx+mmxext" to
> "mmx+mmxext+sse+sse2+sse3" (the relevant function is only overwritten
> when using SSSE3).
>
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libswscale/x86/rgb_2_rgb.asm | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libswscale/x86/rgb_2_rgb.asm b/libswscale/x86/rgb_2_rgb.asm
> index c695c61d5c..76ca1eec03 100644
> --- a/libswscale/x86/rgb_2_rgb.asm
> +++ b/libswscale/x86/rgb_2_rgb.asm
> @@ -104,6 +104,7 @@ jge .end
>  jl .loop_simd
>  
>  .end:
> +emms
>  RET
>  
>  
> ;--

 I'd really love if someone with x86 assembly skills could look over this
 trivial patch and confirm whether it is indeed correct. All I currently
 know is that is works for me.
>>>
>>> emms needs to be called between MMX and float code, as far outside of loops
>>> as possible
>>> that would suggest outside the for() loops in rgbToRgbWrapper() and any
>>> other code using it.
>>
>> But there is another aspect that the above is missing: Namely that if
>> emms_c() is put outside of MMX functions, then it will be called even
>> when it is unnecessary. In this case it is unnecessary for all modern
>> CPUs, as this function is overridden when SSSE3 is available.
> 
> If you dont like that,
> dont call it when its not needed or call it a few hundread times unnecessary
> like your patch does.
> or write only code that doesnt need emms 
> maybe there are more options ...
> 

If emms_c() is used as now outside of MMX functions, then a "dont call
it when its not needed" would involve a check and would therefore still
incur cost for users who don't use this. Also it is unclear how such a
check would even look like given that one can use av_force_cpu_flags().
See also 55fc2c5a892c50feb1b9a8f55b74ec6594755ddb.
This patch also only calls it a few hundred times unnecessarily if one
runs this without SSSE3. CPUs without SSSE3 are ancient today. For the
non-ancient CPUs, using emms_c() adds an EMMS.

- 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 1/4] avcodec/mpegaudiodec_template: use unsigned shift in handle_crc()

2022-08-23 Thread Michael Niedermayer
On Mon, Aug 15, 2022 at 07:59:24PM +0200, Michael Niedermayer wrote:
> Fixes: left shift of 192 by 24 places cannot be represented in type 'int'
> Fixes: 
> 49577/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MP1FLOAT_fuzzer-5205996678545408
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/mpegaudiodec_template.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

will apply patchset with the typo fixed

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

You can kill me, but you cannot change the truth.


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] swscale/x86/rgb2_rgb: Empty MMX state in ff_shuffle_bytes_2103_mmxext

2022-08-23 Thread Michael Niedermayer
On Tue, Aug 23, 2022 at 08:09:09PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Tue, Aug 23, 2022 at 07:28:19PM +0200, Andreas Rheinhardt wrote:
> >> Michael Niedermayer:
> >>> On Mon, Aug 22, 2022 at 11:59:17PM +0200, Andreas Rheinhardt wrote:
>  Andreas Rheinhardt:
> > Fixes FATE-failures with the the filter-2xbr filter-3xbr filter-4xbr
> > filter-ep2x filter-ep3x filter-hq2x filter-hq3x filter-hq4x
> > filter-paletteuse-bayer filter-paletteuse-bayer0
> > filter-paletteuse-nodither and filter-paletteuse-sierra2_4a tests
> > when using 32bit x86 with CPUFLAGS ranging from "mmx+mmxext" to
> > "mmx+mmxext+sse+sse2+sse3" (the relevant function is only overwritten
> > when using SSSE3).
> >
> > Signed-off-by: Andreas Rheinhardt 
> > ---
> >  libswscale/x86/rgb_2_rgb.asm | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/libswscale/x86/rgb_2_rgb.asm b/libswscale/x86/rgb_2_rgb.asm
> > index c695c61d5c..76ca1eec03 100644
> > --- a/libswscale/x86/rgb_2_rgb.asm
> > +++ b/libswscale/x86/rgb_2_rgb.asm
> > @@ -104,6 +104,7 @@ jge .end
> >  jl .loop_simd
> >  
> >  .end:
> > +emms
> >  RET
> >  
> >  
> > ;--
> 
>  I'd really love if someone with x86 assembly skills could look over this
>  trivial patch and confirm whether it is indeed correct. All I currently
>  know is that is works for me.
> >>>
> >>> emms needs to be called between MMX and float code, as far outside of 
> >>> loops
> >>> as possible
> >>> that would suggest outside the for() loops in rgbToRgbWrapper() and any
> >>> other code using it.
> >>
> >> But there is another aspect that the above is missing: Namely that if
> >> emms_c() is put outside of MMX functions, then it will be called even
> >> when it is unnecessary. In this case it is unnecessary for all modern
> >> CPUs, as this function is overridden when SSSE3 is available.
> > 
> > If you dont like that,
> > dont call it when its not needed or call it a few hundread times unnecessary
> > like your patch does.
> > or write only code that doesnt need emms 
> > maybe there are more options ...
> > 
> 
> If emms_c() is used as now outside of MMX functions, then a "dont call
> it when its not needed" would involve a check and would therefore still
> incur cost for users who don't use this. Also it is unclear how such a
> check would even look like given that one can use av_force_cpu_flags().
> See also 55fc2c5a892c50feb1b9a8f55b74ec6594755ddb.
> This patch also only calls it a few hundred times unnecessarily if one
> runs this without SSSE3. CPUs without SSSE3 are ancient today. For the
> non-ancient CPUs, using emms_c() adds an EMMS.

do whatever you prefer.
The best solution depends on assumptions.
The impact is biggest on old CPUs where EMMS is also a slow instruction
But as you say these are ancient today. very small impact on many vs
small to moderate impact on a today rare setup
the worst is if the bug is left open and time is wasted on bikesheding

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Avoid a single point of failure, be that a person or equipment.


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] swscale/x86/rgb2_rgb: Empty MMX state in ff_shuffle_bytes_2103_mmxext

2022-08-23 Thread Andreas Rheinhardt
Michael Niedermayer:
> On Tue, Aug 23, 2022 at 08:09:09PM +0200, Andreas Rheinhardt wrote:
>> Michael Niedermayer:
>>> On Tue, Aug 23, 2022 at 07:28:19PM +0200, Andreas Rheinhardt wrote:
 Michael Niedermayer:
> On Mon, Aug 22, 2022 at 11:59:17PM +0200, Andreas Rheinhardt wrote:
>> Andreas Rheinhardt:
>>> Fixes FATE-failures with the the filter-2xbr filter-3xbr filter-4xbr
>>> filter-ep2x filter-ep3x filter-hq2x filter-hq3x filter-hq4x
>>> filter-paletteuse-bayer filter-paletteuse-bayer0
>>> filter-paletteuse-nodither and filter-paletteuse-sierra2_4a tests
>>> when using 32bit x86 with CPUFLAGS ranging from "mmx+mmxext" to
>>> "mmx+mmxext+sse+sse2+sse3" (the relevant function is only overwritten
>>> when using SSSE3).
>>>
>>> Signed-off-by: Andreas Rheinhardt 
>>> ---
>>>  libswscale/x86/rgb_2_rgb.asm | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/libswscale/x86/rgb_2_rgb.asm b/libswscale/x86/rgb_2_rgb.asm
>>> index c695c61d5c..76ca1eec03 100644
>>> --- a/libswscale/x86/rgb_2_rgb.asm
>>> +++ b/libswscale/x86/rgb_2_rgb.asm
>>> @@ -104,6 +104,7 @@ jge .end
>>>  jl .loop_simd
>>>  
>>>  .end:
>>> +emms
>>>  RET
>>>  
>>>  
>>> ;--
>>
>> I'd really love if someone with x86 assembly skills could look over this
>> trivial patch and confirm whether it is indeed correct. All I currently
>> know is that is works for me.
>
> emms needs to be called between MMX and float code, as far outside of 
> loops
> as possible
> that would suggest outside the for() loops in rgbToRgbWrapper() and any
> other code using it.

 But there is another aspect that the above is missing: Namely that if
 emms_c() is put outside of MMX functions, then it will be called even
 when it is unnecessary. In this case it is unnecessary for all modern
 CPUs, as this function is overridden when SSSE3 is available.
>>>
>>> If you dont like that,
>>> dont call it when its not needed or call it a few hundread times unnecessary
>>> like your patch does.
>>> or write only code that doesnt need emms 
>>> maybe there are more options ...
>>>
>>
>> If emms_c() is used as now outside of MMX functions, then a "dont call
>> it when its not needed" would involve a check and would therefore still
>> incur cost for users who don't use this. Also it is unclear how such a
>> check would even look like given that one can use av_force_cpu_flags().
>> See also 55fc2c5a892c50feb1b9a8f55b74ec6594755ddb.
>> This patch also only calls it a few hundred times unnecessarily if one
>> runs this without SSSE3. CPUs without SSSE3 are ancient today. For the
>> non-ancient CPUs, using emms_c() adds an EMMS.
> 
> do whatever you prefer.
> The best solution depends on assumptions.
> The impact is biggest on old CPUs where EMMS is also a slow instruction
> But as you say these are ancient today. very small impact on many vs
> small to moderate impact on a today rare setup
> the worst is if the bug is left open and time is wasted on bikesheding
> 

Given that Lynne already approved this on IRC, I have already applied it
as de33506e4b3e3362095aab167ad8bb87c1bd9488.
Several of your FATE-boxes are now green: E.g.
https://fate.ffmpeg.org/history.cgi?slot=x86_32-debian-kfreebsd-gcc-4.4-cpuflags-sse
Rejoice!

- 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] Bitrate estimation API in libavformat muxers

2022-08-23 Thread Kevin Wang
Is there an API to get the bitrate from libavformat muxers that support it?
Many streaming protocols now offer some sort of bandwidth estimation,
wondering if there is a common way to get the outbound link capacity
through libavformat so it can be passed to the encoder easily.

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

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


[FFmpeg-devel] [PATCH v3 0/3] lavf/dashdec: Multithreaded DASH initialization

2022-08-23 Thread Lukas Fellechner
Initializing DASH streams is currently slow, because each individual
stream is opened and probed sequentially. With DASH streams often
having somewhere between 10-20 streams, this can easily take up to
half a minute on slow connections.

This patch adds an "init-threads" option, specifying the max number
of threads to use. Multiple worker threads are spun up to massively
bring down init times.
In-Reply-To: 



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

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


[FFmpeg-devel] [PATCH v3 1/3] lavf/dashdec: Prepare DASH decoder for multithreading

2022-08-23 Thread Lukas Fellechner
For adding multithreading to the DASH decoder initialization,
the open_demux_for_component() method must be split up into two parts:

begin_open_demux_for_component(): Opens the stream and does probing
and format detection. This can be run in parallel.

end_open_demux_for_component(): Creates the AVStreams and adds
them to the common parent AVFormatContext. This method must always be
run synchronously, after all threads are finished.
---
 libavformat/dashdec.c | 42 ++
 1 file changed, 30 insertions(+), 12 deletions(-)

diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 63bf7e96a5..e82da45e43 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -1918,10 +1918,9 @@ fail:
 return ret;
 }

-static int open_demux_for_component(AVFormatContext *s, struct representation 
*pls)
+static int begin_open_demux_for_component(AVFormatContext *s, struct 
representation *pls)
 {
 int ret = 0;
-int i;

 pls->parent = s;
 pls->cur_seq_no  = calc_cur_seg_no(s, pls);
@@ -1931,9 +1930,15 @@ static int open_demux_for_component(AVFormatContext *s, 
struct representation *p
 }

 ret = reopen_demux_for_component(s, pls);
-if (ret < 0) {
-goto fail;
-}
+
+return ret;
+}
+
+static int end_open_demux_for_component(AVFormatContext *s, struct 
representation *pls)
+{
+int ret = 0;
+int i;
+
 for (i = 0; i < pls->ctx->nb_streams; i++) {
 AVStream *st = avformat_new_stream(s, NULL);
 AVStream *ist = pls->ctx->streams[i];
@@ -1965,6 +1970,19 @@ fail:
 return ret;
 }

+static int open_demux_for_component(AVFormatContext* s, struct representation* 
pls)
+{
+int ret = 0;
+
+ret = begin_open_demux_for_component(s, pls);
+if (ret < 0)
+return ret;
+
+ret = end_open_demux_for_component(s, pls);
+
+return ret;
+}
+
 static int is_common_init_section_exist(struct representation **pls, int n_pls)
 {
 struct fragment *first_init_section = pls[0]->init_section;
@@ -2040,9 +2058,15 @@ static int dash_read_header(AVFormatContext *s)
 av_dict_set(&c->avio_opts, "seekable", "0", 0);
 }

-if(c->n_videos)
+if (c->n_videos)
 c->is_init_section_common_video = 
is_common_init_section_exist(c->videos, c->n_videos);

+if (c->n_audios)
+c->is_init_section_common_audio = 
is_common_init_section_exist(c->audios, c->n_audios);
+
+if (c->n_subtitles)
+c->is_init_section_common_subtitle = 
is_common_init_section_exist(c->subtitles, c->n_subtitles);
+
 /* Open the demuxer for video and audio components if available */
 for (i = 0; i < c->n_videos; i++) {
 rep = c->videos[i];
@@ -2059,9 +2083,6 @@ static int dash_read_header(AVFormatContext *s)
 ++stream_index;
 }

-if(c->n_audios)
-c->is_init_section_common_audio = 
is_common_init_section_exist(c->audios, c->n_audios);
-
 for (i = 0; i < c->n_audios; i++) {
 rep = c->audios[i];
 if (i > 0 && c->is_init_section_common_audio) {
@@ -2077,9 +2098,6 @@ static int dash_read_header(AVFormatContext *s)
 ++stream_index;
 }

-if (c->n_subtitles)
-c->is_init_section_common_subtitle = 
is_common_init_section_exist(c->subtitles, c->n_subtitles);
-
 for (i = 0; i < c->n_subtitles; i++) {
 rep = c->subtitles[i];
 if (i > 0 && c->is_init_section_common_subtitle) {
--
2.31.1.windows.1

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

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


[FFmpeg-devel] [PATCH v3 2/3] lavf/dashdec: Multithreaded DASH initialization

2022-08-23 Thread Lukas Fellechner
This patch adds an "init-threads" option, specifying the max
number of threads to use. Multiple worker threads are spun up
to massively bring down init times.
---
 libavformat/dashdec.c | 351 +-
 1 file changed, 350 insertions(+), 1 deletion(-)

diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index e82da45e43..20f2557ea3 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -24,6 +24,7 @@
 #include "libavutil/opt.h"
 #include "libavutil/time.h"
 #include "libavutil/parseutils.h"
+#include "libavutil/thread.h"
 #include "internal.h"
 #include "avio_internal.h"
 #include "dash.h"
@@ -152,6 +153,8 @@ typedef struct DASHContext {
 int max_url_size;
 char *cenc_decryption_key;

+int init_threads;
+
 /* Flags for init section*/
 int is_init_section_common_video;
 int is_init_section_common_audio;
@@ -2033,6 +2036,331 @@ static void move_metadata(AVStream *st, const char 
*key, char **value)
 }
 }

+#if HAVE_THREADS
+
+struct work_pool_data
+{
+AVFormatContext *ctx;
+struct representation *pls;
+struct representation *common_pls;
+pthread_mutex_t *common_mutex;
+pthread_cond_t *common_condition;
+int is_common;
+int is_started;
+int result;
+};
+
+struct thread_data
+{
+pthread_t thread;
+pthread_mutex_t *mutex;
+struct work_pool_data *work_pool;
+int work_pool_size;
+int is_started;
+int has_error;
+};
+
+static void *worker_thread(void *ptr)
+{
+int ret = 0;
+int i;
+struct thread_data *thread_data = (struct thread_data*)ptr;
+struct work_pool_data *work_pool = NULL;
+struct work_pool_data *data = NULL;
+for (;;) {
+
+// get next work item unless there was an error
+pthread_mutex_lock(thread_data->mutex);
+data = NULL;
+if (!thread_data->has_error) {
+work_pool = thread_data->work_pool;
+for (i = 0; i < thread_data->work_pool_size; i++) {
+if (!work_pool->is_started) {
+data = work_pool;
+data->is_started = 1;
+break;
+}
+work_pool++;
+}
+}
+pthread_mutex_unlock(thread_data->mutex);
+
+if (!data) {
+// no more work to do
+return NULL;
+}
+
+// if we are common section provider, init and signal
+if (data->is_common) {
+data->pls->parent = data->ctx;
+ret = update_init_section(data->pls);
+if (ret < 0) {
+pthread_cond_signal(data->common_condition);
+goto end;
+}
+else
+ret = AVERROR(pthread_cond_signal(data->common_condition));
+}
+
+// if we depend on common section provider, wait for signal and copy
+if (data->common_pls) {
+ret = AVERROR(pthread_cond_wait(data->common_condition, 
data->common_mutex));
+if (ret < 0)
+goto end;
+
+if (!data->common_pls->init_sec_buf) {
+goto end;
+ret = AVERROR(EFAULT);
+}
+
+ret = copy_init_section(data->pls, data->common_pls);
+if (ret < 0)
+goto end;
+}
+
+ret = begin_open_demux_for_component(data->ctx, data->pls);
+if (ret < 0)
+goto end;
+
+end:
+data->result = ret;
+
+// notify error to other threads and exit
+if (ret < 0) {
+pthread_mutex_lock(thread_data->mutex);
+thread_data->has_error = 1;
+pthread_mutex_unlock(thread_data->mutex);
+return NULL;
+}
+}
+
+
+return NULL;
+}
+
+static void create_work_pool_data(AVFormatContext *ctx, int stream_index,
+struct representation *pls, struct representation *common_pls,
+struct work_pool_data *init_data, pthread_mutex_t *common_mutex,
+pthread_cond_t *common_condition)
+{
+init_data->ctx = ctx;
+init_data->pls = pls;
+init_data->pls->stream_index = stream_index;
+init_data->common_condition = common_condition;
+init_data->common_mutex = common_mutex;
+init_data->result = -1;
+
+if (pls == common_pls) {
+init_data->is_common = 1;
+}
+else if (common_pls) {
+init_data->common_pls = common_pls;
+}
+}
+
+static int start_thread(struct thread_data *thread_data,
+struct work_pool_data *work_pool, int work_pool_size, pthread_mutex_t 
*mutex)
+{
+int ret;
+
+thread_data->mutex = mutex;
+thread_data->work_pool = work_pool;
+thread_data->work_pool_size = work_pool_size;
+
+ret = AVERROR(pthread_create(&thread_data->thread, NULL, worker_thread, 
(void*)thread_data));
+if (ret == 0)
+thread_data->is_started = 1;
+
+return ret;
+}
+
+static int init_streams_multithreaded(AVFormatContext *s, int nstreams, int 
threads)
+{
+DASHConte

[FFmpeg-devel] [PATCH v3 3/3] lavf/dashdec: Fix indentation after multithreading

2022-08-23 Thread Lukas Fellechner
---
 libavformat/dashdec.c | 74 +--
 1 file changed, 37 insertions(+), 37 deletions(-)

diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 20f2557ea3..f653b9850e 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -2412,54 +2412,54 @@ static int dash_read_header(AVFormatContext *s)
 }
 else
 {
-/* Open the demuxer for video and audio components if available */
-for (i = 0; i < c->n_videos; i++) {
-rep = c->videos[i];
-if (i > 0 && c->is_init_section_common_video) {
-ret = copy_init_section(rep, c->videos[0]);
-if (ret < 0)
+/* Open the demuxer for video and audio components if available */
+for (i = 0; i < c->n_videos; i++) {
+rep = c->videos[i];
+if (i > 0 && c->is_init_section_common_video) {
+ret = copy_init_section(rep, c->videos[0]);
+if (ret < 0)
+return ret;
+}
+ret = open_demux_for_component(s, rep);
+
+if (ret)
 return ret;
+rep->stream_index = stream_index;
+++stream_index;
 }
-ret = open_demux_for_component(s, rep);

-if (ret)
-return ret;
-rep->stream_index = stream_index;
-++stream_index;
-}
+for (i = 0; i < c->n_audios; i++) {
+rep = c->audios[i];
+if (i > 0 && c->is_init_section_common_audio) {
+ret = copy_init_section(rep, c->audios[0]);
+if (ret < 0)
+return ret;
+}
+ret = open_demux_for_component(s, rep);

-for (i = 0; i < c->n_audios; i++) {
-rep = c->audios[i];
-if (i > 0 && c->is_init_section_common_audio) {
-ret = copy_init_section(rep, c->audios[0]);
-if (ret < 0)
+if (ret)
 return ret;
+rep->stream_index = stream_index;
+++stream_index;
 }
-ret = open_demux_for_component(s, rep);

-if (ret)
-return ret;
-rep->stream_index = stream_index;
-++stream_index;
-}
+for (i = 0; i < c->n_subtitles; i++) {
+rep = c->subtitles[i];
+if (i > 0 && c->is_init_section_common_subtitle) {
+ret = copy_init_section(rep, c->subtitles[0]);
+if (ret < 0)
+return ret;
+}
+ret = open_demux_for_component(s, rep);

-for (i = 0; i < c->n_subtitles; i++) {
-rep = c->subtitles[i];
-if (i > 0 && c->is_init_section_common_subtitle) {
-ret = copy_init_section(rep, c->subtitles[0]);
-if (ret < 0)
+if (ret)
 return ret;
+rep->stream_index = stream_index;
+++stream_index;
 }
-ret = open_demux_for_component(s, rep);

-if (ret)
-return ret;
-rep->stream_index = stream_index;
-++stream_index;
-}
-
-if (!stream_index)
-return AVERROR_INVALIDDATA;
+if (!stream_index)
+return AVERROR_INVALIDDATA;
 }

 /* Create a program */
--
2.31.1.windows.1

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

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


Re: [FFmpeg-devel] [PATCH v2] lavf/dashdec: Multithreaded DASH initialization

2022-08-23 Thread Lukas Fellechner
Gesendet: Dienstag, 23. August 2022 um 05:19 Uhr
Von: "Steven Liu" 
An: "FFmpeg development discussions and patches" 
Betreff: Re: [FFmpeg-devel] [PATCH v2] lavf/dashdec: Multithreaded DASH 
initialization
Lukas Fellechner  于2022年8月22日周一 03:27写道:
>
> I look at the new functions likes begin_open_demux_for_component and
> end_open_demux_for_component maybe can separate patch.
> maybe you can submit two patch, one is make code clarify, the other
> one support multithreads,

Good idea. I split up the patch into three parts actually. Git seems to
be pretty bad in handling indentation changes, which made the first patch
look awful, although there were only very small changes.

So I pulled out the indentation change into a separate patch.
Not sure if that is a good idea, but it makes the other two patches
much more readable.
___
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] FFmpeg 5.1.1

2022-08-23 Thread Michael Niedermayer
Hi

As there are quite a bunch of bugfixes accumulated I intend to make
5.1.1 soon (in less than a week)

thx
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


[FFmpeg-devel] [PATCH] avformat/mov: Check count sums in build_open_gop_key_points()

2022-08-23 Thread Michael Niedermayer
Fixes: ffmpeg.md
Fixes: Out of array access
Fixes: CVE-2022-2566

Found-by: Andy Nguyen 
Found-by: 3pvd <3...@google.com>
Reviewed-by: Andy Nguyen 
Signed-off-by: Michael Niedermayer 
---
 libavformat/mov.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 1d8c5b2904..35e2271b14 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3967,8 +3967,11 @@ static int build_open_gop_key_points(AVStream *st)
 
 /* Build an unrolled index of the samples */
 sc->sample_offsets_count = 0;
-for (uint32_t i = 0; i < sc->ctts_count; i++)
+for (uint32_t i = 0; i < sc->ctts_count; i++) {
+if (sc->ctts_data[i].count > INT_MAX - sc->sample_offsets_count)
+return AVERROR(ENOMEM);
 sc->sample_offsets_count += sc->ctts_data[i].count;
+}
 av_freep(&sc->sample_offsets);
 sc->sample_offsets = av_calloc(sc->sample_offsets_count, 
sizeof(*sc->sample_offsets));
 if (!sc->sample_offsets)
@@ -3987,8 +3990,11 @@ static int build_open_gop_key_points(AVStream *st)
 /* Build a list of open-GOP key samples */
 sc->open_key_samples_count = 0;
 for (uint32_t i = 0; i < sc->sync_group_count; i++)
-if (sc->sync_group[i].index == cra_index)
+if (sc->sync_group[i].index == cra_index) {
+if (sc->sync_group[i].count > INT_MAX - sc->open_key_samples_count)
+return AVERROR(ENOMEM);
 sc->open_key_samples_count += sc->sync_group[i].count;
+}
 av_freep(&sc->open_key_samples);
 sc->open_key_samples = av_calloc(sc->open_key_samples_count, 
sizeof(*sc->open_key_samples));
 if (!sc->open_key_samples)
@@ -3999,6 +4005,8 @@ static int build_open_gop_key_points(AVStream *st)
 if (sg->index == cra_index)
 for (uint32_t j = 0; j < sg->count; j++)
 sc->open_key_samples[k++] = sample_id;
+if (sg->count > INT_MAX - sample_id)
+return AVERROR_PATCHWELCOME;
 sample_id += sg->count;
 }
 
-- 
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] Allow exporting of RGB and BGR images to CUDA.

2022-08-23 Thread dpeeters
> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> dpeeters@MRU.MEDICAL.CANON
> Sent: Thursday, July 28, 2022 11:24 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [EXTERNAL] Re: [FFmpeg-devel] [PATCH] Allow exporting of RGB
> and BGR images to CUDA.
> 
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of
> > dpeeters@MRU.MEDICAL.CANON
> > Sent: Friday, July 8, 2022 4:51 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: [EXTERNAL] [FFmpeg-devel] [PATCH] Allow exporting of RGB and
> > BGR images to CUDA.
> >
> > Use the step size when calculating the number of channels to allow for
> > more than two channels per plane.  This allows the use of
> > AV_PIX_FMT_0BGR32 when using av_hwframe_transfer_data to transfer
> data
> > from a Vulkan frame to a CUDA frame.
> >
> > Signed-off-by: David Peeters 
> > ---
> >  libavutil/hwcontext_vulkan.c | 8 +++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavutil/hwcontext_vulkan.c
> > b/libavutil/hwcontext_vulkan.c index 237caa4bc0..05e8fc5268 100644
> > --- a/libavutil/hwcontext_vulkan.c
> > +++ b/libavutil/hwcontext_vulkan.c
> > @@ -2992,6 +2992,8 @@ static int
> > vulkan_export_to_cuda(AVHWFramesContext *hwfc,
> >  const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(hwfc-
> > >sw_format);
> >  VulkanDevicePriv *p = ctx->internal->priv;
> >  FFVulkanFunctions *vk = &p->vkfn;
> > +int max_pixsteps[4];
> > +int max_pixstep_comps[4];
> >
> >  AVHWFramesContext *cuda_fc = (AVHWFramesContext*)cuda_hwfc-
> > >data;
> >  AVHWDeviceContext *cuda_cu = cuda_fc->device_ctx; @@ -3001,6
> > +3003,8 @@ static int vulkan_export_to_cuda(AVHWFramesContext
> *hwfc,
> >  CUarray_format cufmt = desc->comp[0].depth > 8 ?
> > CU_AD_FORMAT_UNSIGNED_INT16 :
> >
> > CU_AD_FORMAT_UNSIGNED_INT8;
> >
> > +av_image_fill_max_pixsteps(max_pixsteps, max_pixstep_comps,
> > + desc);
> > +
> >  dst_f = (AVVkFrame *)frame->data[0];
> >
> >  dst_int = dst_f->internal;
> > @@ -3023,7 +3027,9 @@ static int
> > vulkan_export_to_cuda(AVHWFramesContext *hwfc,
> >  .arrayDesc = {
> >  .Depth = 0,
> >  .Format = cufmt,
> > -.NumChannels = 1 + ((planes == 2) && i),
> > +.NumChannels = desc->comp[max_pixstep_comps[i]].depth 
> > > 8
> > +? max_pixsteps[i] / 2
> > +: max_pixsteps[i],
> >  .Flags = 0,
> >  },
> >  .numLevels = 1,
> > --
> > 2.36.1
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> >
> https://urldefense.com/v3/__https://ffmpeg.org/mailman/listinfo/ffmpeg
> > -
> > devel__;!!Ai2CFrZnFhI!6NGwn-
> > Nv1AZn7qfPlMbwKHeDqU79spui_ApfLibprH2k3cVnA6ayxejFpL_xrg-
> > 8adz1jY9btFkZrg33AWLLDsXfE_uWCpvx$
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> 
> Ping.
> Are there any changes needed for this?
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://urldefense.com/v3/__https://ffmpeg.org/mailman/listinfo/ffmpeg-
> devel__;!!Ai2CFrZnFhI!_8PN4GC6c0n28X6z7gL1O_2a6oaf-
> cxdrbLpTmzsR4HvKg7EtCBTrFBiOUrsQrY_ptbzSzlpiVrLjzrCotNFYmkiQZn2BHW
> _$
> 
> To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org
> with subject "unsubscribe".

Ping.
___
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] Fix wavpack decoding regression

2022-08-23 Thread Paul B Mahol
Patch attached.
From 217f31c5eb9355bb8fc61a9f46595ee06628c8b9 Mon Sep 17 00:00:00 2001
From: Paul B Mahol 
Date: Tue, 23 Aug 2022 22:39:41 +0200
Subject: [PATCH] avcodec/wavpack: unbreak regression in decoding

Signed-off-by: Paul B Mahol 
---
 libavcodec/wavpack.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/wavpack.c b/libavcodec/wavpack.c
index c12e1d6ec6..8ab195cc10 100644
--- a/libavcodec/wavpack.c
+++ b/libavcodec/wavpack.c
@@ -266,7 +266,7 @@ static int wv_get_value(WavpackFrameContext *ctx, GetBitContext *gb,
 INC_MED(2);
 }
 if (!c->error_limit) {
-if (add >= 0x200U) {
+if (add >= 0x2000U) {
 av_log(ctx->avctx, AV_LOG_ERROR, "k %d is too large\n", add);
 goto error;
 }
-- 
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".


Re: [FFmpeg-devel] [PATCH] Fix wavpack decoding regression

2022-08-23 Thread Andreas Rheinhardt
Paul B Mahol:
> Patch attached.
> From 217f31c5eb9355bb8fc61a9f46595ee06628c8b9 Mon Sep 17 00:00:00 2001
> From: Paul B Mahol 
> Date: Tue, 23 Aug 2022 22:39:41 +0200
> Subject: [PATCH] avcodec/wavpack: unbreak regression in decoding
> 

You should mention the commit that introduced the regression.

> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/wavpack.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/wavpack.c b/libavcodec/wavpack.c
> index c12e1d6ec6..8ab195cc10 100644
> --- a/libavcodec/wavpack.c
> +++ b/libavcodec/wavpack.c
> @@ -266,7 +266,7 @@ static int wv_get_value(WavpackFrameContext *ctx, 
> GetBitContext *gb,
>  INC_MED(2);
>  }
>  if (!c->error_limit) {
> -if (add >= 0x200U) {
> +if (add >= 0x2000U) {

You should explain why this is safe.

>  av_log(ctx->avctx, AV_LOG_ERROR, "k %d is too large\n", add);
>  goto error;
>  }

___
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] Fix wavpack decoding regression

2022-08-23 Thread Paul B Mahol
Better fix attached.
From 8d0a8dee32c2d51c6bf1bcd58e5e96ba92e6341b Mon Sep 17 00:00:00 2001
From: Paul B Mahol 
Date: Tue, 23 Aug 2022 22:39:41 +0200
Subject: [PATCH] avcodec/wavpack: fix regression in decoding

Regression introduced in c6831e2a70f734c71f483d69d46d0635963530.
Fix it by using bitreader that reads 0-32 bits, instead of
0-25 bits and asserting on anything higher.

Signed-off-by: Paul B Mahol 
---
 libavcodec/wavpack.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/libavcodec/wavpack.c b/libavcodec/wavpack.c
index c12e1d6ec6..a09ce00fe2 100644
--- a/libavcodec/wavpack.c
+++ b/libavcodec/wavpack.c
@@ -119,7 +119,7 @@ typedef struct WavpackContext {
 
 #define LEVEL_DECAY(a)  (((a) + 0x80) >> 8)
 
-static av_always_inline unsigned get_tail(GetBitContext *gb, int k)
+static av_always_inline unsigned get_tail(GetBitContext *gb, unsigned k)
 {
 int p, e, res;
 
@@ -127,7 +127,7 @@ static av_always_inline unsigned get_tail(GetBitContext *gb, int k)
 return 0;
 p   = av_log2(k);
 e   = (1 << (p + 1)) - k - 1;
-res = get_bitsz(gb, p);
+res = get_bits_long(gb, p);
 if (res >= e)
 res = (res << 1) - e + get_bits1(gb);
 return res;
@@ -266,10 +266,6 @@ static int wv_get_value(WavpackFrameContext *ctx, GetBitContext *gb,
 INC_MED(2);
 }
 if (!c->error_limit) {
-if (add >= 0x200U) {
-av_log(ctx->avctx, AV_LOG_ERROR, "k %d is too large\n", add);
-goto error;
-}
 ret = base + get_tail(gb, add);
 if (get_bits_left(gb) <= 0)
 goto error;
-- 
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".


Re: [FFmpeg-devel] [PATCH] avcodec/libvpx: fix assembling vp9 packets with alpha channel

2022-08-23 Thread Vignesh Venkatasubramanian
On Sun, Aug 21, 2022 at 10:21 AM James Almer  wrote:
>
> There's no warranty that vpx_codec_encode() will generate a list with the same
> amount of packets for both the yuv planes encoder and the alpha plane encoder,
> so queueing packets based on what the main encoder returns will fail when the
> amount of packets in both lists differ.
> Queue all data packets for every vpx_codec_encode() call from both encoders
> before attempting to assemble output AVPackets out of them.
>
> Fixes ticket #9884
>

lgtm. thanks for fixing this!

> Signed-off-by: James Almer 
> ---
>  libavcodec/libvpxenc.c | 83 --
>  1 file changed, 40 insertions(+), 43 deletions(-)
>
> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> index 5b7c7735a1..e08df5fb96 100644
> --- a/libavcodec/libvpxenc.c
> +++ b/libavcodec/libvpxenc.c
> @@ -56,8 +56,6 @@
>  struct FrameListData {
>  void *buf;   /**< compressed data buffer */
>  size_t sz;   /**< length of compressed data */
> -void *buf_alpha;
> -size_t sz_alpha;
>  int64_t pts; /**< time stamp to show frame
>(in timebase units) */
>  unsigned long duration;  /**< duration to show frame
> @@ -87,6 +85,7 @@ typedef struct VPxEncoderContext {
>  int have_sse; /**< true if we have pending sse[] */
>  uint64_t frame_number;
>  struct FrameListData *coded_frame_list;
> +struct FrameListData *alpha_coded_frame_list;
>
>  int cpu_used;
>  int sharpness;
> @@ -311,8 +310,6 @@ static void coded_frame_add(void *list, struct 
> FrameListData *cx_frame)
>  static av_cold void free_coded_frame(struct FrameListData *cx_frame)
>  {
>  av_freep(&cx_frame->buf);
> -if (cx_frame->buf_alpha)
> -av_freep(&cx_frame->buf_alpha);
>  av_freep(&cx_frame);
>  }
>
> @@ -446,6 +443,7 @@ static av_cold int vpx_free(AVCodecContext *avctx)
>  av_freep(&ctx->twopass_stats.buf);
>  av_freep(&avctx->stats_out);
>  free_frame_list(ctx->coded_frame_list);
> +free_frame_list(ctx->alpha_coded_frame_list);
>  if (ctx->hdr10_plus_fifo)
>  free_hdr10_plus_fifo(&ctx->hdr10_plus_fifo);
>  return 0;
> @@ -1205,7 +1203,6 @@ static av_cold int vpx_init(AVCodecContext *avctx,
>
>  static inline void cx_pktcpy(struct FrameListData *dst,
>   const struct vpx_codec_cx_pkt *src,
> - const struct vpx_codec_cx_pkt *src_alpha,
>   VPxContext *ctx)
>  {
>  dst->pts  = src->data.frame.pts;
> @@ -1229,13 +1226,6 @@ static inline void cx_pktcpy(struct FrameListData *dst,
>  } else {
>  dst->frame_number = -1;   /* sanity marker */
>  }
> -if (src_alpha) {
> -dst->buf_alpha = src_alpha->data.frame.buf;
> -dst->sz_alpha = src_alpha->data.frame.sz;
> -} else {
> -dst->buf_alpha = NULL;
> -dst->sz_alpha = 0;
> -}
>  }
>
>  /**
> @@ -1246,7 +1236,7 @@ static inline void cx_pktcpy(struct FrameListData *dst,
>   * @return a negative AVERROR on error
>   */
>  static int storeframe(AVCodecContext *avctx, struct FrameListData *cx_frame,
> -  AVPacket *pkt)
> +  struct FrameListData *alpha_cx_frame, AVPacket *pkt)
>  {
>  VPxContext *ctx = avctx->priv_data;
>  int ret = ff_get_encode_buffer(avctx, pkt, cx_frame->sz, 0);
> @@ -1279,16 +1269,16 @@ static int storeframe(AVCodecContext *avctx, struct 
> FrameListData *cx_frame,
>  avctx->error[i] += cx_frame->sse[i + 1];
>  cx_frame->have_sse = 0;
>  }
> -if (cx_frame->sz_alpha > 0) {
> +if (alpha_cx_frame) {
>  side_data = av_packet_new_side_data(pkt,
>  
> AV_PKT_DATA_MATROSKA_BLOCKADDITIONAL,
> -cx_frame->sz_alpha + 8);
> +alpha_cx_frame->sz + 8);
>  if (!side_data) {
>  av_packet_unref(pkt);
>  return AVERROR(ENOMEM);
>  }
>  AV_WB64(side_data, 1);
> -memcpy(side_data + 8, cx_frame->buf_alpha, cx_frame->sz_alpha);
> +memcpy(side_data + 8, alpha_cx_frame->buf, alpha_cx_frame->sz);
>  }
>  if (cx_frame->frame_number != -1) {
>  if (ctx->hdr10_plus_fifo) {
> @@ -1309,40 +1299,37 @@ static int storeframe(AVCodecContext *avctx, struct 
> FrameListData *cx_frame,
>   * @return AVERROR(EINVAL) on output size error
>   * @return AVERROR(ENOMEM) on coded frame queue data allocation error
>   */
> -static int queue_frames(AVCodecContext *avctx, AVPacket *pkt_out)
> +static int queue_frames(AVCodecContext *avctx, struct vpx_codec_ctx *encoder,
> +struct FrameListData **frame_list, AVPacket *pkt_out)
>  {
>  VPxContext *ctx = avctx->priv_data;
>  const struct vpx_codec_cx_pkt *pkt;
> 

Re: [FFmpeg-devel] [PATCH] avfilter/af_alimiter: fix misbehavior when nb_channels != 2

2022-08-23 Thread David Flater
This is a friendly reminder.

Cc: Paul B Mahol 

On 2022-08-14 21:53, David Flater wrote:
> Some code in alimiter assumes that there are 2 channels, resulting in
> clipping if the loudest channel is 3 or above and an out-of-bounds read if
> the input is monophonic.  Fix that in 2 places.
> 
> Signed-off-by: David Flater 
> ---
>  libavfilter/af_alimiter.c | 23 +--
>  1 file changed, 13 insertions(+), 10 deletions(-)
> 
> diff --git a/libavfilter/af_alimiter.c b/libavfilter/af_alimiter.c
> index 622dc66324..c683c4bcf4 100644
> --- a/libavfilter/af_alimiter.c
> +++ b/libavfilter/af_alimiter.c
> @@ -194,10 +194,11 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
> *in)
>  } else {
>  for (i = s->nextiter; i < s->nextiter + s->nextlen; i++) {
>  int j = i % buffer_size;
> -double ppeak, pdelta;
> +double ppeak = 0, pdelta;
>  
> -ppeak = fabs(buffer[nextpos[j]]) > 
> fabs(buffer[nextpos[j] + 1]) ?
> -fabs(buffer[nextpos[j]]) : 
> fabs(buffer[nextpos[j] + 1]);
> +for (c = 0; c < channels; c++) {
> +ppeak = FFMAX(ppeak, fabs(buffer[nextpos[j] + c]));
> +}
>  pdelta = (limit / peak - limit / ppeak) / (((buffer_size 
> - nextpos[j] + s->pos) % buffer_size) / channels);
>  if (pdelta < nextdelta[j]) {
>  nextdelta[j] = pdelta;
> @@ -241,14 +242,16 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
> *in)
>  s->delta = get_rdelta(s, release, inlink->sample_rate,
>peak, limit, s->att, 1);
>  if (s->nextlen > 1) {
> +double ppeak = 0, pdelta;
>  int pnextpos = nextpos[(s->nextiter + 1) % buffer_size];
> -double ppeak = fabs(buffer[pnextpos]) > 
> fabs(buffer[pnextpos + 1]) ?
> -
> fabs(buffer[pnextpos]) :
> -
> fabs(buffer[pnextpos + 1]);
> -double pdelta = (limit / ppeak - s->att) /
> -(((buffer_size + pnextpos -
> -((s->pos + channels) % buffer_size)) %
> -buffer_size) / channels);
> +
> +for (c = 0; c < channels; c++) {
> +ppeak = FFMAX(ppeak, fabs(buffer[pnextpos + c]));
> +}
> +pdelta = (limit / ppeak - s->att) /
> + (((buffer_size + pnextpos -
> + ((s->pos + channels) % buffer_size)) %
> + buffer_size) / channels);
>  if (pdelta < s->delta)
>  s->delta = pdelta;
>  }

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

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


[FFmpeg-devel] [PATCH 1/2] avcodec/libvpxenc: use av_fast_realloc() to resize the stats buffer

2022-08-23 Thread James Almer
Signed-off-by: James Almer 
---
 libavcodec/libvpxenc.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index e08df5fb96..bbbe56c0dc 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -80,6 +80,7 @@ typedef struct VPxEncoderContext {
 struct vpx_image rawimg_alpha;
 uint8_t is_alpha;
 struct vpx_fixed_buf twopass_stats;
+unsigned twopass_stats_size;
 int deadline; //i.e., RT/GOOD/BEST
 uint64_t sse[4];
 int have_sse; /**< true if we have pending sse[] */
@@ -1356,16 +1357,20 @@ static int queue_frames(AVCodecContext *avctx, struct 
vpx_codec_ctx *encoder,
 break;
 case VPX_CODEC_STATS_PKT: {
 struct vpx_fixed_buf *stats = &ctx->twopass_stats;
-int err;
+uint8_t *tmp;
 if (!pkt_out)
 break;
-if ((err = av_reallocp(&stats->buf,
-   stats->sz +
-   pkt->data.twopass_stats.sz)) < 0) {
+tmp = av_fast_realloc(stats->buf,
+  &ctx->twopass_stats_size,
+  stats->sz +
+  pkt->data.twopass_stats.sz);
+if (!tmp) {
+av_freep(&stats->buf);
 stats->sz = 0;
 av_log(avctx, AV_LOG_ERROR, "Stat buffer realloc failed\n");
-return err;
+return AVERROR(ENOMEM);
 }
+stats->buf = tmp;
 memcpy((uint8_t*)stats->buf + stats->sz,
pkt->data.twopass_stats.buf, pkt->data.twopass_stats.sz);
 stats->sz += pkt->data.twopass_stats.sz;
-- 
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] avcodec/libaomenc: use av_fast_realloc() to resize the stats buffer

2022-08-23 Thread James Almer
Signed-off-by: James Almer 
---
 libavcodec/libaomenc.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index 1fd69d59a7..485f554165 100644
--- a/libavcodec/libaomenc.c
+++ b/libavcodec/libaomenc.c
@@ -70,6 +70,7 @@ typedef struct AOMEncoderContext {
 struct aom_codec_ctx encoder;
 struct aom_image rawimg;
 struct aom_fixed_buf twopass_stats;
+unsigned twopass_stats_size;
 struct FrameListData *coded_frame_list;
 int cpu_used;
 int auto_alt_ref;
@@ -1200,14 +1201,17 @@ static int queue_frames(AVCodecContext *avctx, AVPacket 
*pkt_out)
 case AOM_CODEC_STATS_PKT:
 {
 struct aom_fixed_buf *stats = &ctx->twopass_stats;
-int err;
-if ((err = av_reallocp(&stats->buf,
-   stats->sz +
-   pkt->data.twopass_stats.sz)) < 0) {
+uint8_t *tmp = av_fast_realloc(stats->buf,
+   &ctx->twopass_stats_size,
+   stats->sz +
+   pkt->data.twopass_stats.sz);
+if (!tmp) {
+av_freep(&stats->buf);
 stats->sz = 0;
 av_log(avctx, AV_LOG_ERROR, "Stat buffer realloc failed\n");
-return err;
+return AVERROR(ENOMEM);
 }
+stats->buf = tmp;
 memcpy((uint8_t *)stats->buf + stats->sz,
pkt->data.twopass_stats.buf, pkt->data.twopass_stats.sz);
 stats->sz += pkt->data.twopass_stats.sz;
-- 
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".


Re: [FFmpeg-devel] [PATCH v2] avfilter/vf_showinfo: add wallclock option

2022-08-23 Thread Soft Works



> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Michael Riedl
> Sent: Wednesday, August 17, 2022 11:02 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v2] avfilter/vf_showinfo: add
> wallclock option
> 
> On 17.08.2022 10:43, Nicolas George wrote:
> > Michael Riedl (12022-08-17):
> >> Signed-off-by: Michael Riedl 
> >> ---
> >>   libavfilter/vf_showinfo.c | 11 +++
> >>   1 file changed, 11 insertions(+)
> >
> > What is the intended use case? It seems to me very ad-hoc. A
> fftools
> > option to add a timestamp to each log line seems a more generic and
> > cleaner approach.
> 
> This is a good idea, I will look into that. 

There exists a patch that does this and might be useful for you:

https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=4526&state=%2A&archive=both

Best,
softworkz
___
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 01/11] avcodec/tests/avcodec: Mark frame-thrd encoder incompatible with delay

2022-08-23 Thread Andreas Rheinhardt
The API for frame-threaded encoders only works
for one-in-one-out encoders.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/tests/avcodec.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavcodec/tests/avcodec.c b/libavcodec/tests/avcodec.c
index 08b5fbede1..3288a85f64 100644
--- a/libavcodec/tests/avcodec.c
+++ b/libavcodec/tests/avcodec.c
@@ -155,6 +155,9 @@ int main(void){
 if (codec->capabilities & AV_CODEC_CAP_FRAME_THREADS &&
 codec->capabilities & AV_CODEC_CAP_ENCODER_FLUSH)
 ERR("Frame-threaded encoder %s claims to support flushing\n");
+if (codec->capabilities & AV_CODEC_CAP_FRAME_THREADS &&
+codec->capabilities & AV_CODEC_CAP_DELAY)
+ERR("Frame-threaded encoder %s claims to have delay\n");
 } else {
 if ((codec->type == AVMEDIA_TYPE_SUBTITLE) != (codec2->cb_type == 
FF_CODEC_CB_TYPE_DECODE_SUB))
 ERR("Subtitle decoder %s does not implement decode_sub 
callback\n");
-- 
2.34.1

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

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


[FFmpeg-devel] [PATCH 02/11] avcodec/encode: Apply intra_only_flag for receive_packet-API, too

2022-08-23 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/encode.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavcodec/encode.c b/libavcodec/encode.c
index bd66f138a3..9f413095e4 100644
--- a/libavcodec/encode.c
+++ b/libavcodec/encode.c
@@ -240,7 +240,6 @@ static int encode_simple_internal(AVCodecContext *avctx, 
AVPacket *avpkt)
 if (avctx->codec->type == AVMEDIA_TYPE_AUDIO) {
 avpkt->dts = avpkt->pts;
 }
-avpkt->flags |= avci->intra_only_flag;
 }
 
 if (avci->draining && !got_packet)
@@ -301,6 +300,8 @@ static int encode_receive_packet_internal(AVCodecContext 
*avctx, AVPacket *avpkt
 av_assert0(!avpkt->data || avpkt->buf);
 } else
 ret = encode_simple_receive_packet(avctx, avpkt);
+if (ret >= 0)
+avpkt->flags |= avci->intra_only_flag;
 
 if (ret == AVERROR_EOF)
 avci->draining_done = 1;
-- 
2.34.1

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

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


[FFmpeg-devel] [PATCH 03/11] avcodec/aptx: Move AudioFrameQueue to aptxenc.c

2022-08-23 Thread Andreas Rheinhardt
It is only used by the encoder.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/aptx.c|  1 -
 libavcodec/aptx.h|  2 --
 libavcodec/aptxenc.c | 32 
 3 files changed, 24 insertions(+), 11 deletions(-)

diff --git a/libavcodec/aptx.c b/libavcodec/aptx.c
index f2604be60c..8e110acc97 100644
--- a/libavcodec/aptx.c
+++ b/libavcodec/aptx.c
@@ -534,6 +534,5 @@ av_cold int ff_aptx_init(AVCodecContext *avctx)
 }
 }
 
-ff_af_queue_init(avctx, &s->afq);
 return 0;
 }
diff --git a/libavcodec/aptx.h b/libavcodec/aptx.h
index abb49e6faa..da0697e652 100644
--- a/libavcodec/aptx.h
+++ b/libavcodec/aptx.h
@@ -26,7 +26,6 @@
 #include "libavutil/intreadwrite.h"
 #include "avcodec.h"
 #include "mathops.h"
-#include "audio_frame_queue.h"
 
 
 enum channels {
@@ -95,7 +94,6 @@ typedef struct {
 int block_size;
 int32_t sync_idx;
 Channel channels[NB_CHANNELS];
-AudioFrameQueue afq;
 } AptXContext;
 
 typedef const struct {
diff --git a/libavcodec/aptxenc.c b/libavcodec/aptxenc.c
index 453146f154..2a0d8e06eb 100644
--- a/libavcodec/aptxenc.c
+++ b/libavcodec/aptxenc.c
@@ -24,9 +24,15 @@
 
 #include "libavutil/channel_layout.h"
 #include "aptx.h"
+#include "audio_frame_queue.h"
 #include "codec_internal.h"
 #include "encode.h"
 
+typedef struct AptXEncContext {
+AptXContext common;
+AudioFrameQueue afq;
+} AptXEncContext;
+
 /*
  * Half-band QMF analysis filter realized with a polyphase FIR filter.
  * Split into 2 subbands and downsample by 2.
@@ -212,10 +218,11 @@ static void aptx_encode_samples(AptXContext *ctx,
 static int aptx_encode_frame(AVCodecContext *avctx, AVPacket *avpkt,
  const AVFrame *frame, int *got_packet_ptr)
 {
-AptXContext *s = avctx->priv_data;
+AptXEncContext *const s0 = avctx->priv_data;
+AptXContext *const s = &s0->common;
 int pos, ipos, channel, sample, output_size, ret;
 
-if ((ret = ff_af_queue_add(&s->afq, frame)) < 0)
+if ((ret = ff_af_queue_add(&s0->afq, frame)) < 0)
 return ret;
 
 output_size = s->block_size * frame->nb_samples/4;
@@ -232,18 +239,27 @@ static int aptx_encode_frame(AVCodecContext *avctx, 
AVPacket *avpkt,
 aptx_encode_samples(s, samples, avpkt->data + pos);
 }
 
-ff_af_queue_remove(&s->afq, frame->nb_samples, &avpkt->pts, 
&avpkt->duration);
+ff_af_queue_remove(&s0->afq, frame->nb_samples, &avpkt->pts, 
&avpkt->duration);
 *got_packet_ptr = 1;
 return 0;
 }
 
 static av_cold int aptx_close(AVCodecContext *avctx)
 {
-AptXContext *s = avctx->priv_data;
+AptXEncContext *const s = avctx->priv_data;
 ff_af_queue_close(&s->afq);
 return 0;
 }
 
+static av_cold int aptx_encode_init(AVCodecContext *avctx)
+{
+AptXEncContext *const s = avctx->priv_data;
+
+ff_af_queue_init(avctx, &s->afq);
+
+return ff_aptx_init(avctx);
+}
+
 #if CONFIG_APTX_ENCODER
 const FFCodec ff_aptx_encoder = {
 .p.name= "aptx",
@@ -251,8 +267,8 @@ const FFCodec ff_aptx_encoder = {
 .p.type= AVMEDIA_TYPE_AUDIO,
 .p.id  = AV_CODEC_ID_APTX,
 .p.capabilities= AV_CODEC_CAP_DR1 | AV_CODEC_CAP_SMALL_LAST_FRAME,
-.priv_data_size= sizeof(AptXContext),
-.init  = ff_aptx_init,
+.priv_data_size= sizeof(AptXEncContext),
+.init  = aptx_encode_init,
 FF_CODEC_ENCODE_CB(aptx_encode_frame),
 .close = aptx_close,
 #if FF_API_OLD_CHANNEL_LAYOUT
@@ -272,8 +288,8 @@ const FFCodec ff_aptx_hd_encoder = {
 .p.type= AVMEDIA_TYPE_AUDIO,
 .p.id  = AV_CODEC_ID_APTX_HD,
 .p.capabilities= AV_CODEC_CAP_DR1 | AV_CODEC_CAP_SMALL_LAST_FRAME,
-.priv_data_size= sizeof(AptXContext),
-.init  = ff_aptx_init,
+.priv_data_size= sizeof(AptXEncContext),
+.init  = aptx_encode_init,
 FF_CODEC_ENCODE_CB(aptx_encode_frame),
 .close = aptx_close,
 #if FF_API_OLD_CHANNEL_LAYOUT
-- 
2.34.1

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

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


[FFmpeg-devel] [PATCH 04/11] avcodec/encode: Simplify check for frame-threaded encoder

2022-08-23 Thread Andreas Rheinhardt
AVCodecInternal.frame_thread_encoder is only set iff
active_thread_type is FF_THREAD_FRAME.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/encode.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/libavcodec/encode.c b/libavcodec/encode.c
index 9f413095e4..01b59bbf70 100644
--- a/libavcodec/encode.c
+++ b/libavcodec/encode.c
@@ -192,7 +192,7 @@ static int encode_simple_internal(AVCodecContext *avctx, 
AVPacket *avpkt)
 
 if (!frame->buf[0]) {
 if (!(avctx->codec->capabilities & AV_CODEC_CAP_DELAY ||
-  (avci->frame_thread_encoder && avctx->active_thread_type & 
FF_THREAD_FRAME)))
+  avci->frame_thread_encoder))
 return AVERROR_EOF;
 
 // Flushing is signaled with a NULL frame
@@ -203,8 +203,7 @@ static int encode_simple_internal(AVCodecContext *avctx, 
AVPacket *avpkt)
 
 av_assert0(codec->cb_type == FF_CODEC_CB_TYPE_ENCODE);
 
-if (CONFIG_FRAME_THREAD_ENCODER &&
-avci->frame_thread_encoder && (avctx->active_thread_type & 
FF_THREAD_FRAME))
+if (CONFIG_FRAME_THREAD_ENCODER && avci->frame_thread_encoder)
 /* This might modify frame, but it doesn't matter, because
  * the frame properties used below are not used for video
  * (due to the delay inherent in frame threaded encoding, it makes
-- 
2.34.1

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

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


[FFmpeg-devel] [PATCH 05/11] avcodec/frame_thread_encoder: Forward got_packet directly

2022-08-23 Thread Andreas Rheinhardt
Instead of indicating whether we got a packet by setting
pkt->data and pkt->size to zero.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/frame_thread_encoder.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/libavcodec/frame_thread_encoder.c 
b/libavcodec/frame_thread_encoder.c
index 07d310a986..b5765b6343 100644
--- a/libavcodec/frame_thread_encoder.c
+++ b/libavcodec/frame_thread_encoder.c
@@ -45,6 +45,7 @@ typedef struct{
 AVPacket *outdata;
 int   return_code;
 int   finished;
+int   got_packet;
 } Task;
 
 typedef struct{
@@ -110,10 +111,8 @@ static void * attribute_align_arg worker(void *v){
 if (ret >= 0 && ret2 < 0)
 ret = ret2;
 pkt->pts = pkt->dts = frame->pts;
-} else {
-pkt->data = NULL;
-pkt->size = 0;
 }
+task->got_packet = got_packet;
 pthread_mutex_lock(&c->buffer_mutex);
 av_frame_unref(frame);
 pthread_mutex_unlock(&c->buffer_mutex);
@@ -315,8 +314,7 @@ int ff_thread_video_encode_frame(AVCodecContext *avctx, 
AVPacket *pkt,
  * because there is no outstanding task with this index. */
 outtask->finished = 0;
 av_packet_move_ref(pkt, outtask->outdata);
-if(pkt->data)
-*got_packet_ptr = 1;
+*got_packet_ptr = outtask->got_packet;
 c->finished_task_index = (c->finished_task_index + 1) % c->max_tasks;
 
 return outtask->return_code;
-- 
2.34.1

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

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


[FFmpeg-devel] [PATCH 06/11] avcodec/encode, frame_thread_encoder: Unify calling encode callback

2022-08-23 Thread Andreas Rheinhardt
The encode-callback (the callback used by the FF_CODEC_CB_TYPE_ENCODE
encoders) is currently called in two places: encode_simple_internal()
and by the worker threads of frame-threaded encoders.

After the call, some packet properties are set based upon
the corresponding AVFrame properties and the packet is made
refcounted if it isn't already. So there is some code duplication.

There was also non-duplicated code in encode_simple_internal()
which is executed even when using frame-threading. This included
an emms_c() (which is needed for frame-threading, too, if it is
needed for the single-threaded case, because there are allocations
(via av_packet_make_refcounted()) immediately after returning
from the encode-callback).

Furthermore, some further properties are only set in
encode_simple_internal(): For audio, pts and duration are derived
from the corresponding fields of the frame if the encoder does not
have the AV_CODEC_CAP_DELAY set. Yet this is wrong for frame-threaded
encoders, because frame-threading always introduces delay regardless
of whether the underlying codec has said cap. This only worked because
there are no frame-threaded audio encoders.

This commit fixes the code duplication and the above issue by factoring
this code out and reusing it in both places. It would work in case
of audio codecs with frame-threading, because now the values are
derived from the correct AVFrame.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/encode.c   | 86 ---
 libavcodec/encode.h   |  3 ++
 libavcodec/frame_thread_encoder.c | 12 ++---
 3 files changed, 50 insertions(+), 51 deletions(-)

diff --git a/libavcodec/encode.c b/libavcodec/encode.c
index 01b59bbf70..f7b13c8ba1 100644
--- a/libavcodec/encode.c
+++ b/libavcodec/encode.c
@@ -172,6 +172,48 @@ int ff_encode_get_frame(AVCodecContext *avctx, AVFrame 
*frame)
 return 0;
 }
 
+int ff_encode_encode_cb(AVCodecContext *avctx, AVPacket *avpkt,
+const AVFrame *frame, int *got_packet)
+{
+const FFCodec *const codec = ffcodec(avctx->codec);
+int ret;
+
+ret = codec->cb.encode(avctx, avpkt, frame, got_packet);
+emms_c();
+av_assert0(ret <= 0);
+
+if (!ret && *got_packet) {
+if (avpkt->data) {
+ret = av_packet_make_refcounted(avpkt);
+if (ret < 0)
+goto unref;
+// Date returned by encoders must always be ref-counted
+av_assert0(avpkt->buf);
+}
+
+if (avctx->codec->type == AVMEDIA_TYPE_VIDEO &&
+!(avctx->codec->capabilities & AV_CODEC_CAP_DELAY))
+avpkt->pts = avpkt->dts = frame->pts;
+if (frame && !(avctx->codec->capabilities & AV_CODEC_CAP_DELAY)) {
+if (avctx->codec->type == AVMEDIA_TYPE_AUDIO) {
+if (avpkt->pts == AV_NOPTS_VALUE)
+avpkt->pts = frame->pts;
+if (!avpkt->duration)
+avpkt->duration = ff_samples_to_time_base(avctx,
+  
frame->nb_samples);
+}
+}
+if (avctx->codec->type == AVMEDIA_TYPE_AUDIO) {
+avpkt->dts = avpkt->pts;
+}
+} else {
+unref:
+av_packet_unref(avpkt);
+}
+
+return ret;
+}
+
 static int encode_simple_internal(AVCodecContext *avctx, AVPacket *avpkt)
 {
 AVCodecInternal   *avci = avctx->internal;
@@ -204,58 +246,18 @@ static int encode_simple_internal(AVCodecContext *avctx, 
AVPacket *avpkt)
 av_assert0(codec->cb_type == FF_CODEC_CB_TYPE_ENCODE);
 
 if (CONFIG_FRAME_THREAD_ENCODER && avci->frame_thread_encoder)
-/* This might modify frame, but it doesn't matter, because
- * the frame properties used below are not used for video
- * (due to the delay inherent in frame threaded encoding, it makes
- *  no sense to use the properties of the current frame anyway). */
+/* This might unref frame. */
 ret = ff_thread_video_encode_frame(avctx, avpkt, frame, &got_packet);
 else {
-ret = codec->cb.encode(avctx, avpkt, frame, &got_packet);
-if (avctx->codec->type == AVMEDIA_TYPE_VIDEO && !ret && got_packet &&
-!(avctx->codec->capabilities & AV_CODEC_CAP_DELAY))
-avpkt->pts = avpkt->dts = frame->pts;
-}
-
-av_assert0(ret <= 0);
-
-emms_c();
-
-if (!ret && got_packet) {
-if (avpkt->data) {
-ret = av_packet_make_refcounted(avpkt);
-if (ret < 0)
-goto end;
-}
-
-if (frame && !(avctx->codec->capabilities & AV_CODEC_CAP_DELAY)) {
-if (avctx->codec->type == AVMEDIA_TYPE_AUDIO) {
-if (avpkt->pts == AV_NOPTS_VALUE)
-avpkt->pts = frame->pts;
-if (!avpkt->duration)
-avpkt->duration = ff_samples_to_time_base(avctx,
-  

[FFmpeg-devel] [PATCH 08/11] avcodec/(dca|tta|pcm-bluray|pcm-dvd|wavpack)enc: Set pts+dur generically

2022-08-23 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/dcaenc.c| 2 --
 libavcodec/pcm-blurayenc.c | 2 --
 libavcodec/pcm-dvdenc.c| 2 --
 libavcodec/ttaenc.c| 2 --
 libavcodec/wavpackenc.c| 2 --
 5 files changed, 10 deletions(-)

diff --git a/libavcodec/dcaenc.c b/libavcodec/dcaenc.c
index 2481c4d3ec..1ecfbb39e4 100644
--- a/libavcodec/dcaenc.c
+++ b/libavcodec/dcaenc.c
@@ -1215,8 +1215,6 @@ static int encode_frame(AVCodecContext *avctx, AVPacket 
*avpkt,
 flush_put_bits(&c->pb);
 memset(put_bits_ptr(&c->pb), 0, put_bytes_left(&c->pb, 0));
 
-avpkt->pts  = frame->pts;
-avpkt->duration = ff_samples_to_time_base(avctx, frame->nb_samples);
 *got_packet_ptr = 1;
 return 0;
 }
diff --git a/libavcodec/pcm-blurayenc.c b/libavcodec/pcm-blurayenc.c
index 6a5cdb2dcd..4591ba3322 100644
--- a/libavcodec/pcm-blurayenc.c
+++ b/libavcodec/pcm-blurayenc.c
@@ -266,8 +266,6 @@ static int pcm_bluray_encode_frame(AVCodecContext *avctx, 
AVPacket *avpkt,
 return AVERROR_BUG;
 }
 
-avpkt->pts = frame->pts;
-avpkt->duration = ff_samples_to_time_base(avctx, frame->nb_samples);
 *got_packet_ptr = 1;
 
 return 0;
diff --git a/libavcodec/pcm-dvdenc.c b/libavcodec/pcm-dvdenc.c
index a7023d148f..e3104d6e12 100644
--- a/libavcodec/pcm-dvdenc.c
+++ b/libavcodec/pcm-dvdenc.c
@@ -167,8 +167,6 @@ static int pcm_dvd_encode_frame(AVCodecContext *avctx, 
AVPacket *avpkt,
 break;
 }
 
-avpkt->pts  = frame->pts;
-avpkt->duration = ff_samples_to_time_base(avctx, frame->nb_samples);
 *got_packet_ptr = 1;
 
 return 0;
diff --git a/libavcodec/ttaenc.c b/libavcodec/ttaenc.c
index 25113d4a72..9cc86b558e 100644
--- a/libavcodec/ttaenc.c
+++ b/libavcodec/ttaenc.c
@@ -188,9 +188,7 @@ pkt_alloc:
 put_bits32(&pb, av_crc(s->crc_table, UINT32_MAX, avpkt->data, out_bytes) ^ 
UINT32_MAX);
 flush_put_bits(&pb);
 
-avpkt->pts  = frame->pts;
 avpkt->size = out_bytes + 4;
-avpkt->duration = ff_samples_to_time_base(avctx, frame->nb_samples);
 *got_packet_ptr = 1;
 return 0;
 }
diff --git a/libavcodec/wavpackenc.c b/libavcodec/wavpackenc.c
index 7f7ed804ee..d980fdd430 100644
--- a/libavcodec/wavpackenc.c
+++ b/libavcodec/wavpackenc.c
@@ -2905,9 +2905,7 @@ static int wavpack_encode_frame(AVCodecContext *avctx, 
AVPacket *avpkt,
 }
 s->sample_index += frame->nb_samples;
 
-avpkt->pts  = frame->pts;
 avpkt->size = buf - avpkt->data;
-avpkt->duration = ff_samples_to_time_base(avctx, frame->nb_samples);
 *got_packet_ptr = 1;
 return 0;
 }
-- 
2.34.1

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

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


[FFmpeg-devel] [PATCH 10/11] avcodec/encode: Fix outdated comment

2022-08-23 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/encode.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/encode.h b/libavcodec/encode.h
index 10c36435ad..e5d6b754b1 100644
--- a/libavcodec/encode.h
+++ b/libavcodec/encode.h
@@ -57,7 +57,7 @@ int ff_encode_alloc_frame(AVCodecContext *avctx, AVFrame 
*frame);
 /**
  * Check AVPacket size and allocate data.
  *
- * Encoders supporting FFCodec.encode2() can use this as a convenience to
+ * Encoders of type FF_CODEC_CB_TYPE_ENCODE can use this as a convenience to
  * obtain a big enough buffer for the encoded bitstream.
  *
  * @param avctx   the AVCodecContext of the encoder
-- 
2.34.1

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

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


[FFmpeg-devel] [PATCH 09/11] avcodec: Make ff_alloc_packet() based encoders accept user buffers

2022-08-23 Thread Andreas Rheinhardt
Up until now, these encoders received non-refcounted packets
(whose data was owned by the corresponding AVCodecContext)
from ff_alloc_packet(); these packets were made refcounted lateron
by av_packet_make_refcounted() generically.
This commit makes these encoders accept user-supplied buffers by
replacing av_packet_make_refcounted() with an equivalent function
that is based upon get_encode_buffer().

(I am pretty certain that one can also set the flag for mpegvideo-
based encoders, but I want to double-check this later. What is certain
is that it reallocates the buffer owned by the AVCodecContext
which should maybe be moved to encode.c, so that proresenc_kostya.c
and ttaenc.c can make use of it, too.)

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/aacenc.c |  3 ++-
 libavcodec/alacenc.c|  2 +-
 libavcodec/aliaspixenc.c|  1 +
 libavcodec/asvenc.c |  2 ++
 libavcodec/cfhdenc.c|  2 +-
 libavcodec/cinepakenc.c |  1 +
 libavcodec/encode.c | 19 ++-
 libavcodec/ffv1enc.c|  3 ++-
 libavcodec/flashsv2enc.c|  1 +
 libavcodec/flashsvenc.c |  1 +
 libavcodec/gif.c|  1 +
 libavcodec/hapenc.c |  2 +-
 libavcodec/huffyuvenc.c |  4 ++--
 libavcodec/j2kenc.c |  1 +
 libavcodec/lclenc.c |  2 +-
 libavcodec/libfdk-aacenc.c  |  3 ++-
 libavcodec/libilbc.c|  1 +
 libavcodec/libopencore-amr.c|  3 ++-
 libavcodec/libopusenc.c |  3 ++-
 libavcodec/libspeexenc.c|  2 +-
 libavcodec/libtwolame.c |  2 +-
 libavcodec/libvo-amrwbenc.c |  1 +
 libavcodec/libxvid.c|  1 +
 libavcodec/ljpegenc.c   |  2 +-
 libavcodec/magicyuvenc.c|  2 +-
 libavcodec/mlpenc.c |  7 +--
 libavcodec/mpegaudioenc_fixed.c |  1 +
 libavcodec/mpegaudioenc_float.c |  1 +
 libavcodec/opusenc.c|  3 ++-
 libavcodec/pcxenc.c |  1 +
 libavcodec/pngenc.c |  2 +-
 libavcodec/proresenc_anatoliy.c |  4 ++--
 libavcodec/qoienc.c |  2 +-
 libavcodec/qtrleenc.c   |  1 +
 libavcodec/roqvideoenc.c|  1 +
 libavcodec/rpzaenc.c|  1 +
 libavcodec/sgienc.c |  1 +
 libavcodec/smcenc.c |  1 +
 libavcodec/snowenc.c|  1 +
 libavcodec/sonic.c  |  4 ++--
 libavcodec/sunrastenc.c |  1 +
 libavcodec/svq1enc.c|  1 +
 libavcodec/targaenc.c   |  1 +
 libavcodec/tiffenc.c|  2 +-
 libavcodec/ttaenc.c |  2 +-
 libavcodec/utvideoenc.c |  2 +-
 libavcodec/vorbisenc.c  |  3 ++-
 libavcodec/wavpackenc.c |  2 +-
 libavcodec/wmaenc.c |  2 ++
 libavcodec/xbmenc.c |  1 +
 50 files changed, 83 insertions(+), 30 deletions(-)

diff --git a/libavcodec/aacenc.c b/libavcodec/aacenc.c
index 4f51485fc4..a0e5d2942e 100644
--- a/libavcodec/aacenc.c
+++ b/libavcodec/aacenc.c
@@ -1417,6 +1417,8 @@ const FFCodec ff_aac_encoder = {
 .p.long_name= NULL_IF_CONFIG_SMALL("AAC (Advanced Audio Coding)"),
 .p.type = AVMEDIA_TYPE_AUDIO,
 .p.id   = AV_CODEC_ID_AAC,
+.p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY |
+  AV_CODEC_CAP_SMALL_LAST_FRAME,
 .priv_data_size = sizeof(AACEncContext),
 .init   = aac_encode_init,
 FF_CODEC_ENCODE_CB(aac_encode_frame),
@@ -1424,7 +1426,6 @@ const FFCodec ff_aac_encoder = {
 .defaults   = aac_encode_defaults,
 .p.supported_samplerates = ff_mpeg4audio_sample_rates,
 .caps_internal  = FF_CODEC_CAP_INIT_CLEANUP,
-.p.capabilities = AV_CODEC_CAP_SMALL_LAST_FRAME | AV_CODEC_CAP_DELAY,
 .p.sample_fmts  = (const enum AVSampleFormat[]){ AV_SAMPLE_FMT_FLTP,
  AV_SAMPLE_FMT_NONE },
 .p.priv_class   = &aacenc_class,
diff --git a/libavcodec/alacenc.c b/libavcodec/alacenc.c
index 10dab0a67c..20711d242f 100644
--- a/libavcodec/alacenc.c
+++ b/libavcodec/alacenc.c
@@ -654,12 +654,12 @@ const FFCodec ff_alac_encoder = {
 .p.long_name= NULL_IF_CONFIG_SMALL("ALAC (Apple Lossless Audio 
Codec)"),
 .p.type = AVMEDIA_TYPE_AUDIO,
 .p.id   = AV_CODEC_ID_ALAC,
+.p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_SMALL_LAST_FRAME,
 .priv_data_size = sizeof(AlacEncodeContext),
 .p.priv_class   = &alacenc_class,
 .init   = alac_encode_init,
 FF_CODEC_ENCODE_CB(alac_encode_frame),
 .close  = alac_encode_close,
-.p.capabilities = AV_CODEC_CAP_SMALL_LAST_FRAME,
 #if FF_API_OLD_CHANNEL_LAYOUT
 .p.channel_layouts = alac_channel_layouts,
 #endif
diff --git a/libavcodec/aliaspixenc.c b/libavcodec/aliaspixenc.c
index 9c43cfa9e7..ec1cba9a57 100644
--- a/libavcodec/aliaspixenc.c
+++ b/libavcodec/aliaspixenc.c
@@ -106,6 +106,7 @@ const FFCodec ff_alias_pix_encoder = {
 .p.long_name = NULL_IF_CONFIG_

[FFmpeg-devel] [PATCH 11/11] avcodec/internal: Fix outdated comment

2022-08-23 Thread Andreas Rheinhardt
The legacy API is long gone.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/internal.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index 52e7f111c1..61d395e8c9 100644
--- a/libavcodec/internal.h
+++ b/libavcodec/internal.h
@@ -137,7 +137,8 @@ typedef struct AVCodecInternal {
 int draining;
 
 /**
- * buffers for using new encode/decode API through legacy API
+ * Temporary buffers to hold newly received packets and newly decoded 
frames
+ * for decoding or newly received frames and newly encoded packets for 
encoding.
  */
 AVPacket *buffer_pkt;
 AVFrame *buffer_frame;
-- 
2.34.1

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

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


[FFmpeg-devel] [PATCH 07/11] avcodec/encode: Remove redundant check

2022-08-23 Thread Andreas Rheinhardt
frame is always set at this point for no-delay encoders.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/encode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/encode.c b/libavcodec/encode.c
index f7b13c8ba1..f66e2f9ba8 100644
--- a/libavcodec/encode.c
+++ b/libavcodec/encode.c
@@ -194,7 +194,7 @@ int ff_encode_encode_cb(AVCodecContext *avctx, AVPacket 
*avpkt,
 if (avctx->codec->type == AVMEDIA_TYPE_VIDEO &&
 !(avctx->codec->capabilities & AV_CODEC_CAP_DELAY))
 avpkt->pts = avpkt->dts = frame->pts;
-if (frame && !(avctx->codec->capabilities & AV_CODEC_CAP_DELAY)) {
+if (!(avctx->codec->capabilities & AV_CODEC_CAP_DELAY)) {
 if (avctx->codec->type == AVMEDIA_TYPE_AUDIO) {
 if (avpkt->pts == AV_NOPTS_VALUE)
 avpkt->pts = frame->pts;
-- 
2.34.1

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

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


Re: [FFmpeg-devel] [PATCH v2] avfilter/vf_showinfo: add wallclock option

2022-08-23 Thread Soft Works



> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Nicolas George
> Sent: Wednesday, August 17, 2022 11:28 AM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v2] avfilter/vf_showinfo: add
> wallclock option
> 
> Andreas Rheinhardt (12022-08-17):
> > Basically already exists:
> > https://ffmpeg.org/pipermail/ffmpeg-devel/2021-August/283434.html
> 
> Lacks subsecond precision and timezone information, but a good start.
> 
> Regards,
> 
> --
>   Nicolas George

It does provide subsecond precision, please see the 'millisec' variable
here:

https://patchwork.ffmpeg.org/project/ffmpeg/patch/mn2pr04mb5981773a7336c9b46d298354ba...@mn2pr04mb5981.namprd04.prod.outlook.com/

Adding the ability to print time zone information is a good idea, I think.

The patchset allows to control whether to print date, time or both.
In practical use, I ended up printing a line with the date on startup
and print only time information, e.g. like this:

01:40:42.467 ffmpeg version 5.1...
01:40:42.467   built with ...
01:40:42.468 Execution Date: 2022-08-16 01:40:42
01:40:42.499 Input #0, matroska,webm, ...



If there is interest, I can submit my latest version of this.

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

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


Re: [FFmpeg-devel] [PATCH] avformat/wavdec: fix the ID3 metadata obtained in WAV format's missing

2022-08-23 Thread Steven Liu
Steven Liu  于2022年8月23日周二 09:59写道:
>
> Wujian(Chin)  于2022年8月22日周一 22:00写道:
> >
> > Fixes ticket #9848.
> >
> > Signed-off-by: wujian_nanjing 
> > ---
> >  libavformat/wavdec.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c
> > index ca61b84..e3f790f 100644
> > --- a/libavformat/wavdec.c
> > +++ b/libavformat/wavdec.c
> > @@ -555,7 +555,7 @@ static int wav_read_header(AVFormatContext *s)
> >  case MKTAG('I', 'D', '3', ' '):
> >  case MKTAG('i', 'd', '3', ' '): {
> >  ID3v2ExtraMeta *id3v2_extra_meta;
> > -ff_id3v2_read_dict(pb, &ffformatcontext(s)->id3v2_meta, 
> > ID3v2_DEFAULT_MAGIC, &id3v2_extra_meta);
> > +ff_id3v2_read(s, ID3v2_DEFAULT_MAGIC, &id3v2_extra_meta, 0);
> >  if (id3v2_extra_meta) {
> >  ff_id3v2_parse_apic(s, id3v2_extra_meta);
> >  ff_id3v2_parse_chapters(s, id3v2_extra_meta);
> > --
> > 2.7.4
> >
> > ___
> > 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".
>
> Tested ok to me, will push this patch after 24 hours if there have no
> objections.

Pushed.


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

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


Re: [FFmpeg-devel] [PATCH v3] libavcodec/cbs_av1: Add size check before parse obu

2022-08-23 Thread Chen, Wenbin
> cbs_av1_write_unit() check pbc size after parsing obu frame, and return
> AVERROR(ENOSPC) if pbc is small. pbc will be reallocated and this obu
> frame will be parsed again, but this may cause error because
> CodedBitstreamAV1Context has already been updated, for example
> ref_order_hint is updated and will not match the same obu frame. Now size
> check is added before parsing obu frame to avoid this error.
> 
> Signed-off-by: Wenbin Chen 
> ---
>  libavcodec/cbs_av1.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/libavcodec/cbs_av1.c b/libavcodec/cbs_av1.c
> index 154d9156cf..9c51a8c7c8 100644
> --- a/libavcodec/cbs_av1.c
> +++ b/libavcodec/cbs_av1.c
> @@ -1075,6 +1075,9 @@ static int
> cbs_av1_write_obu(CodedBitstreamContext *ctx,
>  put_bits32(pbc, 0);
>  }
> 
> +if (8 * (unit->data_size + obu->obu_size) > put_bits_left(pbc))
> +return AVERROR(ENOSPC);
> +
>  td = NULL;
>  start_pos = put_bits_count(pbc);
> 
> --
> 2.32.0

Ping

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