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 13th May 2021, 18:43   #8181  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 5,074
Yes, we have tested it and it's worse than before. Mind you, it didn't work properly even before v3.5..

It is very much a reality that they don't seem to have many hardcore devs left. Of course, the encoder is very stable and works well, but there are these reported cases which are never investigated.
__________________
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 14th May 2021, 01:09   #8182  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,720
Quote:
Originally Posted by Boulder View Post
Yes, we have tested it and it's worse than before. Mind you, it didn't work properly even before v3.5.
Worse results, but works more reliably?

Quote:
It is very much a reality that they don't seem to have many hardcore devs left. Of course, the encoder is very stable and works well, but there are these reported cases which are never investigated.
I am aware that some work is going on with x265, but yeah, pretty much nothing in the public repository.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 14th May 2021, 09:45   #8183  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 5,074
Quote:
Originally Posted by benwaggoner View Post
Worse results, but works more reliably?
Unfortunately just worse results. It's very flaky and detects scene changes in motion too easily (transition from a slightly motion blurred frame to a crisper one triggers it). The threshold seems to affect it in the wrong way.

https://forum.doom9.org/showthread.p...98#post1919698

What comes to development, I think most of the recent (since ~year or so) stuff has been towards streaming and (very) low bitrate encodes. For regular encodes, much less so. So there's probably someone paying for those things and that's why they get done.
__________________
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 1st June 2021, 20:28   #8184  |  Link
nakTT
Registered User
 
Join Date: Dec 2008
Posts: 407
After many month of no update, now they have made a new commit.

https://bitbucket.org/multicoreware/x265_git/commits/
nakTT is offline   Reply With Quote
Old 3rd June 2021, 21:07   #8185  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,720
Quote:
Originally Posted by nakTT View Post
After many month of no update, now they have made a new commit.

https://bitbucket.org/multicoreware/x265_git/commits/
Documentation only, though, and a somewhat confusing one.

Quote:
If the encoder is unable to reach the level it issues a warning and aborts the encode. The requested level will be signaled in the bitstream even if it is higher than the actual level.
If it is aborted, how is it signaled? If the parameters are wrong, the first frame wouldn't have been even written.

Or is it saying that if a stream is started but has a VBV violation during the encode, it'll abort, but the stream that had been written up to that point would still have the originally specified level?

If so, that would be the expected and appropriate behavior, since the frame that violated the spec never was written and so the file up to that point should still be conformant.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 3rd June 2021, 22:13   #8186  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,149
OUCH! It does appear that, since Steve Borho and Min Chen left the x265 project, the remaining devs DON'T KNOW very-well what they're doing :-/

So... to all the regular/frequent users of x265, ┐could you please say which old version of x265 you recommend?

Last edited by filler56789; 3rd June 2021 at 22:17. Reason: .
filler56789 is offline   Reply With Quote
Old 3rd June 2021, 23:34   #8187  |  Link
DJATOM
Registered User
 
DJATOM's Avatar
 
Join Date: Sep 2010
Location: Ukraine, Bohuslav
Posts: 314
Definitely before ABR ladder introduced. It added complexity to codebase and it was a source of bugs for certain amount of time (maybe some bugs still not discovered). So I recommend to use 3.3 if you want less buggy encoder.
__________________
Me on GitHub
PC Specs: Ryzen 3900X, 64 GB RAM, RTX 2070
DJATOM is offline   Reply With Quote
Old 4th June 2021, 00:32   #8188  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,720
Quote:
Originally Posted by DJATOM View Post
Definitely before ABR ladder introduced. It added complexity to codebase and it was a source of bugs for certain amount of time (maybe some bugs still not discovered). So I recommend to use 3.3 if you want less buggy encoder.
Yeah. While there are promising improvements in 3.4 & 3.5, none that I've really seen tested out enough to judge, and how much of the VBV fixes were for things that got broken post 3.3.

