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 6th December 2023, 04:01   #9181  |  Link
RanmaCanada
Registered User
 
Join Date: May 2009
Posts: 331
Quote:
Originally Posted by Br4twurscht View Post
Hi together,

normally I'm using StaxRip for my encodings and was always happy. HDR10 was added from the source automatically and I could focus on filters, audio and some x265 settings. But now I wanted to try encodes with dolby vision and doesn't get it working.

Firstly, I wanted to ask a question for general understanding. Will the dv metadata be used in the encoding process of x265 in that way, that it has influence on the encoding result itself? Or is the dv metadata "only" added additionally to the stream afterwards and will then be interpreted by the decoder? Or in other words, assuming a dv source and doing one encoding with the rpu file and one without, would the target stream be the same?

Secondly, I wanted to ask if there are guides how to handle the dv stuff for the encoding. I tried this guide https://github.com/staxrip/staxrip/w...Rip-using-x265 and experimented by myself, but run always in an error like
Code:
x265 [INFO]: HEVC encoder version 3.5+147+17-e8947f740 [Mod by Patman]
x265 [INFO]: build info [Windows][MSVC 1937][64 bit] 10bit
x265 [INFO]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [FLAW]: Dolby Vision requires VBV settings to enable HRD.
x265 [FLAW]: x265_encoder_open() failed for Enc, 
x265 [WARN]: Dolby Vision RPU count is greater than frame count in x265
x265 [INFO]: VES muxing with Dolby Vision RPU file successful in x265
aborted at input frame 1, output frame 0 in x265
I read a little bit in the DDVT Thread, but this gave me the impression, that the dv stuff can be muxed and demuxed into/from the container. So, this led me to qustion #1 and I'm still more confused than at the beginning...

Greetings
Br4twurscht
DV is proprietary, and basically what you need to do is follow the information in the DDVT Thread. You do not encode in DV.

https://forum.doom9.org/showthread.php?t=182311

It's a mess.
RanmaCanada is offline   Reply With Quote
Old 6th December 2023, 16:37   #9182  |  Link
Br4twurscht
Registered User
 
Join Date: Jul 2011
Posts: 7
Ok, thx. Then I try my luck with the DDVT.
Br4twurscht is offline   Reply With Quote
Old 24th January 2024, 17:51   #9183  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,768
What's the best source for a multi depth Mac OS ARM x265 binary with all the latest and greatest ARM optimizations?

Last I checked the Xcode version was all messed up and required manual patching. I was never able to get that to work for >8-bit.

It appears the brew version is from 2022!

==> x265: stable 3.5 (bottled), HEAD
% brew info x265
H.265/HEVC encoder
https://bitbucket.org/multicoreware/x265_git
/opt/homebrew/Cellar/x265/HEAD-0b75c44 (11 files, 11.8MB) *
Built from source on 2022-10-20 at 12:33:05
From: https://github.com/Homebrew/homebrew...mula/x/x265.rb
License: GPL-2.0-only
==> Dependencies
Build: cmake ✔
==> Options
--HEAD
Install HEAD version
==> Analytics
install: 20,013 (30 days), 59,842 (90 days), 198,356 (365 days)
install-on-request: 229 (30 days), 537 (90 days), 1,652 (365 days)
build-error: 16 (30 days)
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 24th January 2024, 18:11   #9184  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,420
MacPorts? There is a highdepth variant*, and from what I can tell when looking at the portfile, it doesn't look like it's pinned to a release tarball, so it probably is pulling the latest git HEAD as a snapshot tarball and going from there.

*which you'd enable by tacking '+highdepth' onto the install command.
qyot27 is online now   Reply With Quote
Old 25th January 2024, 00:16   #9185  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,768
Quote:
Originally Posted by qyot27 View Post
MacPorts? There is a highdepth variant*, and from what I can tell when looking at the portfile, it doesn't look like it's pinned to a release tarball, so it probably is pulling the latest git HEAD as a snapshot tarball and going from there.

*which you'd enable by tacking '+highdepth' onto the install command.
That worked!

