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. |
21st July 2018, 04:55 | #6201 | Link |
Broadcast Encoder
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 |
21st July 2018, 15:47 | #6204 | Link |
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. |
21st July 2018, 19:59 | #6206 | Link |
Registered User
Join Date: Sep 2007
Posts: 41
|
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. |
22nd July 2018, 06:42 | #6207 | Link | |
ангел смерти
Join Date: Nov 2004
Location: Lost
Posts: 9,558
|
Quote:
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.) |
|
22nd July 2018, 10:25 | #6208 | Link |
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. |
22nd July 2018, 14:11 | #6209 | Link |
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. |
22nd July 2018, 16:50 | #6210 | Link |
RipBot264 author
Join Date: May 2006
Location: Poland
Posts: 7,806
|
gif in 256 colors is a bad way to demonstrate your issue.
__________________
Windows 7 Image Updater - SkyLake\KabyLake\CoffeLake\Ryzen Threadripper |
23rd July 2018, 05:42 | #6213 | Link |
Registered User
Join Date: Aug 2016
Posts: 60
|
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. |
23rd July 2018, 07:14 | #6214 | Link | |
Registered User
Join Date: Jun 2017
Posts: 89
|
Quote:
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. |
|
23rd July 2018, 09:57 | #6215 | Link |
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. |
23rd July 2018, 10:23 | #6216 | Link |
German doom9/Gleitz SuMo
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. |
23rd July 2018, 10:52 | #6217 | Link | |
Registered User
Join Date: Jun 2018
Posts: 56
|
Quote:
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? |
|
23rd July 2018, 11:43 | #6218 | Link |
German doom9/Gleitz SuMo
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.
|
23rd July 2018, 12:05 | #6219 | Link |
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?
|
23rd July 2018, 13:28 | #6220 | Link |
German doom9/Gleitz SuMo
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. |
Thread Tools | Search this Thread |
Display Modes | |
|
|