x265 HEVC Encoder

[burfadel]

I did a quick test with the revised -tu-limit settigs in 2.1+59. I had both inter and intra TU levels set at 4. No point using anything less since the whole point of this is to be able to make use of a higher inter TU without the performance penalty, right? So 4 makes sense, and likewise therefore 4 for intra as well.

What I found was --limit-tu 3 appeared the nicest to look at without any penalty of file size worth mentioning. I redid the tests with PSNR and SSIM stats enabled. Yes I know that with psy etc this isn't exactly a good way of testing, but --limit-tu 3 had better PSNR and SSIM, which matched what I saw visually. Do take into mind that I did the subjective visual test first without seeing the results.

[LigH]

x265 2.1+59-a895b6344a82

CLI changes:

(new)
   --scenecut-bias <0..100.0>    Bias for scenecut detection. Default 5.00

(changed descr.)
   --[no-]vui-timing-info        Emit VUI timing information in the bistream. Default enabled
   --[no-]vui-hrd-info           Emit VUI HRD information in the bistream. Default enabled
   --[no-]opt-qp-pps             Dynamically optimize QP in PPS (instead of default 26) based on QPs in previous GOP. Default enabled
   --[no-]opt-ref-list-length-pps  Dynamically set L0 and L1 ref list length in PPS (instead of default 0) based on values in last GOP. Default enabled

[burfadel]

Originally Posted by LigH

x265 2.1+59-a895b6344a82

CLI changes:

(new)
   --scenecut-bias <0..100.0>    Bias for scenecut detection. Default 5.00

(changed descr.)
   --[no-]vui-timing-info        Emit VUI timing information in the bistream. Default enabled
   --[no-]vui-hrd-info           Emit VUI HRD information in the bistream. Default enabled
   --[no-]opt-qp-pps             Dynamically optimize QP in PPS (instead of default 26) based on QPs in previous GOP. Default enabled
   --[no-]opt-ref-list-length-pps  Dynamically set L0 and L1 ref list length in PPS (instead of default 0) based on values in last GOP. Default enabled

Plus there's --limit-TU 3 and 4, although command line help doesn't show it. The information is available with the full x265 documentation though: http://x265.readthedocs.io/en/defaul...tion--limit-tu

--limit-tu <0..4>

Enables early exit from TU depth recursion, for inter coded blocks.
Level 1 - decides to recurse to next higher depth based on cost comparison of full size TU and split TU.
Level 2 - based on first split subTU’s depth, limits recursion of other split subTUs.
Level 3 - based on the average depth of the co-located and the neighbor CUs’ TU depth, limits recursion of the current CU.
Level 4 - uses the depth of the neighbouring/ co-located CUs TU depth to limit the 1st subTU depth. The 1st subTU depth is taken as the limiting depth for the other subTUs.

Default: 0

Not quite a direct quote as I think it is easier to read like above instead of all being in one paragraph. I simply changed it so each level is represented as a new line.

As I said previously, I believe 'level 3' which I bolded above gives the most favourable results IMO.

[Gravitator]

Megablock very bad impact on the formation of each of the second frame (wood edge demonstrates). > test(p-b).mkv

[Barough]

x265 v2.1+59-a895b6344a82 (MSYS/MinGW, GCC 6.2.0, 32 & 64bit 8/10/12bit multilib EXEs)

[pradeeprama]

Originally Posted by Boulder

I did some tests and ran a clip through --limit-tu 0 to 4. To me it seems that the higher the value, the smaller blocks are used. Does this actually mean that I'm sacrificing bitrate but achieving better detail retention and faster encoding speed? I haven't done any frame by frame comparisons yet.

Limit-tu isn't trying to favour smaller TUs over larger TUs at all. It is only trying to limit the depth of recursion that is used. In fact, I would think that you would see larger TUs with limit-tu enabled when compared to no limit-tu.

Can you share your command-lines so that we can comment?

[Boulder]

Originally Posted by pradeeprama

Limit-tu isn't trying to favour smaller TUs over larger TUs at all. It is only trying to limit the depth of recursion that is used. In fact, I would think that you would see larger TUs with limit-tu enabled when compared to no limit-tu.

Can you share your command-lines so that we can comment?

Sure, here's the command line I used to test:

vspipe.exe --y4m "c:\x265\hotfuzz.vpy" - | C:\sources\x265\build\vc14-x86_64\Release\x265.exe --input - --y4m --input-depth 16 
--dither --sar 1:1 --profile main10  --keyint 480 --ref 5 --rskip --colormatrix "bt709" --colorprim "bt709" --transfer "bt709" 
--preset slower --rc-lookahead 60 --deblock -3:-1 --no-strong-intra-smoothing  --limit-refs 3 --limit-modes --limit-tu 0 
--tu-inter-depth 4 --tu-intra-depth 4 --merange 38 --tune grain --crf 21 --csv q:\hotfuzz_limittu0.csv --csv-log-level 2 --output "q:\hotfuzz_limittu0.hevc"

Here are the csv logfiles from my five encodes at different values for --limit-tu : https://drive.google.com/open?id=0Bz...HJLdVNfRDdNbWM

In my tests, the bitrate and encoding speed was as follows:

--limit-tu 0 : 4875.60 kbps, 1.64 fps
--limit-tu 1 : 4899.45 kbps, 1.84 fps
--limit-tu 2 : 4990.49 kbps, 1.93 fps
--limit-tu 3 : 5037.98 kbps, 1.99 fps
--limit-tu 4 : 5044.37 kbps, 2.02 fps

The black mattes were cropped and the result downsized to 1280x544. The original source clip is here: https://drive.google.com/open?id=0Bz...khsX3RuZGhWcjA

[burfadel]

Which did you find looked better?

[Boulder]

Originally Posted by burfadel

Which did you find looked better?

It's really hard to tell. I could even say that there is no clear winner there, especially if you don't use still frames to compare.

[K.i.N.G]

Hi anyone know if it is possible to use the x265 encoder on android devices?

I've got a Nvidia Shield (Tegra X1 cpu) which encodes x264 pretty well (via the plex app).
So since x264 works on it, I 'assume' x265 is possible aswell?

I googled it a few times and searched in the play store but I can't find any apps/tools available (yet)..

[sneaker_ger]

I assume Plex is using Nvidia's H.264/AVC encoder, not x264. Running x264 or x265 would be slow on the Shield's CPU. Likewise, you'd need an app that uses Nvidia's H.265/HEVC encoder for fast H.265/HEVC encoding. Maybe you can ask Plex developers if they are willing to add this functionality.

[LigH]

If you can compile x26* for this target OS and CPU architecture, you can probably also use the encoder on it; but I would not recommend using mobile devices for such time and energy consuming tasks. Such CPUs may preferably save energy, instead of executing highly efficient SIMD instructions. And x265 requires a magnitude more processing power than x264, and highly efficient instruction extensions (especially vector math extensions like AVX) help x265 a lot more. Tegra X1 is highly parallelized, but will probably have a lower complexity in available instructions. And x265 does not require maximum parallelizability, instead rather wide and purpose-relevant SIMD and vector instructions.

[filler56789]

x265 v. 2.1+60

http://forum.videohelp.com/threads/3...=1#post2467866

[K.i.N.G]

Originally Posted by sneaker_ger

I assume Plex is using Nvidia's H.264/AVC encoder, not x264. Running x264 or x265 would be slow on the Shield's CPU. Likewise, you'd need an app that uses Nvidia's H.265/HEVC encoder for fast H.265/HEVC encoding. Maybe you can ask Plex developers if they are willing to add this functionality.

Yeah that's what I thought but the presets they use are exactle named as the x264 ones... so I later 'assumed/hoped' it could be x264.
Plex also runs on multiple platforms which many aren't intel and/or nvidia related (windows, unix, my NAS, etc...)

anyway, you're right about contacting them. Wil do so.

Originally Posted by LigH

If you can compile x26* for this target OS and CPU architecture, you can probably also use the encoder on it; but I would not recommend using mobile devices for such time and energy consuming tasks. Such CPUs may preferably save energy, instead of executing highly efficient SIMD instructions. And x265 requires a magnitude more processing power than x264, and highly efficient instruction extensions (especially vector math extensions like AVX) help x265 a lot more. Tegra X1 is highly parallelized, but will probably have a lower complexity in available instructions. And x265 does not require maximum parallelizability, instead rather wide and purpose-relevant SIMD and vector instructions.

its not really a portable device though and its cpu/gpu got some more punch (still not close to an i7 or i5 naturally)...
And the reason I want to use it for encoding is exactly the point you bring up: time & power...
I dont need the power of my media station as much as I need my work station
I wouldnt mind if it needs a whole week. As long as I can set it as a lower priority task so i can watch a movie from time to time in between.

[LigH]

OK, so I maybe confused the "controller tablet" with the host on one hand, and CPU with GPU on the other, when I first read another source of technical facts.

According to the English Wikipedia, the Tegra X1 has a Dual QuadCore structure (four ARM Cortex-A57 cores and four ARM Cortex-A53 cores in big.LITTLE configuration). And this "big.LITTLE" architecture may cause some issues, as I recently read: Threads can be shifted between either kind of CPU, depending on their processing power demand, and must always be aware of whether they run on a CPU with a small or a large cache line. And efficient use of cache lines is a very important speed optimization strategy.

My conclusion for now would be that x265 developers would need to double-check strategies to support this architecture class. They would neither wish to get their threads shifted to a low-power core, nor would they enjoy data corruption due to false assumptions about cache line capacities in an unfortunate moment.

[K.i.N.G]

Well,... I looked again and it's indeed using the x264 encoder.
Don't know why I missed the obvious the last time I checked... oh well



And got a reply in the plex forums aswell (yes, i'm feeling stupid now)
:
"Yes, it is the x.264 library in a highly customized version of ffmpeg."
So how hard would it be to include x265?

[LigH]

As I tried to explain: Probably harder than supporting multi-socket systems with identical CPUs. The CPUs in a big.LITTLE system are not identical, therefore its support needs special care.

Well, and if it can be supported at all ... then the PLEX team would have to release a new ffmpeg built for their specific purposes, and now including libx265.

[K.i.N.G]

Originally Posted by LigH

As I tried to explain: Probably harder than supporting multi-socket systems with identical CPUs. The CPUs in a big.LITTLE system are not identical, therefore its support needs special care.

Well, and if it can be supported at all ... then the PLEX team would have to release a new ffmpeg built for their specific purposes, and now including libx265.

Ok, so if I get it correctly the already heavily modified ffmpeg they have already (to make x264 work on it) would not be enough?
To support x265 they need to heavily re-adjust it again? Too much difference between x264 and x265?

Sounds like you're pretty sure it wont happen anytime soon...
I think it will happen eventually at some point though...

[LigH]

I don't know how "heavily" PLEX had to modify ffmpeg. I just assume they did not include libx265, like libx264. Possibly because there is no certain support for your platform (OS and CPUs) yet. Because x265 depends a lot on optimal use of the available CPU architecture, it would be a very bad idea to compile it without any assembler optimization; yet, it may be possible. But in this case, expecting a week per movie is not unrealistic. Nevertheless, the mentioned problems with the big.LITTLE architecture may also happen for code generated by C/C++ compilers only, this is a general risk factor.

[K.i.N.G]

Ok, thank you for your patience and the great explanation