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 20th January 2020, 01:10   #7361  |  Link
microchip8
ffx264/ffhevc author
 
microchip8's Avatar
 
Join Date: May 2007
Location: /dev/video0
Posts: 1,843
Quote:
Originally Posted by jlpsvk View Post
exactly... my 2160p HDR10 preset currently...any suggestions?

Code:
--preset slow --profile main10 --level-idc 5.1 --output-depth 10 --crf 16 --ctu 64 --aq-mode 4 --merange 57 --amp --no-rskip --qg-size 8 --vbv-bufsize 160000 --vbv-maxrate 160000 --bframes 8
--rc-lookahead 48 --gop-lookahead 30 --hdr10 --hdr10-opt --repeat-headers --no-info --no-deblock --no-sao --selective-sao 0 --allow-non-conformance --no-strong-intra-smoothing --high-tier --chromaloc 2
--fades --hme --hme-search umh,umh,star
I'd set deblock to -1,-1 instead of completely disabling it - deblock has seen a major revision compared to x264.

Also strong-intra-smoothing seems to have a positive effect at keeping noise. Many people are scared by the name but I find it does improve things a bit. It will help reduce banding on very clean scenes too, like skies or other clean textures, by blending a bit instead of keeping the banding

merange has no effect when using HME since the latter has its own range parameters you can adjust with --hme-range
__________________
ffx264 || ffhevc || ffxvid || microenc

Last edited by microchip8; 20th January 2020 at 01:22.
microchip8 is offline   Reply With Quote
Old 20th January 2020, 12:19   #7362  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
Ben Waggoner was doing some tests with --aq-mode 4, I don't think he got them finished though. He's probably the only one (apart from the devs) who has some kind of an insight to how it looks with real life examples.

For what it's worth, lately I've found --aq-mode 3 being troublesome. With normal sources originating from film, like the older seasons of X-Files which contain quite a lot of grain and noise, it works well at around ~0.6 for strength. Then there's something like Suits, or The Killing, which look terrible. The sources are terrible in quality -- lots of macroblocking which appears when the encoder starts removing the grain hiding some of that -- and aq-mode 3 produces a substantially lower average bitrate at the same CRF than aq-mode 1. I don't know why the rate control works this way, The Killing does contain quite a lot of dark scenes but I was unable to get a good result without switching to --aq-mode 1 at the default strength. I also raised psy-rd to 3.0 and deblock to 0:0 to try to keep the higher frequencies and avoid banding where the encoder removes too much from the original image.

I really scratched my head at the issue the whole weekend. Yes, I did test x264 at --preset veryslow, but it wasn't any better

Sometimes I have used a dirty trick and added a light amount of fake grain with GrainFactory3 before feeding the video to the encoder. I may need to test that too
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 20th January 2020, 16:37   #7363  |  Link
microchip8
ffx264/ffhevc author
 
microchip8's Avatar
 
Join Date: May 2007
Location: /dev/video0
Posts: 1,843
Quote:
Originally Posted by Boulder View Post
Ben Waggoner was doing some tests with --aq-mode 4, I don't think he got them finished though. He's probably the only one (apart from the devs) who has some kind of an insight to how it looks with real life examples.

For what it's worth, lately I've found --aq-mode 3 being troublesome. With normal sources originating from film, like the older seasons of X-Files which contain quite a lot of grain and noise, it works well at around ~0.6 for strength. Then there's something like Suits, or The Killing, which look terrible. The sources are terrible in quality -- lots of macroblocking which appears when the encoder starts removing the grain hiding some of that -- and aq-mode 3 produces a substantially lower average bitrate at the same CRF than aq-mode 1. I don't know why the rate control works this way, The Killing does contain quite a lot of dark scenes but I was unable to get a good result without switching to --aq-mode 1 at the default strength. I also raised psy-rd to 3.0 and deblock to 0:0 to try to keep the higher frequencies and avoid banding where the encoder removes too much from the original image.

I really scratched my head at the issue the whole weekend. Yes, I did test x264 at --preset veryslow, but it wasn't any better

