doc:appunti:linux:video:ffmpeg_final_rendering
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
doc:appunti:linux:video:ffmpeg_final_rendering [2023/11/13 11:22] – [Encoding for High Definition Video] niccolo | doc:appunti:linux:video:ffmpeg_final_rendering [2024/07/31 09:57] (current) – [Two pass encoding] niccolo | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Final Rendering | + | ====== Final Rendering with libx264 and ffmpeg ====== |
+ | |||
+ | Whether you are working with **Ffmepg**, **Avidemux** or **Olive Video Editor**, you should be wondering what parameters to use to final render a video montage. Here are my choices for some specific purpose. | ||
===== Encoding for High Definition Video ===== | ===== Encoding for High Definition Video ===== | ||
Line 13: | Line 15: | ||
^ Basic x264 | Preset: **slow** (or less), Tuning: **film**, Profile: **High**, IDC Level: **Auto** | | ^ Basic x264 | Preset: **slow** (or less), Tuning: **film**, Profile: **High**, IDC Level: **Auto** | | ||
^ Video encoding | ^ Video encoding | ||
- | ^ Pixel format | + | ^ Pixel format |
- | ^ Bits per channel | + | ^ Bits per sample |
- | ^ Color range | + | ^ Color range |
^ Audio codec | < | ^ Audio codec | < | ||
^ Audio bitrate | ^ Audio bitrate | ||
Line 33: | Line 35: | ||
-filter:v " | -filter:v " | ||
-vcodec ' | -vcodec ' | ||
+ | -b:v 4M -maxrate:v 6M -bufsize:v 6M \ | ||
-acodec copy \ | -acodec copy \ | ||
" | " | ||
</ | </ | ||
+ | Notice that we selected a target bitrate of **4 Mbps** and a maximum bitrate of **6 Mbps**. Sepcifying both the //bitrate// and the //max bitrate tolerance// requires also to specify a //buffer size//; '' | ||
+ | |||
+ | ===== A warning about the H.264 profile level ===== | ||
+ | |||
+ | It turned out that **Kodi 19.4** (running on a Raspberry Pi 4 with **Raspbian GNU/Linux 11 Bullseye** o.s.) has some problems playing H.264 video files depending on the video format profile used for the encoding. The video actually starts to play, but nothing is seen on the screen; sometimes the screen goes totally green. Similarly a **Google TV** with Kodi 21.0 has problems with the same files, showing stuttering and video artifacts. | ||
+ | |||
+ | Here it is a table of playing capabilities based on experimental testing: | ||
+ | |||
+ | ^ Format profile | ||
+ | | High@L5 | ||
+ | | High@L4 | ||
+ | | High@L4.1 | ||
+ | | High@5 | ||
+ | | High@5 | ||
+ | |||
+ | ===== Two pass encoding ===== | ||
+ | |||
+ | Here it is a recipe of **two-pass encoding** from an high quality //master// produced with [[olive_editor_tools# | ||
+ | |||
+ | <code bash> | ||
+ | TITLE=' | ||
+ | ffmpeg \ | ||
+ | -i full32bit-veryslow-crf18-fullcolor.mkv \ | ||
+ | -metadata title=" | ||
+ | -vcodec ' | ||
+ | -profile:v ' | ||
+ | -b:v 6M -maxrate:v 9M -bufsize:v 18M \ | ||
+ | -x264-params ' | ||
+ | -an \ | ||
+ | -pass 1 \ | ||
+ | -f matroska -y /dev/null | ||
+ | # First pass produces two files: ffmpeg2pass-0.log and ffmpeg2pass-0.log.mbtree. | ||
+ | ffmpeg \ | ||
+ | -i full32bit-veryslow-crf18-fullcolor.mkv \ | ||
+ | -metadata title=" | ||
+ | -vcodec ' | ||
+ | -profile:v ' | ||
+ | -b:v 6M -maxrate:v 9M -bufsize:v 18M \ | ||
+ | -x264-params ' | ||
+ | -an \ | ||
+ | -pass 2 \ | ||
+ | -f matroska marocco-twopass-6max9-level41.mkv | ||
+ | </ | ||
+ | |||
+ | The transcoding works on the video only, suppressing any audio stream (**%%-an%%** option). Using the **keyint=64** option will produce a keyframe every 64 frames (about two seconds), this make seeking back and forward in the video more smooth. | ||
+ | |||
+ | ===== Pixel format considerations ===== | ||
+ | |||
+ | We used the **yuvj420p pixel format**. What does it means? | ||
+ | |||
+ | First of all consider the **420** code; this means tat for each matrix of 4x2 pixels the stream encode all the values for the luminance, only 2 values for the chrominance on the X axis and zero values for the chrominance on the Y axis. This figure explains clearly the 4:4:4, 4:2:2 and 4:2:0 subsampling methods: | ||
+ | |||
+ | {{subsampling.png? | ||
+ | |||
+ | Is file size is not a concern, we might ask ourselves whether a pixel format with less loss of chroma information would be preferable. Obviously is useless to add more chroma information if the final rendering has the same resolution of the original video, but if we are **scaling down** the video resolution we may **retain chroma information** using a different pixel format. | ||
+ | |||
+ | The fact is that **in movies 4:2:0 is almost lossless visually**, which is why it can be found used in Blu-ray discs and a lot of modern video cameras. There is virtually no advantage to using 4:4:4 for consuming video content. | ||
+ | |||
+ | Furthermore, | ||
+ | |||
+ | ===== How to probe a video ===== | ||
+ | |||
+ | How to get the **piexel format**: | ||
+ | |||
+ | < | ||
+ | ffprobe -loglevel error \ | ||
+ | -show_entries stream=pix_fmt \ | ||
+ | -select_streams v YDXJ4050.mp4 | ||
+ | </ | ||
+ | |||
+ | How to get the **bits per raw sample**: | ||
+ | |||
+ | < | ||
+ | ffprobe -loglevel panic \ | ||
+ | -show_entries stream=bits_per_raw_sample \ | ||
+ | -select_streams v YDXJ4050.mp4 | ||
+ | </ | ||
+ | |||
+ | ===== Web Resources ===== | ||
+ | |||
+ | * **[[https:// | ||
+ | * **[[https:// | ||
+ | * **[[https:// | ||
+ | * **[[https:// | ||
doc/appunti/linux/video/ffmpeg_final_rendering.1699870943.txt.gz · Last modified: by niccolo