[x264-devel] [Git][videolan/x264][master] Fix typos with codespell tool
Anton Mitrofanov (@BugMaster)
gitlab at videolan.org
Wed Sep 29 21:14:45 UTC 2021
Anton Mitrofanov pushed to branch master at VideoLAN / x264
Commits:
d8debbc6 by Ziemowit Zabawa at 2021-09-29T21:11:16+00:00
Fix typos with codespell tool
This includes fixing convert_method_to_flag so it recognizes "gauss"
parameter properly instead of silently defaulting to bicubic.
- - - - -
17 changed files:
- AUTHORS
- common/aarch64/mc-c.c
- common/arm/mc-c.c
- common/osdep.h
- common/ppc/pixel.c
- common/x86/bitstream-a.asm
- common/x86/trellis-64.asm
- config.guess
- doc/threads.txt
- encoder/analyse.c
- encoder/ratecontrol.c
- encoder/slicetype-cl.c
- filters/video/resize.c
- tools/checkasm.c
- tools/digress/cli.py
- x264.c
- x264.h
Changes:
=====================================
AUTHORS
=====================================
@@ -58,7 +58,7 @@ S: Sweden
N: Laurent Aimar
E: fenrir AT videolan DOT org
C: fenrir
-D: Intial import, former maintainer
+D: Initial import, former maintainer
D: x86 asm (mmx/mmx2)
S: France
=====================================
common/aarch64/mc-c.c
=====================================
@@ -210,7 +210,7 @@ static void mc_luma_neon( uint8_t *dst, intptr_t i_dst_stride,
int qpel_idx = ((mvy&3)<<2) + (mvx&3);
intptr_t offset = (mvy>>2)*i_src_stride + (mvx>>2);
uint8_t *src1 = src[x264_hpel_ref0[qpel_idx]] + offset;
- if( (mvy&3) == 3 ) // explict if() to force conditional add
+ if( (mvy&3) == 3 ) // explicit if() to force conditional add
src1 += i_src_stride;
if( qpel_idx & 5 ) /* qpel interpolation needed */
@@ -236,7 +236,7 @@ static uint8_t *get_ref_neon( uint8_t *dst, intptr_t *i_dst_stride,
int qpel_idx = ((mvy&3)<<2) + (mvx&3);
intptr_t offset = (mvy>>2)*i_src_stride + (mvx>>2);
uint8_t *src1 = src[x264_hpel_ref0[qpel_idx]] + offset;
- if( (mvy&3) == 3 ) // explict if() to force conditional add
+ if( (mvy&3) == 3 ) // explicit if() to force conditional add
src1 += i_src_stride;
if( qpel_idx & 5 ) /* qpel interpolation needed */
=====================================
common/arm/mc-c.c
=====================================
@@ -218,7 +218,7 @@ static void mc_luma_neon( uint8_t *dst, intptr_t i_dst_stride,
int qpel_idx = ((mvy&3)<<2) + (mvx&3);
intptr_t offset = (mvy>>2)*i_src_stride + (mvx>>2);
uint8_t *src1 = src[x264_hpel_ref0[qpel_idx]] + offset;
- if( (mvy&3) == 3 ) // explict if() to force conditional add
+ if( (mvy&3) == 3 ) // explicit if() to force conditional add
src1 += i_src_stride;
if( qpel_idx & 5 ) /* qpel interpolation needed */
@@ -244,7 +244,7 @@ static uint8_t *get_ref_neon( uint8_t *dst, intptr_t *i_dst_stride,
int qpel_idx = ((mvy&3)<<2) + (mvx&3);
intptr_t offset = (mvy>>2)*i_src_stride + (mvx>>2);
uint8_t *src1 = src[x264_hpel_ref0[qpel_idx]] + offset;
- if( (mvy&3) == 3 ) // explict if() to force conditional add
+ if( (mvy&3) == 3 ) // explicit if() to force conditional add
src1 += i_src_stride;
if( qpel_idx & 5 ) /* qpel interpolation needed */
=====================================
common/osdep.h
=====================================
@@ -289,7 +289,7 @@ static inline int x264_is_regular_file( FILE *filehandle )
#define ALIGNED_8( var ) DECLARE_ALIGNED( var, 8 )
#define ALIGNED_16( var ) DECLARE_ALIGNED( var, 16 )
-// ARM compiliers don't reliably align stack variables
+// ARM compilers don't reliably align stack variables
// - EABI requires only 8 byte stack alignment to be maintained
// - gcc can't align stack variables to more even if the stack were to be correctly aligned outside the function
// - armcc can't either, but is nice enough to actually tell you so
=====================================
common/ppc/pixel.c
=====================================
@@ -1262,7 +1262,7 @@ static int pixel_sa8d_8x8_core_altivec( uint8_t *pix1, intptr_t i_pix1,
SA8D_1D_ALTIVEC(sa8d0v, sa8d1v, sa8d2v, sa8d3v,
sa8d4v, sa8d5v, sa8d6v, sa8d7v );
- /* accumulation of the absolute value of all elements of the resulting bloc */
+ /* accumulation of the absolute value of all elements of the resulting block */
vec_s16_t abs0v = VEC_ABS(sa8d0v);
vec_s16_t abs1v = VEC_ABS(sa8d1v);
vec_s16_t sum01v = vec_add(abs0v, abs1v);
=====================================
common/x86/bitstream-a.asm
=====================================
@@ -34,7 +34,7 @@ SECTION .text
;-----------------------------------------------------------------------------
%macro NAL_LOOP 2
%%escape:
- ; Detect false positive to avoid unneccessary escape loop
+ ; Detect false positive to avoid unnecessary escape loop
xor r3d, r3d
cmp byte [r0+r1-1], 0
setnz r3b
=====================================
common/x86/trellis-64.asm
=====================================
@@ -158,7 +158,7 @@ cglobal %1, 4,15,9
%define cost_siglast stack+80
%define level_tree stack+96
- ; trellis_node_t is layed out differently than C.
+ ; trellis_node_t is laid out differently than C.
; struct-of-arrays rather than array-of-structs, for simd.
%define nodes_curq r7
%define nodes_prevq r8
=====================================
config.guess
=====================================
@@ -1083,7 +1083,7 @@ EOF
# uname -m prints for DJGPP always 'pc', but it prints nothing about
# the processor, so we play safe by assuming i586.
# Note: whatever this is, it MUST be the same as what config.sub
- # prints for the "djgpp" host, or else GDB configury will decide that
+ # prints for the "djgpp" host, or else GDB configure will decide that
# this is a cross-build.
echo i586-pc-msdosdjgpp
exit ;;
=====================================
doc/threads.txt
=====================================
@@ -33,7 +33,7 @@ I enabled the various components of slicing one at a time, and measured the port
* 16% reset cabac contexts
* 6% deblocking between slices (you don't strictly have to turn this off just for standard compliance, but you do if you want to use slices for decoder multithreading)
* 2% cabac neighbors (cbp, skip, etc)
-The proportional cost of redundant headers should certainly depend on bitrate (since the header size is constant and everything else depends on bitrate). Deblocking should too (due to varing deblock strength).
+The proportional cost of redundant headers should certainly depend on bitrate (since the header size is constant and everything else depends on bitrate). Deblocking should too (due to varying deblock strength).
But none of the proportions should depend strongly on the number of slices: some are triggered per slice while some are triggered per macroblock-that's-on-the-edge-of-a-slice, but as long as there's no more than 1 slice per row, the relative frequency of those two conditions is determined solely by the image width.
=====================================
encoder/analyse.c
=====================================
@@ -1346,7 +1346,7 @@ static void mb_analyse_inter_p8x8_mixed_ref( x264_t *h, x264_mb_analysis_t *a )
i_maxref = ref;\
}
- /* early termination: if 16x16 chose ref 0, then evalute no refs older
+ /* early termination: if 16x16 chose ref 0, then evaluate no refs older
* than those used by the neighbors */
if( a->b_early_terminate && (i_maxref > 0 && (a->l0.me16x16.i_ref == 0 || a->l0.me16x16.i_ref == h->mb.ref_blind_dupe) &&
h->mb.i_mb_type_top > 0 && h->mb.i_mb_type_left[0] > 0) )
@@ -2173,7 +2173,7 @@ static void mb_analyse_inter_b8x8_mixed_ref( x264_t *h, x264_mb_analysis_t *a )
ALIGNED_ARRAY_16( pixel, pix,[2],[8*8] );
int i_maxref[2] = {h->mb.pic.i_fref[0]-1, h->mb.pic.i_fref[1]-1};
- /* early termination: if 16x16 chose ref 0, then evalute no refs older
+ /* early termination: if 16x16 chose ref 0, then evaluate no refs older
* than those used by the neighbors */
#define CHECK_NEIGHBOUR(i)\
{\
=====================================
encoder/ratecontrol.c
=====================================
@@ -608,7 +608,7 @@ int x264_reference_build_list_optimal( x264_t *h )
COPY2_IF_GT( max, refcount[i], bestref, i );
/* FIXME: If there are duplicates from frames other than ref0 then it is possible
- * that the optimal ordering doesnt place every duplicate. */
+ * that the optimal ordering doesn't place every duplicate. */
refcount[bestref] = -1;
h->fref[0][ref] = frames[bestref];
@@ -1661,7 +1661,7 @@ int x264_ratecontrol_mb( x264_t *h, int bits )
float b1 = bits_so_far + predict_row_size_to_end( h, y, rc->qpm ) + size_of_other_slices;
float trust_coeff = x264_clip3f( bits_so_far / slice_size_planned, 0.0, 1.0 );
- /* Don't increase the row QPs until a sufficent amount of the bits of the frame have been processed, in case a flat */
+ /* Don't increase the row QPs until a sufficient amount of the bits of the frame have been processed, in case a flat */
/* area at the top of the frame was measured inaccurately. */
if( trust_coeff < 0.05f )
qp_max = qp_absolute_max = prev_row_qp;
=====================================
encoder/slicetype-cl.c
=====================================
@@ -283,7 +283,7 @@ int x264_opencl_lowres_init( x264_t *h, x264_frame_t *fenc, int lambda )
return 0;
}
-/* This function was tested emprically on a number of AMD and NV GPUs. Making a
+/* This function was tested empirically on a number of AMD and NV GPUs. Making a
* function which returns perfect launch dimensions is impossible; some
* applications will have self-tuning code to try many possible variables and
* measure the runtime. Here we simply make an educated guess based on what we
=====================================
filters/video/resize.c
=====================================
@@ -128,7 +128,7 @@ static uint32_t convert_method_to_flag( const char *name )
flag = SWS_AREA;
else if( !strcasecmp( name, "bicublin" ) )
flag = SWS_BICUBLIN;
- else if( !strcasecmp( name, "guass" ) )
+ else if( !strcasecmp( name, "gauss" ) )
flag = SWS_GAUSS;
else if( !strcasecmp( name, "sinc" ) )
flag = SWS_SINC;
=====================================
tools/checkasm.c
=====================================
@@ -262,7 +262,7 @@ intptr_t (*x264_checkasm_call)( intptr_t (*func)(), int *ok, ... ) = x264_checka
* assembly function through x264_checkasm_call with added dummy arguments which forces all
* real arguments to be passed on the stack and not in registers. For 32-bit argument the
* upper half of the 64-bit register location on the stack will now contain junk. Note that
- * this is dependant on compiler behaviour and that interrupts etc. at the wrong time may
+ * this is dependent on compiler behaviour and that interrupts etc. at the wrong time may
* overwrite the junk written to the stack so there's no guarantee that it will always
* detect all functions that assumes zero-extension.
*/
=====================================
tools/digress/cli.py
=====================================
@@ -139,7 +139,7 @@ class Dispatcher(object):
args = self.optparse.parse_args()[1] # arguments may require reparsing after pre_dispatch; see test_x264.py
if len(args) == 0:
- print >>sys.stderr, "error: no comamnd specified\n"
+ print >>sys.stderr, "error: no command specified\n"
self.optparse.print_help()
return
=====================================
x264.c
=====================================
@@ -1302,7 +1302,7 @@ static int init_vid_filters( char *sequence, hnd_t *handle, video_info_t *info,
{
x264_register_vid_filters();
- /* intialize baseline filters */
+ /* initialize baseline filters */
if( x264_init_vid_filter( "source", handle, &filter, info, param, NULL ) ) /* wrap demuxer into a filter */
return -1;
if( x264_init_vid_filter( "resize", handle, &filter, info, param, "normcsp" ) ) /* normalize csps to be of a known/supported format */
=====================================
x264.h
=====================================
@@ -521,7 +521,7 @@ typedef struct x264_param_t
int i_sps_id; /* SPS and PPS id number */
int b_vfr_input; /* VFR input. If 1, use timebase and timestamps for ratecontrol purposes.
* If 0, use fps only. */
- int b_pulldown; /* use explicity set timebase for CFR */
+ int b_pulldown; /* use explicitly set timebase for CFR */
uint32_t i_fps_num;
uint32_t i_fps_den;
uint32_t i_timebase_num; /* Timebase numerator */
View it on GitLab: https://code.videolan.org/videolan/x264/-/commit/d8debbc6ddd54cdf6c1661925287d7f16a3c3144
--
View it on GitLab: https://code.videolan.org/videolan/x264/-/commit/d8debbc6ddd54cdf6c1661925287d7f16a3c3144
You're receiving this email because of your account on code.videolan.org.
More information about the x264-devel
mailing list