V-Nova LCEVC-specific Parameters

As with all encoders, additional parameters are available to tune performance optimally for a use case. To help ensure high-quality output, when using LCEVC, the encoder selects, by default, the appropriate parameters for various combinations of bitrate and resolution. Automatic parameter selection can be overridden by the command line.

LCEVC tuning

lcevc_tune

In line with x264 “tunes,” there are six variants of lcevc_tune, according to the aim of the encodes. Depending on the chosen tuning, the encoder will combine optimal settings and parameters according to that goal. The settings are as follows:

lcevc_tune setting

Description

optimizes for visual quality. Default.

vmaf

optimizes for VMAF

vmaf_neg

optimizes for the new VMAF NEG (No Enhancement Gain)

psnr

optimizes for PSNR

ssim

optimizes for SSIM, MS-SSIM

animation

an alternative to 'vq', optimizes for visual quality of animation

As explained in 1.3, please make sure to decode LCEVC streams with the LCEVC-enabled decoder, otherwise the LCEVC data will be ignored and you will decode in backward-compatibility mode. Also, if you are computing objective metrics, please remember to disable dithering at the decoder, as explained in 4.2.5

Examples of command lines:

CBR, lcevc_tune vq:

ffmpeg.exe -i input.mp4 -c:v lcevc_h264 -base_encoder x264 -r 30 -g 60 -b:v 1000k -eil_params “preset=medium” lcevc_x264_500k_vq.mp4

CBR, lcevc_tune vmaf:

ffmpeg.exe -i input.mp4 -c:v lcevc_h264 -base_encoder x264 -r 30 -g 60 ‑b:v 1000k -eil_params "lcevc_tune=vmaf;preset=medium" lcevc_x264_500k_vmaf.mp4

CBR, lcevc_tune psnr:

ffmpeg.exe -y -i input.mp4 -c:v lcevc_h264 -base_encoder x264 -r 30 -g 60 ‑b:v 1000k -eil_params "lcevc_tune=psnr;preset=medium" lcevc_x264_500k_psnr.mp4

Uncapped pCRF, lcevc_tune vmaf:

ffmpeg.exe -y -i input.mp4 -c:v lcevc_h264 -base_encoder x264 -r 30 -g 60 ‑eil_params "rc_pcrf=27;lcevc_tune=vmaf;preset=medium" lcevc_x264_pcrf27_vmaf.mp4

Note: the x264 -preset medium is called out specifically in this command line. However, please be aware that if not specified, this build of FFmpeg will default to medium.

LCEVC preset

lcevc_preset

Since SDK V 3.5 “lcevc_preset” is supported. Similar to the -preset or -cpu-used configuration of other codecs (i.e. x264, x265, VPx, AV1), lcevc_preset provides six discrete combinations of encoding parameters to optimise speed and video quality trade-off depending on the use case. The options are from 0 to 5, where 0 is the slowest (i.e., consistently with VPx/AV1) while achieving the maximum quality, and 5 is the fastest with 1 as default.

The “lcevc_preset” should be manually set by the user with similar criteria used for the choice of the base encoder preset. Here is our recommendation of lcevc_preset according to the preset of the x264/x265 base encoder. The ‘relative speed index’ provides a ballpark indication of the relative encode time of the various presets vs. the default one; it’s based on LCEVC x264 (medium), an index of ‘110’ means that the given preset takes 10% more encode time vs. the default, while ‘60’ means 40% less encode time. Note: the ratio is approximated and based on a small set of 1080p-encoded sample clips, so results may vary according to testing conditions.

lcevc_preset

Example x264/ x265 base preset

Example VPx/ AV1 base cpu-used/ preset

Relative speed index (based on LCEVC x264)

Use case

slow

<=5

110

Maximum quality, to be used when encoding processing is not a major constrain. LCEVC remains much faster than the base codec used alone at full resolution.

DEFAULT

medium

6-8

100

Optimal speed-quality tradeoff for most use cases where there are no particular speed constraints.

fast

Further speed gain with negligible quality drop (below JND).

faster

n.a.

Further speed gain, switching off certain perceptual improvements (“priority map”); negligible impact on metrics, but may be visually noticeable on some contents.

very fast, super fast

n.a.

65-70

Material speed gain, thanks to switching off LCEVC’s temporal component. Typically not recommended, visual quality can be affected especially on contents with significant static elements (e.g., logos/graphics, eGames, video conferencing)

ultra fast

n.a.

