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 > MPEG-4 AVC / H.264

Reply
 
Thread Tools Search this Thread Display Modes
Old 10th February 2018, 18:22   #41  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,142
Builds are now multi-bitdepth. Use --output-depth 10
sneaker_ger is offline   Reply With Quote
Old 10th February 2018, 19:18   #42  |  Link
Morku
Registered User
 
Join Date: Jul 2012
Posts: 149
Didn't know that. Thanks a lot! So I am going to use videolan build.
Big thanks to komisar for the effort.
Morku is offline   Reply With Quote
Old 1st March 2018, 18:55   #43  |  Link
chompy
Registered User
 
Join Date: Jul 2004
Posts: 193
Hi, now that unfortunately Komisar seems to no longer update his x264 builds, could anybody please tell where could I get builds with fade compensate patch?

Thanks
chompy is offline   Reply With Quote
Old 1st March 2018, 19:29   #44  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 1,648
Try my release on my github, but read the warning.
__________________
My github.
jpsdr is offline   Reply With Quote
Old 1st March 2018, 20:04   #45  |  Link
chompy
Registered User
 
Join Date: Jul 2004
Posts: 193
Quote:
Originally Posted by jpsdr View Post
Try my release on my github, but read the warning.
Thanks, I'll have a look, but when reading your warning it's like reading chinese, I understand that something seems to be broken and you had to take some actions to handle it (I don't know if staying with ffmpeg 2.8.x has any undesirable side effect), but I don't know if I should take any further precautions.

I've also see that by default your build uses weightp=2 that had some time back problems with some buggy AVC decoder chipsets, so I've always used weightp=1 that was also improved with near weightp=2 results. Do you really recommend 2 or is 1 just fine?
chompy is offline   Reply With Quote
Old 1st March 2018, 20:25   #46  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 1,648
It's not that something is broken, it's that the huge update blending the 8 and 10 bits code introduce so much changes, that a lot of patches need a LOT of rework to be implemented again, so, i've skipped it, but still implement the critical changes. So, my releases are not anymore directly from the master branch. At one point i've created my own branch, and to this branch implement the commits i think necessary.

My personnal point of view is that i absolutely don't care of ***#### buggy chipset because, they are buggy. Their responsability they should assume, not force things on me. Still, personnal point of view and subject which piss me off...
So, nothing realy i can recommend.
__________________
My github.
jpsdr is offline   Reply With Quote
Old 1st March 2018, 20:30   #47  |  Link
chompy
Registered User
 
Join Date: Jul 2004
Posts: 193
Thanks again, all clear now!
chompy is offline   Reply With Quote
Old 11th March 2018, 09:12   #48  |  Link
masterkivat
Registered User
 
Join Date: Dec 2008
Location: Brazil
Posts: 14
that means you won't provide new builds anytime soon, @jpsdr?
I've always used your builds, they process the encodes faster than the others, I have no idea why...
Guess I'll rely on this website then for x264 builds. For x265 I'm using from LigH in HEVC's dedicated topic.
masterkivat is offline   Reply With Quote
Old 11th March 2018, 11:54   #49  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 1,648
If you read, i'll still provide builds, but they'll not be anymore from the master branch.They'll just include what i think is realy necessary, because now i have to add the commits "at hands".
Still, it's not impossible that at one point, i'll not be able to provide builds anymore, but it's not the case yet.
__________________
My github.
jpsdr is offline   Reply With Quote
Old 16th March 2018, 19:25   #50  |  Link
LouieChuckyMerry
Registered User
 
LouieChuckyMerry's Avatar
 
Join Date: Feb 2014
Posts: 236
Quote:
Originally Posted by chompy View Post
Hi, now that unfortunately Komisar seems to no longer update his x264 builds...
Happy Friday! and I hope komisar is well . I've been using the kmod build for several years as I find it noticeably faster than the standard build. Please, does anyone know of another modded build similar to komisar's? Thanks in advance for any help.
LouieChuckyMerry is offline   Reply With Quote
Old 16th March 2018, 22:38   #51  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 12,935
Quote:
Originally Posted by LouieChuckyMerry View Post
Happy Friday! and I hope komisar is well . I've been using the kmod build for several years as I find it noticeably faster than the standard build. Please, does anyone know of another modded build similar to komisar's? Thanks in advance for any help.
There is no reasonable reason why the "kmod" x264 build should be any faster than any "vanilla" (clean) x264 build. The code in x264 where the vast majority of the CPU time is spent is heavily-optimized (hand written) assembler code. The "kmod" build does not contain any "magic" that would give you an additional speed-up out of nowhere! The only patch in "kmod" that is (remotely) related to performance is "x264_demuxer_threads.diff". And even that one does not do anything, except for allowing you to tweak the thread count for the FFMS input module - which might have an effect or not. But, unless you are using ultra-fast encoding settings, the CPU time spent in the input module should be minuscule anyway...

To make a long story short: If you came to the conclusion that "kmod" build is any faster than others, it is probably because you have been comparing different revisions of x264 and/or you have been comparing different encoding settings - which is comparing apples and oranges. I suggest that you look at the specific patches included in "kmod" build and understand what they really do. Unless you really need the "feature" enabled by these specific patches, there is absolutely no reason to use "kmod" instead of a "vanilla" build. For me it was much more important to find an up-to-date x264 build that has FFMS input and MP4 output enabled - which no build except Komisar's seems to have. Well, now Ligh's build has too!
__________________
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.



Last edited by LoRd_MuldeR; 16th March 2018 at 22:54.
LoRd_MuldeR is offline   Reply With Quote
Old 17th March 2018, 11:49   #52  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 1,648
On my releases, i made several versions : Somes build with a posix gcc (the version you have in msys2 with "pacman") and everything is build with threading posix option, and somes build with a win32thread gcc (versison you can get here for exemple) and everything is build win32 threading option.
For each version, i have a "standard" build, and an AVX2/Broadwell build (compiler settings option). Personnaly, never made tests, but someone who used my versions one day made a test : using the different builds on the same video with the same settings, on a Win7x64 system.
Result : win32thread was faster than posix, AVX2/Broadwell build was faster than "standard". But... differences were very slight, no more than 5% between the slowest and the fatest. So, you can have differences according "how best" the compiler optimize, because even if a lot of things are wonderfully well optimized in ASM, there still also a lot of things in pure C code, which leave rooms for optimization. Nevertheless, you'll will never hit more than a small few %.
__________________
My github.
jpsdr is offline   Reply With Quote
Old 17th March 2018, 14:49   #53  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,678
Well ... "LigH's build" just came out of the media-autobuild_suite. No further patches. I have no experience in optimizing the building process or even adding patches.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 17th March 2018, 22:58   #54  |  Link
LouieChuckyMerry
Registered User
 
LouieChuckyMerry's Avatar
 
Join Date: Feb 2014
Posts: 236
Quote:
Originally Posted by LoRd_MuldeR View Post
There is no reasonable reason why the "kmod" x264 build should be any faster than any "vanilla" (clean) x264 build. The code in x264 where the vast majority of the CPU time is spent is heavily-optimized (hand written) assembler code. The "kmod" build does not contain any "magic" that would give you an additional speed-up out of nowhere! The only patch in "kmod" that is (remotely) related to performance is "x264_demuxer_threads.diff". And even that one does not do anything, except for allowing you to tweak the thread count for the FFMS input module - which might have an effect or not. But, unless you are using ultra-fast encoding settings, the CPU time spent in the input module should be minuscule anyway...

To make a long story short: If you came to the conclusion that "kmod" build is any faster than others, it is probably because you have been comparing different revisions of x264 and/or you have been comparing different encoding settings - which is comparing apples and oranges. I suggest that you look at the specific patches included in "kmod" build and understand what they really do. Unless you really need the "feature" enabled by these specific patches, there is absolutely no reason to use "kmod" instead of a "vanilla" build. For me it was much more important to find an up-to-date x264 build that has FFMS input and MP4 output enabled - which no build except Komisar's seems to have. Well, now Ligh's build has too!
Happy Saturday! Thanks for your informative reply, I really appreciate it. Odds are pretty good that I did compare different versions or botch something somewhere when I checked encoding speeds, or perhaps I enjoyed one too many . Anyway, thanks for setting me straight.
LouieChuckyMerry is offline   Reply With Quote
Old 26th March 2018, 09:22   #55  |  Link
kuchikirukia
Registered User
 
Join Date: Oct 2014
Posts: 401
Quote:
Originally Posted by sneaker_ger View Post
Builds are now multi-bitdepth. Use --output-depth 10
They should add a note on videolan, since I was wondering why 10 bit looked to be two revisions behind 8.
Is this why the executable doubled in size? (and out of curiosity, why was x264-r2744-b97ae06.exe 1/5th the size of the ones before it?)

Last edited by kuchikirukia; 26th March 2018 at 09:26.
kuchikirukia is offline   Reply With Quote
Old 26th March 2018, 10:00   #56  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,678
If you have an executable which includes two quite substantially different encoders, then you have about twice the size of code in it, yes.

Earlier versions may also not include additional code to read compressed video formats directly from media files in different containers; small builds may only support raw source formats and AviSynth.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 26th March 2018, 13:10   #57  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,142
The Videolan binaries didn't double in size when the multi-depth builds were introduced. Big grow usually happens when some features are added (like ffms and/or lavf input) or binary compression is deactivated.
sneaker_ger is offline   Reply With Quote
Old 5th April 2018, 01:59   #58  |  Link
kuchikirukia
Registered User
 
Join Date: Oct 2014
Posts: 401
Is anyone else having a problem where encoding x264 lags their computer? It's running in low process priority like it should but I'm having problems with MPC-HC taking 20 seconds to start a video and new tabs hang, and it gets worse the more threads I throw at x264.

Windows 10.

Last edited by kuchikirukia; 5th April 2018 at 02:04.
kuchikirukia is offline   Reply With Quote
Old 5th April 2018, 03:29   #59  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 3,273
Mine doesn't slow down that much! Are you low on memory? Are you encoding to or from your OS drive? SSD or spinning disk?
__________________
madVR options explained
Asmodian is offline   Reply With Quote
Old 5th April 2018, 07:57   #60  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,678
And do you use a rather low- or uncompressed source, so reading it may already be a bottleneck?
__________________

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


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