% x265 --version
x265 [info]: HEVC encoder version 3.5+40-0b75c44c1
x265 [info]: build info [Mac OS X][clang 14.0.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: NEON


That said 3.5+40 quite a while ago, and I think lacks a lot of the NEON optimizations. We've already hit at least 3.5+110. Any suggestions on how to get a more recent branch?
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 25th January 2024, 04:59   #9186  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,420
Ah, yeah it looks like it is set to a particular release after all, although I'm not seeing exactly where they're grabbing 3.5+40-0b75c44c1 from, because the Portfile is set to 3.4, and none of the videolan x265 branches are fresh enough to even approach that.

But there might be a solution to edit the Portfile to use a newer version locally and use that. I haven't done so myself (that I can remember, anyway), but the page on the MacPorts Trac is here:
https://trac.macports.org/wiki/howto/Upgrade

There's also this part of the documentation that describes the Port Groups function that interfaces with Github:
https://guide.macports.org/chunked/r...portgroup.html

So my guess is that the necessary change would be to select a different Github repository that mirrors x265*, and set the version to the most recent commit. Adjust the checksums/size fields to match what those should be for something like that (like this one did when bumping to 3.4), and then attempt to build it again.

*most of the videolan mirror network repos aren't synced with bitbucket either. I have one I used a few months ago to refresh the Yuuki patchset, for example; it's only missing the 4 latest commits.
qyot27 is online now   Reply With Quote
Old 25th January 2024, 17:14   #9187  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 483
x265 v3.5+115
https://www.mediafire.com/file/ftoufvn6cjvz90n
__________________
Do NOT re-post any of my Mediafire links. Download & re-host the content(s) if you want to share it somewhere else.
Barough is offline   Reply With Quote
Old 25th January 2024, 18:08   #9188  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,768
Quote:
Originally Posted by Barough View Post
Apropos of the above, do you have the ability to compile a Mac OS ARM build ?
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 25th January 2024, 19:56   #9189  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 483
Sorry, it's not possible to do that with m-ab-s.

Sent from my SM-S908B via Tapatalk
__________________
Do NOT re-post any of my Mediafire links. Download & re-host the content(s) if you want to share it somewhere else.
Barough is offline   Reply With Quote
Old 26th January 2024, 03:19   #9190  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,420
Quote:
Originally Posted by benwaggoner View Post
Apropos of the above, do you have the ability to compile a Mac OS ARM build ?
https://www.mediafire.com/file/ees2c...ld.tar.xz/file

It seems to compile okay using AppleClang 14 on Monterey.
qyot27 is online now   Reply With Quote
Old 26th January 2024, 17:53   #9191  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,768
Quote:
Originally Posted by qyot27 View Post
https://www.mediafire.com/file/ees2c...ld.tar.xz/file

It seems to compile okay using AppleClang 14 on Monterey.
Awesome thanks! And it sure did the trick. 4K slower Encoding speeds on a M1 Pro are at least a third faster than my brew 3.5+20 build.

MacPorts made a 32-bit no-asm version for some horrible reason; I didn't even bother to benchmark that.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 27th January 2024, 08:47   #9192  |  Link
Ritsuka
Registered User
 
Join Date: Mar 2007
Posts: 95
x265 arch check was broken, it printed 32-bit even on 64-bit ARM versions, actually there is no way to run a macOS 32-bit executable on macOS these days.
Unfortunately there are a lot of repositories stuck on the last "official" x265 version. And some websites like phoronix.com still uses 3.4 in their x86_64 vs ARM benchmarks.
Ritsuka is offline   Reply With Quote
Old 27th February 2024, 17:03   #9193  |  Link
Hellboy.
Registered User
 
Join Date: Mar 2020
Posts: 34
I see some people show this with their encode:

x265 [info]: frame I: 54, Avg QP:13.82 kb/s: 18717.13
x265 [info]: frame P: 1128, Avg QP:15.83 kb/s: 13458.52
x265 [info]: frame B: 6031, Avg QP:20.85 kb/s: 5528.32
x265 [info]: Weighted P-Frames: Y:2.0% UV:1.5%
encoded 7213 frames in 396.22s (18.20 fps), 6867.22 kb/s, Avg QP:20.01

What is "Avg QP"? That mean something for the quality of the encode? Lower or higher is better?
Thanks
Hellboy. is offline   Reply With Quote
Old 27th February 2024, 17:20   #9194  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,774
QP is the "Quantizer Parameter". Imagine it as a divider to reduce the variety of color component values. The higher the quantizer, the less accurate the storage of the video, the more obvious the loss gets, visible in video artifacts like blocking, ringing around edges, banding in smooth color ramps. Lower values help keeping better quality, but that requires more bitrate because the stored values are more variable, so less of them can be reduced to an "almost the same as somewhere else" (visual redundancy).

The x264 and x265 encoders do not apply a constant quantizer to all frames, except you use a parameter which enforces that; in general (in 1 pass CRF mode or in 2-pass mode with a target size), they use a metric called "Rate Factor" which tries to keep the visual loss caused by the encoding below a specific threshold, which allows the quantizer to vary a bit in relation to the complexity of the video content.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid

Last edited by LigH; 27th February 2024 at 17:23.
LigH is offline   Reply With Quote
Old 27th February 2024, 18:27   #9195  |  Link
Hellboy.
Registered User
 
Join Date: Mar 2020
Posts: 34
There is some "Avg QP" number that encoders try to achieve? Example: Like below 20.
Hellboy. is offline   Reply With Quote
Old 27th February 2024, 18:39   #9196  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,774
Only if you enforce that by an additional parameter (which may lead to the resulting bitrate exceeding your expectations).

Code:
   --qpfile <string>             Force frametypes and QPs for some or all frames
                                 Format of each line: framenumber frametype QP
                                 QP is optional (none lets x265 choose). Frametypes: I,i,K,P,B,b.
                                 QPs are restricted by qpmin/qpmax.

-q/--qp <integer>                QP for P slices in CQP mode (implied). --ipratio and --pbration determine other slice QPs

   --qpmax <integer>             sets a hard upper limit on QP allowed to ratecontrol. Default 69
In general, though, the rate control algorithm is allowed to vary quantization values as required by the video content.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid

Last edited by LigH; 27th February 2024 at 18:43.
LigH is offline   Reply With Quote
Old 27th February 2024, 22:20   #9197  |  Link
Hellboy.
Registered User
 
Join Date: Mar 2020
Posts: 34
Using higher number on these settings always translate in better quality? (For Blu-ray content with 8,000Bitrate or more and knowing that the encode is going to take more time.) (Slow crf17)

bframes
rc-lookahead
subme

I ask because higher preset use higher numbers and a lot of encoders use slow preset with higher numbers.

Last edited by Hellboy.; 28th February 2024 at 15:04.
Hellboy. is offline   Reply With Quote
Old 28th February 2024, 15:10   #9198  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,774
Not certainly.

B frames are useful in 2-pass encoding to achieve a lower average QP of I and P frames because they often use less bitrate, but use a higher QP themselves by default (I/P/B ratios) because their loss is only visible for a brief time and does not propagate much through time (in contrast to the loss of a P frame sequence). In a CRF encoding they don't improve quality, only help reducing the output size. Also there are hardware decoders which are limited in features. A range of 1-3 consecutive B frames is rather safe. In case of more than 2, enable the B frame pyramid so their weighting is distributed better.

The rate control lookahead also does not help much in the CRF case because there is no rate control on top to alter the target rate factor, you set it constant. It is more important in 2-pass with a target size and in 1-pass with a rather constant average bitrate.

A finer motion estimation is helpful in general. But there is no guarantee for exceptional cases where less than the maximum would already be enough.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid

Last edited by LigH; 28th February 2024 at 15:12.
LigH is offline   Reply With Quote
Old 29th February 2024, 20:23   #9199  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,768
Quote:
Originally Posted by LigH View Post
B frames are useful in 2-pass encoding to achieve a lower average QP of I and P frames because they often use less bitrate, but use a higher QP themselves by default (I/P/B ratios) because their loss is only visible for a brief time and does not propagate much through time (in contrast to the loss of a P frame sequence). In a CRF encoding they don't improve quality, only help reducing the output size. Also there are hardware decoders which are limited in features. A range of 1-3 consecutive B frames is rather safe. In case of more than 2, enable the B frame pyramid so their weighting is distributed better.
Are there decoders outside of optical disc that are limited to three? I've been using up to 8 on a very wide variety of streaming players for a decade, without any compatibility issues.

Quote:
The rate control lookahead also does not help much in the CRF case because there is no rate control on top to alter the target rate factor, you set it constant. It is more important in 2-pass with a target size and in 1-pass with a rather constant average bitrate.
Lookahead absolutely can help CRF if the VBV limit it hit (--vbv-bufsize and --vbv-maxrate set, which is required to set a Profile and Level for device compatibility). When the VBV limit would be hit, more lookahead lets the encoder smooth out the bitrate fluctuation, and thus moderate the worst-case QP spike/quality hit.

RAM permitting, rc-lookhead=keyint provides optimal quality, although there are diminishing returns past 50 or so.

Quote:
A finer motion estimation is helpful in general. But there is no guarantee for exceptional cases where less than the maximum would already be enough.
Yeah, like a lot of quality/speed tradeoff parameters, you're doing stuff that makes it slower for all content that will only help some content. The higher the bitrate, the less likely there will be any visible changes.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 29th February 2024, 20:28   #9200  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,774
Quote:
Originally Posted by benwaggoner View Post
Are there decoders outside of optical disc that are limited to three? I've been using up to 8 on a very wide variety of streaming players for a decade, without any compatibility issues.
Maybe early Apple mobile and Quicktime decoders ... surely improving over time.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH 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 07:18.


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