6. Considerazioni specifiche del codec (Codec-Specific Considerations)
SDP (Session Description Protocol) consente l'indicazione indipendente dal codec delle risoluzioni video preferite utilizzando il meccanismo descritto in [RFC6236]. Gli endpoint WebRTC possono inviare un attributo "a=imageattr" per indicare la risoluzione (Resolution) massima che desiderano ricevere. I mittenti dovrebbero interpretare e rispettare questo attributo limitando la risoluzione codificata alla dimensione massima indicata, poiché il ricevitore potrebbe non essere in grado di gestire risoluzioni più elevate.
Inoltre, i codec possono includere mezzi specifici del codec per segnalare le capacità massime del ricevitore per quanto riguarda risoluzione, frequenza fotogrammi (Frame Rate) e bitrate (Bitrate).
Se non diversamente segnalato nell'SDP, i destinatari di flussi video devono essere in grado di decodificare video a una frequenza di almeno 20 fps a una risoluzione di almeno 320 pixel per 240 pixel. Questi valori sono selezionati in base alle raccomandazioni in [HSUP1].
Gli encoder (Encoder) sono incoraggiati a supportare la codifica di media con almeno la stessa risoluzione e le stesse frequenze fotogrammi citate sopra.
6.1. VP8
Per il codec VP8, definito in [RFC6386], gli endpoint devono supportare i formati di payload (Payload Format) definiti in [RFC7741].
Oltre al meccanismo [RFC6236], gli encoder VP8 devono limitare i flussi che inviano per conformarsi ai valori indicati dai ricevitori negli attributi SDP max-fr e max-fs corrispondenti.
Se non diversamente segnalato, le implementazioni che utilizzano VP8 devono codificare e decodificare pixel con un rapporto d'aspetto (Aspect Ratio) implicito di 1:1 (quadrato).
6.2. H.264
Per il codec [H264], gli endpoint devono supportare i formati di payload definiti in [RFC6184]. Inoltre, devono supportare Constrained Baseline Profile Level 1.2 e dovrebbero supportare H.264 Constrained High Profile Level 1.3.
Le implementazioni del codec H.264 hanno utilizzato un'ampia varietà di parametri opzionali. Per migliorare l'interoperabilità (Interoperability), vengono specificati i seguenti parametri:
packetization-mode (modalità di pacchettizzazione): La modalità di pacchettizzazione 1 deve essere supportata. Altre modalità possono essere negoziate e utilizzate.
profile-level-id (identificatore profilo-livello): Le implementazioni devono includere questo parametro nell'SDP e devono interpretarlo quando lo ricevono.
max-mbps, max-smbps, max-fs, max-cpb, max-dpb e max-br:
Questi parametri consentono all'implementazione di specificare che possono supportare determinate caratteristiche di H.264 a velocità e valori superiori rispetto a quelli segnalati dal loro livello (impostato con profile-level-id). Le implementazioni possono includere questi parametri nel loro SDP, ma dovrebbero interpretarli quando li ricevono, consentendo loro di inviare il video di qualità più elevata possibile.
sprop-parameter-sets: H.264 consente di inviare informazioni di sequenza e immagine sia in banda che fuori banda. Le implementazioni WebRTC devono segnalare queste informazioni in banda. Ciò significa che le implementazioni WebRTC non devono includere questo parametro nell'SDP che generano.
I codec H.264 possono inviare e devono supportare la corretta interpretazione dei messaggi Supplemental Enhancement Information (SEI) "filler payload" e "full frame freeze". I messaggi "full frame freeze" vengono utilizzati nelle MCU (Multipoint Control Unit) di commutazione video, per garantire un'immagine visualizzata decodificata stabile durante la commutazione tra vari flussi di input.
Quando l'uso dell'estensione header RTP di orientamento video (CVO) non è segnalato nell'SDP, le implementazioni H.264 possono inviare e dovrebbero supportare la corretta interpretazione dei messaggi SEI di orientamento display (Display Orientation SEI Messages).
Le implementazioni possono inviare e agire su messaggi "User data registered by Rec. ITU-T T.35" e "User data unregistered". Anche se non agiscono su di essi, le implementazioni devono essere preparate a ricevere tali messaggi senza effetti negativi.
Se non diversamente segnalato, le implementazioni che utilizzano H.264 devono codificare e decodificare pixel con un rapporto d'aspetto implicito di 1:1 (quadrato).