[x265] [PATCH 1 of 6] rc: introduce param variables for 2 pass

[Aarthi Priya Thirumalai]

On Mon, Jun 16, 2014 at 9:33 AM, Steve Borho <steve at borho.org> wrote:

> On Sun, Jun 15, 2014 at 1:50 PM,  <aarthi at multicorewareinc.com> wrote:
> > # HG changeset patch
> > # User Aarthi Thirumalai<aarthi at multicorewareinc.com>
> > # Date 1402856954 -19800
> > #      Sun Jun 15 23:59:14 2014 +0530
> > # Node ID 438a03ff94830fbc17457b6f324397e643c17cba
> > # Parent  e69a427e461f8c8944b68323a3d77295b65ec779
> > rc: introduce param variables for 2 pass
>
> Yeah! two-pass patches \o/
>
> > diff -r e69a427e461f -r 438a03ff9483 source/x265.h
> > --- a/source/x265.h     Thu Jun 12 22:53:47 2014 -0500
> > +++ b/source/x265.h     Sun Jun 15 23:59:14 2014 +0530
> > @@ -745,8 +745,26 @@
> >
> >          /* In CRF mode, minimum CRF as caused by VBV */
> >          double    rfConstantMin;
> > +
> > +        /* 2pass */
> > +        /* Enable stat writing in psz_stat_out */
> > +        bool         statWrite;
>
> these comments are pasted from x264, with their variable names, which
> is unhelpful.
>
sorry, my bad. ll clean up properly.

>
> we don't allow bool types in x265.h; all types must be C native types
>
> > +
> > +        /* Read stat from psz_stat_in and use it */
> > +        int         statRead;
>
> parameters with boolean behaviors should start with lower case b.
>
> > +        /* output filename of the 2pass stats file */
> > +        char        *pszStatOut;
>
> can statWrite be implied from pszStatOut, and statRead from pszStatIn?
>
> should statRead be a bool like statWrite? Can it be implied from
> pszStatIn? Can we assume the user wants to read a stats file if they
> supply an input filename (and abort if the file cannot be opened)?
>
actually, we can do away with both statWrite and statRead bool..if we
shouldn't use default file names to set up pszStatIn/Out ,
then the user should necessarily provide a filename for each pass, we can
set it to either input/output file or both according to the pass sequence
(--pass)
and use them to detect the pass type later on.


> > +
> > +        /* input filename of the 2pass stats file */
> > +        char        *pszStatIn;
>
> Lets not sneak in hungarian prefixes for filenames. I know these come
> from x264, but that isn't a good enough excuse to add "pointer to
> string zero-terminated" to the start of our param variables.
>
ok

>
> > +        /* temporally blur quants */
> > +        double       qblur;
> > +
> > +        /* temporally blur complexity */
> > +        float        complexityBlur;
> >      } rc;
> > -
> >      /*== Video Usability Information ==*/
> >      struct
> >      {
> > @@ -876,6 +894,10 @@
> >  #define X265_PARAM_BAD_VALUE (-2)
> >  int x265_param_parse(x265_param *p, const char *name, const char
> *value);
> >
> > +/* x265_param_fastfirstpass:
> > +        Applies param settings for doing a faster encode in the 1st
> pass of a multi-pass encode. */
> > +void x265_param_apply_fastfirstpass(x265_param *param);
>
> it would be good to give a hint here of what trade-offs are made for
> first-pass encodes
> probably i can do this first pass speed up tuning later on, once i get the
> basic thing to work.
> >  /* x265_param_apply_profile:
> >   *      Applies the restrictions of the given profile. (one of below) */
> >  static const char * const x265_profile_names[] = { "main", "main10",
> "mainstillpicture", 0 };
> > _______________________________________________
> > x265-devel mailing list
> > x265-devel at videolan.org
> > https://mailman.videolan.org/listinfo/x265-devel
>
>
>
> --
> Steve Borho
> _______________________________________________
> x265-devel mailing list
> x265-devel at videolan.org
> https://mailman.videolan.org/listinfo/x265-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20140616/c61dfffe/attachment.html>