User Tools

Site Tools


doc:appunti:linux:video:ffmpeg_final_rendering

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
doc:appunti:linux:video:ffmpeg_final_rendering [2024/07/31 09:52] – [Two pass encoding] niccolodoc:appunti:linux:video:ffmpeg_final_rendering [2026/08/23 21:03] (current) – [Pixel format considerations] niccolo
Line 41: Line 41:
  
 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//; ''ffmpeg'' will re-adjust the bitrate on each buffer size, so if the buffer size is equal to the max rate, ffmpeg will re-calculate the bitrate at least every second. 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//; ''ffmpeg'' will re-adjust the bitrate on each buffer size, so if the buffer size is equal to the max rate, ffmpeg will re-calculate the bitrate at least every second.
 +
 +=====  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  ^ Resolution   ^ Mbps  ^ Can play on Kodi  ^
 +| High@L5         | 1366x768        4 | yes  |
 +| High@L4         | 1920x1080    |    6 | Yes  |
 +| High@L4.1       | 1920x1080    |    6 | Yes  |
 +| High@5          | 1920x1080    |    4 | No   |
 +| High@5          | 1920x1080    |    6 | No   |
  
 =====  Two pass encoding ===== =====  Two pass encoding =====
  
-Here it is a recipe of **two-pass encoding** from an high quality //master// produced with Olive Video Editor. The target video will be a 6 Mbit stream, 1920x1080@30. The profile level selected is High@L4.1, so that the video will play nicely with Kodi 19.4 on the Raspberry Pi 4:+Here it is a recipe of **two-pass encoding** from an high quality //master// produced with [[olive_editor_tools#export_media|Olive Video Editor]]. The target video will be a **6 Mbit** stream, **1920x1080@30**. The profile level selected is **High@L4.1**, so that the video will play nicely with Kodi 19.4 on the Raspberry Pi 4:
  
 <code bash> <code bash>
Line 51: Line 64:
     -i full32bit-veryslow-crf18-fullcolor.mkv \     -i full32bit-veryslow-crf18-fullcolor.mkv \
     -metadata title="$TITLE" -metadata:s:v:0 title="$TITLE" \     -metadata title="$TITLE" -metadata:s:v:0 title="$TITLE" \
-    -vcodec 'libx264' -pix_fmt 'yuvj420p' -preset 'veryslow' -tune 'film' -profile:v 'high' -level:v 4.1 \+    -vcodec 'libx264' -pix_fmt 'yuvj420p' -preset 'veryslow' -tune 'film' 
 +    -profile:v 'high' -level:v 4.1 \
     -b:v 6M -maxrate:v 9M -bufsize:v 18M \     -b:v 6M -maxrate:v 9M -bufsize:v 18M \
     -x264-params 'keyint=64' \     -x264-params 'keyint=64' \
Line 57: Line 71:
     -pass 1 \     -pass 1 \
     -f matroska -y /dev/null     -f matroska -y /dev/null
 +# First pass produces two files: ffmpeg2pass-0.log and ffmpeg2pass-0.log.mbtree.
 ffmpeg \ ffmpeg \
     -i full32bit-veryslow-crf18-fullcolor.mkv \     -i full32bit-veryslow-crf18-fullcolor.mkv \
     -metadata title="$TITLE" -metadata:s:v:0 title="$TITLE" \     -metadata title="$TITLE" -metadata:s:v:0 title="$TITLE" \
-    -vcodec 'libx264' -pix_fmt 'yuvj420p' -preset 'veryslow' -tune 'film' -profile:v 'high' -level:v 4.1 \+    -vcodec 'libx264' -pix_fmt 'yuvj420p' -preset 'veryslow' -tune 'film' 
 +    -profile:v 'high' -level:v 4.1 \
     -b:v 6M -maxrate:v 9M -bufsize:v 18M \     -b:v 6M -maxrate:v 9M -bufsize:v 18M \
     -x264-params 'keyint=64' \     -x264-params 'keyint=64' \
Line 69: Line 84:
 </code> </code>
  
-The transcoding works on the video only, suppressing any video stream (**%%-an%%** option). Using the **keyint=64** option will produce a keyframe every 64 frame (about every two seconds), this make seeking back and forward in the video more smooth. +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.
- +
-=====  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  ^ Resolution   ^ Mbps  ^ Can play on Kodi  ^ +
-| High@L5         | 1366x768        4 | yes  | +
-| High@L4         | 1920x1080    |    6 | Yes  | +
-| High@L4.1       | 1920x1080    |    6 | Yes  | +
-| High@5          | 1920x1080    |    4 | No   | +
-| High@5          | 1920x1080    |    6 | No   |+
  
 =====  Pixel format considerations ===== =====  Pixel format considerations =====
Line 92: Line 94:
 {{subsampling.png?400|Chroma Subsampling}} {{subsampling.png?400|Chroma Subsampling}}
  
-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.+If 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. 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.
doc/appunti/linux/video/ffmpeg_final_rendering.1722412374.txt.gz · Last modified: by niccolo