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
[Proposal]: Improve ScreenGear capture rate using DXcam (Windows) #316
Comments
@ReenigneArcher Thanks. This looks promising! I'll run some tests and let you know soon. |
I don't mean to spam your repo, but I am highly interested in vidgear as it seems like an awesome library with a lot of potential. I'll just put this here for now, although it's a slightly different topic. I can open it in a separate issue/proposal if you prefer. I've also been looking into screen capture with ffmpeg. I'm not sure how good the performance is as of yet. One advantage is that initial testing (from command line only) actually captures the mouse movement (on windows) which is probably worth investigating it further just for that reason. https://trac.ffmpeg.org/wiki/Capture/Desktop I've used ffmpy for re-encoding videos in python before, but not yet for screen capture or piping the output. There's another library that looks interesting for handling ffmpeg streams as well (https://pypi.org/project/python-ffmpeg-video-streaming/). I wasn't able to get it to work but I didn't put in too much effort honestly. |
That's why I'm working on deffcode. It will replace OpenCV here.
No ffmpeg backend for Videocapture is already opened in #148. So you can't open duplicate issues here. |
@ReenigneArcher DXcam cannot employed as ScreenGear backend untill unless ra1nty/DXcam#17 is resolved. Also, we'll have to wait untill DXcam becomes stable. I'll reopen this issue when these problems are fully addressed by DXcam author(s). |
Okay, thanks for the update. You can also install without the test pypi repo.
or latest: If you use poetry instead of pip, it's also possible to install directly from git. |
Yeah I know, but TestPypi test binaries cannot integrate into a stable PyPi project. Furthermore, Pypi is preferred over poetry for vidgear because of its simplicity, and also cloning git repository directly is not a good idea for any stable project. Therefore, DXcam will only be consider as backend only when the ra1nty/DXcam#17 is resolved and it is ready for testing. |
Hi @abhiTronix , pypi has been release on pypi: https://pypi.org/project/dxcam/0.0.5/ |
@ra1nty Thanks, I'll add this to TODO list. |
@ReenigneArcher @ra1nty This issue is resolved on my local machine, and it is working great 😃. But until ra1nty/DXcam#45 is resolved, the changes cannot be commit into vidgear. Looking forward to it. |
Fantastic news. Thank you for your efforts! |
- 🎉 Added initial `dxcam` support for Windows machines. (Fixes #316) - ✨ Implemented complete workflow for dxcam backend. - 🏗️ `dxcam` is now the default backend for Windows machine. - ✨ Added support for tuple value in monitor to specify device and output indexes as `(int[device_idx], int[output_idx])` in dxcam backend only. - 🧑💻 `int` index is also allowed as value for selecting device index. - ⚡️ Added support for variable screen dimensions, to capture an area from screen. - 🚩 Added `dxcam_target_fps` optional flag to control target fps in dxcam. Defaults to `0`(disabled). - ⚡️ RGB frames from dxcam is converted into BGR automatically. - ⚡️ For better performance, `video_mode` is enabled by default. - ➕ Added necessary imports. - ♻️ Refactored code blocks to ensure backward compatibility. - 💥 Enforced threaded queue mode is now removed completely, there might be boost in performance. - 💬 Reason: The IO is automatically blocked by screen refresh rate, so adding overhead of maintaining separate queue is pointless. - 💥 Removed `THREAD_TIMEOUT` optional flag. - 🔥 Cleaned related unused imports and code blocks. - 🍻 Note: Multi-Threading is still there. - 🎨 Implemented short-circuiting. - 🔊 Improved logging. - ✏️ Fixed comment typos.
- 🎉 Added initial `dxcam` support for Windows machines. - ✨ Implemented a complete workflow for the `dxcam` backend. - 🏗️ `dxcam` is now the default backend for Windows machines. - ✨ Added support for tuple values in the monitor parameter to specify device and output indexes as `(int[device_idx], int[output_idx])` in the `dxcam` backend only. - 🧑💻 `int` index is also allowed as a value for selecting device index. - ⚡️ Added support for variable screen dimensions to capture an area from the screen. - 🚩 Added the optional flag `dxcam_target_fps` to control the target fps in `dxcam`. Defaults to `0` (disabled). - ⚡️ RGB frames from `dxcam` are automatically converted into BGR. - ⚡️ For better performance, `video_mode` is enabled by default. - ➕ Added necessary imports. - ♻️ Refactored code blocks to ensure backward compatibility. - 💥 Enforced threaded queue mode is now completely removed, resulting in a potential performance boost. - 💬 Reason: The IO is automatically blocked by the screen refresh rate, so adding the overhead of maintaining a separate queue is pointless. - 💥 Removed the `THREAD_TIMEOUT` optional flag. - 🔥 Cleaned up unused imports and code blocks. - 🍻 Note: Multi-Threading is still available. - 🏗️ Enforced `dxcam` backend (if installed) when `monitor` is defined on Windows machines. - 🐛 Fixed backend not defined while logging. Docs: - 📝 Added docs for controlling Chunk size in HLS stream. (Fixes #359) - 🎨 Fixed context and added separate methods for controlling Chunk size in HLS and DASH streams. - ⚡️ Updated docs for ScreenGear with respect to recent changes. - 🧑💻 Updated usage example docs, added new relevant information, updated requirements. - ✨ Added `dxcam` API specific prerequisites for ScreenGear API when installing on Windows via pip. - ♻️ Refactored `monitor` and `backend` parameters docs of ScreenGear API. - 📝 Added a new description for ScreenGear API. - 🗑️ Removed ScreenGear from Threaded Queue Mode docs. - 🎨 Updated ScreenGear FAQs. - ✨ Added new hyperlinks. - 🔥 Cleaned redundant code. Setup.py: - ⬆️ Added `dxcam` dependency in `core` and `asyncio` extra requires. - 📌 Pinned mss==7.0.1. - 🚑️ Starting from version `8.0.0`, the python-mss library dropped support for Python `3.7`, so as a temporary measure, it has been pinned to version `7.0.1`. Helper: - ⚡️ Added multiple server support for downloading assets. - 🧑💻 Added GitHub server to the `generate_webdata` method to make it more robust for rate limits and other shortcomings. - 🩹 Now, the `generate_webdata` method will retry a different server when one fails. Maintenance: - 🗑️ Removed unused imports. - 🎨 Implemented short-circuiting. - 🔊 Improved logging. - ✏️ Fixed comment typos. - 💡 Updated comments. CI: - 🐛 Fixed m3u8 module failing to recognize Windows paths in ScreenGear tests. - 🚑️ Fixed a path bug by replacing the absolute file path with the decoded file content as a string in its `loads()` function.
@ReenigneArcher Sorry for the delay. The support for DXcam backend has been added in commit 612dee0 and will be available in next release. 🎉 |
Brief Description
While mss and pil are capable of decent capture rates, the rate can be greatly improved using DXcam.
DXcam uses the Windows Desktop Duplication API.
Context
Allowing faster capture rates would allow vidgear to capture video game input far more accurately. I was able to achieve capturing frames > 90 fps average as compared to ~30 fps using mss or Pillow.
Your Current Environment
The text was updated successfully, but these errors were encountered: