Ancillary data
# Ancillary data

Il termine inglese Ancillary data (abbreviato talvolta ANC data e reso spesso in italiano come dati ausiliari) indica, nel contesto della tecnologia televisiva, l'integrazione e la trasmissione di informazioni non video all'interno di flusso video. Il caso più comune e più diffusamente usato è l'integrazione di canali di audio digitale in un segnale SDI.

Gli Ancillary data sono definiti dallo standard SMPTE 291M: Ancillary Data Packet and Space Formatting.

## Dettagli tecnici

### Posizionamento

I pacchetti dei metadati possono essere posizionati ovunque all'interno di un flusso SDI, con le seguenti eccezioni:

* Linee identificate come punti di commutazione (definiti per i diversi standard video in SMPTE RP168), dove potrebbero essere persi in caso di commutazione tra due sorgenti.
* Area del video attivo.
* Tra i pacchetti TRS (timing reference signal).

Una divisione comunemente applicata è tra due tipi di pacchetti, in base al posizionamento. Alcuni tipi specifici di Ancillaty data sono spesso obbligatoriamente di uno o dell'altro tipo.

* I pacchetti posizionati nella zona della cancellazione orizzontale (dopo il pacchetto EAV ma prima del SAV, indipendentemente dal numero di linea, sono chiamati horizontal ancillary data o HANC. I pacchetti HANC sono di solito usati per i dati con maggiore larghezza di banda o che devono essere sincronizzati con una particolare linea. Il tipi di HANC più comune è l'audio embedded.
* I pacchetti posizionati nella zona della cancellazione verticale, dopo il pacchetto SAV e prima del pacchetto EAV, sono chiamati vertical ancillary data o VANC. I pacchetti VANC sono usati per i pacchetti a banda stretta o per i dati che richiedono un aggiornamento solo ogni quadro, per esempio i sottotitoli e i pacchetti VPID sono di solito VANC.

I pacchetti posizionati nelle zone appartenenti sia agli intervalli orizzontali che a quelli verticali ono considerati HANC.

### Formato dei pacchetti

Tutti i pacchetti ANC devono iniziare con una sequenza di start; per le interfacce a componenti (l'unico tipo di interfaccia video seriale in uso oggi), questa sequenza è 0 0x3FF 0x3FF, sequenza che non è consentita in nessun altro punto del flusso video.

Dopo la sequenza di start, seguono tre parole:

* Data Identifier (DID)
* Secondary Data Identifier (SDID) oppure Data Block Number (DBN)
* Data Count (DC).
* Da 0 a 255 (inclusive) User Data Words (UDW)
* Checksum (CS).

**DID**

Il Data Identifier (insieme allo SDID, se usato), indica a quale tipo di dati corrisponde il pacchetto. I Data Identifier assumono valori da 1 a 255, lo 0 è riservato. Dal momento che l'interfaccia SDI è a 10 bit, la parola è codificata come segue:

* Bit 0-7 (bit 0 come LSB - least significant bit): valore del DID.
* Bit 8: bit di parità (pari) dei bit 0-7.
* Bit 9: inverso del bit 8.

Quindi un valore esadecimale 61 è codificato come 161, mentre 63 come 263. Si noti come lo schema di codifica garantisce che non sia mai utilizzato un valore riservato nell'interfaccia (0-3 e 1020-1023).

Se il DID è 128 (80 esadecimale) o maggiore, il pacchetto viene definito pacchetto di tipo 1: in questo caso il DID è tutto ciò che serve per identificare il pacchetto e la parola seguente è un Block Data Number. Viceversa, se il DID è inferiore a 128, il pacchetto è un pacchetto di tipo 2 e le parole che seguono sono i Secondary Data Identifier; il pacchetto è identificato dalla coppia DID e SDID.

**SDID**

Lo SDID è velido solo se il DID è inferiore a 128 (80 esadecimale). Lo SDID è nominalmente un valore a 8 bit, da 0 a 255. è codificato nello stesso modo del DID.

Per esempio, una coppia DID/SDID di 161 101 (esadecimali) corrispondono a un DID pari a 61 e uno SDID pari a 1 (una volta rimossi i due MSB: questi due valori sono definiti dallo standard SMPTE 334M, e contengono i sottotitoli delle trasmissioni DTV.

**DBN**

Valido solo per DID superiori a 128 (80 esadecimale), il DBN è usato per identificare pacchetti multipli dello stesso tipo. Per ogni pacchetto il DBN è incrementato di uno, nell'intervallo da 1 a 255 (da 1 a FF esadecinale), il valore 0 è riservato, quindi "illegale". Il DBN è un valore a 8 bit, codificato nello stesso modo dello SDID.

**DC**

Il Data Count è un valore a 8 bit, codificato allo stesso modo del DID, che indica quanti UDW seguono, da 0 a 255.

**UDW**

User data words, il contenuto attivo del pacchetto ANC, cioè i dati veri e propri. Non esiste una definizione a livello SMPTE dei dati contenuti in questi pacchetti, l'unica restrizione è che non possono contenere valori riservati, (da 0-3 a 1020-1023). Molti dei dati sono codificati a 8 bit nello stesso modo degli header.

**Checksum**

Il checksum è calcolato tramite la somma (modulo 512) dei bit 0-8 (quindi escludendo il 9), di tutte le parole nel pacchetto, tranne la sequenza di start. Il bit 9 del checksum è il bit 8 invertito. La parola di checksum non contiene un bit di parità ma tutti i bit di parità delle altre parole sono incluse nel calcolo.

## Utilizzo

Gli usi degli Ancillary data sono molteplici:

### Audio embedded

L'audio embedded (reso in italiano anche come audio embeddato) è un flusso audio trasportato all'interno di un flusso video. Di solito, anche se non necessariamente, si tratta dei canali audio associato al video in questione. Due standard SMPTE, SMPTE 272M (SD) e SMPTE 299M (HD) definisco il modo in cui i dati audio sono inseriti nel video. Entrambi gli standard prevedono fino a 16 canali di audio digitale PCM, divisi in quattro gruppi e di solito codificati nel formato AES3. In entrambi i casi, i pacchetti audio sono posizionati come HANC nello spazio dei dati Cb/Cr (crominanza).

Gli standard definiscono anche dei pacchetti di controllo audio, inseriti nello spazio dei dati Y e inseriti su ogni semiquadro due linee dopo il punto di commutazione. Questi pacchetti contengono metadati relativi all'audio, come le temporizzazioni, i canali presenti, ecc.

I pacchetti audio sono di tipo 1.

### EDH

I pacchetti EDH sono utilizzati per la rivelazione e la gestioni di errori di trasmissione sui flussi video a definizione standard. Non sono necessari sui flussi HD poiché questi ultimi integrano un controllo CRC.

