<p>FFmpeg has a <a href="http://www.ffmpeg.org/ffmpeg-all.html#framestep" rel="nofollow">framestep</a> filter to take every <code>n</code>th frame.</p>

<p>There's also <code>mpdecimate</code>, which outputs a frame whenever the input frame is different enough from the previous frame.  (so if exactly every 60th frame isn't perfect, you could use <code>mpdecimate</code> instead to detect the changes, and make a potentially VFR video.)</p>

<p>I didn't test this command; post a comment if I screwed it up:</p>

<p><code>ffmpeg -i in.camrec -vf framestep=60 -r 1/60 -codec copy -map 0 -c:v libx264 -preset medium -crf 16 -movflags +faststart -vsync 2 out.mp4</code></p>

<p>Or use <code>out.mkv</code> if you like matroska better than the mp4 container.</p>

<p><code>copy</code> (stream copy) won't work while dropping frames, I think even for an intra-only codec.  So your output has to be encoded to some codec.  My example uses lossy h.264, but with the quality cranked so high it should be transparent.  You could use lossless h.264 (<code>-preset ultrafast -qp 0</code>), <code>-c:v utvideo</code>, or whatever else you like.</p>

<p><code>-vsync 2</code> turns on VFR output mode, which for some reason isn't the default in mp4.  (but it is in mkv).  You'll want that if you use <code>mpdecimate</code>, but you won't need it for <code>framestep</code>.</p>

<p>A quick google didn't tell me if camrec is already lossy or not.  If it's lossy, then there's no way to get a file as small but with the same quality as just keeping every 60th CamRec frame without decoding them.  (assuming there's an intra-only frame at the point you want one, if the format has any non-intra frames.)</p>

<p>With mjpeg, you can turn a video into a directory of images without decoding, and select whichever ones you want, and mux them up again.  Since camrec frames probably aren't a stand-alone image format, it's unlikely there's something similar, so you just have to use video tools.  Like I said, don't think ffmpeg can do clever things like frame dropping without decompressing, even for intra-only codecs.  Other tools might exist that can do that, for some codecs.</p>

<p>If it's lossless, then it just takes more CPU time to decode / re-encode to a new lossless format.</p>

<p>edit: more about mpdecimate:
As noted in the comments, I added some stats logging to mpdecimate.<br>
<code>git pull https://github.com/pcordes/FFmpeg.git mpdecimate</code><br>
and then build ffmpeg as usual.</p>

<p>Then run <code>ffmpeg -v debug ...</code>.<br>
Or <code>ffplav -v debug -vf mpdecimate  input.avi</code></p>

<p>Testing mpdecimate threshold settings with ffplay is a lot faster than making an encode.</p>

