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. |
|
|
Thread Tools | Search this Thread | Display Modes |
2nd April 2008, 11:04 | #201 | Link |
Registered User
Join Date: Dec 2007
Location: Beijing,China
Posts: 92
|
x264.808.modified.experimental.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.v...093/focus=3748 x264_hrd_pulldown.04_interlace.diff - HRD and pulldown for HD compatibility, updated patch for interlacing http://forum.doom9.org/showthread.ph...19#post1047919 x264_fix_win_stdin.diff http://forum.doom9.org/showthread.ph...65#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 |
3rd April 2008, 10:20 | #202 | Link |
Registered User
Join Date: Apr 2007
Posts: 464
|
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 |
3rd April 2008, 10:44 | #203 | Link | |
Junglist
Join Date: May 2003
Location: Belarus, Minsk
Posts: 298
|
Quote:
so.. why?
__________________
Rule Number 6: Concentrate!!! (c)Hercules, Disney "I like to build planes.... in the air" (c) some ADV. tutorials How to Setup agent-based encoding with x264farm (the easy way) |
|
3rd April 2008, 13:08 | #206 | Link |
Registered User
Join Date: May 2006
Posts: 957
|
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.
__________________
x264 log explained || x264 deblocking how-to preset -> tune -> user set options -> fast first pass -> profile -> level Doom10 - Of course it's better, it's one more. |
3rd April 2008, 21:43 | #208 | Link |
<The VFW Sheep of Death>
Join Date: Dec 2004
Location: Deathly pasture of VFW
Posts: 1,149
|
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...
__________________
Recommended all-in-one stop for x264/GCC needs on Windows: Komisar x264 builds! |
3rd April 2008, 21:48 | #209 | Link |
Mr. Sandman
Join Date: Sep 2003
Location: Haddonfield, IL
Posts: 11,768
|
that's coz there's no revision number in git...
__________________
MPEG-4 ASP Custom Matrices: EQM V1(old), EQM AutoGK Sharpmatrix (aka EQM V2), EQM V3HR (updated 01/10/2004), EQM V3LR, EQM V3ULR (updated 04/02/2005), EQM V3UHR (updated 17/12/2004) and EQM V3EHR (updated 05/10/2004) Info about my ASP matrices. MPEG-4 AVC Custom Matrices: EQM AVC-HR Info about my AVC matrices My x264 builds. Mooo!!! |
3rd April 2008, 21:50 | #210 | Link |
<The VFW Sheep of Death>
Join Date: Dec 2004
Location: Deathly pasture of VFW
Posts: 1,149
|
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?
__________________
Recommended all-in-one stop for x264/GCC needs on Windows: Komisar x264 builds! Last edited by DeathTheSheep; 3rd April 2008 at 21:56. |
4th April 2008, 09:44 | #211 | Link | |
Junglist
Join Date: May 2003
Location: Belarus, Minsk
Posts: 298
|
Quote:
maybe, it would be nice to make such optimisations not only for AQ? (like lame with its presets..)
__________________
Rule Number 6: Concentrate!!! (c)Hercules, Disney "I like to build planes.... in the air" (c) some ADV. tutorials How to Setup agent-based encoding with x264farm (the easy way) |
|
4th April 2008, 16:46 | #212 | Link |
Cyberspace Citizen
Join Date: Nov 2005
Posts: 457
|
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? Last edited by Razorholt; 4th April 2008 at 19:53. |
4th April 2008, 20:07 | #215 | Link |
Registered User
Join Date: Aug 2006
Posts: 2,229
|
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... |
4th April 2008, 20:25 | #216 | Link | |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
Quote:
|
|
4th April 2008, 21:13 | #217 | Link |
Registered User
Join Date: Aug 2006
Posts: 2,229
|
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? Last edited by burfadel; 4th April 2008 at 21:16. |
5th April 2008, 00:43 | #218 | Link | |||
<The VFW Sheep of Death>
Join Date: Dec 2004
Location: Deathly pasture of VFW
Posts: 1,149
|
Mmkay guys, lots of stuff to address:
Quote:
Quote:
Quote:
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... |
|||
5th April 2008, 00:48 | #219 | Link | |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
Quote:
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." |
|
5th April 2008, 00:51 | #220 | Link |
<The VFW Sheep of Death>
Join Date: Dec 2004
Location: Deathly pasture of VFW
Posts: 1,149
|
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?
__________________
Recommended all-in-one stop for x264/GCC needs on Windows: Komisar x264 builds! Last edited by DeathTheSheep; 5th April 2008 at 01:01. |
Tags |
h.264, x264, x264 builds, x264 patches, x264 unofficial builds |
|
|