[FFmpeg-devel] [Question] Learning about VVC and wasm

2025-11-13 Thread Sidd via ffmpeg-devel
Hi, I was curious on learning more about VVC and wasm within the
ffmpeg project and would like some guidance on where to find the docs
and references to go through

I am simply trying to get my hands dirty with a past GSoC project to
get the feel of working on the source code (hopefully to understand it
better)

Any help on this would be much appreciated
___
ffmpeg-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]


[FFmpeg-devel] Re: [Question] Learning about VVC and wasm

2025-11-13 Thread Sidd via ffmpeg-devel
Hi Frank,

Thanks for the reply, it seems like there is a lot for me to cover.

Regarding the assembly, since FFmpeg is known for handcrafting it, are
there any references of help in their docs regarding this? I have gone
through their ASM lessons and know the basics of them but am quite far
from being good at writing it. And if I may ask, what exactly are the
current drawbacks of the current C implementation?

Thank you for taking your time to answer my questions.

On Thu, Nov 13, 2025 at 11:13 PM Frank Plowman via ffmpeg-devel
 wrote:
>
> On 13/11/2025 16:46, Sidd via ffmpeg-devel wrote:
> > Hi, I was curious on learning more about VVC and wasm within the
> > ffmpeg project and would like some guidance on where to find the docs
> > and references to go through
> >
> > I am simply trying to get my hands dirty with a past GSoC project to
> > get the feel of working on the source code (hopefully to understand it
> > better)
> >
> > Any help on this would be much appreciated
>
> If you have prior experience with AVC and HEVC, [1] is an overview of
> what was introduced in VVC.  If not, a good place to start would be with
> Iain E. Richardson's "The H.264 Advanced Video Compression Standard".
> He's also got a new book out, "Coding Video: A Practical Guide to HEVC
> and Beyond", but I'm not sure if that’s a good introductory text or
> whether it assumes some knowledge.
>
> As far as FFmpeg’s implementation goes, probably the most notable thing
> is the wavefront parallel processing (WPP) multithreading model, which
> is documented to some extent at [2].  The code for the multithreading
> aspect is pretty well-contained to libavcodec/vvc/thread.c so you can
> get a sense of how the decoder works at a high level there.  There
> aren't many docs for the decoder though really: it's an implementation
> of the standard.  In terms of the progress on the decoder and what needs
> work, its C code is in a good state but it needs more assembly written
> for it, particularly on x86.
>
> If you have any specific questions about VVC or the FFmpeg
> implementation, feel free to ask me.  I don't know anything about wasm.
>
> [1] https://ieeexplore.ieee.org/document/9503377/
> [2] https://archive.fosdem.org/2024/events/attachments/fosdem-2024-3538-
> ffmpeg-vvc-decoder/slides/22900/VVC_decoder_in_FFmpeg_Handout-1_FP3o8rS.pdf
>
> --
> All the best,
> Frank
> ___
> ffmpeg-devel mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
___
ffmpeg-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]


[FFmpeg-devel] Re: [Question] Learning about VVC and wasm

2025-11-13 Thread Sidd via ffmpeg-devel
Ok I misunderstood about the decoder part.

Sorry I am new to mailing lists am not sure what top-posting means, if
I have not abided by any rules I do apologize and will refrain from
doing so

On Thu, Nov 13, 2025 at 11:40 PM Frank Plowman via ffmpeg-devel
 wrote:
>
> On 13/11/2025 17:56, Sidd via ffmpeg-devel wrote:
> > Hi Frank,
> >
> > Thanks for the reply, it seems like there is a lot for me to cover.
> >
> > Regarding the assembly, since FFmpeg is known for handcrafting it, are
> > there any references of help in their docs regarding this? I have gone
> > through their ASM lessons and know the basics of them but am quite far
> > from being good at writing it. And if I may ask, what exactly are the
> > current drawbacks of the current C implementation?
> >
> > Thank you for taking your time to answer my questions.
> >
>
> The assembly lessons are the only "intro to SIMD" resource specifically
> for FFmpeg that I know of, but I'm sure you can find more stuff by
> googling.  A more practical resource for x86 specifically is [1] on
> x86inc.asm.  I think the most important thing is to practice.  Yes, the
> learning curve is steep.  I can't say I'm very good at writing SIMD.
>
> I'm not quite sure what you mean by "drawbacks of the current C
> implementation" -- as opposed to what?  As I said, the C high-level
> decoder logic is in a good state, but the decoder is quite slow and
> needs more ASM to make it faster.
>
> Nit: top-posting is discouraged on mailing lists such as ffmpeg-devel.
>
> [1]
> https://blogs.gnome.org/rbultje/2017/07/14/writing-x86-simd-using-x86inc-asm/
>
> --
> All the best,
> Frank___
> ffmpeg-devel mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
___
ffmpeg-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]


