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 3rd October 2016, 23:00   #4301  |  Link
froggy1
ffx264/ffhevc author
 
froggy1's Avatar
 
Join Date: May 2007
Location: Belgium
Posts: 1,551
Quote:
Originally Posted by mzso View Post
Hi!

Is aliasing a significant issue for x265 (our HEVC)? I came across two separate x265 encoded files of the same thing. The higher bitrate one had some pretty bad aliasing where there were fine patterns. The lower bitrate one was even worse with with more stuff aliased an aliasing being more pronounced.
I haven't read of any... care to provide a sample of the issue?
__________________
ffx264--ffhevc--ffxvid
froggy1 is offline   Reply With Quote
Old 8th October 2016, 00:02   #4302  |  Link
mzso
Registered User
 
Join Date: Oct 2009
Posts: 842
Here are examples of aliasing I saw with x265 encodes:
https://drive.google.com/open?id=0By...UdidHRRenMyQlE

https://drive.google.com/open?id=0By...k5IakRzZDd0eVk

Does anyone have a clue why it happens?
mzso is offline   Reply With Quote
Old 8th October 2016, 04:26   #4303  |  Link
littlepox
Registered User
 
Join Date: Nov 2012
Posts: 218
It's due to the very distinct pattern on his face after down-scaling.
Technically it is called "Moiré pattern".
It has nothing to do with the encoder unless the encoder performs a blur filter before encoding.
littlepox is offline   Reply With Quote
Old 8th October 2016, 17:48   #4304  |  Link
x265_Project
Registered User
 
Join Date: Jul 2013
Posts: 596
Quote:
Originally Posted by mzso View Post
Hi!

Is aliasing a significant issue for x265 (our HEVC)? I came across two separate x265 encoded files of the same thing. The higher bitrate one had some pretty bad aliasing where there were fine patterns. The lower bitrate one was even worse with with more stuff aliased an aliasing being more pronounced.
It looks like something went wrong in a processing step prior to encoding... probably in scaling, or chroma subsampling.
x265_Project is offline   Reply With Quote
Old 9th October 2016, 15:20   #4305  |  Link
Ma
Registered User
 
Join Date: Feb 2015
Posts: 325
There are stability problems with newest Microsoft compilers -- VS 2015 update 3 & VS "15" preview 5. 12-bit x265 compiled with CXXFLAGS=/arch:AVX /GS- /GL hangs at beginning of encoding. (VS 2013 update 5 & VS 2015 update 2 works OK.)

I have a request to a person with AVX2 CPU -- could you test AVX & AVX2 version of 12-bit x265 compiled by VS "15" preview 5 and report back if it works (it hangs at i5 3450S, but it is possible that it works at AVX2 CPU).
VS "15" preview 5 clean builds: http://www.msystem.waw.pl/x265/x265-...393b_vs15p5.7z (it works, no need to test)
AVX-CPU VS "15" preview 5 clean builds: http://www.msystem.waw.pl/x265/x265-..._vs15p5-AVX.7z (x265-12b.exe hangs on AVX CPU)
AVX2-CPU VS "15" preview 5 clean builds: http://www.msystem.waw.pl/x265/x265-...vs15p5-AVX2.7z (not tested -- I don't have AVX2 CPU)
Ma is offline   Reply With Quote
Old 9th October 2016, 19:20   #4306  |  Link
trip_let
Registered User
 
Join Date: Sep 2012
Posts: 47
Quote:
Originally Posted by Ma View Post
There are stability problems with newest Microsoft compilers -- VS 2015 update 3 & VS "15" preview 5. 12-bit x265 compiled with CXXFLAGS=/arch:AVX /GS- /GL hangs at beginning of encoding. (VS 2013 update 5 & VS 2015 update 2 works OK.)

I have a request to a person with AVX2 CPU -- could you test AVX & AVX2 version of 12-bit x265 compiled by VS "15" preview 5 and report back if it works (it hangs at i5 3450S, but it is possible that it works at AVX2 CPU).
VS "15" preview 5 clean builds: http://www.msystem.waw.pl/x265/x265-...393b_vs15p5.7z (it works, no need to test)
AVX-CPU VS "15" preview 5 clean builds: http://www.msystem.waw.pl/x265/x265-..._vs15p5-AVX.7z (x265-12b.exe hangs on AVX CPU)
AVX2-CPU VS "15" preview 5 clean builds: http://www.msystem.waw.pl/x265/x265-...vs15p5-AVX2.7z (not tested -- I don't have AVX2 CPU)
12-bit AVX build from x265-2.1+20-c64393b_vs15p5-AVX.7z and 12-bit AVX2 build from x265-2.1+20-c64393b_vs15p5-AVX2.7z work fine for me.

