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 14th May 2020, 02:45   #7621  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,259
Quote:
Originally Posted by stax76 View Post
Thanks, so --chunk-start and --chunk-end, would be helpful if somebody can share experience with it. How many extra frames are needed? I'll use vspipe and avs2pipemod for trimming, modifying the avs/vpy file has too many implications.
I'd want to use at least as many frames as the greater of keyint and fps*vbv-maxrate/vbv-bufsize. That'll let rate control and IDR placement converge pretty close on what they would be in a full pass encode. If using larger gaps and being kinda paranoid, I'd probably use double the above.

The compute overhead is proportional to chunk duration, so is much less of an issue with 10 minute chunks than 30 second chunks.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 14th May 2020, 09:38   #7622  |  Link
crystalfunky
Registered User
 
Join Date: Apr 2010
Posts: 56
I noticed something about the crf value. One step to the next number is around 4000-5000 kbits bitrate.
So for example I have a clip with 27 Mbit/s and I want to lower the bitrate, I need to lower the crf one step. If I want to get the bitrate around 17 Mbit/s, I need to do 2 steps.
Can somebody confirm that?
crystalfunky is offline   Reply With Quote
Old 14th May 2020, 11:27   #7623  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,858
Quote:
Originally Posted by crystalfunky View Post
I noticed something about the crf value. One step to the next number is around 4000-5000 kbits bitrate.
So for example I have a clip with 27 Mbit/s and I want to lower the bitrate, I need to lower the crf one step. If I want to get the bitrate around 17 Mbit/s, I need to do 2 steps.
Can somebody confirm that?
No, that's not how it works. I'm afraid there is no mathematical way to calculate the "correct" value for CRF. It depends on the source and also the encoder parameters.
__________________
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 2020, 22:59   #7624  |  Link
RanmaCanada
Registered User
 
Join Date: May 2009
Posts: 150
Quote:
Originally Posted by crystalfunky View Post
I noticed something about the crf value. One step to the next number is around 4000-5000 kbits bitrate.
So for example I have a clip with 27 Mbit/s and I want to lower the bitrate, I need to lower the crf one step. If I want to get the bitrate around 17 Mbit/s, I need to do 2 steps.
Can somebody confirm that?
If you want to lower the bitrate, then lower the bitrate with a 2 pass. CRF has nothing to do with bitrate.
RanmaCanada is offline   Reply With Quote
Old 14th May 2020, 23:19   #7625  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,696
Well, that's not accurate. If you're generally ok with the quality + bitrate from a given crf with a given preset, and one particular piece of content ends up too big, you can always just increase CRF.

Capped CRF is reasonable too.
Blue_MiSfit is offline   Reply With Quote
Old 16th May 2020, 14:10   #7626  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,135
Quote:
Originally Posted by LigH View Post
x265 3.3+27-g4780a8d99 (multilib, GCC 10.1)
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.


LoRd_MuldeR is offline   Reply With Quote
Old 16th May 2020, 15:02   #7627  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,043
x265.exe 3.3+31-d5695e2

http://msystem.waw.pl/x265/
filler56789 is offline   Reply With Quote
Old 18th May 2020, 18:02   #7628  |  Link
stax76
Registered Lurker
 
Join Date: Jun 2002
Posts: 6,430
Sorry to post here again, I've added this chunk encoding feature to staxrip, available in the last beta. It turned out everything needed was already in place so it could be finished in four hours.

Documented here:

https://staxrip.readthedocs.io/usage...lel-processing

RipBot264 and Media Coder support it too.
stax76 is offline   Reply With Quote
Old 19th May 2020, 00:28   #7629  |  Link
RanmaCanada
Registered User
 
Join Date: May 2009
Posts: 150
Quote:
Originally Posted by stax76 View Post
Sorry to post here again, I've added this chunk encoding feature to staxrip, available in the last beta. It turned out everything needed was already in place so it could be finished in four hours.

Documented here:

https://staxrip.readthedocs.io/usage...lel-processing

RipBot264 and Media Coder support it too.
This is fantastic. I haven't used this feature since mediacoder.

thank you.
RanmaCanada is offline   Reply With Quote
Old 20th May 2020, 16:57   #7630  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,043
x265.exe 3.3+32-516a579

Code:
Store histogram of Y, U, V and Y's edge in analysis file.

Enables the library to compute Y Histogram and store
Histogram of Y, U, V Channel and Y's Edge in analysis
file at all reuse levels when --hist-scenecut is enabled.
http://msystem.waw.pl/x265/
filler56789 is offline   Reply With Quote
Old 21st May 2020, 19:37   #7631  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 349
x265 v3.3+31-g431a22e82 (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 10.1.0)
Code:
https://bitbucket.org/multicoreware/x265_git/commits/branch/master

Last edited by Barough; 22nd May 2020 at 15:35.
Barough is offline   Reply With Quote
Old 21st May 2020, 22:20   #7632  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,259
Quote:
Originally Posted by Boulder View Post
No, that's not how it works. I'm afraid there is no mathematical way to calculate the "correct" value for CRF. It depends on the source and also the encoder parameters.
As a heuristic, file size doubles with about 5-6 lowerCRF, and halves with about the same in the other direction. Content dependent, of course.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 26th May 2020, 07:06   #7633  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,858
Perhaps a silly question, but something I've wondered ever since MakeMKV was able to add Dolby Vision to Matroska files. If at some point mkvmerge can handle the DV layer in a similar way, would it be possible to re-encode the actual video to a lower bitrate and combine the two (provided that mkvmerge supports such action)? Rescaling would definitely be out of question, but some light denoising should not do much, since it's the same with HDR.
The reason I'm asking this is that I have a small 2.5" HDD next to my TV, which I've been using to playback DV on the TV player since Kodi doesn't support DV. The HDD is only 500GB in size so re-encoding could effectively double the amount of movies I could store there.
__________________
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 26th May 2020, 12:27   #7634  |  Link
quietvoid
Registered User
 
