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