VideoHelp Forum
+ Reply to Thread
Page 26 of 27
FirstFirst ... 16 24 25 26 27 LastLast
Results 751 to 780 of 782
Thread
  1. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    New milestone: v2.5

    Originally Posted by pradeeprama View Post
    x265 version 2.5, which includes improvements to grain handling, and improved CSV logging feature which is now built into the library.

    Version 2.5 can be downloaded from here (md5: 192e54fa3068b594aa44ab2b703f071d).Full documentation is available at http://x265.readthedocs.io/en/stable/

    Release Notes for Version 2.5
    =======================

    Encoder enhancements
    --------------------------------
    1. Improved grain handling with --tune grain option by throttling VBV operations to limit QP jumps.
    2. Frame threads are now decided based on number of threads specified in the --pools, as opposed to the number of hardware threads available. The mapping was also adjusted to improve quality of the encodes with minimal impact to performance.
    3. CSV logging feature (enabled by --csv) is now part of the library; it was previously part of the x265 application. Applications that integrate libx265 can now extract frame level statistics for their encodes by exercising this option in the library.
    4. Globals that track min and max CU sizes, number of slices, and other parameters have now been moved into instance-specific variables. Consequently, applications that invoke multiple instances of x265 library are no longer restricted to use the same settings for these parameter options across the multiple instances.
    x265 can now generate a seprate library that exports the HDR10+ parsing API. Other libraries that wish to use this API may do so by linking against this library. Enable ENABLE_HDR10_PLUS in CMake options and build to generate this library.
    5. SEA motion search receives a 10% performance boost from AVX2 optimization of its kernels.
    6. The CSV log is now more elaborate with additional fields such as PU statistics, average-min-max luma and chroma values, etc. Refer to documentation of --csv for details of all fields.
    7. x86inc.asm cleaned-up for improved instruction handling.

    API changes
    -----------------
    1. New API x265_encoder_ctu_info() introduced to specify suggested partition sizes for various CTUs in a frame. To be used in conjunction with --ctu-info to react to the specified partitions appropriately.
    2. Rate-control statistics passed through the x265_picture object for an incoming frame are now used by the encoder.
    3. Options to scale, reuse, and refine analysis for incoming analysis shared through the x265_analysis_data field in x265_picture for runs that use --analysis-reuse-mode load; use options --scale, --refine-mv, --refine-inter, and --refine-intra to explore.
    4. VBV now has a deterministic mode. Use --const-vbv to exercise.

    Bug fixes
    -------------
    1. Several fixes for HDR10+ parsing code including incompatibility with user-specific SEI, removal of warnings, linking issues in linux, etc.
    2. SEI messages for HDR10 repeated every keyint when HDR options (--hdr-opt, --master-display) specified.

    Happy compressing!
    Quote Quote  
  2. Does anyone know if AVX-512 will be added anytime in the near future (next several months or couple years)? I'm getting ready to build a new computer and trying to decide between Intel and AMD, and one of the factors I'm looking at is that Intel has AVX-512 instructions and AMD does not. If it's going to be a couple years at least before it's added to x265, it probably won't matter much, but if there's a good chance of it being implemented in the next year or so, it would be a good reason to go with Intel.
    Quote Quote  
  3. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    The sources have been changed to use NASM instead of YASM (which seems to be more or less obsolete, feature-wise; altering YASM to make it support AVX-512 may be too much efforts, their developers stated). A first step is done...
    Quote Quote  
  4. So I haven't observed any quality increase since build 1.2. 2.6 has same quality as 1.2. Are any of these new settings/fixes actually doing anything? My source is 480p anime as well as real video.
    Quote Quote  
  5. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    Insufficient details. No complete command lines, no sample clips to compare for our eyes too. Well possible your selected parameter set doesn't show obvious differences because the bitrate is e.g. either too high to see any artifacts, or too low to see less, or you did not use any new useful features for the specific material to be compressed, or ... or ...
    Quote Quote  
  6. Originally Posted by LigH.de View Post
    Insufficient details. No complete command lines, no sample clips to compare for our eyes too. Well possible your selected parameter set doesn't show obvious differences because the bitrate is e.g. either too high to see any artifacts, or too low to see less, or you did not use any new useful features for the specific material to be compressed, or ... or ...
    I've done 64, 128 and 256 kb/s. 64 sucks, 128 is pretty good and 256 looks flawless. All three at the same bitrate look exactly the same for all x265 versions.

    Commandline:
    Code:
    avs4x26x --x26x-binary x265_12 "TouhouAnime.avs" --pass 1 --bitrate 128 --tune ssim --ref 1 --rd 2 --ctu 64 --no-rect --no-amp --early-skip --b-intra --no-tskip-fast --tu-intra-depth 3 --tu-inter-depth 3 --tskip --max-merge 1 --me dia --subme 2 --merange 57 --weightp --weightb --rc-lookahead 40 --b-adapt 2 --bframes 8 --cutree --sao -o "Touhou Anime1.2 2pass.hevc"
    
    avs4x26x --x26x-binary x265_12 "TouhouAnime.avs" --pass 2 --bitrate 128 --tune ssim --ref 5 --rd 6 --ctu 64 --rect --amp --no-early-skip --b-intra --no-tskip-fast --tu-intra-depth 3 --tu-inter-depth 3 --tskip --max-merge 4 --me star --subme 4 --merange 57 --weightp --weightb --rc-lookahead 40 --b-adapt 2 --bframes 8 --cutree --sao -o "Touhou Anime1.2 2pass.hevc"
    
    avs4x26x --x26x-binary x265_26 "TouhouAnime.avs" --pass 1 --bitrate 129 --tune ssim --ref 1 --rd 2 --ctu 64 --no-rect --no-amp --early-skip --b-intra --no-tskip-fast --tu-intra-depth 3 --tu-inter-depth 3 --tskip --max-merge 1 --me dia --subme 2 --merange 57 --weightp --weightb --rc-lookahead 40 --b-adapt 2 --bframes 8 --cutree --sao --no-rskip --limit-modes --rd-refine --limit-refs 1 --min-cu-size 8 --rdoq-level 2 --lookahead-slices 1 --deblock=1:1 --no-fast-intra --psy-rdoq 0 -o "Touhou Anime2.6 2pass.hevc"
    
    avs4x26x --x26x-binary x265_26 "TouhouAnime.avs" --pass 2 --bitrate 129 --tune ssim --ref 5 --rd 6 --ctu 64 --rect --amp --no-early-skip --b-intra --no-tskip-fast --tu-intra-depth 3 --tu-inter-depth 3 --tskip --max-merge 4 --me star --subme 4 --merange 57 --weightp --weightb --rc-lookahead 40 --b-adapt 2 --bframes 8 --cutree --sao --no-rskip --limit-modes --rd-refine --limit-refs 1 --min-cu-size 8 --rdoq-level 2 --lookahead-slices 1 --deblock=1:1 --no-fast-intra --psy-rdoq 0 -o "Touhou Anime2.6 2pass.hevc"
    Image Attached Files
    Quote Quote  
  7. Is there a difference when you use a way higher bitrate and the same avisynth script source? (To be sure that the source has details that could be saved with a newer version,...)
    -> looking at the lower bitrates for that source might be more interesting to see differences
    users currently on my ignore list: deadrats, Stears555
    Quote Quote  
  8. Originally Posted by Selur View Post
    Is there a difference when you use a way higher bitrate and the same avisynth script source? (To be sure that the source has details that could be saved with a newer version,...)
    -> looking at the lower bitrates for that source might be more interesting to see differences
    I don't understand the first question. I always use the same source for the same test. What is a "way higher bitrate"?
    At the same bitrate, quality is always the same no matter the version. Quality metrics have remained nearly identical. Using 10-bit makes no difference.

    I'll show you 64 kb/s samples tomorrow if you're more interested in that.
    Quote Quote  
  9. At a bit rate that is high enough for a specific source even MPEG-1 can be on par with H.265.
    So the question is does your source have more details than the reencode? Since you wrote that 256kBit/s seems to be flawless my fear is that it 256 'too' high for the source to gain from better decisions during compression.
    You already wrote that the low bitrate (64) version 'sucks', so the question is do all the encodes of the same bitrate look to you the same or can you differentiate whether for example a 100kBit/s version was encoded using x264 version 1.2 or 2.6, also you only state the quality is the same at the same bitrate, but is the encoding time also the same?

    Cu Selur
    users currently on my ignore list: deadrats, Stears555
    Quote Quote  
  10. Originally Posted by Selur View Post
    At a bit rate that is high enough for a specific source even MPEG-1 can be on par with H.265.
    So the question is does your source have more details than the reencode? Since you wrote that 256kBit/s seems to be flawless my fear is that it 256 'too' high for the source to gain from better decisions during compression.
    The MPEG-1 bitrate would need to be 650 kb/s to match the quality of 64 kb/s H.265 and 3000 kb/s to match H.265 at 256 kb/s.
    Yes, the source does still have more details but you would need the source to directly compare.

    Originally Posted by Selur View Post
    do all the encodes of the same bitrate look to you the same or can you differentiate whether for example a 100kBit/s version was encoded using x264 version 1.2 or 2.6
    Correct, I can't tell the quality apart. The outputs of all versions look the same. 2.6 does not do better than 1.2.

    Originally Posted by Selur View Post
    also you only state the quality is the same at the same bitrate, but is the encoding time also the same?
    No, 2.6 is twice as slower than 1.2 but the same quality. Version 1.8 is the fastest, but again; same quality.

    Here's the 64 kb/s tests.

    Code:
    M:\>avs4x26x --x26x-binary x265_12 "TouhouAnime.avs" --pass 2 --bitrate 66 --tune ssim --ref 5 --rd
    6 --ctu 64 --rect --amp --no-early-skip --b-intra --no-tskip-fast --tu-intra-depth 3 --tu-inter-dept
    h 3 --tskip --max-merge 4 --me star --subme 4 --merange 57 --weightp --weightb --rc-lookahead 40 --b
    -adapt 2 --bframes 8 --cutree --sao -o "Touhou Anime1.2 2pass.hevc"
    avs [info]: AviSynth 2.60, build:Mar 31 2015 [16:38:54]
    avs [info]: Video colorspace: YV12
    avs [info]: Video resolution: 720x480
    avs [info]: Video framerate: 24000/1001
    avs [info]: Video framecount: 5000
    avs4x26x [info]: "x265_12" - --pass 2 --bitrate 66 --tune ssim --ref 5 --rd 6 --ctu 64 --rect --amp
    --no-early-skip --b-intra --no-tskip-fast --tu-intra-depth 3 --tu-inter-depth 3 --tskip --max-merge
    4 --me star --subme 4 --merange 57 --weightp --weightb --rc-lookahead 40 --b-adapt 2 --bframes 8 --c
    utree --sao -o "Touhou Anime1.2 2pass.hevc" --frames 5000 --fps 24000/1001 --input-res 720x480 --inp
    ut-csp i420
    yuv  [info]: 720x480 fps 24000/1001 i420p8 unknown frame count
    x265 [info]: HEVC encoder version 1.2+305-66ed81577483
    x265 [info]: build info [Windows][GCC 4.8.1][32 bit] 8bpp
    x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2
    x265 [info]: WPP streams / pool / frames         : 8 / 8 / 3
    x265 [info]: Main profile, Level-3 (Main tier)
    x265 [info]: CU size                             : 64
    x265 [info]: Max RQT depth inter / intra         : 3 / 3
    x265 [info]: ME / range / subpel / merge         : star / 57 / 4 / 4
    x265 [info]: Keyframe min / max / scenecut       : 23 / 250 / 40
    x265 [info]: Lookahead / bframes / badapt        : 0 / 8 / 2
    x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 1 / 5
    x265 [info]: Rate Control / AQ-Strength / CUTree : ABR-66 kbps / 1.0 / 1
    x265 [info]: tools: rect amp rd=6 lft sao-lcu signhide tskip stats-read
    x265 [info]: frame I:     35, Avg QP:26.77  kb/s: 2600.50
    x265 [info]: frame P:    960, Avg QP:29.89  kb/s: 170.75
    x265 [info]: frame B:   4005, Avg QP:37.78  kb/s: 18.99
    x265 [info]: global :   5000, Avg QP:36.19  kb/s: 66.20
    x265 [info]: Weighted P-Frames: Y:0.7% UV:0.5%
    x265 [info]: Weighted B-Frames: Y:0.3% UV:0.2%
    x265 [info]: consecutive B-frames: 5.0% 5.0% 3.5% 29.4% 16.5% 22.6% 6.5% 6.9% 4.4%
    
    encoded 5000 frames in 823.97s (6.07 fps), 66.20 kb/s
    
    M:\>avs4x26x --x26x-binary x265_26 "TouhouAnime.avs" --pass 2 --bitrate 67 --tune ssim --ref 5 --rd
    6 --ctu 64 --rect --amp --no-early-skip --b-intra --no-tskip-fast --tu-intra-depth 3 --tu-inter-dept
    h 3 --tskip --max-merge 4 --me star --subme 4 --merange 57 --weightp --weightb --rc-lookahead 40 --b
    -adapt 2 --bframes 8 --cutree --sao --no-rskip --limit-modes --rd-refine --limit-refs 1 --min-cu-siz
    e 8 --rdoq-level 2 --lookahead-slices 1 --deblock=1:1 --no-fast-intra --psy-rdoq 0 -o "Touhou Anime2
    .6 2pass.hevc"
    avs [info]: AviSynth 2.60, build:Mar 31 2015 [16:38:54]
    avs [info]: Video colorspace: YV12
    avs [info]: Video resolution: 720x480
    avs [info]: Video framerate: 24000/1001
    avs [info]: Video framecount: 5000
    avs4x26x [info]: "x265_26" - --pass 2 --bitrate 67 --tune ssim --ref 5 --rd 6 --ctu 64 --rect --amp
    --no-early-skip --b-intra --no-tskip-fast --tu-intra-depth 3 --tu-inter-depth 3 --tskip --max-merge
    4 --me star --subme 4 --merange 57 --weightp --weightb --rc-lookahead 40 --b-adapt 2 --bframes 8 --c
    utree --sao --no-rskip --limit-modes --rd-refine --limit-refs 1 --min-cu-size 8 --rdoq-level 2 --loo
    kahead-slices 1 --deblock=1:1 --no-fast-intra --psy-rdoq 0 -o "Touhou Anime2.6 2pass.hevc" --frames
    5000 --fps 24000/1001 --input-res 720x480 --input-csp i420
    yuv  [info]: 720x480 fps 24000/1001 i420p8 unknown frame count
    raw  [info]: output file: Touhou Anime2.6 2pass.hevc
    x265 [info]: HEVC encoder version 2.6+2-32e6f04b8713
    x265 [info]: build info [Windows][GCC 7.2.0][32 bit] 8bit+10bit+12bit
    x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2
    x265 [info]: Main profile, Level-3 (Main tier)
    x265 [info]: Thread pool created using 8 threads
    x265 [info]: Slices                              : 1
    x265 [info]: frame threads / pool features       : 3 / wpp(8 rows)
    x265 [warning]: Source height < 720p; disabling lookahead-slices
    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: 23 / 250 / 40 / 5.00
    x265 [info]: Lookahead / bframes / badapt        : 40 / 8 / 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  : 2 / 1.0 / 32 / 1
    x265 [info]: Rate Control / qCompress            : ABR-67 kbps / 0.60
    x265 [info]: tools: rect amp limit-modes rd=6 rdoq=2 rd-refine tskip signhide
    x265 [info]: tools: tmvp b-intra strong-intra-smoothing deblock(tC=1:B=1) sao
    x265 [info]: tools: stats-read
    x265 [info]: frame I:     36, Avg QP:27.84  kb/s: 2446.41
    x265 [info]: frame P:    972, Avg QP:35.72  kb/s: 176.38
    x265 [info]: frame B:   3992, Avg QP:39.96  kb/s: 18.45
    x265 [info]: Weighted P-Frames: Y:0.1% UV:0.0%
    x265 [info]: Weighted B-Frames: Y:0.4% UV:0.2%
    x265 [info]: consecutive B-frames: 6.4% 5.0% 3.5% 29.3% 17.1% 20.8% 6.7% 6.2% 5.0%
    
    encoded 5000 frames in 1603.43s (3.12 fps), 66.63 kb/s, Avg QP:39.04
    Image Attached Files
    Quote Quote  
  11. Some screenshots of the 64 kb/s encode:
    1.2 actually looks slightly better here IMO but overall they're about the same.
    Image Attached Thumbnails Click image for larger version

