Answers.Body: <p>The CRF 22 sample looks fine to me at 1x size. The lower the resolution, the greater the impact a high quantization parameter will have. Suggest you stick to values &lt; 24.</p>
  
  <p>Since your video images are mostly static, slower presets won't be worth the extra time (unless you need to squeeze every bit of compression efficiency).</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-04T06:19:56.447Z
Answers.LastActivityDate: 2018-01-04T06:19:56.447Z
Answers.UserDisplayName: Gyan
Body: <p>I'm using ffmpeg libx265 to encode some fun gameplay clips from old games.
  Typically this means low resolution pixel art, with small sprites moving against a static or scrolling background.
  The default settings for the x265 codec are poorly suited for this and give large areas of blocky noise artifacts around the moving sprites. 
  I can of course just increase bitrate, e.g. "crf=22" and allow more computation time "-preset slow" to reduce the problem, but I guess there are better ways to tune the codec parameters to better deal with these types of visuals.</p>
  
  <p>Any suggestions?</p>
  
  <p>EDIT: <em>hmm, I need >10 rep to be allowed to post more than two links. So I'm deleting the old examples and posting updated better examples.</em></p>
  
  <p>Adding better examples (now with source)
  Very simple graphics. Both sprites moving against static background and scrolling background. The major distortions are found when sprites are moving on static background. The noise distortions can extend quite far around the sprites: e.g. @15s</p>
  
  <p>Download the files and view in fullscreen. The gdrive viewer will reencode and destroy.</p>
  
  <p>source (x264 ultrafast crf=0)<br>
  4.4MB <a href="https://goo.gl/VjRhvh" rel="nofollow noreferrer">https://goo.gl/VjRhvh</a></p>
  
  <p>ffmpeg -i source.mkv -libx265 -preset medium -libx265-params "crf=28" out.mkv<br>
  152KB <a href="https://goo.gl/bQDmxe" rel="nofollow noreferrer">https://goo.gl/bQDmxe</a></p>
  
  <p>ffmpeg -i source.mkv -libx265 -preset veryslow -libx265-params "crf=22" out.mkv<br>
  216KB <a href="https://goo.gl/rGtNAT" rel="nofollow noreferrer">https://goo.gl/rGtNAT</a></p>
  
  <p>This one looks a bit better due to higher bitrate and more compute time. Noise artifacts are smaller, but still disturbing.</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-06-09T14:50:57.133Z
Comments.Text: Can you post a short sample - source and result?
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-06-09T16:03:05.473Z
Comments.Text: added examples as suggested
Comments.UserDisplayName: netjiro
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-06-10T04:21:06.497Z
Comments.Text: Sample of source, as well.
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-06-10T09:15:37.617Z
Comments.Text: My apologies. I had already deleted the source. Edited and replaced with better example, simpler graphics. Included source. Too low rep to post all links, removed the old example links
Comments.UserDisplayName: netjiro
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2018-01-03T14:32:07.530Z
Comments.Text: Updated the examples and source now that I have enough reputation points to be allowed to post more than two links
Comments.UserDisplayName: netjiro
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2018-01-03T19:57:05.950Z
Comments.Text: CRF 22 and preset medium at original size of 640 looks ok to me. TBH, as does your 320px CRF 22. Just don't expect it to look ok when scaled up during playback.
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2018-01-03T21:53:52.910Z
Comments.Text: Thanks again Mulvya for getting back on this ancient thread. Perhaps I'm having unrealistic expectations. But take a look:
  https://goo.gl/YRsoH1
  where encoding artefacts extend 10-12+ pixels away from edges of objects and flicker quite a bit from frame to frame.
  Is there a way to specifically tell the encoder to user smaller blocks, or to expect an environment of objects with sharp edges moving on a mostly static background?
  I remember people using special "anime" settings for similar effects on the old x264 encoders?
Comments.UserDisplayName: netjiro
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2018-01-04T05:11:26.130Z
Comments.Text: That's from the CRF 28, which has heavier quantization. So stick to <24.
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2018-01-04T06:02:40.093Z
Comments.Text: @Mulvya: great, can you change your crf<24 comment to an answer so I can accept it?
Comments.UserDisplayName: netjiro
Tags: <ffmpeg><encoding>
Title: How to tune ffmpeg libx265 parameters for encoding old sprite based game video?
UserDisplayName: netjiro
ThreadText: # How to tune ffmpeg libx265 parameters for encoding old sprite based game video?
  
  (Asked by: username_0 on 2017-06-09)
  
  I'm using ffmpeg libx265 to encode some fun gameplay clips from old games.
  Typically this means low resolution pixel art, with small sprites moving against a static or scrolling background.
  The default settings for the x265 codec are poorly suited for this and give large areas of blocky noise artifacts around the moving sprites.
  I can of course just increase bitrate, e.g. "crf=22" and allow more computation time "-preset slow" to reduce the problem, but I guess there are better ways to tune the codec parameters to better deal with these types of visuals.
  
  Any suggestions?
  
  EDIT: *hmm, I need >10 rep to be allowed to post more than two links. So I'm deleting the old examples and posting updated better examples.*
  
  Adding better examples (now with source)
  Very simple graphics. Both sprites moving against static background and scrolling background. The major distortions are found when sprites are moving on static background. The noise distortions can extend quite far around the sprites: e.g. @15s
  
  Download the files and view in fullscreen. The gdrive viewer will reencode and destroy.
  
  source (x264 ultrafast crf=0)  
  4.4MB <https://goo.gl/VjRhvh>
  
  ffmpeg -i source.mkv -libx265 -preset medium -libx265-params "crf=28" out.mkv  
  152KB <https://goo.gl/bQDmxe>
  
  ffmpeg -i source.mkv -libx265 -preset veryslow -libx265-params "crf=22" out.mkv  
  216KB <https://goo.gl/rGtNAT>
  
  This one looks a bit better due to higher bitrate and more compute time. Noise artifacts are smaller, but still disturbing.
  
  **Tags:** ffmpeg, encoding
  
  > **Comments:**
  > **username_1**: Can you post a short sample - source and result?  
  > **username_0**: added examples as suggested  
  > **username_1**: Sample of source, as well.  
  > **username_0**: My apologies. I had already deleted the source. Edited and replaced with better example, simpler graphics. Included source. Too low rep to post all links, removed the old example links  
  > **username_0**: Updated the examples and source now that I have enough reputation points to be allowed to post more than two links  
  > **username_1**: CRF 22 and preset medium at original size of 640 looks ok to me. TBH, as does your 320px CRF 22. Just don't expect it to look ok when scaled up during playback.  
  > **username_0**: Thanks again Mulvya for getting back on this ancient thread. Perhaps I'm having unrealistic expectations. But take a look: https://goo.gl/YRsoH1 where encoding artefacts extend 10-12+ pixels away from edges of objects and flicker quite a bit from frame to frame. Is there a way to specifically tell the encoder to user smaller blocks, or to expect an environment of objects with sharp edges moving on a mostly static background? I remember people using special "anime" settings for similar effects on the old x264 encoders?  
  > **username_1**: That's from the CRF 28, which has heavier quantization. So stick to <24.  
  > **username_0**: @Mulvya: great, can you change your crf<24 comment to an answer so I can accept it?  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2018-01-04. Score: 1 | Accepted answer
  
  The CRF 22 sample looks fine to me at 1x size. The lower the resolution, the greater the impact a high quantization parameter will have. Suggest you stick to values < 24.
  
  Since your video images are mostly static, slower presets won't be worth the extra time (unless you need to squeeze every bit of compression efficiency).
  
  
  ---
  
  