Invalid duration specification for ss: 00:04:60.000 when using -m copy or -m ffmpeg about dvr-scan HOT 6 CLOSED

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!

from dvr-scan.

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.

from dvr-scan.

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... :)

from dvr-scan.

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.

from dvr-scan.

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.

from dvr-scan.

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

from dvr-scan.