[x264-devel] x264-devel Digest, Vol 18, Issue 6
vipul agarwal
zoomrider at gmail.com
Sat Jan 17 14:14:47 CET 2009
sub: compressed bytes after encodingI am working on how to calculate no of
bytes produced after encoding. my model consists of some input variable like
qp,prediction cost and mode etc and it will predict the no of bytes which
encoder will produce,,,, so i thought of curve fitting so can some give me
some suggestion regarding that
On Wed, Nov 5, 2008 at 4:30 PM, <x264-devel-request at videolan.org> wrote:
> Send x264-devel mailing list submissions to
> x264-devel at videolan.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://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: regression test of x264 (Gabriel Bouvigne)
> 2. Re: Default value for the --scenecut option causes heavy
> undesirable flood of I slices in active scenes (Vladimir Chernyshov)
> 3. [PATCH] fix a potential endless loop within 2nd pass vbv
> handling (Gabriel Bouvigne)
> 4. commit: Encoder_reconfig: esa/ tesa can only be enabled if
> they were on to begin with ( Jason Garrett-Glaser )
> (git version control)
> 5. commit: Fix potential infinite loop in VBV under GCC 4.2
> (Gabriel Bouvigne ) (git version control)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 04 Nov 2008 12:17:25 +0100
> From: Gabriel Bouvigne <gabriel.bouvigne at joost.com>
> Subject: Re: [x264-devel] regression test of x264
> To: Mailing list for x264 developers <x264-devel at videolan.org>
> Message-ID: <49102F45.4080201 at joost.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Chang Chen a ?crit :
> > Ok, would you like to help me to point out which algorithm of x264 is
> > randomness?
>
> Threading: x264 threading is by encoding multiple frames in parallel. If
> you are encoding frames A and B with B being predicted from A, B
> encoding results at a given macroblock line can change according to how
> much of frame A is already encoded.
>
> That would be the case with motion estimation and VBV handling.
>
> --
> Gabriel
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 04 Nov 2008 14:34:24 +0200
> From: Vladimir Chernyshov <vchernys at welho.com>
> Subject: Re: [x264-devel] Default value for the --scenecut option
> causes heavy undesirable flood of I slices in active scenes
> To: x264-devel at videolan.org
> Message-ID: <20081104143424.5jxw5el6as08k0g0 at webmail.welho.com>
> Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes";
> format="flowed"
>
> Ok, the discussion is closed.
>
> I understand the point of B-frames as a form or perceptual
> compression. If 1/3 of the frames in video have a slightly higher
> quality, and 2/3 have slightly lower, the human eye will perceive the
> video as having the slightly higher quality, while the video will have
> a lower bitrate than that of the reference video with constant quality.
>
> regards,
> Vladimir
>
> P.S. Sorry, my email client does not show any hint whether the post is
> a top or not.
>
>
> > And I repeat my point that you still do not understand the purpose of
> > B-frames. The purpose of B-frames is not to raise the quantizer, and
> > the purpose of I-frames is not to lower the quantizer. These are
> > ratecontrol choices, which you can adjust as commandline options, and
> > have basically nothing to do with the reason why B-frames are useful
> > in the first place.
> >
> > In such a scene as you have described, B-frames are suboptimal:
> > period. No ifs, ands, or buts. I-frames are relatively optimal,
> > because if a frame is nearly entirely I-blocks, there is little point
> > to having inter prediction anyways. I am not going to change encoder
> > defaults because clueless people on the mailing list manage to
> > convince themselves of falsehoods and then proceed to ignore people
> > with enormously more experience in the field than they do and
> > completely disregard all responses that don't explicitly agree with
> > them.
> >
> > End of story. I am not going to waste any more of my time on this
> > unless someone starts paying me, or you submit a usable patch that not
> > only solves your supposed "problem" but also consistently improves
> > PSNR on every single test clip in my repertoire.
> >
> > Also, stop top-posting, or others will likely proceed to ignore you as
> well.
> >
> > Dark Shikari
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 04 Nov 2008 14:51:29 +0100
> From: Gabriel Bouvigne <gabriel.bouvigne at joost.com>
> Subject: [x264-devel] [PATCH] fix a potential endless loop within 2nd
> pass vbv handling
> To: x264-devel at videolan.org
> Message-ID: <49105361.1020907 at joost.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> workaround against a compilation issue when using gcc 4.2.3/4.2.4 with
> -ffast-math -02 and higher optims levels
> (could lead to endless loop)
>
>
> --
> Gabriel
> -------------- next part --------------
> An embedded and charset-unspecified text was scrubbed...
> Name: gcc_vbv_pass2.patch
> Url:
> http://mailman.videolan.org/pipermail/x264-devel/attachments/20081104/3b5521e3/attachment-0001.txt
>
> ------------------------------
>
> Message: 4
> Date: Wed, 5 Nov 2008 03:37:43 +0100 (CET)
> From: git at videolan.org (git version control)
> Subject: [x264-devel] commit: Encoder_reconfig: esa/ tesa can only be
> enabled if they were on to begin with ( Jason Garrett-Glaser )
> To: <x264-devel at videolan.org>
> Message-ID: <20081105023743.797AF28FD0 at skanda.videolan.org>
> Content-Type: text/plain; charset=UTF-8
>
> x264 | branch: master | Jason Garrett-Glaser <darkshikari at gmail.com> | Mon
> Nov 3 22:59:49 2008 -0800| [bc84e120f62b6fd3d6e08c816028c5f30aaea56b] |
> committer: Jason Garrett-Glaser
>
> Encoder_reconfig: esa/tesa can only be enabled if they were on to begin
> with
> Bug report by kemuri-_9.
>
> >
> http://git.videolan.org/gitweb.cgi/x264.git/?a=commit;h=bc84e120f62b6fd3d6e08c816028c5f30aaea56b
> ---
>
> encoder/encoder.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/encoder/encoder.c b/encoder/encoder.c
> index b359e3f..6655c9b 100644
> --- a/encoder/encoder.c
> +++ b/encoder/encoder.c
> @@ -814,7 +814,6 @@ int x264_encoder_reconfig( x264_t *h, x264_param_t
> *param )
> COPY( analyse.intra );
> COPY( analyse.inter );
> COPY( analyse.i_direct_mv_pred );
> - COPY( analyse.i_me_method );
> COPY( analyse.i_me_range );
> COPY( analyse.i_noise_reduction );
> COPY( analyse.i_subpel_refine );
> @@ -826,6 +825,8 @@ int x264_encoder_reconfig( x264_t *h, x264_param_t
> *param )
> COPY( analyse.f_psy_rd );
> COPY( analyse.f_psy_trellis );
> // can only twiddle these if they were enabled to begin with:
> + if( h->param.analyse.i_me_method >= X264_ME_ESA ||
> param.analyse.i_me_method < X264_ME_ESA )
> + COPY( analyse.i_me_method );
> if( h->pps->b_transform_8x8_mode )
> COPY( analyse.b_transform_8x8 );
> if( h->frames.i_max_ref1 > 1 )
>
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 5 Nov 2008 03:37:43 +0100 (CET)
> From: git at videolan.org (git version control)
> Subject: [x264-devel] commit: Fix potential infinite loop in VBV under
> GCC 4.2 (Gabriel Bouvigne )
> To: <x264-devel at videolan.org>
> Message-ID: <20081105023743.8D8E128FD3 at skanda.videolan.org>
> Content-Type: text/plain; charset=UTF-8
>
> x264 | branch: master | Gabriel Bouvigne <bouvigne at mp3-tech.org> | Tue Nov
> 4 09:56:03 2008 -0800| [b4b113c5955e95d20f4965b6ba3e34643f4aeb2e] |
> committer: Jason Garrett-Glaser
>
> Fix potential infinite loop in VBV under GCC 4.2
>
> >
> http://git.videolan.org/gitweb.cgi/x264.git/?a=commit;h=b4b113c5955e95d20f4965b6ba3e34643f4aeb2e
> ---
>
> encoder/ratecontrol.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/encoder/ratecontrol.c b/encoder/ratecontrol.c
> index 2d75471..876551f 100644
> --- a/encoder/ratecontrol.c
> +++ b/encoder/ratecontrol.c
> @@ -1709,7 +1709,7 @@ static void vbv_pass2( x264_t *h )
> adj_max = fix_underflow(h, t0, t1, 1.001, qscale_min,
> qscale_max);
>
> expected_bits = count_expected_bits(h);
> - } while(expected_bits < .995 * all_available_bits && expected_bits >
> prev_bits);
> + } while((expected_bits < .995*all_available_bits) &&
> ((int)(expected_bits+.5) > (int)(prev_bits+.5)) );
>
> if (!adj_max)
> x264_log( h, X264_LOG_WARNING, "vbv-maxrate issue, qpmax or
> vbv-maxrate too low\n");
>
>
>
> ------------------------------
>
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> http://mailman.videolan.org/listinfo/x264-devel
>
>
> End of x264-devel Digest, Vol 18, Issue 6
> *****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.videolan.org/pipermail/x264-devel/attachments/20090117/6f14ce0d/attachment.htm
More information about the x264-devel
mailing list