https://x265.readthedocs.io/en/master/releasenotes.html
  1. No one claims even no regressions with the improved 3.5 --hist-scenecut
  2. I've not seen test results for --rskip 2, although it is conceptually sound, and seems likely to help motion graphics and cell animation.
  3. Have heard nothing about using RADL for variable duration GOPs yet. I've not grokked the theory for why it would be better.
  4. Nor any results from the now bidirectional --scenecut-aware-qp, or its tuning with --scenecut-window and --max-qp delta. Using it seems to give me a syntax error some of the time (which is weird). All are conceptually sound, though.
  5. --frame-dup seems to work fine, but those are frames that were small and early-exited already, and I've not noticed significant net improvements yet. The new Sol Levante source for my Encoding Challenge should be great to test it due to all the static credits and titles.

Anyone have anything to share on those?
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 4th June 2021, 18:18   #8189  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,149
Quote:
Originally Posted by DJATOM View Post
Definitely before ABR ladder introduced. It added complexity to codebase and it was a source of bugs for certain amount of time (maybe some bugs still not discovered). So I recommend to use 3.3 if you want less buggy encoder.
Thanks.
filler56789 is offline   Reply With Quote
Old 5th June 2021, 07:19   #8190  |  Link
LeXXuz
18 years and counting...
 
LeXXuz's Avatar
 
Join Date: Oct 2002
Location: Germany
Posts: 321
Quote:
Originally Posted by DJATOM View Post
Definitely before ABR ladder introduced. It added complexity to codebase and it was a source of bugs for certain amount of time (maybe some bugs still not discovered). So I recommend to use 3.3 if you want less buggy encoder.
Would you mind compiling an 8-bit & 10-bit version of 3.3 with optimizations for Zen2 and Zen3?

I'd like to have an optimized and stable version for every day use.
LeXXuz is offline   Reply With Quote
Old 5th June 2021, 22:25   #8191  |  Link
masterkivat
変身!
 
masterkivat's Avatar
 
Join Date: Dec 2008
Location: Brazil
Posts: 31
Quote:
Originally Posted by LeXXuz View Post
Would you mind compiling an 8-bit & 10-bit version of 3.3 with optimizations for Zen2 and Zen3?

I'd like to have an optimized and stable version for every day use.
...I second that!
masterkivat is offline   Reply With Quote
Old 6th June 2021, 10:50   #8192  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 5,074
Quote:
Originally Posted by benwaggoner View Post
Yeah. While there are promising improvements in 3.4 & 3.5, none that I've really seen tested out enough to judge, and how much of the VBV fixes were for things that got broken post 3.3.

https://x265.readthedocs.io/en/master/releasenotes.html
  1. No one claims even no regressions with the improved 3.5 --hist-scenecut
  2. I've not seen test results for --rskip 2, although it is conceptually sound, and seems likely to help motion graphics and cell animation.
  3. Have heard nothing about using RADL for variable duration GOPs yet. I've not grokked the theory for why it would be better.
  4. Nor any results from the now bidirectional --scenecut-aware-qp, or its tuning with --scenecut-window and --max-qp delta. Using it seems to give me a syntax error some of the time (which is weird). All are conceptually sound, though.
  5. --frame-dup seems to work fine, but those are frames that were small and early-exited already, and I've not noticed significant net improvements yet. The new Sol Levante source for my Encoding Challenge should be great to test it due to all the static credits and titles.

Anyone have anything to share on those?
My views on some of those:

--hist-scenecut has been proven to not work properly, it cannot be used in any productive encodes. It went worse with the bugfixes they made and then they left it as it is.

--rskip 2 seemed to help with some onion artifacts I was seeing in flat backgrounds with some noise in my Star Trek TNG 720p encodes. I didn't find any problems with it, and shouldn't more computation and analysis be better than skipping anyway? I use --rskip 2 --rskip-edge-threshold 3 as a base setting in my encoding commandline.

Just note that --rskip 2 --limit-tu 0 --ctu 64 is asking for trouble. That combination is broken, but my bug report has not been processed at all.