Join Date: Jan 2019
Posts: 70
The specs do mention the 1080p enhancement layer always comes with a 2160p base layer.
It is also something I have been wondering, you could easily test it by using yusesope's tool and merging the metadata into a reencoded HEVC file.
quietvoid is offline   Reply With Quote
Old 26th May 2020, 17:38   #7635  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,259
Quote:
Originally Posted by quietvoid View Post
The specs do mention the 1080p enhancement layer always comes with a 2160p base layer.
It is also something I have been wondering, you could easily test it by using yusesope's tool and merging the metadata into a reencoded HEVC file.
Yes, the enhancement layer doesn't need to be full rez as it's really spatial metadata. The enhancement layer is unwatchable by itself.

That said, almost all new DoVi content for several years uses a non-backwards compatible (NBC) base layer without an enhancement layer. This provides more efficient encoding and lower complexity decode/tone mapping. x265 can encode the NBC base layer just fine, although I'd use --preset slower at a minimum, and the DoVi-specific encoding tweaks.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 28th May 2020, 20:29   #7636  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,696
3.4 has been tagged for release!

https://bitbucket.org/multicoreware/...ch/Release_3.4

Release notes - v3.4
-----------------------------

New features
------------------
• Edge-aware quadtree partitioning to terminate CU depth recursion based on edge information. --rskip 2 enables the feature and --rskip-edge-threshold <0..100> denotes the minimum expected edge-density percentage within the CU, below which the recursion is skipped. Experimental feature.
• Application-level feature --abr-ladder for automating ABR ladder generation. Shows ~65% savings in the over-all turn-around time required for the generation of a typical HLS ladder in Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz over a sequential ABR-ladder generation approach that leverages save-load architecture.
Enhancements to existing features
----------------------------------------------
• Improved 2-pass rate-control algorithm. The savings in the bitrate is ~1.72% with visual improvement in quality in the initial 1-2 secs.
Encoder enhancements
--------------------------------
• Faster ARM64 encodes enabled by ASM contributions from Huawei. The speed-up over no-asm version for 1080p encodes @ medium preset is ~15% in a 16 core H/W.
• Strict VBV conformance in zone encoding.
Bug fixes
------------
• Multi-pass encode failures with --frame-dup.
• Corrupted bitstreams with --hist-scenecut when input depth and internal bit-depth differ.
• Incorrect analysis propagation in multi-level save-load architecture.
• Failure in detecting NUMA packages installed in non-standard directories.
Blue_MiSfit is offline   Reply With Quote
Old 31st May 2020, 09:17   #7637  |  Link
Patman
Registered User
 
Patman's Avatar
 
Join Date: Jan 2015
Posts: 264
I've updated my x265 builds. x265-3.4+1 is built from the stable branch (stable release) and x265-3.4+6 is built from the master branch. Both builds are 64-bit multilib windows binaries.

Last edited by Patman; 31st May 2020 at 12:25.
Patman is offline   Reply With Quote
Old 31st May 2020, 14:53   #7638  |  Link
alexantr
Registered User
 
alexantr's Avatar
 
Join Date: Nov 2019
Location: Belarus
Posts: 5
Who try --rskip 2? Did you catch rare glitches like that
Attached Images
  
alexantr is offline   Reply With Quote
Old 31st May 2020, 23:22   #7639  |  Link
Sagittaire
Testeur de codecs
 
Sagittaire's Avatar
 
Join Date: May 2003
Location: France
Posts: 2,488
Quote:
Originally Posted by Blue_MiSfit View Post
3.4 has been tagged for release!

https://bitbucket.org/multicoreware/...ch/Release_3.4

Release notes - v3.4
-----------------------------

New features
------------------
• Edge-aware quadtree partitioning to terminate CU depth recursion based on edge information. --rskip 2 enables the feature and --rskip-edge-threshold <0..100> denotes the minimum expected edge-density percentage within the CU, below which the recursion is skipped. Experimental feature.
• Application-level feature --abr-ladder for automating ABR ladder generation. Shows ~65% savings in the over-all turn-around time required for the generation of a typical HLS ladder in Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz over a sequential ABR-ladder generation approach that leverages save-load architecture.
Enhancements to existing features
----------------------------------------------
• Improved 2-pass rate-control algorithm. The savings in the bitrate is ~1.72% with visual improvement in quality in the initial 1-2 secs.
Encoder enhancements
--------------------------------
• Faster ARM64 encodes enabled by ASM contributions from Huawei. The speed-up over no-asm version for 1080p encodes @ medium preset is ~15% in a 16 core H/W.
• Strict VBV conformance in zone encoding.
Bug fixes
------------
• Multi-pass encode failures with --frame-dup.
• Corrupted bitstreams with --hist-scenecut when input depth and internal bit-depth differ.
• Incorrect analysis propagation in multi-level save-load architecture.
• Failure in detecting NUMA packages installed in non-standard directories.
well now Npass encoding seem work like crf mode: It is not a progess. For me the quantizer ratio between pframe and bframe is too high by default.
__________________
Le Sagittaire ... ;-)

1- Ateme AVC or x264
2- VP7 or RV10 only for anime
3- XviD, DivX or WMV9
Sagittaire is offline   Reply With Quote
Old 6th June 2020, 18:34   #7640  |  Link
burnix
Registered User
 
Join Date: Jan 2003
Posts: 44
Patman. Can you build an ffmpeg x64 with it ????

Thanks
burnix 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 00:11.


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