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 6th February 2021, 19:14   #8001  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 480
x265 v3.5_RC1 (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 10.2.0)
Code:
https://bitbucket.org/multicoreware/x265_git/commits/branch/Release_3.5
Barough is offline   Reply With Quote
Old 6th February 2021, 23:11   #8002  |  Link
MeteorRain
結城有紀
 
Join Date: Dec 2003
Location: NJ; OR; Shanghai
Posts: 894
Quote:
Originally Posted by DJATOM View Post
Also you can ask Pat to make StaxRip edition, merging and unifying from both worlds
Second this, and I think it may be better to create an org to organize these projects. We are individuals and we may not always be available to fix issues or implement new features. If we can manage to get a small group of people collaborating on the stax project it may be easier.
__________________
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 7th February 2021, 12:45   #8003  |  Link
stax76
Registered User
 
stax76's Avatar
 
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
The staxrip github org could be used too, no problem. The needed things are a project name, for instance community mod, people who think can work together, and there is the question if binaries should be released on github.

staxrip change I made yesterday is reading --version output to detect if it's a mod and what type of mod and then use different code paths depending on if it's aMod, Asuna or Vanilla, should have done this before.
stax76 is offline   Reply With Quote
Old 9th February 2021, 00:19   #8004  |  Link
nakTT
Registered User
 
Join Date: Dec 2008
Posts: 415
Quote:
Originally Posted by Barough View Post
x265 v3.5_RC1 (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 10.2.0)
Code:
https://bitbucket.org/multicoreware/x265_git/commits/branch/Release_3.5
Thanks for the latest build.
nakTT is offline   Reply With Quote
Old 9th February 2021, 08:17   #8005  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
Note: Multicoreware asks to refresh x265 clone

Quote:
Originally Posted by Aruna Matheswaran
We had to recently strip a commit that got pushed into Release_3.5 branch due to some unavoidable reasons. Hence, we request all those who auto-update x265 to refresh your git repos so that we'll be on the same page.
E.g. in media-autobuild suite, you would remove the build/x265_git-git directory before running the suite again.

PS: Well, m-ab-s does not aim for the Release_3.5 branch. Would have to be the HEAD if.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid

Last edited by LigH; 12th February 2021 at 08:54.
LigH is offline   Reply With Quote
Old 11th February 2021, 13:27   #8006  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 480
x265 v3.5_RC1+2-f3f27198 (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 10.2.0)
Code:
https://bitbucket.org/multicoreware/x265_git/commits/branch/Release_3.5
Barough is offline   Reply With Quote
Old 12th February 2021, 15:23   #8007  |  Link
PoeBear
Registered User
 
Join Date: Jan 2017
Posts: 48
Quote:
Originally Posted by FranceBB View Post
Chroma bleeding is actually really weird, it shouldn't really happen and I think I know why it's happening to you!
Your input is an AVS Script from what I see, which handles 4:2:0 Type 1 but not 4:2:0 Type2!
So, the chroma location is wrong, hence the "bleeding".

Can you try with:

Code:
ffmpeg.exe -i "AVS Script.avs" -vf scale=out_color_matrix=bt2020nc:out_h_chr_pos=0:out_v_chr_pos=0 -pix_fmt yuv420p16le -strict -1 -an -f yuv4mpegpipe - | x265.exe --y4m - --dither
followed by the rest of your x265 command line? This should solve the chroma bleeding problem.
Finally got around to trying this, after tracking down some 32-bit ffmpeg builds (the 64-bit builds try to load 64-bit AviSynth+ and 64-bit plugins, threw me for a loop momentarily)

But it's drastically altering the colors when running the same exact x265 commands

Here's a comparison between the normal avs2yuv pipe I was using, and then your ffmpeg pipe from above:


Here they are tonemapped for better comparison of the changes:


Here were the commands ran, I just used one of my recent tests so I could do a comparison

Code:
avs2yuv.exe "Script.avs" - | "x265.exe" -D 10 --crf 10.5 --profile main10 --level-idc 5.1 --high-tier --preset placebo --input-depth 16 --cu-lossless 
--pmode --bframes 16 --qg-size 32 --frame-threads 4 --ref 6 --limit-refs 1 --merange 57 --no-amp --tskip --tskip-fast --limit-modes --no-open-gop --hrd
 --cbqpoffs -0 --crqpoffs -1 --no-cutree --deblock -2:-2 --psy-rd 2.50 --psy-rdoq 1.00 --qcomp .6 --aq-mode 2 --aq-strength 1.0 --ipratio 1.3 --pbratio 1.2
 --vbv-bufsize 160000 --vbv-maxrate 160000 --aud --hdr10 --hdr10-opt --range limited --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc
 --master-display G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50) --max-cll 602,187 --chromaloc 2 --repeat-headers
 --output "pmode-sao-tskip-r1-test.hevc" --frames 3000 --y4m -
