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 28th July 2016, 15:44   #4061  |  Link
nakTT
Registered User
 
Join Date: Dec 2008
Posts: 386
Quote:
Originally Posted by LigH View Post
XhmikosR recently released an MSYS / MinGW / GCC 6.1.0 package (2016-07-08); so I built x265 binaries for you to cross-compare compilers and linking types of mostly the same generic options, just including the pentium4/generic flag pair Ma suggested for Win32 builds (at least I hope I did it right, please check).

x265 2.0+10-5a0e139e2938 (GCC 5.3.0)
x265 2.0+10-5a0e139e2938 (GCC 6.1.0)
Thanks. It works fine.

I'm using the 64bit version of the GCC 6.1.0 build.

Based on my limited testing, it seems that the 8bit version is close to 75% faster than the 12bit version. Both using Very Slow preset.

Thanks for the executables and hope you would release a new executibles as the encoder get updated.

Last edited by nakTT; 28th July 2016 at 18:54.
nakTT is offline   Reply With Quote
Old 28th July 2016, 19:35   #4062  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,956
I will. Once in a while. Especially when important updates were published.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 28th July 2016, 20:10   #4063  |  Link
brumsky
Registered User
 
Join Date: Jun 2016
Posts: 116
Quote:
Originally Posted by Rogatti View Post
X265 (anime 1.2GB)
-

-
-
X264 (anime 4.7GB)
-

Thanks for the images. I don't argue that the quality of x265 has improved significantly from even a year ago.

I'm still on the fence with the encoding time... All three systems I have are only AVX, none of them have AVX2 which gave a decent speed boost.
brumsky is offline   Reply With Quote
Old 28th July 2016, 20:15   #4064  |  Link
brumsky
Registered User
 
Join Date: Jun 2016
Posts: 116
Quote:
Originally Posted by Khun_Doug View Post
You surely asked a good question aymanalz, and one that I have pondered abundantly lately. For the time being I have decided to stay with x264 until the speed of x265 gets some serious attention. The price of disk is cheap. I added 5TB USB for just over $100. With x264 I usually encode at CRF 20, but sometimes as low as CRF 15. For my HD media I usually go 2 pass with nothing short of 10,000 kbit. I did some test encodes with x265 and calculated the encode time for a full movie would be in excess of 48 hours of solid machine time. The same film encodes in under 5 hours in x264. I don't care that the encoded film is 8 GB in x264 and may be les sin x265. I don't have 48 hours or more of dedicated machine time to use for single encodes.

I can revisit using x265 seriously for my video library once the speed issue is resolved. In the meantime, I am enjoying testing and evaluating it. I feel there is great promise and progress forthcoming.
Disk space is pretty cheap. However, I do like the lower bitrate for streaming media.
brumsky is offline   Reply With Quote
Old 28th July 2016, 20:34   #4065  |  Link
gamebox
Registered User
 
Join Date: Nov 2011
Posts: 66
While changing some random setting in Media Player Classic I noticed something awkward. My Output filter is set to "Enhanced Video Renderer", and below that is a setting for "resizer" where "Bilinear" was selected by default. After I changed it to one of "Bicubic" settings offered, image sharpness in full-screen mode improved dramatically (I use a Full-HD display and mostly play content encoded below that resolution)!

Could that be the stupid cause for "unexplainable" image softness most people notice with HEVC? When playing H.264 many systems (mine included) use built-in GPU decoders through DXVA, where software resize options might not have influence at all.

Which software do you use for playing HEVC videos?

Last edited by gamebox; 28th July 2016 at 20:48.
gamebox is offline   Reply With Quote
Old 28th July 2016, 21:14   #4066  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 337
I mainly use MPC-BE with default settings. Haven't bothered with tweaking the settings since im pleased with how it looks.

Sent from my Samsung Galaxy S7 edge via Tapatalk
Barough is offline   Reply With Quote
Old 28th July 2016, 21:45   #4067  |  Link
brumsky
Registered User
 
