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 31st May 2019, 14:56   #6841  |  Link
stax76
Registered User
 
stax76's Avatar
 
Join Date: Jun 2002
Location: Germany
Posts: 5,631
The zones feature is broken in 3.0+2, it encodes to the end but returns an error code, cmd/batch users normally don't check for the exit code, so they don't notice the problem but staxrip treats this a fatal and aborts further processing.

Code:
ffmpeg -i test.avs -f yuv4mpegpipe - | x265 --crf 22 --output-depth 10 --zones 0,200,b=1.2 --frames 300 --y4m --output test.hevc -

echo %ERRORLEVEL%
pause
Quote:
Video encoding using x265 3.0+2 Wolfberry failed with exit code: -1073740940 (0xC0000374)

The exit code might be a system error code: A heap has been corrupted.
Quote:
The feature you are referring to is probably this commit: Cosmetic: x264-r2204 style progress indicator

@MeteorRain's signature contains the link to the x265 binaries built from the Yuuki / Asuna branch of https://github.com/msg7086/x265-Yuuki-Asuna.
Probably yes, thanks.
stax76 is online now   Reply With Quote
Old 1st June 2019, 08:43   #6842  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 580
I have a question.
Is it possible to use tune vmaf in x265 v3.1?
Code:
x265 has 5 tune modes (psnr, ssim, grain, zero-latency, animation) whereas SVT-HEVC
has only 3 tune modes (0 - visual quality, 1 - PSNR / SSIM and 2 - VMAF). Below 
table shows the mapping of tune modes,

+-----------------------+---------------------------+
| x265 Tune Modes       | SVT-HEVC Tune Modes       |
+=======================+===========================+
| vmaf                  | 2                         |
+-----------------------+---------------------------+
| psnr                  | 1                         |
+-----------------------+---------------------------+
| ssim                  | 1                         |
+-----------------------+---------------------------+
| grain                 | 0                         |
+-----------------------+---------------------------+
| fastdecode            | 0                         |
+-----------------------+---------------------------+
| zerolatency           | 0                         |
+-----------------------+---------------------------+
| animation             | 0                         |
If so how to initiate it?
api->param_default_preset(p, preset, "vmaf");

Last edited by Jamaika; 1st June 2019 at 15:55.
Jamaika is offline   Reply With Quote
Old 7th June 2019, 14:50   #6843  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 326
x265 v3.1_RC1+1-10decf67c077 (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.1.0)

Code:
https://bitbucket.org/multicoreware/x265/commits/branch/Release_3.1
Barough is offline   Reply With Quote
Old 11th June 2019, 11:11   #6844  |  Link
Natty
Noob
 
Join Date: Mar 2017
Posts: 163
Quote:
Originally Posted by MeteorRain View Post
Did you say you make .yuv raw using ffv1 lossless? So would that be an AVI file instead?
i love your yuuki x265 mod, i used the latest 3.1 version, but observed that it hides encoding settings in mediainfo. i didn't change any encoding setting while using your mod..

hoping to get regular gcc 9.1 build updates from you.
Natty is offline   Reply With Quote
Old 11th June 2019, 19:20   #6845  |  Link
MeteorRain
結城有紀
 
Join Date: Dec 2003
Location: NJ; OR; Shanghai
Posts: 543
Quote:
Originally Posted by Natty View Post
i love your yuuki x265 mod, i used the latest 3.1 version, but observed that it hides encoding settings in mediainfo. i didn't change any encoding setting while using your mod..

hoping to get regular gcc 9.1 build updates from you.
Natty,

Thank you for the kind word. I have fixed the issue and slip-streamed to the same file.

I intentionally downgraded to gcc 8.3 as I expect a performance regression on newer gcc. But I might change my mind and upgrade to gcc 9.1 on final build. Suggestions welcome.
MeteorRain is online now   Reply With Quote
Old 12th June 2019, 16:25   #6846  |  Link
Natty
Noob
 
Join Date: Mar 2017
Posts: 163
Quote:
Originally Posted by MeteorRain View Post
Natty,

Thank you for the kind word. I have fixed the issue and slip-streamed to the same file.

I intentionally downgraded to gcc 8.3 as I expect a performance regression on newer gcc. But I might change my mind and upgrade to gcc 9.1 on final build. Suggestions welcome.
it working fine
Natty is offline   Reply With Quote
Old 14th June 2019, 18:36   #6847  |  Link
birdie
.
 
