Answers.Body: <h1>Re-muxing only</h1>
  
  <p>Use <a href="http://ffmpeg.org/ffmpeg.html#Stream-copy" rel="noreferrer">stream copy</a> mode to just re-mux instead of re-encode:</p>
  
  <pre><code>ffmpeg -ss 01:07:29 -i input -codec copy -map 0 -to 01:08:05 fight.avi
  </code></pre>
  
  <ul>
  <li><p>Using <code>-ss</code> as an input option can be faster than using it as an output option, but it may not be as accurate.</p></li>
  <li><p><code>-codec copy</code> will <a href="http://ffmpeg.org/ffmpeg.html#Stream-copy" rel="noreferrer">stream copy</a> (no re-encoding). Default behavior, if <code>-codec copy</code> is omitted, is to re-encode, and as you've noticed the default encoding settings for most encoders are not optimal (they used to be a decade ago).</p></li>
  <li><p>Default <a href="http://ffmpeg.org/ffmpeg.html#Stream-selection" rel="noreferrer">stream selection</a> is to select only one stream per stream type (video, audio, subtitles, data, etc). <code>-map 0</code> will ensure all streams are copied in case there are multiples of each type. That being said, your input only has two different streams, so it is actually not needed here.</p></li>
  <li><p>Development of <code>ffmpeg</code> is very active, so it is important to use a recent build if possible. See the <a href="http://ffmpeg.org/download.html" rel="noreferrer">FFmpeg Download</a> page for several options.</p></li>
  </ul>
  
  <hr>
  
  <h1>If you must re-encode</h1>
  
  <h2><code>-crf</code></h2>
  
  <p>You can target a "visually lossless" quality level using the encoder libx264 with the <code>-crf</code> option. CRF is just about as close as you can get to a "constant quality" option: 0 is lossless (but usually results in huge files), ~18 is usually considered to be visually lossless or nearly so, 23 is the default, and 51 is worst.</p>
  
  <h2><code>-preset</code></h2>
  
  <p>The encoding speed to compression (quality per file size) ratio. Basically use the slowest preset you have patience for: <code>ultrafast</code>, <code>superfast</code>, <code>veryfast</code>, <code>faster</code>, <code>fast</code>, <code>medium</code>, <code>slow</code>, <code>slower</code>, <code>veryslow</code>.</p>
  
  <pre><code>ffmpeg -i input -codec:v libx264 -crf 23 -preset medium -ss 01:07:29 -to 01:08:05 output
  </code></pre>
  
  <hr>
  
  <h1>Also see</h1>
  
  <ul>
  <li><a href="https://trac.ffmpeg.org/wiki/Encode/H.264" rel="noreferrer">FFmpeg H.264 Encoding Guide</a></li>
  <li><a href="https://trac.ffmpeg.org/wiki/Seeking%20with%20FFmpeg" rel="noreferrer">Seeking with FFmpeg</a></li>
  </ul>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-06-19T16:42:53.007Z
Answers.LastActivityDate: 2014-06-19T17:56:47.730Z
Answers.LastEditDate: 2014-06-19T17:56:47.730Z
Answers.UserDisplayName: llogan
Answers.Body: <p>You are re-encoding the video rather than cutting out a portion of the stream.  Any re-encode is going to produce quality loss, particularly when you cut the data rate to less than 1/11th of the original data rate.  </p>
  
  <p>If you want to cut out a portion of the video, you need to use a tool like VirtualDUB to actually extract a portion of the actual video stream and put it in a new container without re-encoding.  Note that there will be limitations to where you can cut like this since you will need to start at the beginning of a group of pictures.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-06-19T17:00:09.640Z