Sometimes I have used a dirty trick and added a light amount of fake grain with GrainFactory3 before feeding the video to the encoder. I may need to test that too
I did my own testing, both with AQ mode 2 and 3. It did not make things beter here and I was hoping AQ mode 3 would work well on dark scenes, but it didn't. All I saw is increased bitrate for 2 and 3 with no meaningful improvements... so I went back and stick to my good ol' AQ mode 1

As for psy-rd/psy-rdoq, they are meant to keep the original energy of the source as much as possible at higher strength. So if you have a (very) noisy sample, the bitrate will shoot up in order to preserve the noise/grain. These two settings are set to high values when using --tune grain (psy-rd is set to 4 and psy-rdoq is set to 10). I personally now use psy-rd of 3.2 and psy-rdoq of 15. I do not mind the increase of bitrate as I aim to preserver the input as much as possible. These two especially have an effect on dark scenes and look better than using AQ mode 2 or 3. I haven't tested AQ mode 4, though
__________________
ffx264 || ffhevc || ffxvid || microenc

Last edited by microchip8; 20th January 2020 at 16:43.
microchip8 is offline   Reply With Quote
Old 20th January 2020, 16:45   #7364  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by Boulder View Post
Ben Waggoner was doing some tests with --aq-mode 4, I don't think he got them finished though. He's probably the only one (apart from the devs) who has some kind of an insight to how it looks with real life examples.
I finished making the content but not my comparisons. Thanks for the reminder to take a look again.

Quote:
For what it's worth, lately I've found --aq-mode 3 being troublesome. With normal sources originating from film, like the older seasons of X-Files which contain quite a lot of grain and noise, it works well at around ~0.6 for strength. Then there's something like Suits, or The Killing, which look terrible. The sources are terrible in quality -- lots of macroblocking which appears when the encoder starts removing the grain hiding some of that -- and aq-mode 3 produces a substantially lower average bitrate at the same CRF than aq-mode 1. I don't know why the rate control works this way, The Killing does contain quite a lot of dark scenes but I was unable to get a good result without switching to --aq-mode 1 at the default strength. I also raised psy-rd to 3.0 and deblock to 0:0 to try to keep the higher frequencies and avoid banding where the encoder removes too much from the original image.
Maybe throw in some --nr-inter? That tends to reduce grain swirling and lower QPs a bit at the same bitrate.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 20th January 2020, 16:47   #7365  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by froggy1 View Post
I did my own testing, both with AQ mode 2 and 3. It did not make things beter here and I was hoping AQ mode 3 would work well on dark scenes, but it didn't. All I saw is increased bitrate for 2 and 3 with no meaningful improvements... so I went back and stick to my good ol' AQ mode 1
The AQ comparisons really need to be made with 2-pass VBR to compare bitrates. Different AQ modes can require different CRF values in practice.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 20th January 2020, 17:01   #7366  |  Link
microchip8
ffx264/ffhevc author
 
microchip8's Avatar
 
Join Date: May 2007
Location: /dev/video0
Posts: 1,843
Quote:
Originally Posted by benwaggoner View Post
The AQ comparisons really need to be made with 2-pass VBR to compare bitrates. Different AQ modes can require different CRF values in practice.
I have no need for 2-pass VBR. I only do CRF encoding and that's what matters to me but also tested in 2-pass as you recommended previously in a post a week or so ago. Not much improvement. I find psy-rd/rdoq delivering better results than these AQ modes
__________________
ffx264 || ffhevc || ffxvid || microenc
microchip8 is offline   Reply With Quote
Old 20th January 2020, 19:25   #7367  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
If you want to try things, I uploaded the sample clip I used to test: https://drive.google.com/open?id=1Ar...5cr6UNO1WjfV7- . Take a look at the flat background in the shots with the cop, it's ugly in the source and gets much worse after encoding.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 20th January 2020, 19:47   #7368  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by froggy1 View Post
I have no need for 2-pass VBR. I only do CRF encoding and that's what matters to me but also tested in 2-pass as you recommended previously in a post a week or so ago. Not much improvement. I find psy-rd/rdoq delivering better results than these AQ modes

