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 July 2018, 04:55   #6201  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
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, 07:03   #6202  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 697
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, 10:34   #6203  |  Link
Ma
Registered User
 
Join Date: Feb 2015
Posts: 326
Easiest solution:
before building x265 please execute
Code:
export CXXFLAGS="-fpermissive"
Ma is offline   Reply With Quote
Old 21st July 2018, 15:47   #6204  |  Link
alex1399
Registered User
 
Join Date: Jun 2018
Posts: 56
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 15:50.
alex1399 is offline   Reply With Quote
Old 21st July 2018, 17:08   #6205  |  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, 19:59   #6206  |  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 12:55.
uneedme is offline   Reply With Quote
Old 22nd July 2018, 06:42   #6207  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,558
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.)
foxyshadis is offline   Reply With Quote
Old 22nd July 2018, 10:25   #6208  |  Link
alex1399
Registered User
 
Join Date: Jun 2018
Posts: 56
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, 14:11   #6209  |  Link
katzenjoghurt
Registered User
 
Join Date: Feb 2007
Posts: 128
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 17:33.
katzenjoghurt is offline   Reply With Quote
Old 22nd July 2018, 16:50   #6210  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 7,806
gif in 256 colors is a bad way to demonstrate your issue.
Atak_Snajpera is offline   Reply With Quote
Old 22nd July 2018, 17:28   #6211  |  Link
katzenjoghurt
Registered User
 
Join Date: Feb 2007
Posts: 128
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 17:33.
katzenjoghurt is offline   Reply With Quote
Old 22nd July 2018, 19:28   #6212  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 7,259
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, 05:42   #6213  |  Link
WhatZit
Registered User
 
Join Date: Aug 2016
Posts: 60
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, 07:14   #6214  |  Link
jd17
Registered User
 
Join Date: Jun 2017
Posts: 89
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, 09:57   #6215  |  Link
katzenjoghurt
Registered User
 
Join Date: Feb 2007
Posts: 128
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 09:59.
katzenjoghurt is offline   Reply With Quote
Old 23rd July 2018, 10:23   #6216  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
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
Old 23rd July 2018, 10:52   #6217  |  Link
alex1399
Registered User
 
Join Date: Jun 2018
Posts: 56
Quote:
Originally Posted by foxyshadis View Post
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).
OK, I found the culprit of the encoding process. The frame numbers of encoded video reported by ffprobe is one more than the original video material. In 2-pass encoding, the -f null - in the first pass encoding seems to bypass vsync detection and provide a invalid analysis for the coming second pass encoding which has a duplicated frame at the start.

If the -f null - in the first pass encoding is replaced by any dummy output, both output of the first pass encoding and the second pass encoding will have the same duplicated frame and the analysis is valid.

Is it possible to log only these error(warning) into txt file during the batch process, so I could read it when I'm back to screen?
alex1399 is offline   Reply With Quote
Old 23rd July 2018, 11:43   #6218  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
VSync (Vertical Retrace Synchronisation) is related to a video monitor, a synchronism between monitor and video frame rate ... you probably mean audio/video synchronism. Whatever it means in detail, this will be an issue related to ffmpeg; x265 (as a separate encoder, or as the core library) processes video only and can only rely on the sequence of input frames. If the ffmpeg core serves a duplicate frame, blame ffmpeg.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 23rd July 2018, 12:05   #6219  |  Link
alex1399
Registered User
 
Join Date: Jun 2018
Posts: 56
I'm sorry that confusing, the audio/video sync stuffs that ffmpeg names not the monitor sync stuffs. Does x265 itself have any mechanic to log out error, for example, somebody purposely use a different video at the second pass encoding to do something wrong?
alex1399 is offline   Reply With Quote
Old 23rd July 2018, 13:28   #6220  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
If x265 uses a statistics file in a 2nd pass which is based on analyzing a different movie in the 1st pass, then it is possible that just the bitrate distribution is not optimal; if you have additional VBV restrictions, it might happen that they fail; if they have a different number of frames, the mismatch may be discovered in the end; but in general, just the quality may vary unexpectedly. There are no security measures to match statistics file and video source (which would be nearly impossible anyway if it comes out of a pipe). Your only workarounds I can imagine right now:

a) let the 1st pass create an output file too;
b) ignore audio during video encoding to avoid this issue if it is not in sync in the source file, always process audio separately, and multiplex it to the final video only

In any case, x265 is not to be blamed.
__________________

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 19:35.


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