Answers.Text: Where am I cutting data rate to 1/11th?
Answers.UserDisplayName: Dims
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-06-19T17:02:07.633Z
Answers.Text: Your input stream is 2295 kb/s.  Your output stream is 200 kb/s.  It is probably a default setting since you aren't specifying a bitrate.
Answers.UserDisplayName: AJ Henderson
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-06-19T17:03:27.040Z
Answers.Text: Can I just conserve bitrate?
Answers.UserDisplayName: Dims
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-06-19T17:04:03.130Z
Answers.Text: I mean that copy operation may cut at inprecise moments
Answers.UserDisplayName: Dims
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-06-19T17:04:27.773Z
Answers.Text: So I agree with reencoding if small decreasing of quality
Answers.UserDisplayName: Dims
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-06-19T17:06:47.820Z
Answers.Text: @Dims - at a consumption quality level like the video is already at, pretty much any re-encode is going to make a reasonably significant quality loss.  You would actually have to increase the file size a fair bit to try to come close to preserving quality.
Answers.UserDisplayName: AJ Henderson
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-06-19T17:07:46.107Z
Answers.Text: Which file size? Output? I agree with any file size.
Answers.UserDisplayName: Dims
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-06-19T17:10:32.357Z
Answers.Text: If you really want to re-encode rather than stream copy (stream copy would likely be accurate to within half a second), then you could probably preserve quality pretty well if you try somewhere around 3,000 or 3,500 kb/s for your encoding.  I'd try starting there and play around with some different data rates to find the best trade off between file size and video quality.
Answers.UserDisplayName: AJ Henderson
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-06-19T15:31:48.383Z
Answers.LastActivityDate: 2014-06-19T15:31:48.383Z
Answers.UserDisplayName: AJ Henderson
Body: <p>I have tried to cut video with the following command</p>
  
  <pre><code>ffmpeg -i "Вспомнить все (Total Recall, 1990).avi"  -ss 01:07:29 -to 01:08:05 fight.avi
  </code></pre>
  
  <p>Output:</p>
  
  <pre><code>Input #0, avi, from '╨Т╤Б╨┐╨╛╨╝╨╜╨╕╤В╤М ╨▓╤Б╨╡ (Total Recall, 1990).avi':
    Metadata:
      encoder         : VirtualDubMod 1.5.10.2 (build 2540/release)
      artist          : Menen
    Duration: 01:53:33.69, start: 0.000000, bitrate: 3660 kb/s
      Stream #0:0: Video: mpeg4 (Advanced Simple Profile) (XVID / 0x44495658), yuv420p, 704x384 [SAR 1:1 DAR 11:6], 2295 kb/s, 23.98 fps, 23.98 tbr, 23.
  98 tbn, 23.98 tbc
      Stream #0:1: Audio: ac3 ([0] [0][0] / 0x2000), 48000 Hz, 5.1(side), fltp, 448 kb/s
      Stream #0:2: Audio: ac3 ([0] [0][0] / 0x2000), 48000 Hz, 5.1(side), fltp, 448 kb/s
      Stream #0:3: Audio: ac3 ([0] [0][0] / 0x2000), 48000 Hz, 5.1(side), fltp, 448 kb/s
  File 'fight.avi' already exists. Overwrite ? [y/N] y
  Output #0, avi, to 'fight.avi':
    Metadata:
      IART            : Menen
      ISFT            : Lavf55.43.100
      Stream #0:0: Video: mpeg4 (FMP4 / 0x34504D46), yuv420p, 704x384 [SAR 1:1 DAR 11:6], q=2-31, 200 kb/s, 23.98 fps, 23.98 tbn, 23.98 tbc
      Metadata:
        encoder         : Lavc55.67.100 mpeg4
      Stream #0:1: Audio: mp3 (libmp3lame) (U[0][0][0] / 0x0055), 48000 Hz, stereo, fltp
      Metadata:
        encoder         : Lavc55.67.100 libmp3lame
  Stream mapping:
    Stream #0:0 -&gt; #0:0 (mpeg4 (native) -&gt; mpeg4 (native))
    Stream #0:1 -&gt; #0:1 (ac3 (native) -&gt; mp3 (libmp3lame))
  Press [q] to stop, [?] for help
  frame=  863 fps= 20 q=31.0 Lsize=    2690kB time=00:00:36.00 bitrate= 612.1kbits/s
  video:2061kB audio:563kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 2.500957%
  </code></pre>
  
  <p>The resulting video has obviously worse quality, with apparent big MPEG squares visible</p>
  
  <p><div class="youtube-embed"><div>
                  <iframe width="640px" height="395px" src="https://www.youtube.com/embed/SzJGrE3ZCo0?start=0"></iframe>
              </div></div></p>
  
  <p>Why?</p>
  
  <p>How to avoid?</p>
  
  <p><strong>UPDATE</strong></p>
  
  <p>Even if re-encoding, then why so drastical change? Can we re-encode so that it will be nearly invisible degrading of quality?</p>
  
  <p><strong>UPDATE 2</strong></p>
  
  <p>I guess if I use <code>-codec copy</code> then I will be unable to cut at precise moment. Moment precision is a priority. So I agree with quality loss but it should not be so drastical.</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-04-16T08:14:19.530Z
