Current Patches, Where to get them, How they affect speed/output

[MythCreator]

x264.808.modified.experimental.exe (http://www.fs2you.com/files/564e6247-009c-11dd-855e-0014221f4662/)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.7.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=3748
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919
x264_fix_win_stdin.diff
http://forum.doom9.org/showthread.php?p=1120065#post1120065

Link to x264 patches collected: http://files.x264.nl/x264_patches/



make frofiled in GCC 4.4.0 20080331 experimental,totally for experiment & test

[audyovydeo]

bob0r,

I noticed the Thread Pool patch hasn't been applied in a while.
I haven't seen at which point it has been dumped : is it no longer useful, or it simply hasn't been updated ?


Also, am I alone in regretting SVN versioning ? Git seems pretty f_d up.


cheers
a/v

[SpAwN_gUy]

Also, am I alone in regretting SVN versioning ? Git seems pretty f_d up. i was also thinking about WHY? ... SVN is just "New" (comparing to CVS) and git.. is just "newer"...
so.. why?

[nm]

i was also thinking about WHY? ... SVN is just "New" (comparing to CVS) and git.. is just "newer"...
so.. why?
Git is in many ways better than SVN and it makes things easier for collaborative development.

[Henrikx]

What Patches would be useful in a Linux Build (Ubuntu).

[J_Darnley]

What do you want your build to do differently than the git source? The patches (not the Win stdin patch) should work the same way on all systems.

[Henrikx]

@J_Darnley

The patches (not the Win stdin patch) should work the same way on all systems.
That is precisely what I wanted to know.

THX!

[DeathTheSheep]

Git might be newer, and from a developer's standpoint it might be "supposedly" advantageous, but for pete's sake, the web interface is AWFUL. It can't even list the revision number on its (butt-ugly) log.

Ironic an encoder that makes video quite pretty has such an ugly developer's interface. Simplicity, I know...

[Sharktooth]

that's coz there's no revision number in git...

[DeathTheSheep]

Exactly my point. :)

Maybe you should "make the move" and switch your builds to a "last modified date," rather than revision number?

...on second thought, I've grown fond of the revision number system. :P

[edit]
More on topic, I'm thinking of optimizing prepass a bit more, at least so that it shares x264's new mv clipping method. Additionally, I'm also thinking of re-releasing AQ0.46 to overwrite the current 1.0 AQ (possibly deciding which rounding method to use based on whether or not an "--anime" tag is specified).

What sayeth thee?

[SpAwN_gUy]

Additionally, I'm also thinking of re-releasing AQ0.46 to overwrite the current 1.0 AQ (possibly deciding which rounding method to use based on whether or not an "--anime" tag is specified).

What sayeth thee?Cool. :) .. nice and simple... just --anime... and you're an Anime Encoder :) ..

maybe, it would be nice to make such optimisations not only for AQ? (like lame with its presets..)

[Razorholt]

How about grown-ups who don't like whatching cartoons? Kiiiiiding :)

What's your intention DeathTheSheep in re-releasing 0.46? Using it for anime only? Don't you think VAQ2 is better?

[Dark Shikari]

How about grown-ups who don't like whatching cartoons? Kiiiiiding :)

What's your intention DeathTheSheep in re-releasing 0.46? Using it for anime only? Don't you think VAQ2 is better?His purpose is to discourage me from ever releasing any patches publicly again by intentionally distributing broken code with my name on it. :rolleyes:

[~bT~]

^ that's sad :p

keep up the gr8 work Dark!

[burfadel]

Its probably the combination of settings he's using is falsely giving the impression that 0.46 is better, when for example if crf mode the objective quality and file size better relates to simply lowering the crf value. A much better way would be to lower the crf instead. It could also be a settings issue where non-ideal settings are used? Of course with solid colour in anime (the Japanese definition of which is all animation), it probably just simply means lowering the AQ strength slightly may benefit, say to 0.7, and disabling fast-pskip! by --no-fast-pskip which is purported to be better in those situations.

Actually Dark_shikari, how is the relationship between --no-fast-pskip and AQ, do they affect each other? I was just thinking that if a slight deterioration occurs on solid colour due to pskip, AQ may be compensating hence causing problems referred to by deaththesheep? I'm only guessing here...

