Re: [FFmpeg-devel] [PATCH] Extract av_hls_codec_attr

2023-11-02 Thread Zhao Zhili 

> 在 2023年11月3日，下午1:21，Romain Beauxis  写道：
> 
> Le mar. 31 oct. 2023 à 11:47, Zhao Zhili  a écrit :
>> 
>> 
>>> From: ffmpeg-devel  On Behalf Of Romain 
>>> Beauxis
>>> Sent: 2023年10月30日 9:06
>>> To: ffmpeg-devel@ffmpeg.org
>>> Cc: Romain Beauxis 
>>> Subject: [FFmpeg-devel] [PATCH] Extract av_hls_codec_attr
>>> 
>>> The logic for extracting HLS codec attribute strings is very useful and
>>> can be re-used in many different situations when working with HLS
>>> streams using libavcodec/libavformat.
>>> 
>>> This patch extracts the function's code and places it into a publicly
>>> available function.
>> 
>> I don't think the implementation is complete enough to be exported as
>> an API. And the ad-hoc API needs some design too.
> 
> I am not in a position to dispute this assessment but I would say it
> could be a "build it and they will come" kind of situation (or chicken
> and egg too).

Maybe it’s fine for internal implementation, but dangerous for API.

> 
>>> 
>>> ---
>>> libavcodec/Makefile  |   2 +
>>> libavcodec/hls.c | 105 +++
>>> libavcodec/hls.h |  42 +
>>> libavformat/hlsenc.c |  83 +++---
>>> 4 files changed, 155 insertions(+), 77 deletions(-)
>>> create mode 100644 libavcodec/hls.c
>>> create mode 100644 libavcodec/hls.h
>>> 
>> 
>> 
>> ___
>> 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-dev

___
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] Extract av_hls_codec_attr

2023-11-02 Thread Romain Beauxis 
Le mar. 31 oct. 2023 à 11:47, Zhao Zhili  a écrit :
>
>
> > From: ffmpeg-devel  On Behalf Of Romain 
> > Beauxis
> > Sent: 2023年10月30日 9:06
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Romain Beauxis 
> > Subject: [FFmpeg-devel] [PATCH] Extract av_hls_codec_attr
> >
> > The logic for extracting HLS codec attribute strings is very useful and
> > can be re-used in many different situations when working with HLS
> > streams using libavcodec/libavformat.
> >
> > This patch extracts the function's code and places it into a publicly
> > available function.
>
> I don't think the implementation is complete enough to be exported as
> an API. And the ad-hoc API needs some design too.

I am not in a position to dispute this assessment but I would say it
could be a "build it and they will come" kind of situation (or chicken
and egg too).

> >
> > ---
> >  libavcodec/Makefile  |   2 +
> >  libavcodec/hls.c | 105 +++
> >  libavcodec/hls.h |  42 +
> >  libavformat/hlsenc.c |  83 +++---
> >  4 files changed, 155 insertions(+), 77 deletions(-)
> >  create mode 100644 libavcodec/hls.c
> >  create mode 100644 libavcodec/hls.h
> >
>
>
> ___
> 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] Extract av_hls_codec_attr

2023-11-02 Thread Romain Beauxis 
Le mar. 31 oct. 2023 à 08:28, Michael Niedermayer
 a écrit :
>
> On Sun, Oct 29, 2023 at 08:05:50PM -0500, Romain Beauxis wrote:
> > The logic for extracting HLS codec attribute strings is very useful and
> > can be re-used in many different situations when working with HLS
> > streams using libavcodec/libavformat.
> >
> > This patch extracts the function's code and places it into a publicly
> > available function.
> >
> > ---
> >  libavcodec/Makefile  |   2 +
> >  libavcodec/hls.c | 105 +++
> >  libavcodec/hls.h |  42 +
> >  libavformat/hlsenc.c |  83 +++---
>
> you cannot call ff_* functions across libs
>
> they need to start with av* / avpriv*

Thanks for the review! Updated patch submitted.

> [...]
> > +  rbsp_buf = ff_nal_unit_extract_rbsp(data, remain_size, 
> > _size, 0);
>
> libavcodec/libavcodec.so: undefined reference to `ff_nal_unit_extract_rbsp'
> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> Makefile:133: recipe for target 'ffmpeg_g' failed
> make: *** [ffmpeg_g] Error 1
> make: *** Waiting for unfinished jobs
> libavcodec/libavcodec.so: undefined reference to `ff_nal_unit_extract_rbsp'
> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> Makefile:133: recipe for target 'ffplay_g' failed
> make: *** [ffplay_g] Error 1
>
> 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.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH v2] Extract av_hls_codec_attr

2023-11-02 Thread Romain Beauxis 
The logic for extracting HLS codec attribute strings is very useful and
can be re-used in many different situations when working with HLS
streams using libavcodec/libavformat.

This patch extracts the function's code and places it into a publicly
available function.

Differences since v1:
- ff_nal_unit_extract_rbsp renamed into avpriv_nal_unit_extract_rbsp to
  follow the appropriate library cross-linking convention.

---
 libavcodec/Makefile  |   2 +
 libavcodec/hls.c | 105 +++
 libavcodec/hls.h |  42 +
 libavformat/avc.c|   4 +-
 libavformat/avc.h|   2 +-
 libavformat/hevc.c   |   2 +-
 libavformat/hlsenc.c |  83 +++---
 7 files changed, 159 insertions(+), 81 deletions(-)
 create mode 100644 libavcodec/hls.c
 create mode 100644 libavcodec/hls.h

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 580a8d6b54..b3b2b18980 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -16,6 +16,7 @@ HEADERS = ac3_parser.h
  \
   dirac.h   \
   dv_profile.h  \
   dxva2.h   \
+  hls.h \
   jni.h \
   mediacodec.h  \
   packet.h  \
@@ -47,6 +48,7 @@ OBJS = ac3_parser.o   
  \
