Come proiezionista al CineTeatro Don Bosco mi sono occupato principalmente della proiezione dei film e della preparazione delle playlist attraverso il Theater Management System (ovvero della predisposizione del film insieme ai trailer e della configurazione degli automatismi delle luci e del suono).
I CTDB Tools sono un insieme di strumenti che ho sviluppato per supportare e automatizzare alcune operazioni prima, durante e al termine della proiezione stessa.

Digital Cinema

La Digital Cinema Initiatives (DCI) è un'associazione dei maggiori studi cinematografici di Hollywood creata agli inizi degli anni 2000 e il cui obiettivo è la standardizzazione dei sistemi per il cinema digitale. Negli ultimi anni la pellicola 35mm è stata progressivamente sostituita dal Digital Cinema Package (DCP), una collezione di file che include tracce audio e video insieme ad altri file ausiliari. I DCP sono tipicamente distribuiti ai diversi cinema utilizzando connessioni satellitari o spediti tramite hard disk. Per poter fornire un certo livello di sicurezza (ad es. impedire proiezioni non autorizzate e copie illegali dei film), i DCP sono cifrati: ciascun cinema necessita di una Key Delivery Message (KDM), un piccolo file, fornito dal distributore, che contiene il materiale crittografico che permette ad uno specifico Theater Management System (TMS) di estrarre le chiavi di decifratura di un certo DCP per sbloccarne la riproduzione in una finestra temporale pre-definita. Maggiori informazioni sul Digital Cinema possono essere trovate qui.

Prima della proiezione

All'inizio di ogni settimana un corriere recapita un insieme di hard disk contenenti i DCP relativi alle proiezioni previste per il weekend. Il primo passo per la creazione di una playlist è l'ingest, ovvero la copia di tutti i DCP dagli hard disk al TMS. Dato che ciascun DCP occupa qualche centinaio di GB, l'ingest può durare diverse ore in tutto e potrebbe essere molto utile verificarne lo stato da remoto. Il TMS server non è direttamente connesso a Internet, però può essere raggiunto da un computer dual-homed, PC TR, che normalmente utilizziamo per gestire le KDM e i trailer. Per evitare di tener accesso PC TR 24 ore su 24, il primo tool che ho sviluppato è un Telegram Bot (CTDB Bot), in esecuzione su un Raspberry PI, che permette di verificare da remoto lo stato di PC TR e di accenderlo attraverso il Wake-on-LAN (WOL). All'accensione, PC TR notifica l'utente attraverso Telegram così da potersi collegare via TeamViewer e infine accedere al TMS server via VNC.
[Mostra più dettagli] Il Telegram Bot è in esecuzione su un Raspberry PI ed è implementato in Python tramite il modulo python-telegram-bot. Il Bot invia il magic packet per il WOL tramite etherwake e permette di verificare lo stato di PC TR utilizzando nmap. [Nascondi dettagli]

Qualche giorno prima della prima proiezione di un film, il distributore invia le KDM via email. Ogni KDM viene ingestata nel TMS server per sbloccare il film corrispondente e abilitare la riproduzione della playlist. Potrebbe succedere che una KDM contenga informazioni parzialmente errate. Dato che solo il distributore è in grado di fornire la nuova KDM, è molto importante poter verificarne le informazioni rapidamente. Ho sviluppato un tool (KDM Validator), eseguibile da PC TR, per automatizzare il processo di verifica.
[Mostra più dettagli] Il tool è implementato in Python e viene eseguito su PC TR. All'avvio, il programma scarica le email degli ultimi 7 giorni via IMAP insieme a tutti gli allegati XML e ZIP e li scompatta. Si collega poi al database del nostro sito Internet per scaricare gli ultimi film in programma (titolo e orari della prima ed ultima proiezione). Analizza quindi le KDM come file XML per estrarre le seguenti informazioni: il titolo del contenuto cifrato, la finestra di validità e il dispositivo per il quale è stata generata. Infine verifica automaticamente per ogni film in programma che (1) il numero di serie del nostro TMS appaia nella KDM, (2) la prima ed ultima proiezione cadano all'interno della finestra di validità della KDM e (3) ci sia una corrispondenza tra il titolo del contenuto cifrato e quello del film. Per quest'ultima verifica il programma scarica da Wikipedia e IMDB il titolo originale del film perchè spesso il nome del film viene riportato all'interno del nome del DCP in lingua originale, mentre il nostro sito presenta sempre il titolo tradotto in italiano. Ad esempio, come si vede nell'immagine, il titolo del DCP sbloccato dalla KDM per il film "Il Grande Gigante Gentile" contiene BFG e il titolo originale del film è proprio "The BFG". Se tutti i controlli hanno esito positivo, la KDM è pronta per essere ingestata nel TMS. [Nascondi dettagli]