birdie's Avatar
 
Join Date: Dec 2006
Posts: 135
Has the meaning of CRF wildly changed since version 2.4?

I'm encoding the same source video using 2.4 and 3.0 using absolutely the same options ( -preset veryslow -x265-params keyint=600:min-keyint=30:bframes=16:crf=22:no-sao=1 - it's relatively static which is why keyint is so high) and 3.0 produces the file which is significantly heavier.

Code:
104,103,181 bytes for v2.4
128,682,330 bytes for v3.0
Also encoding has become significantly slower:

Code:
2.4: encoded 10656 frames in  6302.40s (1.69 fps), 2229.94 kb/s, Avg QP:27.68
3.0: encoded 10656 frames in 11981.75s (0.89 fps), 2780.38 kb/s, Avg QP:27.30
Full output for 2.4:

Code:
x265 [info]: HEVC encoder version 2.4
x265 [info]: build info [Linux][GCC 6.3.1][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main profile, Level-3.1 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: Slices                              : 1
x265 [info]: frame threads / pool features       : 2 / wpp(12 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 3 inter / 3 intra
x265 [info]: ME / range / subpel / merge         : star / 57 / 4 / 4
x265 [info]: Keyframe min / max / scenecut / bias: 30 / 600 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt        : 40 / 16 / 2
x265 [info]: b-pyramid / weightp / weightb       : 1 / 1 / 1
x265 [info]: References / ref-limit  cu / depth  : 5 / off / on
x265 [info]: AQ: mode / str / qg-size / cu-tree  : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress            : CRF-22.0 / 0.60
x265 [info]: tools: rect amp limit-modes rd=6 psy-rd=2.00 rdoq=2 psy-rdoq=1.00
x265 [info]: tools: rskip limit-tu=4 signhide tmvp b-intra
x265 [info]: tools: strong-intra-smoothing deblock
Output #0, matroska, to '265.mkv':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf57.71.100
    Stream #0:0(eng): Video: hevc (libx265), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], q=2-31, 29.83 fps, 1k tbn, 29.83 tbc (default)
    Metadata:
      handler_name    : VideoHandler
      encoder         : Lavc57.89.100 libx265
    Stream #0:1(eng): Audio: aac (LC) ([255][0][0][0] / 0x00FF), 48000 Hz, mono, fltp, 96 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
frame=10656 fps=1.7 q=-0.0 Lsize=  101663kB time=00:05:57.24 bitrate=2331.2kbits/s speed=0.0567x
video:97282kB audio:4187kB subtitle:0kB other streams:0kB global headers:2kB muxing overhead: 0.192047%
x265 [info]: frame I:     20, Avg QP:20.80  kb/s: 13832.49
x265 [info]: frame P:   2322, Avg QP:22.77  kb/s: 6661.60
x265 [info]: frame B:   8314, Avg QP:29.07  kb/s: 964.32
x265 [info]: Weighted P-Frames: Y:11.9% UV:9.3%
x265 [info]: Weighted B-Frames: Y:6.8% UV:4.4%
x265 [info]: consecutive B-frames: 7.3% 5.3% 8.5% 30.1% 16.4% 21.8% 6.9% 3.2% 0.2% 0.2% 0.1% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%
Full output for 3.0:

Code:
x265 [info]: HEVC encoder version 3.0
x265 [info]: build info [Linux][GCC 9.1.1][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main profile, Level-3.1 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: Slices                              : 1
x265 [info]: frame threads / pool features       : 2 / wpp(12 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 3 inter / 3 intra
x265 [info]: ME / range / subpel / merge         : star / 57 / 4 / 5
x265 [info]: Keyframe min / max / scenecut / bias: 30 / 600 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt        : 40 / 16 / 2
x265 [info]: b-pyramid / weightp / weightb       : 1 / 1 / 1
x265 [info]: References / ref-limit  cu / depth  : 5 / off / off
x265 [info]: AQ: mode / str / qg-size / cu-tree  : 2 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress            : CRF-22.0 / 0.60
x265 [info]: tools: rect amp rd=6 psy-rd=2.00 rdoq=2 psy-rdoq=1.00 rskip
x265 [info]: tools: signhide tmvp b-intra strong-intra-smoothing deblock
Output #0, matroska, to '265.mkv':
  Metadata:
    major_brand     : mp42
    minor_version   : 0
    compatible_brands: isommp42
    com.android.version: 6.0
    encoder         : Lavf58.20.100
    Stream #0:0(eng): Video: hevc (libx265), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], q=2-31, 29.83 fps, 1k tbn, 29.83 tbc (default)
    Metadata:
      encoder         : Lavc58.35.100 libx265
      handler_name    : VideoHandle
    Stream #0:1(eng): Audio: aac (LC) ([255][0][0][0] / 0x00FF), 48000 Hz, mono, fltp, 96 kb/s (default)
    Metadata:
      handler_name    : SoundHandle
frame=10656 fps=0.9 q=-0.0 Lsize=  125666kB time=00:05:57.24 bitrate=2881.6kbits/s speed=0.0298x    
video:121284kB audio:4187kB subtitle:0kB other streams:0kB global headers:2kB muxing overhead: 0.155674%
x265 [info]: frame I:     20, Avg QP:20.69  kb/s: 16303.41
x265 [info]: frame P:   2322, Avg QP:22.30  kb/s: 8450.15 
x265 [info]: frame B:   8314, Avg QP:28.71  kb/s: 1164.35 
x265 [info]: Weighted P-Frames: Y:11.9% UV:9.3%
x265 [info]: Weighted B-Frames: Y:6.8% UV:4.4%
x265 [info]: consecutive B-frames: 7.3% 5.3% 8.5% 30.1% 16.4% 21.8% 6.9% 3.2% 0.2% 0.2% 0.1% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 

encoded 10656 frames in 11981.75s (0.89 fps), 2780.38 kb/s, Avg QP:27.30

Last edited by birdie; 14th June 2019 at 18:42.
birdie is offline   Reply With Quote
Old 14th June 2019, 18:55   #6848  |  Link
ChaosKing
Registered User
 
Join Date: Dec 2005
Location: Germany
Posts: 931
Different settings affect the CRF output: https://x265.readthedocs.io/en/defau...r-enhancements

Quote:
Preset: change param defaults for veryslow and slower preset. Replace slower preset with defaults used in veryslow preset and change param defaults in veryslow preset as per experimental results.
AQ: change default AQ mode to auto-variance
__________________
AVSRepoGUI // VSRepoGUI - Package Manager for AviSynth // VapourSynth
VapourSynth Portable FATPACK || VapourSynth Database || https://github.com/avisynth-repository
ChaosKing is offline   Reply With Quote
Old 14th June 2019, 20:54   #6849  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,562
Filesize is probably due to the default aq-mode being 2 now. It often causes a higher average bitrate with the same CRF than aq-mode 1.
__________________
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 15th June 2019, 01:25   #6850  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,512
The preset changes also mean veryslow is radically different relative to 2.4.

[edit] Just saw this was mentioned already [/edit]
Blue_MiSfit is offline   Reply With Quote
Old 15th June 2019, 16:13   #6851  |  Link
katzenjoghurt
Registered User
 
Join Date: Feb 2007
Posts: 85
Quote:
Originally Posted by stax76 View Post
The zones feature is broken in 3.0+2, it encodes to the end but returns an error code, cmd/batch users normally don't check for the exit code, so they don't notice the problem but staxrip treats this a fatal and aborts further processing.[...]
Could some kind soul please, please, pretty please investigate this bug?
It is so annoying.

It means that after every encoding with zones (with an affected tool) your would need to do the muxing manually afterwards
as the tool crashes away due to the returned x265 error code.

See also: https://bitbucket.org/multicoreware/...hen-using-zone

Last edited by katzenjoghurt; 15th June 2019 at 16:15.
katzenjoghurt is offline   Reply With Quote
Old 15th June 2019, 17:43   #6852  |  Link
birdie
.
 
birdie's Avatar
 
Join Date: Dec 2006
Posts: 135
Quote:
Originally Posted by ChaosKing View Post
Different settings affect the CRF output: https://x265.readthedocs.io/en/defau...r-enhancements
My settings were 100% identical.
birdie is offline   Reply With Quote
Old 15th June 2019, 21:56   #6853  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,562
No they're not if you look at the output in your post. I still think the biggest difference comes from aq-mode changing from 1 to 2. The other changes should cause a much smaller change in the bitrate.

EDIT: as mentioned earlier, the presets have been changed. Veryslow in v2.4 is different from v3.0.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...

Last edited by Boulder; 15th June 2019 at 21:59.
Boulder is offline   Reply With Quote
Old 15th June 2019, 22:29   #6854  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 326
x265 v3.1_RC1+3-3bdf06e3c628 (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.1.0)

Code:
https://bitbucket.org/multicoreware/x265/commits/branch/Release_3.1
Barough is offline   Reply With Quote
Old 16th June 2019, 07:09   #6855  |  Link
StvG
Registered User
 
Join Date: Jul 2018
Posts: 91
Quote:
Originally Posted by katzenjoghurt View Post
Could some kind soul please, please, pretty please investigate this bug?
It is so annoying.

It means that after every encoding with zones (with an affected tool) your would need to do the muxing manually afterwards
as the tool crashes away due to the returned x265 error code.

See also: https://bitbucket.org/multicoreware/...hen-using-zone
Use VS20xx not GCC x.x build from here.
StvG is offline   Reply With Quote
Old 16th June 2019, 10:49   #6856  |  Link
katzenjoghurt
Registered User
 
Join Date: Feb 2007
Posts: 85
Hey StvG,

in fact I already do. I'm using the VS2019 versions from there.
katzenjoghurt is offline   Reply With Quote
Old 16th June 2019, 11:01   #6857  |  Link
katzenjoghurt
Registered User
 
Join Date: Feb 2007
Posts: 85
Quote:
Originally Posted by katzenjoghurt View Post
Oh my.
Am I the only one having such a hard time encoding scenes with red light / red backgrounds?

[...]
Oh man. I THINK I finally found a solution for my neverending problem with red areas getting blurred and/or blocky.

People already gave me a hint to use 10bit encoding or playing around with the crqpoffs parameter. Both didn't really help.

This changed drastically now after I converted the source to YV24 colorspace and encoded it with Main 444 10.

Suddenly the crqpoffs parameter started to work wonders and setting it to -1 already brought back most of the details.


How to do it in StaxRip 1.7.0.6:
1) Click on the "AVS Filter" label. Click "Profiles".
2) Find the [Misc] section and add this line to the bottom: ConvertToYV24 = ConvertToYV24()
3) Add the Filter now via right-click -> Misc -> ConvertToYV24
4) Go into the x265 encoder settings
5) In "Basic" chose the Main 444 10 profile.
6) In "Rate Control 1" set CR QB Offset to -1.