Name:	Touhousource.PNG
Views:	150
Size:	477.0 KB
ID:	44239  

    Click image for larger version

Name:	Touhoux265 1.2.PNG
Views:	195
Size:	362.1 KB
ID:	44240  

    Click image for larger version

Name:	Touhoux265 2.6.PNG
Views:	188
Size:	353.8 KB
ID:	44241  

    Quote Quote  
  12. Yes, the source does still have more details but you would need the source to directly compare.
    Okay. So source and used script would be needed for others to validate your statement.

    The colors are 'off' between you source and your encodes, is this intended? If it is intended, you should take screenshots of the source after processing and before reencoding,...
    You might want to set lookahead for both encodes to the same value.

    Cu Selur

    Ps.: Why don't you use 10bit encoding?
    You might want to add VUI signaling (and may be vbv/profile/level-signaling).
    users currently on my ignore list: deadrats, Stears555
    Quote Quote  
  13. Originally Posted by Selur View Post
    Yes, the source does still have more details but you would need the source to directly compare.
    Okay. So source and used script would be needed for others to validate your statement.
    Not feasible. The source is 800MB and my upload speed is shit. I can give a torrent to the source and then provide my Avisynth script but I don't know if this movie is copyrighted or not. Hell, I haven't watched it in the 2 years I had it, it just makes a good test video.

    The colors are 'off' between you source and your encodes, is this intended?
    I don't know what you're talking about.

    You might want to set lookahead for both encodes to the same value.
    They are the same value... I've used identical parameters for all versions except ones that didn't exist until later. Since lookahead is featured in all the tested versions, they've all had the same default value of 40.
    That's why I'm puzzled. Despite all the new features, the quality is not increasing. Why?

    Ps.: Why don't you use 10bit encoding?
    Tried that, it isn't any better quality and it's slow as **** on a 32-bit system. In fact, the quality was slightly worse. I attached it for you. Browse to frame 602 to compare to the screenshot.
    This particular 10-bit encode I attached seems to have been a CRF rather than 2pass encode so it's apples and oranges but my question remains unanswered as to why the quality is stagnating no matter the configuration.

    You might want to add VUI signaling (and may be vbv/profile/level-signaling).
    What's that?
    Image Attached Files
    Quote Quote  
  14. I don't know what you're talking about.
    switching between the screenshots one can easily see in the upper right corner that one clip is as 'darker' than the other. My guess is that it might be related to YUV<>RGB conversions and/or missing VUI signaling. Also when comparing the files you posted and enforcing a specific color metric&co the colors look identical.
    I used Vapoursynth for example:
    Code:
    # Imports
    import vapoursynth as vs
    core = vs.get_core()
    # Loading Plugins
    core.std.LoadPlugin(path="G:/Hybrid/64bit/vsfilters/SourceFilter/LSmashSource/vslsmashsource.dll")
    clip12 = core.lsmas.LWLibavSource(source="C:/Users/Selur/Desktop/Touhou Anime1.2 2pass.mkv", format="YUV420P8", cache=0)
    clip12 = core.resize.Point(clip12, matrix_in_s="470bg")
    clip12 = core.std.SetFrameProp(clip=clip12, prop="_ColorRange", intval=1)
    clip12 = core.sub.Subtitle(clip=clip12, text="1.2");
    clip26 = core.lsmas.LWLibavSource(source="C:/Users/Selur/Desktop/Touhou Anime2.6 2pass.mkv", format="YUV420P8", cache=0)
    clip26 = core.resize.Point(clip26, matrix_in_s="470bg")
    clip26 = core.std.SetFrameProp(clip=clip26, prop="_ColorRange", intval=1)
    clip26 = core.sub.Subtitle(clip=clip12, text="2.6");
    clip1210 = core.lsmas.LWLibavSource(source="C:/Users/Selur/Desktop/TouhouAnime x265 1.2 10bit max CRF.mkv", format="YUV420P8", cache=0)
    clip1210 = core.resize.Point(clip1210, matrix_in_s="470bg")
    clip1210 = core.std.SetFrameProp(clip=clip1210, prop="_ColorRange", intval=1)
    clip1210 = core.sub.Subtitle(clip=clip1210, text="1.2 - 10bit");
    clip2010 = core.lsmas.LWLibavSource(source="C:/Users/Selur/Desktop/TouhouAnime x265 2.0 10bit max CRF.mkv", format="YUV420P8", cache=0)
    clip2010 = core.resize.Point(clip2010, matrix_in_s="470bg")
    clip2010 = core.std.SetFrameProp(clip=clip2010, prop="_ColorRange", intval=1)
    clip2010 = core.sub.Subtitle(clip=clip2010, text="2.0 - 10bit");
    clip1 = core.std.StackHorizontal([clip12,clip26])
    clip2 = core.std.StackHorizontal([clip1210,clip2010])
    clip = core.std.StackVertical([clip1, clip2])
    clip.set_output()
    but similar can easily be done using Avisynth.

    I've used identical parameters for all versions except ones that didn't exist until later. Since lookahead is featured in all the tested versions, they've all had the same default value of 40.
    In 1.2 the effective parameters included:
    Code:
    x265 [info]: Lookahead / bframes / badapt        : 0 / 8 / 2
    in 2.6 the effective parameter included:
    Code:
    x265 [info]: Lookahead / bframes / badapt        : 40 / 8 / 2
    -> lookahead isn't the same.

    That's why I'm puzzled. Despite all the new features, the quality is not increasing. Why?
    Without being able to reproduce it my guess is that the features aim to improve for example details which simply are not there.
    Thus they will slow down looking for details, but in the end find nothing to improve. Or you are simply missing the improvements,.. attached a few screenshots,... (from the script above)

    What's that?
    You might want to read up on those.
    http://x265.readthedocs.io/en/default/cli.html#vui-video-usability-information-options
    http://x265.readthedocs.io/en/default/cli.html#profile-level-tier
    VUI is important for correct color during decoding,...

    This particular 10-bit encode I attached seems to have been a CRF rather than 2pass encode so it's apples and oranges
    Since they are the same size not really, since 2pass and crf use the same rate control algorithms,.. -> you might want to gain some additional understanding about what crf is general and how it works.
    That a side you used 2.0 instead of 2.6 this time so the random screenshots I posted can't be compared that well.

    Tried that, it isn't any better quality and it's slow as **** on a 32-bit system.
    My condolences using a 32bit system nowadays for video encoding really is a pain. (slower encoding than necessary due to missing ASM optimizations)

    -> Since I can't offer enough details for others to reproduce your finding. I can't really help since it's more and more wild guessing.
    Wish you luck with hunting this down and may be someone else is willing to try to reproduce this.

    Cu Selur
    Image Attached Thumbnails Click image for larger version

