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 23rd July 2018, 14:53   #6221  |  Link
alex1399
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.
alex1399 is offline   Reply With Quote
Old 25th July 2018, 05:01   #6222  |  Link
alex1399
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.
alex1399 is offline   Reply With Quote
Old 25th July 2018, 20:56   #6223  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
Quote:
Originally Posted by alex1399 View Post
Now I feel disgusting about those superfluous 10-bit-depth video which was encoded from 8-bit-depth raw source.
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).
FranceBB is offline   Reply With Quote
Old 26th July 2018, 19:44   #6224  |  Link
MeteorRain
結城有紀
 
Join Date: Dec 2003
Location: NJ; OR; Shanghai
Posts: 894
Quote:
Originally Posted by alex1399 View Post
Now I feel disgusting about those superfluous 10-bit-depth video which was encoded from 8-bit-depth raw source.
Have you ever taken the internal bit-depth / precision loss into consideration? IIRC 8-bit HEVC uses 8-bit internal processing which will effectively reduce the bit-depth to lower than 8-bit. (Correct me if I'm outdated)

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.
MeteorRain is offline   Reply With Quote
Old 26th July 2018, 22:01   #6225  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,406
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
Asmodian is offline   Reply With Quote
Old 27th July 2018, 19:08   #6226  |  Link
MeteorRain
結城有紀
 
Join Date: Dec 2003
Location: NJ; OR; Shanghai
Posts: 894
Quote:
Originally Posted by Asmodian View Post
That was true in AVC but HEVC uses a high bitdepth for most of the math internally, for all output bitdepths
My memory says that, but I did a quick search and couldn't find anything saying x265 is using high bitdepth for internal precision. So not very certain about that part.
__________________
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
MeteorRain is offline   Reply With Quote
Old 27th July 2018, 19:10   #6227  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
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...
Boulder is offline   Reply With Quote
Old 28th July 2018, 12:01   #6228  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 480
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
Barough is offline   Reply With Quote
Old 29th July 2018, 06:11   #6229  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,558
Quote:
Originally Posted by MeteorRain View Post
My memory says that, but I did a quick search and couldn't find anything saying x265 is using high bitdepth for internal precision. So not very certain about that part.
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.)
foxyshadis is offline   Reply With Quote
Old 29th July 2018, 15:55   #6230  |  Link
alex1399
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
alex1399 is offline   Reply With Quote
Old 29th July 2018, 16:06   #6231  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
--crf 0 is not meant to be lossless.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 29th July 2018, 16:29   #6232  |  Link
sneaker_ger
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.
sneaker_ger is offline   Reply With Quote
Old 29th July 2018, 17:17   #6233  |  Link
alex1399
Registered User
 
Join Date: Jun 2018
Posts: 56
If x265 is fine, I'm fine. Just messing around to seek some ordinary mistakes that common people will make during encoding process. Those rare conditions are not bugs, maybe.
alex1399 is offline   Reply With Quote
Old 30th July 2018, 12:09   #6234  |  Link
K.i.N.G
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.
K.i.N.G is offline   Reply With Quote
Old 30th July 2018, 12:17   #6235  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
--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...
Boulder is offline   Reply With Quote
Old 30th July 2018, 12:28   #6236  |  Link
K.i.N.G
Registered User
 
Join Date: Aug 2009
Posts: 90
Quote:
Originally Posted by Boulder View Post
--qg-size could be something to look at. Lowering it will cause the bitrate to rise though.
Thank you, I've lowered it to 16 and will report back when its finished.

I can live with 'slight' bitrate increases (which is perfectly understandable).
K.i.N.G is offline   Reply With Quote
Old 30th July 2018, 13:31   #6237  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
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.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 30th July 2018, 13:41   #6238  |  Link
K.i.N.G
Registered User
 
Join Date: Aug 2009
Posts: 90
Quote:
Originally Posted by LigH View Post
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.
Its an UHD source
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?)...
K.i.N.G is offline   Reply With Quote
Old 30th July 2018, 13:52   #6239  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
Quote:
Originally Posted by LigH View Post
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.
I started using 16 after I switched to --ctu 32.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 31st July 2018, 03:36   #6240  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,558
Quote:
Originally Posted by K.i.N.G View Post
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:
The only way to get x265 to retain detail/grain in absolutely all circumstances is --tune grain combined with enough bitrate to not starve it. That will massively change but the bitrate and distribution of your entire movie, not a first choice if you're happy with the rest.

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.
foxyshadis 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 18:02.


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