Join Date: Jun 2016
Posts: 116
I have dual E5-2670 v1 which only have AVX. Anyone here with an equivalent setup with AVX2? What speeds are you averaging given your settings of course.

I use a slightly modified version of littlepox's settings. I'm trying to keep the bitrate down a bit for archival. I average 4.5 - 5.5 FPS with these settings.

Code:
--profile main10 --output-depth 10 --ctu 32 --bframes 8 --rc-lookahead 80 --scenecut 40 --ref 5 --limit-refs 0 --me 1 --merange 25 --subme 3 --no-rect --no-amp --limit-modes --max-merge 4 --no-early-skip --b-intra
--no-sao --signhide --weightp --weightb --aq-mode 3 --aq-strength 0.8 --cutree --rd 4  --tu-intra-depth 3 --tu-inter-depth 3 --psy-rd 2.0 --psy-rdoq 2.0 --rdoq-level 2 --lookahead-slices 4 --qcomp 0.65
 --no-strong-intra-smoothing --deblock -1:-1 --qg-size 32
I'm curious what a E5-2640 v3 might get on average compared to my setup. They are the same speed 2.6ghz...

Last edited by brumsky; 28th July 2016 at 21:46. Reason: --rd 4 not 3
brumsky is offline   Reply With Quote
Old 28th July 2016, 22:11   #4068  |  Link
aymanalz
Registered User
 
Join Date: May 2015
Posts: 67
Quote:
Originally Posted by LigH View Post
It has an impact to the quality/size ratio, but it is not necessarily responsible for better quality in general. If you don't care much about the size, remember: if motion search doesn't find a good enough match for inter coding (motion vector + difference), intra coding (independent newly coded content) is used, which just requires more space, but if the output size is not restricted directly, quality can still be convenient.

Quality gets only worse if you have a limited average or maximum bitrate, which could only be achieved by coarser quantization if too many intra blocks take too much of the overall bitrate. Fortunate motion search matches could have spared bitrate, and finding them requires a more or less thorough search for them.
Right, when I said "quality", I meant quality at a certain bitrate. I should have specified that. When doing 2-pass encodes at a certain average bitrate, isn't the choice of motion estimation method be one of the more important determiners? If I need to encode at a certain bitrate, what other setting would have significant impact on the quality/size ratio? How important in ME method, and what other factors are important?

