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 22nd March 2023, 12:28   #9061  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 480
x265 v3.5+97
https://www.mediafire.com/file/bu7j9tn2c98sw5i
__________________
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 22nd March 2023, 12:33   #9062  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
New upload: x265 3.5+97-c666bc3d3

[Windows][GCC 12.2.0][32/32XP/64 bit] 8bit+10bit+12bit
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 24th March 2023, 23:14   #9063  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,309
Hello.

Made a new build of my custom mod, check my Github.

Also, i've made out of curiosity some speed tests on my Core i7 6950X, encoding time results :
3.50.0.97 AVX2 GCC 12.2.1 : 614.55s
3.50.0.97 Broadwell GCC 12.2.1 : 608.67s
3.50.0.94 Broadwell LLVM 15.0.7 : 600.10s
3.50.0.97 Broadwell LLVM 16.0.0 : 590.88s

Up to 4% speed difference, well, anything is good to take
__________________
My github.

Last edited by jpsdr; 24th March 2023 at 23:17.
jpsdr is offline   Reply With Quote
Old 25th March 2023, 20:34   #9064  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
Quote:
Originally Posted by Lan4 View Post
Buying a new processor is too easy.
Well, if your CPU is AVX capable only, get the AVX build: http://msystem.waw.pl/x265/

it really is as simple as that...
FranceBB is online now   Reply With Quote
Old 26th March 2023, 21:46   #9065  |  Link
john33
Registered User
 
Join Date: Apr 2002
Location: UK
Posts: 68
Also did some speed tests with results that kind of surprised me:
Ryzen 9 3900XT - Win10 Pro x64
61,070 frames - 1920x816 --crf 24.0 --aq-mode 4 --no-cutree --no-open-gop --no-sao

Code:
Winlibs GCC 13.0.1                          1,946.89secs   31.37fps
Winlibs GCC 12.2.0                          1,928.15secs   31.67fps
Msys2 GCC 12.2.0                            1,903.41secs   32.08fps
http://www.msystem.waw.pl/x265/ GCC 12.2.0  1,898.15secs   32.17fps
LLVM Clang 16                               1,718.27secs   35.54fps
VS2019 V16.11.25                            1,717.45secs   35.56fps
Intel 19.2                                  1,600.23secs   38.16fps
These were all AVX2 optimised with similar settings.

Last edited by john33; 27th March 2023 at 18:05. Reason: Added Intel encode results - a new winner!
john33 is offline   Reply With Quote
Old 27th March 2023, 08:19   #9066  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
Quote:
Originally Posted by LigH View Post
New upload: x265 3.5+97-c666bc3d3

[Windows][GCC 12.2.0][32/32XP/64 bit] 8bit+10bit+12bit
Not that it matters, but just so you know and the XP community doesn't find out the hard way, the XP build you provided is attempting to call GetTickCount64 which doesn't exist in XP x86, while it should really be calling GetTickCount.




Sending GetTickCount64 to GetTickCount fixes the issue of course:




I don't know if something changed under the hood in the way you compile (or if indeed is an autobuild issue?), but... well... now you know.
FranceBB is online now   Reply With Quote
Old 28th March 2023, 22:48   #9067  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
Well, thank you for your discovery ... but don't tell me. I only compile. I do not develop. Multicoreware needs to know (via mailing list) and find a workaround if they still officially support XP compatibility at all. Instead they may probably just call it obsolete.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 28th March 2023, 23:19   #9068  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by LigH View Post
Well, thank you for your discovery ... but don't tell me. I only compile. I do not develop. Multicoreware needs to know (via mailing list) and find a workaround if they still officially support XP compatibility at all. Instead they may probably just call it obsolete.
Given that there is no support or security updates for XP, I think it makes sense to not offer builds for it anymore as that's encouraging people to stick with insecure systems.

For embedded applications things are different, of course.

XP doesn't have explicit NUMA support and is missing a lot of other things helpful for maximizing performance.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 29th March 2023, 09:35   #9069  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
Quote:
Originally Posted by benwaggoner View Post
XP doesn't have explicit NUMA support and is missing a lot of other things helpful for maximizing performance.
That's a very-good reason for an HEVC encoder to drop Windowx XP support.

OTOH,
Quote:
Given that there is no support or security updates for XP, I think it makes sense to not offer builds for it anymore as that's encouraging people to stick with insecure systems.
is just a lame excuse for trollish devilopment.

Seriously: 🆖
__________________
«Your software patents have expired.»
filler56789 is offline   Reply With Quote
Old 1st April 2023, 19:45   #9070  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
I don't mind unmounting a dead horse. There are plenty old but functional versions.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 1st April 2023, 20:07   #9071  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
Quote:
Originally Posted by benwaggoner View Post
Given that there is no support or security updates for XP
Although Microsoft pulled support in mid 2019 with the last security update, there's still 0Patch that picked up the task. That + a good antivirus like Avast and it's good enough for a home user, probably.
Anyway, I found out 'cause I do regular testing on all environments in a VM and one of those is indeed XP.

Quote:
Originally Posted by benwaggoner View Post
I think it makes sense to not offer builds for it anymore
Nah, as I showed it's easy enough to build it in an XP compatible way, so much so that with 1 minor adjustment the build works. My post was more of a "just so you know", that's it.


Quote:
Originally Posted by LigH View Post
Well, thank you for your discovery ... but don't tell me. I only compile. I do not develop.
Yeah, that's the thing, it's not the source code per se, rather I'm trying to figure out why the compiler is calling a non existing kernel function while it really shouldn't given that you're targeting XP in a specific build...