50-60

Maximum speed gain, but with material impact on visual quality. Not recommended, unless in most extreme scenarios where maximising encoding speed is the main goal.

Scaling mode

scaling_mode_level0

Specifies the scaling mode for the base encoder picture in the LCEVC hierarchy. In combination with the associated rate control strategies, 2D, 1D and 0D influence the relative allocation of bitrate to the low-, medium- and high-frequency portions of the content. Additional controls, not described in this manual, are available to advanced users.

Scaling mode

Description

Two-dimensional 2:1 scaling. E.g. for a 1920x1080 video, base layer is 960x540. Default for resolutions of 720p and above.

Horizontal-only 2:1 scaling. E.g. for a 1920x1080 video, base layer is 960x1080. This mode is recommendable at high bits per pixel (e.g. full HD above 5 Mbps) or low resolutions (e.g. 540p or below), especially for content with high amounts of relatively low-contrast high-frequency detail.

Default for resolutions lower than 720p.

No scaling. LCEVC enhances a base at the same resolution. This mode is primarily used to modify video features with LCEVC such as providing an HDR output with an SDR base. 0D mode must also be used when encoding in Native mode (without LCEVC).

2D is generally recommended for HD and UHD content and is the default scaling mode setting. 1D instead is the recommended mode, and default setting, for lower resolutions (540p and below).

ffmpeg.exe -i input.mp4 -c:v lcevc_h264 -base_encoder x264 -eil_params "scaling_mode_level0=2D" output.ts

In certain cases (e.g. at high bits per pixel for HD/UHD, or at medium bits per pixel for lower resolutions), 1D may provide a preferable trade-off between robustness to banding/blocking vs. loss of resolution impairments, especially when the content is viewed on a large display or from viewing distances lower than 2H.

Especially when comparison of different encoding parameters is possible (e.g. Convex Hull approach for VOD dynamic optimization, CAE, etc.), we recommend to also include 1D as option for high-bitrate and low-resolution profiles. At relatively low bits per pixel, 2D will provide better protection from big impairments during complex scenes, whilst possibly generating some loss of resolution in low-contrast areas during low-to-medium complexity scenes. Vice versa for 1D scaling mode.

Encoding Mode

encoding_mode

Specifies if LCEVC enhancement or native coding is applied.

Enhancement setting

Description

enhanced

The enhancement coding process is applied. Default.

native

Pass-through. Only the leveraged codec (e.g. x264) is used in full resolution, with no LCEVC enhancement. To be used in combination with:

scaling_mode_level0=0D

Example:

ffmpeg.exe -i input.mp4 -c:v lcevc_h264 -base_encoder x264 -eil_params "scaling_mode_level0=0D;encoding_mode=native" output.ts

Note: when using encoding_mode=native, the LCEVC enhancement is effectively switched off. In this mode, it is recommended NOT to specify any LCEVC specific parameters in the eil_params string to avoid unexpected behaviour or erroring.

Dithering

Specifies custom dither. Dither is an intentionally applied form of subtle noise / camera grain used in constrained bandwidth conditions, to minimise visual impairments, such as colour banding or blocking artefacts due to a constrained base layer.

For some scenes and types of content, dithering can provide a significant uplift in perceived quality, although objective metrics will always be worse when dithering is active. For this reason, dithering is turned off by default for all lcevc_tune settings except lcevc_tune vq.

Below is an example (with gamma increased to 3.0 in order to highlight the effect) of how dithering reduces aliasing on edges and reduces banding/blocking impairments. The effect is even more pleasant in motion, since banding and blocking may follow motion patterns distinct from the object that they overlay.

Figure 4.1 — Same LCEVC encode (dark scene, gamma adjusted to 3.0), decoded with adaptive dithering off (i.e., ignoring the dithering signalling) vs. adaptive dithering on.

dc_dithering_type

Specifies whether to apply a uniform dithering algorithm.

Dither setting

Description

None

No dithering is applied. Default for lcevc_tune psnr, vmaf and ssim.

Uniform

Uniform random dithering applied. Default for lcevc_tune vq.

dc_dithering_strength

Specifies the maximum dithering strength. Dithering preferences are often subjective:

The default value is 4.
A value of 7-8 displays a more visible dither.
A value of 2-3 should be used for substantially imperceptible dither.

