Differences

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

--- doc:appunti:linux:video:ffmpeg [2020/06/17 12:35] – niccolo
+++ doc:appunti:linux:video:ffmpeg [2024/07/25 08:12] (current) – [AVC (x264) is better than ASP (xvid4)] niccolo
@@ Line 264: / Line 264: @@
 </code>
-====== Final rendering (re-encoding) ======
-The video stream recorded by the Xiaomi Yi camera is **1920x1080 pixels** at a variable bitrate of **12.0 Mb/s**. Because we watch it on a simple TV set capable only of 1366x768 pixels, we we re-encode it with the following settings:
+====== Re-encoding with tonal correction ======
-^ Video codec     | MPEG-4 AVC (x264)  |
+We had some video clips recorded with an **SJCAM Sj8 Pro** camera with a **bad color balance and saturation** due some bad tables [[..:..:hardware:sjcam-8pro-custom-firmware|loaded into the firmware]]. It is possibile to re-encode all the video clips applying an equalization filter keeping all the encoding paramteres as similar as possibile to the original ones.
-^ Video filter    | swresize, 1366x768, Bilinear  |
-^ Basic x264      | Preset: **slow** (or less), Tuning: **film**, Profile: **High**, IDC Level: **Auto** |
-^ Video encoding  | Average Bitrate (Two Pass), Average Bitrate 6000 kb/s (about 3 Gb per hour)  |
-^ Audio codec     | <del>Lame MP3</del> Vorbis  |
-^ Audio bitrate   | CBR 192 (or higher)  |
-We can use **Avidemux** to make the final rendering (re-encoding). For a **comman line only** solution you can consider ffmpeg to perfomr the re-encoding and **mkvmerge** (contained into the **mkvtoolnix** Debian package) to merge all into a Matroska container.
+The video clips were **extracted from the original MP4 container** as **[[wp>MPEG transport stream|MPEG-TS]]** snippets containing only video (no audio). To re-encode each clip we used the following **ffmpeg** recipe:
-==== AVC (x264) is better than ASP (xvid4) ====
+<code bash>
+#!/bin/sh
+#
+# Re-encode video clips in MPEG transport stream (MPEG-TS) format applying
+# some saturation and gamma correction.
+#
+# saturation:           In range 0.0 to 3.0. The default value is "1".
+# gamma_{r|g|b}         In range 0.1 to 10.0. The default value is "1".
+INPUT="$1"
+OUTPUT="$INPUT.eq.ts"
+EQ_FILTER="eq=saturation=0.88:gamma_r=0.917:gamma_g=1.007:gamma_b=1.297"
+# Produces MPEG segments like the ones produced by the SJCAM SJ8Pro:
+ffmpeg -i "$INPUT" \
+    -vf "$EQ_FILTER" \
+    -codec:v libx264 \
+    -preset veryslow -profile:v main -level:v 4.2 -pix_fmt yuvj420p \
+    -x264-params 'vbv-maxrate=38000:vbv_bufsize=20000:nal-hrd=vbr:force-cfr=1:keyint=8:bframes=0:scenecut=-1:ref=1' \
+    -keyint_min 8 -brand avc1 -f 3gp \
+    -bsf:v h264_mp4toannexb -f mpegts \
+    "$OUTPUT"
+</code>
+The gamma correction for the three RGB channels was determined with the GIMP, using the //Colors// => //Levels// => //Pick the gray point for all channels// tool. The use of MPEG-TS clips allowed the montage of the final video by just concatenating them.
+===== AVC (x264) is better than ASP (xvid4) =====
 See this page: **[[https://www.avidemux.org/admWiki/doku.php?id=general:common_myths|Common myths]]** to understand the differences between formats (standards) and codecs (pieces of software). Read also this simple page: **[[https://www.cyberlink.com/support/product-faq-content.do?id=1901|Difference between MPEG-4 AVC and MPEG-4 ASP]]**. See also the Wikipedia article about **[[wp>Advanced Video Coding]]**.
@@ Line 293: / Line 313: @@
   * **Tuning**: Use the **film** option for real life scenes.
   * **Profile**: The **High** profile is OK for high-definition television (e.g. 1280×720, or Blu-ray disc), //High 10// add support for 10 bits per sample, //High 444// up to 14 bits per sample (both for [[wp>High dynamic range|HDR]] videos). Do not use //Main//, which is for standard-definition TV, e.g. 720×576.
-  * **IDC Level**: Leave this parameter to **Auto**, setting it to higer values does not increase the video quality, but imposes higher constraints to the decoder. I.e. to decode 1280×1024@42 it is sufficient the 3.1 IDC level (see [[wp>Advanced Video Coding]]).
+  * **IDC Level**: Leave this parameter to **Auto**, setting it to higer values does not increase the video quality, but imposes higher constraints to the decoder. I.e. to decode a 1280×720@30 stream it is sufficient the 3.1 IDC level, to decode a 1920×1080@30 stream (max 20 Mbps) it is required the 4 IDC level (see [[wp>Advanced Video Coding]]).
 ====== More on ffmpeg Command Line ======
@@ Line 471: / Line 491: @@
 </code>
+====== Problem in MKV Remux ======
+It seems there is a bug in ffmpeg **[[https://trac.ffmpeg.org/ticket/6037|#6037 mkv muxing not broken]]**: muxing two working files into a mkv produces a broken file: seeking around can break (mute) audio. I experienced this bug (with ffmpeg 4.1.6) trying to mux one mkv file containing one audio and one subtitle streams to another mkv file conaining video and audio. The resulting file did not play good in mplayer: seeking into the file caused audio or vido to stop playing.
+This was the first try command line:
+<code>
+# The resulting video is broken.
+ffmpeg -i input_file1.mkv -i input_file2.mkv \
+    -map '0:v:0' -map '0:a:0' \
+    -map '1:a:0' -map '1:s:0' \
+    -codec:v copy -codec:a copy -codec:s copy \
+    output_file.mkv
+</code>
+The workaround was to extract each individual stream, and mux then together:
+<code>
+ffmpeg -i input_file1.mkv -map 0:v:0 -codec:v copy input-v_env.mkv
+ffmpeg -i input_file1.mkv -map 0:a:0 -codec:a copy input-a_ita.mkv
+ffmpeg -i input_file2.mkv -map 0:a:0 -codec:a copy input-a_eng.mkv
+ffmpeg -i input_file2.mkv -map 0:s:0 -codec:s copy input-s_eng.mkv
+ffmpeg \
+    -i input-v_env.mkv \
+    -i input-a_ita.mkv \
+    -i input-a_eng.mkv \
+    -i input-s_eng.mkv \
+    -codec:v copy -codec:a copy -codec:s copy \
+    -map '0' -map '1' -map '2' -map '3' \
+    output_file.mkv
+</code>
+====== ffmpeg: leggere la sequenza di VOB da un DVD ======
+Nella directory **VIDEO_TS** di un DVD la traccia principale è normalmente suddivisa in file numerati sequenzialmente, ad esempio: ''VTS_01_0.VOB'', ''VTS_01_1.VOB'', ...
+In teoria è sufficiente concatenare i file in un solo file destinazione e quindi trattarlo come un normale file audio/video. Tuttavia è possibile indicare i singoli file come input senza la necessità di occupare ulteriore spazio disco con questa sintassi:
+<code bash>
+SOURCE="concat:VTS_01_1.VOB|VTS_01_2.VOB|VTS_01_3.VOB|VTS_01_4.VOB|VTS_01_5.VOB"
+ffmpeg -i "$SOURCE" ...
+</code>
+====== ffmpeg: impostare un ritardo sui sottotitoli durante il muxing ======
+Se un flusso di sottotitoli (ad esempio nel formato Picture based DVD) non indica correttamente l'offset iniziale di riproduzione è possibile dire ad ffmpeg di impostarlo opportunamente in fase di muxing. In questo esempio il primo sottotitolo appare a 44.5 secondi:
+<code bash>
+ffmpeg -i video-stream.mkv -i audio-stream.mkv -itsoffset 44.5 -i subtitles-stream.mkv ...
+</code>
+In generale dovrebbe essere possibile scoprire l'offset quando ffmpeg legge l'intero stream, al momento in cui trova il prmio frame dei subtitles mostra qualcosa del genere sulla console:
+<code>
+[mpeg @ 0x55f98bb2c6c0] New subtitle stream 0:7 at pos:14755854 and DTS:44.5s
+</code>
+====== Parameters for final rendering ======
+See the page **[[ffmpeg_final_rendering]]**.
 ====== Doppiaggio audio con Ardour ======
 Vedere la pagina dedicata: **[[ardour_dubbing]]**.