Skip to content

[Regression] New multithreaded reformat function slower by default than with just 1 thread used in PyAV < 17.0.0 #2200

Closed
Closed
[Regression] New multithreaded reformat function slower by default than with just 1 thread used in PyAV < 17.0.0#2200

Description

@timminator
timminator
opened on Mar 16, 2026

In the latest version, to_ndarray(format='rgb24') is significantly slower by default. Forcing threads=1 restores the original performance inline with PyAV 16.1.0. Seems to only occur consistently on unique video frames, hence the startup code in the script underneath. I expected a performance increase from this new update. :-)
@lgeiger I hope its fine if I tag you here - you added this new functionality which is really appreciated and you might know whats going on here. :-)

Example script:

import timeit
import numpy as np

n = 500

setup_code = f"""
import av
frames = [av.VideoFrame(1920, 1080, 'yuv420p') for _ in range({n})]
frame_iter = iter(frames)
"""

stmt_code = "next(frame_iter).to_ndarray(format='rgb24')"
stmt_code_1thread = "next(frame_iter).to_ndarray(format='rgb24', threads=1)"

# Run benchmark
times = timeit.repeat(stmt_code, setup=setup_code, repeat=10, number=n)
times_per_call = np.array(times) / n
times = timeit.repeat(stmt_code_1thread, setup=setup_code, repeat=10, number=n)
times_per_call_1thread = np.array(times) / n

print(f"Multithreaded (new default): {times_per_call.mean() * 1e3:.4f} ± {times_per_call.std() * 1e3:.4f} ms")
print(f"Single threaded (PyAV < 17.0.0): {times_per_call_1thread.mean() * 1e3:.4f} ± {times_per_call_1thread.std() * 1e3:.4f} ms")

Result:

Multithreaded (new default): 2.5456 ± 0.0552 ms
Single threaded (PyAV < 17.0.0): 1.8747 ± 0.0305 ms

Operating System: Windows 11
Python version: 3.12.8

Activity

  1. WyattBlue commented on Mar 16, 2026

    @WyattBlue
    WyattBlue
    on Mar 16, 2026
    Member

    You might be just be measuring 3.11 limited api perf regression, which is known issue. You should try using 3.14t

  2. lgeiger commented on Mar 16, 2026

    @lgeiger
    lgeiger
    on Mar 16, 2026
    Contributor

    I can't seem to reproduce this regression on my machine. I'm using the wheel from pypi with 3.12.13 on macOS:

    Multithreaded (new default): 0.6496 ± 0.0289 ms
Single threaded (PyAV < 17.0.0): 1.4913 ± 0.0045 ms

    @timminator Maybe this is an issue related to Windows? Can you also reproduce this on Linux?

  3. timminator commented on Mar 16, 2026

    @timminator
    timminator
    on Mar 16, 2026
    Author

    Thanks for the quick replies!

    @lgeiger Yes, im also seeing this on Linux:

    (myenv) gpuvm@gpuvm-Virtual-Machine:~/test$ echo "CPU: $(lscpu | grep 'Model name' | sed 's/Model name:[[:space:]]*//')" && echo "OS: $(grep PRETTY_NAME /etc/os-release | cut -d= -f2 | tr -d '"')" && echo "Python: $(python -V 2>&1)"
CPU: AMD Ryzen 9 5900X 12-Core Processor
OS: Ubuntu 22.04.5 LTS
Python: Python 3.12.8
(myenv) gpuvm@gpuvm-Virtual-Machine:~/test$ python test.py
Multithreaded (new default): 1.9957 ± 0.1240 ms
Single threaded (PyAV < 17.0.0): 0.7005 ± 0.0184 ms

    I dont have a mac so I cant test there aswell.
    @WyattBlue I have not tested on 3.14t but I think something else is going on here. On Linux and Windows its considerably slower.

    Edit: FYI: I've noticed this in my program that makes use of PyAV where the whole runtime in my testcase increased from 42 seconds to over 60 seconds after upgrading to PyAV 17.0.0.

  4. timminator commented on Mar 16, 2026

    @timminator
    timminator
    on Mar 16, 2026
    Author

    I was able to test 3.14t on another Windows install with the same result:

    (venv-3.14t) PS C:\Users\GPUVM\Desktop\Neuer Ordner (6)> python test.py