Dithering is applied dynamically and content-adaptively by the encoder, depending on the quality of the base layer (base qp), on the level of lighting of a scene as well as on other factors. Irrespective of the specified strength, it automatically disappears in static/low-motion, low-detail scenes, and its intensity is automatically modulated on a frame-by-frame basis, according to the base QP, starting above a certain threshold (dc_dithering_qp_start), and maxing out above a second threshold (dc_dithering_qp_saturate). When dithering is activated, also at low base QP some dithering may still be applied by the encoder in case of dark scenes with relatively noisy source content.

dc_dithering_qp_start

This parameter specifies the base QP value at which to start applying dither. Range: 0-51. Default: 24.

dc_dithering_qp_saturate

This parameter specifies the base QP value at which to saturate dither. Range: 0-51. Default: 36.

Regardless of the base QP value, other low-level parameters make dithering adapt dithering strength settings based on frame luminosity (according to contrast sensitivity function) as well as presence of no-contrast plain graphics which would not benefit from dithering.

Dithering at the decoder

V-Nova recommends that dithering be used for optimal subjective visual quality. However, when calculating objective metrics for content that was encoded with dithering enabled, dithering must be disabled via the following command:

disable_dithering

Enables/disables the dithering algorithm (see section 8 for use with an FFmpeg decoding command line).

Disable dithering setting

Description

Dithering setting is unaffected, i.e., it is performed adaptively as indicated within the LCEVC elementary stream. Default.

Dithering is disabled.

As an example:

ffmpeg.exe -vcodec lcevc_h264 -disable_dithering 1 -i stream.mp4 -vcodec rawvideo output.yuv

M Adaptive Downsampling

The M Adaptive Downsampling settings influence a combination of LCEVC advanced encoder settings that affect the interlocked image processing effects of downsampler filter, upsampler filter, predicted residuals and full-resolution residual data. The LCEVC format is extremely flexible, allowing the encoder to leverage both non-linear (as well as content-adaptive) downsampling methods and signal custom (content- or context- adaptive) upsampling kernels. The upsampled reconstruction, before adding full-resolution details, is further amended by the LCEVC decoder with a non-linear processing step called “Predicted Residuals”. The combination of these cascade of non-linear adaptive filters generates a sort of simplified super-resolution upsampling, which is further corrected by adding details (residual data) that could not be otherwise reconstructed, so as to approximate the source as closely as possible, up to mathematically lossless.

The overall compression efficiency of LCEVC-enhanced multi-layer coding vs. the enhanced single-layer codec used alone at full resolution comes from sensibly separating high-frequency energy (“details”) from medium-to-low frequency energy (“core signal”), and efficiently compressing both components of the signal with:

a) low-complexity tools specifically designed to efficiently compress sparse high-frequency details via light-weight parallel processing

and

b) a traditional single-layer codec operating more efficiently on the core signal by compressing it at a lower resolution.

Modifying some key elements of this non-linear combination of resampling and signal decomposition tools generates profound impact to both visual quality and metrics. In the current implementation we established some combinations that work reasonably well, and we embedded them in the various lcevc_tunes. But the calibration effort isn’t infallible: we observed material divergence in how different objective metrics (as well as subjective preferences) react to changes in these low-level settings. In short, there is still much room for improvement and fine-tuning. Future releases will further improve the way in which the encoder automatically calibrates these tools based on user preference and on the specificity of the content being encoded.

The M adaptive downsampling (m_ad_mode) settings deviate from basic linear kernels and provide some degree of control for one of the elements of this “chain reaction” of interlocked non-linear image processing tools.

m_ad_mode

Specifies the M adaptive downsampling mode (String).

Mode

Description

disabled

M adaptive downsampling disabled.

Default for lcevc_tune=psnr, lcevc_tune=ssim and lcevc_tune=vmaf_neg

replace

M adaptive downsampling is applied equally to both residual surfaces.

Default for lcevc_tune=vq and lcevc_tune=vmaf

separate

M adaptive downsampling is applied separately to residual surfaces.

Default for lcevc_tune=animation

