Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > High Efficiency Video Coding (HEVC)

Reply
 
Thread Tools Search this Thread Display Modes
Old 3rd January 2018, 13:27   #21  |  Link
birdie
.
 
Join Date: Dec 2006
Posts: 107
Quote:
Originally Posted by froggy1 View Post
you're doing something wrong. I get almost half size reduction when using x265 10 bit @ CRF 21 compared to 8 bit x264 @ CRF 18. Am hard pressed to notice difference in quality between the two

post your settings, if you will
Nope, I was doing everything OK. Again, I didn't encode an uncompressed source, I re-encoded H.264 videos.

I never use any fancy encoding flags. Here's my usual encoding parameters (tune is optional):

Code:
ffmpeg -i *mkv -c:audio copy -c:v libx265 -preset veryslow -x265-params crf=18:no-sao=1:tune=grain
Again, I got negatives gains from using 10bit encoding (increased encoding time and increased file sizes with zero improvements in details retention).
birdie is offline   Reply With Quote
Old 3rd January 2018, 19:51   #22  |  Link
jd17
Registered User
 
Join Date: Jun 2017
Posts: 63
Quote:
Originally Posted by birdie View Post
I didn't encode an uncompressed source, I re-encoded H.264 videos.
H.264 can be anything from a Blu-ray @ 35000 kbit/s down to a bad x264 encode at 2000 kbit/s.
So what exactly are we talking about?

Also, what kind of video were the sources you tested? 35mm with a lot of grain or squeaky-clean digital video?

Quote:
Code:
-preset veryslow -x265-params crf=18:no-sao=1:tune=grain
This is absolute overkill. (BTW, --no-sao is part of --tune grain anyhow.)
--preset veryslow plus --tune grain will just create loads of artificial grain i.e. blowing up the bitrate without a real benefit.
Also, combining those two will result in insanely low encoding speeds...

I would recommend to either go with a fast preset (not slower than medium) when using grain or use a slow(er) preset without --tune grain, just adding --no-sao.

Try going --crf 18 --preset slow --no-sao @10bit on a source that has not been compressed to death and you will see the benefits.
jd17 is offline   Reply With Quote
Old 3rd January 2018, 20:44   #23  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 2,801
Quote:
Originally Posted by birdie View Post
I re-encoded H.264 videos.
Blu-ray or already highly compressed?

Quote:
Originally Posted by birdie View Post
Again, I got negatives gains from using 10bit encoding (increased encoding time and increased file sizes with zero improvements in details retention).
If you were already transparent at the bitrate obtained with your 8 bit encode and simply used the same command line with 10 bit then, sure, you probably won't notice a difference.

Compare at the same bitrates and when you can notice the drop in quality and 10 bit will look better. At bit rates where increasing the bitrate of the 8 bit encode does not result in higher quality using 10 bit probably won't increase the quality either (unless you are getting banding at 8 bit even at high bitrates; source dependant).
__________________
madVR options explained
Asmodian is offline   Reply With Quote
Old 3rd January 2018, 22:58   #24  |  Link
birdie
.
 
Join Date: Dec 2006
Posts: 107
Quote:
Originally Posted by jd17 View Post
This is absolute overkill. (BTW, --no-sao is part of --tune grain anyhow.)
I wouldn't call veryslow/crf 18/no-sao/grain an overkill - it's probably a must for transparent FullHD (re)encodes. I won't argue if you're OK with losing tons of details. I'm not. I want to get the exact amount of details for my reencodes as the source has.

Quote:
Originally Posted by Asmodian View Post
Blu-ray or already highly compressed?
The latter.
birdie is offline   Reply With Quote
Old 4th January 2018, 00:12   #25  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 2,801
If your 8 bit encode looks exactly like the source then of course the 10 bit one doesn't look any better.

The 10 bit one is higher quality, you simply cannot tell. The same reason why you aren't using crf 17 even though that would be higher quality. To compare fairly you need to determine new "optimal" settings for the 10 bit encode, the same way you did for the 8 bit one.
__________________
madVR options explained
Asmodian is offline   Reply With Quote
Old 4th January 2018, 08:32   #26  |  Link
jd17
Registered User
 
