Type a search term to find related articles by LIMS subject matter experts gathered from the most trusted and dynamic collaboration tools in the laboratory informatics industry.
| VP9 | |
|---|---|
| |
| Dateiendung: | webm
|
| Entwickelt von: | Google Inc. |
| Erstveröffentlichung: | 13. Dezember 2012 |
| Art: | lossy Video |
| Enthalten in: | WebM, IVF |
| Erweitert von: | VP8 |
| Erweitert zu: | AV1 |
| Standard(s): | (Bitstream Specification) |
| webmproject.org/vp9 | |
VP9 ist ein lizenzgebührenfreies, offenes Format vorrangig für komprimierte Videodaten. Es ist nach VP8 die letzte offizielle Ausgabe der von Google aufgekauften TrueMotion-Videoformatreihe (VPx) und konkurriert mit H.265/HEVC.
VP9 wurde zunächst hauptsächlich auf Googles Video-Plattform YouTube verwendet.[1][2]
VP9 lässt sich zusammen mit Opus in WebM-Dateien speichern.[3] Safari, Chromium, Chrome, Vivaldi, Firefox und Opera unterstützen das VP9-Format für HTML5 Video.[4][5][6][7]
Teile des Verfahrens unterliegen Patenten von Google. Das Unternehmen räumt jedem unter Gegenseitigkeitsbedingung dauerhaft und unwiderruflich die freie Nutzung betroffener eigener Patente ein, solange er nicht seinerseits Patentforderungen einklagt.[8]
VP9 ist auf die Kodierung von Material in Auflösungen jenseits Full HD (wie etwa UHD) ausgerichtet und ermöglicht bei Bedarf auch verlustfreie Kompression.
Es gibt verschiedene Varianten des VP9-Formates, die sogenannten Kodierungsprofile, die von der Grundversion, dem Profil 0 (verbindliches Minimum für Hardware-Implementierungen), hin zu Profil 3 zunehmend mehr Merkmale erlauben:
VP9 unterstützt die Farbräume Rec. 601, Rec. 709, Rec. 2020, SMPTE-170, SMPTE-240 und sRGB.[9][10]
In einem 2014 durchgeführten subjektiven Qualitätsvergleich mit den Referenzkodierern für HEVC (HM 15.0), MPEG-4 AVC/H.264 (JM 18.6) und VP9 (libvpx 1.2.0 mit vorläufiger VP9-Unterstützung) benötigte VP9 noch ähnlich H.264 etwa doppelt so viel Bitrate für mit HEVC vergleichbare Videoqualität, wobei VP9 für synthetisches Bildmaterial ähnlich HEVC abschnitt.[11] Dagegen ergab ein anderer subjektiver Qualitätsvergleich von 2014 in höheren Qualitätsbereichen bei VP9 und HEVC eine vergleichbare Einsparung von 40 bis 45 % gegenüber H.264.[12]
Nach algorithmischer Bewertung mittels SSIM erreichte VP9 mit libvpx im September 2015 in einem Test gegenüber dem besten H.264-Kodierer x264 eine um 50 % verbesserte Bitrateneffizienz bei 10 bis 20 Mal höherer Kodierzeit. Bei beliebiger gleicher Kodiergeschwindigkeit wurde immer noch um 20 bis 30 % bessere Effizienz erreicht.[13] Andere Tests zeigen mit x264 vergleichbare Kodiergeschwindigkeit, wenn Parallelisierung der Ausführung erzwungen wird. Nach der objektiven Metrik VQM lieferte der VP9-Referenzkodierer Anfang 2015 gleiche Videoqualität wie die besten HEVC-Implementierungen und kodierte in der Regel schneller.[14]
Der Rechenaufwand beim Dekodieren liegt in der Praxis etwas über 20 Prozent höher als bei H.264 mit libvpx, während der proprietäre Ittiam-Dekodierer eine um 30 Prozent niedrigere CPU-Last zeigt als libvpx.[15] Mit dem neueren Dekodierer ffvp9 soll vergleichbare oder schnellere Dekodierung als bei H.264 (ffh264) und um 25 bis 50 % massiv schnellere Dekodierung als mit libvpx erreicht werden.[16]
VP9 ist ein klassisches blockbasiertes Transformations-Verfahren. Das Bitstromformat ist im Vergleich zu ähnlich bitrateneffizienten Formaten wie HEVC relativ einfach.[17]
Als größte Formatverbesserung gegenüber dem direkten Vorgängerformat VP8 können Transformationsblöcke zur Vorhersage zu größeren Makroblöcken von nun bis zu 64×64 Bildpunkten zusammengefasst werden. Dies ist besonders bei hochaufgelösten Videos nützlich.[2] Weiterhin wurde die Vorhersage von Bewegungsvektoren verbessert.[18] Neue Kodierungswerkzeuge umfassen außerdem:
Um Parallelverarbeitung von Einzelbildern zu ermöglichen, können diese entlang Superblockgrenzen in bis zu 4 Reihen von 256 bis 4096 Bildpunkten breiten, gleichmäßigen Kacheln aufgeteilt werden, wobei jede Spalte unabhängig kodiert wird. Dies ist verpflichtend für Auflösungen oberhalb von 4096 Punkten Bildbreite. Die Kopfdaten der Kacheln enthalten die Kachelgröße in Bytes, sodass Dekodierer Kacheln direkt überspringen und jede Kachelspalte in einem separaten Ausführungsstrang dekodieren können.
Das Bild wird weiter in Superblöcke genannte Kodierungseinheiten von 64 auf 64 Bildpunkten unterteilt, welche adaptiv in einer Quaternärbaum-Struktur unterteilt werden.[19][20] Sie können entweder in horizontaler oder vertikaler oder beiden Richtungen unterteilt werden; quadratische (Unter-)Einheiten können rekursiv bis zu einer Blockgröße von 4 auf 4 Bildpunkten weiter unterteilt werden. Untereinheiten werden in Rasterlesereihenfolge kodiert: von links nach rechts, von oben nach unten.
Beginnend an Schlüsselbildern halten Dekodierer 8 Einzelbilder für die Nutzung als Referenzbilder oder spätere Anzeige gepuffert. Übertragene Einzelbilder signalisieren, welcher der Puffer mit ihnen überschrieben werden soll und können optional in einen der Puffer dekodiert werden ohne angezeigt zu werden. Der Kodierer kann minimale Einzelbilder senden, die einzig die Anzeige eines der Pufferinhalte auslösen („skip frame“). Jedes Inter-Bild kann bis zu 3 der gepufferten Einzelbilder für zeitliche Vorhersage referenzieren. In einem Kodierungsblock können für die Berechnung von Vorhersagebilddaten räumlich verschobene Inhalte (Bewegungsausgleich) von einem oder zwei Einzelbildern (zusammengesetzte Vorhersage, mit Durchschnittsbildung) verwendet werden. Die (idealerweise geringe) verbleibende Differenz (Delta-Kodierung) der berechneten Vorhersage zum eigentlichen Bildinhalt wird transformiert mittels einer DCT oder ADST (für Kantenblöcke) und quantisiert.
Eine B-Frame-artige Struktur kann in sogenannten Superframes unter Erhalt der ursprünglichen Einzelbildreihenfolge im Bitstrom kodiert werden. Versteckte Alternate-Reference-Bilder können zusammengepackt werden mit einem gewöhnlichen Inter-Bild und einem skip frame, der die Anzeige des Inhalts des vorhergehenden versteckten Altref-Bildes direkt nach dem Inter-Bild auslöst.[17]
VP9 ermöglicht verlustfreie Kodierung, indem bei niedrigster Quantisierungsstufe (q-Index 0) zusätzlich ein in 4×4-Blöcken Hadamard-transformiertes (WHT) Restsignal übertragen wird.[21][22]
In Containerformaten werden VP9-Ströme mit der FourCC VP90 (beziehungsweise zukünftig eventuell VP91, ...) oder VP09 gekennzeichnet.[23]
Um wahlfreien Zugriff zu ermöglichen, müssen VP9-Rohdaten gekapselt werden; entweder in Googles Matroska-basiertem WebM-Format (.webm) oder dem älteren minimalistischen Format Indeo video file (IVF), welches von libvpx traditionell unterstützt wird.[17]
[24]
Adobe Flash, in dem bis VP7 traditionell VPx-Formate zum Einsatz kamen, wurde nie auf VP8 oder VP9, sondern stattdessen auf H.264 aufgerüstet. Daher drang VP9 oft erst mit der graduellen Umstellung von Flash auf die zur VP9-Markteinführung noch unreife HTML5-Technik in entsprechende Webvideoanwendungen vor. Trends hin zu UHD-Auflösungen, höherer Farbtiefe und weiteren Gamuts treiben zum Umstieg auf neue, darauf ausgelegte Videoformate. Die durch die Alliance for Open Media klare Unterstützungs- und Entwicklungsperspektive sowie die teure und unübersichtliche Lizenzierungssituation von HEVC lassen erwarten, dass Anwender der bisher führenden MPEG-Formate dabei anstatt einer Aufrüstung auf HEVC vermehrt auf die lizenzkostenfreien Alternativformate der VPx- beziehungsweise nunmehr AVx-Reihe umsteigen.[25]
VP9 ist implementiert in den Webbrowsern
Im Internet Explorer fehlt jegliche VP9-Unterstützung, kann jedoch über ein Plugin nachgerüstet werden.[28] Auf Datenbasis von StatCounter konnten im März 2016 auf Desktop- und Notebook-Systemen geschätzte 65 bis 75 % benutzter Webbrowser VP9-Videos in HTML5-Webseiten abspielen.[15]
Das Format wird hauptsächlich bei Googles Video-Plattform YouTube genutzt,[1] wo seit 2015 in großem Stil VP9-kodierte Videos ausgeliefert werden.[2]
Android unterstützt VP9-Dekodierung ab Version 4.4 („KitKat“).[29]
JW Player unterstützt VP9 in seinem vielgenutzten SaaS-HTML5-Videoplayer.[15]
Seit 2016 bietet eine Reihe von Cloud-Kodierungsdiensten (Amazon, Brightcove, castLabs, JW Player, Telestream, Wowza) VP9-Kodierung an.[15]
Die Referenzimplementierung findet sich seit dem 17. Juni 2013 in der von Google herausgegebenen Programmbibliothek libvpx und wurde in Version 1.3 vom 2. Dezember 2013 offiziell eingeführt.[30] Sie wird als freie Software auch im Quelltext unter den Bedingungen der modifizierten BSD-Lizenz veröffentlicht.[31] Mitgeliefert werden die darauf aufbauenden Kommandozeilenwerkzeuge vpxenc und vpxdec.
Es existiert je ein Modus für Kodierung in einem einzigen und in zwei Durchläufen, wobei der Einzeldurchlaufmodus als kaputt gilt und keine brauchbare Kontrolle über die Zielbitrate bietet.[32][15]
Das freie Multimediakonvertierungswerkzeug FFmpeg enthält seit Oktober 2013 den eigenen Dekodierer ffvp9, der 25 bis 50 % schneller arbeitet als libvpx und vergleichbar schnell (gleiche Bitrate) beziehungsweise etwa 10 % schneller (gleiche Qualität) als ffh264.[33][16]
Es existiert ein von Ittiam, ARM und Google entwickelter für ARM-Cortex-A-Architekturen mit ARM-Mali-GPUs optimierter VP9-Dekodierer.[34][35]
Viele Kritikpunkte an VP9 beschränkten sich auf die Mängel des Referenzkodierers. Im Mai 2016 wurde mit Eve („Efficient Video Encoder“) ein proprietärer alternativer Kodierer herausgebracht, der als überlegen gilt.[36]
Seit Februar 2019 entwickelt Intel öffentlich einen weiteren Encoder namens SVT-VP9.[37][38]
Die meisten führenden Prozessoren für Mobilgeräte bieten Hardware-Unterstützung für VP9-Dekodierung. Hardware-Beschleunigung für Dekodierung findet sich in Chips von AMD (Polaris P10/11 und neuer)[39], Allwinner, MediaTek, Nvidia, Qualcomm und Rockchip. Neuere Chips von ARM, Samsung und Intel (Kabylake-Architektur [Q3 2016] und spätere) unterstützen auch VP9-Kodierung.[40]
Alle AMD GCN GPUs unterstützen VP9 decoding per GPU in Software und entlasten so die CPU.[39]
VP9 ist die letzte offizielle Ausgabe der TrueMotion-Videoformatreihe, die Google 2010 für 134 Millionen Dollar mit dessen Herstellerunternehmen On2 Technologies aufkaufte.[41] Die Entwicklung von VP9 begann im dritten Quartal 2011 unter den Projektnamen VP-Next und Next Gen Open Video (NGOV).[42] Unter anderem wurde eine gegenüber dem Vorgängerformat VP8 verdoppelte Bitrateneffizienz angestrebt (zum Beispiel Halbierung der Bitrate bei gleicher Videoqualität).[43] Zukünftig soll auch die Bitrateneffizienz von HEVC unterboten werden. Eine noch nicht endgültige Version von Ende 2011 von VP9 soll noch um 7 % schlechter gewesen sein als HEVC.[44][45] Erreicht werden sollten diese Verbesserungen durch ausgefeiltere Techniken im Bereich der Vorhersage und Kodierung.[17]
Ende 2012 wurde Unterstützung für VP9 in Chromium eingebaut.[46]
2013 wurde eine um VP9- und Opus-Unterstützung erweiterte Version des WebM-Formats veröffentlicht.
Im März 2013 gab die MPEG Licensing Administration eine angekündigte Geltendmachung angeblicher Patentansprüche gegen VP8 und dessen Nachfolgeformate auf, nachdem das Justizministerium der Vereinigten Staaten Ermittlungen wegen eventueller Behinderung von Konkurrenz eingeleitet hatte.[47][48][49]
Im Juni 2013 wurde mit dem Kodierungsprofil 0 ein grundlegender erster Teil des Bitstromformates festgelegt.
In Version 1.4.0 („Indian Runner Duck“) vom 3. April 2015 wurden Unterstützung für die Farbmodelle YUV 4:2:2 und 4:4:4 sowie für 10 und 12 Bit Farbtiefe (Profile 1, 2, 3) nachgerüstet und der Codec beschleunigt.
VP9 wurde einer entsprechenden Arbeitsgruppe der Internet Engineering Task Force (IETF), die seit 2012 an einem zukünftigen Internetstandard für Videokomprimierung arbeitet, als Arbeitsgrundlage angeboten.[42]
VP10 wurde unter der Leitung von Alex Converse entwickelt.[50] Als primäres Entwicklungsziel wird die Verbesserung der Komprimierungsleistung genannt. Für VP10 sollen VP9 viele neue Kodierungsmittel hinzugefügt werden, die jeweils nur noch höchstens wenige Prozent, jedoch in der Summe eine signifikant höhere Bitrateneffizienz ermöglichen.[1]
Am 12. September 2014 gab Google bekannt, dass die Entwicklung von VP10 begonnen habe und dass nach der Veröffentlichung von VP10 jeweils nach 18 Monaten eine Veröffentlichung eines Videostandards erfolgen solle.[29] Im August 2015 begann die Veröffentlichung von Code für VP10.[51] Im Gegensatz zu der Entwicklung von VP9 geschieht die Entwicklung von VP10 seither öffentlich. Die am 1. September 2015 verkündete Mitgründung der Alliance for Open Media (AOMedia) durch Google demonstrierte Interesse an der Entwicklung eines einheitlichen Standards für ein neues Videokomprimierungsverfahren. Doch eine Bekanntgabe konkreter, aktiver Zusammenarbeit mit anderen bestehenden Initiativen wie der bereits aktiven IETF-Arbeitsgruppe NetVC wurde zunächst vermieden.[50] Später einigte sich die AOMedia auf VP10 als Basis für deren neue Videoformate. Die offizielle Veröffentlichung von VP10 wurde zu Gunsten von AV1 aufgegeben, der ersten Ausgabe der Videoformatreihe AOMedia Video (AVx).
LIMS forum content by LIMS forum members is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. Based on a work at www.limsforum.com.