Right. But if you want to figure out the optimum efficiency for a CRF encode, comparing the features in 2-pass VBR shows you how features compare at the same file size. Once you nail down the optimum parameters, then you figure out what CRF is optimal for you with those other parameters.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 20th January 2020, 19:51   #7369  |  Link
microchip8
ffx264/ffhevc author
 
microchip8's Avatar
 
Join Date: May 2007
Location: /dev/video0
Posts: 1,843
Quote:
Originally Posted by benwaggoner View Post
Right. But if you want to figure out the optimum efficiency for a CRF encode, comparing the features in 2-pass VBR shows you how features compare at the same file size. Once you nail down the optimum parameters, then you figure out what CRF is optimal for you with those other parameters.
I won't be bothered doing this. At the moment I'm quite happy with my own setting for CRF @ 21. I increased some of them by a small amount to give it a bit more headroom. If I can compress a source of say 22-25 GiB down to 5-6 or 7 GiB (with decent quality according to my eyes), I'm a happy camper
__________________
ffx264 || ffhevc || ffxvid || microenc
microchip8 is offline   Reply With Quote
Old 26th January 2020, 22:41   #7370  |  Link
zerowalker
Registered User
 
Join Date: Jul 2011
Posts: 1,121
Annoying question but might as well ask it.

It was a long time ago since i checked out x265, probably like 2 years ago, and back then x264 was better except for edge cases which was very low bitrate and very high resolutions mostly.
And then it looked crap anyway so even if x265 won it didn't really matter (for me).

How is it nowadays (know it's a vague question)?

If you have like a 1080p video and use crf=16 (which i would say results in high quality for x264 at least) would x265 achieve the "same quality" for less space?
Or is it only in very high resolutions like 4k and beyond that x265 can outdo it cause of how it works?

I know it sounds like i am saying x265 is crap compared to x264, but that's not what i am trying to say, but it's hard to ask the comparison question without making it sound that way.
I am not denying x265 nor the standard h265, it's obviously made for a good reason and the encoder is surely aiming to be as great as possible compared to what currently exists (either for all or some cases),
i just don't know that much about it except that the standard was made with very high resolutions in mind as h264 breaks down quickly there except with very high bitrates (which is the "throw money at the problem" solution usually;P).

Thanks
zerowalker is offline   Reply With Quote
Old 27th January 2020, 17:41   #7371  |  Link
MeteorRain
結城有紀
 
Join Date: Dec 2003
Location: NJ; OR; Shanghai
Posts: 894
zerowalker, I can't answer your question but I do have a question for you. Were you using 10-bit and were you comparing 10-bit x265 against 8-bit x264?

We / I switched to x265 simply because we wanted to use 10-bit and AVC High10 had some compatibility issues with hardware players.
__________________
Projects
x265 - Yuuki-Asuna-mod Download / GitHub
TS - ADTS AAC Splitter | LATM AAC Splitter | BS4K-ASS
Neo AviSynth+ filters - F3KDB | FFT3D | DFTTest | MiniDeen | Temporal Median
MeteorRain is offline   Reply With Quote
Old 27th January 2020, 19:46   #7372  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by zerowalker View Post
If you have like a 1080p video and use crf=16 (which i would say results in high quality for x264 at least) would x265 achieve the "same quality" for less space?
Or is it only in very high resolutions like 4k and beyond that x265 can outdo it cause of how it works?
If you're trying to get the best image in a fixed amount of bits, x265 beats x264 in the large majority of scenarios. A big part of this is you can use HEVC at a higher resolution, preserving a lot more detail by preserving more pixels. CRF comparisons are more complex, as it's not a linear relationship. Even just using x264 the same CRF gives different results depending on other parameters.

The biggest problem with x265 years ago was how it handled grain, which is much improved now.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 28th January 2020, 15:59   #7373  |  Link
birdie
Artem S. Tashkinov
 
birdie's Avatar
 
Join Date: Dec 2006
Posts: 337
Quote:
Originally Posted by zerowalker View Post
Annoying question but might as well ask it.

It was a long time ago since i checked out x265, probably like 2 years ago, and back then x264 was better except for edge cases which was very low bitrate and very high resolutions mostly.
This is still largely true: x265 is better for resolutions above 1080p and for very low bitrates (which are mostly suitable for streaming anyways).
birdie is offline   Reply With Quote
Old 29th January 2020, 08:21   #7374  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
But the general rule remains: There is no magic. Size reduction requires a loss of quality. It's just a matter how annoying you rate this kind of loss.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 5th February 2020, 13:43   #7375  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
The x265 source repo will migrate to Git and move to https://bitbucket.org/multicoreware/x265_git/ (Bitbucket will drop Mercurial support until June 2020).

Previously I used the combo of "hg pull" and "hg update" to keep a local working directory up to date. Which would be the recommended Git commands?
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 5th February 2020, 13:59   #7376  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
Quote:
Originally Posted by LigH View Post
The x265 source repo will migrate to Git and move to https://bitbucket.org/multicoreware/x265_git/ (Bitbucket will drop Mercurial support until June 2020).
1) Thanks for the info *THUMBS UP*