Last edited by katzenjoghurt; 16th June 2019 at 11:24.
katzenjoghurt is offline   Reply With Quote
Old 17th June 2019, 05:20   #6858  |  Link
StvG
Registered User
 
Join Date: Jul 2018
Posts: 91
Quote:
Originally Posted by katzenjoghurt View Post
Hey StvG,

in fact I already do. I'm using the VS2019 versions from there.
Hey. A week ago or so I tested VS2019 builds and I had no problems when using zones. GCC builds were crashing when using zones.
StvG is offline   Reply With Quote
Old 17th June 2019, 09:12   #6859  |  Link
birdie
.
 
birdie's Avatar
 
Join Date: Dec 2006
Posts: 135
Quote:
Originally Posted by Boulder View Post
No they're not if you look at the output in your post. I still think the biggest difference comes from aq-mode changing from 1 to 2. The other changes should cause a much smaller change in the bitrate.

EDIT: as mentioned earlier, the presets have been changed. Veryslow in v2.4 is different from v3.0.
I thought CRF actually meant something. Not really a given bitrate but something close to it.
birdie is offline   Reply With Quote
Old 17th June 2019, 11:05   #6860  |  Link
mini-moose
Registered User
 
Join Date: Oct 2007
Posts: 375
Quote:
Originally Posted by birdie View Post
I thought CRF actually meant something. Not really a given bitrate but something close to it.
the lower the CRF value, the higher the bitrate. slowdown is due to preset changes, bitrate differences are due to AQ mode changing from AQ1 default to AQ2 default.

I found that AQ1 was giving a higher bitrate than AQ2, but I suppose it depends on source. I think AQ1 is constant while AQ2 is variable.
mini-moose 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 02:28.


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