Name:	comapre - 664.png
Views:	171
Size:	1.18 MB
ID:	44255  

    Click image for larger version

Name:	compare - 502.png
Views:	235
Size:	1.01 MB
ID:	44256  

    Click image for larger version

Name:	compare - 602.png
Views:	173
Size:	1.03 MB
ID:	44257  

    Click image for larger version

Name:	compare - 604.png
Views:	192
Size:	1.03 MB
ID:	44258  

    Click image for larger version

Name:	compare - 2100.png
Views:	216
Size:	1.26 MB
ID:	44259  

    Click image for larger version

Name:	compare - 2729.png
Views:	167
Size:	1.32 MB
ID:	44260  

    Click image for larger version

Name:	compare - 3197.png
Views:	352
Size:	1.05 MB
ID:	44261  

    Click image for larger version

Name:	compare - 3579.png
Views:	197
Size:	1.13 MB
ID:	44262  

    Click image for larger version

Name:	compare - 4014.png
Views:	214
Size:	1.15 MB
ID:	44263  

    Click image for larger version

Name:	compare - 4378.png
Views:	381
Size:	1.13 MB
ID:	44264  

    users currently on my ignore list: deadrats, Stears555
    Quote Quote  
  15. Hey, ignore the 1.2 10-bit encode I uploaded. It is visibly worse quality and I should've checked my journal before posting that. I uploaded the 2.0 10-bit encode because it was all I kept and I didn't feel like waiting 3 hours to produce a new 2.6 10-bit encode.
    But notice the 2.0 10-bit encode is not better quality than the 1.2 8-bit encode. That alone proves that 10-bit is not improving anything here.

    The movie Touhou Summer Day's Dream is fan-made so I believe you can legally download it. Once you get it, the Avisynth script is
    Code:
    ffvideosource("M:\Musou Kakyou - A Summer Day's Dream.mkv")
    trim(5000,9999)
    spline64resize(720,480)
    Originally Posted by Selur View Post
    switching between the screenshots one can easily see in the upper right corner that one clip is as 'darker' than the other.
    I see no such thing, perhaps you have a browser issue? My source is YV12 and the encode is also YV12. No conversion going on here.

    I don't know why the CMD log says 0 lookahead but it is not correct. I clearly used lookahead 40 in my encoding script. You can confirm this with MediaInfo. I tried changing it to 41 to see if the CMD log would change but it remained 0. Changed it to 30, still 0.
    But regardless of this, if 1.2 with no lookahead is doing slightly better than 2.6 with 40 lookahead, what does that tell you?
    It once again begs the question: why do the new x265 versions suck so bad?

    Okay... so VUI is basically things like custom aspect ratio, custom color matrix and all that? Why would I need to mess with this exactly? The video is YV12 just like its source. And why exactly would this affect the encoding quality? If I saw two videos, one of them awash with smearing and DCT artifacts, it wouldn't make a difference if it was tinted green or slightly darker. This would f*ck up the quality metrics but not much else.

    That a side you used 2.0 instead of 2.6 this time so the random screenshots I posted can't be compared that well.
    2.0 is way more recent than 1.2 so it should do better but it isn't.

    Wish you luck with hunting this down and may be someone else is willing to try to reproduce this.
    Download the source, it's a fan made short. But I've tested x265 on multiple sources, not just this one. The results are the same. The quality is NOT IMPROVING. So here's an honest challenge: do a test on a 480p video and show me the quality proof of new x265 versions. Then I'll be anxious to reproduce that.
    Quote Quote  
  16. Here's a 2.6 10-bit encode, for apples'n'apples.

    Code:
    M:\>avs4x26x --x26x-binary x265_26 "TouhouAnime.avs" -D 10 --pass 1 --bitrate 67 --tune ssim --ref 1
     --rd 2 --ctu 64 --no-rect --no-amp --early-skip --b-intra --no-tskip-fast --tu-intra-depth 3 --tu-i
    nter-depth 3 --tskip --max-merge 1 --me dia --subme 2 --merange 57 --weightp --weightb --rc-lookahea
    d 40 --b-adapt 2 --bframes 8 --cutree --sao --no-rskip --limit-modes --rd-refine --limit-refs 1 --mi
    n-cu-size 8 --rdoq-level 2 --lookahead-slices 1 --deblock=1:1 --no-fast-intra --psy-rdoq 0 -o "Touho
    u Anime2.6 10bit 2pass.hevc"
    avs [info]: AviSynth 2.60, build:Mar 31 2015 [16:38:54]
    avs [info]: Video colorspace: YV12
    avs [info]: Video resolution: 720x480
    avs [info]: Video framerate: 24000/1001
    avs [info]: Video framecount: 5000
    avs4x26x [info]: "x265_26" - -D 10 --pass 1 --bitrate 67 --tune ssim --ref 1 --rd 2 --ctu 64 --no-re
    ct --no-amp --early-skip --b-intra --no-tskip-fast --tu-intra-depth 3 --tu-inter-depth 3 --tskip --m
    ax-merge 1 --me dia --subme 2 --merange 57 --weightp --weightb --rc-lookahead 40 --b-adapt 2 --bfram
    es 8 --cutree --sao --no-rskip --limit-modes --rd-refine --limit-refs 1 --min-cu-size 8 --rdoq-level
     2 --lookahead-slices 1 --deblock=1:1 --no-fast-intra --psy-rdoq 0 -o "Touhou Anime2.6 10bit 2pass.h
    evc" --frames 5000 --fps 24000/1001 --input-res 720x480 --input-csp i420
    yuv  [info]: 720x480 fps 24000/1001 i420p8 unknown frame count
    raw  [info]: output file: Touhou Anime2.6 10bit 2pass.hevc
    x265 [info]: HEVC encoder version 2.6+2-32e6f04b8713
    x265 [info]: build info [Windows][GCC 7.2.0][32 bit][noasm] 10bit
    x265 [info]: using cpu capabilities: none!
    x265 [warning]: --tskip disabled, requires --rdlevel 3 or higher
    x265 [warning]: --rd-refine disabled, requires RD level > 4 and adaptive quant
    x265 [info]: Main 10 profile, Level-3 (Main tier)
    x265 [info]: Thread pool created using 8 threads
    x265 [info]: Slices                              : 1
    x265 [info]: frame threads / pool features       : 3 / wpp(8 rows)
    x265 [warning]: Source height < 720p; disabling lookahead-slices
    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         : dia / 57 / 2 / 1
    x265 [info]: Keyframe min / max / scenecut / bias: 23 / 250 / 40 / 5.00
    x265 [info]: Lookahead / bframes / badapt        : 40 / 8 / 2
    x265 [info]: b-pyramid / weightp / weightb       : 1 / 1 / 1
    x265 [info]: References / ref-limit  cu / depth  : 1 / off / on
    x265 [info]: AQ: mode / str / qg-size / cu-tree  : 2 / 1.0 / 32 / 1
    x265 [info]: Rate Control / qCompress            : ABR-67 kbps / 0.60
    x265 [info]: tools: limit-modes rd=2 rdoq=2 early-skip signhide tmvp b-intra
    x265 [info]: tools: strong-intra-smoothing deblock(tC=1:B=1) sao stats-write
    x265 [info]: frame I:     35, Avg QP:29.08  kb/s: 2064.28
    x265 [info]: frame P:    954, Avg QP:35.07  kb/s: 187.16
    x265 [info]: frame B:   4011, Avg QP:40.07  kb/s: 21.99
    x265 [info]: Weighted P-Frames: Y:4.6% UV:4.3%
    x265 [info]: Weighted B-Frames: Y:2.6% UV:2.5%
    x265 [info]: consecutive B-frames: 7.0% 4.8% 4.1% 27.8% 12.3% 22.2% 9.0% 7.4% 5.4%
    
    encoded 5000 frames in 453.95s (11.01 fps), 67.80 kb/s, Avg QP:39.04
    
    M:\>
    M:\>avs4x26x --x26x-binary x265_26 "TouhouAnime.avs" -D 10 --pass 2 --bitrate 67 --tune ssim --ref 5
     --rd 6 --ctu 64 --rect --amp --no-early-skip --b-intra --no-tskip-fast --tu-intra-depth 3 --tu-inte
    r-depth 3 --tskip --max-merge 4 --me star --subme 4 --merange 57 --weightp --weightb --rc-lookahead
    40 --b-adapt 2 --bframes 8 --cutree --sao --no-rskip --limit-modes --rd-refine --limit-refs 1 --min-
    cu-size 8 --rdoq-level 2 --lookahead-slices 1 --deblock=1:1 --no-fast-intra --psy-rdoq 0 -o "Touhou
    Anime2.6 10bit 2pass.hevc"
    avs [info]: AviSynth 2.60, build:Mar 31 2015 [16:38:54]
    avs [info]: Video colorspace: YV12
    avs [info]: Video resolution: 720x480
    avs [info]: Video framerate: 24000/1001
    avs [info]: Video framecount: 5000
    avs4x26x [info]: "x265_26" - -D 10 --pass 2 --bitrate 67 --tune ssim --ref 5 --rd 6 --ctu 64 --rect
    --amp --no-early-skip --b-intra --no-tskip-fast --tu-intra-depth 3 --tu-inter-depth 3 --tskip --max-
    merge 4 --me star --subme 4 --merange 57 --weightp --weightb --rc-lookahead 40 --b-adapt 2 --bframes
     8 --cutree --sao --no-rskip --limit-modes --rd-refine --limit-refs 1 --min-cu-size 8 --rdoq-level 2
     --lookahead-slices 1 --deblock=1:1 --no-fast-intra --psy-rdoq 0 -o "Touhou Anime2.6 10bit 2pass10bi
    t.hevc" --frames 5000 --fps 24000/1001 --input-res 720x480 --input-csp i420
    yuv  [info]: 720x480 fps 24000/1001 i420p8 unknown frame count
    raw  [info]: output file: Touhou Anime2.6 10bit 2pass.hevc
    x265 [info]: HEVC encoder version 2.6+2-32e6f04b8713
    x265 [info]: build info [Windows][GCC 7.2.0][32 bit][noasm] 10bit
    x265 [info]: using cpu capabilities: none!
    x265 [info]: Main 10 profile, Level-3 (Main tier)
    x265 [info]: Thread pool created using 8 threads
    x265 [info]: Slices                              : 1
    x265 [info]: frame threads / pool features       : 3 / wpp(8 rows)
    x265 [warning]: Source height < 720p; disabling lookahead-slices
    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: 23 / 250 / 40 / 5.00
    x265 [info]: Lookahead / bframes / badapt        : 40 / 8 / 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  : 2 / 1.0 / 32 / 1
    x265 [info]: Rate Control / qCompress            : ABR-67 kbps / 0.60
    x265 [info]: tools: rect amp limit-modes rd=6 rdoq=2 rd-refine tskip signhide
    x265 [info]: tools: tmvp b-intra strong-intra-smoothing deblock(tC=1:B=1) sao
    x265 [info]: tools: stats-read
    x265 [info]: frame I:     35, Avg QP:27.12  kb/s: 2451.31
    x265 [info]: frame P:    954, Avg QP:35.38  kb/s: 177.87
    x265 [info]: frame B:   4011, Avg QP:39.59  kb/s: 19.29
    x265 [info]: Weighted P-Frames: Y:0.8% UV:0.3%
    x265 [info]: Weighted B-Frames: Y:0.7% UV:0.4%
    x265 [info]: consecutive B-frames: 7.0% 4.8% 4.1% 27.8% 12.3% 22.2% 9.0% 7.4% 5.4%
    
    encoded 5000 frames in 5176.15s (0.97 fps), 66.57 kb/s, Avg QP:38.70
    Image Attached Files
    Quote Quote  
  17. And here are the source frames for all the screenshots you posted.
    Image Attached Thumbnails Click image for larger version

