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 21st April 2018, 12:05   #6061  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,433
When watching some x265 encoded content on my TV, I can see very, very thin greyish vertical lines in scenes that are almost or completely black. Is this due to slice boundaries?
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is online now   Reply With Quote
Old 21st April 2018, 18:54   #6062  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,380
Quote:
Originally Posted by Boulder View Post
When watching some x265 encoded content on my TV, I can see very, very thin greyish vertical lines in scenes that are almost or completely black. Is this due to slice boundaries?
That'd more likely be tile boundaries. Definitely sounds like a decoder bug.
__________________
There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. ~ Ed Howdershelt
foxyshadis is offline   Reply With Quote
Old 21st April 2018, 19:10   #6063  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,433
(I did some more testing and I cannot see the strips if lookahead-slices was disabled (vertical resolution less than 720).) EDIT: tested with existing encodes - couldn't replicate this with the latest x265 using the same source.

This is how it looks on the TV and on my display, a snippet from the upper left corner (seriously exaggerated by getting the brightness real high):

https://imgur.com/a/gO45OYB

I recall seeing this also with x264 encoded videos. Different decoders have been used, on the computer it's the NVIDIA GPU and on the TV it's whatever is on Apple TV 4K - VideoToolBox I think.

EDIT: this older clip shows the thing at the start, turn up the brightness to see it: https://drive.google.com/open?id=1ui...b7A0ob9nqtJKa2
__________________
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; 21st April 2018 at 20:14.
Boulder is online now   Reply With Quote
Old 22nd April 2018, 19:33   #6064  |  Link
jlpsvk
Registered User
 
Join Date: Dec 2014
Posts: 167
just an addition to x265 AVX-512 problems...

ASRock X299 OC Formula + i9-7940X + Win10 x64 ... no crashing... AVX512 working flawlessly.

Binary from here (compiled in VS2017):
Code:
http://msystem.waw.pl/x265/x265-2.7+340-aa91024_vs2017.7z
jlpsvk is offline   Reply With Quote
Old 23rd April 2018, 12:26   #6065  |  Link
Bhavnahari
Registered User
 
Join Date: Nov 2016
Posts: 4
Quote:
Originally Posted by jlpsvk View Post
Thanks!!! So it won't downscale and upscale video? Only stats? Right? So it's better for retain quality/details or not?
The input video used to generate the analysis file(stats) in "save" encode must be the downscaled version of the video used to encode "load", x265 scales only the analysis data, not the input video.

The refinement techniques are to improve the speed of the encode with similar quality when compared to encoding the high-res video without any prior analysis information. Among the different refinement levels, --refine-inter 3 --refine-intra 4 gives the best quality retention.
Bhavnahari is offline   Reply With Quote
Old 23rd April 2018, 17:21   #6066  |  Link
Loomes
Registered User
 
Join Date: Nov 2003
Location: Germany, Berlin
Posts: 38
Quote:
Originally Posted by jlpsvk View Post
ASRock X299 OC Formula + i9-7940X + Win10 x64 ... no crashing... AVX512 working flawlessly.
Good for you ;P
What is your command line? Are you using ffmpeg?
Loomes is offline   Reply With Quote
Old 24th April 2018, 13:30   #6067  |  Link
jlpsvk
Registered User
 
Join Date: Dec 2014
Posts: 167
Quote:
Originally Posted by Loomes View Post
Good for you ;P
What is your command line? Are you using ffmpeg?
No... x265 ... 5 instances at once (RipBot264 Distr. encoding) to penetrate all cores at 100%.

My current command line:
Code:
--profile main10 --level-idc 5.1 --output-depth 10 --ctu 32 --amp --vbv-bufsize 160000 --vbv-maxrate 160000 --me star
--max-merge 5 --rc-lookahead 40 --lookahead-slices 4 --gop-lookahead 34 --ref 5 --hdr --hdr-opt --repeat-headers --no-info
--no-deblock --no-sao --no-strong-intra-smoothing --high-tier --asm avx512

Last edited by jlpsvk; 24th April 2018 at 13:33.
jlpsvk is offline   Reply With Quote
Old 24th April 2018, 14:59   #6068  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,648
Quote:
Originally Posted by jlpsvk View Post
No... x265 ... 5 instances at once (RipBot264 Distr. encoding) to penetrate all cores at 100%.
This requires a powerful fan ...

__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 24th April 2018, 17:30   #6069  |  Link
jlpsvk
Registered User
 
Join Date: Dec 2014
Posts: 167
Quote:
Originally Posted by LigH View Post
This requires a powerful fan ...
Nope... Noctua NH-D15 keeping it at 63 degrees.
jlpsvk is offline   Reply With Quote
Old 24th April 2018, 17:58   #6070  |  Link
Loomes
Registered User
 
Join Date: Nov 2003
Location: Germany, Berlin
Posts: 38
Quote:
Originally Posted by jlpsvk View Post
Nope... Noctua NH-D15 keeping it at 63 degrees.
That's great but what is your frequency and your AVX offset? Because that's what makes the heat.
Loomes is offline   Reply With Quote
Old 24th April 2018, 19:41   #6071  |  Link
jlpsvk
Registered User
 
Join Date: Dec 2014
Posts: 167
Quote:
Originally Posted by Loomes View Post
That's great but what is your frequency and your AVX offset? Because that's what makes the heat.
All 14 cores running at 3.7GHz (instead of 3.1 stock).
jlpsvk is offline   Reply With Quote
Old 24th April 2018, 20:24   #6072  |  Link
RieGo
Registered User
 
Join Date: Nov 2009
Posts: 57
Quote:
Originally Posted by jlpsvk View Post
All 14 cores running at 3.7GHz (instead of 3.1 stock).
so no AVX512 offset?

i got really weird results while using avx512 and x265:
A) temps don't really go much higher while using avx512, at least on my system
B) AVX512 offset almost doesn't make a difference. i had same performance on 12x 100MHz difference in offset
RieGo is offline   Reply With Quote
Old 24th April 2018, 21:53   #6073  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 3,257
Are you sure you are using AVX-512 and not bottlenecked by something else? I could notice even 2x offset (200 MHz), not hugely significant but a reproducible decrease in performance. Temperatures weren't much, if any, higher for me, running AVX2 or AVX512.

If you use something like hwinfo do you notice any cores running at the offset multiplier?
__________________
madVR options explained
Asmodian is offline   Reply With Quote
Old 25th April 2018, 00:03   #6074  |  Link
Ma
Registered User
 
Join Date: Feb 2015
Posts: 301
Quote:
Originally Posted by Loomes View Post
Are you using ffmpeg?
In case that the bug is in ffmpeg instead of x265, you can test ffmpeg binaries compiled by VS2015 -- ffmpeg-20180424.7z (without any libs, only for decoding video). I've added also ffmpeg compiled by GCC 7 and GCC 8 with only '-O2' optimize option instead of default '-O3 -fno-tree-vectorize'.

In my Win10/i7 8700 all 3 ffmpeg binaries works (and current Zeranoe builds also works).
Ma is offline   Reply With Quote
Old 25th April 2018, 00:52   #6075  |  Link
Loomes
Registered User
 
Join Date: Nov 2003
Location: Germany, Berlin
Posts: 38
Quote:
Originally Posted by Ma View Post
In case that the bug is in ffmpeg instead of x265, you can test ffmpeg binaries compiled by VS2015 -- ffmpeg-20180424.7z (without any libs, only for decoding video). I've added also ffmpeg compiled by GCC 7 and GCC 8 with only '-O2' optimize option instead of default '-O3 -fno-tree-vectorize'
Thanks a lot, I will do some more tests at the weekend. I have a feeling that it's not x265 or ffmpeg but that there's something wrong with my system. At least my Win10 install is rather fresh, almost vanilla and from an ISO directly downloaded from the Microsoft site. Well, I'll find out!
Loomes is offline   Reply With Quote
Old 25th April 2018, 16:30   #6076  |  Link
sdml
Registered User
 
Join Date: Mar 2009
Posts: 3
Am I correct that all *-refine-* features useful only for multi-pass scenarios?
sdml is offline   Reply With Quote
Old 25th April 2018, 16:31   #6077  |  Link
froggy1
ffx264/ffhevc author
 
froggy1's Avatar
 
Join Date: May 2007
Location: Belgium
Posts: 1,444
Quote:
Originally Posted by sdml View Post
Am I correct that all *-refine-* features useful only for multi-pass scenarios?
rd-refine works in crf too
froggy1 is offline   Reply With Quote
Old 25th April 2018, 16:34   #6078  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,433
I'm a bit confused as Bhavnahari stated that "refine-inter and refine-intra features may be used with any rate control techniques including ABR, CRF and CQP". Why would you do a 2-step encode in CRF mode to utilize the refining? Shouldn't a normal CRF encode already bring all the quality you can get from your settings with the least amount of time spent on encoding or analysing?
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is online now   Reply With Quote
Old 25th April 2018, 19:52   #6079  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 3,257
I believe the point is to do much of the analysis on a lower resolution video, then reuse that analysis with the higher resolution while still doing some refinement to fine tune the analysis for the full resolution. This gives a speed boost while also not lowering the quality too much, like simply using the analysis done on the low resolution video directly would.

I am not sure I would do this, but then I tend to run far up the quality/speed curve, e.g. preset veryslow with a few extra options that slow it down even more. It would be interesting to see the speed and quality impacts from using this method compared to slower or faster presets and/or other options.
__________________
madVR options explained
Asmodian is offline   Reply With Quote
Old 26th April 2018, 04:23   #6080  |  Link
WhatZit
Registered User
 
Join Date: Aug 2016
Posts: 57
Quote:
Originally Posted by Asmodian View Post
I believe the point is to do much of the analysis on a lower resolution video, then reuse that analysis with the higher resolution while still doing some refinement to fine tune the analysis for the full resolution.
Basically correct. The idea is to "Analyse once, encode many".

Many of the recent CLI functions added to x265 are there to suit the demands of professional broadcast/OTT content providers, who may wish to create multiple resolution and bitrate copies of any one source.

The practical consumer application of this particular "reuse" functionality would be very niche.
WhatZit 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 19:02.


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