Prima dell'era del cinema digitale, specialmente nei cinema più piccoli, la proiezione del film veniva spesso interrotta a metà da un intervallo per permettere al proiezionista di cambiare la bobina della pellicola caricando sulla macchina da proiezione il secondo tempo. Al giorno d'oggi diversi cinema hanno mantenuto questa pratica per permettere ancora agli spettatori di fare una breve pausa e accedere al bar. In teoria il documento tecnico fornito insieme all'hard disk potrebbe contenere un suggerimento sul momento migliore per inserire l'intervallo, ma nella pratica questo accade raramente. Per alcune ragioni pratiche (ad esempio per poter riutilizzare parti di un DCP o per trasferire un DCP usando un supporto con limiti sulla dimensione dei file) un DCP potrebbe essere giá suddiviso in sottosezioni, chiamate rulli (reels), che solitamente iniziano con un cambio scena (caratteristica comune ai vecchi rulli della pellicola). Ho sviluppato un tool (DCP Interval Finder) per estrarre le informazioni sui rulli dai DCP e fornire automaticamente un suggerimento sulla migliore tempistica per l'intervallo.
[Mostra più dettagli] Il tool é implementato in Python e dev'essere eseguito sul TMS server per poter aver accesso ai file XML dei DCP ingestati. Analizzando i file XML il tool estrae tutte le informazioni sui rulli e suggerisce come miglior tempo per l'intervallo l'istante di inizio del rullo piú vicino alla metá esatta del film. Questo tempo puó infine essere utilizzato per configurare gli automatismi del TSM (la pausa della riproduzione e l'accensione delle luci in sala) durante la creazione della playlist. [Nascondi dettagli]

Durante la proiezione

Prima dell'inizio della proiezione potrebbe essere utile mostrare agli spettatori (e specialmente ai loro genitori!) una stima dell'orario di termine della proiezione. La durata stessa del film non fornisce un'informazione sufficiente a causa di diverse incertezze sull'inizio della proiezione e sulle durate dei trailer e dell'intervallo. Ho sviluppato un tool (Ticket Office Display) per calcolare questa informazione direttamente dal TMS e mostrarla in cassa su un grande schermo.
[Mostra più dettagli]

Tre fonti di incertezza ci impediscono di sommare semplicemente la durata del film T_len all'inizio del film da programma T_sched. Prima di tutto, a seconda del numero di persone in fila in cassa, l'inizio della proiezione potrebbe essere leggermente ritardato. In secondo luogo, i trailer mostrati prima del film (seguiti a volte da una breve introduzione di un critico), posticipano ulteriormente l'inizio del film. Infine, l'intervallo in mezzo al film ha una durata variabile a seconda della fila al bar che dipende a sua volta dall'orario della proiezione (diversi spettacoli sono rivolti a diversi tipi di spettatori e con diversa affluenza).
Ho sviluppato un sistema per fornire tre diverse stime sul termine della proiezione con un livello di accuratezza crescente. Il back-end, sviluppato in Python, é in esecuzione su un Raspberry PI, mentre il front-end é sviluppato in PHP e combina le informazioni fornite dal nostro sito web con quelle del back-end per mostrare in cassa in ogni momento la miglior stima disponibile. Prima stima: questa misura, mostrata prima dell'inizio del film fino a 20 minuti dopo l'orario di inizio previsto, é ottenuta a partire dall'orario di inizio previsto sommando la durata del film (ricavata dal nostro sito web) e la durata media dell'intervallo per il particolare orario della proiezione (ad es. sabato sera o domenica pomeriggio).
Seconda stima: ogni notte un cron job in esecuzione sul Raspberry PI scarica dal nostro sito web le proiezioni previste per la giornata e programma il lancio dello script di back-end 20 minuti dopo l'inizio previsto per la proiezione. A quel punto possiamo essere certi che sia i trailer che l'introduzione del critico siano conclusi e possiamo quindi calcolare il vero inizio della proiezione. Il problema é che il nostro TMS non fornisce alcuna interfaccia per leggere il timestamp del contenuto in riproduzione. Lo script quindi estrae questa informazione connettendosi al TMS via VNC, facendo uno screenshot della GUI del TMS, ritagliando l'immagine e applicando infine una tecnica di Optical Character Recognition (OCR) tramite tesseract-ocr. Dal timestamp letto possiamo quindi ricostruire l'inizio effettivo della proiezione e fornire una miglior stima del termine della proiezione.
Terza stima: a partire dall'inizio previsto per la proiezione, il sistema attenda che sia trascorso il 75% della durata del film ed estrae nuovamente il timestamp come al passo precedente. A questo punto il sistema conosce anche la durata esatta dell'intervallo ed é in grado di compensarne l'effetto per fornire la stima finale del termine della proiezione.
NB la durata dell'intervallo estratta nell'ultimo passo viene anche utilizzata per aggiornare la durata media dell'intervallo in modo che, man mano che il sistema viene eseguito nel tempo, l'accuratezza delle prime due stime diventi sempre piú affidabile. [Nascondi dettagli]

Al termine della proiezione

Al termine del film, mentre vengono mostrati i titoli di coda, è necessario accendere le luci in sala e quest'ultima operazione puó essere automatizzata direttamente nella playlist del TMS fornendo l'esatto istante temporale. Questo timestamp, chiamato Credits Offset, viene talvolta riportato nel documento fornito insieme all'hard disk, ma non sempre questo succede. Abbiamo sviluppato un tool (CTDB Lights) per accendere e spegnere manualmente, anche da remoto, le luci di sala utilizzando le porte GPIO sul Raspberry PI implementando un sistema complementare a quello basato sulle porte GPIO del TMS.
[Mostra più dettagli] Mi sono occupato principalmente del lato software del sistema. Il tool é implementato in Python come server HTTP interfacciato con le porte GPIO tramite il modulo RPi.GPIO. CTDB Lights espone una web app accessibile da un qualsiasi computer connesso alla stessa LAN, rendendo il sistema di controllo luci utilizzabile anche durante gli spettacoli teatrali. Ho anche implementato un'applicazione Android che rende la web app accessibile anche al di fuori della LAN tramite SSH local port forwarding usando il Raspberry PI come jump server. Infine, il servizio é anche direttamente interfacciato al Telegram Bot. [Nascondi dettagli]