[x264-devel] Degrade video quality by time

[Alex S]

sorry for delay. I tried your crf param and intra-refresh option.
certainly, with crf=23, quality is very high but It degraded by time (it is
right because 164kbps may be too low in this case). Output video seems
displaying a line of object movement (as if we do not have IDR but in fact
we have).
However, what I need is quality (we even could accept block) should not
degraded

On Fri, Oct 28, 2011 at 12:53 PM, Alex Jurkiewicz <alex at jurkiewi.cz> wrote:

> I'm not clear on which of my suggestions you tried.
>
> Are you sure your video does not simply get more complex as it goes on?
>
> On Fri, Oct 28, 2011 at 3:00 PM, Alex S <flashsupporter at gmail.com> wrote:
> > Thanks for your information!
> > However, it is still degraded quality by time (but in different effect
> and
> > VBV overflow more).
> > Is there anyway that bits is overallocated constant overtime (mean, at
> low
> > bitrate, quality can be low but does not degrade by time)?
> >
> > On Thu, Oct 27, 2011 at 10:11 AM, Alex Jurkiewicz <alex at jurkiewi.cz>
> wrote:
> >>
> >> You must specify a bufsize for VBV encoding to work. More info:
> >>
> http://mewiki.project357.com/wiki/X264_Encoding_Suggestions#VBV_Encoding
> >>
> >> Single pass bitrate-based ratecontrol doesn't work so well, because
> >> the ratecontrol algorithm has no information about the complexity of
> >> future scenes. It often overallocates bits at the start and has to
> >> underallocate later on.
> >>
> >> A common recommendation is to use CRF-based ratecontrol to pick a
> >> 'target quality' and VBV settings to constrain the maximum bitrate to
> >> below your maximum pipe size. This will use the lowest bitrate
> >> required to achieve the given CRF value, capped given the VBV
> >> settings.
> >>
> >> Try these options: rc_method=crf, crf=23, vbv_bufsize=164,
> >> vbv_maxrate=164. Don't specify bitrate.
> >>
> >> Also, at such a low bitrate you might want to consider intra-refresh
> >> as well, which will make the size of each frame more consistent. This
> >> can improve streaming performance when you have small VBV buffers.
> >>
> >> Alex
> >>
> >> On Mon, Oct 24, 2011 at 2:23 PM, Alex S <flashsupporter at gmail.com>
> wrote:
> >> > I am using x264 in ABR and CBR mode. However, the quality is degraded
> by
> >> > time.
> >> > If I use CQP ratecontrol method, the quality is acceptable at bitrate
> >> > 160kbps. However, with the same bitrate (or even higher) in ABR/CBR
> >> > mode,
> >> > video quality is degraded by time and unacceptable.
> >> > Here is context setting in my code:
> >> > x264_param_default_preset(&param, "veryfast", "zerolatency");
> >> > x264_param_apply_profile(&param, "main");
> >> > param.i_threads = 1;
> >> > param.i_width = width;
> >> > param.i_height = height;
> >> > param.i_fps_num = fps;
> >> > param.i_fps_den = 1;
> >> > param.i_keyint_max = fps * 2
> >> > param.b_intra_refresh = 0;
> >> > param.rc.i_bitrate = 164     ;
> >> > param.rc.i_vbv_max_bitrate = 164;
> >> > param.rc.i_rc_method = X264_RC_ABR;
> >> > param.b_repeat_headers = 1;
> >> > param.b_annexb = 1;
> >> > Could anybody help me to modify or add other setting parameters to
> solve
> >> > the
> >> > problem?
> >> > Thank you!
> >> > Alex
> >> >
> >> > _______________________________________________
> >> > x264-devel mailing list
> >> > x264-devel at videolan.org
> >> > http://mailman.videolan.org/listinfo/x264-devel
> >> >
> >> >
> >> _______________________________________________
> >> x264-devel mailing list
> >> x264-devel at videolan.org
> >> http://mailman.videolan.org/listinfo/x264-devel
> >
> >
> > _______________________________________________
> > x264-devel mailing list
> > x264-devel at videolan.org
> > http://mailman.videolan.org/listinfo/x264-devel
> >
> >
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> http://mailman.videolan.org/listinfo/x264-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20111031/e092a1bd/attachment.html>