Multithreaded (new default): 3.4096 ± 0.0828 ms
Single threaded (PyAV < 17.0.0): 2.6226 ± 0.0808 ms

    So something is not correctly working on Windows and Linux.

  5. lgeiger commented on Mar 16, 2026

    @lgeiger
    lgeiger
    on Mar 16, 2026
    Contributor

    Thanks for testing. I also ran the above benchmark on Linux:
    CPU: AMD EPYC 9R45
    OS: Ubuntu 24.04.3 LTS
    Python: Python 3.12.3

    And I'm also not seeing any benefits from multithreading, although there is no regression:

    Multithreaded (new default): 0.5349 ± 0.0463 ms
Single threaded (PyAV < 17.0.0): 0.5517 ± 0.0100 ms

    Though it seems like I'm when I'm reusing the same reformatter I am seeing benefits from multithreading:

    import timeit
import numpy as np

n = 500

setup_code = f"""
import av
frames = [av.VideoFrame(1920, 1080, 'yuv420p') for _ in range({n})]
frame_iter = iter(frames)
reformatter = av.video.reformatter.VideoReformatter()
"""

stmt_code = "reformatter.reformat(next(frame_iter), format='rgb24').to_ndarray()"
stmt_code_1thread = "reformatter.reformat(next(frame_iter), format='rgb24', threads=1).to_ndarray()"

# Run benchmark
times = timeit.repeat(stmt_code, setup=setup_code, repeat=10, number=n)
times_per_call = np.array(times) / n
times = timeit.repeat(stmt_code_1thread, setup=setup_code, repeat=10, number=n)
times_per_call_1thread = np.array(times) / n

print(f"Multithreaded (new default): {times_per_call.mean() * 1e3:.4f} ± {times_per_call.std() * 1e3:.4f} ms")
print(f"Single threaded (PyAV < 17.0.0): {times_per_call_1thread.mean() * 1e3:.4f} ± {times_per_call_1thread.std() * 1e3:.4f} ms")
    Multithreaded (new default): 0.1912 ± 0.0410 ms
Single threaded (PyAV < 17.0.0): 0.7364 ± 0.0015 ms

    I'm not sure why the single threaded run with a shared reformatter is slower 🤔 Maybe this is an artefact from the benchmarking? @WyattBlue any ideas?

  6. WyattBlue commented on Mar 16, 2026

    @WyattBlue
    WyattBlue
    on Mar 16, 2026
    Member

    My results on AArch64 MacOS:

    v17
Multithreaded (threads=auto): 0.7858 ± 0.0267 ms
Single threaded (threads=1): 2.4082 ± 0.0784 ms

v16
Single threaded: 2.4466 ± 0.0748 ms

  7. lgeiger commented on Mar 17, 2026

    @lgeiger
    lgeiger
    on Mar 17, 2026
    Contributor

    I'm not sure why the single threaded run with a shared reformatter is slower 🤔 Maybe this is an artefact from the benchmarking?

    Looks like this is indeed just an artefact of the test ordering. So there's no regression when running single threaded with a shared reformatter.

    Looking into this a bit closer, it seems like setting up a thread pool on macOS has much lower overhead than on Linux or Windows. This causes .to_ndarray(threads=0) to be much slower since it sets up a new threadpool on each call.

    I guess using threads=1, at least for Linux/Windows, is a more sensible behaviour. We could think about keeping threads=0 as the default for the reformatter since it's might be reused multiple times, but that seems a bit inconsistent.

    @WyattBlue Do you prefer switching back to threads=1 for all platforms or do you prefer keeping threads=0 for macOS? I think I'd slightly favour sticking with threads=1 for all platforms. Users can then still tune this manually for their specific workload.

  8. WyattBlue commented on Mar 17, 2026

    @WyattBlue
    WyattBlue
    on Mar 17, 2026
    Member

    We can't release until like July 1st (storage limitations). Given that it's very likely that upstream will, or has already, fixed this issue on their end (by making threads faster or something), we should just tell users to set threads and leave it at that.

    (We really need to benchmark 480p to 4k anyway)

  9. WyattBlue
    closed this as completedon Mar 17, 2026

  10. timminator commented on Oct 5, 2026

    @timminator
    timminator
    on Oct 5, 2026
    Author

    Just for future reference and people maybe stumbling over this.
    This issue is resolved with version 19.0.x and later. Here I can see a speedup >2x on my Windows system now with the original example I posted when I opened this issue. I assume the fix was #2379.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions