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 14th July 2018, 23:50   #6201  |  Link
uneedme
Registered User
 
Join Date: Sep 2007
Posts: 41
Hello Dudes,

I have tried to encode a video...

From 5 mins and on, the quality is getting worse and worse steadily(it is like auto crf downgrade). and then I split the source video into pieces and encoded them again. Every outputs are good then.

with the same params, I dont know why......

I suspect "--psy-rd 3.2" is the cause or it is a bug?......Or some wrong commands-combinations cause the chaos...

Cheers.


--crf 18.6 -m 2 --me 1 --rd 5 --rc-lookahead 120 --merange 114 --bframes 6 --ref 6 --min-keyint 23 --keyint 240 --max-merge 5 --tu-intra-depth 3 --tu-inter-depth 2 --aq-motion --qg-size 16 --no-sao --no-strong-intra-smoothing --psy-rd 3.2 --scenecut 80 --deblock -1:3 --aq-mode 2 --qcomp 0.8 --aq-strength 0.8 --colorprim bt709 --colormatrix bt709 --transfer bt709 --input-res 1862x768 --fps 24000/1001 --input-depth 10 -D 10 -o "1" --rc-grain --input -

Last edited by uneedme; 15th July 2018 at 00:11.
uneedme is offline   Reply With Quote
Old 15th July 2018, 00:19   #6202  |  Link
froggy1
ffx264/ffhevc author
 
froggy1's Avatar
 
Join Date: May 2007
Location: Belgium
Posts: 1,455
remove --aq-motion and try again
__________________
ffx264--ffhevc--ffxvid
froggy1 is offline   Reply With Quote
Old 20th July 2018, 16:36   #6203  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,790
x265 2.8+47-e2759ae31c36

several fixes related to HDR10+ LLC JSON and dependencies between effects of options
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 20th July 2018, 16:40   #6204  |  Link
alex1399
Registered User
 
Join Date: Jun 2018
Posts: 45
I've got some 60fps video materials with wrongly encoded frame-rate which has lots of duplicated frames.
Encoding those video tends to exceed the bits per second budget.
1. remove duplicated frame
2. increase qcomp
3. set tu-inter-depth=4:tu-intra-depth=4
The 1. and 2. don't perform well, those "still" frames seems to compromised by the poorly unstable sampling rate and ghosting artifacts.
The 3. is interesting.
Instead, how to set x265 parameters to act just like a corrected frame-rate video but farther Intra-coded (I) frames and high level hierarchy Bi-directional predicted (B) frames?
alex1399 is offline   Reply With Quote
Old 21st July 2018, 05:55   #6205  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Germany
Posts: 501
If it's 60fps with many dups, you may wanna decimate it using a frameserver first.
I would use something like this in Avisynth:

tdecimate(mode=2, rate=30)

change "rate" according to the original frame-rate of your source.

Then, you said that "it tends to exceed the bits per second budget".
I assume you mean that it requires too much bitrate than the one you are trying to keep as maximum.
If that's the case, I would increase the reframe parameter and a few other things, but beware that it's gonna be more resource intensive to both encode and decode.
Try with --ref 16 --me esa --subme 11
FranceBB is offline   Reply With Quote
Old 21st July 2018, 08:03   #6206  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 533
How to get around this?
PHP Code:
api.cpp:491:1errorjump to label 'fail' [-fpermissive]
 
fail:
 ^~~~
In file included from api.cpp:24:
common.h:225:18note:   from here
             
goto fail; \ 
Jamaika is offline   Reply With Quote
Old 21st July 2018, 11:34   #6207  |  Link
Ma
Registered User
 
Join Date: Feb 2015
Posts: 324
Easiest solution:
before building x265 please execute
Code:
export CXXFLAGS="-fpermissive"
Ma is offline   Reply With Quote
Old 21st July 2018, 16:47   #6208  |  Link
alex1399
Registered User
 
Join Date: Jun 2018
Posts: 45
After some suggestions and a fast review of x265 documents, quick conclusion comes out for the x265 encoder parameters.
My boss will reject those that are not heuristic methods so trivial trimming frame is not option.

keyint = 10*frame-rate. Long distance key-frames are best for Still frames, based on frame-rate without affecting decoder side too much. Default is 250.
scenecut = 30. Scene-cut detection is less aggressive to ignore some ghosting / blending scene. Default is 40.
rc-lookahead = 0.8*frame-rate. Add some more lookahead for frame-type decision. Default is 20.

Rest of the options i.e., bframes, ref and many motion prediction would be based on the presets by default. Feel free to give your comments about those custom options and or de-noising (mostly from high-bit-depth to 8-bit-depth dithering) or de-ghosting stuffs?

Last edited by alex1399; 21st July 2018 at 16:50.
alex1399 is offline   Reply With Quote
Old 21st July 2018, 18:08   #6209  |  Link
kento
Registered User
 
Join Date: Dec 2001
Location: Switzerland
Posts: 21
I just wish to thank everyone for the hard work and the suggestions made through the years !
kento is offline   Reply With Quote
Old 21st July 2018, 20:59   #6210  |  Link
uneedme
Registered User
 
Join Date: Sep 2007
Posts: 41
Quote:
Originally Posted by froggy1 View Post
remove --aq-motion and try again
ooh cheers,

I will have another try...

(just cant logon the forum dont know why)



From current processing, it is sure aq-motion cause the Chaos......But Why. Is this experimental param still Buggy?

Last edited by uneedme; 22nd July 2018 at 13:55.
uneedme is offline   Reply With Quote
Old 22nd July 2018, 07:42   #6211  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,401
Quote:
Originally Posted by alex1399 View Post
After some suggestions and a fast review of x265 documents, quick conclusion comes out for the x265 encoder parameters.
My boss will reject those that are not heuristic methods so trivial trimming frame is not option.

keyint = 10*frame-rate. Long distance key-frames are best for Still frames, based on frame-rate without affecting decoder side too much. Default is 250.
scenecut = 30. Scene-cut detection is less aggressive to ignore some ghosting / blending scene. Default is 40.
rc-lookahead = 0.8*frame-rate. Add some more lookahead for frame-type decision. Default is 20.

Rest of the options i.e., bframes, ref and many motion prediction would be based on the presets by default. Feel free to give your comments about those custom options and or de-noising (mostly from high-bit-depth to 8-bit-depth dithering) or de-ghosting stuffs?
If you have a bit-budget, in any way, shape, or form, then you need to turn on VBV. You're only exceeding it because you didn't set up VBV correctly. If you're consistently exceeding it throughout the whole video, you can either raise the profile (longer encoding, bit of a crapshoot on how much it lowers bitrate) or raise the crf (guaranteed bitrate and quality reduction).

B-frames aren't set by the profile, only the tune, so setting them manually to a higher value is a solid option, but after 3 b-frames the value falls off enormously. (Except in certain classes of animation.)
__________________
There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order.
foxyshadis is offline   Reply With Quote
Old 22nd July 2018, 11:25   #6212  |  Link
alex1399
Registered User
 
Join Date: Jun 2018
Posts: 45
Increasing bframes with those duplicated frames doesn't help at all, maybe. Might require more experiments under the PSNR tunes to figure out. The hierarchy stuffs in x265 is quite abstract, so left those for presets.

VBV seems to be great if videos would be publicly released on air in advance. On the contrary, increasing qcomp and qpstep provide something better in motion view.
alex1399 is offline   Reply With Quote
Old 22nd July 2018, 15:11   #6213  |  Link
katzenjoghurt
Registered User
 
Join Date: Feb 2007
Posts: 76
Washed out colors



Sources:
https://www2.pic-upload.de/img/35671...g_original.png
https://www2.pic-upload.de/img/35671...oding_x265.png

Slider Comparison Tool Link:
https://cdn.knightlab.com/libs/juxta...3-0edaf8f81e27

Hey community!

Hm... I feel something's funky with my settings but I don't know what.
SOMETIMES the encodings come out with a bit washed out colors.
It especially seems to happen in darker scenes...
See the gif above.

For most movies it seems to not happen at all.

What is it and how can I detect / prevent it?

I used Staxrip with these encoding settings:

short:

--crf 22 --tune grain --profile main10 --output-depth 10 --rskip --qcomp 0.8 --no-open-gop --sar 12:11 --no-deblock --no-strong-intra-smoothing


detailed settings:

Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L4@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 2 h 13 min
Bit rate : 6 416 kb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.129
Stream size : 6.00 GiB (77%)
Writing library : x265 2.8+40-0106f9f2f867:[Windows][GCC 7.3.0][64 bit] 10bit
Encoding settings : cpuid=1111039 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=192702 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / no-open-gop / min-keyint=23 / keyint=250 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=6 / scenecut=40 / radl=0 / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=2 / limit-refs=3 / no-limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / weightp / no-weightb / no-analyze-src-pics / no-deblock / no-sao / no-sao-non-deblock / rd=3 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=4.00 / psy-rdoq=0.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=22.0 / qcomp=0.80 / qpstep=1 / stats-write=0 / stats-read=0 / ipratio=1.10 / pbratio=1.00 / aq-mode=0 / aq-strength=0.00 / no-cutree / zone-count=0 / no-strict-cbr / qg-size=64 / rc-grain / qpmax=69 / qpmin=0 / const-vbv / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=5 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-mv-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei
Default : Yes
Forced : No


Someone mentioned that washed out colors may be caused by a too low bitrate... but hum... I don't see much of a difference when rising it.

Last edited by katzenjoghurt; 22nd July 2018 at 18:33.
katzenjoghurt is offline   Reply With Quote
Old 22nd July 2018, 17:50   #6214  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 6,774
gif in 256 colors is a bad way to demonstrate your issue.
Atak_Snajpera is offline   Reply With Quote
Old 22nd July 2018, 18:28   #6215  |  Link
katzenjoghurt
Registered User
 
Join Date: Feb 2007
Posts: 76
Quote:
Originally Posted by Atak_Snajpera View Post
gif in 256 colors is a bad way to demonstrate your issue.
It visualizes the point: The warm face color turns grayish.

Added the sources to the original posting.

Last edited by katzenjoghurt; 22nd July 2018 at 18:33.
katzenjoghurt is offline   Reply With Quote
Old 22nd July 2018, 20:28   #6216  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 5,800
looking at it in Firefox at 200% on a HP 5k z27q with a Geforce GTX 1070t, I see the color change around the eye, but sure what is causing this.
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 23rd July 2018, 06:42   #6217  |  Link
WhatZit
Registered User
 
Join Date: Aug 2016
Posts: 59
Quote:
Originally Posted by katzenjoghurt View Post
...
colorprim=2 / transfer=2 / colormatrix=2
...
There's a lot we don't know about your source, such as its bitdepth, frame size, encoder family, or colour tagging.

A conversion from any of those source states could introduce colour-shifting depending entirely on what specific process you're using, especially rounding errors when resizing or denoising, or even a bad source decoder. Heaps of variables.

However, given that your MediaInfo dump of the x265 encode shows "unknown" for all of the colour characteristics, I'd start my investigation there.
WhatZit is offline   Reply With Quote
Old 23rd July 2018, 08:14   #6218  |  Link
jd17
Registered User
 
Join Date: Jun 2017
Posts: 82
Quote:
Originally Posted by katzenjoghurt View Post
Hm... I feel something's funky with my settings but I don't know what.
SOMETIMES the encodings come out with a bit washed out colors.
It especially seems to happen in darker scenes...
See the gif above.
Without knowing all the details already requested by others, I can at least offer a suspicion:

Assumption:
Your source is 8bit and you encode to 10bit.
If that is the case, what you see is most likely not an issue with your encode, but rather the decoder.
I stumbled over this a while back - I could only see the issue on my PC, but not when I watched the videos on my TV (clean 10bit decoding chain).

I think this was already discussed somewhere here on doom9 as well.
jd17 is offline   Reply With Quote
Old 23rd July 2018, 10:57   #6219  |  Link
katzenjoghurt
Registered User
 
Join Date: Feb 2007
Posts: 76
Hi jd17!

OMG! You are right!!
It's an 8bit source.

Tried a bit around and compared it against a main 8bit encoding and the problem was gone. (Using StaxRip's comparison tool)

I then opened the 8bit and the main10 10bit file in VLC and... again no washed out colors.

So the issue seems to be related to StaxRip's screen comparison tool.


Thx a lot, Sherlock!

Last edited by katzenjoghurt; 23rd July 2018 at 10:59.
katzenjoghurt is offline   Reply With Quote
Old 23rd July 2018, 11:23   #6220  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,790
I remember people putting two media players side by side, wondering about color differences ... but they set up the media player to use the Hardware Overlay renderer. Which can have different color controls, compared to the desktop. And can only be used by one player. The other player must then select an alternative desktop-contained renderer.

One renderer in the overlay, the other in the desktop: in this case, color differences are no surprise.
__________________

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 12:45.


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