-
Notifications
You must be signed in to change notification settings - Fork 369
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
Create a path toward sharing memory from a numpy buffer #1061
Conversation
1c7415a
to
615bfa5
Compare
@jlaine I didn't ask but are you interested in something like this? I've been using it with quite a bit of success more recently, I can add checks for continuous buffers too if you want. |
6c6d398
to
3fbb392
Compare
anycomments on the desire to even support this kind of feature? |
9b176c7
to
a78a054
Compare
e4da4df
to
172d8a8
Compare
This avoids the use of hstack, which inevitiably copies the data to a new memory locaiton. The speed up is small, but measurable. I can go from 185 fps decoding of a ~3000 x 2000 video to 200 fps decoding.
172d8a8
to
635a6c5
Compare
I've rebased this. this is ready for review. |
For the future, I'm okay with having numpy as a compile time dep if that meant PyAV was faster or smaller. |
Maybe we can discuss this in an issue |
The YUV fastpath did not preserve the underlying byte-order, which causes issues for applications that rely on it.
The YUV fastpath did not preserve the underlying byte-order, which causes issues for applications that rely on it.
I know there is some concern about having the memory aligned.
I didn't know if it needed to be aligned to 16 bits, or 16 bytes.
If you know let me know which it is, I can add a check for it. If you don't want to support this, then that is fine too.
Closes: #1060