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