-
Notifications
You must be signed in to change notification settings - Fork 246
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MP4 conversion - Performance improvements #234
Comments
For the record, on my system, encoding a 45s (2 megabytes) session took almost 7 minutes:
|
The fix done in #273 accelerated the encoding by 2x:
I'm going to write it in the changelog. 🎈 |
The fix done in #349 led to a 6x improvement! Combined with #273 this means a 12x improvement since this issue was opened. There's a comment in the code about threading now. I just re-tested it and it had a net negative impact on performance. We would need to rewrite the encoder to proceed in batches but even then I'm not sure. PyAV is not super clear about threading encoding performance. I'm closing this for now since we did achieve 12x. We will open another one when we hit another wall after the next release. |
The time it takes to convert a replay file to MP4 seems to be an order of magnitude slower that actual replay playback.
I'd guess it's because the code is not using the PyAV bindings efficiently, or the default preset is too aggressive.
I tried saving individual PNGs (and BMPs) for each frames and using ffmpeg to convert to the final mp4 and this is roughly 10x faster. FFMPEG is multithreading the encoding, but I haven't figured out whether it's possible/exposed with PyAV.
Dumping stills is not practical for very long replays due to the disk space and additional steps required for conversion.
We should experiment with the PyAV API whether some multithreading can be done, and whether chunking the data (i.e. sending batches of X frames at once for muxing) improves performance.
The text was updated successfully, but these errors were encountered: