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 26th July 2016, 09:49   #4041  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,880
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)
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is online now   Reply With Quote
Old 26th July 2016, 18:32   #4042  |  Link
Ma
Registered User
 
Join Date: Feb 2015
Posts: 324
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).
Everything works OK.
Speed comparison of 32-bit builds on i5 3450S (AVX), input file file 1920x800, no special options:
Code:
 bits |      GCC 5.3      |      GCC 6.1
 8bit |  95.37s (7.86 fps)|  83.15s (9.02 fps)
10bit | 435.44s (1.72 fps)| 328.79s (2.28 fps)
12bit | 436.29s (1.72 fps)| 328.16s (2.29 fps)
GCC 5.3 builds with option "-march=pentium4 -mtune=generic" should be also faster (and at 10/12 bit faster than GCC 6.1).
Ma is offline   Reply With Quote
Old 26th July 2016, 19:26   #4043  |  Link
jlpsvk
Registered User
 
Join Date: Dec 2014
Posts: 190
Quote:
Originally Posted by LigH View Post
The search for motion vectors in different ME modes is more or less exhaustive; "star" will probably prefer vertical and horizontal directions, but won't search as far in diagonal directions, I believe. I never saw descriptive diagrams yet, though... But fewer directions means faster speed, obviously.
In terms of visual quality, should they be the same? It's only compressibility thing? I think so.

What are you thinking about some using LimitedSharpenFaster or LSFmod to slightly sharpen the image....

And...what's better/faster in x265? me UMH or STAR?

Last edited by jlpsvk; 26th July 2016 at 19:44.
jlpsvk is offline   Reply With Quote
Old 26th July 2016, 19:51   #4044  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,880
@ Ma:

I think I used your additional options for the GCC 5.3.0 build as well. That was on another PC... Maybe compare with v2.0+9 which certainly did not have these options set; the changes to v2.0+10 should be small or not relevant in this case, IIRC.
_

@ jlpsvk:

When motion search does not find a good enough match to inter-code a block, it has to be intra-coded, which requires more space and reduces the efficiency. Therefore, a more exhaustive search may improve the efficiency of an encode. Depending on the material. If there are almost only short or perpendicular motions, star would be efficient enough. Could you know beforehand?

Artifical sharpening usually worsens the compressibility. It requires spending more bits for high frequency parameters to be encoded without noticeable artifacts.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is online now   Reply With Quote
Old 26th July 2016, 19:55   #4045  |  Link
jlpsvk
Registered User
 
Join Date: Dec 2014
Posts: 190
Quote:
Originally Posted by LigH View Post
@ Ma:

I think I used your additional options for the GCC 5.3.0 build as well. That was on another PC... Maybe compare with v2.0+9 which certainly did not have these options set; the changes to v2.0+10 should be small or not relevant in this case, IIRC.
_

@ jlpsvk:

When motion search does not find a good enough match to inter-code a block, it has to be intra-coded, which requires more space and reduces the efficiency. Therefore, a more exhaustive search may improve the efficiency of an encode. Depending on the material. If there are almost only short or perpendicular motions, star would be efficient enough. Could you know beforehand?

Artifical sharpening usually worsens the compressibility. It requires spending more bits for high frequency parameters to be encoded without noticeable artifacts.
Encoding mainly blurays. Starting converting all my BD's to HEVC (as I have VU+ Solo 4K DVB-S2 receiver, which plays 10bit HEVC also, so I will spare lot of space on my RAID). Right now my selected settings:
Code:
--crf 19 --output-depth 10 --level-idc 5.1 --cbqpoffs -3 --me umh --rc-lookahead 60 --ref 4 --min-keyint 23 --keyint 240 --no-open-gop --colorprim bt709 --colormatrix bt709 --transfer bt709 --rskip --crqpoffs -3 --high-tier
Looking for balance speed/quality/size.
jlpsvk is offline   Reply With Quote
Old 26th July 2016, 20:23   #4046  |  Link
froggy1
ffx264/ffhevc author
 
froggy1's Avatar
 
Join Date: May 2007
Location: Belgium
Posts: 1,474
Quote:
Originally Posted by jlpsvk View Post
Encoding mainly blurays. Starting converting all my BD's to HEVC (as I have VU+ Solo 4K DVB-S2 receiver, which plays 10bit HEVC also, so I will spare lot of space on my RAID). Right now my selected settings:
Code:
--crf 19 --output-depth 10 --level-idc 5.1 --cbqpoffs -3 --me umh --rc-lookahead 60 --ref 4 --min-keyint 23 --keyint 240 --no-open-gop --colorprim bt709 --colormatrix bt709 --transfer bt709 --rskip --crqpoffs -3 --high-tier
Looking for balance speed/quality/size.
I would disable --sao if I was you. seems to blur too much. it will also speed things a little bit up. Also, bump up psy-rdoq if you have (lots of) noise and want to preserve it. I use a value of 6.0 and psy-rd of 3.5
__________________
ffx264--ffhevc--ffxvid

Last edited by froggy1; 26th July 2016 at 20:26.
froggy1 is online now   Reply With Quote
Old 26th July 2016, 20:23   #4047  |  Link
jlpsvk
Registered User
 
Join Date: Dec 2014
Posts: 190
Quote:
Originally Posted by froggy1 View Post
I will disable --sao if I was you. seems to blur too much
--no-sao ???
jlpsvk is offline   Reply With Quote
Old 26th July 2016, 20:25   #4048  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,880
By "material", I rather mean rather little or much action, rather random or regular motion, short or far range. The fact that they are stored on Blu-ray is less relevant...

If you focus on Hollywood blockbusters, you will probably have to expect much random and rather far motion, therefore a more exhaustive search may be more efficient for the quality/size ratio, but cost some speed. In case of nature documentaries, there are different attributes...
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is online now   Reply With Quote
Old 26th July 2016, 21:05   #4049  |  Link
froggy1
ffx264/ffhevc author
 
froggy1's Avatar
 
Join Date: May 2007
Location: Belgium
Posts: 1,474
Quote:
Originally Posted by jlpsvk View Post
--no-sao ???
yes, and you can also do a --no-amp, will up the performance a bit with no visual degradation. But keep --rect
__________________
ffx264--ffhevc--ffxvid
froggy1 is online now   Reply With Quote
Old 27th July 2016, 12:51   #4050  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,562
Is the scenechange detection essentially the same as in x264? I just encoded the exact same video with both and x264 produced 1411 I-frames while the x265 encode has 1611 I-frames. The length of the source (Zootropolis) is 156147 frames.
__________________
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 27th July 2016, 23:55   #4051  |  Link
brumsky
Registered User
 
Join Date: Jun 2016
Posts: 111
Personal Opinion

What is everyone's opinion of x265? Is it worth the longer encoding time compared to x264?
brumsky is offline   Reply With Quote
Old 28th July 2016, 00:49   #4052  |  Link
aymanalz
Registered User
 
Join Date: May 2015
Posts: 46
Quote:
Originally Posted by LigH View Post
By "material", I rather mean rather little or much action, rather random or regular motion, short or far range. The fact that they are stored on Blu-ray is less relevant...

If you focus on Hollywood blockbusters, you will probably have to expect much random and rather far motion, therefore a more exhaustive search may be more efficient for the quality/size ratio, but cost some speed. In case of nature documentaries, there are different attributes...
Which is the more exhaustive search, umh or star?
aymanalz is offline   Reply With Quote
Old 28th July 2016, 01:10   #4053  |  Link
Rogatti
Registered User
 
Join Date: Jun 2015
Posts: 5
Quote:
Originally Posted by brumsky View Post
What is everyone's opinion of x265? Is it worth the longer encoding time compared to x264?
X265 (anime 1.2GB)
-

-
-
X264 (anime 4.7GB)
-
Rogatti is offline   Reply With Quote
Old 28th July 2016, 04:35   #4054  |  Link
Khun_Doug
Registered User
 
Join Date: Jul 2016
Posts: 70
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.
Khun_Doug is offline   Reply With Quote
Old 28th July 2016, 06:12   #4055  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,880
Quote:
Originally Posted by aymanalz View Post
Which is the more exhaustive search, umh or star?
Hmm, now that I read the docs again ... I believe we need explanations (and even diagrams!) from a person with more insight.

The description of "star" mode sounds as if it is quite adaptive and can be fast if it finds a good match already in the first star pattern search, but will take more time if the other two steps are required in case of a bad match. Speculations.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is online now   Reply With Quote
Old 28th July 2016, 07:22   #4056  |  Link
aymanalz
Registered User
 
Join Date: May 2015
Posts: 46
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.
I said the same thing, when x265 was at version 1.7. My computer at the time was getting about 1.5 FPS! The developers then stated (on this thread, I believe) that they had speed improvements planned for the future, but that they had other priorities to address first. Version 1.8 brought quite a bit of speed improvement, and in my experience, version 2.0 has also made it faster. (Not sure if everybody else has experienced speed improvement with 2.0)

But you are right, they do need to further speed it up, if it is possible to do so. And I really hope it is possible, because as you state, x265 shows tremendous promise over previous codecs. I see that with every encode I make - the quality of output is far better than x264, at similar bitrates. But the encoding speed is still drearily slow for those of us who don't have professional level hardware. Which is why I'm also holding back on re-encoding a ton of HD home videos for now.
aymanalz is offline   Reply With Quote
Old 28th July 2016, 07:45   #4057  |  Link
aymanalz
Registered User
 
Join Date: May 2015
Posts: 46
Quote:
Originally Posted by LigH View Post
Hmm, now that I read the docs again ... I believe we need explanations (and even diagrams!) from a person with more insight.

The description of "star" mode sounds as if it is quite adaptive and can be fast if it finds a good match already in the first star pattern search, but will take more time if the other two steps are required in case of a bad match. Speculations.
The manual states:
Code:
Generally, the higher the number the harder the ME method will try to find an optimal match.
That line suggests that star is more exhaustive, since the "number" is 3 for star and 2 for umh. But it is far from clear, and several posts here gave me the opposite impression.

I hope this gets clarified soon. Isn't it one of the more important determiners of quality?
aymanalz is offline   Reply With Quote
Old 28th July 2016, 09:46   #4058  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,880
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.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is online now   Reply With Quote
Old 28th July 2016, 13:54   #4059  |  Link
shinchiro
Registered User
 
Join Date: Feb 2012
Posts: 46
Since it has been 3 years x265 under development, is there any news about gpu acceleration?
shinchiro is offline   Reply With Quote
Old 28th July 2016, 14:05   #4060  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,880
I doubt x265 development will ever consider GPU support. The complexity of HEVC encoding can easily surpass the limits of most available GPU architecture.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is online now   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 08:48.


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