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 ... 5 6 7 8 9 ... 16
User actions

LoRd_MuldeR

#90
November 15, 2009, 02:13:34 PM
libx264 SVN-r1339 with Weighted P-Frame Prediction:
[list=*]
______________________________________________________


libx264 SVN-r1339 without Weighted P-Frame Prediction and MB-Tree:
[list=*]
______________________________________________________


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

The patches used for my builds can be found at this location.
Information about the new \"Macroblock Tree\" ratecontrol, which redefines the CRF scale, can be found in this thread.
More info on AutoVAQ (now officially committed) can be found in this thread.

This revision fixes at least two possible Deadlocks in Weighted P-Frame Prediction.
Therefore people are highly encouraged to update asap!
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/

Brazil

#91
November 15, 2009, 05:26:07 PM
Quote from: LoRd_MuldeRlibx264 SVN-r1339 with Weighted P-Frame Prediction:
Which weightp parameter is your build using ? 1 or 2 ?


Quote from: LoRd_MuldeRlibx264 SVN-r1339 without Weighted P-Frame Prediction and MB-Tree:
I\'m not sure to understand it properly: does this mean this build has no weightp AND no mbtree or is it no weightp WITH mbtree on ?

LoRd_MuldeR

#92
November 15, 2009, 09:48:59 PM
Quote from: Brazil
Quote from: LoRd_MuldeRlibx264 SVN-r1339 with Weighted P-Frame Prediction:
Which weightp parameter is your build using ? 1 or 2 ?

It\'s hardcoded to mode 2 (aka \"Smart\") in my builds, as Avidemux doesn\'t support the \"weighted_pred\" parameter yet.

BTW: You know that Avidemux creates a log file and x264 prints its complete parameter set to that log?


Quote from: Brazil
Quote from: LoRd_MuldeRlibx264 SVN-r1339 without Weighted P-Frame Prediction and MB-Tree:
I\'m not sure to understand it properly: does this mean this build has no weightp AND no mbtree or is it no weightp WITH mbtree on ?

MB-Tree is always on, unless stated otherwise. That\'s because MB-Tree is x264\'s default and it does a great job.

However in that specific build both, MB-Tree and Weighted P-Frames, are disabled :o

That was a necessary workaround: I currently must disable MB-Tree when I hardcode weighted_pred to mode 0.

In original x264 weighted_pred = 0 would be overwritten to -1 (\"Fake\" mode), if MB-Tree is enabled ;)

Again a look at the log file could have answered your question faster. Also all patches are included in the 7z file.
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/

Brazil

#93
November 16, 2009, 05:10:56 PM
Quote from: LoRd_MuldeRIt\'s hardcoded to mode 2 (aka \"Smart\") in my builds, as Avidemux doesn\'t support the \"weighted_pred\" parameter yet.
OK, thanks for the info. It has to be used with care then since there are some decoders and hardware having problems with this mode AFAIK.

Quote from: LoRd_MuldeRBTW: You know that Avidemux creates a log file and x264 prints its complete parameter set to that log?
No I didn\'t know that x264 parameters were in the log.
And you know what ? I never read the log when everything is working as expected :P
I read it only in case of a crash or any other error. But thanks for the tip, it\'ll be usefull.

Quote from: LoRd_MuldeRThat\'s because MB-Tree is x264\'s default and it does a great job.
Not always. It highly depends on the source that\'s why I\'m also using your non-mbtree build sometimes.

Quote from: LoRd_MuldeRHowever in that specific build both, MB-Tree and Weighted P-Frames, are disabled :o
OK thanks. So we can consider this build as an equivalent to r1318 without mbtree then ?

LoRd_MuldeR

#94
November 16, 2009, 08:09:14 PM
libx264 SVN-r1342 with Weighted P-Frame Prediction:
[list=*]
______________________________________________________


libx264 SVN-r1342 without Weighted P-Frame Prediction and MB-Tree:
[list=*]
______________________________________________________


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

The patches used for my builds can be found at this location.
Information about the new \"Macroblock Tree\" ratecontrol, which redefines the CRF scale, can be found in this thread.
More info on AutoVAQ (now officially committed) can be found in this thread.

This revision contains yet another bugfix for Weighted P-Frame Prediction. Previous revisions could produce out-of-specs H.264 streams. Therefore people are highly encouraged to update asap!
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

#95
November 16, 2009, 08:21:46 PM
Quote from: Brazil
Quote from: LoRd_MuldeRIt\'s hardcoded to mode 2 (aka \"Smart\") in my builds, as Avidemux doesn\'t support the \"weighted_pred\" parameter yet.
OK, thanks for the info. It has to be used with care then since there are some decoders and hardware having problems with this mode AFAIK.

Weighted P-Frames are 100% spec compliant. H.264 decoders that fail are broken! However there are only two known decoders that are broken with respect to Weighted-P Frames: CoreVAC 1.9.x (in software mode) and the Apple TV.

Also note that bugs in weightp which could produce out-of-specs streams has just been fixed in r1342 ;)

Quote from: Brazil
Quote from: LoRd_MuldeRHowever in that specific build both, MB-Tree and Weighted P-Frames, are disabled :o
OK thanks. So we can consider this build as an equivalent to r1318 without mbtree then ?