[Dark Shikari]

Actually Dark_shikari, how is the relationship between --no-fast-pskip and AQ, do they affect each other? I was just thinking that if a slight deterioration occurs on solid colour due to pskip, AQ may be compensating hence causing problems referred to by deaththesheep? I'm only guessing here...AQ will reduce the amount of blocks in which fast-pskip is activated, yes. The primary effect is a reduction in speed.

[burfadel]

Therefore for anime, 0.46 was possibly not correcting the pskip induced areas that occur in flat areas, at least to the extent of the proper VAQ? leaving more bits for lines?

If thats the case, is variable fast-pskip possible? that is, only apply fast-pskip to non-flat areas? I'm guessing that would improve the picture quality and effectiveness of VAQ, and since it would only be applied to flat areas (or largely flat areas) not induce the speed penalty that occurs when --no-fast-pskip is applied? That would be a good default option if possible! I believe its only flat areas that are visually penalised by using fast-pskip?

[DeathTheSheep]

Mmkay guys, lots of stuff to address:

What's your intention DeathTheSheep in re-releasing 0.46? Using it for anime only? Don't you think VAQ2 is better?
My intentions at the time of initial posting were nil, which is precisely the reason why I was gathering input. I've made extensive quality comparisons of the two and have found 0.46 produces a significantly higher SSIM and (perceived) visual quality on low-bitrate (high quantizer) anime sources, especially in baseline profile, and regardless of other options used. However, I do plan to wait it out a bit in the hopes that DS will in fact address anime specifically in VAQ2.0 (read below).

His purpose is to discourage me from ever releasing any patches publicly again by intentionally distributing broken code with my name on it.
What! I appreciate your work as much as (or perhaps more than) most. Recall I was of the very first to support your first x264 hacks (remember x264-sad-opt and such?), and was always in favor of you releasing all and anything you could. I can't understand your accusation of me intentionally discouraging you...unless the underlying intention of this statement is the OS equivalent of FUD (I'm teasing here, but really now, it's unprofessional). Look at my sources, people--any anime sources, including Gundam Seed--and test yourself. My tests were all very clear, replete with commandlines, the source, tons of screenshots, visual analysis, the sample clips, metrics (especially the one found in the "megathread"). Besides, the code is certainly not "broken" (though the rounding is mathematically suboptimal), and if you'd like I can take your name off of it, DS. You can disown your ugly first born, if you will. But at your strongly suggested request, I will hold off on releasing it and instead watch the progress of VAQ 2.0.

Its probably the combination of settings he's using is falsely giving the impression that 0.46 is better
Wrong, my good sir. While I do not profess nearly the code affinity and proficiency of DS, I understand the quality settings of x264 at least well enough to conduct proper and thorough testing (note: baseline/mobile profile). However, in doubt, I also used an exhaustive testing rubric, trying a ridiculously large combination of settings in the effort to convince myself. As you recall, I used no-fast-pskip in the majority of my testing--but certainly not all--and please remember the fact that the underlying algorithm is essentially a quantizer redistribution according to a variance function, not an intentional modification of color information. The difference between 1.0 and 0.46, for instance, is the rounding for core formula. That is all.

If you want a technical explanation, refer to the previous thread. 1.0 is no longer a patch. The admittedly interesting postulate that 0.46 is "favoring lines" isn't necessarily the case either. The quantizers were properly raised, but to the extent that the x264 deblocker would (conveniently) efficiently conceal artifacts. Additionally, relatively flat backgrounds and such were indeed awarded lower quantizers, but not to the extent that blocks would reappear due to an excess or an irregularity of distribution across the entire background. However, it isn't a matter of simply decreasing AQ strength on 1.0 to re-acheive this fragile balance--rather, the two algorithms have a markedly distinct visual effect from one another, for better (as DS strongly supports), or for worse (as DS strongly opposes, since his interests understandably lie with his newer codebase, the evolution of his brainchild).

And indeed, this is only noticeable on anime. Perhaps 0.48/1.0 is in the lead as regards live footage/non-anime content. One would be more willing to accept that a perfected mathematical formula to account for real quantization error would perform more optimally on non-artificial footage unlike anime.

