Hi,
There are two settings in webODM that appear to be related to processing stills from video files (‘video-limit’ and ‘video-resolution’) but I don’t see anywhere else that ODM can process video files and if I upload an mp4 to webODM, the UI doesn’t ever enable the “Start Processing” button.
So does ODM handle video files and if not, what are these two flags intended for?
Thanks
Those flags came about from this work by Piero and HeDoth:
So, the mp4 upload should work.
How big is it (filesize) and what is the codec and resolution?
Thanks for clarifying.
So I take it the actual capability to do this doesn’t show up unless we have the module installed?
Hmm, I’ve not gotten around to testing it, but it was merged into the code so it should just be working.
I’ll take a poke this week and see what I can turn up.
Software fault (now fixed): Allow upload of a single file · OpenDroneMap/[email protected] · GitHub
I was curious about this possibility so I tried to test it.
Some more info about the videofile, its about 28 secs and 64mb in size.
Are you using the Docker/WSL2 version, or the native installer?
Ok, there was another issue related to this, which should be now fixed: Allow single file upload by pierotofy · Pull Request #1339 · OpenDroneMap/WebODM · GitHub
I assume the above issue is the same as I’m seeing in Windows native version?
Cannot upload DJI_0126.MP4, exceeded max retries (10)
Wow! Hats of to you sir! I made a 360 around the bike from my son and WebODM made a nice 3D model.
Video
Result
I am getting the same error as Gordon but running locally with docker, etc, in Ubuntu 22.04.
I discovered and installed WebODM for the first time several weeks ago. Earlier today I thought I would try a video as input. It failed. I then found this thread and saw there were recent updates to fix some issues.
First attempt to run “./webodb.sh update” failed because git spotted a bunch of filemode changes (added executable bit). After more research I change git’s config to ignore filemode changes and applied the update without any further problems.
However, I still get same error that Gordon has shown when I try to use the single video file as input. It’s about 500 MB in size, extracted from a larger video recorded on a DJI Mini 2.
Umm. Murphy strikes!
Not yet fully confirmed but after posting my earlier message I tried again with a smaller video (about 150 MB this time). Upload went okay and processing began… until I ran out of disk space partway through the processing. Eventually I stopped WedODM and then discovered the wonders of “docker system prune” (while also feeling the fear of using that for the first time). I’m now in middle of another test with video as input.
So it seems the real problem was that I decided to try the video input just as my disk space was about to run out, and attempting to upload the 500 MB video was the straw that broke the camel’s back!
I suspect my next “learning” will be how to move docker to a location with more headroom!
Disk space wasn’t the problem for me, the error appeared immediately before any processing.
Is there a limit on video file size/length?
I was too quick with my diagnosis Gordon. Like you I still get that same error message (without any delay) as the system goes to upload the video. However I am in the final moments of processing a smaller file (150 MB instead of 500 MB).
This smaller file is video of not even one complete orbit around a cell phone tower on a hill and the processing of that was consuming far more disk than anything I’ve done before. However I now think that is because the video captures a wide panorama of the surrounding countryside in the background. For the current attempt (which looks like it will finish) I turned on the option to clean up disk space as it progressed.
Bottom line, despite what I wrote above, the problem does persist with my larger 500 MB file.
This is so great! can’t wait to test it once we’ve updated ODM
Thanks
Best to use Background removal in cases like that.
sky removal works quite well too. Although anecdotally it seems to increase processing time by huge amounts (but I haven’t tested this very systematically)
Thanks Tim and Gordon for your suggestions.
I did actually try both of those options earlier today. They don’t actually seem to add much to the processing and I checked how well the masking worked for both (by copying the images and masks out of the docker container and examining those by eye). Sky removal seemed fine. Background removal was a little less reliable, in my case sometimes masking out parts of the tower that was centre frame and my point of interest, and then at one point of the orbit it started including quite large parts of the background for no apparent reason.
I also did one pass with both turned on, but in this case it looked like the sky removal took precedence (perhaps just by virtue of running second and overwriting the mask files from the background removal). If anything I would suggest it should be the other way around if both are selected.
In any case, I still had various problems from all of those attempts. They did finish but the output was pretty broken in one way or another.
Right now another attempt is going through the pipeline. This time I cropped the input video to a 1000 px by 1000 px square that managed to keep the cell tower in view throughout but no sky and far less distant background. We will see how that works out! (Prior to this I manually cropped the frames extracted from one of the earlier tests but that seemed to confuse WebODM - the model showed no tower but the 2D image was essentially a portrait of vast number of broken towers spread out all over the surrounding land… probably not helped by the fact I only did about 1/4 of the orbit. 
And just for the record, I believe one of my earlier attempts used an input video of around 360 MB without getting the problem originally reported above by Gordan.
If you’ve got geographic data associated with the camera positions, you might try setting auto-boundary which can substantially reduce resource usage for tower reconstructions and similar.