Join Date: Jun 2017
Posts: 63
Quote:
Originally Posted by birdie View Post
The latter.
Reencoding already highly compressed sources is such a useless thing to do that I am regretting ever engaging in this discussion...

Quote:
I wouldn't call veryslow/crf 18/no-sao/grain an overkill - it's probably a must for transparent FullHD (re)encodes. I won't argue if you're OK with losing tons of details. I'm not. I want to get the exact amount of details for my reencodes as the source has.
Your premise is flawed.

- Reencoding an already highly compressed source is nonsense. Expecting the result to look better is even more nonsense.
- Again! --no-sao is already part of --tune grain. No use adding it to the command line.
- Starting with --preset slow, --tune grain adds --psy-rdoq 10, which generates artificial grain with relatively clean sources. The result might appear sharper to your eye, but it is not closer to the source.
- As long as you are not being precise regarding sources, any further discussion is useless. While --tune grain can surely help with noisy 16/35/65mm sources (or those with a grain filter), even with slower presets, it will hurt other, clean digital sources. High grain/noise sources have never been the strong suit for x265 so far. Even if the source were lossless or low compression / high bitrate, opting for x265 might be a mistake.

Anyhow, not trying different settings is probably the best thing you can do, considering your sources are already highly compressed.
So I'll rest my case now...
jd17 is offline   Reply With Quote
Old 4th January 2018, 21:45   #27  |  Link
Nico8583
Registered User
 
Join Date: Jan 2010
Location: France
Posts: 672
Does anyone already compile a FFMPEG x265 10bit Windows build ?
Nico8583 is offline   Reply With Quote
Old 5th January 2018, 04:11   #28  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 2,801
Don't ffmpeg builds usually support the --output-depth option?
__________________
madVR options explained
Asmodian is offline   Reply With Quote
Old 5th January 2018, 08:24   #29  |  Link
Nico8583
Registered User
 
Join Date: Jan 2010
Location: France
Posts: 672
It seems to not support it :
Unrecognized option '-output-depth'.
Error splitting the argument list: Option not found
Nico8583 is offline   Reply With Quote
Old 5th January 2018, 11:22   #30  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 2,801
Hmm, you are correct. I don't know how to set the output bitdepth for libx265 in ffmpeg. I usually pipe to x265.exe from Avisynth (avs2pipemod.exe).
__________________
madVR options explained
Asmodian is offline   Reply With Quote
Old 5th January 2018, 20:46   #31  |  Link
Nico8583
Registered User
 
Join Date: Jan 2010
Location: France
Posts: 672
Thank you, and is it necessary to install FFDShow or LAV or other to use avs2pipemod ?
Nico8583 is offline   Reply With Quote
Old 5th January 2018, 22:00   #32  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 2,801
No, but you do need to get a decoding plugin for Avisynth (I use ffms2) and create the decoding script. I often use a single line like "FFVideoSource("00260.mkv")".

Example command line:
C:\Tools\avs2pipemod.exe -y4mp=1:1 input.avs| C:\Tools\x265.exe --input - --y4m -o "output.mkv" --crf 21 -D 10 -p 8
__________________
madVR options explained

Last edited by Asmodian; 5th January 2018 at 22:12.
Asmodian is offline   Reply With Quote
Old 5th January 2018, 22:20   #33  |  Link
Motenai Yoda
Registered User
 
Motenai Yoda's Avatar
 
Join Date: Jan 2010
Posts: 652
LoL just add -pix_fmt yuv420p10le after input file
__________________
powered by Google Translator
Motenai Yoda is offline   Reply With Quote
Old 5th January 2018, 22:35   #34  |  Link
Nico8583
Registered User
 
Join Date: Jan 2010
Location: France
Posts: 672
Thank you Asmodian, I'll try it
And -pix_fmt doesn't work, you need to compile a 10bit build : http://www.gregwessels.com/dev/2017/...mpeg-x265.html
But I don't have all the tools to do it
Nico8583 is offline   Reply With Quote
Old 5th January 2018, 22:42   #35  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 2,801
C:\Tools\ffmpeg\bin\ffmpeg.exe -i input.mkv -pix_fmt yuv420p10le -c:v libx265 output.mp4:

