Open Ilya87 opened 5 years ago
Good taste. However, the ss are so dark, that it's so hard to see the banding. Also, why the ? after Antergos x86_64?
@1480c1 ? is a typo (corrected in post), comma should be used. And not, when you'll see screenshots fullscreen using 24" monitor artifacts are clearly seen, moreover this screenshots are from still scene (and you'll see artifacts for seconds), moreover x264 doesn't produce such artifacts.
That is true, I saw it when I zoomed in.
@Ilya87 yes, I can see the artifacts on the face. 6.1MBx8/(751/24) = about 1.6Mbps which is not very high for 1080p. What is the bitrate of x264 bitstream?
@tianjunwork, yes, I'm sorry - at this bitrate x264 also provides comparable banding artifacts, BUT at comparable bitrate x264 is better x264 veryslow_qp15_bitrate_3549 https://yadi.sk/i/uBj5eDI_m7-Pcw SVT-HEVC -q12 result bitrate is 3108 https://yadi.sk/i/gFZWSRU0kXDZPg Banding artifacts are still the problem.
Almost doubled bitrate - same artifacts.
Compare with x264 veryslow -crf 16.6 (bitrate is 3088) (yes, I know crf mode for SVT-HEVC isn't yet implemented) https://yadi.sk/i/2Ow-PxJZdqcmUg Comparable encoding speed, same bitrate, banding artifacts are much less.
What is the tune mode used by x264? Could you try -tune 0/2 with SVT?
@tianjunwork, for x264 I used ffmpeg with -c:v libx264 -preset veryslow -qp 15. No additional options. For crf mode -c:v libx264 -preset veryslow -crf 16.6 @tianjunwork, you can test all options you wish if download the sample from the bugreport (1 message).
I tried with different tune mode(all other configs are the same as yours), tune0 is slightly better for banding artifacts. I took the snapshot from media analyzer tool. All of the tune modes are not as obvious as viewed in VLC. This frame is the 263th counting from 0.
tune0
tune1
tune2
@tianjunwork, such clearly seen artifacts as I checked have divx265, x265, turing, SVT-HEVC encoders (there is open issue about banding in x265 bug tracker). While x264 has much less banding artifacts. So, my conclusion is that all HEVC standard encoders can't encode without such artifacts by design. But it's only my not professional opinion. If you wish, I can upload encoded materials (encoders mentioned above, same sample as here) with settings description, VMAF values, bitrates.
Hevc introduced SAO filter applied after the standard deblocking filter; it’s designed to increase picture quality and reduce banding and ringing artifacts at some cost of encoding speed. Generally speaking, hevc should perform better than avc. I think SVT has room to further reduce banding artifacts. Please do upload your material:) which will help us debugging later. Thanks! I will mark this issue as a low priority task based on our current resources.
https://yadi.sk/d/KizxwX0-Tu-WRg - encoded files with results in ods. @tianjunwork, SAO filter doesn't significantly affect to banding artifacts. You can try x265 with no-sao option. Generally speaking, HEVC significantly outperforms AVC only on low bitrate (if encoding speed is at the same level at least).
@Ilya87 Thx for the files. You can also turn off SAO for SVT. For all the encoding tools, trade off between video quality and speed has to be made. With SAO turned on, in order not to affect speed so much, parameters of SAO is tuned for each every encoder. So you observe the difference among each encoder output.
@tianjunwork, the problem is not in SAO turned on or off (that doesn't affect much), but in the same banding artifacts of all HEVC encoders for high quality encodes. It can't be a coincidence.
Os - Antergos x86_64, SVT-HEVC latest from git https://yadi.sk/i/qBkjd3TzJ_yBQQ - original h.264 file from blu-ray (was converted to YUV) https://yadi.sk/d/K6LBH3HdDVF6zQ - encoded version
Encoding options are:
-w 1920 -h 1080 -tune 1 -intra-period 239 -rc 0 -profile 2 -fps-num 24 -fps-denom 1 -encMode 3 -lad 49 -q 15 -n 751 -b out.hevc
Example screenshots (artifacts on faces, eyes):
![vlcsnap-2019-03-25-3](https://user-images.githubusercontent.com/1446573/54888839-e7fff500-4eb1-11e9-80f1-5f97f60c2a41.png)