But when all is said and done, this isn't a settings discussion, or a question of whether or not anybody/anything knows what he/it's doing, or who/what is right and wrong about the subtleties of the algorithms at hand--I had wanted a re-release so that any user can come along and see it for himself with his sources and bitrates which performed more optimally for his needs.

The point of fact is, there is far too much contention, and I fear re-releasing AQ 0.46 at this point will do much in the way of hurting DS (his feelings, his name, his efforts) and perhaps the concept of "progress" itself, so I will not. At least not until 2.0 has matured enough to make differences meaningful, not to mention worthwhile. I have my eyes on it, in the meantime...

[Dark Shikari]

Look at my sources, people--any anime sources, including Gundam Seed--and test yourself. My tests were all very clear, replete with commandlines, the source, tons of screenshots, visual analysis, the sample clips, metrics (especially the one found in the "megathread").Your tests were completely invalid, and only proved one thing: lower AQ strength was better on certain frames in anime. Because 0.46 had an effectively lower strength, it therefore performed better on those frames. You have never ever posted any comparison clip in which AQ 0.46 offered a "better" distribution of QPs except in that it offered a weaker AQ.

Yet you cannot accept this simple fact, and continue to simply post cherrypicked comparison frames and intentionally misleading comparisons in order to promote an algorithm that does not make sense.

I welcome an attempt to make a better AQ for anime; I have had a number of ideas in mind, in fact, such as intentionally raising QP for flat blocks while putting lambda much lower, to take advantage of the higher deblocking.

I don't welcome an attempt to rip off a broken, bugged version of my own work and, through a careful campaign of misleading comparisons, declare it "better."

[DeathTheSheep]