Incompatible pixel format 'yuv420p10le' for codec 'libx265', auto-selecting format 'yuv420p'
__________________
madVR options explained
Asmodian is offline   Reply With Quote
Old 6th January 2018, 06:22   #36  |  Link
DotJun
Registered User
 
Join Date: Aug 2014
Posts: 8
Is there a reason to use ffmsindex over L-smash works for uhd source?
DotJun is offline   Reply With Quote
Old 8th January 2018, 04:29   #37  |  Link
Neillithan
Registered User
 
Join Date: Feb 2007
Posts: 95
Wow, I posted this question and completely forgot about it. Came back, and it's 2 pages long. Haha.

Thanks everyone for the responses. I will read through these.

Slightly off topic.

For the time being, I'd like to point out that I did like, 3 dozen tests on a particular sample footage (blu-ray source)..... Converting to HEVC (x265) CRF 8-bit (Medium Preset) With Grain Tune Enabled. Each and every single time, it completely butchered the sample. It over-compressed and caused the faces to become a complete blurry mess. It wasn't until I started doing a 2-pass (12,000br) conversion that it was able to properly allocate the bitrate. For some reason, CRF with HEVC is too problematic to be reliable for me. It simply is unable to determine what the bitrate should be for my particular sample, and decided it should be less than 500 bitrate, which resulted in a horrible artifacty mess, that didn't resolve itself until the people's heads moved slightly.

2-pass did not have this problem, and produced flawless results every time.

So anyway, the reason I felt the need to bring that up is because I see a *lot* of comments here saying CRF results were problematic with x265, and my theory is simply x265 CRF misses the mark by a mile. Use 2-pass for the best results. In my experience, x264 never had this problem with CRF.

And before anybody says it, yes, I'm fully aware that 2-pass is intended to be used when you are trying to meet a specific target filesize, such as DVD-5 or DVD-DL. At this point, I'm simply using 2-pass because it's more reliable than CRF, and target filesize does not matter to me. Only intelligent bitrate allocation matters to me.

@birdie,

If you're aiming for highest quality downconversion from a Blu-ray source, I recommend sticking to this x265 configuration:

x265 8-bit 2-pass (Medium Preset with Fast First pass) (Grain Tune enabled depending on whether or not your source has grain), at least 12,000 bitrate, with a max VBV of 50,000. This has been yielding very positive results for me.

Please note, I have not yet tested 10-bit so I can't yet recommend it. I plan to experiment with this.

As for banding artifacts, I have not yet noticed any of that in any of my encodes. I do use FFDShow Tryouts and enable anti banding for sources that do have heavy banding problems, but I haven't needed to enable this for my own encodes.

Last edited by Neillithan; 8th January 2018 at 04:51.
Neillithan is offline   Reply With Quote
Old 8th January 2018, 07:08   #38  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 2,801
Quote:
Originally Posted by DotJun View Post
Is there a reason to use ffmsindex over L-smash works for uhd source?
L-smash had an issue with returning incorrect frames during out of order frame requests in specific situations and ffmsindex works well for me.

They are both good but I think that index file is a good thing to have.
__________________
madVR options explained
Asmodian is offline   Reply With Quote
Old 8th January 2018, 14:39   #39  |  Link
DotJun
Registered User
 
Join Date: Aug 2014
Posts: 8
Quote:
Originally Posted by Asmodian View Post
L-smash had an issue with returning incorrect frames during out of order frame requests in specific situations and ffmsindex works well for me.



They are both good but I think that index file is a good thing to have.

Has this problem not been addressed yet? Iíve only used smash so far and havenít had any trouble with it yet, though as you said, maybe that is due to my particular source file.
DotJun is offline   Reply With Quote
Old 8th January 2018, 17:20   #40  |  Link
Motenai Yoda
Registered User
 
Motenai Yoda's Avatar
 
Join Date: Jan 2010
Posts: 652
Quote:
Originally Posted by Nico8583 View Post
Does anyone already compile a FFMPEG x265 10bit Windows build ?
x86_64 https://expirebox.com/download/fb998...b50c8f246.html
should stay on for 48h, media-autobuild_suite describe it as GPL2.1 but I found only LGPL2.1 license...
__________________
powered by Google Translator

Last edited by Motenai Yoda; 8th January 2018 at 17:35.
Motenai Yoda is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 00:59.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.