CC BY-SA 3.0
2015-03-01T18:45:19.700Z
Oh btw, camrec appears to be a container format.  It can hold a few different codecs.  I haven't checked that ffmpeg can decode them all, but apparently you can record in xvid or h.264 in camrec, unless I misread a random forum comment.
Peter Cordes
CC BY-SA 3.0
2015-03-02T19:23:57.473Z
I tried both commands but neither worked. It seems `mpdecimate` is really what I'm looking for, but every time I try to run the command I get either an unchanged file, or a purely black file that is slightly longer than the input file. I converted my camrec file to a lossless AVI file (since ff seems to have trouble with it) and ran this: `ffmpeg -i "capture-1.avi" -vf "mpdecimate" -vsync 2 "capture-1.mp4"`, also without the `-vsync 2` part, to no avail. Am I doing this wrong?
IDontWorkAtNASA
CC BY-SA 3.0
2015-03-02T19:45:47.127Z
The difference in the frames is substantial and should be triggering the drops, but in case it isn't I tried altering the command parameters with little success. The [documentation](https://ffmpeg.org/ffmpeg-filters.html#mpdecimate) unfortunately offers no real guidance on how the parameters are entered.
IDontWorkAtNASA
CC BY-SA 3.0
2015-03-03T02:25:45.370Z
That looks like the right command line. What different options did you try for mpdecimate?  The options set thresholds for 8x8 SAD of blocks on all planes (luma and chroma).  (http://en.wikipedia.org/wiki/Sum_of_absolute_differences).  Is there a blinking cursor somewhere on the screen that's triggering the `hi` threshold?  Maybe crank it really high, and depend on the `lo` threshold to detect when large areas of the screen change.
Peter Cordes
CC BY-SA 3.0
2015-03-03T03:23:52.543Z
See my edit to my answer.  Last time I used mpdecimate, I added some debug prints to it.  If can and want to compile ffmpeg from source, grab my mpdecimate branch of https://github.com/pcordes/FFmpeg/tree/mpdecimate.  (I just rebased it to current git master, so you should be able to `git pull https://github.com/pcordes/FFmpeg.git mpdecimate` in an existing git clone of ffmpeg.)
Peter Cordes
CC BY-SA 3.0
2015-03-03T18:50:30.357Z
I retried the commands, I noticed the files I thought were "purely black" were actually mostly black, with some of my input video at the end. But it doesn't seem like all the frames were dropped (some were), so I would need to increase the sensitivity. Do you know how I would do that? I don't have the tools to recompile ffmpeg, sorry.
IDontWorkAtNASA
CC BY-SA 3.0
2015-03-03T23:18:51.373Z
No worries.  Black frames sounds like a really weird symptom.  `mpdecimate` should make your video appear to freeze for a bit if it does anything at all.  IDK if it even can drop the first frame.  Try  `ffplay -vf mpdecimate,showinfo`.  You can tell it's dropping frames when showinfo isn't printing lines of output.
Peter Cordes
CC BY-SA 3.0
2015-03-03T23:24:34.290Z
If the frames you want to drop are really identical, you can try `-vf mpdecimate=hi=64*12:lo=64*2:frac=0.1,showinfo`.  as http://www.ffmpeg.org/ffmpeg-all.html#mpdecimate explains, one 8x8 block where the sum of differences exceeds `hi` will result in an output frame.  Same when more than `frac` fraction of the 8x8 blocks have more than `lo` difference.  So if there's a blinking cursor, that will trigger `hi` every time unless you crank it all the way up and just depend on `lo`.
Peter Cordes
CC BY-SA 3.0
2015-03-03T23:42:15.457Z
Next time you test it, can you copy/paste FULL command line output from ffmpeg into your question?  There might be something else going wrong leading to black frames.  Like I said, you should just see an old frame stay there for ages if mpdecimate is dropping more than it should.  (Maybe your input video has black frames?  Or ffmpeg isn't decoding it perfectly?)
Peter Cordes
CC BY-SA 3.0
2015-03-04T20:39:17.170Z
Ok done. In terms of black frames, I remember Camtasia prompting what color background I wanted the video to have, black being the default. I didn't understand it, since I was screen recording (there should never be a "background" showing, but maybe it's just a weird format requirement).
IDontWorkAtNASA
CC BY-SA 3.0
2015-03-05T17:33:49.187Z
3 things: What do you get without `mpdecimate`?  Still black frames at the beginning?
Peter Cordes
CC BY-SA 3.0
2015-03-05T17:42:49.313Z
Try with `ffmpeg -v debug`.  I'd forgotten mpdecimate does have debug-logging code to print WHEN it's dropping frames; my patch just added info on whether `hi` or `frac` / `lo` was the reason for allowing a frame through.  (It will spew a crapton of debug output from everything else, too, since there's no per-component logging).  You didn't post output from the `mpdecimate,showinfo`, just the x264 encoder stats after it got to the end.  I could see that it allowed 411 frames through, instead of 406 from your run with mpdecimate default settings.  (of 35s*30fps = about 1050 frames.)
Peter Cordes
CC BY-SA 3.0
2015-03-05T17:45:46.983Z
and the 3rd thing: I tried to download your original from dropbox, but it didn't work.  I get the captcha, but no download starts at all.  Since your ffmpeg output indicates it's really uncompressed, not just lossless, you could make it a LOT smaller but still bit-for-bit identical data with `ffmpeg -i raw.avi -c:v libx264rgb -qp 0 -preset ultrafast  lossless.mkv`.  Then upload that.  (libx264rgb since I see your input is raw RGB video.)  No need to try mpdecimate with that input, results will be identical.  Filters happen after video decoding.
Peter Cordes
CC BY-SA 3.0
2015-03-05T17:50:08.417Z
Oh also, your video is only 572x280.  Do you normally record at such low rez?  Doesn't that make it hard to read text?  Anyway, this might be causing changes in the input to happen on smaller scales than the 8x8 blocks that mpdecimate checks.
Peter Cordes
CC BY-SA 3.0
2015-03-05T18:46:38.673Z
I *really* appreciate all your help with this (seriously), but I think this is simply outside my expertise (psychologist, sadly). I'm burning taxpayer dollars and getting nowhere fast, so I'm just going to re-record using different software capable of 1 frame-per-minute recording. Thanks again for all your help.
IDontWorkAtNASA
CC BY-SA 3.0
2015-03-05T18:48:32.643Z
no worries.  mpdecimate isn't the most user-friendly filter.
Peter Cordes
CC BY-SA 3.0
2015-03-01T02:00:01.127Z
2015-03-03T03:28:01.740Z
2015-03-03T03:28:01.740Z
Peter Cordes
<p>I have large video files of screen recordings which I created with Camtasia Recorder. The content I am recording only updates once per minute (1/60 fps), however Camtasia appears to require at least 1 fps for recording (quite silly, really). So that's what I did, and then I tried looking in Camtasia Studio to cut out the extra frames but it seems the only way to reduce the file size without compressing to a lossy format is to manually cut by hand 1 second segments throughout the entire file, but these files are too long to do this by hand (3 files, one of which is 24 hrs and the shortest is 8 hrs).</p>
<h3>How would I cut all but 1 frame every 60 seconds from a video file?</h3>
<p>Note that while the file is currently in the CamRec format, I can convert it to other formats if need be.</p>
<h3>Attempts at using mpdecimate:</h3>
<hr />
<p>I have a 479mb &quot;test.avi&quot; video (you can download it <a href="http://www.filedropper.com/test_71" rel="nofollow noreferrer">here</a>) which is 35 second uncompressed avi file of me moving some windows around on my desktop.</p>
<p>The first command I ran was:</p>
<pre><code>ffmpeg -i test.avi -vf mpdecimate test-out.mp4
</code></pre>
<p>The <a href="http://www.filedropper.com/test-out" rel="nofollow noreferrer">resulting file</a> (714kb) has 5-6 seconds of black, then the rest of the input video unaltered (but it is compressed).</p>
<hr />
<p>Then I tried:</p>
<pre><code>ffmpeg -i test.avi -vf mpdecimate -vsync 2 test-out.mp4
</code></pre>
<p>Which output <a href="http://www.filedropper.com/test-out2" rel="nofollow noreferrer">a file</a> (716kb) with seemingly the same results.</p>
<pre><code>ffmpeg version N-70358-g047fd98 Copyright (c) 2000-2015 the FFmpeg developers
  built with gcc 4.9.2 (GCC)
  configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnu
tls --enable-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libfreetype --enable-libgme --enable-libgsm --enable-
libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-l
ibrtmp --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-aacenc --
enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --ena
ble-libxvid --enable-lzma --enable-decklink --enable-zlib
  libavutil      54. 19.100 / 54. 19.100
  libavcodec     56. 26.100 / 56. 26.100
  libavformat    56. 23.106 / 56. 23.106
  libavdevice    56.  4.100 / 56.  4.100
  libavfilter     5. 11.102 /  5. 11.102
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  1.100 /  1.  1.100
  libpostproc    53.  3.100 / 53.  3.100
Input #0, avi, from 'test.avi':
  Duration: 00:00:34.87, start: 0.000000, bitrate: 115403 kb/s
    Stream #0:0: Video: rawvideo, bgr24, 572x280, 115425 kb/s, 30 fps, 30 tbr, 30 tbn, 30 tbc
File 'test-out2.mp4' already exists. Overwrite ? [y/N] y
No pixel format specified, yuv444p for H.264 encoding chosen.
Use -pix_fmt yuv420p for compatibility with outdated media players.
[libx264 @ 0000000003047200] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
[libx264 @ 0000000003047200] profile High 4:4:4 Predictive, level 2.1, 4:4:4 8-bit
[libx264 @ 0000000003047200] 264 - core 144 r2525 40bb568 - H.264/MPEG-4 AVC codec - Copyleft 2003-2014 - http://www.videolan.org/x264.html - options:
 cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 dead
zone=21,11 fast_pskip=1 chroma_qp_offset=4 threads=12 lookahead_threads=2 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_in
tra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahe
ad=40 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
Output #0, mp4, to 'test-out2.mp4':
  Metadata:
    encoder         : Lavf56.23.106
    Stream #0:0: Video: h264 (libx264) ([33][0][0][0] / 0x0021), yuv444p, 572x280, q=-1--1, 30 fps, 10000k tbn, 30 tbc
    Metadata:
      encoder         : Lavc56.26.100 libx264
Stream mapping:
  Stream #0:0 -&gt; #0:0 (rawvideo (native) -&gt; h264 (libx264))
Press [q] to stop, [?] for help
[swscaler @ 0000000003017fe0] Warning: data is not aligned! This can lead to a speedloss
frame=  406 fps= 50 q=-1.0 Lsize=     715kB time=00:00:34.06 bitrate= 171.9kbits/s
video:711kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.578083%
[libx264 @ 0000000003047200] frame I:4     Avg QP:20.40  size: 18550
[libx264 @ 0000000003047200] frame P:342   Avg QP:21.60  size:  1878
[libx264 @ 0000000003047200] frame B:60    Avg QP:19.97  size:   176
[libx264 @ 0000000003047200] consecutive B-frames: 75.9% 12.8%  1.5%  9.9%
[libx264 @ 0000000003047200] mb I  I16..4: 40.3% 25.6% 34.1%
[libx264 @ 0000000003047200] mb P  I16..4: 10.2%  4.6%  4.8%  P16..4:  7.6%  2.0%  0.6%  0.0%  0.0%    skip:70.1%
[libx264 @ 0000000003047200] mb B  I16..4:  0.6%  0.1%  0.3%  B16..8:  7.8%  0.4%  0.0%  direct: 0.1%  skip:90.7%  L0:42.8% L1:56.3% BI: 1.0%
[libx264 @ 0000000003047200] 8x8 transform intra:23.3% inter:53.3%
[libx264 @ 0000000003047200] coded y,u,v intra: 17.3% 7.5% 7.2% inter: 1.9% 0.4% 0.4%
[libx264 @ 0000000003047200] i16 v,h,dc,p: 20% 76%  3%  1%
[libx264 @ 0000000003047200] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 23% 18% 57%  0%  0%  0%  1%  0%  1%
[libx264 @ 0000000003047200] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 26% 45% 16%  1%  2%  2%  2%  2%  3%
[libx264 @ 0000000003047200] Weighted P-Frames: Y:0.0% UV:0.0%
[libx264 @ 0000000003047200] ref P L0: 62.9% 10.7% 14.1% 12.3%
[libx264 @ 0000000003047200] ref B L0: 85.2% 14.2%  0.6%
[libx264 @ 0000000003047200] ref B L1: 99.1%  0.9%
[libx264 @ 0000000003047200] kb/s:163.69
</code></pre>
<hr />
<p>Then I tried:</p>
<pre><code>ffmpeg -i test.avi -vf mpdecimate=hi=64*12:lo=64*2:frac=0.1,showinfo -vsync 2 test-out2.mp4
</code></pre>
<p>with the same results (in terms of how the video file appeared).</p>
<pre><code>frame=  411 fps=221 q=-1.0 Lsize=     716kB time=00:00:34.06 bitrate= 172.3kbits/s
video:712kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.589478%
[libx264 @ 0000000004e66b40] frame I:4     Avg QP:20.26  size: 18595
[libx264 @ 0000000004e66b40] frame P:343   Avg QP:21.49  size:  1876
[libx264 @ 0000000004e66b40] frame B:64    Avg QP:19.52  size:   170
[libx264 @ 0000000004e66b40] consecutive B-frames: 74.7% 13.1%  1.5% 10.7%
[libx264 @ 0000000004e66b40] mb I  I16..4: 41.6% 24.6% 33.8%
[libx264 @ 0000000004e66b40] mb P  I16..4: 10.2%  4.5%  4.8%  P16..4:  7.6%  2.0%  0.6%  0.0%  0.0%    skip:70.3%
[libx264 @ 0000000004e66b40] mb B  I16..4:  0.6%  0.1%  0.3%  B16..8:  7.5%  0.4%  0.0%  direct: 0.0%  skip:91.0%  L0:43.4% L1:55.6% BI: 0.9%
[libx264 @ 0000000004e66b40] 8x8 transform intra:23.1% inter:53.7%
[libx264 @ 0000000004e66b40] coded y,u,v intra: 17.4% 7.5% 7.2% inter: 1.9% 0.4% 0.4%
[libx264 @ 0000000004e66b40] i16 v,h,dc,p: 21% 75%  3%  1%
[libx264 @ 0000000004e66b40] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 23% 17% 58%  0%  0%  0%  1%  0%  1%
[libx264 @ 0000000004e66b40] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 26% 45% 16%  1%  2%  2%  2%  2%  3%
[libx264 @ 0000000004e66b40] Weighted P-Frames: Y:0.0% UV:0.0%
[libx264 @ 0000000004e66b40] ref P L0: 62.9% 10.6% 14.2% 12.3%
[libx264 @ 0000000004e66b40] ref B L0: 86.0% 13.3%  0.6%
[libx264 @ 0000000004e66b40] ref B L1: 99.1%  0.9%
[libx264 @ 0000000004e66b40] kb/s:164.04
</code></pre>

<editing>
How would I remove a specific pattern (say, every n-n+59th frame) of frames from a lengthy video file?
IDontWorkAtNASA
# How would I remove a specific pattern (say, every n-n+59th frame) of frames from a lengthy video file?

(Asked by: username_0 on 2015-02-27)

I have large video files of screen recordings which I created with Camtasia Recorder. The content I am recording only updates once per minute (1/60 fps), however Camtasia appears to require at least 1 fps for recording (quite silly, really). So that's what I did, and then I tried looking in Camtasia Studio to cut out the extra frames but it seems the only way to reduce the file size without compressing to a lossy format is to manually cut by hand 1 second segments throughout the entire file, but these files are too long to do this by hand (3 files, one of which is 24 hrs and the shortest is 8 hrs).
How would I cut all but 1 frame every 60 seconds from a video file?
Note that while the file is currently in the CamRec format, I can convert it to other formats if need be.
Attempts at using mpdecimate:

I have a 479mb "test.avi" video (you can download it here) which is 35 second uncompressed avi file of me moving some windows around on my desktop.
The first command I ran was:
ffmpeg -i test.avi -vf mpdecimate test-out.mp4

The resulting file (714kb) has 5-6 seconds of black, then the rest of the input video unaltered (but it is compressed).

Then I tried:
ffmpeg -i test.avi -vf mpdecimate -vsync 2 test-out.mp4

Which output a file (716kb) with seemingly the same results.
ffmpeg version N-70358-g047fd98 Copyright (c) 2000-2015 the FFmpeg developers
  built with gcc 4.9.2 (GCC)
  configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnu
tls --enable-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libfreetype --enable-libgme --enable-libgsm --enable-
libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-l
ibrtmp --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-aacenc --
enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --ena
ble-libxvid --enable-lzma --enable-decklink --enable-zlib
  libavutil      54. 19.100 / 54. 19.100
  libavcodec     56. 26.100 / 56. 26.100
  libavformat    56. 23.106 / 56. 23.106
  libavdevice    56.  4.100 / 56.  4.100
  libavfilter     5. 11.102 /  5. 11.102
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  1.100 /  1.  1.100
  libpostproc    53.  3.100 / 53.  3.100
Input #0, avi, from 'test.avi':
  Duration: 00:00:34.87, start: 0.000000, bitrate: 115403 kb/s
    Stream #0:0: Video: rawvideo, bgr24, 572x280, 115425 kb/s, 30 fps, 30 tbr, 30 tbn, 30 tbc
File 'test-out2.mp4' already exists. Overwrite ? [y/N] y
No pixel format specified, yuv444p for H.264 encoding chosen.
Use -pix_fmt yuv420p for compatibility with outdated media players.
[libx264 @ 0000000003047200] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
[libx264 @ 0000000003047200] profile High 4:4:4 Predictive, level 2.1, 4:4:4 8-bit
[libx264 @ 0000000003047200] 264 - core 144 r2525 40bb568 - H.264/MPEG-4 AVC codec - Copyleft 2003-2014 - http://www.videolan.org/x264.html - options:
 cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 dead
zone=21,11 fast_pskip=1 chroma_qp_offset=4 threads=12 lookahead_threads=2 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_in
tra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahe
ad=40 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
Output #0, mp4, to 'test-out2.mp4':
  Metadata:
    encoder         : Lavf56.23.106
    Stream #0:0: Video: h264 (libx264) ([33][0][0][0] / 0x0021), yuv444p, 572x280, q=-1--1, 30 fps, 10000k tbn, 30 tbc
    Metadata:
      encoder         : Lavc56.26.100 libx264
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> h264 (libx264))
Press [q] to stop, [?] for help
[swscaler @ 0000000003017fe0] Warning: data is not aligned! This can lead to a speedloss
frame=  406 fps= 50 q=-1.0 Lsize=     715kB time=00:00:34.06 bitrate= 171.9kbits/s
video:711kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.578083%
[libx264 @ 0000000003047200] frame I:4     Avg QP:20.40  size: 18550
[libx264 @ 0000000003047200] frame P:342   Avg QP:21.60  size:  1878
[libx264 @ 0000000003047200] frame B:60    Avg QP:19.97  size:   176
[libx264 @ 0000000003047200] consecutive B-frames: 75.9% 12.8%  1.5%  9.9%
[libx264 @ 0000000003047200] mb I  I16..4: 40.3% 25.6% 34.1%
[libx264 @ 0000000003047200] mb P  I16..4: 10.2%  4.6%  4.8%  P16..4:  7.6%  2.0%  0.6%  0.0%  0.0%    skip:70.1%
[libx264 @ 0000000003047200] mb B  I16..4:  0.6%  0.1%  0.3%  B16..8:  7.8%  0.4%  0.0%  direct: 0.1%  skip:90.7%  L0:42.8% L1:56.3% BI: 1.0%
[libx264 @ 0000000003047200] 8x8 transform intra:23.3% inter:53.3%
[libx264 @ 0000000003047200] coded y,u,v intra: 17.3% 7.5% 7.2% inter: 1.9% 0.4% 0.4%
[libx264 @ 0000000003047200] i16 v,h,dc,p: 20% 76%  3%  1%
[libx264 @ 0000000003047200] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 23% 18% 57%  0%  0%  0%  1%  0%  1%
[libx264 @ 0000000003047200] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 26% 45% 16%  1%  2%  2%  2%  2%  3%
[libx264 @ 0000000003047200] Weighted P-Frames: Y:0.0% UV:0.0%
[libx264 @ 0000000003047200] ref P L0: 62.9% 10.7% 14.1% 12.3%
[libx264 @ 0000000003047200] ref B L0: 85.2% 14.2%  0.6%
[libx264 @ 0000000003047200] ref B L1: 99.1%  0.9%
[libx264 @ 0000000003047200] kb/s:163.69


Then I tried:
ffmpeg -i test.avi -vf mpdecimate=hi=64*12:lo=64*2:frac=0.1,showinfo -vsync 2 test-out2.mp4

with the same results (in terms of how the video file appeared).
frame=  411 fps=221 q=-1.0 Lsize=     716kB time=00:00:34.06 bitrate= 172.3kbits/s
video:712kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.589478%
[libx264 @ 0000000004e66b40] frame I:4     Avg QP:20.26  size: 18595
[libx264 @ 0000000004e66b40] frame P:343   Avg QP:21.49  size:  1876
[libx264 @ 0000000004e66b40] frame B:64    Avg QP:19.52  size:   170
[libx264 @ 0000000004e66b40] consecutive B-frames: 74.7% 13.1%  1.5% 10.7%
[libx264 @ 0000000004e66b40] mb I  I16..4: 41.6% 24.6% 33.8%
[libx264 @ 0000000004e66b40] mb P  I16..4: 10.2%  4.5%  4.8%  P16..4:  7.6%  2.0%  0.6%  0.0%  0.0%    skip:70.3%
[libx264 @ 0000000004e66b40] mb B  I16..4:  0.6%  0.1%  0.3%  B16..8:  7.5%  0.4%  0.0%  direct: 0.0%  skip:91.0%  L0:43.4% L1:55.6% BI: 0.9%
[libx264 @ 0000000004e66b40] 8x8 transform intra:23.1% inter:53.7%
[libx264 @ 0000000004e66b40] coded y,u,v intra: 17.4% 7.5% 7.2% inter: 1.9% 0.4% 0.4%
[libx264 @ 0000000004e66b40] i16 v,h,dc,p: 21% 75%  3%  1%
[libx264 @ 0000000004e66b40] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 23% 17% 58%  0%  0%  0%  1%  0%  1%
[libx264 @ 0000000004e66b40] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 26% 45% 16%  1%  2%  2%  2%  2%  3%
[libx264 @ 0000000004e66b40] Weighted P-Frames: Y:0.0% UV:0.0%
[libx264 @ 0000000004e66b40] ref P L0: 62.9% 10.6% 14.2% 12.3%
[libx264 @ 0000000004e66b40] ref B L0: 86.0% 13.3%  0.6%
[libx264 @ 0000000004e66b40] ref B L1: 99.1%  0.9%
[libx264 @ 0000000004e66b40] kb/s:164.04

**Tags:** editing


---

## 1 answers

### Answer by username_1 on 2015-03-01. Score: 2 | Accepted answer

FFmpeg has a [framestep](http://www.ffmpeg.org/ffmpeg-all.html#framestep) filter to take every `n`th frame.

There's also `mpdecimate`, which outputs a frame whenever the input frame is different enough from the previous frame. (so if exactly every 60th frame isn't perfect, you could use `mpdecimate` instead to detect the changes, and make a potentially VFR video.)

I didn't test this command; post a comment if I screwed it up:

`ffmpeg -i in.camrec -vf framestep=60 -r 1/60 -codec copy -map 0 -c:v libx264 -preset medium -crf 16 -movflags +faststart -vsync 2 out.mp4`

Or use `out.mkv` if you like matroska better than the mp4 container.

`copy` (stream copy) won't work while dropping frames, I think even for an intra-only codec. So your output has to be encoded to some codec. My example uses lossy h.264, but with the quality cranked so high it should be transparent. You could use lossless h.264 (`-preset ultrafast -qp 0`), `-c:v utvideo`, or whatever else you like.

`-vsync 2` turns on VFR output mode, which for some reason isn't the default in mp4. (but it is in mkv). You'll want that if you use `mpdecimate`, but you won't need it for `framestep`.

A quick google didn't tell me if camrec is already lossy or not. If it's lossy, then there's no way to get a file as small but with the same quality as just keeping every 60th CamRec frame without decoding them. (assuming there's an intra-only frame at the point you want one, if the format has any non-intra frames.)

