-
Notifications
You must be signed in to change notification settings - Fork 23
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
Feature/recursive videos to poses #126
Feature/recursive videos to poses #126
Conversation
Did a quick edit to the file to _SUPPORTED_VIDEO_FORMATS to see how easy it would be to switch extensions, and it successfully found and ran on .webm files as expected. But .webm support is a separate issue. #127 |
…o check .pose files for speed
Updated code to check against list of pose files as requested, and to iterate over all video suffixes. Realized this could result in foo.mp4, foo.webm both being posed to foo.pose, so added an option to keep original video suffix, and added a "this will cause name collisions do you want to keep going" check |
Also added a try/except checking for ValueError, so that if one of the video files is corrupted, the utility will keep going. Also added a check for existing .pose files, in which case it will not re-run/overwrite. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
much better. still minor changes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM - just revert one change and i'll merge.
Thanks!
This reverts commit 87346c0.
It is great! I will add a multiprocessing option to the script to use multiple CPUs. Currently, I need to run pose estimation on 1000+ hours of BSL data, and do not want to wait for too long ;) |
@J22Melody I actually did that with GNU parallel lol |
@cleong110 please share the repo with me! |
Oh silly me! The two files in question: |
Not that we shouldn't add the multiprocessing! I think that's a good thing to do. This was just my workaround:
|
Implemented a recursive option, solves #125 . Also added in an optional argument to specify the video extension to search for, though currently the only choice is .mp4. All behavior should be the same as before, as in if you don't use the -r argument it will just look in the current directory.