Notice: MSE-based metrics such as PSNR and SSIM strongly “dislike” the use of M adaptive downsampling, so if you are in any way looking at any MSE-based metrics, either set m_ad_mode=disabled or use the corresponding lcevc_tune (which, among other things, will set m_ad_mode to "disabled). On the other side, both formal subjective MOS scores and VMAF tend to agree that some degree of M adaptive downsampling improves visual quality.

m_hf_strength

m_hf_strength, which accepts fractional values between 0 and 0.5, allows to increase or decrease the energy of high frequencies, with 0 being a preference for softer details. Default values, which are modified adaptively by the encoder if you do not specify anything, are comprised between 0 and 0.35.

m_lf_strength

m_lf_strength, which accepts fractional values between 0 and 1.0, allows you to modify the way in which full resolution details are separated from the mid-to-low frequencies that are passed as low resolution to the base codec. Default values, which are modified adaptively by the encoder if you do not specify anything, are comprised between 0 and 0.5.

IPP mode (no b-frames)

For certain low-latency applications, such as video conferencing, the V-Nova LCEVC rate control includes a specific IPP mode, i.e., in which b-frames are not used. This mode must be turned on for optimal performance, in combination with setting b-frames to zero (bframes=0 in the case of x264); otherwise the V-Nova LCEVC rate control will make incorrect assumption about the GOP structure, and consequently, will make suboptimal rate allocations.

rc_pcrf_ipp_mode

Specifies whether to apply IPP mode.

IPP mode setting

Description

No IPP mode applied, i.e., assumption of IBP structure. Default.

IPP mode applied.

Example:

ffmpeg.exe -i input.mp4 -c:v lcevc_h264 -base_encoder x264 -eil_params "bframes=0;rc_pcrf_ipp_mode=1" output.ts

Optimising Encoding CPU utilization

There are two main tools we can use for CPU optimisation: 1; NUMA awareness, 2; api mode. NUMA For best performance it is crucial to make sure that a process does not cross NUMA nodes or physical CPU sockets as the LCEVC SDK is currently not NUMA aware. This is most relevant when using physical server hardware or large compute cloud environments. Linux: run 'lscpu' Windows: Open Task Manager > Performance > right click > change graphs to NUMA node, if grey your system only has 1 node.

NUMA node0 CPU(s):   0-17,36-53
NUMA node1 CPU(s):   18-35,54-71

Here is an example of the NUMA information from a large Linux server. If we are to run encodes in parallel, job A would be best on NUMA 0, job B on NUMA 1 and so on. This is to stop frame data having to transfer between nodes which is a bottleneck for encoding. This can be achieved by using a tool such as 'taskset' on Linux or 'AFFINITY' on Windows to restrict the cores that the function is allowed to run on. API Mode Another method is to add the following to the eil parameters within your LCEVC encode. This is system dependent and should be used on larger systems, but can also have a negative impact on encoding performance on smaller machines (below 16 threads) where it should not be used.

eil_params= "api_mode=asynchronous"

This parameter decouples the encoding pipeline into different queues rather than processing all in one queue across the threads.

Querying Configuration Properties

All publicly available encoding configuration properties for the base encoder and LCEVC enhancement can be queried through the API using EIL_QueryPropertyGroups. This will return an array of all property groups which each contain an array of all properties in that group. Alternatively, if the name of the parameter is known then it can be directly queried through EIL_QueryProperty.

Each property contains a name, description, the expected type of that property and its current value. Below is an example that queries the API for all properties and prints them.

void PrintProperties(EILContext context)
{
	EILPropertyGroups groups;
	EILReturnCode     rc = EIL_QueryPropertyGroups(context, &groups);

	if (rc != EIL_RC_Success)
	{
		fprintf(stderr, "Unable to query property groups: %s\n", EIL_GetErrorString(rc));
		return;
	}

	for (uint32_t g = 0; g < groups.group_count; ++g)
	{
		EILPropertyGroup* group = &groups.group[g];

		printf("%s:\n", group->name);

		for (uint32_t p = 0; p < group->property_count; ++p)
		{
			EILProperty* property = &group->properties[p];

			printf("\t%s (", property->name);

			switch (property->type)
			{
				case EIL_PT_Int16: printf("int16"); break;
				case EIL_PT_Int32: printf("int32"); break;
				case EIL_PT_Int64: printf("int64"); break;
				case EIL_PT_Uint16: printf("uint16"); break;
				case EIL_PT_Uint32: printf("uint32"); break;
				case EIL_PT_Uint64: printf("uint64"); break;
				case EIL_PT_Float: printf("float"); break;
				case EIL_PT_Double: printf("double"); break;
				case EIL_PT_String: printf("string"); break;
				case EIL_PT_Boolean: printf("boolean"); break;
				case EIL_PT_Blob: printf("blob"); break;
			}

			printf("): %s\n", property->description);
		}
	}
}

PreviousLower Resolutions (720p and below)NextMetadata

Last updated 7 days ago

Was this helpful?