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 28th January 2008, 04:44   #601  |  Link
DeathTheSheep
<The VFW Sheep of Death>
 
DeathTheSheep's Avatar
 
Join Date: Dec 2004
Location: Deathly pasture of VFW
Posts: 1,149
Does anyone know where I can find 0.46? It seems to have vanished, and I'd like to upgrade from 0.45.

[edit] w007
Code:
-        var += ssd - (sad * sad >> (i?6:8));
+        var += ssd - ((sad/16) * (sad/16));
I win.

Y4yz 4 err0r-ous (0[)3 |=+\X/
__________________
Recommended all-in-one stop for x264/GCC needs on Windows: Komisar x264 builds!

Last edited by DeathTheSheep; 28th January 2008 at 05:29.
DeathTheSheep is offline   Reply With Quote
Old 28th January 2008, 05:41   #602  |  Link
burfadel
Registered User
 
Join Date: Aug 2006
Posts: 2,229
Anyone else notice that in general, the higher the input resolution he lower the sensitivity required? So a sensitivity of say, 9 is good for 1920x1080, whereas for much lower resolutions a 16 or 17 etc is required? Also the strength affects whether a higher or lower sensitivity is more beneficial.

That makes a fixed sensitivity almost impossible, maybe an automatic sensitivity that can adjust to the input resolution and AQ strength?

Last edited by burfadel; 28th January 2008 at 05:44. Reason: Correction
burfadel is offline   Reply With Quote
Old 28th January 2008, 05:42   #603  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,666
Quote:
Originally Posted by DeathTheSheep View Post
Does anyone know where I can find 0.46? It seems to have vanished, and I'd like to upgrade from 0.45.

[edit] w007
Code:
-        var += ssd - (sad * sad >> (i?6:8));
+        var += ssd - ((sad/16) * (sad/16));
I win.

Y4yz 4 err0r-ous (0[)3 |=+\X/
That will fail because i?6:8 compensates for the different sizes of the SSDs in different planes, while your code does not.
Quote:
Originally Posted by burfadel View Post
Anyone else notice that in general, the higher the input resolution he lower the sensitivity required? So a sensitivity of say, 9 is good for 1920x1080, whereas for much lower resolutions a 16 or 17 etc is required?

That makes a fixed sensitivity almost impossible, maybe an automatic sensitivity that can adjust to the input resolution?
This reflects the fact that lower resolutions generally have higher average block variances, since there are more edges and fewer large areas of flat detail.
Dark Shikari is offline   Reply With Quote
Old 28th January 2008, 05:44   #604  |  Link
DeathTheSheep
<The VFW Sheep of Death>
 
DeathTheSheep's Avatar
 
Join Date: Dec 2004
Location: Deathly pasture of VFW
Posts: 1,149
Do you have a link to 0.46?

If not, how do I add this compensation?
__________________
Recommended all-in-one stop for x264/GCC needs on Windows: Komisar x264 builds!
DeathTheSheep is offline   Reply With Quote
Old 28th January 2008, 05:52   #605  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,666
Quote:
Originally Posted by DeathTheSheep View Post
Do you have a link to 0.46?

If not, how do I add this compensation?
Divide by 8 for chroma planes, 16 for luma planes.
Dark Shikari is offline   Reply With Quote
Old 28th January 2008, 05:58   #606  |  Link
DeathTheSheep
<The VFW Sheep of Death>
 
DeathTheSheep's Avatar
 
Join Date: Dec 2004
Location: Deathly pasture of VFW
Posts: 1,149
Divide which part? The whole expression, the (sad/16)^2 chunk only, or...? And how can I test with a neat little "colon question mark" if (like something below)?
Code:
var += ssd - ((sad/16) * (sad/16)) / (i?8:16);
Is this even the right syntax for such a trick? And is there a neat bitshift >> or whatnot for "divide by 16"? Admittedly, I know very little when it comes to syntax/speed notation.
__________________
Recommended all-in-one stop for x264/GCC needs on Windows: Komisar x264 builds!

Last edited by DeathTheSheep; 28th January 2008 at 06:14.
DeathTheSheep is offline   Reply With Quote
Old 28th January 2008, 06:03   #607  |  Link
burfadel
Registered User
 
Join Date: Aug 2006
Posts: 2,229
Quote:
Originally Posted by Dark Shikari View Post
This reflects the fact that lower resolutions generally have higher average block variances, since there are more edges and fewer large areas of flat detail.
I found that:
--aq-strength 0.3 --aq-sensitivity 16.5
Seems to maintain an almost identical file size to not having AQ on for both very low res and Full HD encodes, although strength 0.3 is very little. With even a strength of 0.6 the difference is too great between low and high resolutions to the normal, non AQ builds. - that is, what works for high res doesn't work for low res and vice versa.
burfadel is offline   Reply With Quote
Old 28th January 2008, 06:45   #608  |  Link
akupenguin
x264 developer
 
akupenguin's Avatar
 
Join Date: Sep 2004
Posts: 2,392
Quote:
Originally Posted by DeathTheSheep View Post
Code:
var += ssd - ((sad/16) * (sad/16)) / (i?8:16);
No, and even if you corrected it it would just bring back the imprecision.
The compensation would be:
Code:
-    unsigned int var=0
+    unsigned int var=42
for some value of 42. Or better yet, add it after the computation, so that the satd shortcut still works.

Last edited by akupenguin; 28th January 2008 at 06:49.
akupenguin is offline   Reply With Quote
Old 28th January 2008, 12:09   #609  |  Link
CruNcher
Registered User
 
CruNcher's Avatar
 
Join Date: Apr 2002
Location: Germany
Posts: 4,926
hmm is it possible that the Visual Quality decreased? i see ringing now @ Face Edges (something i saw last time with ASP but not used to see with H.264) aq-strength of 1.0 only lower strength avoid this now.
__________________
all my compares are riddles so please try to decipher them yourselves :)

It is about Time

Join the Revolution NOW before it is to Late !

http://forum.doom9.org/showthread.php?t=168004

Last edited by CruNcher; 28th January 2008 at 12:14.
CruNcher is offline   Reply With Quote
Old 28th January 2008, 12:29   #610  |  Link
burfadel
Registered User
 
Join Date: Aug 2006
Posts: 2,229
Quote:
Originally Posted by CruNcher View Post
hmm is it possible that the Visual Quality decreased? i see ringing now @ Face Edges (something i saw last time with ASP but not used to see with H.264) aq-strength of 1.0 only lower strength avoid this now.
Have you checked the file size with and without AQ? I found at a strength of 1 NO senstivity suited all scenarios. There was a very large difference in terms of comparing it with its non-AQ counterpart between HD and resolution such as 512x384. What sensitivity at that strength works for one DOES NOT work for the other.

Even at a strength of 0.6, the sensitivities made a large difference with different resolutions. The only figure that worked perfectly for low and high resolutions for me, was strength 0.3 and sensitivity 16.5. (16 was giving a slightly lower file size, 16.5 fractionally larger, which is ok!).

It did help in the dark areas still, although its very weak at those settings, although I'd have to agree with you about strength 1, it did make the faces etc a bit less in terms of quality. That doesn't occur with strength 0.3. It was as if I raised the CRF in a way... Problem is to have an ideal quality in the dark areas, taking bits away from bright areas will lower its quality, and it seems having a strong AQ takes too much away from the bright areas. I'm not even sure that it maintains a CRF of say 24, with aq enabled at strength 1, it lowers the bright area quality and the filesize can become way undersized - or oversized!

Try strength 0.3 and sensitivity 16.5 and see whether that helps you like it did with me - and its ideal for both very low res and full HD

Last edited by burfadel; 28th January 2008 at 12:32.
burfadel is offline   Reply With Quote
Old 29th January 2008, 02:37   #611  |  Link
DeathTheSheep
<The VFW Sheep of Death>
 
DeathTheSheep's Avatar
 
Join Date: Dec 2004
Location: Deathly pasture of VFW
Posts: 1,149
Since the one posted here earlier wasn't at all valid, here's my updated version:
Updated me-prepass (unoptimized):
Code:
--- common/common.c	Sun Jan 27 13:39:08 2008
+++ common/common.c	Sun Jan 27 13:39:08 2008
@@ -441,6 +441,8 @@
         p->analyse.i_mv_range_thread = atoi(value);
     OPT2("subme", "subq")
         p->analyse.i_subpel_refine = atoi(value);
+    OPT2("me-prepass", "meprepass")
+        p->analyse.i_me_prepass = atobool(value);
     OPT("bime")
         p->analyse.b_bidir_me = atobool(value);
     OPT("chroma-me")
@@ -879,6 +881,7 @@
     s += sprintf( s, " analyse=%#x:%#x", p->analyse.intra, p->analyse.inter );
     s += sprintf( s, " me=%s", x264_motion_est_names[ p->analyse.i_me_method ] );
     s += sprintf( s, " subme=%d", p->analyse.i_subpel_refine );
+    s += sprintf( s, " me-prepass=%d", p->analyse.i_me_prepass );
     s += sprintf( s, " brdo=%d", p->analyse.b_bframe_rdo );
     s += sprintf( s, " mixed_ref=%d", p->analyse.b_mixed_references );
     s += sprintf( s, " me_range=%d", p->analyse.i_me_range );
--- x264.c	Sun Jan 27 13:39:08 2008
+++ x264.c	Sun Jan 27 13:39:08 2008
@@ -232,7 +232,8 @@
     H1( "      --mvrange-thread <int>  Minimum buffer between threads [-1 (auto)]\n" );
     H0( "  -m, --subme <integer>       Subpixel motion estimation and partition\n"
         "                                  decision quality: 1=fast, 7=best. [%d]\n", defaults->analyse.i_subpel_refine );
-    H0( "      --b-rdo                 RD based mode decision for B-frames. Requires subme 6.\n" );
+    H0( "      --me-prepass            Run an ME prepass on predictors.  Requires subme 3 or higher.\n");
+    H0( "      --b-rdo                 RD based mode decision for B-frames. Requires subme 6 or higher.\n" );
     H0( "      --mixed-refs            Decide references on a per partition basis\n" );
     H1( "      --no-chroma-me          Ignore chroma in motion estimation\n" );
     H1( "      --bime                  Jointly optimize both MVs in B-frames\n" );
@@ -398,6 +399,7 @@
             { "mvrange", required_argument, NULL, 0 },
             { "mvrange-thread", required_argument, NULL, 0 },
             { "subme",   required_argument, NULL, 'm' },
+            { "me-prepass", no_argument,    NULL, 0 },
             { "b-rdo",   no_argument,       NULL, 0 },
             { "mixed-refs", no_argument,    NULL, 0 },
             { "no-chroma-me", no_argument,  NULL, 0 },
--- x264.h	Sun Jan 27 13:39:08 2008
+++ x264.h	Sun Jan 27 13:39:08 2008
@@ -220,6 +220,7 @@
         int          i_mv_range; /* maximum length of a mv (in pixels). -1 = auto, based on level */
         int          i_mv_range_thread; /* minimum space between threads. -1 = auto, based on number of threads. */
         int          i_subpel_refine; /* subpixel motion estimation quality */
+        int          i_me_prepass; /* run an ME prepass on predictors */
         int          b_bidir_me; /* jointly optimize both MVs in B-frames */
         int          b_chroma_me; /* chroma ME for subpel and mode decision in P-frames */
         int          b_bframe_rdo; /* RD based mode decision for B-frames */
--- encoder/me.c	Sun Jan 27 13:39:08 2008
+++ encoder/me.c	Sun Jan 27 20:25:50 2008
@@ -69,6 +69,23 @@
     COPY3_IF_LT( bpred_cost, cost, bpred_mx, mx, bpred_my, my ); \
 }
 
