A pre-condition on a method has been violated.

A post-condition on a method has been violated.

An invalid hardware device ID has been supplied.

Raw RGB picture data in a memory area.

RGB picture data stored in a Symbian OS CFbsBitmapCFbsBitmap object.

Raw YUV picture data stored in a memory area. The data storage format depends on the YUV sampling pattern and data layout used.

16-bit RGB data format with four pixels per component. The data format is the same as used in Symbian EColor4K bitmaps, with each pixel using two bytes with the bit layout [ggggbbbb xxxxrrrr] where "x" indicates unused bits. (This corresponds to "XRGB" 16-bit little-endian halfwords)

16-bit RGB data format with five bits per component for red and blue and six bits for green. The data format is the same as used in Symbian EColor64K bitmaps, with each pixel using two bytes with the bit layout [gggbbbbb rrrrrggg] (This corresponds to "RGB" 16-bit little-endian halfwords)

32-bit RGB data format with eight bits per component. This data format is the same as is used in Symbian EColor16MU bitmaps. The bit layout is [bbbbbbbb gggggggg rrrrrrrr xxxxxxxx] where "x" indicates unused bits. (This corresponds to "XRGB" 32-bit little-endian words)

CFbsBitmapCFbsBitmap object with EColor4K data format.

CFbsBitmapCFbsBitmap object with EColor64K data format.

CFbsBitmapCFbsBitmap object with EColor16M data format.

CFbsBitmapCFbsBitmap object with EColor16MU data format.

4:2:0 sampling format. 4 luminance sample positions correspond to one chrominance sample position. The four luminance sample positions are on the corners of a square. The chrominance sample position is vertically half-way of the luminance sample positions and horizontally aligned with the left side of the square. This is the MPEG-2 and the MPEG-4 Part 2 sampling pattern.

4:2:0 sampling format. 4 luminance sample positions correspond to one chrominance sample position. The four luminance sample positions are on the corners of a square. The chrominance sample position is vertically and horizontally in the middle of the luminance sample positions. This is the MPEG-1 sampling pattern.

4:2:0 sampling format. 4 luminance sample positions correspond to one chrominance sample position. The four luminance sample positions are on the corners of a square. The chrominance sample position colocates with the top-left corner of the square. This sampling format is one of the options in Annex E of H.264 | MPEG-4 AVC.

4:2:2 sampling format. 2 luminance sample positions correspond to one chrominance sample position. The luminance sample positions reside on the same pixel row. The chrominance sample position is co-located with the left one of the luminance sample positions. This is the MPEG-2 4:2:2 sampling pattern.

4:2:2 sampling format. 2 luminance sample positions correspond to one chrominance sample position. The luminance sample positions reside on the same pixel row. The chrominance sample position is in the middle of the luminance sample positions. This is the MPEG-1 4:2:2 sampling pattern.

The data is stored in a plane mode. The memory buffer contains first all Y component data for the whole picture, followed by U and V, making the data format Y00Y01Y02Y03...U0...V0... For YUV 4:2:0 data, this is the same data format as EFormatYUV420Planar in the Onboard Camera API

The data is stored interleaved mode, all components interleaved in a single memory block. Interleaved layout is only supported for YUV 4:2:2 data. The data byte order is Y1VY0U, corresponding to "UY0VY1" little-endian 32-bit words. This is the same data format as EFormatYUV422Reversed in the Onboard Camera API

The data is stored interleaved mode, all components interleaved in a single memory block. Interleaved layout is only supported for YUV 4:2:2 data. The data byte order is UY0VY1, corresponding to "UY0VY1" big-endian 32-bit words. This is the same data format as EFormatYUV422 in the Onboard Camera API

The data is stored in a semi-planar mode. The memory buffer contains first all Y component data for the whole picture, followed by U and V components, which are interlaced, making the data format Y00Y01Y02Y03...U0V0U1V1... For YUV 4:2:0 data, this is the same data format as FormatYUV420SemiPlanar in the Onboard Camera API

No effect.

Fade from black.

Fade to black.

Unspecified transition from or to constant colour.

Dissolve.

Wipe.

Unspecified mixture of two scenes.

The RGB data uses the full 8-bit range of [0…255].

The RGB data uses the nominal range of [16…235]. Individual samples can still contain values beyond that range, the rest of the 8-bit range is used for headroom and footroom.

Each data unit is a single coded picture.

