<p>As you are hardcoding subtitles, the video (with the subtitles added) <strong>will be re-encoded</strong>. </p>

<p>You can use the CRF rate control method to modulate the quality of the output.</p>

<p>So, start with</p>

<pre><code>ffmpeg -i grdedFinal.mov -vf subtitles=portSbs.srt -crf 18 -c:a copy gradedFinalwithSubs.mov
</code></pre>

<p>If the quality's not acceptable, lower that value till it is - in exchange for a larger file. Of course, don't decide based on file <em>size</em> but on visual quality. x264 is very good at compressing video while maintaining subjectively perceived quality.</p>

CC BY-SA 3.0
2016-01-31T12:36:45.760Z
Thanks very much, I had a look [here](https://trac.ffmpeg.org/wiki/Encode/H.264#crf) and put `crf 0`.
Konrad
CC BY-SA 3.0
2016-01-31T12:37:36.927Z
Unnecessary, but that's your choice. Use edited command for audio passthrough.
Gyan
CC BY-SA 3.0
2016-01-31T12:45:55.273Z
So what `crf` would be optimal for lack of quality loss? Side question, the created file does not open in QuickTime but it runs in VLC so I'm guessing that the file is no longer `mov` but `avi` for example?
Konrad
CC BY-SA 3.0
2016-01-31T12:49:57.810Z
For being mathematically lossless? None. For being visually lossless, `18` is generally transparent, but YMMV. Try `-crf 1` - I think ffmpeg has chosen a pixel format for CRF 0 that QT doesn't work with.
Gyan
CC BY-SA 3.0
2016-01-31T12:29:49.350Z
2016-01-31T12:36:47.903Z
2016-01-31T12:36:47.903Z
Gyan
<p>After solving on problem I cam coming to a next one. After adding subtitles, discussed <a href="https://video.stackexchange.com/q/17543/12686">here</a>, with the command:</p>

<pre><code>ffmpeg -i grdedFinal.mov -vf subtitles=portSbs.srt gradedFinalwithSubs.mov
</code></pre>

<p>the quality of the generated file significantly decreased. The original file was of size <strong>1,5GB</strong> whereas the resulting file was of size <strong>~300MB</strong>. The subtitles are added correctly but the compression is unnecessary. In a word I would like for the <strong>FFmpeg</strong> to add subtitless and do only that leaving the sound and picture quality untouched.</p>

<ffmpeg><conversion><compression><subtitles>
Loss of quality while adding subtitle via FFmpeg
Konrad
# Loss of quality while adding subtitle via FFmpeg

(Asked by: username_0 on 2016-01-31)

After solving on problem I cam coming to a next one. After adding subtitles, discussed here, with the command:
ffmpeg -i grdedFinal.mov -vf subtitles=portSbs.srt gradedFinalwithSubs.mov

the quality of the generated file significantly decreased. The original file was of size 1,5GB whereas the resulting file was of size ~300MB. The subtitles are added correctly but the compression is unnecessary. In a word I would like for the FFmpeg to add subtitless and do only that leaving the sound and picture quality untouched.

**Tags:** ffmpeg, conversion, compression, subtitles


---

## 1 answers

### Answer by username_1 on 2016-01-31. Score: 6 | Accepted answer

As you are hardcoding subtitles, the video (with the subtitles added) will be re-encoded. 
You can use the CRF rate control method to modulate the quality of the output.
So, start with
ffmpeg -i grdedFinal.mov -vf subtitles=portSbs.srt -crf 18 -c:a copy gradedFinalwithSubs.mov

If the quality's not acceptable, lower that value till it is - in exchange for a larger file. Of course, don't decide based on file size but on visual quality. x264 is very good at compressing video while maintaining subjectively perceived quality.

> **Comments:**
> **username_0**: Thanks very much, I had a look [here](https://trac.ffmpeg.org/wiki/Encode/H.264#crf) and put `crf 0`.  
> **username_1**: Unnecessary, but that's your choice. Use edited command for audio passthrough.  
> **username_0**: So what `crf` would be optimal for lack of quality loss? Side question, the created file does not open in QuickTime but it runs in VLC so I'm guessing that the file is no longer `mov` but `avi` for example?  
> **username_1**: For being mathematically lossless? None. For being visually lossless, `18` is generally transparent, but YMMV. Try `-crf 1` - I think ffmpeg has chosen a pixel format for CRF 0 that QT doesn't work with.  

---