More or less. But other things have been changed/fixed in the meantime. So output won\'t be bit-identical, I guess...
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/

lych

#96
November 17, 2009, 06:24:12 AM
Quote from: LoRd_MuldeRWeighted P-Frames are 100% spec compliant. H.264 decoders that fail are broken! However there are only two known decoders that are broken with respect to Weighted-P Frames: CoreVAC 1.9.x (in software mode) and the Apple TV.
Is CoreAVC 1.9.x broken when using CUDA as well or is it just in software mode?

LoRd_MuldeR

#97
November 17, 2009, 01:34:26 PM
Quote from: lych
Quote from: LoRd_MuldeRWeighted P-Frames are 100% spec compliant. H.264 decoders that fail are broken! However there are only two known decoders that are broken with respect to Weighted-P Frames: CoreVAC 1.9.x (in software mode) and the Apple TV.
Is CoreAVC 1.9.x broken when using CUDA as well or is it just in software mode?

As I said, only \"software\" mode is effected. And it will be fixed in CoreAVC 2.0, to be released this week.

In \"CUDA mode\" CoreAVC doesn\'t decode the video itself. It simply lets the \"PureVideo HD\" decoder do the all the work ;)

Actually CoreAVC doesn\'t use CUDA. It only uses the CUDA Video API to access NVIDIA\'s built-in hardware video decoder unit.

But CoreAVC does NOT implement their own H.264 decoder as CUDA Kernels to run on the GPU.

So if NVIDIA\'s hardware video decoder does handle Weightp properly (and it does), then CoreAVC in \"CUDA mode\" will too.

Hardware decoders are tested more thoroughly against the specs, because they can\'t fix bugs after fabrication :p

[EDIT]

Note that Flash Player, which had some (rare) problems too, has just been fixed. The fix is will be in Flash Player 10.1 ;)
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/

lych

#98
November 18, 2009, 06:21:12 AM
Quote from: LoRd_MuldeRAs I said, only \"software\" mode is effected. And it will be fixed in CoreAVC 2.0, to be released this week.

In \"CUDA mode\" CoreAVC doesn\'t decode the video itself. It simply lets the \"PureVideo HD\" decoder do the all the work ;)

Actually CoreAVC doesn\'t use CUDA. It only uses the CUDA Video API to access NVIDIA\'s built-in hardware video decoder unit.

But CoreAVC does NOT implement their own H.264 decoder as CUDA Kernels to run on the GPU.

So if NVIDIA\'s hardware video decoder does handle Weightp properly (and it does), then CoreAVC in \"CUDA mode\" will too.

Hardware decoders are tested more thoroughly against the specs, because they can\'t fix bugs after fabrication :p

[EDIT]

Note that Flash Player, which had some (rare) problems too, has just been fixed. The fix is will be in Flash Player 10.1 ;)
AH!!!  That makes perfect sense.  I was wondering what everyone was talking about in regards to CoreAVC being broken.  I have been using coreavc in cuda mode ever since it was supported and I have never noticed any problem with my encodes.  Thanks Mulder!

LoRd_MuldeR

#99
November 20, 2009, 01:40:09 AM
libx264 SVN-r1342 with Weighted P-Frame Prediction:
[list=*]
______________________________________________________


libx264 SVN-r1342 without Weighted P-Frame Prediction:
[list=*]
______________________________________________________


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

Recompiled x264 r1342 for the latest Avidemux build, which finally supports x264 core-79.
Interlaced encoding should work again.
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/

Brazil

#100
November 20, 2009, 12:07:50 PM
Quote from: LoRd_MuldeRlibx264 SVN-r1342 with Weighted P-Frame Prediction:
libx264 SVN-r1342 without Weighted P-Frame Prediction:
Thanks for your builds :)

Any chance for a no mbtree build though ? I find in some cases the result is visually better without mbtree.

LoRd_MuldeR

#101
November 20, 2009, 03:03:11 PM
I could make one, when I return back home. But that\'s not before tomorrow.

The better way of course would be an updated x264 dialog in Avidemux, which adds the missing x264 options.

So users could configure MB Tree and weightp at Runtrime, instead of having to use \"special\" builds  ;)
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/

Brazil

#102
November 20, 2009, 03:37:30 PM
Quote from: LoRd_MuldeRThe better way of course would be an updated x264 dialog in Avidemux, which adds the missing x264 options.
That would be nice indeed ;)

LoRd_MuldeR

#103
November 21, 2009, 06:26:06 PM
libx264 SVN-r1342 with Weighted P-Frame Prediction:
[list=*]
______________________________________________________


libx264 SVN-r1342 without Weighted P-Frame Prediction:
[list=*]

libx264 SVN-r1342 without MB-Tree RC:
[list=*]
______________________________________________________


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

Recompiled x264 r1342 for the latest Avidemux build, which finally supports x264 core-79.
Interlaced encoding should work again. Added  builds with MB-Tree RC disabled.
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/

Brazil

#104
November 22, 2009, 02:35:02 PM
Quote from: LoRd_MuldeRlibx264 SVN-r1342 without MB-Tree RC:
Nice, thanks a lot :)
Print
Go Up Pages 1 ... 5 6 7 8 9 ... 16
User actions