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 spee
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 possib
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:
>
>
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, Si
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
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 understa