2)

downloading with Mercurial = 35.4 MB, very fast;

downloading with git = 290 MB, very slow;

x265_git\.git\objects\pack\pack*.pack = 276 MB — ¿what the devil is that?

Last edited by filler56789; 5th February 2020 at 14:57. Reason: typo
filler56789 is offline   Reply With Quote
Old 5th February 2020, 16:05   #7377  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
Quote:
Originally Posted by LigH View Post
The x265 source repo will migrate to Git and move to https://bitbucket.org/multicoreware/x265_git/ (Bitbucket will drop Mercurial support until June 2020).

Previously I used the combo of "hg pull" and "hg update" to keep a local working directory up to date. Which would be the recommended Git commands?
I think an initial "git clone" followed by "git pull" every time you need to update would do. You may need to set the branch which you want to follow, I don't have any knowledge on that.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 5th February 2020, 22:19   #7378  |  Link
MeteorRain
結城有紀
 
Join Date: Dec 2003
Location: NJ; OR; Shanghai
Posts: 894
Quote:
Originally Posted by LigH View Post
Previously I used the combo of "hg pull" and "hg update" to keep a local working directory up to date. Which would be the recommended Git commands?
If you are not used to Git, I strongly recommend using a GUI to help learning. Personally I love SmartGit the best, but it's a proprietary software (free for non-commercial use).

Pull updates from remote to local is "git fetch".

Pull updates from local to working directory is "git checkout".

Git is much more flexible (and thus harder to use) that's why I always recommend people to use a GUI to get started. There are more concepts in Git than in Hg and it takes time to get used to.
__________________
Projects
x265 - Yuuki-Asuna-mod Download / GitHub
TS - ADTS AAC Splitter | LATM AAC Splitter | BS4K-ASS
Neo AviSynth+ filters - F3KDB | FFT3D | DFTTest | MiniDeen | Temporal Median
MeteorRain is offline   Reply With Quote
Old 5th February 2020, 23:21   #7379  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
Just re-checking...

the latest cloned x265/.hg directory = 23.2 MB
Apparently the "conversion" of x265's Hg repository into git included or added some TONS of *garbage*...

Last edited by filler56789; 5th February 2020 at 23:22. Reason: clarity
filler56789 is offline   Reply With Quote
Old 6th February 2020, 00:36   #7380  |  Link
MeteorRain
結城有紀
 
Join Date: Dec 2003
Location: NJ; OR; Shanghai
Posts: 894
I don't understand the point of mentioning the size of the repository.
I use Git not for saving 200MB of space, but for managing the source code.
I'd happily trade a few gigabytes of my "precious?" hard drive space for a tool that works better to me.

To answer your previous question, git object pack is a compressed package of all kinds of objects used by git, including histories, files, deltas, etc.
If network activity is a real concern to you, you can limit the depth of repository to download. You can choose to only download and store the most recent 500 commits, for example, and still work on that as long as you don't need access to history more than 500 commits back.
__________________
Projects
x265 - Yuuki-Asuna-mod Download / GitHub
TS - ADTS AAC Splitter | LATM AAC Splitter | BS4K-ASS
Neo AviSynth+ filters - F3KDB | FFT3D | DFTTest | MiniDeen | Temporal Median
MeteorRain 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 21:13.


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