ffmpeg has a huge array of conversion parameters, many of which were tested to optimise this project.
x264, the default video encoder, is actually a separate library (libx264) and project, and has a very large number of configurable parameters of it's own. Refer to this ffmpeg write-up: https://trac.ffmpeg.org/wiki/Encode/H.264 and a very detailed and useful write-up: http://www.lighterra.com/papers/videoencodingh264.
The default audio encoder chosen is ffmpeg's built-in AAC encoder, which since late 2015 is mainstream, no longer "experimental". You may also configure Fraunhofer's libfdk_aac or libmp3lame to output mp3 audio with the -a option if you prefer. libfdk_aac is required for HE-AAC (podcasts). See options
The parameters used in this script are:
***Video*** (keep) H264, profile: 4.0 high CRF 21 preset medium* (single use) H264, profile: 4.0 high CRF 23 preset veryfast* -OR- (keep) H265, above CRF +5 preset medium* (single use) H265, above CRF +5 preset veryfast* ***Audio*** (keep) stereo: MP2/3 > AAC or MP3 # @ lesser of 10/12 existing bitrate and 150k, with floor of 100k (e.g. 192k > 150k) (single use) stereo: MP2/3 > AAC or MP3 # @ lesser of 10/12 existing bitrate and 120k, with floor of 100k AC3/5.1 > copy mono: > copy (e.g. AD stream) (podcast) stereo: MP2/3 > HE-AAC v2 @ 48k or MP3, Opus as defined in $podcastaudioprofile variable ***Subtitles*** DVB > copy* CRF and preset are related.
If you use a faster preset, you need to reduce CRF to get similar quality, somewhat reducing any speed gain. It appears that that the stated quality is measured using the default "medium" preset, 23 being H264 standard, 18 being near perfect. In testing, using slower than "medium" or lowering the CRF below 20 or 21 did not seem to benefit the already compressed video quality of typical SD material. vdr-convert uses a default CRF of 21. On good HD material, when doing single use conversions, a CRF of 24 or more (-q 24) is often quite acceptable, but the user can set their own value as required with the -q option.
The conversion process is documented in Workflow
In "keep" mode, a good rule of thumb for H264 is real time x number of cores for a 3.2GHz CPU on SD material.
In single-use mode, conversion speed approximately doubles.
H265 is considerably slower, but has recently improved (v2.7 in 2018). On SD material it now runs at approximately half H264 speed
MPEG2 SD recordings are typically around 1 - 2Gb / hour for good material. Equivalent H264/AAC recordings are typically 650M - 1Gb / hour, more for grainy older films. H265 is typically 2/3 to 1/2 the size of H264, so approx 25-40% of MPEG2.
vdr-convert checks recording sizes and produces an error if the output is unreasonably small or larger than the original (e.g. very grainy film).