Nel contesto di FFmpeg, come funziona Trac (FFmpeg Bug Tracker)?

In FFmpeg, Trac (trac.ffmpeg.org) è il sistema web ufficiale di bug tracking e wiki. Viene utilizzato dalla community per segnalare malfunzionamenti, tracciare regressioni, richiedere nuove funzionalità ed erogare la documentazione tecnica del progetto.

1. Regole e Requisiti Prima di Aprire un Ticket

Per evitare segnalazioni non valide, la community di FFmpeg impone standard rigorosi per la segnalazione dei bug:

• Test sull'ultima versione di sviluppo (master): Il bug deve essere riprodotto obbligatoriamente utilizzando l'ultima versione Git master/development. I bug riscontrati su versioni obsolete o build distribuite da terzi non vengono presi in carico se non verificati sulla versione più recente.

• Comando esatto e log completo: È necessario fornire il comando eseguito e l'output integrale del terminale (senza tagli o abbreviazioni), possibilmente impostando il log verboso (ffmpeg -v 9 -loglevel 99 ...) oppure generando il file di log tramite il flag -report.

• File di esempio (Samples): Se il problema riguarda un file specifico, occorre allegare un campione riproducibile.

  • Per file inferiori a 2.5 MB, è possibile allegarli direttamente nel ticket.

  • Per file più grandi (fino a 1 GB), viene utilizzato l'uploader dedicato di VideoLAN (streams.videolan.org/upload/) specificando il numero di ticket Trac.

• Debug e Crash (gdb / valgrind): In caso di crash dell'applicazione, il segnalatore deve fornire il backtrace (bt) e il disassembly generati tramite gdb eseguito sul binario di debug ffmpeg_g, o l'output di valgrind.

• Identificazione delle regressioni (git bisect): Se un comando funzionava in passato e ha smesso di funzionare, viene richiesto di individuare il commit esatto che ha introdotto il problema tramite git bisect.

2. Struttura e Campi del Ticket

Durante la creazione di una segnalazione su Trac, occorre compilare diversi campi chiave:

Campo
Descrizione

Type
defect (bug vero e proprio), enhancement (richiesta di funzionalità) o task.

Component
Componente interessato (es. ffmpeg, ffprobe, librerie come libavcodec, libavformat, libavfilter, o sottosistemi specifici per sistema operativo/hardware).

Version
Versione specifica di FFmpeg in cui si presenta il problema.

Priority / Severity
Grado di urgenza o impatto dell'errore.

Keywords
Tag per facilitare la ricerca (es. h264, vaapi, subtitles, crash).

3. Ciclo di Vita di un Ticket (Workflow)

1. New / Open: Il ticket viene creato ed entra nella coda di analisi degli sviluppatori o dei maintainer del componente.

2. Assigned: Un contributore o maintainer si fa carico del ticket per investigare o preparare una patch.

3. Closed: Il ticket viene chiuso quando il problema viene risolto o archiviato. Le risoluzioni tipiche includono:

   • fixed: Il bug è stato risolto (solitamente accompagnato dal riferimento al commit Git della patch).

   • invalid: Informazioni insufficienti, log mancanti o mancato rispetto delle linee guida.

   • duplicate: Segnalazione già presente in un altro ticket.

   • wontfix: Comportamento intenzionale o funzionalità non supportata dal progetto.

   • worksforme: Il problema non è stato riprodotto dagli sviluppatori.

4. Integrazione con Wiki e Sistema di Sviluppo

• Piattaforma Wiki: Trac funge anche da hub documentale principale per la compilazione (guide per Linux, Windows, macOS), guide all'uso dei codec (H.264, AV1, AAC) ed esempi avanzati di filtri o streaming.

• Cross-Referencing: Grazie alla sintassi TracLinks, è possibile collegare direttamente ticket (#1234), commit Git (r12345 o hash del commit) e pagine wiki.

• Integrazione con la Mailing List: Le discussioni sulle patch e lo sviluppo del codice non avvengono direttamente su Trac, ma sulla mailing list ufficiale (ffmpeg-devel). Trac serve principalmente come registro per tracciare i problemi non ancora risolti