Re: [FFmpeg-devel] [PATCH 1/4] avfilter/asrc_sine: increase phase precision

[James Almer]

On 11/5/2024 6:31 AM, Nicolas George wrote:

Anton Khirnov (12024-11-05):

That is an unreasonable demand IMO.


Care to elaborate why requesting benchmarks for changes on a filter that
was designed for speed on the architectures it would be most impacted on
seems to you unreasonable?


Asking for benchmarks on old CPUs that are running deprecated or 
obsolete OSes is not reasonable.




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

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

Re: [FFmpeg-devel] [PATCH] avcodec/jpegxl_parser: check entropy_decoder_read_symbol return value

[Leo Izen]

On 11/1/24 8:50 AM, Kacper Michajłow wrote:

Found by OSS-Fuzz.

Signed-off-by: Kacper Michajłow 
---
  libavcodec/jpegxl_parser.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavcodec/jpegxl_parser.c b/libavcodec/jpegxl_parser.c
index 8c45e1a1b7..746c429b9c 100644
--- a/libavcodec/jpegxl_parser.c
+++ b/libavcodec/jpegxl_parser.c
@@ -1311,7 +1311,7 @@ static int parse_frame_header(void *avctx, 
JXLParseContext *ctx, GetBitContext *
  // permuted toc
  if (get_bits1(gb)) {
  JXLEntropyDecoder dec;
-uint32_t end, lehmer = 0;
+int64_t end, lehmer = 0;
  ret = entropy_decoder_init(avctx, gb, &dec, 8);
  if (ret < 0)
  return ret;
@@ -1320,13 +1320,13 @@ static int parse_frame_header(void *avctx, 
JXLParseContext *ctx, GetBitContext *
  return AVERROR_BUFFER_TOO_SMALL;
  }
  end = entropy_decoder_read_symbol(gb, &dec, toc_context(toc_count));
-if (end > toc_count) {
+if (end < 0 || end > toc_count) {
  entropy_decoder_close(&dec);
  return AVERROR_INVALIDDATA;
  }
  for (uint32_t i = 0; i < end; i++) {
  lehmer = entropy_decoder_read_symbol(gb, &dec, 
toc_context(lehmer));
-if (get_bits_left(gb) < 0) {
+if (lehmer < 0 || get_bits_left(gb) < 0) {
  entropy_decoder_close(&dec);
  return AVERROR_BUFFER_TOO_SMALL;
  }


LTGM, Will apply.

- Leo Izen (Traneptora)

___
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] avfilter/asrc_sine: increase phase precision

[Nicolas George]

Marton Balint (12024-11-04):
> Signed-off-by: Marton Balint 
> ---
>  libavfilter/asrc_sine.c |  16 +-
>  tests/ref/fate/copy-shortest1   |  58 ++---
>  tests/ref/fate/copy-shortest2   |  58 ++---
>  tests/ref/fate/filter-concat| 344 ++--
>  tests/ref/fate/filter-concat-vfr| 344 ++--
>  tests/ref/fate/filter-crazychannels |  64 +++---
>  tests/ref/fate/shortest |  58 ++---
>  tests/ref/fate/swr-async-firstpts   |  34 +--
>  8 files changed, 488 insertions(+), 488 deletions(-)

Hi.

I dislike that the ref changes. What is the point of having tests if we
change the ref when we change the code.

Please split this patch into two parts: first one that changes the code
but not the ref by updating “sine=1000” into
“sine=1000.034…” using a float constant that gives the same value
(<<32) for dphi; then a second one that reverts the test to the simple
constants and updates the refs accordingly.

That way we can be sure it is really an increase in accuracy and nothing
more.

Also, please check the speed impact on speed on a 32 bits CPU. A real
one, not an emulation or compatibility mode, and preferably a low-end
one.

Regards,

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

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

Re: [FFmpeg-devel] [PATCH 1/4] avfilter/asrc_sine: increase phase precision

[Rémi Denis-Courmont]

Le 5 novembre 2024 11:40:33 GMT+02:00, Nicolas George  a écrit 
:
>Anton Khirnov (12024-11-05):
>> 32bit CPUs are effectively obsolete and heading to extinction
>
>The idea that FFmpeg is only for new hardware and should not support
>“obsolete” hardware is unreasonable.

Sure. We should still support x86-32, but realistically the main use case for 
the ISA in future FFmpeg releases will be 32-bit apps on 64-bit hardware.

Your requirement for specific benchmarks on ""obsolete" hardware" is completely 
unreasonable regardless.
___
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/jpegxl_parser: clear window

[Leo Izen]

On 11/4/24 9:59 PM, James Almer wrote:

On 11/4/2024 11:23 PM, Michael Niedermayer wrote:

Fixes: Use of uninitialised value of size 8


Odd, the only load op with dec->window appears to be 4 bytes.

Fixes: 368725676/clusterfuzz-testcase-minimized- 
fuzzer_protocol_file-6022251122589696-cut
Fixes: 42537758/clusterfuzz-testcase-minimized- 
fuzzer_protocol_file-5818969469026304-cut


Found-by: ossfuzz
Reported-by: Kacper Michajlow
Signed-off-by: Michael Niedermayer 
---
  libavcodec/jpegxl_parser.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/jpegxl_parser.c b/libavcodec/jpegxl_parser.c
index 8c45e1a1b73..179ca1170bd 100644
--- a/libavcodec/jpegxl_parser.c
+++ b/libavcodec/jpegxl_parser.c
@@ -847,7 +847,7 @@ static int read_distribution_bundle(GetBitContext 
*gb, JXLEntropyDecoder *dec,

  }
  if (bundle->lz77_enabled && !dec->window) {
-    dec->window = av_malloc_array(1 << 20, sizeof(uint32_t));
+    dec->window = calloc(1 << 20, sizeof(uint32_t));


av_calloc(). How did it not crash for you once it was freed by av_free?

Also, wouldn't this be hiding a bug? Reading memory that was expected to 
be previously set.




It would be, as this is just a sliding LZ77 window. Reading 
uninitialized bytes that weren't written is a bug. I'd be curious to see 
the fuzz case so I could run it through valgrind and figure out why 
that's happening.


This says reported by kacper, could you send me the fuzz testcase?

- Leo Izen (Traneptora)

___
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] avfilter/asrc_sine: increase phase precision

[Anton Khirnov]

Quoting Nicolas George (2024-11-05 09:52:47)
> Also, please check the speed impact on speed on a 32 bits CPU. A real
> one, not an emulation or compatibility mode, and preferably a low-end
> one.

That is an unreasonable demand IMO.

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

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

Re: [FFmpeg-devel] [PATCH v2 4/4] tests/fate/filter-audio: add aloop test

[Anton Khirnov]

Quoting Marton Balint (2024-11-05 08:15:31)
> v2: use -filter_complex instead of -f lavfi to generate input
> 
> Signed-off-by: Marton Balint 
> ---
>  tests/fate/filter-audio.mak |  3 +++
>  tests/ref/fate/filter-aloop | 45 +
>  2 files changed, 48 insertions(+)
>  create mode 100644 tests/ref/fate/filter-aloop
> 
> diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak
> index 84478740c7..343fa40e9d 100644
> --- a/tests/fate/filter-audio.mak
> +++ b/tests/fate/filter-audio.mak
> @@ -418,6 +418,9 @@ fate-filter-atempo: CMD = pcm -i 
> $(TARGET_PATH)/tests/data/asynth-44100-1.wav -a
>  fate-filter-atempo: CMP = oneoff
>  fate-filter-atempo: REF = $(SAMPLES)/filter-reference/atempo.pcm
>  
> +fate-filter-aloop: CMD = framecrc -filter_complex 
> "sine=r=48000:f=480:d=4,aloop=loop=4:start=48000:size=48000,asetnsamples=9600"
> +FATE_AFILTER-$(call ALLYES, SINE_FILTER ALOOP_FILTER ASETNSAMPLES_FILTER 
> PCM_S16LE_ENCODER FRAMECRC_MUXER PIPE_PROTOCOL) += fate-filter-aloop

Looks ok

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

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

Re: [FFmpeg-devel] [PATCH 4/4] tests/fate/filter-audio: add aloop test

[Anton Khirnov]

Quoting Marton Balint (2024-11-04 21:30:23)
> Signed-off-by: Marton Balint 
> ---
>  tests/fate/filter-audio.mak |  3 +++
>  tests/ref/fate/filter-aloop | 45 +
>  2 files changed, 48 insertions(+)
>  create mode 100644 tests/ref/fate/filter-aloop
> 
> diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak
> index 84478740c7..04032a7d75 100644
> --- a/tests/fate/filter-audio.mak
> +++ b/tests/fate/filter-audio.mak
> @@ -418,6 +418,9 @@ fate-filter-atempo: CMD = pcm -i 
> $(TARGET_PATH)/tests/data/asynth-44100-1.wav -a
>  fate-filter-atempo: CMP = oneoff
>  fate-filter-atempo: REF = $(SAMPLES)/filter-reference/atempo.pcm
>  
> +fate-filter-aloop: CMD = framecrc -f lavfi -i "sine=r=48000:f=480:d=4" -af 
> "aloop=loop=4:start=48000:size=48000,asetnsamples=9600"
> +FATE_AFILTER-$(call ALLYES, LAVFI_INDEV SINE_FILTER ALOOP_FILTER 
> ASETNSAMPLES_FILTER PCM_S16LE_ENCODER FRAMECRC_MUXER PIPE_PROTOCOL) += 
> fate-filter-aloop

Why the dependency on -f lavfi?

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

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

Re: [FFmpeg-devel] [PATCH 1/4] avfilter/asrc_sine: increase phase precision

[Nicolas George]

Anton Khirnov (12024-11-05):
> That is an unreasonable demand IMO.

Care to elaborate why requesting benchmarks for changes on a filter that
was designed for speed on the architectures it would be most impacted on
seems to you unreasonable?

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

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

[FFmpeg-devel] [PATCH] lavfi/vf_libplacebo: eliminate LibplaceboInput.link

[Anton Khirnov]

Setting it was broken in 8160178dfc0e6bdaacf80dec58e595a9d595eedc, since
links are not yet set up during init. It is also redundant, as the
struct also stores the input index.

Reported-By: llyyr 
---
 libavfilter/vf_libplacebo.c | 41 ++---
 1 file changed, 20 insertions(+), 21 deletions(-)

diff --git a/libavfilter/vf_libplacebo.c b/libavfilter/vf_libplacebo.c
index 77219b830a..8f1787c123 100644
--- a/libavfilter/vf_libplacebo.c
+++ b/libavfilter/vf_libplacebo.c
@@ -143,7 +143,6 @@ typedef struct LibplaceboInput {
 pl_queue queue;
 enum pl_queue_status qstatus;
 struct pl_frame_mix mix; ///< temporary storage
-AVFilterLink *link;
 AVFifo *out_pts; ///< timestamps of wanted output frames
 int64_t status_pts;
 int status;
@@ -593,8 +592,7 @@ static void unlock_queue(void *priv, uint32_t qf, uint32_t 
qidx)
 }
 #endif
 
-static int input_init(AVFilterContext *avctx, AVFilterLink *link,
-  LibplaceboInput *input, int idx)
+static int input_init(AVFilterContext *avctx, LibplaceboInput *input, int idx)
 {
 LibplaceboContext *s = avctx->priv;
 
@@ -603,7 +601,6 @@ static int input_init(AVFilterContext *avctx, AVFilterLink 
*link,
 return AVERROR(ENOMEM);
 input->queue = pl_queue_create(s->gpu);
 input->renderer = pl_renderer_create(s->log, s->gpu);
-input->link = link;
 input->idx = idx;
 
 return 0;
@@ -690,7 +687,7 @@ static int init_vulkan(AVFilterContext *avctx, const 
AVVulkanDeviceContext *hwct
 if (!s->inputs)
 return AVERROR(ENOMEM);
 for (int i = 0; i < s->nb_inputs; i++)
-RET(input_init(avctx, avctx->inputs[i], &s->inputs[i], i));
+RET(input_init(avctx, &s->inputs[i], i));
 
 /* fall through */
 fail:
@@ -756,6 +753,7 @@ static void update_crops(AVFilterContext *ctx, 
LibplaceboInput *in,
 {
 FilterLink *outl = ff_filter_link(ctx->outputs[0]);
 LibplaceboContext *s = ctx->priv;
+const AVFilterLink *inlink = ctx->inputs[in->idx];
 const AVFrame *ref = ref_frame(&in->mix);
 
 for (int i = 0; i < in->mix.num_frames; i++) {
@@ -763,15 +761,15 @@ static void update_crops(AVFilterContext *ctx, 
LibplaceboInput *in,
 // own the entire pl_queue, and hence, the pointed-at frames.
 struct pl_frame *image = (struct pl_frame *) in->mix.frames[i];
 const AVFrame *src = pl_get_mapped_avframe(image);
-double image_pts = src->pts * av_q2d(in->link->time_base);
+double image_pts = src->pts * av_q2d(inlink->time_base);
 
 /* Update dynamic variables */
 s->var_values[VAR_IN_IDX] = s->var_values[VAR_IDX] = in->idx;
-s->var_values[VAR_IN_W]   = s->var_values[VAR_IW] = in->link->w;
-s->var_values[VAR_IN_H]   = s->var_values[VAR_IH] = in->link->h;
-s->var_values[VAR_A]  = (double) in->link->w / in->link->h;
-s->var_values[VAR_SAR]= in->link->sample_aspect_ratio.num ?
-av_q2d(in->link->sample_aspect_ratio) : 1.0;
+s->var_values[VAR_IN_W]   = s->var_values[VAR_IW] = inlink->w;
+s->var_values[VAR_IN_H]   = s->var_values[VAR_IH] = inlink->h;
+s->var_values[VAR_A]  = (double) inlink->w / inlink->h;
+s->var_values[VAR_SAR]= inlink->sample_aspect_ratio.num ?
+av_q2d(inlink->sample_aspect_ratio) : 1.0;
 s->var_values[VAR_IN_T]   = s->var_values[VAR_T]  = image_pts;
 s->var_values[VAR_OUT_T]  = s->var_values[VAR_OT] = target_pts;
 s->var_values[VAR_N]  = outl->frame_count_out;
@@ -809,7 +807,7 @@ static void update_crops(AVFilterContext *ctx, 
LibplaceboInput *in,
 target->crop.y1 = target->crop.y0 + s->var_values[VAR_POS_H];
 if (s->normalize_sar) {
 float aspect = pl_rect2df_aspect(&image->crop);
-aspect *= av_q2d(in->link->sample_aspect_ratio);
+aspect *= av_q2d(inlink->sample_aspect_ratio);
 pl_rect2df_aspect_set(&target->crop, aspect, 
s->pad_crop_ratio);
 }
 }
@@ -899,7 +897,7 @@ static int output_frame(AVFilterContext *ctx, int64_t pts)
 opts->params.blend_params = NULL;
 for (int i = 0; i < s->nb_inputs; i++) {
 LibplaceboInput *in = &s->inputs[i];
-FilterLink *il = ff_filter_link(in->link);
+FilterLink *il = ff_filter_link(ctx->inputs[in->idx]);
 FilterLink *ol = ff_filter_link(outlink);
 int high_fps = av_cmp_q(il->frame_rate, ol->frame_rate) >= 0;
 if (in->qstatus != PL_QUEUE_OK)
@@ -960,14 +958,15 @@ static int handle_input(AVFilterContext *ctx, 
LibplaceboInput *input)
 int ret, status;
 LibplaceboContext *s = ctx->priv;
 AVFilterLink *outlink = ctx->outputs[0];
+AVFilterLink *inlink = ctx->inputs[input->idx];
 AVFrame *in;
 int64_t pts;
 
-while ((ret = ff_inlink_consume_frame(input->link, &in)) > 0) {
+while ((ret = ff_inlink_consume_frame(inlink, &in)) > 0) {
 in-

Re: [FFmpeg-devel] [PATCH 1/4] avfilter/asrc_sine: increase phase precision

[Anton Khirnov]

Quoting Nicolas George (2024-11-05 10:31:04)
> Anton Khirnov (12024-11-05):
> > That is an unreasonable demand IMO.
> 
> Care to elaborate why requesting benchmarks for changes on a filter that
> was designed for speed on the architectures it would be most impacted on
> seems to you unreasonable?

32bit CPUs are effectively obsolete and heading to extinction for
general-purpose computing. Optimizing code for them is a waste of
precious developer time.

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

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

Re: [FFmpeg-devel] [PATCH 1/4] avfilter/asrc_sine: increase phase precision

[Nicolas George]

Anton Khirnov (12024-11-05):
> 32bit CPUs are effectively obsolete and heading to extinction

The idea that FFmpeg is only for new hardware and should not support
“obsolete” hardware is unreasonable.

-- 
  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 1/4] avfilter/asrc_sine: increase phase precision

[Rémi Denis-Courmont]

Le 5 novembre 2024 11:31:04 GMT+02:00, Nicolas George  a écrit 
:
>Anton Khirnov (12024-11-05):
>> That is an unreasonable demand IMO.
>
>Care to elaborate why requesting benchmarks for changes on a filter that
>was designed for speed on the architectures it would be most impacted on
>seems to you unreasonable?

It should be obvious, but you can't expect people to have whatever uncommon (or 
in  this case, no longer common) hardware.

You're free to take those benchmarks if they are so important. Most distros and 
commercial OSes have dropped or are dropping support for x86-32 hardware, so it 
seems very dubious that they would be relevant for future FFmpeg releases.
___
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] avfilter/asrc_sine: increase phase precision

[Nicolas George]

Rémi Denis-Courmont (12024-11-05):
> It should be obvious, but you can't expect people to have whatever
> uncommon (or in  this case, no longer common) hardware.

Anybody who needs access to unusual hardware for a Free Software project
can get an account on the GCC compile farm and thus access to a number
of servers with various hardware and OS. I am surprised that an
experienced developer does not already have an account, let alone not
know of it.

Furthermore, unless Marton neglected to mention a specific reason in the
commit message, pushing the accuracy of the frequency of a test filter
from 10^-9 to 10^-19 is a very minor enhancement that could easily
shelved until benchmark can be obtained.

-- 
  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 1/4] avfilter/asrc_sine: increase phase precision

[Nicolas George]

James Almer (12024-11-05):
> Asking for benchmarks on old CPUs that are running deprecated or obsolete
> OSes is not reasonable.

I did not ask that they be running deprecated or obsolete OSes, so…

Also there are recent ARM32 CPUs.

-- 
  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] root access voting

[Ronald S. Bultje]

Hi,

On Sun, Nov 3, 2024 at 11:37 AM Michael Niedermayer 
wrote:

> On Sun, Nov 03, 2024 at 08:56:36PM +0900, Rémi Denis-Courmont wrote:
> > Le 2 novembre 2024 20:34:30 GMT+09:00, Michael Niedermayer <
> mich...@niedermayer.cc> a écrit :
> > >At teh current videolan developer days there where several surprise
> votes on FFmpegs
> > >infractructure.
> >
> > There were obviously no formal votes on anything since no GA meetings
> were held. To be honest, you are being awfully misleading and disparaging
> of the VDD (and it's not the first time) and its attendees, including a lot
> of community members.
>
> The only information remotely made available was the
> page attached (iam not posting the link itself as iam not sure thats read
> only)
>
> and this contains multiple votes
> "Should we? 9 vs 3 vs 20 (yes, no, abstain)"
> "19 vs 0 vs 9 (yes, no, abstain)"
>

Maybe the best way to think about these is like a "show of hands",
something akin to "what's the opinion of the people in this room regarding
this subject". The opinions of the participants may alarm you, but there is
(currently) no action associated with these opinions.

As Remi said, no GA votes were held during (or at - is that even possible?)
VDD2024.

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] Fix crash when trying to get a fragment time for a non-existing fragment

[Eugene Zemtsov via ffmpeg-devel]

Any feedback?

On Thu, Oct 24, 2024 at 6:54 PM  wrote:

> From: Eugene Zemtsov 
>
> Bug: https://issues.chromium.org/issues/372994341
> Change-Id: I695d625717c078ed6f84f44e58c34da858af4d3b
> Reviewed-on:
> https://chromium-review.googlesource.com/c/chromium/third_party/ffmpeg/+/5958151
> Reviewed-by
> :
> Dale Curtis 
> ---
>  libavformat/mov.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index b4390be44f..f213fd5b22 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -1672,6 +1672,8 @@ static int64_t get_frag_time(AVFormatContext *s,
> AVStream *dst_st,
>  // to fragments that referenced this stream in the sidx
>  if (sc->has_sidx) {
>  frag_stream_info = get_frag_stream_info(frag_index, index,
> sc->id);
> +if (!frag_stream_info)
> +return AV_NOPTS_VALUE;
>  if (frag_stream_info->sidx_pts != AV_NOPTS_VALUE)
>  return frag_stream_info->sidx_pts;
>  if (frag_stream_info->first_tfra_pts != AV_NOPTS_VALUE)
> --
> 2.47.0.163.g1226f6d8fa-goog
>
>

-- 
Thanks,
Eugene Zemtsov.
___
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 incorrect enum type used for a local variable

[Eugene Zemtsov via ffmpeg-devel]

Any feedback?

On Thu, Oct 24, 2024 at 6:52 PM  wrote:

> From: Eugene Zemtsov 
>
> It's AVPacketSideDataType, not AVFrameSideDataType.
>
> Bug: https://issues.chromium.org/issues/374797732
> Change-Id: If75702c6d639ca63827cc3370477de00544d3c0f
> Reviewed-on:
> https://chromium-review.googlesource.com/c/chromium/third_party/ffmpeg/+/5950926
> Reviewed-by
> :
> Ted (Chromium) Meyer 
> ---
>  libavcodec/decode.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index c331bb8596..fbb6be2971 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -1466,7 +1466,7 @@ static int side_data_map(AVFrame *dst,
>
>  {
>  for (int i = 0; map[i].packet < AV_PKT_DATA_NB; i++) {
> -const enum AVFrameSideDataType type_pkt   = map[i].packet;
> +const enum AVPacketSideDataType type_pkt   = map[i].packet;
>  const enum AVFrameSideDataType type_frame = map[i].frame;
>  const AVPacketSideData *sd_pkt;
>  AVFrameSideData *sd_frame;
> --
> 2.47.0.163.g1226f6d8fa-goog
>
>

-- 
Thanks,
Eugene Zemtsov.
___
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] root access voting

[Michael Niedermayer]

On Tue, Nov 05, 2024 at 04:51:30PM -0500, Ronald S. Bultje wrote:
> Hi,
> 
> On Sun, Nov 3, 2024 at 11:37 AM Michael Niedermayer 
> wrote:
> 
> > On Sun, Nov 03, 2024 at 08:56:36PM +0900, Rémi Denis-Courmont wrote:
> > > Le 2 novembre 2024 20:34:30 GMT+09:00, Michael Niedermayer <
> > mich...@niedermayer.cc> a écrit :
> > > >At teh current videolan developer days there where several surprise
> > votes on FFmpegs
> > > >infractructure.
> > >
> > > There were obviously no formal votes on anything since no GA meetings
> > were held. To be honest, you are being awfully misleading and disparaging
> > of the VDD (and it's not the first time) and its attendees, including a lot
> > of community members.
> >
> > The only information remotely made available was the
> > page attached (iam not posting the link itself as iam not sure thats read
> > only)
> >
> > and this contains multiple votes
> > "Should we? 9 vs 3 vs 20 (yes, no, abstain)"
> > "19 vs 0 vs 9 (yes, no, abstain)"
> >
> 
> Maybe the best way to think about these is like a "show of hands",
> something akin to "what's the opinion of the people in this room regarding
> this subject". The opinions of the participants may alarm you, but there is
> (currently) no action associated with these opinions.

Iam disappointed and sad

This community has just a few months ago managed to loose the 2nd largest
contributor to a fork.

Instead of making "getting him back" a major talking point of the meeting.
And having an all inclusive meeting, there is no remote participation, no
recording, Even the developer with the most commits in FFmpeg has no option
to participate.
Theres a "show of hands" that i belive should not have occured, not without
discussing with the people it was about.
I hope there is noone who belives one can remove a persons admin powers for
no reason, put oneself in power instead and have that person still be
a volunteer working in that project afterwards.

ronald, you are someone knowing about buisness, I think you know this. If a CEO 
is or other
executive is voted out against his will. They dont stay in the company normally.
Iam saying this so people understand. Because i believe this is not the intend
of most of the people who raised their hand.

What we need is a open dialoge, a calm discussion about what the underlaying
issues are (if there are any). And to work towards correcting them.

thx

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

[FFmpeg-devel] [PATCH 2/2] avcodec/rv60: check init_get_bits8 return value

[Peter Ross]

Fixes CID 1634471
---
 libavcodec/rv60dec.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/libavcodec/rv60dec.c b/libavcodec/rv60dec.c
index d68fa66fa7..86c7aefbca 100644
--- a/libavcodec/rv60dec.c
+++ b/libavcodec/rv60dec.c
@@ -2263,7 +2263,8 @@ static int decode_slice(AVCodecContext *avctx, void 
*tdata, int cu_y, int thread
 thread.avg_linesize[1] = 32;
 thread.avg_linesize[2] = 32;
 
-init_get_bits8(&gb, s->slice[cu_y].data, s->slice[cu_y].size);
+if ((ret = init_get_bits8(&gb, s->slice[cu_y].data, s->slice[cu_y].size)) 
< 0)
+return ret;
 
 for (int cu_x = 0; cu_x < s->cu_width; cu_x++) {
 if ((s->avctx->active_thread_type & FF_THREAD_SLICE) && cu_y)
@@ -2317,7 +2318,8 @@ static int rv60_decode_frame(AVCodecContext *avctx, 
AVFrame * frame,
 if (avpkt->size < header_size)
 return AVERROR_INVALIDDATA;
 
-init_get_bits8(&gb, avpkt->data + header_size, avpkt->size - header_size);
+if ((ret = init_get_bits8(&gb, avpkt->data + header_size, avpkt->size - 
header_size)) < 0)
+return ret;
 
 if ((ret = read_frame_header(s, &gb, &width, &height)) < 0)
 return ret;
-- 
2.45.2

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)


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 1/2] avcodec/rv60: negative qp guard

[Peter Ross]

Fixes CID 1634472
---
 libavcodec/rv60dec.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/rv60dec.c b/libavcodec/rv60dec.c
index d0cc10253b..d68fa66fa7 100644
--- a/libavcodec/rv60dec.c
+++ b/libavcodec/rv60dec.c
@@ -2270,6 +2270,8 @@ static int decode_slice(AVCodecContext *avctx, void 
*tdata, int cu_y, int thread
 ff_thread_progress_await(&s->progress[cu_y - 1], cu_x + 2);
 
 qp = s->qp + read_qp_offset(&gb, s->qp_off_type);
+if (qp < 0)
+return AVERROR_INVALIDDATA;
 sel_qp = calc_sel_qp(s->osvquant, qp);
 
 memset(thread.coded_blk, 0, sizeof(thread.coded_blk));
-- 
2.45.2

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)


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] [PATCHv2] avcodec/eatgq: decode motion vector macroblocks

[Peter Ross]

Signed-off-by: Peter Ross 
---
added missing reference frame check. will apply soon.

 libavcodec/codec_desc.c |  2 +-
 libavcodec/eatgq.c  | 54 ++---
 2 files changed, 51 insertions(+), 5 deletions(-)

diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 315c758acb..aeac75a6c5 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -905,7 +905,7 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .type  = AVMEDIA_TYPE_VIDEO,
 .name  = "tgq",
 .long_name = NULL_IF_CONFIG_SMALL("Electronic Arts TGQ video"),
-.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY,
+.props = AV_CODEC_PROP_LOSSY,
 },
 {
 .id= AV_CODEC_ID_TQI,
diff --git a/libavcodec/eatgq.c b/libavcodec/eatgq.c
index d326c05390..e488f3c510 100644
--- a/libavcodec/eatgq.c
+++ b/libavcodec/eatgq.c
@@ -36,12 +36,14 @@
 #include "avcodec.h"
 #include "bytestream.h"
 #include "codec_internal.h"
+#include "copy_block.h"
 #include "decode.h"
 #include "eaidct.h"
 #include "get_bits.h"
 
 typedef struct TgqContext {
 AVCodecContext *avctx;
+AVFrame *last_frame;
 int width, height;
 int qtable[64];
 DECLARE_ALIGNED(16, int16_t, block)[6][64];
@@ -53,6 +55,9 @@ static av_cold int tgq_decode_init(AVCodecContext *avctx)
 s->avctx = avctx;
 avctx->framerate = (AVRational){ 15, 1 };
 avctx->pix_fmt   = AV_PIX_FMT_YUV420P;
+s->last_frame = av_frame_alloc();
+if (!s->last_frame)
+return AVERROR(ENOMEM);
 return 0;
 }
 
@@ -173,7 +178,33 @@ static int tgq_decode_mb(TgqContext *s, GetByteContext 
*gbyte,
 tgq_idct_put_mb(s, s->block, frame, mb_x, mb_y);
 bytestream2_skip(gbyte, mode);
 } else {
-if (mode == 3) {
+if (mode == 1) {
+int x, y;
+int mv = bytestream2_get_byte(gbyte);
+int mv_x = mv >> 4;
+int mv_y = mv & 0x0F;
+if (!s->last_frame->data[0]) {
+av_log(s->avctx, AV_LOG_ERROR, "missing reference frame\n");
+return -1;
+}
+if (mv_x >= 8) mv_x -= 16;
+if (mv_y >= 8) mv_y -= 16;
+x = mb_x * 16 - mv_x;
+y = mb_y * 16 - mv_y;
+if (x < 0 || x + 16 > s->width || y < 0 || y + 16 > s->height) {
+av_log(s->avctx, AV_LOG_ERROR, "invalid motion vector\n");
+return -1;
+}
+copy_block16(frame->data[0] + (mb_y * 16 * frame->linesize[0]) + 
mb_x * 16,
+ s->last_frame->data[0] + y * 
s->last_frame->linesize[0] + x,
+ frame->linesize[0], s->last_frame->linesize[0], 16);
+for (int p = 1; p < 3; p++)
+copy_block8(frame->data[p] + (mb_y * 8 * frame->linesize[p]) + 
mb_x * 8,
+s->last_frame->data[p] + (y >> 1) * 
s->last_frame->linesize[p] + (x >> 1),
+frame->linesize[p], s->last_frame->linesize[p], 8);
+frame->flags &= ~AV_FRAME_FLAG_KEY;
+return 0;
+} else if (mode == 3) {
 memset(dc, bytestream2_get_byte(gbyte), 4);
 dc[4] = bytestream2_get_byte(gbyte);
 dc[5] = bytestream2_get_byte(gbyte);
@@ -228,9 +259,12 @@ static int tgq_decode_frame(AVCodecContext *avctx, AVFrame 
*frame,
 s->height = bytestream2_get_le16u(&gbyte);
 }
 
-ret = ff_set_dimensions(s->avctx, s->width, s->height);
-if (ret < 0)
-return ret;
+if (s->avctx->width != s->width || s->avctx->height != s->height) {
+av_frame_unref(s->last_frame);
+ret = ff_set_dimensions(s->avctx, s->width, s->height);
+if (ret < 0)
+return ret;
+}
 
 tgq_calculate_qtable(s, bytestream2_get_byteu(&gbyte));
 bytestream2_skipu(&gbyte, 3);
@@ -238,16 +272,27 @@ static int tgq_decode_frame(AVCodecContext *avctx, 
AVFrame *frame,
 if ((ret = ff_get_buffer(avctx, frame, 0)) < 0)
 return ret;
 
+frame->flags |= AV_FRAME_FLAG_KEY;
 for (y = 0; y < FFALIGN(avctx->height, 16) >> 4; y++)
 for (x = 0; x < FFALIGN(avctx->width, 16) >> 4; x++)
 if (tgq_decode_mb(s, &gbyte, frame, y, x) < 0)
 return AVERROR_INVALIDDATA;
 
+if ((ret = av_frame_replace(s->last_frame, frame)) < 0)
+return ret;
+
 *got_frame = 1;
 
 return avpkt->size;
 }
 
+static av_cold int tgq_decode_close(AVCodecContext *avctx)
+{
+TgqContext *s = avctx->priv_data;
+av_frame_free(&s->last_frame);
+return 0;
+}
+
 const FFCodec ff_eatgq_decoder = {
 .p.name = "eatgq",
 CODEC_LONG_NAME("Electronic Arts TGQ video"),
@@ -255,6 +300,7 @@ const FFCodec ff_eatgq_decoder = {
 .p.id   = AV_CODEC_ID_TGQ,
 .priv_data_size = sizeof(TgqContext),
 .init   = tgq_decode_init,
+.close  = tgq_decode_close,
 FF_CODEC