6. Codec-spezifische Überlegungen (Codec-Specific Considerations)
SDP (Session Description Protocol) ermöglicht die codec-unabhängige Angabe bevorzugter Videoauflösungen unter Verwendung des in [RFC6236] beschriebenen Mechanismus. WebRTC-Endpunkte können ein "a=imageattr"-Attribut senden, um die maximale Auflösung (Resolution) anzugeben, die sie empfangen möchten. Sender sollten dieses Attribut interpretieren und beachten, indem sie die codierte Auflösung auf die angegebene maximale Größe beschränken, da der Empfänger möglicherweise nicht in der Lage ist, höhere Auflösungen zu verarbeiten.
Darüber hinaus können Codecs codec-spezifische Mittel zur Signalisierung der maximalen Empfängerfähigkeiten in Bezug auf Auflösung, Bildrate (Frame Rate) und Bitrate (Bitrate) enthalten.
Sofern nicht anders im SDP signalisiert, müssen Empfänger von Videostreams in der Lage sein, Video mit einer Rate von mindestens 20 fps bei einer Auflösung von mindestens 320 Pixeln mal 240 Pixeln zu dekodieren (Decode). Diese Werte wurden auf der Grundlage der Empfehlungen in [HSUP1] ausgewählt.
Encoder (Encoder) werden ermutigt, die Codierung von Medien mit mindestens der gleichen Auflösung und den gleichen Bildraten wie oben angegeben zu unterstützen.
6.1. VP8
Für den VP8-Codec, definiert in [RFC6386], müssen Endpunkte die in [RFC7741] definierten Payload-Formate (Payload Format) unterstützen.
Zusätzlich zum [RFC6236]-Mechanismus müssen VP8-Encoder die von ihnen gesendeten Streams so einschränken, dass sie den von Empfängern in den entsprechenden max-fr- und max-fs-SDP-Attributen angegebenen Werten entsprechen.
Sofern nicht anders signalisiert, müssen Implementierungen, die VP8 verwenden, Pixel mit einem impliziten 1:1 (quadratischen) Seitenverhältnis (Aspect Ratio) codieren und dekodieren.
6.2. H.264
Für den [H264]-Codec müssen Endpunkte die in [RFC6184] definierten Payload-Formate unterstützen. Darüber hinaus müssen sie Constrained Baseline Profile Level 1.2 unterstützen und sollten H.264 Constrained High Profile Level 1.3 unterstützen.
Implementierungen des H.264-Codecs haben eine Vielzahl von optionalen Parametern verwendet. Um die Interoperabilität (Interoperability) zu verbessern, werden die folgenden Parametereinstellungen spezifiziert:
packetization-mode (Paketierungsmodus): Paketierungsmodus 1 muss unterstützt werden. Andere Modi können ausgehandelt und verwendet werden.
profile-level-id (Profil-Level-ID): Implementierungen müssen diesen Parameter im SDP enthalten und müssen ihn beim Empfang interpretieren.
max-mbps, max-smbps, max-fs, max-cpb, max-dpb und max-br:
Diese Parameter ermöglichen es der Implementierung anzugeben, dass sie bestimmte Funktionen von H.264 mit höheren Raten und Werten unterstützen kann, als durch ihr Level (festgelegt mit profile-level-id) signalisiert. Implementierungen können diese Parameter in ihr SDP aufnehmen, sollten sie aber beim Empfang interpretieren, damit sie das höchstmögliche Video in bester Qualität senden können.
sprop-parameter-sets: H.264 ermöglicht das Senden von Sequenz- und Bildinformationen sowohl in-band als auch out-of-band. WebRTC-Implementierungen müssen diese Informationen in-band signalisieren. Dies bedeutet, dass WebRTC-Implementierungen diesen Parameter nicht in das von ihnen generierte SDP aufnehmen dürfen.
H.264-Codecs können Supplemental Enhancement Information (SEI) "filler payload"- und "full frame freeze"-Nachrichten senden und müssen die korrekte Interpretation unterstützen. Die "full frame freeze"-Nachrichten werden in video-switching MCUs (Multipoint Control Unit) verwendet, um ein stabiles dekodiertes angezeigtes Bild beim Wechseln zwischen verschiedenen Eingabestreams sicherzustellen.
Wenn die Verwendung der Video Orientation (CVO) RTP-Header-Erweiterung nicht als Teil des SDP signalisiert wird, können H.264-Implementierungen Display Orientation SEI-Nachrichten (Display Orientation SEI Messages) senden und sollten die korrekte Interpretation unterstützen.
Implementierungen können "User data registered by Rec. ITU-T T.35"- und "User data unregistered"-Nachrichten senden und darauf reagieren. Selbst wenn sie nicht darauf reagieren, müssen Implementierungen darauf vorbereitet sein, solche Nachrichten ohne negative Auswirkungen zu empfangen.
Sofern nicht anders signalisiert, müssen Implementierungen, die H.264 verwenden, Pixel mit einem impliziten 1:1 (quadratischen) Seitenverhältnis codieren und dekodieren.