Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-01T18:45:19.700Z
Answers.Text: 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.
Answers.UserDisplayName: Peter Cordes
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-02T19:23:57.473Z
Answers.Text: 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?
Answers.UserDisplayName: IDontWorkAtNASA
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-02T19:45:47.127Z
Answers.Text: 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.
Answers.UserDisplayName: IDontWorkAtNASA
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-03T02:25:45.370Z
Answers.Text: 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.
Answers.UserDisplayName: Peter Cordes
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-03T03:23:52.543Z
Answers.Text: 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.)
Answers.UserDisplayName: Peter Cordes
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-03T18:50:30.357Z
Answers.Text: 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.
Answers.UserDisplayName: IDontWorkAtNASA
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-03T23:18:51.373Z
Answers.Text: 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.
Answers.UserDisplayName: Peter Cordes
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-03T23:24:34.290Z
Answers.Text: 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`.
Answers.UserDisplayName: Peter Cordes
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-03T23:42:15.457Z
Answers.Text: 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?)
Answers.UserDisplayName: Peter Cordes
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-04T20:39:17.170Z
Answers.Text: 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).
Answers.UserDisplayName: IDontWorkAtNASA
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-05T17:33:49.187Z
Answers.Text: 3 things: What do you get without `mpdecimate`?  Still black frames at the beginning?
Answers.UserDisplayName: Peter Cordes
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-05T17:42:49.313Z
Answers.Text: 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.)
Answers.UserDisplayName: Peter Cordes
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-05T17:45:46.983Z
Answers.Text: 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.
Answers.UserDisplayName: Peter Cordes
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-05T17:50:08.417Z
Answers.Text: 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.
Answers.UserDisplayName: Peter Cordes
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-05T18:46:38.673Z
Answers.Text: 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.
Answers.UserDisplayName: IDontWorkAtNASA
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-05T18:48:32.643Z
Answers.Text: no worries.  mpdecimate isn't the most user-friendly filter.
Answers.UserDisplayName: Peter Cordes
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-01T02:00:01.127Z
Answers.LastActivityDate: 2015-03-03T03:28:01.740Z
Answers.LastEditDate: 2015-03-03T03:28:01.740Z
Answers.UserDisplayName: Peter Cordes
Body: <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>
  
Tags: <editing>
Title: How would I remove a specific pattern (say, every n-n+59th frame) of frames from a lengthy video file?
UserDisplayName: IDontWorkAtNASA
ThreadText: # 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](http://www.filedropper.com/test_71)) 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](http://www.filedropper.com/test-out) (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](http://www.filedropper.com/test-out2) (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.  
  
  ---
  
  