get_buffer.o \
imgconvert.o \
jni.o\
+   hls.o\
mathtables.o \
mediacodec.o \
mpeg12framerate.o\
diff --git a/libavcodec/hls.c b/libavcodec/hls.c
new file mode 100644
index 00..05a6277dbc
--- /dev/null
+++ b/libavcodec/hls.c
@@ -0,0 +1,105 @@
+/*
+ * HLS public API
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "hls.h"
+#include "libavutil/intreadwrite.h"
+#include "libavformat/avc.h"
+
+int av_hls_codec_attr(AVStream *st, char *attr, size_t attr_len) {
+  if (st->codecpar->codec_id == AV_CODEC_ID_H264) {
+  uint8_t *data = st->codecpar->extradata;
+  if (data) {
+  const uint8_t *p;
+
+  if (AV_RB32(data) == 0x01 && (data[4] & 0x1F) == 7)
+  p = [5];
+  else if (AV_RB24(data) == 0x01 && (data[3] & 0x1F) == 7)
+  p = [4];
+  else if (data[0] == 0x01)  /* avcC */
+  p = [1];
+  else
+  return AVERROR_INVALIDDATA;
+  snprintf(attr, attr_len,
+   "avc1.%02x%02x%02x", p[0], p[1], p[2]);
+  } else {
+  return AVERROR_INVALIDDATA;
+  }
+  } else if (st->codecpar->codec_id == AV_CODEC_ID_HEVC) {
+  uint8_t *data = st->codecpar->extradata;
+  int profile = AV_PROFILE_UNKNOWN;
+  int level = AV_LEVEL_UNKNOWN;
+
+  if (st->codecpar->profile != AV_PROFILE_UNKNOWN)
+  profile = st->codecpar->profile;
+  if (st->codecpar->level != AV_LEVEL_UNKNOWN)
+  level = st->codecpar->level;
+
+  /* check the boundary of data which from current position is small than 
extradata_size */
+  while (data && (data - st->codecpar->extradata + 19) < 
st->codecpar->extradata_size) {
+  /* get HEVC SPS NAL and seek to profile_tier_level */
+  if (!(data[0] | data[1] | data[2]) && data[3] == 1 && ((data[4] & 
0x7E) == 0x42)) {
+  uint8_t *rbsp_buf;
+  int remain_size = 0;
+  int rbsp_size = 0;
+  /* skip start code + nalu header */
+  data += 6;
+  /* process by reference General NAL unit syntax */
+  remain_size =

[FFmpeg-devel] [PATCH] avformat/hlsenc: Only append postfix to fmp4 init filename if not in the subdir

2023-11-02 Thread Dave Johansen 
---
 libavformat/hlsenc.c | 26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 4ef84c05c1..dd1a461cce 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1931,6 +1931,30 @@ fail:
 return ret;
 }
 
+static int validate_subdir(const char *fn)
+{
+const char *subdir_name;
+char *fn_dup = NULL;
+int ret = 0;
+
+if (!fn)
+return AVERROR(EINVAL);
+
+fn_dup = av_strdup(fn);
+if (!fn_dup)
+return AVERROR(ENOMEM);
+subdir_name = av_dirname(fn_dup);
+
+if (!av_stristr(subdir_name, "%v")) {
+ret = AVERROR(EINVAL);
+goto fail;
+}
+
+fail:
+av_freep(_dup);
+return ret;
+}
+
 static int format_name(const char *buf, char **s, int index, const char 
*varname)
 {
 const char *proto, *dir;
@@ -3019,7 +3043,7 @@ static int hls_init(AVFormatContext *s)
 av_freep(>fmp4_init_filename);
 ret = format_name(hls->fmp4_init_filename,
   >fmp4_init_filename, i, 
vs->varname);
-} else {
+} else if (validate_subdir(s->url) < 0) {
 ret = append_postfix(vs->fmp4_init_filename, 
fmp4_init_filename_len, i);
 }
 if (ret < 0)
-- 
2.39.2 (Apple Git-143)

___
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 4/4] avformat/lafdec: Check for 0 parameters

2023-11-02 Thread Sean McGovern 
On Thu, Nov 2, 2023, 19:50 Michael Niedermayer 
wrote:

> Fixes: Timeout
> Fixes:
> 63661/clusterfuzz-testcase-minimized-ffmpeg_dem_LAF_fuzzer-6615365234589696
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by
> :
> Michael Niedermayer 
> ---
>  libavformat/lafdec.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/lafdec.c b/libavformat/lafdec.c
> index 59a59dcfe9c..b867f106aee 100644
> --- a/libavformat/lafdec.c
> +++ b/libavformat/lafdec.c
> @@ -139,7 +139,9 @@ static int laf_read_header(AVFormatContext *ctx)
>  s->index = 0;
>  s->stored_index = 0;
>  s->bpp = bpp;
> -if ((int64_t)bpp * st_count * (int64_t)sample_rate >= INT32_MAX)
> +if ((int64_t)bpp * st_count * (int64_t)sample_rate >= INT32_MAX ||
> +(int64_t)bpp * st_count * (int64_t)sample_rate == 0
> +)
>  return AVERROR_INVALIDDATA;
>  s->data = av_calloc(st_count * sample_rate, bpp);
>  if (!s->data)
> --
> 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".
>

This looks OK to me.

-- Sean McGovern

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

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

Re: [FFmpeg-devel] [PATCH 3/4] avcodec/flicvideo: consider width in copy loops

2023-11-02 Thread Sean McGovern 
On Thu, Nov 2, 2023, 19:50 Michael Niedermayer 
wrote:

> Fixes: out of array write
> Fixes:
> 63520/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FLIC_fuzzer-4876198087622656
> Regression since: c7f8d42c12582b0626ea38117df6c9aea9fcf5b1 (was not posted
> to ffmpeg-devel)
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by
> :
> Michael Niedermayer 
> ---
>  libavcodec/flicvideo.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/flicvideo.c b/libavcodec/flicvideo.c
> index 6ce033ba409..43f3f83bf65 100644
> --- a/libavcodec/flicvideo.c
> +++ b/libavcodec/flicvideo.c
> @@ -642,7 +642,7 @@ static int flic_decode_frame_8BPP(AVCodecContext
> *avctx,
> "has incorrect size, skipping chunk\n", chunk_size
> - 6);
>  bytestream2_skip(, chunk_size - 6);
>  } else {
> -for (y_ptr = 0; check_pixel_ptr(y_ptr, 0, pixel_limit,
> direction) == 0;
> +for (y_ptr = 0; check_pixel_ptr(y_ptr, s->avctx->width,
> pixel_limit, direction) == 0;
>   y_ptr += s->frame->linesize[0]) {
>  bytestream2_get_buffer(, [y_ptr],
> s->avctx->width);
> @@ -949,7 +949,7 @@ static int flic_decode_frame_15_16BPP(AVCodecContext
> *avctx,
>
>  if (bytestream2_get_bytes_left() < 2 * s->avctx->width
> * s->avctx->height )
>  return AVERROR_INVALIDDATA;
> -for (y_ptr = 0; check_pixel_ptr(y_ptr, 0, pixel_limit,
> direction) == 0;
> +for (y_ptr = 0; check_pixel_ptr(y_ptr, 2*s->avctx->width,
> pixel_limit, direction) == 0;
>   y_ptr += s->frame->linesize[0]) {
>
>  pixel_countdown = s->avctx->width;
> @@ -1235,7 +1235,7 @@ static int flic_decode_frame_24BPP(AVCodecContext
> *avctx,
> "bigger than image, skipping chunk\n", chunk_size
> - 6);
>  bytestream2_skip(, chunk_size - 6);
>  } else {
> -for (y_ptr = 0; check_pixel_ptr(y_ptr, 0, pixel_limit,
> direction) == 0;
> +for (y_ptr = 0; check_pixel_ptr(y_ptr, 3*s->avctx->width,
> pixel_limit, direction) == 0;
>   y_ptr += s->frame->linesize[0]) {
>
>  bytestream2_get_buffer(, pixels + y_ptr,
> 3*s->avctx->width);
> --
> 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".
>

On quick inspection this looks OK,  but is s->avctx->width guaranteed to be
non-zero as well?

-- Sean McGovern

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

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

Re: [FFmpeg-devel] [PATCH 2/4] avfilter/buffersink: cuddle () closer around =

2023-11-02 Thread Sean McGovern 
On Thu, Nov 2, 2023, 19:50 Michael Niedermayer 
wrote:

> Signed-off-by: Michael Niedermayer 
> ---
>  libavfilter/buffersink.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavfilter/buffersink.c b/libavfilter/buffersink.c
> index 9426ded7ee3..ca2af1bc077 100644
> --- a/libavfilter/buffersink.c
> +++ b/libavfilter/buffersink.c
> @@ -293,7 +293,7 @@ static int asink_query_formats(AVFilterContext *ctx)
>  cleanup_redundant_layouts(ctx);
>  for (i = 0; i < NB_ITEMS(buf->channel_layouts); i++)
>  if ((ret = av_channel_layout_from_mask(,
> buf->channel_layouts[i])) < 0 ||
> -(ret = ff_add_channel_layout(, ) < 0))
> +(ret = ff_add_channel_layout(, )) < 0)
>  return ret;
>  for (i = 0; i < NB_ITEMS(buf->channel_counts); i++) {
>  layout = FF_COUNT2LAYOUT(buf->channel_counts[i]);
> --
> 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".
>

This and 1/2 seem a bit frivolous, but providing they don't violate the
project style guide, LGTM.

-- Sean McGovern

>
___
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 4/4] avformat/lafdec: Check for 0 parameters

2023-11-02 Thread Michael Niedermayer 
Fixes: Timeout
Fixes: 
63661/clusterfuzz-testcase-minimized-ffmpeg_dem_LAF_fuzzer-6615365234589696

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavformat/lafdec.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavformat/lafdec.c b/libavformat/lafdec.c
index 59a59dcfe9c..b867f106aee 100644
--- a/libavformat/lafdec.c
+++ b/libavformat/lafdec.c
@@ -139,7 +139,9 @@ static int laf_read_header(AVFormatContext *ctx)
 s->index = 0;
 s->stored_index = 0;
 s->bpp = bpp;
-if ((int64_t)bpp * st_count * (int64_t)sample_rate >= INT32_MAX)
+if ((int64_t)bpp * st_count * (int64_t)sample_rate >= INT32_MAX ||
+(int64_t)bpp * st_count * (int64_t)sample_rate == 0
+)
 return AVERROR_INVALIDDATA;
 s->data = av_calloc(st_count * sample_rate, bpp);
 if (!s->data)
-- 
2.17.1

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

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

[FFmpeg-devel] [PATCH 3/4] avcodec/flicvideo: consider width in copy loops

2023-11-02 Thread Michael Niedermayer 
Fixes: out of array write
Fixes: 
63520/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FLIC_fuzzer-4876198087622656
Regression since: c7f8d42c12582b0626ea38117df6c9aea9fcf5b1 (was not posted to 
ffmpeg-devel)

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/flicvideo.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavcodec/flicvideo.c b/libavcodec/flicvideo.c
index 6ce033ba409..43f3f83bf65 100644
--- a/libavcodec/flicvideo.c
+++ b/libavcodec/flicvideo.c
@@ -642,7 +642,7 @@ static int flic_decode_frame_8BPP(AVCodecContext *avctx,
"has incorrect size, skipping chunk\n", chunk_size - 6);
 bytestream2_skip(, chunk_size - 6);
 } else {
-for (y_ptr = 0; check_pixel_ptr(y_ptr, 0, pixel_limit, 
direction) == 0;
+for (y_ptr = 0; check_pixel_ptr(y_ptr, s->avctx->width, 
pixel_limit, direction) == 0;
  y_ptr += s->frame->linesize[0]) {
 bytestream2_get_buffer(, [y_ptr],
s->avctx->width);
@@ -949,7 +949,7 @@ static int flic_decode_frame_15_16BPP(AVCodecContext *avctx,
 
 if (bytestream2_get_bytes_left() < 2 * s->avctx->width * 
s->avctx->height )
 return AVERROR_INVALIDDATA;
-for (y_ptr = 0; check_pixel_ptr(y_ptr, 0, pixel_limit, 
direction) == 0;
+for (y_ptr = 0; check_pixel_ptr(y_ptr, 2*s->avctx->width, 
pixel_limit, direction) == 0;
  y_ptr += s->frame->linesize[0]) {
 
 pixel_countdown = s->avctx->width;
@@ -1235,7 +1235,7 @@ static int flic_decode_frame_24BPP(AVCodecContext *avctx,
"bigger than image, skipping chunk\n", chunk_size - 6);
 bytestream2_skip(, chunk_size - 6);
 } else {
-for (y_ptr = 0; check_pixel_ptr(y_ptr, 0, pixel_limit, 
direction) == 0;
+for (y_ptr = 0; check_pixel_ptr(y_ptr, 3*s->avctx->width, 
pixel_limit, direction) == 0;
  y_ptr += s->frame->linesize[0]) {
 
 bytestream2_get_buffer(, pixels + y_ptr, 
3*s->avctx->width);
-- 
2.17.1

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

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

[FFmpeg-devel] [PATCH 2/4] avfilter/buffersink: cuddle () closer around =

2023-11-02 Thread Michael Niedermayer 
Signed-off-by: Michael Niedermayer 
---
 libavfilter/buffersink.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/buffersink.c b/libavfilter/buffersink.c
index 9426ded7ee3..ca2af1bc077 100644
--- a/libavfilter/buffersink.c
+++ b/libavfilter/buffersink.c
@@ -293,7 +293,7 @@ static int asink_query_formats(AVFilterContext *ctx)
 cleanup_redundant_layouts(ctx);
 for (i = 0; i < NB_ITEMS(buf->channel_layouts); i++)
 if ((ret = av_channel_layout_from_mask(, 
buf->channel_layouts[i])) < 0 ||
-(ret = ff_add_channel_layout(, ) < 0))
+(ret = ff_add_channel_layout(, )) < 0)
 return ret;
 for (i = 0; i < NB_ITEMS(buf->channel_counts); i++) {
 layout = FF_COUNT2LAYOUT(buf->channel_counts[i]);
-- 
2.17.1

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

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

[FFmpeg-devel] [PATCH 1/4] avfilter/framesync: cuddle () closer around =

2023-11-02 Thread Michael Niedermayer 
Signed-off-by: Michael Niedermayer 
---
 libavfilter/framesync.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/framesync.c b/libavfilter/framesync.c
index c748262ba6a..6cb4b21fed8 100644
--- a/libavfilter/framesync.c
+++ b/libavfilter/framesync.c
@@ -288,7 +288,7 @@ int ff_framesync_get_frame(FFFrameSync *fs, unsigned in, 
AVFrame **rframe,
 if (need_copy) {
 if (!(frame = av_frame_clone(frame)))
 return AVERROR(ENOMEM);
-if ((ret = ff_inlink_make_frame_writable(fs->parent->inputs[in], 
) < 0)) {
+if ((ret = ff_inlink_make_frame_writable(fs->parent->inputs[in], 
)) < 0) {
 av_frame_free();
 return ret;
 }
-- 
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 v3 6/8] avfilter/vf_scale: simplify color matrix parsing logic

2023-11-02 Thread Michael Niedermayer 
On Tue, Oct 31, 2023 at 03:54:48PM +0100, Niklas Haas wrote:
> From: Niklas Haas 
> 
> No need to write a custom string parser when we can just use an integer
> option with preset values. The various bits of fallback logic are wholly
> redundant with equivalent logic already inside sws_getCoefficients.
> 
> Note: I disallowed setting 'out_color_matrix=auto', because this does
> not do anything meaningful in the current code (just hard-codes
> AVCOL_SPC_BT470BG fallback).
> ---
>  libavfilter/vf_scale.c | 66 ++
>  1 file changed, 22 insertions(+), 44 deletions(-)

probably ok

thx

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

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras


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 v3 2/8] swscale: don't omit ff_sws_init_range_convert for high-bit

2023-11-02 Thread Michael Niedermayer 
On Tue, Oct 31, 2023 at 03:54:44PM +0100, Niklas Haas wrote:
> From: Niklas Haas 
> 
> This was a complete hack seemingly designed to work around a different
> bug, which was fixed in the previous commit. As such, there is no more
> reason not to do this, as it simply breaks changing color range in
> sws_setColorspaceDetails for no reason.
> ---
>  libswscale/utils.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)

less hack LGTM

thx

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

No snowflake in an avalanche ever feels responsible. -- Voltaire


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] lavc/opusdsp: rewrite R-V V postfilter

2023-11-02 Thread Rémi Denis-Courmont 
Le torstaina 2. marraskuuta 2023, 23.07.03 EET Rémi Denis-Courmont a écrit :
> This uses a more traditional approach allowing up processing of up to
> period minus two elements per iteration. This also allows the algorithm
> to work for all and any vector length.
> 
> As the T-Head C908 device under test can load 16 elements loop, there is
> unsurprisingly a little performance drop when the period is minimal and
> the parallelism is capped at 13 elements:
> 
> Before:
> postfilter_15_c: 21222.2
> postfilter_15_rvv_f32:   22007.7
> postfilter_512_c:20189.7
> postfilter_512_rvv_f32:  22004.2
> postfilter_1022_c:   20189.7
> postfilter_1022_rvv_f32: 22004.2
> 
> After:
> postfilter_15_c: 20189.5
> postfilter_15_rvv_f32:7057.2
> postfilter_512_c:20189.5
> postfilter_512_rvv_f32:   5667.2
> postfilter_1022_c:   20192.7
> postfilter_1022_rvv_f32:  5667.2
> ---
>  libavcodec/riscv/opusdsp_init.c | 22 ++---
>  libavcodec/riscv/opusdsp_rvv.S  | 87 +++--
>  2 files changed, 42 insertions(+), 67 deletions(-)
> 
> diff --git a/libavcodec/riscv/opusdsp_init.c
> b/libavcodec/riscv/opusdsp_init.c index 7fde9b1fa8..f5a842a326 100644
> --- a/libavcodec/riscv/opusdsp_init.c
> +++ b/libavcodec/riscv/opusdsp_init.c
> @@ -25,30 +25,14 @@
>  #include "libavutil/riscv/cpu.h"
>  #include "libavcodec/opusdsp.h"
> 
> -void ff_opus_postfilter_rvv_128(float *data, int period, float *g, int
> len); -void ff_opus_postfilter_rvv_256(float *data, int period, float *g,
> int len); -void ff_opus_postfilter_rvv_512(float *data, int period, float
> *g, int len); -void ff_opus_postfilter_rvv_1024(float *data, int period,
> float *g, int len); +void ff_opus_postfilter_rvv(float *data, int period,
> float *g, int len);
> 
>  av_cold void ff_opus_dsp_init_riscv(OpusDSP *d)
>  {
>  #if HAVE_RVV
>  int flags = av_get_cpu_flags();
> 
> -if (flags & AV_CPU_FLAG_RVV_F32)
> -switch (ff_get_rv_vlenb()) {
> -case 16:
> -d->postfilter = ff_opus_postfilter_rvv_128;
> -break;
> -case 32:
> -d->postfilter = ff_opus_postfilter_rvv_256;
> -break;
> -case 64:
> -d->postfilter = ff_opus_postfilter_rvv_512;
> -break;
> -case 128:
> -d->postfilter = ff_opus_postfilter_rvv_512;
> -break;
> -}
> +if ((flags & AV_CPU_FLAG_RVV_F32) && (flags & AV_CPU_FLAG_RVB_ADDR))

Will add check for Zbb for the MIN instruction.

> +d->postfilter = ff_opus_postfilter_rvv;
>  #endif
>  }

-- 
雷米‧德尼-库尔蒙
http://www.remlab.net/



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

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

[FFmpeg-devel] [PATCH] lavc/opusdsp: rewrite R-V V postfilter

2023-11-02 Thread Rémi Denis-Courmont 
This uses a more traditional approach allowing up processing of up to
period minus two elements per iteration. This also allows the algorithm
to work for all and any vector length.

As the T-Head C908 device under test can load 16 elements loop, there is
unsurprisingly a little performance drop when the period is minimal and
the parallelism is capped at 13 elements:

Before:
postfilter_15_c: 21222.2
postfilter_15_rvv_f32:   22007.7
postfilter_512_c:20189.7
postfilter_512_rvv_f32:  22004.2
postfilter_1022_c:   20189.7
postfilter_1022_rvv_f32: 22004.2

After:
postfilter_15_c: 20189.5
postfilter_15_rvv_f32:7057.2
postfilter_512_c:20189.5
postfilter_512_rvv_f32:   5667.2
postfilter_1022_c:   20192.7
postfilter_1022_rvv_f32:  5667.2
---
 libavcodec/riscv/opusdsp_init.c | 22 ++---
 libavcodec/riscv/opusdsp_rvv.S  | 87 +++--
 2 files changed, 42 insertions(+), 67 deletions(-)

diff --git a/libavcodec/riscv/opusdsp_init.c b/libavcodec/riscv/opusdsp_init.c
index 7fde9b1fa8..f5a842a326 100644
--- a/libavcodec/riscv/opusdsp_init.c
+++ b/libavcodec/riscv/opusdsp_init.c
@@ -25,30 +25,14 @@
 #include "libavutil/riscv/cpu.h"
 #include "libavcodec/opusdsp.h"
 
-void ff_opus_postfilter_rvv_128(float *data, int period, float *g, int len);
-void ff_opus_postfilter_rvv_256(float *data, int period, float *g, int len);
-void ff_opus_postfilter_rvv_512(float *data, int period, float *g, int len);
-void ff_opus_postfilter_rvv_1024(float *data, int period, float *g, int len);
+void ff_opus_postfilter_rvv(float *data, int period, float *g, int len);
 
 av_cold void ff_opus_dsp_init_riscv(OpusDSP *d)
 {
 #if HAVE_RVV
 int flags = av_get_cpu_flags();
 
-if (flags & AV_CPU_FLAG_RVV_F32)
-switch (ff_get_rv_vlenb()) {
-case 16:
-d->postfilter = ff_opus_postfilter_rvv_128;
-break;
-case 32:
-d->postfilter = ff_opus_postfilter_rvv_256;
-break;
-case 64:
-d->postfilter = ff_opus_postfilter_rvv_512;
-break;
-case 128:
-d->postfilter = ff_opus_postfilter_rvv_512;
-break;
-}
+if ((flags & AV_CPU_FLAG_RVV_F32) && (flags & AV_CPU_FLAG_RVB_ADDR))
+d->postfilter = ff_opus_postfilter_rvv;
 #endif
 }
diff --git a/libavcodec/riscv/opusdsp_rvv.S b/libavcodec/riscv/opusdsp_rvv.S
index b3d23a9de5..79ae86c30e 100644
--- a/libavcodec/riscv/opusdsp_rvv.S
+++ b/libavcodec/riscv/opusdsp_rvv.S
@@ -20,56 +20,47 @@
 
 #include "libavutil/riscv/asm.S"
 
-func ff_opus_postfilter_rvv_128, zve32f
-lvtypei a5, e32, m2, ta, ma
-j   1f
-endfunc
-
-func ff_opus_postfilter_rvv_512, zve32f
-lvtypei a5, e32, mf2, ta, ma
-j   1f
-endfunc
+func ff_opus_postfilter_rvv, zve32f
+flw fa0, 0(a2) // g0
+sllit1, a1, 2
+flw fa1, 4(a2) // g1
+sub t0, a0, t1
+flw fa2, 8(a2) // g2
+addit0, t0, 2 * 4 // data - (period - 2) = initial 
 
-func ff_opus_postfilter_rvv_1024, zve32f
-lvtypei a5, e32, mf4, ta, ma
-j   1f
-endfunc
-
-func ff_opus_postfilter_rvv_256, zve32f
-lvtypei a5, e32, m1, ta, ma
+flw ft4, -16(t0)
+addit3, a1, -2 // maximum parallelism w/o stepping our tail
+flw ft3, -12(t0)
+flw ft2,  -8(t0)
+flw ft1,  -4(t0)
 1:
-li   a4, 5
-addi a1, a1, 2
-slli a1, a1, 2
-lw   t1, 4(a2)
-vsetivli zero, 3, e32, m1, ta, ma
-vle32.v  v24, (a2)
-sub  a1, a0, a1  // a1 =  = [-(period + 2)]
-vsetvl   zero, a4, a5
-vslide1up.vx v8, v24, t1
-lw   t2, 8(a2)
-vle32.v  v16, (a1)
-vslide1up.vx v24, v8, t2 // v24 = { g[2], g[1], g[0], g[1], g[2] }
-2:
-vsetvl  t0, a3, a5
-vle32.v v0, (a0)
-sub a3, a3, t0
-3:
-vsetvl zero, a4, a5
-lw t2, 20(a1)
-vfmul.vv   v8, v24, v16
-addi   a0, a0, 4
-vslide1down.vx v16, v16, t2
-addi   a1, a1, 4
-vfredusum.vs   v0, v8, v0
-vsetvl zero, t0, a5
-vmv.x.st1, v0
-addi   t0, t0, -1
-vslide1down.vx v0, v0, zero
-sw t1, -4(a0)
-bnez   t0, 3b
-
-bneza3, 2b
+min t1, a3, t3
+vsetvli t1, t1, e32, m4, ta, ma
+vle32.v v0, (t0) // x0
+sub a3, a3, t1
+vle32.v v28, (a0)
+sh2add  t0, t1, t0
+vfslide1up.vf v4, v0, ft1
+addit2, t1, -4
+vfslide1up.vf v8, v4, ft2
+vfslide1up.vf v12, v8, ft3
+vfslide1up.vf v16, v12, ft4
+vfadd.vv v20, v4, v12
+vfadd.vv v24, v0, v16
+vslidedown.vx v12, v0, t2
+vfmacc.vf v28, fa0, v8
+

Re: [FFmpeg-devel] [PATCH] avfillter/buffersrc: activate and EOF fix

2023-11-02 Thread Tristan Matthews 
On Thu, Nov 2, 2023 at 6:10 AM Paul B Mahol  wrote:
>
> On Thu, Nov 2, 2023 at 11:03 AM Nicolas George  wrote:
>
> > Paul B Mahol (12023-11-02):
> > > I analyzed it already, It is very sorry state of libavfilter that
> > buffersrc
> > > keeps sending frames to EOF filtergraph.
> >
> > So, Paul, I will explain this to you one last time.
> >
> > Remember high school, when you had math test, and if you just gave the
> > result you got almost no points even if the result was correct? That was
> > because solving a math exercise is not just about finding the result, it
> > is about showing how you reach the result and proving that the result is
> > correct.
> >
> > The same goes here. On your own projects, you can change randomly the
> > code until a bug is no longer triggered and call it fixed.
> >
> > But in FFmpeg, you are not alone, and when a change is not trivial you
> > have to prove to your fellow developers that it is correct and
> > necessary.
> >
> > So get to work, produce that proof, re-submit the patch with the proof
> > in the commit message, and then we can talk.
> >
> > As it is, the need to switch buffersrc to activate is not established,
> > and therefore it should not be done.
> >
>
> I do not understand. What proof you need?
> Have you even tested this JEEB script without patches applied?
> It should straight forward cause OOM bomb.
>
> Have you noticed that buffersrc filter never checks outlink status of its
> output link?
>

Just to confirm that I can reproduce JEEB's test, before the patches:

Maximum resident set size (kbytes): 629568

with *both* patches applied:

Maximum resident set size (kbytes): 80920

Best,
Tristan

>
> >
> > --
> >   Nicolas George
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> >
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
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] [ANNOUNCE] upcoming GA vote

2023-11-02 Thread Michael Niedermayer 
On Sun, Oct 29, 2023 at 10:33:12AM +0100, Anton Khirnov wrote:
> Hi all,
> updating the answers according to received comments:
> 
> vote question (unchanged):
> How do we update the list of active members of the general assembly?
> 
> Available answers:
> * twice a year (1st Jan & 1st July, 0:00 UTC);
>   as an exception, the list will also be updated immediately after this
>   vote
>   (suggested at VDD, added time and the exceptional update clause)

> * before each vote
>   (suggested at VDD)

This is not well defined
https://en.wikipedia.org/wiki/Well-defined_expression

"before each vote" is not a single unique point in time

First what is meant by "vote", theres a annoucement of some
intend to make a vote, there would be a discussion, there could
be a 2nd annoucement theres a period where people can propose
new options. Then the vote start is announced at some point
the actual vote start then also happens.

So we have many reference points
then "before" is everything before, even a year is "before"

and exactly at the time when the vote actually starts is impossible
because at that time the list must already be known and entered
into the vote system

I guess this doesnt matter if the option doesnt win ...

thx

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

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


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] libavdevice/decklink: extend available actions on signal loss

2023-11-02 Thread Michael Riedl 
> Hi Michael,
>
> I haven't tried your patch, but a quick review suggests that while
> you've declared the option as deprecated that it no longer works.
> Presumably somewhere in there should be a line of code that says
> something like "if (ctx->draw_bars == 0) then ctx->signal_loss_action
> = SIGNAL_LOSS_NONE"
>
> Even though the option is deprecated, it should still continue to work
> until it is completely removed.
>
> Devin


Hi Devin,

thank you for reviewing.

I just tested the code again and can confirm that the old option draw_bars still
works as intended (as describe in the table below). If the users explicitly uses
"-draw_bars false" then we set signal_loss_action to SIGNAL_LOSS_NONE (if the
option was not set by the user) and emit a deprecation warning to the user. If
the users leaves draw_bars to the default value, the option signal_loss_action
has priority.

I think this is the best solution for now that keeps the old behavior and allows
us to remove the option in the future.

| draw_bars      | signal_loss_action | new action     |
| -- | -- | -- |
| true (default) | bars (default) | bars           |
| true (default) | none               | none       |
| true (default) | repeat             | repeat     |
| false  | bars (default) | none       |
| false  | none   | none   |
| false  | repeat             | conflict 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] libavdevice/decklink: extend available actions on signal loss

2023-11-02 Thread Devin Heitmueller 
Hi Michael,

I haven't tried your patch, but a quick review suggests that while
you've declared the option as deprecated that it no longer works.
Presumably somewhere in there should be a line of code that says
something like "if (ctx->draw_bars == 0) then ctx->signal_loss_action
= SIGNAL_LOSS_NONE"

Even though the option is deprecated, it should still continue to work
until it is completely removed.

Devin

-- 
Devin Heitmueller, Senior Software Engineer
LTN Global Communications
o: +1 (301) 363-1001
w: https://ltnglobal.com  e: devin.heitmuel...@ltnglobal.com
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] libavdevice/decklink: extend available actions on signal loss

2023-11-02 Thread Michael Riedl 
On 9/25/23 13:58, Michael Riedl wrote:
> Deprecate the option 'draw_bars' in favor of the new option 
> 'signal_loss_action',
> which controls the behavior when the input signal is not available
> (including the behavior previously available through draw_bars).
> The default behavior remains unchanged to be backwards compatible.
> The new option is more flexible for extending now and in the future.
>
> The new value 'repeat' repeats the last video frame.
> This is useful for very short dropouts and was not available before.
>
> Signed-off-by: Michael Riedl 
> ---
>  doc/indevs.texi | 16 
>  libavdevice/decklink_common.h   |  1 +
>  libavdevice/decklink_common_c.h |  7 +++
>  libavdevice/decklink_dec.cpp| 23 ++-
>  libavdevice/decklink_dec_c.c|  6 +-
>  5 files changed, 51 insertions(+), 2 deletions(-)
>
> diff --git a/doc/indevs.texi b/doc/indevs.texi
> index 863536a34d5..a985d58ce7f 100644
> --- a/doc/indevs.texi
> +++ b/doc/indevs.texi
> @@ -395,6 +395,22 @@ Defaults to @samp{audio}.
>  @item draw_bars
>  If set to @samp{true}, color bars are drawn in the event of a signal loss.
>  Defaults to @samp{true}.
> +This option is deprecated, please use the @code{signal_loss_action} option.
> +
> +@item signal_loss_action
> +Sets the action to take in the event of a signal loss. Accepts one of the
> +following values:
> +
> +@table @option
> +@item 1, none
> +Do nothing on signal loss. This usually results in black frames.
> +@item 2, bars
> +Draw color bars on signal loss. Only supported for 8-bit input signals.
> +@item 3, repeat
> +Repeat the last video frame on signal loss.
> +@end table
> +
> +Defaults to @samp{bars}.
>  
>  @item queue_size
>  Sets maximum input buffer size in bytes. If the buffering reaches this value,
> diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
> index 34ab1b96700..be666212e6c 100644
> --- a/libavdevice/decklink_common.h
> +++ b/libavdevice/decklink_common.h
> @@ -146,6 +146,7 @@ struct decklink_ctx {
>  DecklinkPtsSource video_pts_source;
>  int draw_bars;
>  BMDPixelFormat raw_format;
> +DecklinkSignalLossAction signal_loss_action;
>  
>  int frames_preroll;
>  int frames_buffer;
> diff --git a/libavdevice/decklink_common_c.h b/libavdevice/decklink_common_c.h
> index 9c55d891494..53d2c583e7e 100644
> --- a/libavdevice/decklink_common_c.h
> +++ b/libavdevice/decklink_common_c.h
> @@ -37,6 +37,12 @@ typedef enum DecklinkPtsSource {
>  PTS_SRC_NB
>  } DecklinkPtsSource;
>  
> +typedef enum DecklinkSignalLossAction {
> +SIGNAL_LOSS_NONE= 1,
> +SIGNAL_LOSS_REPEAT  = 2,
> +SIGNAL_LOSS_BARS= 3
> +} DecklinkSignalLossAction;
> +
>  struct decklink_cctx {
>  const AVClass *cclass;
>  
> @@ -68,6 +74,7 @@ struct decklink_cctx {
>  int64_t timestamp_align;
>  int timing_offset;
>  int wait_for_tc;
> +DecklinkSignalLossAction signal_loss_action;
>  };
>  
>  #endif /* AVDEVICE_DECKLINK_COMMON_C_H */
> diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
> index 11640f72caa..f6095c72359 100644
> --- a/libavdevice/decklink_dec.cpp
> +++ b/libavdevice/decklink_dec.cpp
> @@ -593,6 +593,7 @@ private:
>  int no_video;
>  int64_t initial_video_pts;
>  int64_t initial_audio_pts;
> +IDeckLinkVideoInputFrame* last_video_frame;
>  };
>  
>  decklink_input_callback::decklink_input_callback(AVFormatContext *_avctx) : 
> _refs(1)
> @@ -602,10 +603,13 @@ 
> decklink_input_callback::decklink_input_callback(AVFormatContext *_avctx) : 
> _ref
>  ctx = (struct decklink_ctx *)cctx->ctx;
>  no_video = 0;
>  initial_audio_pts = initial_video_pts = AV_NOPTS_VALUE;
> +last_video_frame = nullptr;
>  }
>  
>  decklink_input_callback::~decklink_input_callback()
>  {
> +if (last_video_frame)
> +last_video_frame->Release();
>  }
>  
>  ULONG decklink_input_callback::AddRef(void)
> @@ -773,7 +777,7 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
>ctx->video_st->time_base.den);
>  
>  if (videoFrame->GetFlags() & bmdFrameHasNoInputSource) {
> -if (ctx->draw_bars && videoFrame->GetPixelFormat() == 
> bmdFormat8BitYUV) {
> +if (ctx->signal_loss_action == SIGNAL_LOSS_BARS && 
> videoFrame->GetPixelFormat() == bmdFormat8BitYUV) {
>  unsigned bars[8] = {
>  0xEA80EA80, 0xD292D210, 0xA910A9A5, 0x90229035,
>  0x6ADD6ACA, 0x51EF515A, 0x286D28EF, 0x10801080 };
> @@ -785,6 +789,8 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
>  for (int x = 0; x < width; x += 2)
>  *p++ = bars[(x * 8) / width];
>  }
> +} else if (ctx->signal_loss_action == SIGNAL_LOSS_REPEAT) {
> +last_video_frame->GetBytes();
>  }
>  
>  if (!no_video) {
> @@ -793,6

[FFmpeg-devel] [PATCH] avutil/hwcontext_vulkan: get VkFormatFeatureFlagBits2

2023-11-02 Thread Víctor Manuel Jáquez Leal 
Rather than the VkFormatFeatureFlagBits enum

Signed-off-by: Víctor Manuel Jáquez Leal 
---
 libavutil/hwcontext_vulkan.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c
index 8481427b42..506a218a42 100644
--- a/libavutil/hwcontext_vulkan.c
+++ b/libavutil/hwcontext_vulkan.c
@@ -298,8 +298,12 @@ static int vkfmt_from_pixfmt2(AVHWDeviceContext *dev_ctx, 
enum AVPixelFormat p,
 
 for (int i = 0; i < nb_vk_formats_list; i++) {
 if (vk_formats_list[i].pixfmt == p) {
+VkFormatProperties3 fprops = {
+.sType = VK_STRUCTURE_TYPE_FORMAT_PROPERTIES_3,
+};
 VkFormatProperties2 prop = {
 .sType = VK_STRUCTURE_TYPE_FORMAT_PROPERTIES_2,
+.pNext = ,
 };
 VkFormatFeatureFlagBits2 feats_primary, feats_secondary;
 int basics_primary = 0, basics_secondary = 0;
@@ -310,8 +314,7 @@ static int vkfmt_from_pixfmt2(AVHWDeviceContext *dev_ctx, 
enum AVPixelFormat p,
);
 
 feats_primary = tiling == VK_IMAGE_TILING_LINEAR ?
- prop.formatProperties.linearTilingFeatures :
- prop.formatProperties.optimalTilingFeatures;
+ fprops.linearTilingFeatures : 
fprops.optimalTilingFeatures;
 basics_primary = (feats_primary & basic_flags) == basic_flags;
 storage_primary = !!(feats_primary & 
VK_FORMAT_FEATURE_2_STORAGE_IMAGE_BIT);
 
@@ -320,8 +323,7 @@ static int vkfmt_from_pixfmt2(AVHWDeviceContext *dev_ctx, 
enum AVPixelFormat p,

vk_formats_list[i].fallback[0],
);
 feats_secondary = tiling == VK_IMAGE_TILING_LINEAR ?
-  prop.formatProperties.linearTilingFeatures :
-  prop.formatProperties.optimalTilingFeatures;
+  fprops.linearTilingFeatures : 
fprops.optimalTilingFeatures;
 basics_secondary = (feats_secondary & basic_flags) == 
basic_flags;
 storage_secondary = !!(feats_secondary & 
VK_FORMAT_FEATURE_2_STORAGE_IMAGE_BIT);
 } else {
-- 
2.42.0

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

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

Re: [FFmpeg-devel] [PATCH] avfillter/buffersrc: activate and EOF fix

2023-11-02 Thread Nicolas George 
Paul B Mahol (12023-11-02):
> I do not understand. What proof you need?

That the patch is correct and necessary.

First, explain how the current triggers the problem. In the commit
message.

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

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

Re: [FFmpeg-devel] [PATCH] avfillter/buffersrc: activate and EOF fix

2023-11-02 Thread Paul B Mahol 
On Thu, Nov 2, 2023 at 11:03 AM Nicolas George  wrote:

> Paul B Mahol (12023-11-02):
> > I analyzed it already, It is very sorry state of libavfilter that
> buffersrc
> > keeps sending frames to EOF filtergraph.
>
> So, Paul, I will explain this to you one last time.
>
> Remember high school, when you had math test, and if you just gave the
> result you got almost no points even if the result was correct? That was
> because solving a math exercise is not just about finding the result, it
> is about showing how you reach the result and proving that the result is
> correct.
>
> The same goes here. On your own projects, you can change randomly the
> code until a bug is no longer triggered and call it fixed.
>
> But in FFmpeg, you are not alone, and when a change is not trivial you
> have to prove to your fellow developers that it is correct and
> necessary.
>
> So get to work, produce that proof, re-submit the patch with the proof
> in the commit message, and then we can talk.
>
> As it is, the need to switch buffersrc to activate is not established,
> and therefore it should not be done.
>

I do not understand. What proof you need?
Have you even tested this JEEB script without patches applied?
It should straight forward cause OOM bomb.

Have you noticed that buffersrc filter never checks outlink status of its
output link?


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

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

Re: [FFmpeg-devel] [PATCH] avfillter/buffersrc: activate and EOF fix

2023-11-02 Thread Nicolas George 
Paul B Mahol (12023-11-02):
> I analyzed it already, It is very sorry state of libavfilter that buffersrc
> keeps sending frames to EOF filtergraph.

So, Paul, I will explain this to you one last time.

Remember high school, when you had math test, and if you just gave the
result you got almost no points even if the result was correct? That was
because solving a math exercise is not just about finding the result, it
is about showing how you reach the result and proving that the result is
correct.

The same goes here. On your own projects, you can change randomly the
code until a bug is no longer triggered and call it fixed.

But in FFmpeg, you are not alone, and when a change is not trivial you
have to prove to your fellow developers that it is correct and
necessary.

So get to work, produce that proof, re-submit the patch with the proof
in the commit message, and then we can talk.

As it is, the need to switch buffersrc to activate is not established,
and therefore it should not be done.

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

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

Re: [FFmpeg-devel] [PATCH] avfillter/buffersrc: activate and EOF fix

2023-11-02 Thread Paul B Mahol 
On Thu, Nov 2, 2023 at 10:50 AM Nicolas George  wrote:

> Paul B Mahol (12023-11-02):
> > You applied both patches? At correct order?
>
> Duh.
>

There are two  patches, OOM is fixed only if both are applied.


>
> > I probably should merge patches into single one.
>
> You need to analyze the bug and produce a proof that it is correct. A
> change to activate is not acceptable without a proof that it is
> necessary. The proof should be detailed and in the commit message.
>

I analyzed it already, It is very sorry state of libavfilter that buffersrc
keeps sending frames to EOF filtergraph.


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

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

Re: [FFmpeg-devel] [PATCH] avfillter/buffersrc: activate and EOF fix

2023-11-02 Thread Nicolas George 
Paul B Mahol (12023-11-02):
> You applied both patches? At correct order?

Duh.

> I probably should merge patches into single one.

You need to analyze the bug and produce a proof that it is correct. A
change to activate is not acceptable without a proof that it is
necessary. The proof should be detailed and in the commit message.

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

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

Re: [FFmpeg-devel] [PATCH] avfillter/buffersrc: activate and EOF fix

2023-11-02 Thread Paul B Mahol 
On Wed, Nov 1, 2023 at 3:13 PM Nicolas George  wrote:

> Paul B Mahol (12023-11-01):
> > It fixes it for me, ffmpeg no longer keeps sending frames to EOF
> > filtergraph.
> > And no more memory is allocated and never freed.
>
> And that is just LUCK because you changed unrelated things. You have to
> provide a PROOF, starting with what was wrong in the original code.
>
> > I ask you, kindly, once more time, to provide way how to trigger memory
> > boom (OOM) with those patches applied.
>
> I just ran the test case you gave in my usual testing environment. There
> is nothing I can tell you more, I can just copy-paste the result.
>
> Anyway, in the process of analyzing the bug and writing the proof for
> your fix, you should be able to find out why it is still happening ins
> subtly different circumstances.
>
>
> ffmpeg version N-112636-g53f9d14063 Copyright (c) 2000-2023 the FFmpeg
> developers
>   built with gcc 13 (Debian 13.2.0-5)
>   configuration: --enable-shared --disable-static --enable-gpl
> --enable-libx264 --enable-libopus --enable-libass --enable-libfreetype
> --enable-opengl --assert-level=2
>   libavutil  58. 31.100 / 58. 31.100
>   libavcodec 60. 32.102 / 60. 32.102
>   libavformat60. 17.100 / 60. 17.100
>   libavdevice60.  4.100 / 60.  4.100
>   libavfilter 9. 13.100 /  9. 13.100
>   libswscale  7.  6.100 /  7.  6.100
>   libswresample   4. 13.100 /  4. 13.100
>   libpostproc57.  4.100 / 57.  4.100
> [Parsed_scale_2 @ 0x557c9a7e6fc0] w:720 h:-2 flags:'' interl:0
> [Parsed_hqdn3d_4 @ 0x557c9a7f4640] ls:4.00 cs:3.00 lt:6.00
> ct:4.50
> [h264 @ 0x557c9a7e7e40] Reinit context to 640x480, pix_fmt: yuv420p
> Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '../test_clip.mp4':
>   Metadata:
> major_brand : isom
> minor_version   : 512
> compatible_brands: isomiso2avc1mp41
> encoder : Lavf60.17.100
>   Duration: 00:07:50.00, start: 0.00, bitrate: 1594 kb/s
>   Stream #0:0[0x1](und): Video: h264 (High), 1 reference frame (avc1 /
> 0x31637661), yuv420p(progressive, left), 640x480 [SAR 1:1 DAR 4:3], 1592
> kb/s, 25 fps, 25 tbr, 12800 tbn (default)
> Metadata:
>   handler_name: VideoHandler
>   vendor_id   : [0][0][0][0]
>   encoder : Lavc60.32.102 libx264
> [out#0/mp4 @ 0x557c9b07e000] Adding streams from explicit maps...
> [vost#0:0/copy @ 0x557c9b07f080] Created video stream from input stream 0:0
> Output #0, mp4, to '../test_clip.mp4_copy.mp4':
>   Metadata:
> major_brand : isom
> minor_version   : 512
> compatible_brands: isomiso2avc1mp41
> encoder : Lavf60.17.100
>   Stream #0:0(und): Video: h264 (High), 1 reference frame (avc1 /
> 0x31637661), yuv420p(progressive, left), 640x480 (0x0) [SAR 1:1 DAR 4:3],
> q=2-31, 1592 kb/s, 25 fps, 25 tbr, 12800 tbn (default)
> Metadata:
>   handler_name: VideoHandler
>   vendor_id   : [0][0][0][0]
>   encoder : Lavc60.32.102 libx264
> [out#1/image2 @ 0x557c9b0c1640] Adding streams from explicit maps...
> [out#1/image2 @ 0x557c9b0c1640] Creating output stream from an explicitly
> mapped complex filtergraph 0, output [thumb_out]
> [vost#1:0/mjpeg @ 0x557c9b0c44c0] Created video stream from complex
> filtergraph 0:[unsharp:default]
> [vost#1:0/mjpeg @ 0x557c9b0c44c0]
> Stream mapping:
>   Stream #0:0 (h264) -> split:default
>   Stream #0:0 -> #0:0 (copy)
>   unsharp:default -> Stream #1:0 (mjpeg)
> Press [q] to stop, [?] for help
> [h264 @ 0x557c9a8099c0] Reinit context to 640x480, pix_fmt: yuv420p
> [Parsed_scale_2 @ 0x557c9a80fa80] w:720 h:-2 flags:'' interl:0
> [Parsed_hqdn3d_4 @ 0x557c9a7e4180] ls:4.00 cs:3.00 lt:6.00
> ct:4.50
> [graph 0 input from stream 0:0 @ 0x557c9b0d9dc0] w:640 h:480
> pixfmt:yuv420p tb:1/12800 fr:25/1 sar:1/1
> [swscaler @ 0x557c9b0ddb00] deprecated pixel format used, make sure you
> did set range correctly
> [Parsed_scale_2 @ 0x557c9a80fa80] w:640 h:480 fmt:yuv420p sar:1/1 -> w:720
> h:540 fmt:yuvj420p sar:1/1 flags:0x0004
> [Parsed_setsar_3 @ 0x557c9a80dcc0] w:720 h:540 sar:1/1 dar:4/3 -> sar:1/1
> dar:4/3
> [Parsed_unsharp_5 @ 0x557c9a80fdc0] effect:sharpen type:luma msize_x:5
> msize_y:5 amount:1.00
> [Parsed_unsharp_5 @ 0x557c9a80fdc0] effect:none type:chroma msize_x:5
> msize_y:5 amount:0.00
> [vost#1:0/mjpeg @ 0x557c9b0c44c0] *** 10500 dup!
> [vost#1:0/mjpeg @ 0x557c9b0c44c0] More than 1000 frames duplicated
> Output #1, image2, to 'test_clip.mp4_img2.jpg':
>   Metadata:
> major_brand : isom
> minor_version   : 512
> compatible_brands: isomiso2avc1mp41
> encoder : Lavf60.17.100
>   Stream #1:0: Video: mjpeg, 1 reference frame, yuvj420p(pc, progressive,
> left), 720x540 (0x0) [SAR 1:1 DAR 4:3], q=2-31, 200 kb/s, 25 fps, 25 tbn
> Metadata:
>   encoder : Lavc60.32.102 mjpeg
> Side data:
>   cpb: bitrate max/min/avg: 0/0/20 buffer size: 0 vbv_delay: N/A
> Error while filtering: Resource temporarily

Re: [FFmpeg-devel] [PATCH v2] lavc/libaribcaption: Fix mistake in document decoders.texi

2023-11-02 Thread zheng qian 
On Thu, Nov 2, 2023 at 5:40 PM Gyan Doshi  wrote:
>
>
>
> On 2023-11-02 01:21 am, Gyan Doshi wrote:
> >
> >
> > On 2023-11-01 08:54 pm, zheng qian wrote:
> >> Fix the mistake in the description of `-caption_encoding
> >> encoding_scheme` option.
> > Will fix commit message and push.
>
> Pushed as 4dbfb52230c4993e58598386ac79b964589dc00e and
> 80daebdfdff48dc5ad7c1a704d885c215168e214


Thanks.

Regards,
xqq

>
> Regards, Gyan
> >
> >>
> >> Signed-off-by: zheng qian 
> >> ---
> >>   doc/decoders.texi | 5 +
> >>   1 file changed, 1 insertion(+), 4 deletions(-)
> >>
> >> diff --git a/doc/decoders.texi b/doc/decoders.texi
> >> index eb00e2a9e9..f75364166e 100644
> >> --- a/doc/decoders.texi
> >> +++ b/doc/decoders.texi
> >> @@ -391,7 +391,7 @@ Specifies the encoding scheme of input subtitle
> >> text.
> >> @table @samp
> >>   @item auto
> >> -Automatically detect text encoding.
> >> +Automatically detect text encoding (default).
> >>   @item jis
> >>   8bit-char JIS encoding defined in ARIB STD B24.
> >>   This encoding used in Japan for ISDB captions.
> >> @@ -403,9 +403,6 @@ Latin character encoding defined in ABNT NBR
> >> 15606-1.
> >>   This encoding is used in South America for SBTVD / ISDB-Tb captions.
> >>   @end table
> >>   -The default is @dfn{ass} as same as @dfn{libaribb24} decoder.
> >> -Some present players (e.g., @dfn{mpv}) expect ASS format for ARIB
> >> caption.
> >> -
> >>   @item -font @var{font_name[,font_name2,...]}
> >>   Specify comma-separated list of font family names to be used for
> >> @dfn{bitmap}
> >>   or @dfn{ass} type subtitle rendering.
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel 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] lavc/libaribcaption: Fix mistake in document decoders.texi

2023-11-02 Thread Gyan Doshi 



On 2023-11-02 01:21 am, Gyan Doshi wrote:



On 2023-11-01 08:54 pm, zheng qian wrote:
Fix the mistake in the description of `-caption_encoding 
encoding_scheme` option.

Will fix commit message and push.


Pushed as 4dbfb52230c4993e58598386ac79b964589dc00e and 
80daebdfdff48dc5ad7c1a704d885c215168e214

Regards, Gyan




Signed-off-by: zheng qian 
---
  doc/decoders.texi | 5 +
  1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/doc/decoders.texi b/doc/decoders.texi
index eb00e2a9e9..f75364166e 100644
--- a/doc/decoders.texi
+++ b/doc/decoders.texi
@@ -391,7 +391,7 @@ Specifies the encoding scheme of input subtitle 
text.

    @table @samp
  @item auto
-Automatically detect text encoding.
+Automatically detect text encoding (default).
  @item jis
  8bit-char JIS encoding defined in ARIB STD B24.
  This encoding used in Japan for ISDB captions.
@@ -403,9 +403,6 @@ Latin character encoding defined in ABNT NBR 
15606-1.

  This encoding is used in South America for SBTVD / ISDB-Tb captions.
  @end table
  -The default is @dfn{ass} as same as @dfn{libaribb24} decoder.
-Some present players (e.g., @dfn{mpv}) expect ASS format for ARIB 
caption.

-
  @item -font @var{font_name[,font_name2,...]}
  Specify comma-separated list of font family names to be used for 
@dfn{bitmap}

  or @dfn{ass} type subtitle rendering.


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

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

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

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

Re: [FFmpeg-devel] FFmpeg at NAB 2024

2023-11-02 Thread Rémi Denis-Courmont 
Hi,

FWIW, FFmpeg will most probably be granted a free community booth at the next 
SCaLE in 21x a month earlier also in South-Western USA. If this unfolds as it 
usually does, we will get confirmation in January.

There are no hidden costs *there*. But of course it's a very different crowd of 
visitors than NAB's.
___
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".