I let it go for about 1000 frames before I stopped the process. This on a Core i7-6700K.
trip_let is offline   Reply With Quote
Old 9th October 2016, 19:43   #4307  |  Link
Ma
Registered User
 
Join Date: Feb 2015
Posts: 325
Quote:
Originally Posted by trip_let View Post
12-bit AVX build from x265-2.1+20-c64393b_vs15p5-AVX.7z and 12-bit AVX2 build from x265-2.1+20-c64393b_vs15p5-AVX2.7z work fine for me.

I let it go for about 1000 frames before I stopped the process. This on a Core i7-6700K.
Thanks!

It looks like newest M$ compilers emit AVX2 only instruction with /arch:AVX option. I will try to report this bug.
Ma is offline   Reply With Quote
Old 10th October 2016, 21:46   #4308  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 337
x265 v2.1+20-c64393b415ad (MSYS/MinGW, GCC 6.2.0, 32 & 64bit 8/10/12bit multilib EXEs)
Barough is offline   Reply With Quote
Old 11th October 2016, 15:18   #4309  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,956
x265 2.1+20-c64393b415ad (GCC 5.3.0)
x265 2.1+20-c64393b415ad (GCC 6.2.0)

CLI changes since v2.1+2:

Code:
+   --limit-tu <integer>          Enable early exit from TU recursion for inter coded blocks. Default 0

-   --discard-sei                 Discard SEI packets in bitstream. Default disabled
-   --discard-vui                 Discard optional VUI information from the bistream. Default disabled
+   --[no]-vui-timing-info        Discard optional VUI timing information from the bistream. Default enabled
+   --[no]-vui-hrd-info           Discard optional HRD timing information from the bistream. Default enabled
^ The small syntax typo will surely be corrected soon... ([no-]... instead of [no]-...).

The new option --limit-tu sounds interesting to me; I wonder how much speed gain will be possible without a noticable additional loss of quality.
__

P.S.: Don't try --limit-tu >2.

Code:
Invalid limit-tu option, limit-TU must be 0, 1 or 2
In a very brief test with a small video, the results were bit-identical, and no certain speed increase. So I guess an advantage requires specific situations.
__________________

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

Last edited by LigH; 11th October 2016 at 15:40.
LigH is offline   Reply With Quote
Old 11th October 2016, 16:46   #4310  |  Link
fauxreaper
Registered User
 
Join Date: Oct 2014
Posts: 14
Quote:
Originally Posted by LigH View Post
In a very brief test with a small video, the results were bit-identical, and no certain speed increase. So I guess an advantage requires specific situations.
limit-tu only works with tu-inter-depth>1.
fauxreaper is offline   Reply With Quote
Old 11th October 2016, 18:15   #4311  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,977
Quote:
Originally Posted by LigH View Post
x265 2.1+20-c64393b415ad (GCC 5.3.0)
x265 2.1+20-c64393b415ad (GCC 6.2.0)
The new option --limit-tu sounds interesting to me; I wonder how much speed gain will be possible without a noticable additional loss of quality.
__

In a very brief test with a small video, the results were bit-identical, and no certain speed increase. So I guess an advantage requires specific situations.
I have a few more --limit-tu questions as well.
  1. What does the default of 0 do? Is it the same as --no-limit-tu?
  2. Is the expectation that 2 is faster and potentially lower quality than 1?
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 11th October 2016, 18:37   #4312  |  Link
brumsky
Registered User
 
Join Date: Jun 2016
Posts: 116
--limit-tu

@x265_project

Thank you guys so much! I've been wishing for a option like this for some time.

A few quick tests show a performance drop of ~.5% with a file size ~2% smaller. This is comparing inter 1 vs inter 4 + limit tu 1. Without limit tu, inter 4 is ~ 20% slower.

So far I see no visible quality difference.

Great job!!!

Could you explain the differences between limit tu 1 + 2 a bit more in depth, please?
brumsky is offline   Reply With Quote
Old 11th October 2016, 19:08   #4313  |  Link
easyfab
Registered User
 
Join Date: Jan 2002
Posts: 327
Quote:
Originally Posted by LigH View Post
I wonder how much speed gain will be possible without a noticable additional loss of quality.
.
according to this https://mailman.videolan.org/piperma...er/010702.html

it seems there is no significant loss of quality for a good gain of speed with slower presets
easyfab is offline   Reply With Quote
Old 12th October 2016, 08:35   #4314  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,956
Quote:
Originally Posted by fauxreaper View Post
limit-tu only works with tu-inter-depth>1.
This leads to the follow-up question: When does that happen? — For preset defaults slower than "slow".

slower = 2
veryslow = 3
placebo = 4

They are all no choice for a CPU without AVX support, I fear...
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 13th October 2016, 14:33   #4315  |  Link
stevendj
Registered User
 
Join Date: Aug 2016
Location: Noord-Brabant, Netherlands
Posts: 3
Hi all,

I noticed a speed decrease between today's x265 and an earlier version of it.
Using builds from builds.x265.eu I narrowed the change I'm talking about down to be between the following versions:
1.9+217-626fcbac7ffb
1.9+223-17c0c875f27d

Encoding the same input video with the same settings takes 5%-30% longer in +223 compared to +217.
File size and visual quality of the output are virtually the SAME.

These commits can currently be found at the fourth page of the commits list on Bitbucket.
I also attached a screenshot of the 6 commits that could have caused this slowdown.

The new recursion skip a.k.a. --rskip seems like something big that could have caused the different encoding time, so I tried --no-rskip, but that (logically) only further increased the encoding time.

Could some other people perhaps test if they see a significant slow down between these versions too?

Thanks in advance
Attached Images
 

Last edited by stevendj; 13th October 2016 at 15:02.
stevendj is offline   Reply With Quote
Old 13th October 2016, 15:39   #4316  |  Link
Ma
Registered User
 
Join Date: Feb 2015
Posts: 325
Quote:
Originally Posted by stevendj View Post
Encoding the same input video with the same settings takes 5%-30% longer in +223 compared to +217.
File size and visual quality of the output are virtually the SAME.
Could you specify your encoding settings?
Ma is offline   Reply With Quote
Old 13th October 2016, 16:51   #4317  |  Link
Motenai Yoda
Registered User
 
Motenai Yoda's Avatar
 
Join Date: Jan 2010
Posts: 701
Quote:
Originally Posted by LigH View Post
This leads to the follow-up question: When does that happen? — For preset defaults slower than "slow".

slower = 2
veryslow = 3
placebo = 4

They are all no choice for a CPU without AVX support, I fear...
virtually they can change preset defaults to use tu-inter 2/3 on faster presets with limit-tu 2/1 w/o sensible speed impact

also as the doc says
Code:
--limit-tu <0|1|2>
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.
Default: 0
so testing anything over 2 has no sense
__________________
powered by Google Translator

Last edited by Motenai Yoda; 13th October 2016 at 16:58.
Motenai Yoda is offline   Reply With Quote
Old 13th October 2016, 18:15   #4318  |  Link
brumsky
Registered User
 
Join Date: Jun 2016
Posts: 116
Quote:
Originally Posted by stevendj View Post
Hi all,

I noticed a speed decrease between today's x265 and an earlier version of it.
This will explain the performance difference you are seeing.

http://forum.doom9.org/showpost.php?...postcount=4237

At least it should.
brumsky is offline   Reply With Quote
Old 13th October 2016, 19:00   #4319  |  Link
stevendj
Registered User
 
Join Date: Aug 2016
Location: Noord-Brabant, Netherlands
Posts: 3
Quote:
Originally Posted by Ma View Post
Could you specify your encoding settings?
I can reproduce the difference with just preset slower & crf 23.
I also tried preset medium, but the issue seems non-existent there.

It seems especially reproducible when encoding animated content, less so with 'real-life footage'.
Now that I've done some more testing, I do see a quality increase in the 'real-life footage' encodes (so good job x265 team!),
but when encoding animated content -in my opinion so far- the quality doesn't visibly change while the extra encoding time is noticable..
stevendj is offline   Reply With Quote
Old 13th October 2016, 19:26   #4320  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,977
Quote:
Originally Posted by stevendj View Post
but when encoding animated content -in my opinion so far- the quality doesn't visibly change while the extra encoding time is noticable..
Animation is pretty easy to encode. If it's already looking pretty much dialed in, than encoder improvements aren't going to do visually. Try raising your CRF by 3 and redoing the comparison.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner 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 23:26.


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