Code:
ffmpeg.exe -i "Script.avs" -vf scale=out_color_matrix=bt2020nc:out_h_chr_pos=0:out_v_chr_pos=0 -pix_fmt yuv420p16le -strict -1 -an -f yuv4mpegpipe - | x265.exe
 --y4m - --dither --output-depth 10 --crf 10.5 --profile main10 --level-idc 5.1 --high-tier --preset placebo --input-depth 16 --cu-lossless --pmode --bframes 16
 --qg-size 32 --frame-threads 4 --ref 6 --limit-refs 1 --merange 57 --no-amp --tskip --tskip-fast --limit-modes --no-open-gop --hrd --cbqpoffs -0 --crqpoffs -1
 --no-cutree --deblock -2:-2 --psy-rd 2.50 --psy-rdoq 1.00 --qcomp .6 --aq-mode 2 --aq-strength 1.0 --ipratio 1.3 --pbratio 1.2 --vbv-bufsize 160000
 --vbv-maxrate 160000 --aud --hdr10 --hdr10-opt --range limited --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc
 --master-display G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50) --max-cll 602,187 --chromaloc 2 --repeat-headers
 --output "pmode-sao-tskip-r1-testFF.hevc" --frames 3000
Quote:
Originally Posted by FranceBB View Post
True, but the thing is that he was using chromaloc 2 in x265 but his input (the AVS Script output) wasn't, so it was just wrong. Either he specifies the normal 4:2:0 or he converts it to type2 and specifies chromaloc 2. That's what I meant
My input is just the raw video track from the UHD (which is chromaloc 2 per the UHD Blu-ray spec) indexed with DGDecNV. Is there a limitation with the way AviSynth+ outputs?

Script.avs:
Code:
DGSource("UHD.dgi")
Crop(0,276,-0,-276)
z_Spline36Resize(1920,804)

Last edited by PoeBear; 12th February 2021 at 15:27. Reason: No wordwrap on the code tag...
PoeBear is offline   Reply With Quote
Old 12th February 2021, 21:40   #8008  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
I suspect you need to specify PQ as well as 2020 in ffmpeg somehow, if it supports it yet.

You want the whole SMPTE Rec.2100 package.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 22nd February 2021, 18:44   #8009  |  Link
_kermit
Registered User
 
Join Date: Apr 2017
Posts: 63
currently I use this to encode:

ffmpeg.exe -i abc.mkv -pix_fmt yuv420p -f yuv4mpegpipe -| x265.exe -o output

But this doesn't use all my new 12 cores to a 100%, maybe half.
How can I improve this?
_kermit is offline   Reply With Quote
Old 22nd February 2021, 19:32   #8010  |  Link
microchip8
ffx264/ffhevc author
 
microchip8's Avatar
 
Join Date: May 2007
Location: /dev/video0
Posts: 1,843
Quote:
Originally Posted by _kermit View Post
currently I use this to encode:

ffmpeg.exe -i abc.mkv -pix_fmt yuv420p -f yuv4mpegpipe -| x265.exe -o output

But this doesn't use all my new 12 cores to a 100%, maybe half.
How can I improve this?
Have you tried passing --pmode to x265?
__________________
ffx264 || ffhevc || ffxvid || microenc
microchip8 is offline   Reply With Quote
Old 22nd February 2021, 20:10   #8011  |  Link
stax76
Registered User
 
stax76's Avatar
 
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
Quote:
But this doesn't use all my new 12 cores to a 100%, maybe half.
How can I improve this?
Split into chunks maybe.

https://github.com/staxrip/staxrip/w...chunk-encoding
stax76 is offline   Reply With Quote
Old 22nd February 2021, 21:15   #8012  |  Link
_kermit
Registered User
 
Join Date: Apr 2017
Posts: 63
Quote:
Originally Posted by microchip8 View Post
Have you tried passing --pmode to x265?
no, haven't tried anything.
The question came up when using fastflix, which utilized almost 100% with UHD. I don't think it's related to UHD, just that it does it differently.