With mjpeg, you can turn a video into a directory of images without decoding, and select whichever ones you want, and mux them up again. Since camrec frames probably aren't a stand-alone image format, it's unlikely there's something similar, so you just have to use video tools. Like I said, don't think ffmpeg can do clever things like frame dropping without decompressing, even for intra-only codecs. Other tools might exist that can do that, for some codecs.

If it's lossless, then it just takes more CPU time to decode / re-encode to a new lossless format.

edit: more about mpdecimate:
As noted in the comments, I added some stats logging to mpdecimate.  
`git pull https://github.com/pcordes/FFmpeg.git mpdecimate`  
and then build ffmpeg as usual.

Then run `ffmpeg -v debug ...`.  
Or `ffplav -v debug -vf mpdecimate input.avi`

Testing mpdecimate threshold settings with ffplay is a lot faster than making an encode.

> **Comments:**
> **username_1**: Oh btw, camrec appears to be a container format.  It can hold a few different codecs.  I haven't checked that ffmpeg can decode them all, but apparently you can record in xvid or h.264 in camrec, unless I misread a random forum comment.  
> **username_0**: I tried both commands but neither worked. It seems `mpdecimate` is really what I'm looking for, but every time I try to run the command I get either an unchanged file, or a purely black file that is slightly longer than the input file. I converted my camrec file to a lossless AVI file (since ff seems to have trouble with it) and ran this: `ffmpeg -i "capture-1.avi" -vf "mpdecimate" -vsync 2 "capture-1.mp4"`, also without the `-vsync 2` part, to no avail. Am I doing this wrong?  
> **username_0**: The difference in the frames is substantial and should be triggering the drops, but in case it isn't I tried altering the command parameters with little success. The [documentation](https://ffmpeg.org/ffmpeg-filters.html#mpdecimate) unfortunately offers no real guidance on how the parameters are entered.  
> **username_1**: That looks like the right command line. What different options did you try for mpdecimate?  The options set thresholds for 8x8 SAD of blocks on all planes (luma and chroma).  (http://en.wikipedia.org/wiki/Sum_of_absolute_differences).  Is there a blinking cursor somewhere on the screen that's triggering the `hi` threshold?  Maybe crank it really high, and depend on the `lo` threshold to detect when large areas of the screen change.  
> **username_1**: See my edit to my answer.  Last time I used mpdecimate, I added some debug prints to it.  If can and want to compile ffmpeg from source, grab my mpdecimate branch of https://github.com/pcordes/FFmpeg/tree/mpdecimate.  (I just rebased it to current git master, so you should be able to `git pull https://github.com/pcordes/FFmpeg.git mpdecimate` in an existing git clone of ffmpeg.)  
> **username_0**: I retried the commands, I noticed the files I thought were "purely black" were actually mostly black, with some of my input video at the end. But it doesn't seem like all the frames were dropped (some were), so I would need to increase the sensitivity. Do you know how I would do that? I don't have the tools to recompile ffmpeg, sorry.  
> **username_1**: No worries.  Black frames sounds like a really weird symptom.  `mpdecimate` should make your video appear to freeze for a bit if it does anything at all.  IDK if it even can drop the first frame.  Try  `ffplay -vf mpdecimate,showinfo`.  You can tell it's dropping frames when showinfo isn't printing lines of output.  
> **username_1**: If the frames you want to drop are really identical, you can try `-vf mpdecimate=hi=64*12:lo=64*2:frac=0.1,showinfo`.  as http://www.ffmpeg.org/ffmpeg-all.html#mpdecimate explains, one 8x8 block where the sum of differences exceeds `hi` will result in an output frame.  Same when more than `frac` fraction of the 8x8 blocks have more than `lo` difference.  So if there's a blinking cursor, that will trigger `hi` every time unless you crank it all the way up and just depend on `lo`.  
> **username_1**: Next time you test it, can you copy/paste FULL command line output from ffmpeg into your question?  There might be something else going wrong leading to black frames.  Like I said, you should just see an old frame stay there for ages if mpdecimate is dropping more than it should.  (Maybe your input video has black frames?  Or ffmpeg isn't decoding it perfectly?)  
> **username_0**: Ok done. In terms of black frames, I remember Camtasia prompting what color background I wanted the video to have, black being the default. I didn't understand it, since I was screen recording (there should never be a "background" showing, but maybe it's just a weird format requirement).  
> **username_1**: 3 things: What do you get without `mpdecimate`?  Still black frames at the beginning?  
> **username_1**: Try with `ffmpeg -v debug`.  I'd forgotten mpdecimate does have debug-logging code to print WHEN it's dropping frames; my patch just added info on whether `hi` or `frac` / `lo` was the reason for allowing a frame through.  (It will spew a crapton of debug output from everything else, too, since there's no per-component logging).  You didn't post output from the `mpdecimate,showinfo`, just the x264 encoder stats after it got to the end.  I could see that it allowed 411 frames through, instead of 406 from your run with mpdecimate default settings.  (of 35s*30fps = about 1050 frames.)  
> **username_1**: and the 3rd thing: I tried to download your original from dropbox, but it didn't work.  I get the captcha, but no download starts at all.  Since your ffmpeg output indicates it's really uncompressed, not just lossless, you could make it a LOT smaller but still bit-for-bit identical data with `ffmpeg -i raw.avi -c:v libx264rgb -qp 0 -preset ultrafast  lossless.mkv`.  Then upload that.  (libx264rgb since I see your input is raw RGB video.)  No need to try mpdecimate with that input, results will be identical.  Filters happen after video decoding.  
> **username_1**: Oh also, your video is only 572x280.  Do you normally record at such low rez?  Doesn't that make it hard to read text?  Anyway, this might be causing changes in the input to happen on smaller scales than the 8x8 blocks that mpdecimate checks.  
> **username_0**: I *really* appreciate all your help with this (seriously), but I think this is simply outside my expertise (psychologist, sadly). I'm burning taxpayer dollars and getting nowhere fast, so I'm just going to re-record using different software capable of 1 frame-per-minute recording. Thanks again for all your help.  
> **username_1**: no worries.  mpdecimate isn't the most user-friendly filter.  

---