Scenecut-aware-qp is a bit silly implementation because it only works in 2-pass encodes. I did some tests on a modded version that allows using it in CRF mode but didn't find it useful.
__________________
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 7th June 2021, 17:50   #8193  |  Link
charliebaby
Registered User
 
charliebaby's Avatar
 
Join Date: Jun 2020
Posts: 26
3.5+10-82786fc GCC 11.1

https://www.mediafire.com/file/gsyvu...1-AVX2.7z/file
__________________
I love x265
charliebaby is offline   Reply With Quote
Old 7th June 2021, 19:57   #8194  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,720
Quote:
Originally Posted by charliebaby View Post
Why is your build labeled "AVX2?" Does it exclude AVX-512 or something?
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 7th June 2021, 20:23   #8195  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,720
I'm starting tests for the new anime version of my Encoder Challenge.

Despite content that seems ripe for --frame-dup helping static frames of credits, it doesn't seem to be working. Looking at the docs for --dup-threshold, it's unclear what the scale is, or if higher values make it more or less strict. Anyone have any insights?
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 7th June 2021, 21:04   #8196  |  Link
fauxreaper
Registered User
 
Join Date: Oct 2014
Posts: 22
Quote:
Originally Posted by benwaggoner View Post
I'm starting tests for the new anime version of my Encoder Challenge.

Despite content that seems ripe for --frame-dup helping static frames of credits, it doesn't seem to be working. Looking at the docs for --dup-threshold, it's unclear what the scale is, or if higher values make it more or less strict. Anyone have any insights?
Scale is PSNR between two frames. Higher values make it more strict. Default is PSNR 70.
fauxreaper is offline   Reply With Quote
Old 8th June 2021, 18:41   #8197  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,720
Quote:
Originally Posted by fauxreaper View Post
Scale is PSNR between two frames. Higher values make it more strict. Default is PSNR 70.
Awesome, thank you. I'm trying another pass of my encode with --dup-threshold of 50.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 8th June 2021, 21:15   #8198  |  Link
Gravitator
Registered User
 
Join Date: May 2014
Posts: 204
v3.5+10 - defective image output (v3.0+1 is okay).
Quote:
ffmpeg -i z:\space_6s.mkv -f yuv4mpegpipe - | x265 --y4m - --preset medium --bitrate 1000 --max-merge 1 z:\test.mkv
__________________
Win10x64, Xeon E5450, GTX 750 2GB, DDR3 8GB.
Gravitator is offline   Reply With Quote
Old 8th June 2021, 22:42   #8199  |  Link
Ma
Registered User
 
Join Date: Feb 2015
Posts: 326
Quote:
Originally Posted by Gravitator View Post
v3.5+10 - defective image output (v3.0+1 is okay).
It is caused by
https://bitbucket.org/multicoreware/...2adf4ed7299d82

To go back to old behavior please add
Code:
--no-early-skip --no-b-intra --limit-refs 3
options to new version of x265.
Ma is offline   Reply With Quote
Old 9th June 2021, 19:39   #8200  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,720
I've yet to get --frame-dup to actually do anything, even with --dup-threshold at 20. And with source where there are lots of identical consecutive frames.

x265.exe --input SolLevante_SDRv2_1080p24_8bit.y4m --level-idc 4.0 --preset slower --tune animation --frame-dup --dup-threshold 20 --pools "-,+" --pass 1 --keyint 120 --bitrate 1000 --vbv-maxrate 12000 --vbv-bufsize 12000 --hrd --aud --colorprim bt709 --transfer bt709 --colormatrix bt709 -o SolLevante_SDR-1080p_1000_slower-dup20_p1.hevc --psnr --ssim --csv-log-level 1 --stats SolLevante_SDR-1080p_1000_slower-dup20.stats --csv SolLevante_SDR-1080p_1000_slower-dup20_p1.csv

Every frame is at least 600 bytes. They're mostly Merge or Skip, but with very low percentages of Intra and Inter blocks of various sizes in the b-frames.

Same in first and second passes.

Anyone have any insights/suggestions?

I'm trying a single-pass test.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner 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 21:37.


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