Use case: High Efficiency Video Coding (HEVC)

An example of video profile based on CRF, a quality-controlled variable bitrate, instead of fixed quality scale (ABR). HEVC (H.265) was developed as a successor to AVC (H.264) to more efficiently compress the future large amounts of data from 2/4/8k videos. In comparison to AVC, an average saving of around 30 percent can be assumed for the same quality. Because HEVC is not bound to any size format, it is suitable for virtually any image size.

The following example is HD and FullHD oriented and produces a picture quality similar to the Blu-ray with some limitations. As container Matroska (.mkv) is used, but also mp4 and others are possible.

	matroska libx265
	
	# CRF 16 creates a balanced compromise
	# between quality and file size.
	crf=16
	
	# Preset changes encoding speed and generally
	# degrades the overall result. Medium (default)
	# always fits.
	preset=medium
	
	# Additional parameters that are passed on to the codec.
	# me=star improves the search for very fast
	# movements, but slows down the encoding.
	#x265-params=me=star
	
	# Keyint does FFmpeg automatically, otherwise
	# the setting must match the frame rate.
	#keyint_min=25
	
	# Profile does FFmpeg automatically.
	#profile=high
	
	# Source sRBG and retention of color space.
	# 720/1080=bt709 if no profile set. Useful
	# for formats smaller than 720 if no lossy
	# conversion is desired.
	colorspace=bt709
	color_trc=bt709
	color_primaries=bt709
	
	# Output in 10 bit, prevents 8-bit step formation
	pixel_format=yuv420p

NOTE:

A CRF of 16 delivers satisfactory results in most cases. However, if the video material is really grainy, a CRF 16 can lead to unwanted large files. In this case, a trial export of perhaps one minute should be performed. The resulting bit rate can be used to correct the CRF to 17, 18, 19...– remember, a CRF of 0 (zero) means lossless, the higher the number the stronger the lossy compression. The approximate calculation of the final file size can be extrapolated from the sample export.

The color space information must be used explicitly so that it can be included in the video. CINELERRA-GG or FFmpeg does not write it by itself. Without this information the players (e. g. mpv) stick to the dimensions of the video and take the assumed color model from a table. With videos in the dimensions from 720 to 1080 this is bt709. For smaller dimensions, e. g. DVD, bt601 is assumed and for 4k and above it is bt2020. Normally this is not a problem, but if you want to export a FullHD without color loss to a smaller size like 576 for example, you have to inform the encoder as well as the decoder of the player. This also applies if the videos are to be loaded on video platforms, where they are then converted into videos of different sizes. It is a security measure to prevent false colors, such as the color profiles in digital photos and the copies made from them.

The HEVC tuning has not been considered here, because it is is rarely used and requires background knowledge.

Further links:

The CINELERRA-GG Community, 2021
https://www.cinelerra-gg.org