8.4. Parameter Set Considerations (Considerazioni sugli insiemi di parametri)

8.4. Parameter Set Considerations (Considerazioni sugli insiemi di parametri)

Gli insiemi di parametri H.264 sono una parte fondamentale del codec video e vitali per il suo funzionamento (vedere la sezione 1.2). A causa delle loro caratteristiche e della loro importanza per il processo di decodifica, gli insiemi di parametri persi o trasmessi erroneamente possono difficilmente essere occultati localmente al ricevitore. Un riferimento a un insieme di parametri corrotto ha normalmente esiti fatali per il processo di decodifica. La corruzione può verificarsi, ad esempio, a causa della trasmissione errata o della perdita di una unità NAL di insieme di parametri, ma anche a causa della trasmissione intempestiva di un aggiornamento dell'insieme di parametri. Un aggiornamento dell'insieme di parametri si riferisce a una modifica di almeno un parametro in un insieme di parametri di immagine o di sequenza per cui l'identificatore dell'insieme di parametri di immagine o di sequenza resta invariato. Pertanto, le seguenti raccomandazioni sono fornite come guida per l'implementatore del mittente RTP.

Le NALU degli insiemi di parametri possono essere trasportate con tre principi diversi:

A. Utilizzo di un protocollo di controllo di sessione (fuori banda) prima della sessione RTP effettiva.

B. Utilizzo di un protocollo di controllo di sessione (fuori banda) durante una sessione RTP in corso.

C. All'interno del flusso di pacchetti RTP nel payload (in banda) durante una sessione RTP in corso.

Si raccomanda di implementare i principi A e B all'interno di un protocollo di controllo di sessione. SIP e SDP possono essere usati come descritto nel modello SDP Offer/Answer e nelle sezioni precedenti di questo memo. La sezione 8.2.2 include una discussione dettagliata sul trasporto in banda o fuori banda degli insiemi di parametri in SDP Offer/Answer usando i parametri di tipo media sprop-parameter-sets, sprop-level-parameter-sets, use-level-src-parameter-sets e in-band-parameter-sets. Questa sezione contiene linee guida su come i principi A e B dovrebbero essere implementati nei protocolli di controllo di sessione. È indipendente dal particolare protocollo usato. Il principio C è supportato dal formato di payload RTP definito in questa specifica. Esistono topologie come Topo-Video-switch-MCU [29] per cui l'uso del principio C può essere desiderabile.

Se viene usata la segnalazione in banda degli insiemi di parametri, le NALU degli insiemi di parametri di immagine e di sequenza DOVREBBERO essere trasmesse nel payload RTP usando un metodo affidabile di consegna RTP (vedere sotto), poiché la perdita di un insieme di parametri di uno dei due tipi probabilmente impedirà la decodifica di una porzione considerevole del corrispondente flusso di pacchetti RTP.

Se viene usata la segnalazione in banda degli insiemi di parametri, il mittente DOVREBBE tenere conto delle caratteristiche di errore e usare meccanismi per fornire un'alta probabilità di consegna corretta degli insiemi di parametri. I meccanismi che aumentano la probabilità di ricezione corretta includono ripetizione di pacchetti, FEC e ritrasmissione. L'uso di un protocollo di controllo fuori banda non affidabile presenta svantaggi simili alla segnalazione in banda (possibile perdita) e può inoltre portare a difficoltà di sincronizzazione (vedere sotto). Pertanto, NON È RACCOMANDATO.

Gli insiemi di parametri POSSONO essere aggiunti o aggiornati durante la durata di una sessione usando i principi B e C. È richiesto che gli insiemi di parametri siano presenti al decodificatore prima delle unità NAL che vi fanno riferimento. L'aggiornamento o l'aggiunta di insiemi di parametri può causare ulteriori problemi ; pertanto, DOVREBBERO essere considerate le seguenti raccomandazioni.

• Quando gli insiemi di parametri sono aggiunti o aggiornati, si DOVREBBE prestare attenzione a garantire che ogni insieme di parametri sia consegnato prima del suo utilizzo. Quando vengono aggiunti nuovi insiemi di parametri, si usano identificatori di insieme di parametri precedentemente inutilizzati. È comune che non sia presente sincronizzazione tra segnalazione fuori banda e traffico in banda. Se si usa la segnalazione fuori banda, si RACCOMANDA che un mittente non inizi a inviare NALU che richiedono gli insiemi di parametri aggiunti o aggiornati prima dell'acknowledgement di consegna dal protocollo di segnalazione.

• Quando gli insiemi di parametri sono aggiornati, si DOVREBBE tenere conto del seguente problema di sincronizzazione. Quando si sovrascrive un insieme di parametri al ricevitore, il mittente deve assicurarsi che l'insieme di parametri in questione non sia necessario a nessuna NALU presente nei buffer di rete o del ricevitore. Altrimenti può verificarsi una decodifica con un insieme di parametri errato. Per attenuare questo problema, si RACCOMANDA di sovrascrivere solo gli insiemi di parametri che non sono stati usati per un tempo sufficientemente lungo (per assicurarsi che tutte le NALU correlate siano state consumate) oppure di aggiungere un nuovo insieme di parametri (che può avere conseguenze negative per l'efficienza della codifica video).

Nota informativa: In alcune topologie come Topo-Video-switch-MCU [29], l'origine dell'intero insieme di parametri può provenire da più sorgenti che possono usare identificatori di insiemi di parametri non univoci. In questo caso, un'offerta può sovrascrivere un insieme di parametri esistente se non esiste altro meccanismo che consenta l'univocità degli insiemi di parametri nel canale fuori banda.

• In una sessione multipartecipante, un partecipante DEVE associare gli insiemi di parametri provenienti da fonti diverse all'identificazione della fonte ove possibile, ad esempio trasportando fuori banda gli insiemi di parametri, poiché fonti diverse usano tipicamente spazi di valori degli identificatori indipendenti.

• Aggiungere o modificare insiemi di parametri usando sia i principi B che C nella stessa sessione RTP può portare a inconsistenze degli insiemi di parametri a causa della mancanza di sincronizzazione tra il canale di controllo e il canale RTP. Pertanto, i principi B e C NON DEVONO essere entrambi usati nella stessa sessione a meno che non si possa fornire sincronizzazione sufficiente.

In alcuni scenari (ad esempio quando si usa solo il sottoinsieme di questa specifica di formato di payload corrispondente a H.241) o topologie, non è possibile impiegare la trasmissione fuori banda degli insiemi di parametri. In questo caso gli insiemi di parametri devono essere trasmessi in banda. Qui la sincronizzazione con i dati non insieme di parametri nel bitstream è implicita, ma la possibilità di una perdita deve essere presa in considerazione.

La probabilità di perdita DOVREBBE essere ridotta usando i meccanismi discussi sopra. In caso di rilevamento della perdita di un insieme di parametri, il ripristino può essere ottenuto usando una procedura di punto di aggiornamento del decodificatore, ad esempio usando il feedback RTCP Full Intra Request (FIR) [30]. Due esempi di procedure di punto di aggiornamento del decodificatore sono forniti nella sezione informativa 8.5.

• Quando gli insiemi di parametri sono inizialmente forniti usando il principio A e poi aggiunti o aggiornati in banda (principio C), vi è un rischio associato all'aggiornamento degli insiemi di parametri consegnati fuori banda. Se i ricevitori perdono alcuni aggiornamenti in banda (ad esempio a causa di una perdita o di un ingresso tardivo), tali ricevitori tentano di decodificare il bitstream usando parametri obsoleti. Si RACCOMANDA pertanto di partizionare gli ID degli insiemi di parametri tra insiemi fuori banda e in banda.