Invalid duration specification for ss: 00:04:60.000 when using -m copy or -m ffmpeg

[ThatCoffeeGuy]

Bug/Issue Description: A clear and concise description of what the bug or issue is - in other words, what the unexpected behavior or output is.

I believe this tells everything:

[DVR-Scan] DVR-Scan v1.5.1
[DVR-Scan] Initializing scan context...
[DVR-Scan] Opened video 2023092620.mp4 (1920 x 1080 at 29.970 FPS).
[DVR-Scan] Scanning input video for motion events...
[DVR-Scan] Splitting events using ffmpeg, first event:
[DVR-Scan] ffmpeg -y -nostdin -v error -ss 00:04:08.782 -i 2023092620.mp4 -t 00:00:11.011 -map 0 -c:v libx264 -preset fast -crf
 21 -c:a aac -sn 2023092620.DSME_0001.mp4
[DVR-Scan] Fatal error: Exception raised in encode thread.
Detected: 5 | Progress:  22%|████████████▎                                          | 9599/42938 [01:16<04:24, 125.85 frames/s]
[DVR-Scan] Failed to run command:
  ffmpeg -y -nostdin -v error -ss 00:04:60.000 -i 2023092620.mp4 -t 00:00:16.483 -map 0 -c:v libx264 -preset fast -crf 21 -c:a
aac -sn 2023092620.DSME_0004.mp4
Command returned 1, output:

Invalid duration specification for ss: 00:04:60.000

Provide a full copy of the command line options you are using, and add --verbosity debug, for example:

for i inls *.mp4; do dvr-scan --input $i -m ffmpeg --logf ile motion-log.log; done

Computing Environment:

• OS: Ubuntu 22.04
• DVR-Scan v1.5.1
• ffmpeg version 4.4.2
• Python Version: Python 3.10.12
• OpenCV Version: '4.8.1

[ThatCoffeeGuy]

It seems the issue is with -ss 00:04:60.000. If I manually set it to -ss 00:05:00.000, ffmpeg works.

I suppose the issue really is with edgecases like this.

Also, after checking my videos, it seems it could generate some files using ffmpeg, but those are all mismatching the timestamps, since nothing actually happens in them.

[ThatCoffeeGuy]

I can also see that if I do it with AVI, it works perfectly, but there's no sound and the footage is slightly faster than it should be. There are multiple issue at force here... :)

[Breakthrough]

Hmm there might be some floating point rouding issues happening here. Timestamp calculation is done by the scenedetect FrameTimecode class, so it's possible something is wrong there... I see a few suspicious issues with rounding that might be causing this.

Thanks for bringing this up, I'll try to have a workaround in place for v1.6. Feel free to file an issue for any other bugs you find, thanks!

[ThatCoffeeGuy]

Thank you for your answer, I will keep this updated with my findings. In the 1 hour video I tested, the first motion was around 14 minutes. With just letting it use .avi, it extracts that timestamp properly, but the motion is definitely sped up. If I let it go with ffmpeg or copy option, the first cut is from somewhere around 4-5 minutes of the original 1 hour footage.

It could be an issue with variable framerate as well. to the same video file, I read 10-20 and 30 fps results somewhere, so I believe the framerate is not constant there.

[Breakthrough]

VFR isn't well supported yet when splitting videos with ffmpeg, nor will the timestamps be accurate. However, the AVI should provide the correct result, minus potential differences in playback speed due to it always encoding as fixed framerate. Fixing VFR stuff is tracked by #20 and is planned for a future release.

[Breakthrough]

Fix will be included in v1.6 release, thanks!