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

Steve Borho steve at borho.org
Mon Jun 16 06:03:39 CEST 2014


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.

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)?

> +
> +        /* 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.

> +        /* 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

>  /* 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


More information about the x265-devel mailing list