-
Notifications
You must be signed in to change notification settings - Fork 4
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
Improve Support for Iterative Reading of High-Res Video #16
Comments
Hello, thank you for you interest in this library. import video_reader as vr
from tqdm import tqdm
filename = "/path/to/file.mp4"
chunk_size = 500
(n, h ,w) = vr.get_shape(filename)
for i in tqdm(range(0, n, chunk_size)):
end = min(i + chunk_size, n)
frames = vr.decode(filename, start_frame=i, end_frame=end)
# do whatever you need with `frames` afterwards It is still not as fast as it could be, but should be a big improvement compared to using Also it is worth noting that the main bottleneck with this use case (ie High Res videos) is the part of converting the raw frame into an ndarray. You might be interested to try the last snippet of code here described in the discussion #5 |
For simple iterative stuff, something like this would better suit the use case. For now I've decided to stick with simply calling FFMPEG through a subprocess due to the amount of flexibility one can get through it, though eventually, as soon as the bindings are done I will potentially switch as well. |
Might be worth mentioning that this ffmpy lib seems to be Windows only for now. |
Hello, I've pushed some interesting update that should improve decoding speed by 2.5x to 3x. Let me know how it works out for you ;-) |
import video_reader as vr
from tqdm import tqdm
filename = r"C:\Users\User\Downloads\file_example_MP4_1920_18MG.mp4"
chunk_size = 500
(n, h, w) = vr.get_shape(filename)
for i in tqdm(range(0, n, chunk_size)):
end = min(i + chunk_size, n)
frames = vr.decode_fast(filename, start_frame=i, end_frame=end) Looks like DLL Load is still an issue. |
I dont have a windows machine so I cannot test. I would suggest to try and build from source:
|
This package has been useful to me already. Thank you very much for your work!
My particular use case involves iterative processing of high resolution video.
Decord fails for me here, because of the apparent memory leak described here, which ultimately lead me to explore this library as an alternative.
Unfortunately, this library falls short for me as well because this sort of reading seems to be quite slow (much slower than Decord). I noted the discussion in #5, and in particular the approach outlined in this comment outlining necessary development to support this use case.
I wanted to follow up on any plans to support this use case, and at the very least document / track it in this issue.
The text was updated successfully, but these errors were encountered: