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 23rd November 2016, 03:48   #4421  |  Link
x265_Project
Registered User
 
Join Date: Jul 2013
Posts: 596
Quote:
Originally Posted by nevcairiel View Post
This is just HEVC Advanced though, how is the MPEG-LA's stance on this?
At the moment, there is no change in their license program. I'm optimistic that the companies who have pooled their HEVC patents in MPEG LA's license program will recognize the wisdom of adopting this policy enabling most software implementations to be royalty free.
x265_Project is offline   Reply With Quote
Old 23rd November 2016, 07:09   #4422  |  Link
burfadel
Registered User
 
Join Date: Aug 2006
Posts: 2,234
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.
burfadel is offline   Reply With Quote
Old 23rd November 2016, 11:12   #4423  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,968
x265 2.1+59-a895b6344a82

CLI changes:
Code:
(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
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 23rd November 2016, 11:40   #4424  |  Link
burfadel
Registered User
 
Join Date: Aug 2006
Posts: 2,234
Quote:
Originally Posted by LigH View Post
x265 2.1+59-a895b6344a82

CLI changes:
Code:
(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.

Last edited by burfadel; 23rd November 2016 at 11:43.
burfadel is offline   Reply With Quote
Old 23rd November 2016, 12:45   #4425  |  Link
Gravitator
Registered User
 
Join Date: May 2014
Posts: 170
Megablock very bad impact on the formation of each of the second frame (wood edge demonstrates). > test(p-b).mkv
Gravitator is offline   Reply With Quote
Old 23rd November 2016, 14:30   #4426  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 337
x265 v2.1+59-a895b6344a82 (MSYS/MinGW, GCC 6.2.0, 32 & 64bit 8/10/12bit multilib EXEs)
Barough is offline   Reply With Quote
Old 23rd November 2016, 16:38   #4427  |  Link
pradeeprama
Registered User
 
Join Date: Sep 2015
Posts: 48
Quote:
Originally Posted by Boulder View Post
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?
pradeeprama is offline   Reply With Quote
Old 23rd November 2016, 17:30   #4428  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,636
Quote:
Originally Posted by pradeeprama View Post
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:

Code:
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
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...

Last edited by Boulder; 23rd November 2016 at 17:35.
Boulder is offline   Reply With Quote
Old 23rd November 2016, 22:41   #4429  |  Link
burfadel
Registered User
 
Join Date: Aug 2006
Posts: 2,234
Which did you find looked better?
burfadel is offline   Reply With Quote
Old 24th November 2016, 04:59   #4430  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,636
Quote:
Originally Posted by burfadel View Post
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.
__________________
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 24th November 2016, 18:25   #4431  |  Link
K.i.N.G
Registered User
 
Join Date: Aug 2009
Posts: 72
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)..

Last edited by K.i.N.G; 24th November 2016 at 18:29.
K.i.N.G is offline   Reply With Quote
Old 24th November 2016, 19:14   #4432  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,494
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.
sneaker_ger is offline   Reply With Quote
Old 24th November 2016, 20:34   #4433  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,968
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.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid

Last edited by LigH; 24th November 2016 at 20:53.
LigH is offline   Reply With Quote
Old 25th November 2016, 01:45   #4434  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 955
x265 v. 2.1+60

http://forum.videohelp.com/threads/3...=1#post2467866
filler56789 is offline   Reply With Quote
Old 27th November 2016, 14:06   #4435  |  Link
K.i.N.G
Registered User
 
Join Date: Aug 2009
Posts: 72
Quote:
Originally Posted by sneaker_ger View Post
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.

Quote:
Originally Posted by LigH View Post
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.

Last edited by K.i.N.G; 28th November 2016 at 01:29.
K.i.N.G is offline   Reply With Quote
Old 27th November 2016, 17:20   #4436  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,968
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.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 28th November 2016, 02:35   #4437  |  Link
K.i.N.G
Registered User
 
Join Date: Aug 2009
Posts: 72
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?

Last edited by K.i.N.G; 28th November 2016 at 02:44.
K.i.N.G is offline   Reply With Quote
Old 28th November 2016, 08:43   #4438  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,968
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.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 28th November 2016, 16:48   #4439  |  Link
K.i.N.G
Registered User
 
Join Date: Aug 2009
Posts: 72
Quote:
Originally Posted by LigH View Post
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...
K.i.N.G is offline   Reply With Quote
Old 28th November 2016, 16:55   #4440  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,968
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.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH 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 03:55.


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