Le 16/10/2024 à 22:53, Michael Niedermayer a écrit :
what are you testing?
the new code is faster than the old code.
There is something not right here, the range coder based implementation
i posted now is 5% faster then the range coder based one i posted earlier today
thats overall speed meassured with "time ./ffmpeg"
if you see no difference there is something fishy

I tested your latest "8/8" and "5/5" patches, I don't see a big difference on ~50 frames.
~20% but the "bitfield" version is ~27%.
I wonder if it is due to the fact that you test with 1 frame only.


i simply tested this:
./ffmpeg -i rawsamples/16/01.dpx -threads 1  -c:v ffv1 -context 1 -coder 1 
-strict -2 -level 4 -rawlsb 4   -y /tmp/speedtest4.nut

I use this command too except -threads 1, I use all threads.
GCC 11, Ubuntu on Windows.

It uses 1 thread as the speed with more threads was very unstable between runs
and we want to know how fast ffv1 is not how multithreading behaves

Less unstable with more frames :).
Maybe the impact is different between using 1 thread only and all threads, but at the end we want to have the best speed compared to compression when all threads are used, not with only one thread.

I tested with 1 thread on 1 frame, FFmpeg + master + put_rac_raw/get_rac_raw from a previous patch + the latest patch sent (8/8 Oct 16)
- 0m9.754s without -strict -2 -level 4 -rawlsb 4
- 0m8.542s with -strict -2 -level 4 -rawlsb 4

Worse, only 13% improvement instead of 25% from bitfield patch.


can this content be downloaded somewhere ?

Not publicly (I try to have something publicly available).

Jérôme
_______________________________________________
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".

Reply via email to