News:

--

Main Menu

libx264 GIT builds

Started by LoRd_MuldeR, January 30, 2009, 12:39:23 AM

Previous topic - Next topic
Print
Go Down Pages 1 ... 10 11 12 13 14 ... 16
User actions

LoRd_MuldeR

#165
May 01, 2010, 02:30:24 AM
libx264 SVN-r1570:
[list=*]
  • libx264-r1570, MinGW GCC 4.6.0, optimized for Core 2 (removed)[/*]
  • libx264-r1570, MinGW GCC 4.6.0, optimized for K10 (removed)[/*]
  • libx264-r1570, MinGW GCC 4.6.0, optimized for Pentium III (removed)[/*]
  • libx264-r1570, MinGW GCC 4.6.0, generic build (removed)[/*]
  • libx264-r1570, MinGW GCC 4.6.0, without ASM (slow!) (removed)[/*]
[list=*]
  • libx264-r1570, MinGW GCC 4.4.3, legacy build (removed)[/*]
  • libx264-r1570, MinGW GCC 3.4.5, legacy build (removed)[/*]

libx264 SVN-r1570 with AutoVAQ enabled:
[list=*]
  • libx264-r1570, MinGW GCC 4.6.0, optimized for Core 2 (removed)[/*]
  • libx264-r1570, MinGW GCC 4.6.0, optimized for K10 (removed)[/*]
  • libx264-r1570, MinGW GCC 4.6.0, optimized for Pentium III (removed)[/*]
  • libx264-r1570, MinGW GCC 4.6.0, generic build (removed)[/*]
  • libx264-r1570, MinGW GCC 4.6.0, without ASM (slow!) (removed)[/*]

These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r6129 or later now!
You asked me once, what was in Room 101. I told you that you knew the answer already.
Everyone knows it. The thing that is in Room 101 is the worst thing in the world.

MuldeR's OpenSource stuff: http://muldersoft.com/

LoRd_MuldeR

#166
May 01, 2010, 08:13:32 PM
libx264 SVN-r1570:
[list=*]
[list=*]
[list=*]
[list=*]

libx264 SVN-r1570 with AutoVAQ enabled:
[list=*]
[list=*]
[list=*]

These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r6129 or later now!

EDIT: Proper GCC 4.6.0 builds of libx264 r1570 uploaded now. I made a stupid mistake before :/
You asked me once, what was in Room 101. I told you that you knew the answer already.
Everyone knows it. The thing that is in Room 101 is the worst thing in the world.

MuldeR's OpenSource stuff: http://muldersoft.com/

nerdpunk

#167
May 02, 2010, 08:10:08 AM
Quote from: LoRd_MuldeRGCC 4.5.1 ... GCC 4.6.0

wow. you got compilers from the future... can i borrow your time machine for a while? ;)

LoRd_MuldeR

#168
May 02, 2010, 10:02:03 AM
Quote from: nerdpunk
Quote from: LoRd_MuldeRGCC 4.5.1 ... GCC 4.6.0

wow. you got compilers from the future... can i borrow your time machine for a while? ;)

Nope. The aforementioned compilers are not from the future at all :P

GCC 4.6.x is the \"active development\" series (see trunk), GCC 4.5.x is the \"current release\" series (see 4.5 branch).

See the file \"BASE-VER\" file for an exact version number, i.e. \"4.6.0\" and \"4.5.1\" at the moment.

And of course I have tested the \"pre-release\" compilers for regressions regarding x264. The results look fine now!
You asked me once, what was in Room 101. I told you that you knew the answer already.
Everyone knows it. The thing that is in Room 101 is the worst thing in the world.

MuldeR's OpenSource stuff: http://muldersoft.com/

Setsunaaa

#169
May 09, 2010, 05:15:09 PM
Question: You you allow a bigger --merange ? Like up to 256? Or up to 500 since 511.5 is the maximum allowed motion vector...
Currently it is limited to 64, but I am using 128 on a few occasions when doing full HD encodings. It actually reduces the filesize about 5%, _very_ much source video dependent of course.

IF I edit the .js file and set 128 there, will it be accepted by avidemux? It looks like it resets to 16.

Why is --subme 10 missing? I don\'t use it, I only use --subme 9 since I see no difference, so this is just my curiosity....

LoRd_MuldeR

#170
May 09, 2010, 05:31:39 PM
@all:
Can we please keep discussion out of the sticky ???


Quote from: SetsunaaaQuestion: You you allow a bigger --merange ? Like up to 256? Or up to 500 since 511.5 is the maximum allowed motion vector...
Currently it is limited to 64, but I am using 128 on a few occasions when doing full HD encodings. It actually reduces the filesize about 5%, _very_ much source video dependent of course.

IF I edit the .js file and set 128 there, will it be accepted by avidemux? It looks like it resets to 16.

Increasing the motion search range over the default value of 16 is NOT recommended :o

Doing so will significantly slow down the encoding process for a very minor improvement or no improvement at all.

Furthermore 256 or even higher is totally insane. Even x264\'s built-in \"placebo\" and \"veryslow\" presets use a value of only 24.

Everything below \"veryslow\" (i.e. \"slower\" and all the faster presets) sticks with the default value of 16. So should you!


BTW: ME-Range does not specify the maximum MV length, but limits the range that x264 will search to find the best MV.

There also is a separate MV-Range setting in x264 that does limit the maximum MV length.


Quote from: SetsunaaaWhy is --subme 10 missing? I don\'t use it, I only use --subme 9 since I see no difference, so this is just my curiosity....

SubME=10 is not exposed in Avidemux. That\'s simply because nobody has bothered implementing it yet.

My custom builds have it enabled though: Use SubME=9 + ME=UMH/ESA/TESA + Trellis=2 to trigger SubME=10 ;)
You asked me once, what was in Room 101. I told you that you knew the answer already.
Everyone knows it. The thing that is in Room 101 is the worst thing in the world.

MuldeR's OpenSource stuff: http://muldersoft.com/

Setsunaaa

#171
May 09, 2010, 05:51:36 PM
Serious slowdown of merange 128: yes. From 4 fps down to 0.7 fps : ). It is my \"Encoding time does not matter\" setting.

--preset veryslow sets merange to 24 (according to x264 --fullhelp).

I just want to be free to choose, when I see in the source video a lot of motion which goes a bit over 100 pixels per frame it works very well. Like I said: I only use it on SOME HD sources, such motion vector search ranges don\'t make much sense on DVD or lower resolutions.

Such motion vectors are used anyway, according to \"Dark Shakiri\", he says:
Also, \"merange\" is not the range of the maximum motion distance that the motion estimation will catch: it\'s only the distance that it will search beyond the best predictor.


He corrected me on a few other details in that thread (my nick there is Jou):

http://doom10.org/index.php?topic=141.msg1087#msg1087

I won\'t die if you don\'t implement, I can always go back to commandline x264-x64.exe : ). But Avidemux is much more convenient to use compared to my other methods.

LoRd_MuldeR

#172
May 09, 2010, 06:40:41 PM
Quote from: SetsunaaaSerious slowdown of merange 128: yes. From 4 fps down to 0.7 fps : ). It is my \"Encoding time does not matter\" setting.

--preset veryslow sets merange to 24 (according to x264 --fullhelp).

That\'s exactly what I said. And the \"veryslow\" preset should give you a good indication of the slowest settings you should ever use. Anything that\'s beyond \"veryslow\" preset (and especially everything that is included or beyond \"placebo\") should NEVER be used for any real encoding task. The \"placebo\" presets only exists to show people what NOT to use.

Conclusion: If encoding time isn\'t important, use ME-Range 24. Otherwise use ME-Range 16.


Quote from: SetsunaaaI just want to be free to choose, when I see in the source video a lot of motion which goes a bit over 100 pixels per frame it works very well. Like I said: I only use it on SOME HD sources, such motion vector search ranges don\'t make much sense on DVD or lower resolutions.

Sure, you are free to choose. But if ME-Range 24 only gives a very minor improvement over the default ME-Range 16 (if at all) and further anything above ME-Range 24 doesn\'t give any benefit it all (except in homeopathic cases), it simply makes NO sense to use a totally overkill value, such as ME-Range 512. Of course if you insist on using insane settings, then I can\'t prevent you from shooting yourself into the foot. But you have been warned ^^


Quote from: SetsunaaaSuch motion vectors are used anyway, according to \"Dark Shakiri\", he says:
Also, \"merange\" is not the range of the maximum motion distance that the motion estimation will catch: it\'s only the distance that it will search beyond the best predictor.

He corrected me on a few other details in that thread (my nick there is Jou):

http://doom10.org/index.php?topic=141.msg1087#msg1087

That\'s what I said above ;)

ME-Range is the range x264 will search to find the best MV, starting at the best predictor. You know, H.264 doesn\'t store the MV, but only the delta (offset) between the predicted MV and the \"optimal\" MV chosen by the encoder. So the actual length of the resulting MV can be much bigger than the ME-Range. If the predicted MV has a length of 256 for example and the ME search-range is set to 16, then we can get MV\'s with a length of 256±16 (i.e. up to 272). The total MV length can be limited using the MV-Range setting, but of course this may hurt quality! So you should allow the maximum MV length allowed in the H.264 specs (which is the x264 default behavior), because any proper decoder will handle it just fine.

Also: Allowing a bigger ME-Range potentially allows x264 to find \"optimal\" MV\'s it wouldn\'t have found otherwise. BUT: There is no guarantee that a bigger ME-Range will actually result in a \"better\" MV. The predicted MV is pretty good already, so x264 only searches the area around the predicted MV - it does the \"fine adjustment\". The chance that a \"better\" MV is outside the search range of 24 is near zero (i.e. negligible). The chance to find one outside of 16 is very small already...
You asked me once, what was in Room 101. I told you that you knew the answer already.
Everyone knows it. The thing that is in Room 101 is the worst thing in the world.

MuldeR's OpenSource stuff: http://muldersoft.com/

Setsunaaa

#173
May 09, 2010, 07:10:03 PM
But then why allowing up to 64 anyway? Why not remove the option?
But we are getting in the \"we have different opinions\" range : ), should be a different thread (if worth a thread anyway).
So it won\'t be implemented and I\'ll be using cmdline for such cases.

LoRd_MuldeR

#174
May 09, 2010, 07:18:19 PM
Quote from: SetsunaaaBut then why allowing up to 64 anyway? Why not remove the option?

Because neither x264 nor Avidemux prevents the user from doing stupid things.

And choosing between 16 (default) and 24 (slower, slightly better) still makes sense, so removing the option is a no-go!

Furthermore sometimes people want to lower ME-Range below 16 to improve encoding speed.

Last not least, somebody may want to run test encodes with ME-Range 64 to see that it really isn\'t better than 24 ;)


This shows how important the rule of thumb is:
If you don\'t know what a specific setting does or if you don\'t have a good reason to adjusted it, then don\'t touch it.

And if you are uncertain, look at the built-in presets. Is your setting identical to \"placebo\" (or even higher), go correct it!

Blindly crippling your encoding speed by using insane/overkill settings doesn\'t necessarily improve quality...
You asked me once, what was in Room 101. I told you that you knew the answer already.
Everyone knows it. The thing that is in Room 101 is the worst thing in the world.

MuldeR's OpenSource stuff: http://muldersoft.com/

LoRd_MuldeR

#175
May 09, 2010, 07:56:32 PM
libx264 SVN-r1583:
[list=*]
[list=*]
[list=*]
[list=*]

libx264 SVN-r1583 with AutoVAQ enabled:
[list=*]
[list=*]
[list=*]

These builds will NOT work with Avidemux 2.5.1 or older. Please update to Avidemux 2.5.2 r6129 or later now!
You asked me once, what was in Room 101. I told you that you knew the answer already.
Everyone knows it. The thing that is in Room 101 is the worst thing in the world.

MuldeR's OpenSource stuff: http://muldersoft.com/

LoRd_MuldeR

#176
May 17, 2010, 12:04:02 AM
You asked me once, what was in Room 101. I told you that you knew the answer already.
Everyone knows it. The thing that is in Room 101 is the worst thing in the world.

MuldeR's OpenSource stuff: http://muldersoft.com/

LoRd_MuldeR

#177
May 17, 2010, 10:24:46 PM
You asked me once, what was in Room 101. I told you that you knew the answer already.
Everyone knows it. The thing that is in Room 101 is the worst thing in the world.

MuldeR's OpenSource stuff: http://muldersoft.com/

LoRd_MuldeR

#178
May 21, 2010, 10:06:51 PM
You asked me once, what was in Room 101. I told you that you knew the answer already.
Everyone knows it. The thing that is in Room 101 is the worst thing in the world.

MuldeR's OpenSource stuff: http://muldersoft.com/

LoRd_MuldeR

#179
May 26, 2010, 11:55:46 PM
You asked me once, what was in Room 101. I told you that you knew the answer already.
Everyone knows it. The thing that is in Room 101 is the worst thing in the world.

MuldeR's OpenSource stuff: http://muldersoft.com/
Print
Go Up Pages 1 ... 10 11 12 13 14 ... 16
User actions