DLC_analyse_videos stops estimates after # frames

Hi everyone,

When I run deeplabcut.analyze_videos() the estimation of bodyparts stops after a certain number of frames (variable, but within second half of the video). For example, in the csv file for my last video I see that after frame 339557 out of 376739 all entries for each body part are 0. I posted a screenshot of the terminal output for deeplabcut.analyze_videos() and csv file.

Any ideas of what is going on?
Thanks

Can you screenshot video metadata with number of frames, length etc.? There seem to be three different values here, one is that detected are 376740 frames, then analysis does 380457 and then in the file you have 339556 with data out of (I assume) 376740 rows - which would be correct number of frames if video length is correct at 21 mins long.

Here is it (used ffprobe).

Edit: I added # frames

Hi @Palacios! That happens when one frame cannot be read. We’ve recently pushed a fix (Avoid premature video analysis stopping in the case of a corrupted frame by jeylau · Pull Request #1105 · DeepLabCut/DeepLabCut · GitHub), which will be available in the next release :slight_smile:

Hi @Jessy! I thought so too but I tried to check this with the following:

following deeplabcut misses video frames · Issue #982 · DeepLabCut/DeepLabCut · GitHub. Does this mean that it’s not about frame integrity? Also, I think to remember that when i tried to analyse the entire video (the one in the screeshot is the first half of it) it stopped at frames beyond 339557 (the one it stopped at this time). What do you think?

Thanks

Can you transcode the video and check if it works then? If yes, then most likely there is something wrong with the video

Hi @Konrad_Danielewski . Sorry for the late reply.

I retrained the network using deeplabcut 2.1.10.3, which should have solved issue #982. However I get the same behaviour on hyffyuv (output of ffprobe → encoder: Lavf57.83.100, Stream #0:0: Video: huffyuv (HFYU / 0x55594648), bgr0, 362x352, 294098 kb/s, 299 fps, 299 tbr, 299 tbn, 299 tbc).

Instead, if I use mpeg4 (output ffprobe → encoder:Lavf57.83.100, Stream #0:0: Video: mpeg4 (Simple Profile) (FMP4 / 0x34504D46), yuv420p, 380x300 [SAR 1:1 DAR 19:15], 725 kb/s, 299 fps, 299 tbr, 299 tbn, 299 tbc) it works until the end of the videos I tested. So as you said there is something wrong with the video.

Do you have any recommendation about how to transcode the original (very big) .avi file? I’m using ffmpeg -i testvideo.avi -crf 0 -c:v huffyuv -c:a copy filter:v “crop=out_w:out_h:x:y” -r 299 testvideo_rc.avi. Maybe I’m doing something obviously wrong?

Thanks
Ensor

I use h264 or 265 on my videos with these one-liners for iterating over all .avi files in a folder. Since you have a lot of frames, but they are very small it should be quite fast. If it’s still slow maybe think of transcoding on GPU (though the quality settings might have to be more strict)

for %i in (*.avi) do ffmpeg -i "%i" -c:v libx265 -preset veryfast -crf 18 -filter:v "crop=x:y:x:y" "%~ni.mp4"
for %i in (*.avi) do ffmpeg -i "%i" -c:v libx264 -preset veryfast -crf 15 -filter:v "crop=x:y:x:y" "%~ni.mp4"

This seems to work. Thank you very much!