+#define COST_MV_HPEL2( mx, my, cost ) \
+{ \
+    int stride = 16; \
+    uint8_t *src = h->mc.get_ref( pix, &stride, m->p_fref, m->i_stride[0], mx, my, bw, bh ); \
+        cost = h->pixf.fpelcmp[i_pixel]( m->p_fenc[0], FENC_STRIDE, src, stride ) \
+             + p_cost_mvx[ mx ] + p_cost_mvy[ my ]; \
+}
+
+#define COST_MV_HPEL3( mx, my) \
+{ \
+    int stride = 16; \
+    uint8_t *src = h->mc.get_ref( pix, &stride, m->p_fref, m->i_stride[0], mx, my, bw, bh ); \
+    int cost = h->pixf.fpelcmp[i_pixel]( m->p_fenc[0], FENC_STRIDE, src, stride ) \
+             + p_cost_mvx[ mx ] + p_cost_mvy[ my ]; \
+    COPY3_IF_LT( bestcost, cost, bestx, mx, besty, my ); \
+}
+
 #define COST_MV_X3_DIR( m0x, m0y, m1x, m1y, m2x, m2y, costs )\
 {\
     uint8_t *pix_base = p_fref + bmx + bmy*m->i_stride[0];\
@@ -171,8 +188,13 @@
     int mv_y_min = h->mb.mv_min_fpel[1];
     int mv_x_max = h->mb.mv_max_fpel[0];
     int mv_y_max = h->mb.mv_max_fpel[1];
+    int mv_x_min4 = h->mb.mv_min_fpel[0]<<2;
+    int mv_y_min4 = h->mb.mv_min_fpel[1]<<2;
+    int mv_x_max4 = h->mb.mv_max_fpel[0]<<2;
+    int mv_y_max4 = h->mb.mv_max_fpel[1]<<2;
 
 #define CHECK_MVRANGE(mx,my) ( mx >= mv_x_min && mx <= mv_x_max && my >= mv_y_min && my <= mv_y_max )
+#define CHECK_MVRANGE4(mx,my) ( mx >= mv_x_min4 && mx <= mv_x_max4 && my >= mv_y_min4 && my <= mv_y_max4 )
 
     const int16_t *p_cost_mvx = m->p_cost_mv - m->mvp[0];
     const int16_t *p_cost_mvy = m->p_cost_mv - m->mvp[1];
@@ -183,19 +205,88 @@
     pmy = ( bmy + 2 ) >> 2;
     bcost = COST_MAX;
 
-    /* try extra predictors if provided */
-    if( h->mb.i_subpel_refine >= 3 )
-    {
-        COST_MV_HPEL( bmx, bmy );
-        for( i = 0; i < i_mvc; i++ )
+     /* try extra predictors if provided */
+     if( h->mb.i_subpel_refine >= 3 )
+     {
+         COST_MV_HPEL( bmx, bmy );
+        if(!h->param.analyse.i_me_prepass)
+         {
+            for( i = 0; i < i_mvc; i++ )
+            {
+                 const int mx = x264_clip3( mvc[i][0], mv_x_min*4, mv_x_max*4 );
+                 const int my = x264_clip3( mvc[i][1], mv_y_min*4, mv_y_max*4 );
+                 if( mx != bpred_mx || my != bpred_my )
+                     COST_MV_HPEL( mx, my );
+            }
+        }
+        else
         {
-            int mx = mvc[i][0];
-            int my = mvc[i][1];
-            if( (mx | my) && ((mx-bmx) | (my-bmy)) )
+            for( i = 0; i < i_mvc; i++ )
             {
-                mx = x264_clip3( mx, mv_x_min*4, mv_x_max*4 );
-                my = x264_clip3( my, mv_y_min*4, mv_y_max*4 );
-                COST_MV_HPEL( mx, my );
+                const int mx = x264_clip3( mvc[i][0], mv_x_min*4, mv_x_max*4 );
+                const int my = x264_clip3( mvc[i][1], mv_y_min*4, mv_y_max*4 );
+                int doSearch = 1;
+                int j;
+                for(j = 0; j < i; j++)
+                {
+                    if(mvc[i][0] == mvc[j][0] && mvc[i][1] == mvc[j][1]) doSearch = 0;
+                }
+                if( ( mx != bpred_mx || my != bpred_my ) && doSearch)
+                {
+                    int bestcost;
+                    int bestx = mx;
+                    int besty = my;
+                    COST_MV_HPEL2( mx, my, bestcost );
+                    COPY3_IF_LT( bpred_cost, bestcost, bpred_mx, bestx, bpred_my, besty );
+                    if(bestcost < 2*bpred_cost)
+                    {
+                        int n;
+                        int dir = -2;
+                        COST_MV_HPEL2(bestx-4,besty,costs[0]);
+                        COST_MV_HPEL2(bestx-2,besty+4,costs[1]);
+                        COST_MV_HPEL2(bestx+2,besty+4,costs[2]);
+                        COST_MV_HPEL2(bestx+4,besty,costs[3]);
+                        COST_MV_HPEL2(bestx+2,besty-4,costs[4]);
+                        COST_MV_HPEL2(bestx-2,besty-4,costs[5]);
+                        COPY2_IF_LT( bestcost, costs[0], dir, 0 );
+                        COPY2_IF_LT( bestcost, costs[1], dir, 1 );
+                        COPY2_IF_LT( bestcost, costs[2], dir, 2 );
+                        COPY2_IF_LT( bestcost, costs[3], dir, 3 );
+                        COPY2_IF_LT( bestcost, costs[4], dir, 4 );
+                        COPY2_IF_LT( bestcost, costs[5], dir, 5 );
+                        if( dir != -2 )
+                        {
+                            static const int hex2[8][2] = {{-2,-4}, {-4,0}, {-2,4}, {2,4}, {4,0}, {2,-4}, {-2,-4}, {-4,0}};
+                            bestx += hex2[dir+1][0];
+                            besty += hex2[dir+1][1];
+                            for( n = 1; n < i_me_range && CHECK_MVRANGE4(bestx, besty); n++ )
+                            {
+                                static const int mod6[8] = {5,0,1,2,3,4,5,0};
+                                const int odir = mod6[dir+1];
+                                COST_MV_HPEL2(hex2[odir+0][0]+bestx,hex2[odir+0][1]+besty,costs[0]);
+                                COST_MV_HPEL2(hex2[odir+1][0]+bestx,hex2[odir+1][1]+besty,costs[1]);
+                                COST_MV_HPEL2(hex2[odir+2][0]+bestx,hex2[odir+2][1]+besty,costs[2]);
+                                dir = -2;
+                                COPY2_IF_LT( bestcost, costs[0], dir, odir-1 );
+                                COPY2_IF_LT( bestcost, costs[1], dir, odir   );
+                                COPY2_IF_LT( bestcost, costs[2], dir, odir+1 );
+                                if( dir == -2 )
+                                    break;
+                                bestx += hex2[dir+1][0];
+                                besty += hex2[dir+1][1];
+                            }
+                        }
+                        COST_MV_HPEL3(bestx+2,besty-2);
+                        COST_MV_HPEL3(bestx+2,besty);
+                        COST_MV_HPEL3(bestx+2,besty+2);
+                        COST_MV_HPEL3(bestx,besty-2);
+                        COST_MV_HPEL3(bestx,besty+2);
+                        COST_MV_HPEL3(bestx-2,besty-2);
+                        COST_MV_HPEL3(bestx-2,besty);
+                        COST_MV_HPEL3(bestx-2,besty+2);
+                        COPY3_IF_LT(bpred_cost,bestcost,bpred_mx,bestx,bpred_my,besty);
+                    }
+                }
             }
         }
         bmx = ( bpred_mx + 2 ) >> 2;
Quote:
Originally Posted by akupenguin
Or better yet, add it after the computation, so that the satd shortcut still works.
After the computation in line 69, like this?
Code:
var += ssd - (sad * sad >> (i?6:8)) + k; 

or just:

        var += ssd - (sad * sad >> (i?6:8));
        // SATD to represent the block's overall complexity (bit cost) for intra encoding.
        // exclude the DC coef, because nothing short of an actual intra prediction will estimate DC cost.
        if( var && satd )
            *satd += h->pixf.satd[pix](flat, 0, h->fenc->plane[i]+offset, stride) - sad/2;
+       var += 42;
    }
    return var;
where k=42, an arbitrary constant?

[edit]
Your code above (var=42) made almost no difference in quality, SSIM, or QP distribution, and certainly didn't reinstate the behavior of .45, for better or for worse mathematically, you might say, though visually worse in my case. At constant QP, the bitrate/threshold ratio also remains the same; the algorithm still requires a vastly lower threshold to reach the same bitrate as .45 at less SSIM and quality--same as normal .47--a sure sign it's not doing what it's intended to.

At the risk of reintroducing imprecision (and what tremendously vast imprecision it must be to produce what in some cases amounts to such polar opposite bit distributions), I still seek to recreate a rounding/distribution similar to that present in .45, but perhaps, if possible, more mathematically accurate behavior.
__________________
Recommended all-in-one stop for x264/GCC needs on Windows: Komisar x264 builds!

Last edited by DeathTheSheep; 29th January 2008 at 04:02.
DeathTheSheep is offline   Reply With Quote
Old 29th January 2008, 17:07   #612  |  Link
sysKin
Registered User
 
sysKin's Avatar
 
Join Date: Jun 2002
Location: Adelaide, Australia
Posts: 1,167
Lol, as much as 42 is the answer to everything, it's not the answer here. It's in the order of several thousands I'm guessing.
__________________
Visit #xvid or #x264 at irc.freenode.net
sysKin is offline   Reply With Quote
Old 29th January 2008, 18:47   #613  |  Link
zbutsam
Registered User
 
Join Date: May 2004
Posts: 5
Quote:
Originally Posted by CruNcher View Post
hmm is it possible that the Visual Quality decreased? i see ringing now @ Face Edges (something i saw last time with ASP but not used to see with H.264) aq-strength of 1.0 only lower strength avoid this now.
I have to report the same thing. I did a 2-pass encode with aq-strength at 1.0 and default sensitivity and in the video with AQ enabled there was a lot more ringing around people's faces than the one without AQ. Perhaps the bitrate was too low for my source and where the No-AQ version became blurred, the AQ version produced ringing.
zbutsam is offline   Reply With Quote
Old 29th January 2008, 18:51   #614  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,666
Quote:
Originally Posted by zbutsam View Post
I have to report the same thing. I did a 2-pass encode with aq-strength at 1.0 and default sensitivity and in the video with AQ enabled there was a lot more ringing around people's faces than the one without AQ. Perhaps the bitrate was too low for my source and where the No-AQ version became blurred, the AQ version produced ringing.
AQ 1.0 is too strong. Use the recommended settings: strength 0.5, sensitivity 13, qcomp 1.
Dark Shikari is offline   Reply With Quote
Old 29th January 2008, 19:54   #615  |  Link
DeathTheSheep
<The VFW Sheep of Death>
 
DeathTheSheep's Avatar
 
Join Date: Dec 2004
Location: Deathly pasture of VFW
Posts: 1,149
Quote:
Originally Posted by sysKin View Post
Lol, as much as 42 is the answer to everything, it's not the answer here. It's in the order of several thousands I'm guessing.
Hmm, true that. But after all, I've tried on the order of up to 50000 already to limited success. Very high values do skew QP distribution indeed (throwing in any sizable constant into any rate control mechanism would almost have to), but trying to guess at some random, arbitrary constant isn't quite optimal unless I know exactly what constant .45 did introduce, and how exactly that supposed "constant" actually varies per frame/decision.
__________________
Recommended all-in-one stop for x264/GCC needs on Windows: Komisar x264 builds!
DeathTheSheep is offline   Reply With Quote
Old 29th January 2008, 19:55   #616  |  Link
zbutsam
Registered User
 
Join Date: May 2004
Posts: 5
Quote:
Originally Posted by Dark Shikari View Post
AQ 1.0 is too strong. Use the recommended settings: strength 0.5, sensitivity 13, qcomp 1.


I tried again with the settings you recommended and everything looks in order now.
Could you please add these new recommended settings on the first post of this thread?
zbutsam is offline   Reply With Quote
Old 29th January 2008, 20:07   #617  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,666
Quote:
Originally Posted by zbutsam View Post


I tried again with the settings you recommended and everything looks in order now.
Could you please add these new recommended settings on the first post of this thread?
Done.
Dark Shikari is offline   Reply With Quote
Old 29th January 2008, 22:12   #618  |  Link
Poopoo
Registered User
 
Join Date: Nov 2007
Posts: 65
Can you please tell me where I can get this SSIM thingy ?
Thanks !
Poopoo is offline   Reply With Quote
Old 29th January 2008, 22:15   #619  |  Link
Sagekilla
x264aholic
 
Join Date: Jul 2007
Location: New York
Posts: 1,752
SSIM calculation is built into x264. In fact, x264 calculates it by default. You have to use --no-ssim to disable it. When your encode finishes, it'll display the SSIM along with a bunch of other data.
Sagekilla is offline   Reply With Quote
Old 30th January 2008, 05:30   #620  |  Link
Yoshiyuki Blade
Novice x264 User
 
Yoshiyuki Blade's Avatar
 
Join Date: Dec 2006
Location: California
Posts: 169
Quote:
Originally Posted by Dark Shikari View Post
AQ 1.0 is too strong. Use the recommended settings: strength 0.5, sensitivity 13, qcomp 1.
I've tried several different levels of AQ strength and sensitivity, but I still can't seem to reproduce the same quality as I did with v0.45 whether its in CRF mode or 2-pass (anime). High strength and high sensitivity is the closest I've gotten, but the overall visual quality turns out so bad, it's not a worthwhile tradeoff anymore. With v0.45 I used strength 1.0, sensitivity 20, and qcomp 0.6, and the improvement in dark areas was definitely worth the cost of some overall quality. It didn't look nearly as bad as it does now.

Using the current recommended settings (strength 0.5, sensitivity 13-15, qcomp 1), the quality is good, but dark areas don't get addressed very well if at all.

At the moment, nothing looks remotely satisfying unless I really up the bitrates (about 500 megabytes for 25-minute footage), in which case it will look good across the board. Perhaps this version of AQ is more optimized for real-life footage?

However, before I feel confident on my experiences, I'm gonna have to do another encode with v0.45. Be back in like 10 hours with my experiences lol .
Yoshiyuki Blade is offline   Reply With Quote
Reply

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 17:44.


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