Comments.Text: I don't think ffmpeg supports this, but you can get nearly the best of both options by using the original stream (-codec copy) from the nearest keyframe, and re-encoding only the frames between the cut-point and that keyframe.  This only works if you have an encoder that can produce output compatible with the original stream, but you can use a high bitrate for the short segment to avoid quality loss.
Comments.UserDisplayName: Peter Cordes
Tags: <ffmpeg>
Title: Why does quality degrade so much if just cutting video with ffmpeg?
UserDisplayName: Dims
ThreadText: # Why does quality degrade so much if just cutting video with ffmpeg?
  
  (Asked by: username_0 on 2014-06-19)
  
  I have tried to cut video with the following command
  
  ```
  ffmpeg -i "Вспомнить все (Total Recall, 1990).avi"  -ss 01:07:29 -to 01:08:05 fight.avi
  
  ```
  
  Output:
  
  ```
  Input #0, avi, from '╨Т╤Б╨┐╨╛╨╝╨╜╨╕╤В╤М ╨▓╤Б╨╡ (Total Recall, 1990).avi':
    Metadata:
      encoder         : VirtualDubMod 1.5.10.2 (build 2540/release)
      artist          : Menen
    Duration: 01:53:33.69, start: 0.000000, bitrate: 3660 kb/s
      Stream #0:0: Video: mpeg4 (Advanced Simple Profile) (XVID / 0x44495658), yuv420p, 704x384 [SAR 1:1 DAR 11:6], 2295 kb/s, 23.98 fps, 23.98 tbr, 23.
  98 tbn, 23.98 tbc
      Stream #0:1: Audio: ac3 ([0] [0][0] / 0x2000), 48000 Hz, 5.1(side), fltp, 448 kb/s
      Stream #0:2: Audio: ac3 ([0] [0][0] / 0x2000), 48000 Hz, 5.1(side), fltp, 448 kb/s
      Stream #0:3: Audio: ac3 ([0] [0][0] / 0x2000), 48000 Hz, 5.1(side), fltp, 448 kb/s
  File 'fight.avi' already exists. Overwrite ? [y/N] y
  Output #0, avi, to 'fight.avi':
    Metadata:
      IART            : Menen
      ISFT            : Lavf55.43.100
      Stream #0:0: Video: mpeg4 (FMP4 / 0x34504D46), yuv420p, 704x384 [SAR 1:1 DAR 11:6], q=2-31, 200 kb/s, 23.98 fps, 23.98 tbn, 23.98 tbc
      Metadata:
        encoder         : Lavc55.67.100 mpeg4
      Stream #0:1: Audio: mp3 (libmp3lame) (U[0][0][0] / 0x0055), 48000 Hz, stereo, fltp
      Metadata:
        encoder         : Lavc55.67.100 libmp3lame
  Stream mapping:
    Stream #0:0 -> #0:0 (mpeg4 (native) -> mpeg4 (native))
    Stream #0:1 -> #0:1 (ac3 (native) -> mp3 (libmp3lame))
  Press [q] to stop, [?] for help
  frame=  863 fps= 20 q=31.0 Lsize=    2690kB time=00:00:36.00 bitrate= 612.1kbits/s
  video:2061kB audio:563kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 2.500957%
  
  ```
  
  The resulting video has obviously worse quality, with apparent big MPEG squares visible
  
  Why?
  
  How to avoid?
  
  **UPDATE**
  
  Even if re-encoding, then why so drastical change? Can we re-encode so that it will be nearly invisible degrading of quality?
  
  **UPDATE 2**
  
  I guess if I use `-codec copy` then I will be unable to cut at precise moment. Moment precision is a priority. So I agree with quality loss but it should not be so drastical.
  
  **Tags:** ffmpeg
  
  > **Comments:**
  > **username_1**: I don't think ffmpeg supports this, but you can get nearly the best of both options by using the original stream (-codec copy) from the nearest keyframe, and re-encoding only the frames between the cut-point and that keyframe.  This only works if you have an encoder that can produce output compatible with the original stream, but you can use a high bitrate for the short segment to avoid quality loss.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2014-06-19. Score: 10
  
  # Re-muxing only
  
  Use [stream copy](http://ffmpeg.org/ffmpeg.html#Stream-copy) mode to just re-mux instead of re-encode:
  
  ```
  ffmpeg -ss 01:07:29 -i input -codec copy -map 0 -to 01:08:05 fight.avi
  
  ```
  
  * Using `-ss` as an input option can be faster than using it as an output option, but it may not be as accurate.
  * `-codec copy` will [stream copy](http://ffmpeg.org/ffmpeg.html#Stream-copy) (no re-encoding). Default behavior, if `-codec copy` is omitted, is to re-encode, and as you've noticed the default encoding settings for most encoders are not optimal (they used to be a decade ago).
  * Default [stream selection](http://ffmpeg.org/ffmpeg.html#Stream-selection) is to select only one stream per stream type (video, audio, subtitles, data, etc). `-map 0` will ensure all streams are copied in case there are multiples of each type. That being said, your input only has two different streams, so it is actually not needed here.
  * Development of `ffmpeg` is very active, so it is important to use a recent build if possible. See the [FFmpeg Download](http://ffmpeg.org/download.html) page for several options.
  
  ---
  
  # If you must re-encode
  
  ## `-crf`
  
  You can target a "visually lossless" quality level using the encoder libx264 with the `-crf` option. CRF is just about as close as you can get to a "constant quality" option: 0 is lossless (but usually results in huge files), ~18 is usually considered to be visually lossless or nearly so, 23 is the default, and 51 is worst.
  
  ## `-preset`
  
  The encoding speed to compression (quality per file size) ratio. Basically use the slowest preset you have patience for: `ultrafast`, `superfast`, `veryfast`, `faster`, `fast`, `medium`, `slow`, `slower`, `veryslow`.
  
  ```
  ffmpeg -i input -codec:v libx264 -crf 23 -preset medium -ss 01:07:29 -to 01:08:05 output
  
  ```
  
  ---
  
  # Also see
  
  * [FFmpeg H.264 Encoding Guide](https://trac.ffmpeg.org/wiki/Encode/H.264)
  * [Seeking with FFmpeg](https://trac.ffmpeg.org/wiki/Seeking%20with%20FFmpeg)
  
  
  ---
  
  ### Answer by username_3 on 2014-06-19. Score: 3
  
  You are re-encoding the video rather than cutting out a portion of the stream. Any re-encode is going to produce quality loss, particularly when you cut the data rate to less than 1/11th of the original data rate.
  
  If you want to cut out a portion of the video, you need to use a tool like VirtualDUB to actually extract a portion of the actual video stream and put it in a new container without re-encoding. Note that there will be limitations to where you can cut like this since you will need to start at the beginning of a group of pictures.
  
  > **Comments:**
  > **username_0**: Where am I cutting data rate to 1/11th?  
  > **username_3**: Your input stream is 2295 kb/s.  Your output stream is 200 kb/s.  It is probably a default setting since you aren't specifying a bitrate.  
  > **username_0**: Can I just conserve bitrate?  
  > **username_0**: I mean that copy operation may cut at inprecise moments  
  > **username_0**: So I agree with reencoding if small decreasing of quality  
  > **username_3**: @username_0 - at a consumption quality level like the video is already at, pretty much any re-encode is going to make a reasonably significant quality loss.  You would actually have to increase the file size a fair bit to try to come close to preserving quality.  
  > **username_0**: Which file size? Output? I agree with any file size.  
  > **username_3**: If you really want to re-encode rather than stream copy (stream copy would likely be accurate to within half a second), then you could probably preserve quality pretty well if you try somewhere around 3,000 or 3,500 kb/s for your encoding.  I'd try starting there and play around with some different data rates to find the best trade off between file size and video quality.  
  
  ---
  
  