[x264-devel] Degrade video quality by time
Alex S
flashsupporter at gmail.com
Mon Nov 7 02:28:47 CET 2011
Thank Alex! I have tried b_vfr_input=0 but nothing change. It seem
b_vfr_input=0 as default.
On Tue, Nov 1, 2011 at 12:02 AM, Alex Giladi <alex.giladi at gmail.com> wrote:
> Try setting b_vfr_input=0
>
> On Mon, Oct 31, 2011 at 2:17 AM, Alex S <flashsupporter at gmail.com> wrote:
> > 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(¶m, "veryfast", "zerolatency");
> >> >> > x264_param_apply_profile(¶m, "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
> >
> >
> > _______________________________________________
> > 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/20111107/4b93f9c0/attachment.html>
More information about the x264-devel
mailing list