Closed supRy closed 4 years ago
Just tried that mpdecimate on a few of my clips and the result is fantastic. I would really like to see this added as well.
Just one issue I am seeing is that the clip is still reported as 10min long. Not sure if this is a bug or working as intended. So for example if it’s reduced to a 30sec clip. The progress bar and if you try to skip will only work on the first 5% of progress. The other 95% contains no data and will just end playback if you try to skip into it. From my perspective, the expected result would be a clip reported as a normal 30sec one, or 10min where you skip into the correct real life time and only playback time is sped up and slowed down.
@PiscisSwimeatus My clips report the new length. My clips also don't have 95% without any data. Can you provide more information on how you ran it?
I used the same command as above on some already merged clips. For example ffmpeg -i "2019-09-19T09-15-53_2019-09-19T09-26-08.mp4" -vf mpdecimate,setpts=N/FRAME_RATE/TB "2019-09-19T09-15-53_2019-09-19T09-26-08-shortened.mp4"
The original video is 9:51 long The shortened video is 1:15 long However both mediainfo, VLC and other players I tried reports the shortened video as still 9:51 long.
Which results in the progress stopping here in the players I tried:
My previous statement about 95% without data, just means trying anything after the 1:15 marks ends the video/no data.
I’ve uploaded the file here if you want to have a look: https://ufile.io/2nk461em
Release 0.1.14 is out now including this enhancement. Issue that was mentioned here with chapters is resolved in this.
After running this program, I have separately been running an FFMPEG command which removes duplicate frames. This brings a 10 minute Sentry video down to about 2 minutes typically.
There are a couple ffmpeg commands that can remove duplicate frames. What I like about the one I use is that it doesn't cut the video to the action, it takes out the intermediate frames. This means I can watch the timestamp go through the full time of the video, but when there is no motion on screen, the timestamp runs very quick; when there is motion, the time runs at normal speed.
The ffmpeg command I use is:
I'm thinking this would add a tesla_dashcam argument of
--shorten
. I'm not an ffmpeg expert, but I think this could be run concurrently with the concatenation (this would be the fastest if possible), or after the concatenation is complete.Thanks for all the work you put into this!