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 11th May 2020, 23:08   #7601  |  Link
stax76
Registered User
 
stax76's Avatar
 
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
If somebody is looking for vpy code:

https://github.com/rigaya/NVEnc/blob..._input_vpy.cpp

https://github.com/FFmpeg/FFmpeg/blo.../vapoursynth.c

Last edited by stax76; 11th May 2020 at 23:26.
stax76 is offline   Reply With Quote
Old 12th May 2020, 20:48   #7602  |  Link
stax76
Registered User
 
stax76's Avatar
 
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
Maybe I build a chunk encoding console app as it seems to be relatively simple and nobody else seems to be interested in building it. Are there any special x265 settings needed? x264 has a --stitchable option. How does ripbot264 do it? vspipe and avs2pipemod allow defining start and end frame. Are two chunks enough?
stax76 is offline   Reply With Quote
Old 12th May 2020, 22:18   #7603  |  Link
vpupkind
Registered User
 
Join Date: Jul 2007
Posts: 60
Quote:
Originally Posted by stax76 View Post
Maybe I build a chunk encoding console app as it seems to be relatively simple and nobody else seems to be interested in building it. Are there any special x265 settings needed? x264 has a --stitchable option. How does ripbot264 do it? vspipe and avs2pipemod allow defining start and end frame. Are two chunks enough?
You may want to use their "chunked encoding" mode which will improve performance at the chunk boundaries
vpupkind is offline   Reply With Quote
Old 13th May 2020, 09:08   #7604  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
x265 3.3+27-g4780a8d99 (multilib, GCC 10.1)
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 13th May 2020, 09:54   #7605  |  Link
stax76
Registered User
 
stax76's Avatar
 
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
Quote:
Originally Posted by vpupkind View Post
You may want to use their "chunked encoding" mode which will improve performance at the chunk boundaries
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.
stax76 is offline   Reply With Quote
Old 14th May 2020, 02:45   #7606  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
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   #7607  |  Link
crystalfunky
Registered User
 
Join Date: Apr 2010
Posts: 57
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   #7608  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
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   #7609  |  Link
RanmaCanada
Registered User
 
Join Date: May 2009
Posts: 328
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   #7610  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
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   #7611  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
Quote:
Originally Posted by LigH View Post
x265 3.3+27-g4780a8d99 (multilib, GCC 10.1)
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊
LoRd_MuldeR is offline   Reply With Quote
Old 16th May 2020, 15:02   #7612  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
x265.exe 3.3+31-d5695e2

http://msystem.waw.pl/x265/
filler56789 is offline   Reply With Quote
Old 18th May 2020, 18:02   #7613  |  Link
stax76
Registered User
 
stax76's Avatar
 
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
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   #7614  |  Link
RanmaCanada
Registered User
 
Join Date: May 2009
Posts: 328
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   #7615  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
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   #7616  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 480
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   #7617  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
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   #7618  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
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   #7619  |  Link
quietvoid
Registered User
 
Join Date: Jan 2019
Location: Canada
Posts: 570
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   #7620  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
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
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:21.


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