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. |
26th January 2018, 03:39 | #5861 | Link |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
|
@mini-moose... I did it accidentally more than once and it didn't corrupt my encode; everything resumed fine and the final output wasn't affected. I think x265 *just* waits for frames from the pipe to encode them. Clicking on the console prevents the pipe from processing frames, therefore x265 waits.
|
27th January 2018, 09:40 | #5865 | Link | |
Registered User
Join Date: Apr 2016
Posts: 7
|
Does anyone have any CLI tricks for cutting down on the grid of "squares" that pop up during encoding? I'm still trying out various options, trying to keep most options near placebo level, but this seems to be a common occurrence, am I misusing a switch?
Example, Source: Encode Quote:
Last edited by dcxero; 27th January 2018 at 09:55. |
|
27th January 2018, 11:29 | #5866 | Link | ||
Registered User
Join Date: Mar 2002
Location: Krautland
Posts: 903
|
Sorry, my english is maybe bad.
But I cant see Quote:
Just the normal encoding artefacts. Your Quote:
Even bumping up the monitor brightness and magnifying the png shows no squares on my side. Or maybe my eyesight is vanishing. Just an old horse with dull eyes ! |
||
27th January 2018, 18:29 | #5867 | Link |
Registered User
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,406
|
-3 is probably too weak deblocking for x265, try -1 or -2 at most.
__________________
madVR options explained |
27th January 2018, 22:38 | #5869 | Link |
Registered User
Join Date: Apr 2016
Posts: 7
|
Cheers, that seemed to be it. I guess I assumed the deblocking was more like x264, but I ran the same CLI a dozen more times, only changing deblock between -3,-3 -2,-2... all the way back to +3,+3 and then disabled. +2,+2 had the least offensive blocking (practically none) while remaining closer to the source (+3,+3 started to alter it)
|
27th January 2018, 22:54 | #5870 | Link | |
ffx264/ffhevc author
Join Date: May 2007
Location: /dev/video0
Posts: 1,843
|
Quote:
|
|
27th January 2018, 23:07 | #5871 | Link |
Registered User
Join Date: Dec 2014
Posts: 240
|
any cons to using --no-deblock in CLI? i I want to preserve as much sharpness as ist gets? my CLI:
Code:
--crf 18 --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 --ref 5 --min-keyint 24 --keyint 240 --colorprim bt709 --colormatrix bt709 --transfer bt709 --no-info --no-deblock --no-sao --no-strong-intra-smoothing --high-tier |
27th January 2018, 23:18 | #5872 | Link |
Registered User
Join Date: Apr 2016
Posts: 7
|
|
27th January 2018, 23:27 | #5873 | Link | |
ffx264/ffhevc author
Join Date: May 2007
Location: /dev/video0
Posts: 1,843
|
Quote:
Anyways, if you're happy with +2, use it |
|
27th January 2018, 23:36 | #5874 | Link |
Registered User
Join Date: Apr 2016
Posts: 7
|
You definitely need a new monitor then!
I suppose it's harder to see if you look at it unless zooming, or blown up on a TV/projector. Try flipping back and forth between the source image zoomed in, there's a faint grid of squares about 16x16 pixels wide across the whole image It seems to be something inherent to HEVC (or just more noticeable), because I've seen it in some retail UHD discs as well (unless they're just using x264 too! ) |
27th January 2018, 23:41 | #5875 | Link | |
ffx264/ffhevc author
Join Date: May 2007
Location: /dev/video0
Posts: 1,843
|
Quote:
I don't have any 4K displays here, all are FHD and on FHD I can't see it on any of my displays |
|
28th January 2018, 01:09 | #5876 | Link |
Registered User
Join Date: Aug 2006
Posts: 2,229
|
It doesn't look like a true transfer from the film original. Is it The Fifth Element? It's a movie I thought they would have done a proper 4k transfer for. The grain doesn't help much either, as the grain acts as detail that needs to be encoded. If it changes each frame it is probably using most of the bandwidth and bit allocation for the grain and not the actual picture. I think you'll find using a denoiser first could greatly improve the success of your output. Maybe give my mClean (v2.1) a go? https://forum.doom9.org/showthread.php?t=174804
I'm not specifically spruiking my script! This situation is just one of many that it is designed to help with. You will need to use the latest Avisynth+, updated RGTools, MVTools, Masktools, Modplus, f3kdb, as the script utilises new functions that weren't available in older versions of these. It's designed in such a way that the base settings should be adequate and retain some grain in a way that it will be more encoder bit friendly. Last edited by burfadel; 28th January 2018 at 01:12. |
29th January 2018, 06:59 | #5877 | Link |
Registered User
Join Date: Aug 2007
Posts: 79
|
hi there. I was wondering what are the thoughts about the aq-motion option regarding cartoon or anime content. In my experience it's beneficial to use with real world content where the higher quantization of moving parts is masked by the motion blur they introduce. but with drawn content moving parts are usually as sharp as still areas. I made a little encoding test to see the effect on bitrate and with drawn content it doesn't seem to do much anyways. any experiences with this option here?
|
30th January 2018, 00:53 | #5878 | Link |
Registered User
Join Date: Mar 2015
Location: New Zealand
Posts: 45
|
@burfadel, thats interesting, I will have to check your filter out! I am currently getting very good results with smdegrain:
vid = haf.SMDegrain(vid, tr=3,thSAD=150,RefineMotion=True,contrasharp=True,pel=2) varying thSAD from 100-400 depending on grain, or smdegrain off if no grain (ironman3, Star Trek Beyond). Cheers, Divxmaster |
30th January 2018, 05:58 | #5879 | Link | |
Registered User
Join Date: Aug 2016
Posts: 60
|
Quote:
The --deblock loop filter uses a PAIR of values that correspond to STRENGTH,DECISION. STRENGTH needs no explanation, but DECISION (literally) decides how often to employ the filter on coding units. The default value of 0 activates on relatively balanced values between the block boundaries. The maximum value of 6 activates on ALL block boundaries regardless of disparity, producing whole-scene smoothing. The minimum value of -6 activates only on those block boundaries which have significant threshold disparity, producing virtually no deblocking on anything other than already unwatchable artifacts. To answer your question, unless you are using a high enough bitrate to never create blocking artifacts in the first place, you should always have some level of deblocking active (even -6,-6), because blocking is something that the eye just spots immediately. To figure out what values the filter should be set to FOR YOU and your bitrates, get yourself a high-detail sample with stationary foreground elements & rapidly moving background elements. A sunny panning shot of people running in front of plants or other complex backgrounds is perfect. Adjust DECISION until the background blocking stops (or is acceptable) whilst the foreground remains untouched. Then adjust STRENGTH to suit. I personally use -2,-3. Last edited by WhatZit; 30th January 2018 at 06:01. |
|
30th January 2018, 09:24 | #5880 | Link | |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,752
|
Quote:
__ The "founder and chairman of MPEG", Leonardo Chiariglione, discovered that the patent licensing model gets obsolete with the success of OpenSource media formats like Opus audio and soon AOMedia AV1 video ... all the investments for an uncertain future of MPEG technologies. Including HEVC. No immediate reason for Multicoreware to panic, I believe. Established uses of MPEG technologies won't disappear quickly. And when their substitution with more advanced and free OpenSoure formats comes closer, it's not improbable that their development gets paid for as well. __ P.S.: Holding back new builds until [PATCH] CMake: blacklist mingw implicit link libraries gets committed. If I understand its intention correctly, this should slim down the binary base a little by avoiding superfluous linked libraries? Last edited by LigH; 31st January 2018 at 08:31. |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|