[x264-devel] speed & time
mm1201 at mail.ustc.edu.cn
mm1201 at mail.ustc.edu.cn
Fri Nov 14 03:19:00 CET 2014
Thanks for help，I hava solved it with "x264_param_default_preset()"
> -----原始邮件-----
> 发件人: x264-devel-request at videolan.org
> 发送时间: 2014-11-13 22:42:33 (星期四)
> 收件人: x264-devel at videolan.org
> 抄送:
> 主题: x264-devel Digest, Vol 90, Issue 10
>
> Send x264-devel mailing list submissions to
> x264-devel at videolan.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mailman.videolan.org/listinfo/x264-devel
> or, via email, send a message with subject or body 'help' to
> x264-devel-request at videolan.org
>
> You can reach the person managing the list at
> x264-devel-owner at videolan.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of x264-devel digest..."
>
>
> Today's Topics:
>
> 1. speed & time (mm1201 at mail.ustc.edu.cn)
> 2. Re: speed & time (James Darnley)
> 3. Re: x264_encoder_encode too slow (mm1201 at mail.ustc.edu.cn)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 13 Nov 2014 21:31:51 +0800 (GMT+08:00)
> From: mm1201 at mail.ustc.edu.cn
> To: x264-devel <x264-devel at videolan.org>
> Subject: [x264-devel] speed & time
> Message-ID:
> <4356e136.211a0.149a95a5a57.Coremail.mm1201 at mail.ustc.edu.cn>
> Content-Type: text/plain; charset="utf-8"
>
> How fast can your program run?In mine,it cost nearly 2s to encode one frame.Is that normal?I'm confused,someone help me out.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20141113/7da03606/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 13 Nov 2014 14:44:06 +0100
> From: James Darnley <james.darnley at gmail.com>
> To: Mailing list for x264 developers <x264-devel at videolan.org>
> Subject: Re: [x264-devel] speed & time
> Message-ID: <5464B5A6.7080600 at gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On 2014-11-13 14:31, mm1201 at mail.ustc.edu.cn wrote:
> > How fast can your program run?In mine,it cost nearly 2s to encode one
> > frame.Is that normal?I'm confused,someone help me out.
>
> Usually, 2 seconds per frame is not normal. However x264 can run from
> blazingly fast to molasses slow depends on your settings, hardware, and
> video input. You have told use nothing about any of these three.
>
> Are you on x86? Did you compile with assembly? Did you compile with
> threads? What sort of video are you encoding? What settings are you using?
>
>
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 603 bytes
> Desc: OpenPGP digital signature
> URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20141113/5d868289/attachment-0001.sig>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 13 Nov 2014 22:42:22 +0800 (GMT+08:00)
> From: mm1201 at mail.ustc.edu.cn
> To: x264-devel at videolan.org
> Subject: Re: [x264-devel] x264_encoder_encode too slow
> Message-ID:
> <5c10d5b3.21597.149a99ae8f5.Coremail.mm1201 at mail.ustc.edu.cn>
> Content-Type: text/plain; charset=UTF-8
>
>
> It works,thank you a lot,interesting!
>
> > -----????-----
> > ???: x264-devel-request at videolan.org
> > ????: 2014-11-13 20:52:05 (???)
> > ???: x264-devel at videolan.org
> > ??:
> > ??: x264-devel Digest, Vol 90, Issue 8
> >
> > Send x264-devel mailing list submissions to
> > x264-devel at videolan.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > https://mailman.videolan.org/listinfo/x264-devel
> > or, via email, send a message with subject or body 'help' to
> > x264-devel-request at videolan.org
> >
> > You can reach the person managing the list at
> > x264-devel-owner at videolan.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of x264-devel digest..."
> >
> >
> > Today's Topics:
> >
> > 1. Re: x264_encoder_encode too slow (Daniel Tisch)
> > 2. Fix VBV (Anton Mitrofanov)
> > 3. Fix VBV with true VFR streams (Anton Mitrofanov)
> > 4. Fix inappropriate instruction use (Anton Mitrofanov)
> > 5. x264asm: warn when inappropriate instruction used in function
> > with specified cpuflags (Anton Mitrofanov)
> > 6. Fix few clang -Wunused-* warnings (Anton Mitrofanov)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Thu, 13 Nov 2014 12:45:31 +0100
> > From: Daniel Tisch <tisch.daniel at gmail.com>
> > To: Mailing list for x264 developers <x264-devel at videolan.org>
> > Subject: Re: [x264-devel] x264_encoder_encode too slow
> > Message-ID:
> > <CA+mv---31KCoT6nh3y6C0f2uftQuK6qjkrEuifkMsCZmbUct0w at mail.gmail.com>
> > Content-Type: text/plain; charset="utf-8"
> >
> > H.264 encoding can be *VERY* slow depending on your settings, source
> > resolution and CPU. Try using presets "ultrafast", "superfast", "veryfast",
> > "faster" or "fast" (in decreasing encoding speed) with
> > x264_param_default_preset (instead of x264_param_default)!
> >
> >
> > Good luck! ;)
> >
> > Cheers,
> >
> > Daniel
> >
> >
> > 2014.11.13. 9:27 ezt ?rta ( <mm1201 at mail.ustc.edu.cn>):
> >
> > > i call x264_encoder_encoed() in my code,and it works,but the problem is
> > > that it runs slow,costs about 2 seconds,i don't know why.Is there anynoe
> > > who ever ran into this,or knows what could cause this?
> > > _______________________________________________
> > > x264-devel mailing list
> > > x264-devel at videolan.org
> > > https://mailman.videolan.org/listinfo/x264-devel
> > >
> > >
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20141113/8577e375/attachment-0001.html>
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Thu, 13 Nov 2014 13:52:02 +0100 (CET)
> > From: git at videolan.org (Anton Mitrofanov)
> > To: x264-devel at videolan.org
> > Subject: [x264-devel] Fix VBV
> > Message-ID: <20141113125202.C8FC9151F6F at albiero.videolan.org>
> > Content-Type: text/plain; charset=UTF-8
> >
> > x264 | branch: master | Anton Mitrofanov <BugMaster at narod.ru> | Mon Sep 1 22:45:00 2014 +0400| [b36d44c68cddff00c5b6de1e6cb6a86c1af2cbfc] | committer: Fiona Glaser
> >
> > Fix VBV
> >
> > > http://git.videolan.org/gitweb.cgi/x264.git/?a=commit;h=b36d44c68cddff00c5b6de1e6cb6a86c1af2cbfc
> > ---
> >
> > encoder/ratecontrol.c | 27 ++++++++++++++++-----------
> > 1 file changed, 16 insertions(+), 11 deletions(-)
> >
> > diff --git a/encoder/ratecontrol.c b/encoder/ratecontrol.c
> > index f71eb5f..8893c1f 100644
> > --- a/encoder/ratecontrol.c
> > +++ b/encoder/ratecontrol.c
> > @@ -2255,32 +2255,31 @@ static double clip_qscale( x264_t *h, int pict_type, double q )
> > /* Now a hard threshold to make sure the frame fits in VBV.
> > * This one is mostly for I-frames. */
> > double bits = predict_size( &rcc->pred[h->sh.i_type], q, rcc->last_satd );
> > - double qf = 1.0;
> > /* For small VBVs, allow the frame to use up the entire VBV. */
> > double max_fill_factor = h->param.rc.i_vbv_buffer_size >= 5*h->param.rc.i_vbv_max_bitrate / rcc->fps ? 2 : 1;
> > /* For single-frame VBVs, request that the frame use up the entire VBV. */
> > double min_fill_factor = rcc->single_frame_vbv ? 1 : 2;
> >
> > if( bits > rcc->buffer_fill/max_fill_factor )
> > - qf = x264_clip3f( rcc->buffer_fill/(max_fill_factor*bits), 0.2, 1.0 );
> > - q /= qf;
> > - bits *= qf;
> > + {
> > + double qf = x264_clip3f( rcc->buffer_fill/(max_fill_factor*bits), 0.2, 1.0 );
> > + q /= qf;
> > + bits *= qf;
> > + }
> > if( bits < rcc->buffer_rate/min_fill_factor )
> > - q *= bits*min_fill_factor/rcc->buffer_rate;
> > + {
> > + double qf = x264_clip3f( bits*min_fill_factor/rcc->buffer_rate, 0.001, 1.0 );
> > + q *= qf;
> > + }
> > q = X264_MAX( q0, q );
> > }
> >
> > - /* Apply MinCR restrictions */
> > - double bits = predict_size( &rcc->pred[h->sh.i_type], q, rcc->last_satd );
> > - if( bits > rcc->frame_size_maximum )
> > - q *= bits / rcc->frame_size_maximum;
> > - bits = predict_size( &rcc->pred[h->sh.i_type], q, rcc->last_satd );
> > -
> > /* Check B-frame complexity, and use up any bits that would
> > * overflow before the next P-frame. */
> > if( h->sh.i_type == SLICE_TYPE_P && !rcc->single_frame_vbv )
> > {
> > int nb = rcc->bframes;
> > + double bits = predict_size( &rcc->pred[h->sh.i_type], q, rcc->last_satd );
> > double pbbits = bits;
> > double bbits = predict_size( rcc->pred_b_from_p, q * h->param.rc.f_pb_factor, rcc->last_satd );
> > double space;
> > @@ -2302,6 +2301,12 @@ static double clip_qscale( x264_t *h, int pict_type, double q )
> > q = X264_MAX( q0/2, q );
> > }
> >
> > + /* Apply MinCR and buffer fill restrictions */
> > + double bits = predict_size( &rcc->pred[h->sh.i_type], q, rcc->last_satd );
> > + double frame_size_maximum = X264_MIN( rcc->frame_size_maximum, X264_MAX( rcc->buffer_fill, 0.001 ) );
> > + if( bits > frame_size_maximum )
> > + q *= bits / frame_size_maximum;
> > +
> > if( !rcc->b_vbv_min_rate )
> > q = X264_MAX( q0, q );
> > }
> >
> >
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Thu, 13 Nov 2014 13:52:02 +0100 (CET)
> > From: git at videolan.org (Anton Mitrofanov)
> > To: x264-devel at videolan.org
> > Subject: [x264-devel] Fix VBV with true VFR streams
> > Message-ID: <20141113125202.DF804151DC1 at albiero.videolan.org>
> > Content-Type: text/plain; charset=UTF-8
> >
> > x264 | branch: master | Anton Mitrofanov <BugMaster at narod.ru> | Tue Sep 2 01:48:00 2014 +0400| [204a9bd0a1bc507cbd69a77f3318afcb56ede65d] | committer: Fiona Glaser
> >
> > Fix VBV with true VFR streams
> >
> > > http://git.videolan.org/gitweb.cgi/x264.git/?a=commit;h=204a9bd0a1bc507cbd69a77f3318afcb56ede65d
> > ---
> >
> > encoder/ratecontrol.c | 12 ++++++++----
> > encoder/slicetype.c | 5 +----
> > 2 files changed, 9 insertions(+), 8 deletions(-)
> >
> > diff --git a/encoder/ratecontrol.c b/encoder/ratecontrol.c
> > index 8893c1f..86aad96 100644
> > --- a/encoder/ratecontrol.c
> > +++ b/encoder/ratecontrol.c
> > @@ -2191,6 +2191,8 @@ static double clip_qscale( x264_t *h, int pict_type, double q )
> >
> > if( rcc->b_vbv && rcc->last_satd > 0 )
> > {
> > + double fenc_cpb_duration = (double)h->fenc->i_cpb_duration *
> > + h->sps->vui.i_num_units_in_tick / h->sps->vui.i_time_scale;
> > /* Lookahead VBV: raise the quantizer as necessary such that no frames in
> > * the lookahead overflow and such that the buffer is in a reasonable state
> > * by the end of the lookahead. */
> > @@ -2206,6 +2208,7 @@ static double clip_qscale( x264_t *h, int pict_type, double q )
> > double buffer_fill_cur = rcc->buffer_fill - cur_bits;
> > double target_fill;
> > double total_duration = 0;
> > + double last_duration = fenc_cpb_duration;
> > frame_q[0] = h->sh.i_type == SLICE_TYPE_I ? q * h->param.rc.f_ip_factor : q;
> > frame_q[1] = frame_q[0] * h->param.rc.f_pb_factor;
> > frame_q[2] = frame_q[0] / h->param.rc.f_ip_factor;
> > @@ -2213,8 +2216,8 @@ static double clip_qscale( x264_t *h, int pict_type, double q )
> > /* Loop over the planned future frames. */
> > for( int j = 0; buffer_fill_cur >= 0 && buffer_fill_cur <= rcc->buffer_size; j++ )
> > {
> > - total_duration += h->fenc->f_planned_cpb_duration[j];
> > - buffer_fill_cur += rcc->vbv_max_rate * h->fenc->f_planned_cpb_duration[j];
> > + total_duration += last_duration;
> > + buffer_fill_cur += rcc->vbv_max_rate * last_duration;
> > int i_type = h->fenc->i_planned_type[j];
> > int i_satd = h->fenc->i_planned_satd[j];
> > if( i_type == X264_TYPE_AUTO )
> > @@ -2222,6 +2225,7 @@ static double clip_qscale( x264_t *h, int pict_type, double q )
> > i_type = IS_X264_TYPE_I( i_type ) ? SLICE_TYPE_I : IS_X264_TYPE_B( i_type ) ? SLICE_TYPE_B : SLICE_TYPE_P;
> > cur_bits = predict_size( &rcc->pred[i_type], frame_q[i_type], i_satd );
> > buffer_fill_cur -= cur_bits;
> > + last_duration = h->fenc->f_planned_cpb_duration[j];
> > }
> > /* Try to get to get the buffer at least 50% filled, but don't set an impossible goal. */
> > target_fill = X264_MIN( rcc->buffer_fill + total_duration * rcc->vbv_max_rate * 0.5, rcc->buffer_size * 0.5 );
> > @@ -2286,13 +2290,13 @@ static double clip_qscale( x264_t *h, int pict_type, double q )
> > double bframe_cpb_duration = 0;
> > double minigop_cpb_duration;
> > for( int i = 0; i < nb; i++ )
> > - bframe_cpb_duration += h->fenc->f_planned_cpb_duration[1+i];
> > + bframe_cpb_duration += h->fenc->f_planned_cpb_duration[i];
> >
> > if( bbits * nb > bframe_cpb_duration * rcc->vbv_max_rate )
> > nb = 0;
> > pbbits += nb * bbits;
> >
> > - minigop_cpb_duration = bframe_cpb_duration + h->fenc->f_planned_cpb_duration[0];
> > + minigop_cpb_duration = bframe_cpb_duration + fenc_cpb_duration;
> > space = rcc->buffer_fill + minigop_cpb_duration*rcc->vbv_max_rate - rcc->buffer_size;
> > if( pbbits < space )
> > {
> > diff --git a/encoder/slicetype.c b/encoder/slicetype.c
> > index 0f4d831..dd5e318 100644
> > --- a/encoder/slicetype.c
> > +++ b/encoder/slicetype.c
> > @@ -1853,14 +1853,11 @@ void x264_slicetype_decide( x264_t *h )
> > if( i )
> > {
> > x264_calculate_durations( h, h->lookahead->next.list[i], h->lookahead->next.list[i-1], &h->i_cpb_delay, &h->i_coded_fields );
> > - h->lookahead->next.list[0]->f_planned_cpb_duration[i-1] = (double)h->lookahead->next.list[i-1]->i_cpb_duration *
> > + h->lookahead->next.list[0]->f_planned_cpb_duration[i-1] = (double)h->lookahead->next.list[i]->i_cpb_duration *
> > h->sps->vui.i_num_units_in_tick / h->sps->vui.i_time_scale;
> > }
> > else
> > x264_calculate_durations( h, h->lookahead->next.list[i], NULL, &h->i_cpb_delay, &h->i_coded_fields );
> > -
> > - h->lookahead->next.list[0]->f_planned_cpb_duration[i] = (double)h->lookahead->next.list[i]->i_cpb_duration *
> > - h->sps->vui.i_num_units_in_tick / h->sps->vui.i_time_scale;
> > }
> > }
> >
> >
> >
> >
> > ------------------------------
> >
> > Message: 4
> > Date: Thu, 13 Nov 2014 13:52:03 +0100 (CET)
> > From: git at videolan.org (Anton Mitrofanov)
> > To: x264-devel at videolan.org
> > Subject: [x264-devel] Fix inappropriate instruction use
> > Message-ID: <20141113125203.366EF1527EE at albiero.videolan.org>
> > Content-Type: text/plain; charset=UTF-8
> >
> > x264 | branch: master | Anton Mitrofanov <BugMaster at narod.ru> | Thu Aug 28 20:13:13 2014 +0400| [9df377f87702c82a2202d34919c07e32c60b40ae] | committer: Fiona Glaser
> >
> > Fix inappropriate instruction use
> >
> > > http://git.videolan.org/gitweb.cgi/x264.git/?a=commit;h=9df377f87702c82a2202d34919c07e32c60b40ae
> > ---
> >
> > common/dct.c | 2 +-
> > common/quant.c | 4 ++--
> > common/x86/dct-a.asm | 2 +-
> > common/x86/dct.h | 2 +-
> > common/x86/pixel-a.asm | 2 +-
> > common/x86/quant-a.asm | 2 +-
> > common/x86/quant.h | 4 ++--
> > 7 files changed, 9 insertions(+), 9 deletions(-)
> >
> > diff --git a/common/dct.c b/common/dct.c
> > index f5900ef..08f4e89 100644
> > --- a/common/dct.c
> > +++ b/common/dct.c
> > @@ -611,7 +611,6 @@ void x264_dct_init( int cpu, x264_dct_function_t *dctf )
> > {
> > dctf->sub4x4_dct = x264_sub4x4_dct_mmx;
> > dctf->add4x4_idct = x264_add4x4_idct_mmx;
> > - dctf->dct4x4dc = x264_dct4x4dc_mmx;
> > dctf->idct4x4dc = x264_idct4x4dc_mmx;
> > dctf->sub8x8_dct_dc = x264_sub8x8_dct_dc_mmx2;
> >
> > @@ -630,6 +629,7 @@ void x264_dct_init( int cpu, x264_dct_function_t *dctf )
> >
> > if( cpu&X264_CPU_MMX2 )
> > {
> > + dctf->dct4x4dc = x264_dct4x4dc_mmx2;
> > dctf->add8x8_idct_dc = x264_add8x8_idct_dc_mmx2;
> > dctf->add16x16_idct_dc = x264_add16x16_idct_dc_mmx2;
> > }
> > diff --git a/common/quant.c b/common/quant.c
> > index d7b6911..31d8901 100644
> > --- a/common/quant.c
> > +++ b/common/quant.c
> > @@ -558,8 +558,6 @@ void x264_quant_init( x264_t *h, int cpu, x264_quant_function_t *pf )
> > if( cpu&X264_CPU_MMX )
> > {
> > #if ARCH_X86
> > - pf->quant_4x4 = x264_quant_4x4_mmx;
> > - pf->quant_8x8 = x264_quant_8x8_mmx;
> > pf->dequant_4x4 = x264_dequant_4x4_mmx;
> > pf->dequant_4x4_dc = x264_dequant_4x4dc_mmx2;
> > pf->dequant_8x8 = x264_dequant_8x8_mmx;
> > @@ -576,6 +574,8 @@ void x264_quant_init( x264_t *h, int cpu, x264_quant_function_t *pf )
> > {
> > pf->quant_2x2_dc = x264_quant_2x2_dc_mmx2;
> > #if ARCH_X86
> > + pf->quant_4x4 = x264_quant_4x4_mmx2;
> > + pf->quant_8x8 = x264_quant_8x8_mmx2;
> > pf->quant_4x4_dc = x264_quant_4x4_dc_mmx2;
> > pf->decimate_score15 = x264_decimate_score15_mmx2;
> > pf->decimate_score16 = x264_decimate_score16_mmx2;
> > diff --git a/common/x86/dct-a.asm b/common/x86/dct-a.asm
> > index 4376e36..bc82ff6 100644
> > --- a/common/x86/dct-a.asm
> > +++ b/common/x86/dct-a.asm
> > @@ -143,7 +143,7 @@ INIT_XMM avx
> > DCT4x4_DC
> > %else
> >
> > -INIT_MMX mmx
> > +INIT_MMX mmx2
> > cglobal dct4x4dc, 1,1
> > movq m3, [r0+24]
> > movq m2, [r0+16]
> > diff --git a/common/x86/dct.h b/common/x86/dct.h
> > index 337a632..f22a979 100644
> > --- a/common/x86/dct.h
> > +++ b/common/x86/dct.h
> > @@ -70,7 +70,7 @@ void x264_add8x8_idct_dc_avx ( pixel *p_dst, dctcoef dct [ 4] );
> > void x264_add16x16_idct_dc_avx ( pixel *p_dst, dctcoef dct [16] );
> > void x264_add16x16_idct_dc_avx2 ( uint8_t *p_dst, int16_t dct [16] );
> >
> > -void x264_dct4x4dc_mmx ( int16_t d[16] );
> > +void x264_dct4x4dc_mmx2 ( int16_t d[16] );
> > void x264_dct4x4dc_sse2 ( int32_t d[16] );
> > void x264_dct4x4dc_avx ( int32_t d[16] );
> > void x264_idct4x4dc_mmx ( int16_t d[16] );
> > diff --git a/common/x86/pixel-a.asm b/common/x86/pixel-a.asm
> > index 262c537..f5f6a82 100644
> > --- a/common/x86/pixel-a.asm
> > +++ b/common/x86/pixel-a.asm
> > @@ -1600,7 +1600,7 @@ cglobal pixel_satd_4x4, 4,6
> > %macro SATDS_SSE2 0
> > %define vertical ((notcpuflag(ssse3) || cpuflag(atom)) || HIGH_BIT_DEPTH)
> >
> > -%if vertical==0 || HIGH_BIT_DEPTH
> > +%if cpuflag(ssse3) && (vertical==0 || HIGH_BIT_DEPTH)
> > cglobal pixel_satd_4x4, 4, 6, 6
> > SATD_START_MMX
> > mova m4, [hmul_4p]
> > diff --git a/common/x86/quant-a.asm b/common/x86/quant-a.asm
> > index fb588d3..731f7d1 100644
> > --- a/common/x86/quant-a.asm
> > +++ b/common/x86/quant-a.asm
> > @@ -453,7 +453,7 @@ INIT_MMX mmx2
> > QUANT_DC quant_2x2_dc, 1
> > %if ARCH_X86_64 == 0 ; not needed because sse2 is faster
> > QUANT_DC quant_4x4_dc, 4
> > -INIT_MMX mmx
> > +INIT_MMX mmx2
> > QUANT_AC quant_4x4, 4
> > QUANT_AC quant_8x8, 16
> > %endif
> > diff --git a/common/x86/quant.h b/common/x86/quant.h
> > index 1fcb800..c6a8a9b 100644
> > --- a/common/x86/quant.h
> > +++ b/common/x86/quant.h
> > @@ -30,8 +30,8 @@
> >
> > int x264_quant_2x2_dc_mmx2( dctcoef dct[4], int mf, int bias );
> > int x264_quant_4x4_dc_mmx2( dctcoef dct[16], int mf, int bias );
> > -int x264_quant_4x4_mmx( dctcoef dct[16], udctcoef mf[16], udctcoef bias[16] );
> > -int x264_quant_8x8_mmx( dctcoef dct[64], udctcoef mf[64], udctcoef bias[64] );
> > +int x264_quant_4x4_mmx2( dctcoef dct[16], udctcoef mf[16], udctcoef bias[16] );
> > +int x264_quant_8x8_mmx2( dctcoef dct[64], udctcoef mf[64], udctcoef bias[64] );
> > int x264_quant_2x2_dc_sse2( dctcoef dct[16], int mf, int bias );
> > int x264_quant_4x4_dc_sse2( dctcoef dct[16], int mf, int bias );
> > int x264_quant_4x4_sse2( dctcoef dct[16], udctcoef mf[16], udctcoef bias[16] );
> >
> >
> >
> > ------------------------------
> >
> > Message: 5
> > Date: Thu, 13 Nov 2014 13:52:02 +0100 (CET)
> > From: git at videolan.org (Anton Mitrofanov)
> > To: x264-devel at videolan.org
> > Subject: [x264-devel] x264asm: warn when inappropriate instruction
> > used in function with specified cpuflags
> > Message-ID: <20141113125203.02ECB152262 at albiero.videolan.org>
> > Content-Type: text/plain; charset=UTF-8
> >
> > x264 | branch: master | Anton Mitrofanov <BugMaster at narod.ru> | Thu Aug 28 18:38:53 2014 +0400| [73b8686fc22c9247d90963983d406cd7b9131068] | committer: Fiona Glaser
> >
> > x264asm: warn when inappropriate instruction used in function with specified cpuflags
> >
> > > http://git.videolan.org/gitweb.cgi/x264.git/?a=commit;h=73b8686fc22c9247d90963983d406cd7b9131068
> > ---
> >
> > common/x86/x86inc.asm | 581 +++++++++++++++++++++++++------------------------
> > 1 file changed, 295 insertions(+), 286 deletions(-)
> >
> > Diff: http://git.videolan.org/gitweb.cgi/x264.git/?a=commitdiff;h=73b8686fc22c9247d90963983d406cd7b9131068
> >
> >
> > ------------------------------
> >
> > Message: 6
> > Date: Thu, 13 Nov 2014 13:52:03 +0100 (CET)
> > From: git at videolan.org (Anton Mitrofanov)
> > To: x264-devel at videolan.org
> > Subject: [x264-devel] Fix few clang -Wunused-* warnings
> > Message-ID: <20141113125203.5959D151DC1 at albiero.videolan.org>
> > Content-Type: text/plain; charset=UTF-8
> >
> > x264 | branch: master | Anton Mitrofanov <BugMaster at narod.ru> | Fri Sep 5 19:30:47 2014 +0400| [01204b60367f4959e8393652dd30f0cfba2d2c80] | committer: Fiona Glaser
> >
> > Fix few clang -Wunused-* warnings
> >
> > > http://git.videolan.org/gitweb.cgi/x264.git/?a=commit;h=01204b60367f4959e8393652dd30f0cfba2d2c80
> > ---
> >
> > common/x86/predict-c.c | 5 +++++
> > encoder/cavlc.c | 2 ++
> > 2 files changed, 7 insertions(+)
> >
> > diff --git a/common/x86/predict-c.c b/common/x86/predict-c.c
> > index 086c45d..0c668fa 100644
> > --- a/common/x86/predict-c.c
> > +++ b/common/x86/predict-c.c
> > @@ -65,12 +65,17 @@ PREDICT_16x16_DC_LEFT( avx2 )
> > H += i * ( src[j+i - FDEC_STRIDE ] - src[j-i - FDEC_STRIDE ] );\
> > V += i * ( src[(j+i)*FDEC_STRIDE -1] - src[(j-i)*FDEC_STRIDE -1] );
> >
> > +#if HAVE_X86_INLINE_ASM
> > +#if HIGH_BIT_DEPTH
> > ALIGNED_16( static const int16_t pw_12345678[8] ) = {1,2,3,4,5,6,7,8};
> > ALIGNED_16( static const int16_t pw_m87654321[8] ) = {-8,-7,-6,-5,-4,-3,-2,-1};
> > ALIGNED_16( static const int16_t pw_m32101234[8] ) = {-3,-2,-1,0,1,2,3,4};
> > +#else // !HIGH_BIT_DEPTH
> > ALIGNED_8( static const int8_t pb_12345678[8] ) = {1,2,3,4,5,6,7,8};
> > ALIGNED_8( static const int8_t pb_m87654321[8] ) = {-8,-7,-6,-5,-4,-3,-2,-1};
> > ALIGNED_8( static const int8_t pb_m32101234[8] ) = {-3,-2,-1,0,1,2,3,4};
> > +#endif // HIGH_BIT_DEPTH
> > +#endif // HAVE_X86_INLINE_ASM
> >
> > #define PREDICT_16x16_P_CORE\
> > int H = 0;\
> > diff --git a/encoder/cavlc.c b/encoder/cavlc.c
> > index 5d826ff..1d393fd 100644
> > --- a/encoder/cavlc.c
> > +++ b/encoder/cavlc.c
> > @@ -289,6 +289,7 @@ static ALWAYS_INLINE void x264_cavlc_macroblock_luma_residual( x264_t *h, int pl
> > x264_cavlc_block_residual( h, DCT_LUMA_4x4, i4+i8*4+p*16, h->dct.luma4x4[i4+i8*4+p*16] );
> > }
> >
> > +#if RDO_SKIP_BS
> > static ALWAYS_INLINE void x264_cavlc_partition_luma_residual( x264_t *h, int i8, int p )
> > {
> > if( h->mb.b_transform_8x8 && h->mb.cache.non_zero_count[x264_scan8[i8*4]] )
> > @@ -299,6 +300,7 @@ static ALWAYS_INLINE void x264_cavlc_partition_luma_residual( x264_t *h, int i8,
> > for( int i4 = 0; i4 < 4; i4++ )
> > x264_cavlc_block_residual( h, DCT_LUMA_4x4, i4+i8*4+p*16, h->dct.luma4x4[i4+i8*4+p*16] );
> > }
> > +#endif
> >
> > static void x264_cavlc_mb_header_i( x264_t *h, int i_mb_type, int i_mb_i_offset, int chroma )
> > {
> >
> >
> >
> > ------------------------------
> >
> > Subject: Digest Footer
> >
> > _______________________________________________
> > x264-devel mailing list
> > x264-devel at videolan.org
> > https://mailman.videolan.org/listinfo/x264-devel
> >
> >
> > ------------------------------
> >
> > End of x264-devel Digest, Vol 90, Issue 8
> > *****************************************
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> https://mailman.videolan.org/listinfo/x264-devel
>
>
> ------------------------------
>
> End of x264-devel Digest, Vol 90, Issue 10
> ******************************************
More information about the x264-devel
mailing list