(For me, it's mostly high definition movies and HD home videos, all in x264, which I want to re-encode at about 30% of original bitrate.)
aymanalz is offline   Reply With Quote
Old 29th July 2016, 11:43   #4069  |  Link
divxmaster
Registered User
 
Join Date: Mar 2015
Location: New Zealand
Posts: 45
30% of the original bitrate? You wont get that, but you may get 30% reduction in bitrate. That is what I am seeing. I am currently reencoding ds9, and the latest x265 is excellent, but only with no-sao. Bitrate is about 60% of x264, and the quality is better. Admittedly some of that is that I now have run smdegrain over it.

Ok, now time for something weird. The ultimate x265 low bitrate test. As per previous posts, I have encoded sg1, 480p, low bitrate for mobile devices. I took a 1.36MB chunk of an episode, 1min 7 seconds, and copied it on to a FLOPPY DISK. And guess what, it played it no problem! buffered for 16 seconds and then played the remaining 51 seconds fine. In fact it finished reading the disk after it had played 30 seconds, so the floppy disk transfer rate was too fast! So a great testament to how good x265 is at low bitrates. What about bluray from floppy disk? lets see now...

Last edited by divxmaster; 29th July 2016 at 11:46.
divxmaster is offline   Reply With Quote
Old 29th July 2016, 12:10   #4070  |  Link
aymanalz
Registered User
 
Join Date: May 2015
Posts: 67
Quote:
Originally Posted by divxmaster View Post
30% of the original bitrate? You wont get that, but you may get 30% reduction in bitrate. That is what I am seeing. I am currently reencoding ds9, and the latest x265 is excellent, but only with no-sao. Bitrate is about 60% of x264, and the quality is better. Admittedly some of that is that I now have run smdegrain over it.
As I said, I'm using 2-pass encode, so I can choose the bitrate. I don't mind a slight degradation in quality, which is why I'm encoding at 30%-50% of original bitrate. But I'd like to know how I can get maximum possible quality, for the target bitrate I choose.

About SAO that you mention, that's an aspect I'd like to know as well. Are others too experiencing noticeable loss of quality due to SAO? The developers have stated that SAO was improved in 2.0.
aymanalz is offline   Reply With Quote
Old 29th July 2016, 12:51   #4071  |  Link
divxmaster
Registered User
 
Join Date: Mar 2015
Location: New Zealand
Posts: 45
Yes, the testing of the 'new' SAO in 2.0 is one thing I have to get around to doing. But as far as fixed bitrate goes, for me I wouldn't do that. The bitrate required is way to variable. In crf mode, I have some 576p that uses a bitrate of 450-500, but other 576p uses a bitrate of 1000-1200! And the 450-500 looks better in this instance.
divxmaster is offline   Reply With Quote
Old 29th July 2016, 15:02   #4072  |  Link
burfadel
Registered User
 
Join Date: Aug 2006
Posts: 2,234
Output bitrate depends on the quality of the source. A poor quality source means you also encode the poor quality elements. A lot of these are random so increases encode complexity.
burfadel is offline   Reply With Quote
Old 29th July 2016, 16:13   #4073  |  Link
MeteorRain
結城有紀
 
Join Date: Dec 2003
Location: NJ; OR; Shanghai
Posts: 621
Yuuki Asuna Mod
x265-Yuuki-2.0M+9-g457336f+14.7z
x265-Asuna-2.0+2-ge16e208+14.7z
MeteorRain is offline   Reply With Quote
Old 29th July 2016, 23:14   #4074  |  Link
dipje
Registered User
 
Join Date: Oct 2014
Posts: 270
Quote:
Originally Posted by shinchiro View Post
Since it has been 3 years x265 under development, is there any news about gpu acceleration?
I thought they had that pretty much from the start, but in the commercial license stuff, not the opensource x265 stuff.

Does x264 have decent gpu acceleration after all those years?? . OpenCL lookaheads came eventually - very late - and contribute not much.. I don't expect much to change for x265.

Pretty much accelerated hevc encoding already exist on the recent GPUs and there are commandline tools to use it, but you have to do with the quality it provides, not much to improve upon.
dipje is offline   Reply With Quote
Old 30th July 2016, 04:50   #4075  |  Link
JohnLai
Registered User
 
Join Date: Mar 2008
Posts: 448
Quote:
Originally Posted by dipje View Post
I thought they had that pretty much from the start, but in the commercial license stuff, not the opensource x265 stuff.

Does x264 have decent gpu acceleration after all those years?? . OpenCL lookaheads came eventually - very late - and contribute not much.. I don't expect much to change for x265.

Pretty much accelerated hevc encoding already exist on the recent GPUs and there are commandline tools to use it, but you have to do with the quality it provides, not much to improve upon.
Perhaps they could offload motion estimation section, after all, both Intel and Nvidia (no AMD) support external motion estimation mode only. Then again........it probably will be rejected in the name of 'open source' where there is no room for proprietary code or maybe there isn't any speed gain from it....or nobody is willing to work on it....pick one ~.~
JohnLai is offline   Reply With Quote
Old 30th July 2016, 07:46   #4076  |  Link
aegisofrime
Registered User
 
Join Date: Apr 2009
Posts: 462
Quote:
Originally Posted by JohnLai View Post
Perhaps they could offload motion estimation section, after all, both Intel and Nvidia (no AMD) support external motion estimation mode only. Then again........it probably will be rejected in the name of 'open source' where there is no room for proprietary code or maybe there isn't any speed gain from it....or nobody is willing to work on it....pick one ~.~
So is there no possible way to offload some of the processing to the fixed function units on Intel and AMD chips?

Quote:
Originally Posted by brumsky View Post
Thanks for the images. I don't argue that the quality of x265 has improved significantly from even a year ago.

I'm still on the fence with the encoding time... All three systems I have are only AVX, none of them have AVX2 which gave a decent speed boost.
I used to be on the same boat as you. But one thing that you have to understand is that the presets of x264 and x265 are not comparable. For me, x265's medium is roughly comparable in quality and speed as x264's slow, but with smaller file size of course.

Last edited by aegisofrime; 30th July 2016 at 07:50.
aegisofrime is offline   Reply With Quote
Old 30th July 2016, 08:19   #4077  |  Link
JohnLai
Registered User
 
Join Date: Mar 2008
Posts: 448
Quote:
Originally Posted by aegisofrime View Post
So is there no possible way to offload some of the processing to the fixed function units on Intel and AMD chips?
It is possible, an excerpt from NVENC documentation :

NVENC can be used as a hardware accelerator to perform motion search and generate motion vectors and mode information only. The resulting motion vectors or mode decisions can used, for example, in motion compensated filtering or for supporting other codecs not fully supported by NVENC or simply as motion vector hints for a custom encoder.

Sample code from nvenc :

/**
* Motion vector structure per CU for HEVC motion estimation.
*/
typedef struct _NV_ENC_HEVC_MV_DATA
{
NV_ENC_MVECTOR mv[4]; /**< up to 4 vectors within a CU */
uint8_t cuType; /**< 0 (I), 1(P), 2 (Skip) */
uint8_t cuSize; /**< 0: 8x8, 1: 16x16, 2: 32x32, 3: 64x64 */
uint8_t partitionMode; /**< The CU partition mode
0 (2Nx2N), 1 (2NxN), 2(Nx2N), 3 (NxN),
4 (2NxnU), 5 (2NxnD), 6(nLx2N), 7 (nRx2N) */
uint8_t lastCUInCTB; /**< Marker to separate CUs in the current CTB from CUs in the next CTB */
} NV_ENC_HEVC_MV_DATA;

/**
* Creation parameters for output motion vector buffer for ME only mode.
*/
typedef struct _NV_ENC_CREATE_MV_BUFFER
{
uint32_t version; /**< [in]: Struct version. Must be set to NV_ENC_CREATE_MV_BUFFER_VER */
NV_ENC_OUTPUT_PTR mvBuffer; /**< [out]: Pointer to the output motion vector buffer */
uint32_t reserved1[255]; /**< [in]: Reserved and should be set to 0 */
void* reserved2[63]; /**< [in]: Reserved and should be set to NULL */
} NV_ENC_CREATE_MV_BUFFER;

/** NV_ENC_CREATE_MV_BUFFER struct version*/
#define NV_ENC_CREATE_MV_BUFFER_VER NVENCAPI_STRUCT_VERSION(1)


Of course, there are lotta lines of code before ME step, such as buffer creation + reference frame + buffer locking + buffer pointer location and finally the last step buffer destruction + release.

Questions are.....how to port the code for x265 or can it be done in first place? Who will do it for free? Is there any licensing issue?

Last edited by JohnLai; 30th July 2016 at 08:28.
JohnLai is offline   Reply With Quote
Old 30th July 2016, 10:25   #4078  |  Link
burfadel
Registered User
 
Join Date: Aug 2006
Posts: 2,234
Quote:
Originally Posted by brumsky View Post
I have dual E5-2670 v1 which only have AVX. Anyone here with an equivalent setup with AVX2? What speeds are you averaging given your settings of course.

I use a slightly modified version of littlepox's settings. I'm trying to keep the bitrate down a bit for archival. I average 4.5 - 5.5 FPS with these settings.

Code:
--profile main10 --output-depth 10 --ctu 32 --bframes 8 --rc-lookahead 80 --scenecut 40 --ref 5 --limit-refs 0 --me 1 --merange 25 --subme 3 --no-rect --no-amp --limit-modes --max-merge 4 --no-early-skip --b-intra
--no-sao --signhide --weightp --weightb --aq-mode 3 --aq-strength 0.8 --cutree --rd 4  --tu-intra-depth 3 --tu-inter-depth 3 --psy-rd 2.0 --psy-rdoq 2.0 --rdoq-level 2 --lookahead-slices 4 --qcomp 0.65
 --no-strong-intra-smoothing --deblock -1:-1 --qg-size 32
I'm curious what a E5-2640 v3 might get on average compared to my setup. They are the same speed 2.6ghz...
Those settings are all over the place. try the following:
Quote:
--output-depth 10 --rd 4 --tu-intra-depth 3 --rdoq-level 2 --early-skip --fast-intra --b-intra --tskip --tskip-fast --limit-modes --aq-mode 2 --qg-size 16 --me star --merange 25 --max-merge 3 --weightb --bframes 6 --rc-lookahead 40 --ref 6 --psy-rdoq 1.38
The merange of 25 is good performance, but it depends on what resolution you are encoding. I have found that the ideal number is the vertical resolution you are encoding to, divided by 1080, multiplied by 57.

So:
480
---- x 57
1080

Equals 25.33, which is why 25 seems to be optimal for 480P If you are doing 720P, likewise:

480
---- x 57
1080

Equals 38. Now in effect, the 25 and 38 takes you to the equivalent point in the picture, since there are more pixels between the two points at 720P than 480P. For b-frames, I found around 6 is ideal for normal content, but maybe 8 for animation. Setting this too high just leads to more encode time with little efficiency benefit. In the stats at the end of the encode, you can see the percentages for the consecutive b-frames. The first number is 0, so if there are 7 numbers the seventh one relates to 6 consecutive b-frames. You will see the percentages can be quite low at the top end, any less than a few percent it wouldn't be worth the extra encode time. Instead of a B frame in that instance, a P frame would be used instead.

For example, for a few recent recent encodes (x265 2.0+11) I got:
Quote:
x265 [info]: consecutive B-frames: 8.6% 3.0% 6.1% 37.1% 15.3% 23.4% 6.5%
x265 [info]: consecutive B-frames: 6.3% 1.8% 4.5% 35.4% 22.3% 21.4% 8.4%
x265 [info]: consecutive B-frames: 9.7% 5.2% 10.1% 33.7% 13.2% 21.0% 7.1%
The 6.5%, 8.4%, and 7.1% relate to the 6th b-frame. I found no matter what the source, if I selected 7 or higher for testing the 7th and so on frame percentage was very low. That is why I settled on 6 b-frames as optimal.

The other options are a balance of speed and quality. Also note I set --tu-intra-depth 3 as this shows benefits for little peformance cost, however I did not option --tu-inter-depth 3, as it didn't show any noticeable quality or compression improvements, and just slowed down the encode.
The settings -early-skip --fast-intra --tskip --tskip-fast --limit-modes are all performance related, they noticeably improve speed when all used together but really don't impact the quality of the output. Give the settings I listed a go exactly as written apart from the --merange calculation (no other changes) and see how the speed compares to quality.

EDIT:
Forgot to mention, the above is solely the options on the command line. That is, not using any other preset as a basis. The crf (not stated) should be set to the desired amount. I would suggest maybe something a little lower than the default but within what would give you a desirable end file size. You can use decimals, so you could set it to 21.2 if you wanted (for example).

Last edited by burfadel; 30th July 2016 at 19:36.
burfadel is offline   Reply With Quote
Old 30th July 2016, 15:00   #4079  |  Link
JohnLai
Registered User
 
Join Date: Mar 2008
Posts: 448
Quick question, why does x265 preset doesn't make use of b-adapt 1(fast)?
All presets either use 0(none) or 2(full). Is there anything wrong with 1(fast)?
JohnLai is offline   Reply With Quote
Old 30th July 2016, 21:41   #4080  |  Link
Rogatti
Registered User
 
Join Date: Jun 2015
Posts: 5
Quote:
Originally Posted by brumsky View Post
Thanks for the images. I don't argue that the quality of x265 has improved significantly from even a year ago.

I'm still on the fence with the encoding time... All three systems I have are only AVX, none of them have AVX2 which gave a decent speed boost.
"speed" certainly x264.
-
benefit cost (quality + size) = x265 .
Rogatti 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 06:42.


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