[FFmpeg-devel] [Question] Testing and evaluating runtime performance of functions

2025-11-17 Thread Sidd via ffmpeg-devel
I have been going through some code and found a couple of FIXME's that
mention the section of code to be "slow" and I was just curious since
I am relatively new to most kinds of profiling, how do you evaluate
this and if anybody were to come up with a patch for this, how can
they reliably show speedups in this?

I am assuming simply using valgrind or perf to cpu profile (on linux
atleast) can do a decent job showcasing certain metrics like cycles
spent, time of execution so on but I would appreciate it if I can get
some clarity on this, as I am unsure of what is expected and the usual
practice here.

PS: Sorry for double mailing my patch. I was not aware that opening a
PR would do the same.
___
ffmpeg-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]


[FFmpeg-devel] Re: [PATCH] avfilter/af_afftfilt: fix the overlap buffer size

2025-11-16 Thread Sidd via ffmpeg-devel
PR: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20933

On Sun, Nov 16, 2025 at 4:19 PM nots1dd  wrote:
>
> From what I understand, we only need to be moving N bytes as window_size
> - s->hop_size after inverse fft to the buffer for overlap. Currently the
> compiler throws a warning regarding possible overflow and this patch
> fixs it.
> ---
>  libavfilter/af_afftfilt.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavfilter/af_afftfilt.c b/libavfilter/af_afftfilt.c
> index 08cdcae2f7..4fc28c6143 100644
> --- a/libavfilter/af_afftfilt.c
> +++ b/libavfilter/af_afftfilt.c
> @@ -250,6 +250,7 @@ static int filter_channel(AVFilterContext *ctx, void 
> *arg, int jobnr, int nb_job
>  {
>  AFFTFiltContext *s = ctx->priv;
>  const int window_size = s->window_size;
> +const int hop_size = s->hop_size;
>  const float *window_lut = s->window_func_lut;
>  const float f = sqrtf(1.f - s->overlap);
>  const int channels = s->channels;
> @@ -294,7 +295,7 @@ static int filter_channel(AVFilterContext *ctx, void 
> *arg, int jobnr, int nb_job
>
>  s->itx_fn(s->ifft[ch], fft_out, fft_temp, sizeof(*fft_temp));
>
> -memmove(buf, buf + s->hop_size, window_size * sizeof(float));
> +memmove(buf, buf + hop_size, (window_size - hop_size) * 
> sizeof(float));
>  for (int i = 0; i < window_size; i++)
>  buf[i] += fft_out[i].re * window_lut[i] * f;
>  }
> --
> 2.51.0
>
___
ffmpeg-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]


[FFmpeg-devel] Re: [PATCH] avfilter/af_afftfilt: fix the overlap buffer size

2025-11-16 Thread Sidd via ffmpeg-devel
Also I am a bit confused what happens after a maintainer accepts or is
satisfied with this patch (as I am unable to commit anything to my
fork on code.ffmpeg.org) so any help on this would be great (it is my
first time if it wasnt obvious enough)

On Sun, Nov 16, 2025 at 4:19 PM nots1dd  wrote:
>
> From what I understand, we only need to be moving N bytes as window_size
> - s->hop_size after inverse fft to the buffer for overlap. Currently the
> compiler throws a warning regarding possible overflow and this patch
> fixs it.
> ---
>  libavfilter/af_afftfilt.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavfilter/af_afftfilt.c b/libavfilter/af_afftfilt.c
> index 08cdcae2f7..4fc28c6143 100644
> --- a/libavfilter/af_afftfilt.c
> +++ b/libavfilter/af_afftfilt.c
> @@ -250,6 +250,7 @@ static int filter_channel(AVFilterContext *ctx, void 
> *arg, int jobnr, int nb_job
>  {
>  AFFTFiltContext *s = ctx->priv;
>  const int window_size = s->window_size;
> +const int hop_size = s->hop_size;
>  const float *window_lut = s->window_func_lut;
>  const float f = sqrtf(1.f - s->overlap);
>  const int channels = s->channels;
> @@ -294,7 +295,7 @@ static int filter_channel(AVFilterContext *ctx, void 
> *arg, int jobnr, int nb_job
>
>  s->itx_fn(s->ifft[ch], fft_out, fft_temp, sizeof(*fft_temp));
>
> -memmove(buf, buf + s->hop_size, window_size * sizeof(float));
> +memmove(buf, buf + hop_size, (window_size - hop_size) * 
> sizeof(float));
>  for (int i = 0; i < window_size; i++)
>  buf[i] += fft_out[i].re * window_lut[i] * f;
>  }
> --
> 2.51.0
>
___
ffmpeg-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]