TL;DR Multicoreware has nothing to do this with, rather the compiler or whoever made the autobuild compilation script :P

Quote:
Originally Posted by benwaggoner View Post
XP doesn't have explicit NUMA support and is missing a lot of other things helpful for maximizing performance.
True. In a multicore and multisocket environment, it would probably underperform by a margin: no NUMA, no AVX, no AVX2, no AVX512, also 32bit version of bit depth higher than 8bit don't have any intrinsics at all, so they would run in plain C. Anyway, I don't really think there are any businesses out there running XP/Server 2003 to encode stuff; I myself am on Server 2019 x64 with my farm at work, but I was thinking more about some home users, that's it.
FranceBB is online now   Reply With Quote
Old 2nd April 2023, 08:14   #9072  |  Link
ShortKatz
Registered User
 
Join Date: Aug 2018
Location: Germany
Posts: 118
Finally someone made a pull request to fix the compilation on macOS arm64.
https://mailman.videolan.org/piperma...il/013600.html
Hopefully this patch gets applied soon to fix the broken arm64 compilation on macOS.
ShortKatz is offline   Reply With Quote
Old 5th April 2023, 11:23   #9073  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
Quote:
Originally Posted by FranceBB View Post
Multicoreware has nothing to do this with, rather the compiler or whoever made the autobuild compilation script :P
In that case ... it might be possible that newer GCC versions (12) should get added a command line parameter which was not yet required in older versions (9/10)?
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 6th April 2023, 17:27   #9074  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by ShortKatz View Post
Finally someone made a pull request to fix the compilation on macOS arm64.
https://mailman.videolan.org/piperma...il/013600.html
Hopefully this patch gets applied soon to fix the broken arm64 compilation on macOS.
It was checked in five days ago! Yay!

https://bitbucket.org/multicoreware/...25267b16258c21
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 6th April 2023, 23:30   #9075  |  Link
ShortKatz
Registered User
 
Join Date: Aug 2018
Location: Germany
Posts: 118
Quote:
Originally Posted by benwaggoner View Post
It was checked in five days ago! Yay!

https://bitbucket.org/multicoreware/...25267b16258c21
Yes, this are great news. Now I don't need the fix from HandBrake anymore to build on Mac.
ShortKatz is offline   Reply With Quote
Old 7th April 2023, 10:33   #9076  |  Link
DMD
Registered User
 
DMD's Avatar
 
Join Date: Jan 2006
Location: Italy
Posts: 259
Good morning
I have always wondered how to do to predict, the final file size based on preset Medium, Slower.... and CFR quality.
Even reading the specific article at https://slhck.info/video/2017/02/24/crf-guide.html

I have verified that in practice the data obtained is different from that predicted in the article.
I assume that the same value of CRF gives different results according to the speed preset set.
I ask if this assumption of mine can be an attempt at estimated prediction.
One could start the procedure and when we are about the 1% value , check in the temp folder the size of the produced file and make a proportion with the percentage of the remaining process.
Could this be correct?
Thank you
__________________
my PC with Ryzen 7950X
DMD is offline   Reply With Quote
Old 7th April 2023, 15:11   #9077  |  Link
rwill
Registered User
 
Join Date: Dec 2013
Posts: 343
Quote:
Originally Posted by DMD View Post
Could this be correct?
No. But you could randomly encode 50% of a sequence and then you are halfway there.
rwill is offline   Reply With Quote
Old 9th April 2023, 09:31   #9078  |  Link
katzenjoghurt
Registered User
 
Join Date: Feb 2007
Posts: 128
@DMD

When quality reencoding a movie for smaller size I split the source into 7minute chunks using MKVToolnix. I then sort them by filesize and pick one in the middle where I think it's representative for the rest of the movie (day, night, lighting, grain).

I then encode that chunk with different crf values and compare the quality with StaxRip's built-in video comparison tool.

When changing only the crf value my rule of thumb for estimating the resulting file size is:
File size increases by 1.25^(crf_increase).
So if I rise the crf value by 3 it's estimated_new_size = old_crf_filesize*1.25*1.25*1.25.


May not totally answer your question but that's my approach to get close to the sweet spot and it works 85% of the time for me.

Last edited by katzenjoghurt; 9th April 2023 at 09:33.
katzenjoghurt is offline   Reply With Quote
Old 15th April 2023, 07:56   #9079  |  Link
DMD
Registered User
 
DMD's Avatar
 
Join Date: Jan 2006
Location: Italy
Posts: 259
@katzenjoghurt
Thank you for the suggestion, I am also performing tests by processing only 20 % of the file and make an estimate of the total size.




A question I have always wondered why in video files with aspect ratio higher than 16:9, Crop is not used so that the pixel ratio (DAR) is higher than 1.78.
In theory, only the active part of the screen should be processed, also saving time in the compression procedure.
Analyzing with MediaInfo, commercial UHD blurays all have the 16:9 aspetc ratio.
Maybe my reasoning is not correct?
Thanks
__________________
my PC with Ryzen 7950X

Last edited by DMD; 15th April 2023 at 08:09.
DMD is offline   Reply With Quote
Old 15th April 2023, 11:02   #9080  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
The pixel aspect ratio = SAR (sample aspect ratio), means the anamorphic skew factor, is 1:1 in modern commercial video formats. The DAR (display aspect ratio) means the ratio between width and height of the whole image.

The efficiency of compressing temporally stable solid black borders covering complete macroblocks (or partitions in HEVC/H.265) is already quite high. Explicit crop areas with panning offsets may be unsupported by consumer players. Cropping 1088 to 1080 lines in AVC/H.264 video is common, though.
__________________

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 22:04.


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