1. MulticoreWare Avatar MulticoreWare
  2. mcw
  3. x265_git

Wiki

Clone wiki

x265_git / Coding

View History

Coding Style

The cardinal rule when contributing code to a project is to simply follow the coding style already in place.

x265's coding style is both documented in and enforced by uncrustify. Our uncrustify configuration is tracked in the repository.

You are highly recommended to configure your editor to insert tabs as 4 spaces for both C++ and plain text files (for example, CMakeLists.txt). New files should have unix EOLN.

New files should have the following GPL2+ compliant header:

#!C++
/*****************************************************************************
 * Copyright (C) 2013 x265 project
 *
 * Authors: Your Name <your@email.edu>
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02111, USA.
 *
 * This program is also available under a commercial proprietary license.
 * For more information, contact us at licensing@multicorewareinc.com.
 *****************************************************************************/

Visual Leak Detector

Our CMake scripts will detect Visual Leak Detector if it is installed and will use it automatically for debug builds.

  1. Download VLD from codeplex and install: http://vld.codeplex.com
  2. Restart Visual Studio so the bin/ folder is in your %PATH%
  3. Force cmake to run, it will find VLD and report a version number in the log
  4. Build for Debug and run (not many frames, it will be slow)
  5. At exit, VLD will report leaks to stderr and the debugger console

For release builds, VLD is completely disabled.

Naming and Argument Conventions

Currently, the naming conventions have not been applied to all of the code. If you contribute any changes please update any touched names accordingly. Class and struct names should begin with a capital letter. Variable names and arguments are camelCase. Class members are prefixed by m_, structure members are not. A struct should be a class if it has non-trivial member functions. We allow the use of protected members and functions for the purpose of clarity, but we do not allow trivial set/get methods.

Objects should be passed by reference if the called function cannot handle NULL pointers. The object should be declared const if it is unharmed by the function. The methods themselves should be declared const if no member variables are harmed.

If a function returns a single integer output, it should be a return value. If the function returns more than a single value, then all the outputs may be references.

All classes, structs, functions, and global variables should be within the x265 namespace unless they are prefixed by x265_.

Common names

  • Yuv* fooYuv
  • PicYuv* fooPic
  • Frame* fooFrame
  • pixel* foo
  • CTU - top level (maximum size) coding unit, similar to AVC macroblock
  • cuAddr or ctuAddr - the scan-order index of a CTU within a picture
  • absPartIdx - the z-order offset [0..255] of a CU/PU/TU within a CTU
  • puIdx - part index [0..1] for rectangular partitions, [0..3] for NxN
  • ctu - a CUData instance in a FrameData, the 'official' CTU instance
  • cu - a CUData instance in Analysis, possibly smaller than a CTU
  • cuGeom - a CUGeom instance in Analysis that describes the depth and size of a CU. cuGeom.encodeIdx holds the absPartIdx of that CU within its CTU

There are three general classes for holding blocks of pixels

  • PicYuv - holds entire pictures (Y,Cb,Cr) with padding on all four sides for motion compensation. m_stride, m_strideC
  • Yuv - holds a CU (from 64x64 down to 8x8) of pixels, no padding. m_size, m_csize
  • ShortYuv - like Yuv except it holds int16_t instead of pixel, for residual or coeff

Common addressing operations:

Get the starting address of a CTU, with index ctuAddr, within a picture 

#!c++

intptr_t lumaStride = reconPic->m_stride, chromaStride = reconPic->m_strideC;
pixel* reconCTU = reconPic->getLumaAddr(ctuAddr);

Get the starting address of a CU within a CTU within a picture 

#!c++

pixel* reconCU = reconPic->getLumaAddr(ctuAddr, cuGeom.encodeIdx);

Get the starting address of a PU/TU within a CU within a CTU within a picture. Since part indices are in z-order, you can simply add offsets. 

#!c++

pixel* reconPU = reconPic->getLumaAddr(ctuAddr, cuGeom.encodeIdx + absPartIdx);

Since Yuv and ShortYuv instances only hold a single square TU/CU without any padding, their indexing is simpler 

#!c++

uint32_t lumaStride = reconYuv->m_size, chromaStride = reconYuv->m_csize;
pixel* reconCU = reconYuv->m_buf[0];
pixel* reconPU = reconYuv->getLumaAddr(absPartIdx);

Prefixes

m_ class members
s_ static class members
g_ global variables
b boolean

The boolean prefix can be omitted if the variable name is obviously a boolean value, such as fooFlag or isFoo.

Updated