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. |
23rd July 2018, 14:53 | #6221 | Link |
Registered User
Join Date: Jun 2018
Posts: 56
|
The second pass encoding just use the slice-type order from the first pass encoding where the first pass intently encodes video A and the second pass intently encodes video B respectively. Both video A and B have the same frame-rate, resolution and amount of frames. the slice-type order is checked by ffprobe -show_frames.
Before I closed the paused batch window during the weekend, it shows something like "[warning]: specified frame type (*) at **** is not compatible with keyframe interval" and "[error]: slice=I but 2pass stats say B", never mind. Now a dummy output is assigned for the first past encoding output. During debug mode, to record the PSNR statics, options tune PSNR for x265, psnr stats_file for ffmpeg, and move stats_file SomeGenericNameNum are mixed in the batch process. If the result is promising, then the debug stuffs will be canceled and use the default tuning for the rest of the videos. A bonus demonstration of the mad Adam from RWBY V5E2 for the encoding misplacement https://i.imgur.com/b6wmHFz.jpg Last edited by alex1399; 24th July 2018 at 07:47. |
25th July 2018, 05:01 | #6222 | Link |
Registered User
Join Date: Jun 2018
Posts: 56
|
No VBV restrictions right now. Just trying to simulate how could those videos badly up-sampled and up-scaled and low-bit-depth to high-bit-depth / high-bit-depth to low-bit-depth conversion back and forth. Now I feel disgusting about those superfluous 10-bit-depth video which was encoded from 8-bit-depth raw source.
A problematic USB stick is fine to reproduce binary corruption / missing in poor network to observe blocking artifacts. --gop-lookahead value larger than --min-keyint value is great on letting x265 produces more noise. Hard-coded artifacts from --dithering and --deblock that make things look not natural : a little subjective. And so on. |
25th July 2018, 20:56 | #6223 | Link |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,905
|
Actually, it makes sense to encode in 10bit starting from an 8bit source. I know that if there's banding already in the 8bit source, there's gonna be banding in the 10bit encode as well, but if I had to deband an 8bit source, I wouldn't encode it back to 8bit unless I really need to. Besides, Main10 is the "de-facto" standard and is widely compatible with players (unlike H.264 High10 that wasn't very supported).
|
26th July 2018, 19:44 | #6224 | Link | |
結城有紀
Join Date: Dec 2003
Location: NJ; OR; Shanghai
Posts: 894
|
Quote:
Take math as an example. The area of a circle of 4.5, computing in 1-digit after point internal precision is 4.5 * 4.5 -> 20.2, then 20.2 * pi -> 62.6. However computing in 2-digit internal precision gives you 63.58 which is much closer to the real number 63.61725015. Totally different result.
__________________
Projects x265 - Yuuki-Asuna-mod Download / GitHub TS - ADTS AAC Splitter | LATM AAC Splitter | BS4K-ASS Neo AviSynth+ filters - F3KDB | FFT3D | DFTTest | MiniDeen | Temporal Median Last edited by MeteorRain; 26th July 2018 at 19:47. |
|
26th July 2018, 22:01 | #6225 | Link |
Registered User
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,407
|
That was true in AVC but HEVC uses a high bitdepth for most of the math internally, for all output bitdepths, but it is still a good idea to always encode to 10 bit HEVC.
__________________
madVR options explained |
27th July 2018, 19:10 | #6227 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,733
|
I also recall reading somewhere that internally everything happens in 16-bit precision.
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
28th July 2018, 12:01 | #6228 | Link |
Registered User
Join Date: Feb 2007
Location: Sweden
Posts: 483
|
x265 v2.8+56-613074c6714f (GCC 7.3.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)
Code:
https://bitbucket.org/multicoreware/x265/commits/branch/default |
29th July 2018, 06:11 | #6229 | Link |
Angel of Night
Join Date: Nov 2004
Location: Tangled in the silks
Posts: 9,559
|
The spec absolutely hates being clear about things mere mortals like to know, but there are a few points: All dct transform processing is from -2^15 to 2^15 (7.4.3.2.2), meaning signed 16-bit. That's about it, though; for purposes of processing they're immediately scaled to bitdepth, and reference prediction & filtering are performed in the bit-depth of the encode. (8.5.3-4 & 8.7.2 has much of the gory details.)
|
29th July 2018, 15:55 | #6230 | Link |
Registered User
Join Date: Jun 2018
Posts: 56
|
Thanks for everybody's input. To provide an additional reason why lossless x265 is superior, Video A and B are presented for a trivial scheme : interweave.
First, interweave both video; Second, select and mux the even frame; third, compare it under PSNR measure. Video A: https://www5.zippyshare.com/v/uVQP4Ccc/file.html Video B: https://www87.zippyshare.com/v/pkkl1Eph/file.html x265 crf 0 interweave scheme ffmpeg -i in.y4m -i out.y4m -filter_complex framepack=frameseq -c:v libx265 -crf 0 output.mp4 ffmpeg -i output.mp4 -vf select=mod(n\,2) -r 24000/1001 -c:v libx265 -crf 0 output1.mp4 ffmpeg -i output1.mp4 -i out.y4m -lavfi psnr=stats_file=psnr.csv -f null - x265 lossless interweave scheme ffmpeg -i in.y4m -i out.y4m -filter_complex framepack=frameseq -c:v libx265 lossless=1 output.mp4 ffmpeg -i output.mp4 -vf select=mod(n\,2) -r 24000/1001 -c:v libx265 -x265-params lossless=1 output1.mp4 ffmpeg -i output1.mp4 -i out.y4m -lavfi psnr=stats_file=psnr.csv -f null - raw lossless interweave scheme ffmpeg -i in.y4m -i out.y4m -filter_complex framepack=frameseq -f yuv4mpegpipe output.y4m ffmpeg -i output.y4m -vf select=mod(n\,2) -r 24000/1001 -f yuv4mpegpipe output1.y4m ffmpeg -i output1.y4m -i out.y4m -lavfi psnr=stats_file=psnr.csv -f null - A mean-square-error of 0.00 but PSNR of non-inf is quite surprised me in the crf=0 x265 scheme. Maybe there exists some bit-exact-accuracy options I didn't activate for x265, but crf=0 is definitely not lossless. Out of topic x264 crf 0 interweave scheme ffmpeg -i in.y4m -i out.y4m -filter_complex framepack=frameseq -c:v libx264 -crf 0 output.mp4 ffmpeg -i output.mp4 -vf select=mod(n\,2) -r 24000/1001 -c:v libx264 -crf 0 output1.mp4 ffmpeg -i output1.mp4 -i out.y4m -lavfi psnr=stats_file=psnr.csv -f null - Last edited by alex1399; 29th July 2018 at 17:18. Reason: x264 re-added for bug tracker |
29th July 2018, 16:29 | #6232 | Link |
Registered User
Join Date: Dec 2002
Posts: 5,565
|
It is for 8 bit x264. I suspect the error is not in libx264, maybe ffmpeg muxing/demuxing. Either way this has nothing to do with x265. Please move to a new thread or better yet report on ffmpeg bug tracker.
Last edited by sneaker_ger; 29th July 2018 at 16:34. |
30th July 2018, 12:09 | #6234 | Link |
Registered User
Join Date: Aug 2009
Posts: 90
|
I really like x265 but I seem to be unable to get rid of linear smearing/stretching artifacts when there are fast moving objects in a scene.
Is there a specific parameter targeted at improving this, without increasing the bit rate in other areas (those are fine)? My settings are: --crf 17 --preset veryslow --profile main10 --level-idc 5 --output-depth 10 --psy-rdoq 4 --aq-mode 3 --qg-size 64 --qcomp 0.7 --subme 5 --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50)" --colorprim bt2020 --colormatrix bt2020nc --transfer smpte2084 --max-cll "457,179" --hdr --hdr-opt --deblock -1:-1 --no-sao --no-strong-intra-smoothing example: Last edited by K.i.N.G; 30th July 2018 at 12:28. |
30th July 2018, 12:17 | #6235 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,733
|
--qg-size could be something to look at. Lowering it will cause the bitrate to rise though.
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
30th July 2018, 13:31 | #6237 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,783
|
A value of 64 was only recommended for UHD material and has caused known over-blurring issues in the history of x265; I am not sure if they were completely fixed. 32 used to be a default; 16 may even be a bit pessimistic.
|
30th July 2018, 13:41 | #6238 | Link | |
Registered User
Join Date: Aug 2009
Posts: 90
|
Quote:
I tried a value of 16 to see if its better (would've tried 32 afterwards to see if its good enough). Anyway, setting it to 16 made the artifacts smaller and thus a bit less obvious, but they still annoy me... Right now I'm doing an encode with strong intra smoothing to see if that maybe helps... Going to try an higher AQ strength after that but I'm affraid that's going to boost the bit rate a bit too much since it also affects areas that are already good enough (if im not mistaken?)... |
|
31st July 2018, 03:36 | #6240 | Link | |
Angel of Night
Join Date: Nov 2004
Location: Tangled in the silks
Posts: 9,559
|
Quote:
I noticed you raised qcomp to 0.7 from the default 0.6, effectively telling x265, "I want fast-motion and difficult-to-compress scenes compressed harder than usual." Was there a specific reason for raising it? Lastly, are you sure you're not fixating on three frames that in motion will be utterly unnoticeable everyone who actually watches? It's a very common ailment when you go down the rabbit hole of settings. You have to balance frame analysis, especially in "fast moving objects" scenes, with real-life watching of a whole whole scene. |
|
|
|