x265 HEVC Encoder

[Stereodude]

Originally Posted by fauxreaper

With less frame-threads and no-wpp, the encode has better quality and uses less bitrate. In my tests, disabling wpp is more effective to quality and bitrate than decreasing frame-threads.

I haven't tried no-wpp yet, but going from 4 frame threads to 1 frame thread makes a dramatic quality difference in my testing. I didn't pay much if any attention to the bitrate. I will give --no-wpp a try.

Edit: --no-wpp really reduces CPU usage and used alone increases the number of frame threads. Killing wpp and holding frame threads to 1 is really slow and uses very little CPU. Encodes would be so slow as to be totally impractical.

[Blue_MiSfit]

I found using 1 frame thread to be necessary to avoid macroblocking in certain edge cases (CBR encoding of 4K HDR content, namely)

[Stereodude]

Originally Posted by Blue_MiSfit

I found using 1 frame thread to be necessary to avoid macroblocking in certain edge cases (CBR encoding of 4K HDR content, namely)

I've been encoding 1080p and 480p and find using 1 frame thread (vs. 4) and found it makes a big difference in the stability of flat areas vs. the source. 1 is nice and stable, 4 is "nervous" with considerably more noise that not in the source. This is using fairly low CRF's (16 for 1080p / 15.5 for 480p).

[LigH]

Originally Posted by Stereodude

Where can I get another 64-bit Windows build of 3.3+1-f94b0d32737d? I already have a HolyWu build made with Clang 9.0.0 and want to compare a behavior I see to a different build of the same x265 version.

Using the media-autobuild suite you can compile them yourself, with either clang or GCC.