like this (1080p):
"C:/Users/admin/AppData/Roaming/FFmpeg/bin/ffmpeg.exe" -y -to 6492.7 -i "abc.mkv" -metadata title="abc" -max_muxing_queue_size 1024 -filter_complex "[0:0]crop=1920:800:0:140[v]" -map "[v]" -c:v libx265 -pix_fmt yuv420p10le -x265-params "aq-mode=2:repeat-headers=0:strong-intra-smoothing=1:bframes=4:b-adapt=2:frame-threads=0:hdr10_opt=0:hdr10=0" -crf 20 -preset medium -map_metadata -1 -map_chapters 0 "abc.mkv"

it's not piping but using libx265 (?), but how do I use that?
_kermit is offline   Reply With Quote
Old 22nd February 2021, 21:18   #8013  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by _kermit View Post
no, haven't tried anything.
The question came up when using fastflix, which utilized almost 100% with UHD. I don't think it's related to UHD, just that it does it differently.
Being UHD is actually pretty substantial. There's a lot of frame-size proportional parallelism in x265, so bigger frames use more cores. Wavefront Parallel Processing is the most obvious one, where you extra parallelism out of each 64 pixels of frame height.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 22nd February 2021, 22:08   #8014  |  Link
_kermit
Registered User
 
Join Date: Apr 2017
Posts: 63
Quote:
Originally Posted by benwaggoner View Post
Being UHD is actually pretty substantial. There's a lot of frame-size proportional parallelism in x265, so bigger frames use more cores. Wavefront Parallel Processing is the most obvious one, where you extra parallelism out of each 64 pixels of frame height.
ok, I guess I have to check with 1080p and fastflix first, or vice versa.

EDIT:

Indeed, 1080p is also not using all CPU power as UHD does.
Adding --pmode to fastflix doesn't change that.
I'm actually not that much concerned. If it's easy to do fine, otherwise never mind

But, any suggestions for 1080p CPU usage?

thanks.

Last edited by _kermit; 23rd February 2021 at 17:20.
_kermit is offline   Reply With Quote
Old 25th February 2021, 18:27   #8015  |  Link
charliebaby
Registered User
 
charliebaby's Avatar
 
Join Date: Jun 2020
Posts: 37
@_kermit ? video test 2pass =
https://i.goopics.net/bem88.png
__________________

Last edited by charliebaby; 25th February 2021 at 18:31.
charliebaby is offline   Reply With Quote
Old 26th February 2021, 17:36   #8016  |  Link
MeteorRain
結城有紀
 
Join Date: Dec 2003
Location: NJ; OR; Shanghai
Posts: 894
Quote:
Originally Posted by _kermit View Post
But, any suggestions for 1080p CPU usage?
If you don't mind slightly lower efficiency you can try --ctu 32. That essentially half the row size, doubling the number of rows.
__________________
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 3rd March 2021, 08:06   #8017  |  Link
_kermit
Registered User
 
Join Date: Apr 2017
Posts: 63
Quote:
Originally Posted by charliebaby View Post
@_kermit ? video test 2pass =
https://i.goopics.net/bem88.png
I always use CRF. Is 2pass doing something better in that regard?
_kermit is offline   Reply With Quote
Old 3rd March 2021, 08:08   #8018  |  Link
_kermit
Registered User
 
Join Date: Apr 2017
Posts: 63
Quote:
Originally Posted by MeteorRain View Post
If you don't mind slightly lower efficiency you can try --ctu 32. That essentially half the row size, doubling the number of rows.
makes no difference
_kermit is offline   Reply With Quote
Old 3rd March 2021, 08:45   #8019  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
Quote:
Originally Posted by _kermit View Post
I always use CRF. Is 2pass doing something better in that regard?
2-pass encoding is only required if you aim for a specified target size. In fact, it will calculate the optimal CRF value for its 2nd pass from statistics gathered during a 1st pass.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 3rd March 2021, 11:15   #8020  |  Link
tormento
Acid fr0g
 
tormento's Avatar
 
Join Date: May 2002
Location: Italy
Posts: 2,542
Quote:
Originally Posted by Barough View Post
x265 v3.5_RC1+2-f3f27198
Thanks!

Would you please release processor builds? At least SandyBridge I still own
__________________
@turment on Telegram
tormento 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 20:42.


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