Differences

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

--- doc:appunti:linux:video:flowblade_howto [2026/07/20 10:53] – [How to re-frame a clip (position and scale)] niccolo
+++ doc:appunti:linux:video:flowblade_howto [2026/07/23 06:59] (current) – [Rendering memory leak] niccolo
@@ Line 149: / Line 149: @@
   * **Shift + tasti freccia**: modifica la dimensione dell'immagine originale di 8 pixel per volta.
-Purtroppo sembra che non sia possibile immettere da tastiera i valori numerici del filtro.
+È possible anche **immettere da tastiera i valori numerici** di posizione e dimensione, basta avere l'accortezza di **premere invio** dopo aver digitato i numero nella casella. I parametri del filtro sono l'offset a cui spostare l'angolo in alto a sinistra della clip e la nuova dimensione. Solitamente l'offset è negativo in quanto la clip viene ingrandita e spostata verso l'alto a sinistra (X e Y negativi).
 Il play di una clip su cui siano stati applicati uno o più filtri è molto oneroso e potrebbe non avvenire in tempo reale su una CPU non abbastanza performante.
+===== Rendering memory leak =====
+Abbiamo sperimentato un **memory leak** durante il rendering finale di un video. Queste le condizioni in cui si è verificato:
+  * **flowblade** 1:2.22.1.1-dmo0+deb13u1 da %%https://www.deb-multimedia.org%% trixie/main
+  * **python3-mlt7** 1:7.32.0-dmo1 da %%https://www.deb-multimedia.org%% trixie/main
+  * **ffmpeg** 10:7.1.3-dmo1+deb13u1 da %%https://www.deb-multimedia.org%% trixie/main
+  * Profilo output **2.5K QHD 1440p 59.94 fps** (2560x1440).
+  * Durata del video **37 minuti**.
+  * CPU Intel Core i5-7200U, **16 Gb RAM**.
+Il processo di rendering terminava intorno al 10%, con il seguente errore in **dmesg**:
+<code>
+[82395.529730] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,
+    mems_allowed=0,global_oom,
+    task_memcg=/user.slice/user-1000.slice/user@1000.service/
+    app.slice/app-org.kde.konsole-2921.scope,
+    task=python3,pid=1937318,uid=1000
+[82395.530097] Out of memory: Killed process 1937318 (python3)
+    total-vm:25535832kB, anon-rss:14339756kB, file-rss:7212kB, shmem-rss:0kB,
+    UID:1000 pgtables:46500kB oom_score_adj:0
+</code>
+Durante il rendering si è monitorato l'andamento della memoria libera (comando **free -h**) e si è generato un grafico. Si vede che appena viene esaurita la RAM inizia ad esaurirsi anche lo swap, fino a che il kernel effettua il kill del processo:
+{{.:flowblade:flowblade-rendering-memory-leak.png?480|Flowblade rendering memory leak}}
+Durante il rendering si hanno due processi in esecuzuione: **flowblade** e **flowbladesinglerender**. È il secondo che esaurisce la memoria. Si tratta del processo che esegue il motore di rendering MLT seguendo il binding **python** => **python3-mlt7** => **libmlt-7-7**:
+{{.:flowblade:flowblade-memory-leak-processes.png?480|Flowblade rendering processes memory leak}}
+Come workaround del problema è stato possibile esportare il progetto in formato **MLT XLS** (//File// => //Export// => //MLT XML//) e quindi eseguire il rendering da riga di comando con **melt** (installato dal pacchetto **melt7**):
+<code bash>
+melt '2026-05_spagna.xml' -consumer 'avformat:2026-05_spagna.mkv' \
+    f=matroska \
+    acodec=aac \
+    ab=256k \
+    preset=slow \
+    vcodec=libx264 \
+    threads=0 \
+    vprofile=high \
+    crf=18
+</code>
+Il parametro principale per controllare la qualità del video è **crf**; a valori inferiori corrisponde una migliore qualità e un bitrare maggiore. Il valore predefinito per il codec x264 è 23, un valore di 18 dovrebbe corrispondere ad una compressione con perdita di qualità visivamente non percettibile. Nel nostro caso (video **2.7K@60**) si è ottenuto un bitrate variabile fra i **43** e i **60 Mb/s**.
+È possibile effettuare il rendering della sola traccia audio, evitando la codifica del video che è estremamente onerosa per la CPU:
+<code bash>
+melt '2026-05_spagna.xml' \
+    -consumer 'avformat:2026-05_spagna.wav' \
+    video_off=1 \
+    acodec=pcm_s16le
+</code>
+Questi alcuni parametri utili per **melt** quando si utilizza il //consumer avformat// (codifica tramite la libreria **ffmpeg**). La documentazione completa è su **[[https://www.mltframework.org/plugins/ConsumerAvformat/|www.mltframework.org]]**, i paraemtri per il codec H.264 di ffmpeg sono documentati su **[[https://trac.ffmpeg.org/wiki/Encode/H.264|trac.ffmpeg.org]]**.
+^ f=matroska      | Formato del container prodotto: mp4, matroska, ipod, ...  |
+^ vcodec=libx264  | Seleziona il codec video H.264.  |
+^ vprofile=high   | Il profilo definisce il set di funzionalità, algoritmi e strumenti di compressione che l'encoder H.264 può utilizzare. Serve a garantire la compatibilità del video con i dispositivi di riproduzione. Valori possibili: //baseline//, //main//, //high//, //high10//, ... Alcuni bitrate più elevati richiedono profili più elevati.  |
+^ preset=slow     | Determina la velocità di codifica e l'efficienza della compressione del codec H.264: ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow.  |
+^ crf=18          | Constant Rate Factor, definisce la qualità visiva percepita che si desidera ottenere nel video. Valori più bassi determinano una migliore qualità. 18 visivamente senza perdita (adatto all'archiviazione); 23 valore predefinito per x264; 28 buono per lo streaming.  |
+^ video_off=1     | Non processa il flusso video, utile ad esempio per effettuare la codifica del solo audio.  |
+^ vn=1            | Esclude il flusso video nell'output, ma il video viene comunque elaborato.  |
+^ acodec=aac      | Codec audio per l'output aac, pcm_s16le, ...  |
+^ ab=256k         | Bitrate per il flusso audio.  |
 ===== Impostazioni =====