Name:	Touhou source 502.png
Views:	152
Size:	365.3 KB
ID:	44277  

    Click image for larger version

Name:	Touhou source 602.png
Views:	244
Size:	378.7 KB
ID:	44278  

    Click image for larger version

Name:	Touhou source 604.png
Views:	146
Size:	376.4 KB
ID:	44279  

    Click image for larger version

Name:	Touhou source 664.png
Views:	156
Size:	432.6 KB
ID:	44280  

    Click image for larger version

Name:	Touhou source 2100.png
Views:	180
Size:	456.3 KB
ID:	44281  

    Click image for larger version

Name:	Touhou source 2729.png
Views:	147
Size:	462.5 KB
ID:	44282  

    Click image for larger version

Name:	Touhou source 3197.png
Views:	182
Size:	363.2 KB
ID:	44283  

    Click image for larger version

Name:	Touhou source 3579.png
Views:	162
Size:	416.8 KB
ID:	44284  

    Click image for larger version

Name:	Touhou source 4014.png
Views:	133
Size:	417.6 KB
ID:	44285  

    Click image for larger version

Name:	Touhou source 4378.png
Views:	130
Size:	421.6 KB
ID:	44286  

    Quote Quote  
  18. I just wanted to write that I have experimented a bit with .h265 encoding via VidCoder and I think it is a good format. I find it takes twice as long as what the video is to encode but you get reduced file size and a nice looking and sounding video. I am sticking with .h264 for the most part but I want to say thank you to the developers. It is nice to have options and .h265 shows a lot of promise.
    Quote Quote  
  19. Selur?
    I can't really help since it's more and more wild guessing.
    after that I stopped reading,..

    @Moderators: Would be nice if this whole discussion could be moved into another thread since it's spamming this thread quite a bit,..
    users currently on my ignore list: deadrats, Stears555
    Quote Quote  
  20. Originally Posted by Selur View Post
    Selur?
    I can't really help since it's more and more wild guessing.
    after that I stopped reading,..

    @Moderators: Would be nice if this whole discussion could be moved into another thread since it's spamming this thread quite a bit,..
    Well I was hoping you would grab the source and try some tests. It never occurred to me until now that I could just split the part in direct stream copy and post it to avoid pasting 800MB. Here it is: https://www.sendspace.com/file/dcp19b
    Do
    Code:
    spline64resize(720,480)
    trim(8,5007)
    in avisynth to get the exact same source as mine.

    Please also use the same encoding settings.

    And how is this spam? The topic is the x265 encoder, what are we discussing?
    Last edited by Aludin; 7th Jan 2018 at 00:25.
    Quote Quote  
  21. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    It means that this thread is mainly for announcing a new version and explaining changes between versions.

    But questions how to use the encoder in specific cases usually develops into a longer discussion, which could make people miss brief announcements in between posts with long code blocks and image lists. Such questions deserve a separate thread.
    Quote Quote  
  22. Originally Posted by LigH.de View Post
    It means that this thread is mainly for announcing a new version and explaining changes between versions.

    But questions how to use the encoder in specific cases usually develops into a longer discussion, which could make people miss brief announcements in between posts with long code blocks and image lists. Such questions deserve a separate thread.
    Isn't there already a thread for that? https://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds
    Quote Quote  
  23. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    That's for binaries built with MSYS / MinGW / GCC. There could also be binaries built with other compilers and environments.

    IMHO, one more thread is less anoying than a huge growing and derailing one.
    Quote Quote  
  24. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM


    307 patches with AVX-512 (and other improved assembly) code uploaded to the developer mailing list. That will take a little while to review.
    Quote Quote  
  25. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    The AVX-512 patches are committed.

    Unfortunately, they don't compile for the x86 (Win32) target architecture (assembler optimized code was still enabled for 8-bit depth core). A "bailout" to skip AVX-512 assembler code completely in 32-bit mode may be required.
    Quote Quote  
  26. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    From the doom9 forum:

    Originally Posted by Ashok Kumar Mishra
    Version 2.8
    ===========

    Release date - 21/05/2018

    New features
    -------------
    1. :option:`--asm avx512` used to enable AVX-512 in x265. Default disabled.
    For 4K main10 high-quality encoding, we are seeing good gains; for other resolutions and presets, we don't recommend using this setting for now.

    2. :option:`--dynamic-refine` dynamically switches between different inter refine levels. Default disabled.
    It is recommended to use :option:`--refine-intra 4' with dynamic refinement for a better trade-off between encode efficiency and performance than using static refinement.

    3. :option:`--single-sei`
    Encode SEI messages in a single NAL unit instead of multiple NAL units. Default disabled.

    4. :option:`--max-ausize-factor` controls the maximum AU size defined in HEVC specification.
    It represents the percentage of maximum AU size used. Default is 1.

    5. VMAF (Video Multi-Method Assessment Fusion)
    Added VMAF support for objective quality measurement of a video sequence.
    Enable cmake option ENABLE_LIBVMAF to report per frame and aggregate VMAF score. The frame level VMAF score does not include temporal scores.
    This is supported only on linux for now.

    Encoder enhancements
    --------------------
    1. Introduced refine-intra level 4 to improve quality.
    2. Support for HLG-graded content and pic_struct in SEI message.

    Bug Fixes
    ---------
    1. Fix 32 bit build error (using CMAKE GUI) in Linux.
    2. Fix 32 bit build error for asm primitives.
    3. Fix build error on mac OS.
    4. Fix VBV Lookahead in analysis load to achieve target bitrate.
    Quote Quote  
  27. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    Belated from releasenotes.rst:

    Code:
    Version 2.9
    ===========
    
    Release date - 05/10/2018
    
    New features
    -------------
    1. Support for chunked encoding
    
       :option:`--chunk-start and --chunk-end` 
       Frames preceding first frame of chunk in display order will be encoded, however, they will be discarded in the bitstream.
       Frames following last frame of the chunk in display order will be used in taking lookahead decisions, but, they will not be encoded. 
       This feature can be enabled only in closed GOP structures. Default disabled.
    
    2. Support for HDR10+ version 1 SEI messages.
    
    Encoder enhancements
    --------------------
    1. Create API function for allocating and freeing x265_analysis_data.
    2. CEA 608/708 support: Read SEI messages from text file and encode it using userSEI message.
    
    Bug fixes
    ---------
    1. Disable noise reduction when vbv is enabled.
    2. Support minLuma and maxLuma values changed by the commandline.
    Quote Quote  
  28. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    x265 2.9+14-3023bd8b05c0 (MSYS2, MinGW32 + GCC 7.4.0 / MinGW64 + GCC 8.2.1)

    support for Dolby Vision profile 5 and RPU multiplexing; Cutree offset for analysis reuse
    Image Attached Files
    Quote Quote  
  29. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    Excuse me, fellow developers, but to a half-wit like me, this graph looks like there might be parallel development for a while now: One branch with mainly code and one with mainly version tags.

    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!