You may find binaries of the same source state, either with git hash (starting with a g) or with Mercurial hash, but they are equivalent even though hash and increment are not the same (Mercurial counts merges, git doesn't). I switched to git as soon as Multicoreware announced that Bitbucket will drop Mercurial support during this year.

x265 3.3+1-g396395b2b (GCC 9.2.0)

[Stereodude]

Originally Posted by fauxreaper

With less frame-threads and no-wpp, the encode has better quality and uses less bitrate. In my tests, disabling wpp is more effective to quality and bitrate than decreasing frame-threads.

So I tried --no-wpp and did not duplicate your finding on my test clip (first 14943 frames of Oblivion). On encodes that ended up at 400MB they were all within 650kB of each other. FWIW, the clip using -F 1 with wpp was the smallest of the permutations I tried.

Here are the common options I used for all 4 encodes:
--crf 16.0 -p veryslow --aq-strength 1.15 --vbv-maxrate 40000 --vbv-bufsize 40000 --level 5.1 --keyint 120 --open-gop -D 10 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1

On the visual quality I didn't find any improvement from turning wpp off. In contrast it was worse because the frame threads are >1. wpp on with 1 frame thread looked the best of them. wpp off with only 1 frame thread is so excruciatingly slow I would consider it totally unusable. It would have taken days to compress the test sample with those options so I did not run it.

Lastly, after reading up on wpp and how x265 makes the number of wpp rows I don't really see why it would noticeably degrade the image quality. Doesn't it select the number of rows based on the vertical resolution of the video max CU size? So if your CU can be as large as 64 pixels and your video is 1080 pixels tall it will do 17 rows which is basically 1080/64. What's the problem with that method?

[Stereodude]

Originally Posted by LigH

Using the media-autobuild suite you can compile them yourself, with either clang or GCC.

You may find binaries of the same source state, either with git hash (starting with a g) or with Mercurial hash, but they are equivalent even though hash and increment are not the same (Mercurial counts merges, git doesn't). I switched to git as soon as Multicoreware announced that Bitbucket will drop Mercurial support during this year.

x265 3.3+1-g396395b2b (GCC 9.2.0)

Thanks. I found a [Windows][MSVC 1916][64 bit] build online of it that I'm testing now. I will try the one you linked next as another data point, but the test can take over 24 hours to run while I wait to see if I get and crashes.

[Boulder]

Does anyone have any sample clips of this big difference between -F 1 and 4? I just tested on a rather noisy clip and visibly they look the same. The average bitrate was almost the same as well, in fact F 2-4 all produced the same size. I think it could be different with clean clips as frame threads should affect references.

[Stereodude]

Originally Posted by Boulder

Does anyone have any sample clips of this big difference between -F 1 and 4? I just tested on a rather noisy clip and visibly they look the same. The average bitrate was almost the same as well, in fact F 2-4 all produced the same size. I think it could be different with clean clips as frame threads should affect references.

You want the source or the output? BTW, I've not found much difference in the resulting file size.

[Blue_MiSfit]

I don't have a sample I can share unfortunately.

I found explosive macroblocking for a few frames a time, and only very rarely (only on specific content and encoding settings).

[Boulder]

Originally Posted by Stereodude

You want the source or the output? BTW, I've not found much difference in the resulting file size.

The output would be interesting to see in case I run into similar issues.

EDIT: And of course, it would be best if you could file a bug report for MultiCoreWare as this could also be a bug.

[LigH]

If you need common samples to compare, try Derf's collection at xiph.org, there is a variety of material (Y4M) with different kinds of codec annoyances.

My favorites: crowd_run / ducks_take_off / in_to_tree / park_joy / parkrun / pedestrian_area / riverbed / sintel_trailer

And if you need a longer playtime: the footage of "Tears of Steel"

[Lucius Snow]

Originally Posted by Stereodude

What file format is the video source? You don't have to split the source video file. You only have to split the encoding of the source video file.

By the way, you could just encode two different video source files at the same time.

ProRes 4:2:2 HQ or 4:4:4:4 in UHD.

But I don't have two different files to encode at the same time. Only one, fast.

[Stereodude]

Originally Posted by Lucius Snow

ProRes 4:2:2 HQ or 4:4:4:4 in UHD.

But I don't have two different files to encode at the same time. Only one, fast.

Are you using AVIsynth, or how are you getting the file into x265 to be encoded?

[Atak_Snajpera]

Originally Posted by Lucius Snow

ProRes 4:2:2 HQ or 4:4:4:4 in UHD.

But I don't have two different files to encode at the same time. Only one, fast.

How about this?

Spliting is fully automated. Just fire and forget.

[Lucius Snow]

I use the command line with ffmpeg / x265.

Interesting this RipBot64 thing. Never tried. I'll have a look. Thanks.

EDIT: Well, finally no, just the indexing process at startup takes too much time.

[Andouille]

Originally Posted by Atak_Snajpera

How about this?

Spliting is fully automated. Just fire and forget.

Distributed encoding/file spliting should NOT be used for 2pass/filesize target.(your pic seems to be)
Only for quality encoding.

[Blue_MiSfit]

To be fair, distributed multi-pass encoding is a thing.

It's hard to get right and there absolutely are trade-offs, but it can be done.

[Atak_Snajpera]

Originally Posted by Andouille

Distributed encoding/file spliting should NOT be used for 2pass/filesize target.(your pic seems to be)
Only for quality encoding.

I analyze stat file from first pass and then adjust bitrate for each chunk(more complex chunk gets higher bitrate while less complex gets lower). If you use large for example 10 min chunk then you do not have to worry about quality.

[Zebulon84]

Can (or could) RipBot do that automatically ?

[filler56789]

x265.exe 3.3+7-d769bc8e8cde

(x64, multilib, GCC 8.4.0)

Add aarch64 support - Part 1
This patch add some common assembly optimization function for aarch64 platform. These function won't work until the patch Part 2 is merged.

Add aarch64 support - Part 2
This patch adds aarch64 build & compile support. This patch must be merged after the Part 1.

Fix: segmentation fault for hist-scenecut option
fixes plane size calculation for chroma planes using source resolution and not padded resolution.

http://www.mediafire.com/file/2oj8wn...e8cde.rar/file