Nobody sweepingly declared anything better, and people can determine for themselves whether or not my tests were valid. I strongly believe in their suggestive validity. The higher 0.46 AQ strength was optimal metrically and visually when keyframes (or the frames you "cherrypicked" [that's a funny word] immediately proceeding them!) were respectively boosted. Again, the frames I chose were random. Again, I did not base my comparisons off of still shots.

I welcome your ideas to make AQ better for anime. So much so I'm not re-releasing 0.46, as I said. Please don't misinterpret, and please don't go on the defensive/offensive about this. How about you email me, and I'll take this whole shebang off air, eh?

[Dark Shikari]

I welcome your ideas to make AQ better for anime.If you want to work on this, drop by #x264dev; I'd be happy to help. I'm somewhat interested in the concept myself, and given your success in getting QNS to work, I suspect you're good enough at coding that given enough guidance you can try out some ideas ;)
So much so I'm not re-releasing 0.46, as I said.Good that's cleared up then.

[DeathTheSheep]

Hey, I'm not one to so easily forget about that little QNS present you presented me. I owe you big time for help on that. And for that, period. :)

[Razorholt]

Can we once for all determine how to declare what's best? If comparing frames doesn't make sense at all (Although you DS as well as others is using that method very often) and if SSIM doesn't always make sense either, so what does? I'm talking about professional judgment and not personal taste.

I have the feeling that this little war between VAQ 0.46 partisans and VAQ 1.0 enthusiasts will not end soon... And I don't think it benefits the majority of us (x264 users).

I'm personally spending a lot of hours encoding and comparing VAQ settings because it's the least I can do to “give back”, but I want to know whether my time is spent wisely.


Thanks,
- Dan

[DeathTheSheep]

Actually, trying to find the "best" is banned in this forum. Even the word. :) You can do metrics, or you can do a double-blind elsewhere.

But, as DS suggested, it's best to pick up 2.0 and optimize that specifically rather than keep around the old guy.

[Razorholt]

So, SSIM + frames comparison will work or not? - I'm talking about comparing settings.

[DeathTheSheep]

Why not? Nobody's stopping you, knock yourself out. But in retrospect, 1.0 is committed, and there's a 2.0 under wraps, so why not just integrate 0.46's benefit (not the formula, but some "anime optimization") into 2.0 while it's still not out of the oven?

[Razorholt]

No no, I'm talking about comparing different settings using VAQ2 exclusively. Oh well, I'll stick to frames + SSIM and that's it. :)

[burfadel]

So variable fast-pskip, so that is only applies to non-flat areas wouldn't actually work?!

[lexor]

No no, I'm talking about comparing different settings using VAQ2 exclusively. Oh well, I'll stick to frames + SSIM and that's it. :)

I think the original quote by DS about frame to frame comparison being useless is being misinterpreted. What I think it should say is that you can't take just one frame and compare that frame with different settings. If you take enough frames out of the stream and compare them using different settings, it's valid.

Think of it this way, bits have to go somewhere. If one frame has lost some, another had to gain some to maintain bitrate (especially with 2pass). So selecting like 1 or 2% of frames at random (random is important here) and comparing them is useful and will yield a valid result. Though it will be difficult if the source has a large number of frames (i.e. you aren't testing on a short clip). You can of course reduce the number of frames (2% I would say is an overkill) at the expense of confidence in your conclusion. However don't just use avisynth's selectevery()/even/whatever-else function, you have got to pick randomly as many frames as you are willing to compare. So get a decent pseudo-random number generator (random.org is a good place for a quick one) generate N numbers between 1 and max_num_frames in your clip, then compare the frames corresponding to those numbers.

[Dark Shikari]

I think the original quote by DS about frame to frame comparison being useless is being misinterpreted. What I think it should say is that you can't take just one frame and compare that frame with different settings. If you take enough frames out of the stream and compare them using different settings, it's valid.One trick is to also compare frame sizes: if two frames are quite different sizes, its probably not a valid comparison.

With P/B frames, one also has to look at the size of the last I-frame and recent frames, too.

[DeathTheSheep]

Hot diggity dang, QNS is so good it hurts. And so slow it hurts. (Hey, there's always the tradeoff).

It's simply amazing in baseline. It brings CAVLC encoding to the efficiency of CABAC+trellis encoding. Well, you know. Pretty much. It's absolutely, utterly, ridiculously good on low-bitrate anime. No, no, forget AQ for now, this thing is already on the table. This is the first real progress baseline profile has seen since AQ. And that was the first ever, pretty much, since general RDO refinements. Usually CABAC and B-frames and trellis are required when quality is increased, but nobody seemed to care about where the quality hits home the most--in the lowest bitrates, for older computers or crappy decoders or handhelds or small screens and so on.

QNS is astounding. I can't believe something like tucking quant error in strange places does something this...marked. Is there any hope of a speedup??!

[Dark Shikari]

Hot diggity dang, QNS is so good it hurts. And so slow it hurts. (Hey, there's always the tradeoff).

It's simply amazing in baseline. It brings CAVLC encoding to the efficiency of CABAC+trellis encoding. Well, you know. Pretty much. It's absolutely, utterly, ridiculously good on low-bitrate anime. No, no, forget AQ for now, this thing is already on the table. This is the first real progress baseline profile has seen since AQ. And that was the first ever, pretty much, since general RDO refinements. Usually CABAC and B-frames and trellis are required when quality is increased, but nobody seemed to care about where the quality hits home the most--in the lowest bitrates, for older computers or crappy decoders or handhelds or small screens and so on.

QNS is astounding. I can't believe something like tucking quant error in strange places does something this...marked. Is there any hope of a speedup??!This is because QNS does two things:

1. It serves as a non-optimal version of trellis that works on CAVLC. Normal trellis might actually have to be exponential time to work on CAVLC. This means you get most of the benefits of trellis on CAVLC, at a high speed cost (but not as high as true trellis). One thing you might want to try is to not use the variance-weighting at all (use a constant weight for each pixel) and then change the "error *= 38" line to make the bitrate equal to what it was before in CRF mode; this will make the result of QNS basically like trellis. Considering the amazing benefit of both trellis and CABAC on low-bitrate anime, its not surprising QNS is also so useful.

2. It weights the value of pixels based on their local variance.

Possible speedups:

1. Find a way to estimate the bit cost of a decision without doing an actual macroblock_write. Trellis already has this; obviously its method is CABAC-only.

2. Make a special IDCT function that adds only a single basis vector to an existing IDCT output, since we're only adjusting one coefficient at a time. FFmpeg has something like this for the regular DCT, which is even more important there since MPEG-2/MPEG-4 ASP use much slower DCT algorithms than H.264 does.

3. ASM-ize the quality metric used.

4. Don't look at coefficients that are already zeroed.

5. Don't consider raising or lowering any coefficient more than once.

[DeathTheSheep]

Varience-weighting, I wonder how it would stack on top of Variance AQ. At the same filesize and settings, I get:
Normal 0.46: SSIM: 0.9752356
w/QNS 0.46: SSIM: 0.9758788

I notice less artifacts in the QNS encode (surprised? :P).
That's a sizable boost even with VAQ on (admittedly I did use 0.46, though, as it was the only one with adjustable sensitivity I had lying around).

So if I disable variance weighting, will this likely go up or down with VAQ? :)

[Dark Shikari]

So if I disable variance weighting, will this likely go up or down with VAQ? :)Try and see ;)

[lexor]

One trick is to also compare frame sizes: if two frames are quite different sizes, its probably not a valid comparison.

With P/B frames, one also has to look at the size of the last I-frame and recent frames, too.

It's a bad thing to try to manually find specific frames to compare by an arbitrary criterion like you describe. Just because frames found by that criterion may be better with AQ, the price you pay for them on other frames may be too high. It is the overall quality that we want too see, having a bunch of really good frames counts for little if the rest of the frames tank.

Random selection is as close as we can get to fairness (with large enough sample pool, it will actually achieve fairness), due to natural balancing properties of random selection.

[fields_g]

No no, I'm talking about comparing different settings using VAQ2 exclusively. Oh well, I'll stick to frames + SSIM and that's it. :)

I've been seeing messages about using PNSR finally disappearing. In a non-AQ world, SSIM has much more meaning than now with VAQ. This is because VAQ, in some cases, will lower SSIM to achieve better subjective quality. This is because SSIM is not a perfect match to the average user's perception (although better then PNSR).

With newer VAQ moving bits between frames, select frames can look worse while a segment of encoded time is better perceptually.

My coding abilities are no where close to many here so I'm not one for implementation, but I think I see the need to complete another tool before we further try to tweak VAQ. Do you guys also see a need for some comparison tool (player)?

Load 2 (or more) encoded files, have a single time slider, blind the user of which is which, Side by side and/or toggled playback, user rating, etc. Have you guys seen what tools are available for audio abx? They even have blinded submissions so results can be combined with other people's results!

We can successfully make crude tweaks to psy, but when we start smaller shifts, we do really need something better.

[IgorC]

I totally agree with you.
Public ABX is optimal way to go when test psycho visual enhancements.
There was application MSU ABX for video.

[lexor]

I totally agree with you.
Public ABX is optimal way to go when test psycho visual enhancements.
There was application MSU ABX for video.

Actually I don't think this should be done as a group. Anything but personal tests are not very useful in this case. If you look at the audio ABX tests, they ask one question "can you hear a difference between 2 files?". Testing AQ doesn't just ask the question of "can you see a difference?", it also has to ask "is the difference better?". And "better" is not just a question of more or less noise (as it is in audio abx between multiple formats), it's too much of a personal preference in AQ's case.

I remember when DS first started working on his AQ he asked us to rate a bunch of pics (while fine tuning some params) and the thing that looked best to me was a sharper detailed picture, but others voted for blurrier ones, because that's more DVD like (or so they said).

While ABX will detect difference reliably, in this case it can't really rate quality effectively.

[fields_g]

lexor,
I see what you are saying about abx about perceivable differences. I think you are right, however if it is tied to using high/low anchors and a rating system, meaningful "x" is better than "y" can be determined. Take for example the 64 kbps encoding comparison here (http://www.listening-tests.info/mf-64-1/results.htm). I think your concern also connects to the important note found on the page:
Important note: These plots represent group preferences (for the particular group of people who participated in the test). Individual preferences vary somewhat. The best codec for a person is dependent on his own preferences and the type of music he prefers.
It is true that it is the rating is based on the participants. And not all participants may agree. That is where the averages and confidence intervals come into play.

But your concern that this should be done independently because personal preference varies, I believe, is wrong. Psy is all about compromises. We strive to have the compromises have as little visual impact on the end product for most people. Opinions will differ at points and what wins out should be what is most pleasing for the majority. Therefore it should be tested as a group, with group data backing our decisions.

I'm not saying that only one version of psy will be committed. Eventually I hope we develop multiple psy models, for example anime, noise, darkness, bitrate, etc and interactions between these. Hopefully scene detection will come into the mix and an auto detect setting would choose the correct model for that scene. We are not looking at psy this way yet, and may not ever. We are trying to find broad psy that works on most for most.

We will not be able to commit every conceived psy into x264 and at some point we will need to trim to the most useful. Personal taste needs to be set aside for group tastes at these times. This is where I believe a comparison tool fits.

I'm not trying to sound overly egalitarian, but it has its place when judging subjectively.

Oh yea... acceptance is also based on if x264 authors are willing to maintain the psy code also.

[MythCreator]

x264.815.modified.experimental.exe (http://www.fs2you.com/files/3d178ab5-06e9-11dd-a2d4-00142218fc6e/)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.7.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=3748
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919
x264_fix_win_stdin.diff
http://forum.doom9.org/showthread.php?p=1120065#post1120065

Link to x264 patches collected: http://files.x264.nl/x264_patches/



make frofiled in GCC 4.4.0 20080331 experimental,totally for experiment & test

[bob0r]

x264.816.modified.exe (http://files.x264.nl/x264.816.modified.exe)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.7.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=3748
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919

Link to x264 patches collected: http://files.x264.nl/x264_patches/

[MythCreator]

x264.816.modified.experimental.exe (http://www.fs2you.com/files/5cad8a23-06ee-11dd-8be7-0014221b798a/)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.7.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=3748
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919
x264_fix_win_stdin.diff
http://forum.doom9.org/showthread.php?p=1120065#post1120065

Link to x264 patches collected: http://files.x264.nl/x264_patches/



make frofiled in GCC 4.4.0 20080331 experimental,totally for experiment & test

[Atak_Snajpera]

I cannot find -aq-mode in longhelp :(

[MuLTiTaSK]

I cannot find -aq-mode in longhelp :(


x264 core:59 r816M 761630d
Syntax: x264 [options] -o outfile infile [widthxheight]

Infile can be raw YUV 4:2:0 (in which case resolution is required),
or YUV4MPEG 4:2:0 (*.y4m),
or AVI or Avisynth if compiled with AVIS support (yes).
Outfile type is selected by filename:
.264 -> Raw bytestream
.mkv -> Matroska
.mp4 -> MP4 if compiled with GPAC support (yes)

Options:

-h, --help List the more commonly used options
--longhelp List all options

Frame-type options:

-I, --keyint <integer> Maximum GOP size [250]
-i, --min-keyint <integer> Minimum GOP size [25]
--scenecut <integer> How aggressively to insert extra I-frames [40]
--pre-scenecut Faster, less precise scenecut detection.
Required and implied by multi-threading.
-b, --bframes <integer> Number of B-frames between I and P [0]
--no-b-adapt Disable adaptive B-frame decision
--b-bias <integer> Influences how often B-frames are used [0]
--b-pyramid Keep some B-frames as references
--no-cabac Disable CABAC
-r, --ref <integer> Number of reference frames [1]
--no-deblock Disable loop filter
-f, --deblock <alpha:beta> Loop filter AlphaC0 and Beta parameters [0:0]
--interlaced Enable pure-interlaced mode (tff)
--tff Alias for --interlaced
--bff Enable pure-interlaced mode (bff)

Ratecontrol:

-q, --qp <integer> Set QP (0=lossless) [26]
-B, --bitrate <integer> Set bitrate (kbit/s)
--crf <float> Quality-based VBR (nominal QP)
--vbv-maxrate <integer> Max local bitrate (kbit/s) [0]
--vbv-bufsize <integer> Enable CBR and set size of the VBV buffer (kbit) [0]
--vbv-init <float> Initial VBV buffer occupancy [0.9]
--qpmin <integer> Set min QP [10]
--qpmax <integer> Set max QP [51]
--qpstep <integer> Set max QP step [4]
--ratetol <float> Allowed variance of average bitrate [1.0]
--ipratio <float> QP factor between I and P [1.40]
--pbratio <float> QP factor between P and B [1.30]
--chroma-qp-offset <integer> QP difference between chroma and luma [0]
--aq-mode <integer> How AQ distributes bits [2]
- 0: Disabled
- 1: Avoid moving bits between frames
- 2: Move bits between frames
--aq-strength <float> Reduces blocking and blurring in flat and
textured areas. [1.0]
- 0.5: weak AQ
- 1.5: strong AQ

-p, --pass <1|2|3> Enable multipass ratecontrol
- 1: First pass, creates stats file
- 2: Last pass, does not overwrite stats file
- 3: Nth pass, overwrites stats file
--stats <string> Filename for 2 pass stats ["x264_2pass.log"]
--rceq <string> Ratecontrol equation ["blurCplx^(1-qComp)"]
--qcomp <float> QP curve compression: 0.0 => CBR, 1.0 => CQP [0.60]
--cplxblur <float> Reduce fluctuations in QP (before curve compression) [20.0]
--qblur <float> Reduce fluctuations in QP (after curve compression) [0.5]
--zones <zone0>/<zone1>/... Tweak the bitrate of some regions of the video
Each zone is of the form
<start frame>,<end frame>,<option>
where <option> is either
q=<integer> (force QP)
or b=<float> (bitrate multiplier)
--qpfile <string> Force frametypes and QPs

Analysis:

-A, --partitions <string> Partitions to consider ["p8x8,b8x8,i8x8,i4x4"]
- p8x8, p4x4, b8x8, i8x8, i4x4
- none, all
(p4x4 requires p8x8. i8x8 requires --8x8dct.)
--direct <string> Direct MV prediction mode ["spatial"]
- none, spatial, temporal, auto
--direct-8x8 <-1|0|1> Direct prediction size [-1]
- 0: 4x4
- 1: 8x8
- -1: smallest possible according to level
-w, --weightb Weighted prediction for B-frames
--me <string> Integer pixel motion estimation method ["hex"]
- dia: diamond search, radius 1 (fast)
- hex: hexagonal search, radius 2
- umh: uneven multi-hexagon search
- esa: exhaustive search
- tesa: hadamard exhaustive search (slow)
--merange <integer> Maximum motion vector search range [16]
--mvrange <integer> Maximum motion vector length [-1 (auto)]
--mvrange-thread <int> Minimum buffer between threads [-1 (auto)]
-m, --subme <integer> Subpixel motion estimation and partition
decision quality: 1=fast, 7=best. [5]
--me-prepass Run an ME prepass on predictors. Requires subme 3 or higher.
--b-rdo RD based mode decision for B-frames. Requires subme 6 or higher.
--mixed-refs Decide references on a per partition basis
--no-chroma-me Ignore chroma in motion estimation
--bime Jointly optimize both MVs in B-frames
-8, --8x8dct Adaptive spatial transform size
-t, --trellis <integer> Trellis RD quantization. Requires CABAC. [0]
- 0: disabled
- 1: enabled only on the final encode of a MB
- 2: enabled on all mode decisions
--no-fast-pskip Disables early SKIP detection on P-frames
--no-dct-decimate Disables coefficient thresholding on P-frames
--nr <integer> Noise reduction [0]

--deadzone-inter <int> Set the size of the inter luma quantization deadzone [21]
--deadzone-intra <int> Set the size of the intra luma quantization deadzone [11]
Deadzones should be in the range 0 - 32.
--cqm <string> Preset quant matrices ["flat"]
- jvt, flat
--cqmfile <string> Read custom quant matrices from a JM-compatible file
Overrides any other --cqm* options.
--cqm4 <list> Set all 4x4 quant matrices
Takes a comma-separated list of 16 integers.
--cqm8 <list> Set all 8x8 quant matrices
Takes a comma-separated list of 64 integers.
--cqm4i, --cqm4p, --cqm8i, --cqm8p
Set both luma and chroma quant matrices
--cqm4iy, --cqm4ic, --cqm4py, --cqm4pc
Set individual quant matrices

Video Usability Info (Annex E):
The VUI settings are not used by the encoder but are merely suggestions to
the playback equipment. See doc/vui.txt for details. Use at your own risk.

--overscan <string> Specify crop overscan setting ["undef"]
- undef, show, crop
--videoformat <string> Specify video format ["undef"]
- component, pal, ntsc, secam, mac, undef
--fullrange <string> Specify full range samples setting ["off"]
- off, on
--colorprim <string> Specify color primaries ["undef"]
- undef, bt709, bt470m, bt470bg
smpte170m, smpte240m, film
--transfer <string> Specify transfer characteristics ["undef"]
- undef, bt709, bt470m, bt470bg, linear,
log100, log316, smpte170m, smpte240m
--colormatrix <string> Specify color matrix setting ["undef"]
- undef, bt709, fcc, bt470bg
smpte170m, smpte240m, GBR, YCgCo
--chromaloc <integer> Specify chroma sample location (0 to 5) [0]

Input/Output:

-o, --output Specify output file
--sar width:height Specify Sample Aspect Ratio
--fps <float|rational> Specify framerate
--seek <integer> First frame to encode
--frames <integer> Maximum number of frames to encode
--level <string> Specify level (as defined by Annex A)

-v, --verbose Print stats for each frame
--progress Show a progress indicator while encoding
--quiet Quiet Mode
--no-psnr Disable PSNR computation
--no-ssim Disable SSIM computation
--threads <integer> Parallel encoding
--thread-input Run Avisynth in its own thread
--non-deterministic Slightly improve quality of SMP, at the cost of repeatability
--no-asm Disable all CPU optimizations
--visualize Show MB types overlayed on the encoded video
--sps-id <integer> Set SPS and PPS id numbers [0]
--aud Use access unit delimiters
--nal-hrd Use NAL HRD parameters
--pulldown <integer> Use 3:2 pulldown
- 32: TBT,BT,BTB,BT pattern
- 64: triple,double *recommended for 720p

[Atak_Snajpera]

I need stronger glasses :)

[bob0r]

I need stronger glasses :)

Or put them on (avatar) :rolleyes:

[bob0r]

x264.818.modified.exe (http://files.x264.nl/x264.818.modified.exe)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.7.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=3748
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919

Link to x264 patches collected: http://files.x264.nl/x264_patches/

[SpAwN_gUy]

can i post this here?

ok. i've found a solution about howto build x264 in MSVC 2005 ... and even with some patches..
but..

i'm having strange compiler errors about "no ";" before "type"" when x264.gaussian.cplxblur.01.diff is applied (just before first declaration of "double gaussian_weight").. is it fixable?

and i'm a bit confused.. how to determine REVISION, when having access only to daily tar-balls?

is there a way to configure git to use proxy?

any simple howto apply patches? (git-merge applied only x264_hrd_pulldown.04_interlace.diff ... and even not on ALL files...)

upd.can anyone test this?
revision... em.. from 20080410. modified.
gPACK, pthreads - enabled :)

applied patches:
x264_me-prepass_DeathTheSheep.01.diff
x264_2pass_vbv.7.diff
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing

removed...

[SpAwN_gUy]

ok.. i've made another one... this one is a bit MORE proper :) .. the previous one had constant glitches on some scenes of my testencode... this one went just fine... if anyone interested...

BTW.. i've changed a bit first patch... 'cause under MSVC it still gave me
"error C2143: syntax error : missing ';' before 'type' d:\CVS\x264farm-GUI\x264\build\x264\encoder\ratecontrol.c line: 1757"

so i had to make it like this:
if(weight < .0001){
break;
}
else {
double gaussian_weight = weight * exp(-j*j/200.0);
weight_sum += gaussian_weight;
cplx_sum += gaussian_weight * (qscale2bits(rcj, 1) - rcj->misc_bits);
}

x264 rev.819, modified, MSVC2005 build
General thread:
http://forum.doom9.org/showthread.php?t=130364

x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.7.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=3748
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919

grab it here (http://rapidshare.com/files/107703602/x264.819.msvc2005.modified.exe)

[buzzqw]

@ALL

please apply the x264_fix_win_stdin.diff too!

BHH