There have been a number of issues and forum entries reported errors following apparently completed video analysis. Users report "No unfiltered data file found" type errors (e.g.: #1141) even though DLC reports "Analysis completed".
While there are other causes of this error (e.g. moving projects between computers, or user error in not including tracking method in multi-animal projects), some or most of the errors appear to be caused by corrupted video files or frames, and based on screenshots of the folders containing the targeted videos, dlc.analyze_videos simply didn't save any files.
OpenCV somewhat infamously lacks robustness working with corrupted video files that will play without problems in most media players which suggests the file is uncorrupted. Re-encoding video files with ffmpeg typically fixes the error, but DeepLabCut (and opencv) provide no warning. In fact, from my own experience, the only indication of a problem while running dlc.analyze_videos is that the progress bar stops prematurely. Even in those cases, there is no traceback, the "success" message is still printed, and no output files are actually saved.
It appears in predict_videos.py that the strategy is to create data frames of zeros, and then to continue over corrupted frames by simply not writing data to that row. But in some cases, no data file ends up being saved. I'm hypothesizing that some forms of corruption, probably in the header/metadata, are more fatal so this frame skipping method doesn't work. But it's not clear why no traceback is produced.
I think a relatively easy (and informative fix) would be a simple print alerting to skipped frames, the possibility of no data file being saved, and the solution of re-encoding the video with ffmpeg.
I'm not at my development computer right now, but I think adding in something like the following would help:
After the if ret: operations
elif counter < nframes:
print("possible corrupt frame encountered...if no .pickle, .meta, or .h5 files are saved for the video, consider re-encoding the video with ffmpeg")Without a break, that would allow the analysis to continue in case the corruption is minor enough to allow completion, but would inform the user of the problem.
Of course, it would print with each skipped frame, so this could get messy. As an alternative, you could set a variable corrupt_frame=True in the loop, with a single conditional print instance after the loop.
If I can find a corrupt video to test on, I'll see if I can test a PR, but it might be a while.
There have been a number of issues and forum entries reported errors following apparently completed video analysis. Users report "No unfiltered data file found" type errors (e.g.: #1141) even though DLC reports "Analysis completed".
While there are other causes of this error (e.g. moving projects between computers, or user error in not including tracking method in multi-animal projects), some or most of the errors appear to be caused by corrupted video files or frames, and based on screenshots of the folders containing the targeted videos,
dlc.analyze_videossimply didn't save any files.OpenCV somewhat infamously lacks robustness working with corrupted video files that will play without problems in most media players which suggests the file is uncorrupted. Re-encoding video files with ffmpeg typically fixes the error, but DeepLabCut (and opencv) provide no warning. In fact, from my own experience, the only indication of a problem while running
dlc.analyze_videosis that the progress bar stops prematurely. Even in those cases, there is no traceback, the "success" message is still printed, and no output files are actually saved.It appears in
predict_videos.pythat the strategy is to create data frames of zeros, and then to continue over corrupted frames by simply not writing data to that row. But in some cases, no data file ends up being saved. I'm hypothesizing that some forms of corruption, probably in the header/metadata, are more fatal so this frame skipping method doesn't work. But it's not clear why no traceback is produced.I think a relatively easy (and informative fix) would be a simple print alerting to skipped frames, the possibility of no data file being saved, and the solution of re-encoding the video with ffmpeg.
I'm not at my development computer right now, but I think adding in something like the following would help:
After the
if ret:operationsWithout a
break, that would allow the analysis to continue in case the corruption is minor enough to allow completion, but would inform the user of the problem.Of course, it would print with each skipped frame, so this could get messy. As an alternative, you could set a variable
corrupt_frame=Truein the loop, with a single conditional print instance after the loop.If I can find a corrupt video to test on, I'll see if I can test a PR, but it might be a while.