Each data unit is a coded video segment. A coded video segment is a part of the coded video data that forms an independently decodable part of a coded video frame. For example, a video packet in MPEG-4 Part 2 and slice in H.263 are coded video segments.

Each data unit contains an integer number of video segments consecutive in decoding order, possibly more than one. The video segments shall be a subset of one coded picture.

Each data unit contains a piece of raw video bitstream, not necessarily aligned at any headers. The data must be written in decoding order. This data unit type can be used for playback if the client does not have information about the bitstream syntax, and just writes data in random-sized chunks. For recording this data unit type is useful if the client can handle arbitrarily split data units, giving the encoder maximum flexibility in buffer allocation. For encoded data output, each data unit must still belong to exactly one output picture.

The coded data units can be chained in a bitstream that can be decoded. For example, MPEG-4 Part 2 elementary streams, H.263 bitstreams, and H.264 | MPEG-4 AVC Annex B bitstreams fall into this category.

The coded data units are encapsulated in a general-purpose packet payload format whose coded data units can be decoded independently but cannot be generally chained into a bitstream. For example, the Network Abstraction Layer Units of H.264 | MPEG-4 AVC fall into this category.

The coded data units are encapsulated in RTP packet payload format. The RTP payload header may contain codec-specific items, such as a redundant copy of a picture header in the H.263 payload specification RFC2429.

No HRD/VBV specification.

The HRD/VBV specification in the corresponding coding standard.

Annex G of 3GPP TS 26.234 Release 5.

Input cropping, used for pan-scan cropping in video playback and digital zoom in video recording. Pan-scan cropping is useful, for example, for displaying arbitrary-sized pictures with codecs that only support image dimensions that are multiples of 16 pixels.

Horizontal mirroring, flips the image data around a vertical line in its center.

Picture rotation, supports rotation by 90 or 180 degrees, clockwise and anticlockwise.

Picture scaling to a new size, includes both upscaling and downscaling. The supported scaling types and scale factors depend on the pixel processor.

Crops the picture to a final output rectangle.

Pads the output picture to a defined size. Used in video recording to pad pictures to suit the encoder input requirements.

YUV to RGB color space conversion. Supported only for video playback.

RGB to YUV color space conversion. Supported only for video recording.

YUV to YUV data format conversion. Supported only for video recording.

Noise filtering. Noise filtering is typically used to enhance the input picture from the camera, and is usually only supported for video recording.

Color enhancement. Color enhancement is typically used to enhance the input picture from the camera, and is usually only supported for video recording.

Frame stabilisation. Supported only for video recording.

Deblocking is typically used to remove artefacts from the output picture that result from high compression or a noisy input signal. Only supported for video playback.

Deringing is typically used to remove artefacts from the output picture that result from a noisy input signal corrupting motion estimates. Only supported for video playback.

Custom hardware device specific processing.

No dithering.

Ordered dither.

Error diffusion dither.

Other hardware device specific dithering type.

No rotation.

Rotate the picture 90 degrees clockwise.

Rotate the picture 90 degrees anticlockwise.

Rotate the picture 180 degrees.

The encoder does not control the bit-rate, but uses specified target picture quality and picture rate as such. The coded data stream must still remain compliant with the standard and buffer settings in use, if any, and thus HRD/VBV settings can limit the possible bit-rate.

The encoder controls the coded bit-rate of the stream. The caller indicates target bit-rate, target picture quality, target frame rate, spatial-temporal trade-off, and latency-quality trade-off.

The encoder controls the coded bit-rate of each picture. The caller gives the target amount of bits per frame. Each given input frame is coded. This type of operation is applicable only in memory-buffer-based input.

The layer uses temporal scalability. Using the layer increases the picture rate.

The layer uses quality scalability. Using the layer improves picture quality.

The layer uses spatial scalability. Using the layer increases picture resolution.

The layer is a fine-granularity scalability layer. In fine granularity scalability, the output quality increases gradually as a function of decoded bits from the enhancement layer.

The layer is a fine-granularity quality scalability layer.

No error control.

Low error control strength.

Normal error control strength.

High error control strength.

Temporal scalability, such as B-pictures.

Other scalability type.

The frame portion is unknown.

An entire frame.

A fragment of a frame containing the start but not the end.

An fragment of a frame containing neither the start nor the end.

A fragment of a frame containing the end but not the start.