Avoid premature video analysis stopping in the case of a corrupted frame - #1058
Conversation
|
Great idea! My only worry with this (I have not tested yet!) is that for 3D, if one video is shorter than the other, etc, how is this handled? i.e., let's say video A (100 frames) has 1 frame corrupted mid-way through, video B is fine (100 frames). Then, video A has 99 frames, and video B has 100. Then of course they are not matched in time/length/postures. Is the corrupted frame placed with a place holder for the dropped frame? |
|
I'll give some more thoughts to that particular case 😄. |
|
I think it must be a placeholder frame then in the resulting H5/CSV; otherwise, this would severely disrupt not only 3D, but any expt in our lab, for example (i.e., if time does not match other datastreams). |
|
Noting that this is only a problem for batch analysis (as otherwise frames are correctly stored according to the counter), I think there is simple solution: keeping a list of the corresponding frame indices. That way, whether frames are skipped or not, batches are still filled the same way and we know we have the right indices when populating the data dictionary. |
Corrupted frames are now skipped during video analysis, no longer causing its early termination. Only when a frame cannot be grabbed and all previous frames have been read does the analysis stop.