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, 03:19   #8161  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by Stacey Spears View Post
Isn't --abr-ladder more for layered encodes in the streaming scenario?
I thought you were encoding multiple variants of the same source. If not applicable, than it is not applicable .

Quote:
3 of 12 are done so far. I currently have the next three running their initial two pass to figure out what to use for the qp file. This is for a single project, so not the end of the world. If I were a streaming service, this would not be practical. The real solution is for someone to debug the issue and figure out why the rate control is opting for low P and B QPs with high I QPs. Perhaps I should see if I can get MSU to use the content for future CODEC shootouts.
Good stress test content is always a delight. My new favorite stress test clip is Netflix's Sol Volante. http://download.opencontent.netflix....Levante/hdr10/

Quote:
BTW, off topic, is it true that Blue Star has closed many locations in Portland? So sad if true!
I see four still open, but I don't recall how many there used to be. I've barely been to restaurants the last 14 months. But my fiancé is getting her second shot on Friday, so hopefully venturing into the world more soon.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 13th May 2021, 09:25   #8162  |  Link
Marsu42
Huba Huba
 
Marsu42's Avatar
 
Join Date: Aug 2005
Location: Palumbian Jungle
Posts: 78
Quote:
Originally Posted by quietvoid View Post
Since then I've just given up on hist-scenecut.
Quote:
Originally Posted by Boulder View Post
Too bad they don't seem to care for the original method anymore
Quote:
Originally Posted by foxyshadis View Post
Since Steve Borho and chen moved on, the main quality check is "does it compile". Almost every submitted patch is immediately committed without discussion now, and reverted later if need be.
Quote:
Originally Posted by Boulder View Post
Unfortunately at least --hist-scenecut is not good at all. They just left it half finished.
So the expert consensus is that --hist-scenecut is broken atm, and users should simply use the traditional method - correct?

If so, it's unfortunate this isn't marked as "Experimental feature" in the command line options :-\ https://x265.readthedocs.io/en/master/cli.html
__________________
"The innocent have nothing to fear" :stupid:

Last edited by Marsu42; 13th May 2021 at 09:33.
Marsu42 is offline   Reply With Quote
Old 13th May 2021, 16:53   #8163  |  Link
ShortKatz
Registered User
 
Join Date: Aug 2018
Location: Germany
Posts: 118
Did x265 development kind of stoped? It is not much going on currently.
ShortKatz is offline   Reply With Quote
Old 13th May 2021, 18:35   #8164  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by Marsu42 View Post
So the expert consensus is that --hist-scenecut is broken atm, and users should simply use the traditional method - correct?

If so, it's unfortunate this isn't marked as "Experimental feature" in the command line options :-\ https://x265.readthedocs.io/en/master/cli.html
I haven't seen much feedback about it 3.5, where it was improved. From the release notes:
Quote:
+1. Improved hist-based scene cut algorithm: Reduces false positives by leveraging motion and scene transition info.
Anyone retried --hist-scencut again in 3.5?
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 13th May 2021, 18:43   #8165  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
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   #8166  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
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   #8167  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
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   #8168  |  Link
nakTT
Registered User
 
Join Date: Dec 2008
Posts: 415
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   #8169  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
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   #8170  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
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   #8171  |  Link
DJATOM
Registered User
 
DJATOM's Avatar
 
Join Date: Sep 2010
Location: Ukraine, Bohuslav
Posts: 377
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 5950X, 64 GB RAM, RTX 2070
DJATOM is offline   Reply With Quote
Old 4th June 2021, 00:32   #8172  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
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   #8173  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
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   #8174  |  Link
LeXXuz
21 years and counting...
 
LeXXuz's Avatar
 
Join Date: Oct 2002
Location: Germany
Posts: 716
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   #8175  |  Link
masterkivat
変身!
 
masterkivat's Avatar
 
Join Date: Dec 2008
Location: Brazil
Posts: 38
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   #8176  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
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   #8177  |  Link
charliebaby
Registered User
 
charliebaby's Avatar
 
Join Date: Jun 2020
Posts: 37
3.5+10-82786fc GCC 11.1

https://www.mediafire.com/file/gsyvu...1-AVX2.7z/file
__________________
charliebaby is offline   Reply With Quote
Old 7th June 2021, 19:57   #8178  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
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   #8179  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
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   #8180  |  Link
fauxreaper
Registered User
 
Join Date: Oct 2014
Posts: 23
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
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 15:16.


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