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.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 AVC / H.264

Reply
 
Thread Tools Search this Thread Display Modes
Old 5th April 2008, 00:53   #221  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,666
Quote:
Originally Posted by DeathTheSheep View Post
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
Quote:
Originally Posted by DeathTheSheep View Post
So much so I'm not re-releasing 0.46, as I said.
Good that's cleared up then.
Dark Shikari is offline   Reply With Quote
Old 5th April 2008, 00:56   #222  |  Link
DeathTheSheep
<The VFW Sheep of Death>
 
DeathTheSheep's Avatar
 
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!
DeathTheSheep is offline   Reply With Quote
Old 5th April 2008, 01:05   #223  |  Link
Razorholt
Cyberspace Citizen
 
Razorholt's Avatar
 
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
Razorholt is offline   Reply With Quote
Old 5th April 2008, 01:10   #224  |  Link
DeathTheSheep
<The VFW Sheep of Death>
 
DeathTheSheep's Avatar
 
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!
DeathTheSheep is offline   Reply With Quote
Old 5th April 2008, 01:10   #225  |  Link
Razorholt
Cyberspace Citizen
 
Razorholt's Avatar
 
Join Date: Nov 2005
Posts: 457
So, SSIM + frames comparison will work or not? - I'm talking about comparing settings.
Razorholt is offline   Reply With Quote
Old 5th April 2008, 01:13   #226  |  Link
DeathTheSheep
<The VFW Sheep of Death>
 
DeathTheSheep's Avatar
 
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!
DeathTheSheep is offline   Reply With Quote
Old 5th April 2008, 01:33   #227  |  Link
Razorholt
Cyberspace Citizen
 
Razorholt's Avatar
 
Join Date: Nov 2005
Posts: 457
No no, I'm talking about comparing different settings using VAQ2 exclusively. Oh well, I'll stick to frames + SSIM and that's it.
Razorholt is offline   Reply With Quote
Old 5th April 2008, 06:24   #228  |  Link
burfadel
Registered User
 
Join Date: Aug 2006
Posts: 2,229
So variable fast-pskip, so that is only applies to non-flat areas wouldn't actually work?!
burfadel is offline   Reply With Quote
Old 5th April 2008, 18:58   #229  |  Link
lexor
Registered User
 
Join Date: Jan 2004
Posts: 849
Quote:
Originally Posted by Razorholt View Post
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.
__________________
Geforce GTX 260
Windows 7, 64bit, Core i7
MPC-HC, Foobar2000

Last edited by lexor; 5th April 2008 at 19:23.
lexor is offline   Reply With Quote
Old 5th April 2008, 20:04   #230  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,666
Quote:
Originally Posted by lexor View Post
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.
Dark Shikari is offline   Reply With Quote
Old 5th April 2008, 20:09   #231  |  Link
DeathTheSheep
<The VFW Sheep of Death>
 
DeathTheSheep's Avatar
 
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!
DeathTheSheep is offline   Reply With Quote
Old 5th April 2008, 20:27   #232  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,666
Quote:
Originally Posted by DeathTheSheep View Post
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.

Last edited by Dark Shikari; 5th April 2008 at 20:32.
Dark Shikari is offline   Reply With Quote
Old 5th April 2008, 20:46   #233  |  Link
DeathTheSheep
<The VFW Sheep of Death>
 
DeathTheSheep's Avatar
 
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!
DeathTheSheep is offline   Reply With Quote
Old 5th April 2008, 21:06   #234  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,666
Quote:
Originally Posted by DeathTheSheep View Post
So if I disable variance weighting, will this likely go up or down with VAQ?
Try and see
Dark Shikari is offline   Reply With Quote
Old 5th April 2008, 21:35   #235  |  Link
lexor
Registered User
 
Join Date: Jan 2004
Posts: 849
Quote:
Originally Posted by Dark Shikari View Post
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.
__________________
Geforce GTX 260
Windows 7, 64bit, Core i7
MPC-HC, Foobar2000

Last edited by lexor; 5th April 2008 at 21:39.
lexor is offline   Reply With Quote
Old 6th April 2008, 14:24   #236  |  Link
fields_g
x264... Brilliant!
 
Join Date: Mar 2005
Location: Rockville, MD
Posts: 167
Quote:
Originally Posted by Razorholt View Post
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.
fields_g is offline   Reply With Quote
Old 6th April 2008, 18:23   #237  |  Link
IgorC
Registered User
 
Join Date: Apr 2004
Posts: 1,315
I totally agree with you.
Public ABX is optimal way to go when test psycho visual enhancements.
There was application MSU ABX for video.
IgorC is offline   Reply With Quote
Old 6th April 2008, 20:55   #238  |  Link
lexor
Registered User
 
Join Date: Jan 2004
Posts: 849
Quote:
Originally Posted by IgorC View Post
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.
__________________
Geforce GTX 260
Windows 7, 64bit, Core i7
MPC-HC, Foobar2000

Last edited by lexor; 6th April 2008 at 20:58.
lexor is offline   Reply With Quote
Old 7th April 2008, 02:14   #239  |  Link
fields_g
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:
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.
fields_g is offline   Reply With Quote
Old 10th April 2008, 11:30   #240  |  Link
MythCreator
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
MythCreator is offline   Reply With Quote
Reply

Tags
h.264, x264, x264 builds, x264 patches, x264 unofficial builds

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 07:47.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.