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 |
5th April 2008, 00:53 | #221 | Link |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
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
Good that's cleared up then. |
5th April 2008, 00:56 | #222 | Link |
<The VFW Sheep of Death>
Join Date: Dec 2004
Location: Deathly pasture of VFW
Posts: 1,149
|
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.
__________________
Recommended all-in-one stop for x264/GCC needs on Windows: Komisar x264 builds! |
5th April 2008, 01:05 | #223 | Link |
Cyberspace Citizen
Join Date: Nov 2005
Posts: 457
|
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 |
5th April 2008, 01:10 | #224 | Link |
<The VFW Sheep of Death>
Join Date: Dec 2004
Location: Deathly pasture of VFW
Posts: 1,149
|
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.
__________________
Recommended all-in-one stop for x264/GCC needs on Windows: Komisar x264 builds! |
5th April 2008, 01:13 | #226 | Link |
<The VFW Sheep of Death>
Join Date: Dec 2004
Location: Deathly pasture of VFW
Posts: 1,149
|
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?
__________________
Recommended all-in-one stop for x264/GCC needs on Windows: Komisar x264 builds! |
5th April 2008, 18:58 | #229 | Link | |
Registered User
Join Date: Jan 2004
Posts: 849
|
Quote:
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.
__________________
Geforce GTX 260 Windows 7, 64bit, Core i7 MPC-HC, Foobar2000 Last edited by lexor; 5th April 2008 at 19:23. |
|
5th April 2008, 20:04 | #230 | Link | |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
Quote:
With P/B frames, one also has to look at the size of the last I-frame and recent frames, too. |
|
5th April 2008, 20:09 | #231 | Link |
<The VFW Sheep of Death>
Join Date: Dec 2004
Location: Deathly pasture of VFW
Posts: 1,149
|
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??!
__________________
Recommended all-in-one stop for x264/GCC needs on Windows: Komisar x264 builds! |
5th April 2008, 20:27 | #232 | Link | |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
Quote:
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. Last edited by Dark Shikari; 5th April 2008 at 20:32. |
|
5th April 2008, 20:46 | #233 | Link |
<The VFW Sheep of Death>
Join Date: Dec 2004
Location: Deathly pasture of VFW
Posts: 1,149
|
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?
__________________
Recommended all-in-one stop for x264/GCC needs on Windows: Komisar x264 builds! |
5th April 2008, 21:35 | #235 | Link | |
Registered User
Join Date: Jan 2004
Posts: 849
|
Quote:
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.
__________________
Geforce GTX 260 Windows 7, 64bit, Core i7 MPC-HC, Foobar2000 Last edited by lexor; 5th April 2008 at 21:39. |
|
6th April 2008, 14:24 | #236 | Link | |
x264... Brilliant!
Join Date: Mar 2005
Location: Rockville, MD
Posts: 167
|
Quote:
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. |
|
6th April 2008, 20:55 | #238 | Link | |
Registered User
Join Date: Jan 2004
Posts: 849
|
Quote:
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.
__________________
Geforce GTX 260 Windows 7, 64bit, Core i7 MPC-HC, Foobar2000 Last edited by lexor; 6th April 2008 at 20:58. |
|
7th April 2008, 02:14 | #239 | Link | |
x264... Brilliant!
Join Date: Mar 2005
Location: Rockville, MD
Posts: 167
|
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. I think your concern also connects to the important note found on the page: Quote:
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. |
|
10th April 2008, 11:30 | #240 | Link |
Registered User
Join Date: Dec 2007
Location: Beijing,China
Posts: 92
|
x264.815.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 |
Tags |
h.264, x264, x264 builds, x264 patches, x264 unofficial builds |
Thread Tools | Search this Thread |
Display Modes | |
|
|