Thema: Aktuelle Videocodecs im Vergleich

[SiLæncer]

Ein spannender Wettstreit um die effizienteste Video-Kodierung ist entbrannt: Microsofts VC-1 und H.264/AVC treten an, die aktuellen MPEG-4-Platzhirsche DivX 6, Nero Digital, XviD & Co. alt aussehen zu lassen. Doch halten die Werbeversprechen der Codec-Anbieter auch der Realität stand? 13 aktuelle Kompressionisten mussten sich unserem Testparcours stellen.

Trotz Double-Layer-DVDs und dickeren DSL-Anbindungen ersinnen die Codec-Entwickler immer effizientere Kodierverfahren, denn aktuelle Kompressionsformate müssen Allrounder sein: Sie sollen nicht nur das DVD-Video in ordentlicher Qualität auf CD schrumpfen, sondern auch bei niedrigsten Bitraten auf dem Handy-Display eine gute Figur machen.

Zwei Jahre nach dem letzten Codec-Vergleich [1] buhlen weit mehr Anbieter um die Gunst der Nutzer. Zu DivX und seinem Open-Source-Konkurrenten XviD gesellten sich unter anderem Nero Digital (MPEG-4) und die brandneue Codec-Suite HDX4. Sie alle beruhen auf dem MPEG-Standard „MPEG-4 Part 2 Video Coding“ und nutzen dessen Advanced Simple Profile (ASP) zur Kodierung der Inhalte. Zudem bringen sie in der Regel für Otto-Normal-Kodierer gedachte Hardware-Profile mit, die DivXNetworks maßgeblich einführte, um die reibungslose Wiedergabe der so erzeugten Videos auf Standalone-DVD-Playern zu gewährleisten. Das Feld der MPEG-4-Protagonisten rundet der MPEG-4-Veteran 3ivx ab, der in der Kodierszene erneut Beachtung findet.

Besonders hoch im Kurs steht momentan der gemeinsame Standard von ITU-T und MPEG, H.264/Advanced Video Coding (AVC), der neben Microsofts Codec-Kreation als einer der obligatorischen Codecs für die DVD-Nachfolger HD-DVD und Blu-ray Disc vorgesehen ist. Ging in [1] mit Vanguards VSS264 nur ein einziger H.264/AVC-Codec an den Start, stellen die Verfechter des neuen Videostandards diesmal einen Großteil: Nero, MainConcept, Sorenson, Videosoft (ehemals Vanguard Software) und das VideoLAN-Team schicken ihre Implementierungen ins Rennen.

Cyberlinks PowerEncoder AVC disqualifizierte sich schon bei den ersten Vorabtests, weil er sich partout nicht einmal annähernd an Bitraten-Vorgaben halten wollte. Laut Cyberlink handelt es sich im Wesentlichen um eine Technologie-Demo, die Bitratenkontrolle soll in Version 2 eingebaut werden - im Januar 2006. Dass Cyberlink den Encoder dennoch für immerhin 45 Euro verkauft, ist ein starkes Stück.

Mit QuickTime 7 Pro, das Teil von Mac OS X 10.4 (Tiger) ist, unterstützt auch Apple H.264/AVC. Leider kam es für diesen Test ein wenig zu spät. Wir testen Apples Implementierung jedoch nach, sobald sie verfügbar ist.

Die Fahne der proprietären Algorithmen halten On2 Technologies (TrueMotion VP7), RealNetworks (RealVideo 10) und Microsoft hoch. Der inoffizielle Gewinner des vergangenen Vergleichstests, Windows Media Video 9, liegt noch immer in nahezu unveränderter Form vor. Microsoft schob mit Veröffentlichung des Media Player 10 lediglich ein kleines Update nach, mehr dazu in den Einzelbesprechungen. Für den Vergleichstest überließ Microsoft uns eine frühe Vorabversion seiner VC-1-Referenzimplementierung - die von den Redmondern zur Standardisierung eingereichte verallgemeinerte WMV-Version.

Aus Platzgründen verzichten wir in diesem Artikel auf eine Betrachtung der Open-Source-Codecs Ogg Theora, Dirac und Snow. Bei Ogg Theora handelt es sich um die Open-Source-Weiterentwicklung von TrueMotion VP3.2, das von der BBC erdachte Dirac arbeitet ebenso wie ffmpegs Snow-Codec auf Wavelet-Basis. Wir werden das Trio in einer der Folgeausgaben genauer unter die Lupe nehmen.

Der ganze Artikel

Quelle : www.heise.de

[SiLæncer]

Viele hatten es nach der Übernahme des Videospezialisten On2 Technologies gehofft oder gar von Google gefordert: Der Videocodec Truemotion VP8 muss Open Source werden. Angeblich will Google nun dem Wunsch tatsächlich nachkommen, wie das Blog NewTeeVee unter Berufung auf gut informierte Kreise berichtet. Als Termin nennt NewTeeVee die Ende Mai stattfindende Google-Entwicklerkonferenz Google I/O. Google wollte die Informationen nicht bestätigen, momentan gäbe es nichts anzukündigen, so ein Google-Sprecher gegenüber NewTeeVee.

Sowohl Google Chrome als auch Firefox sollen den Codec für die HTML5-Videowiedergabe nutzen. Bisher unterstützt Chrome MPEG-4 AVC (H.264) sowie das freie Ogg Theora, Mozillas Firefox hingegen nur Letzteres. Mozilla nutzt den Industriestandard H.264 nicht, weil die Organisation weder die fälligen Lizenzkosten zahlen, noch einen patentgeschützten Codec in das Projekt integrieren will. Bei Ogg Theora fürchten einige Unternehmen unterdessen "U-Boot-Patente", zudem mangelt es dem Codec an Kodiereffizienz.VP8 könnte beide Probleme beseitigen, allerdings ist fraglich, ob der Codec eine so breite bei den Videoanbietern Akzeptanz finden würde wie H.264. Die größten Videoportale verwenden spätestens seit Einführung von HD-Videos H.264, etwa YouTube oder Vimeo. Browser-seitig wird H.264 momentan von Google Chrome, Apple Safari, dem Internet Explorer mithilfe des "Chrome Frame" und von der Vorabversion des Internet Explorer 9 unterstützt.

Außerdem könnten in VP8 wie bei Ogg Theora (das auf VP3.2 aufsetzt) "U-Boot-Patente" schlummern. Allerdings dürfte Google deutlich mehr Patentanwälte zum Ausräumen etwaiger Bedenken beschäftigen als die Xiph.org Foundation, die Ogg Theora entwickelt.

Quelle : www.heise.de

[SiLæncer]

Google hat erste Verbesserungen am mittlerweile freien Videocodec VP8 vorgenommen, der im Webvideoformat WebM zum Einsatz kommt. Auch erste unabhängige Entwickler haben Verbesserungen beigesteuert. Sowohl Encoder als auch Decoder dürften damit bald schneller werden.
Mehrere Entwickler haben sich unterschiedliche Bereiche von VP8 vorgenommen, um den Codec schneller zu machen. Scott LaVarnway vom VP8-Entwickler On2 hat beispielsweise an eine Assemblerversion des bei VP8 verwendeten Qantizer für x86-Systeme geschrieben. Da der Code vom VP8-Encoder häufig aufgerufen wird, sollte diese Umstellung das Codieren von VP8-Videos beschleunigen, wenn auch nur auf entsprechenden Prozessoren.

Allerdings bietet sich weiteres Potenzial für Verbesserungen, denn große Teile des von VP8 verwendeten Assemblercodes nutzen nur SSE2-Instruktionen. Mit einem Wechsel auf neue Instruktionserweiterungen sollte sich der Encoder weiter beschleunigen lassen, meint Google-Entwickler John Koleszar. Auch andere Bereiche könnten von einer Umstellung auf SIMD profitieren.

Auch in anderen Bereichen sind Verbesserungen möglich: Koleszar nennt vor allem die Suche nach neuen Strategien zur Bewegungserkennung. Gelänge es, die Bewegungserkennung komplett zu entkoppeln, ließe sie sich beispielsweise auf eine GPU auslagern, was zu deutlich höherer Geschwindigkeit führen würde.

Auch auf Seiten des Decoders gibt es erste Verbesserungen. Mozilla-Entwickler Jeff Muizelaar hat beispielsweise einige Funktionen in der x86-Version zusammengelegt, so dass weniger Daten im Speicher hin und her bewegt werden müssen. Da dadurch aber der Assemblercode fundamental verändert wird, ist es voraussichtlich notwendig, andere Plattformen auf generischen C-Code umzustellen, was dort die Leistung verringern wird. An einer Implementierung des Assembler-Codes für ARM wird aber bereits gearbeitet. Sowohl die Änderungen für x86 als auch ARM sollen demnächst in den Hauptentwicklungszweig von VP8 einfließen.

Koleszar selbst will sich unter anderem einem Multi-Threaded-Decoder widmen.

Darüber hinaus soll vor allem die Leistung auf Embedded-Plattformen verbessert werden. Erste Optimierungen für Intels Atom sind in Arbeit. Das ist vor allem deshalb wichtig, weil der bisher geschriebene Assembler-Code auf Out-of-Order-Prozessoren ausgelegt ist. Beim Atom handelt es sich aber um einen In-Order-Prozessor.

Letztendlich aber, betont Koleszar, sei die Optimierung von Codecs eine unendliche Geschichte.

Quelle : www.golem.de

[SiLæncer]

Google hat im aktuellen VP8-Codec den Encoder beschleunigt: Vor allem auf der ARM-Plattform soll VP8 Videos um bis zu 26 Prozent schneller encodieren. Zudem soll die Videoqualität verbessert worden sein.

Google hat unter dem Namen Bali eine neue Version seines freien VP8-Codes veröffentlicht. Das Encodieren von Videos will Google dabei deutlich beschleunigt haben. Gegenüber dem Vorgänger mit dem Namen Aylesbury soll Bali auf der x86-Plattform Videos im "Best"-Modus 1,35-mal so schnell encodieren. Videos in mittelmäßiger Qualität sollen bis zu 1,4-mal schneller encodiert werden können.

Zusätzlich wollen die Entwickler die Qualität der encodierten Videos verbessert haben. Videos in bester Qualität sollen insgesamt konsistenter erstellt werden können. Auch Videos mit Hintergrundrauschen sollen durch Filterung qualitativ besser erscheinen. Zusätzlich soll die Bewegungsvorhersage durch überarbeitete Algorithmen verfeinert worden sein, vor allem bei kleinen Blöcken. Der Assembly-Code wurde ebenfalls überarbeitet, vor allem bei den Funktionen, die für die Rauschunterdrückung und Quantifizierung verantwortlich sind.

Die Multithreading-Fähigkeiten des Codecs sollen auf Mehrkern-CPUs ebenfalls besser funktionieren. Vor allem auf der ARM-Plattform soll der Codec deutlich schneller funktionieren. Google spricht von einem siebenprozentigen Geschwindigkeitszuwachs auf einem Cortex A9, bis zu 15 Prozent auf einem zweikernigen ARM-Prozessor und bis zu 26 Prozent auf einer ARM-CPU mit vier Kernen.

In einem entsprechenden Blog betonen die Entwickler, dass sich nicht das VP8-Format geändert habe, sondern lediglich die SDK für Libvpx. Die neue Version der Bibliothek steht auf den Google-Servern zum Download bereit.

Quelle : www.golem.de

[SiLæncer]

Features of Google VP8 Video Codec 1.2 :

- Compiled with the optimized Google VP8 library
- Includes most color space conversions supported by the Xvid codec
- Uses several threads on multi-core processors
- Encoded files can fully be decoded with FFMPEG as well as VLC
- FOURCC used is VP80

How to install Google VP8 Video Codec :

You need to have administrator rights, simply right-click on the vp8vfw.inf file and choose the install option.

Known Issues :

Because of how the VP8 library is designed, that one more call to the library must be done
to get the full statistics packets even after all frames are processed (NULL parameter of vpx_codec_encode()),
therefore 2-pass encoding will not work on software that use the Video Compression Manager without setting
a valid framecount using the ICM_COMPRESS_FRAMES_INFO.

The following software has been tested:

- Corel Videostudio Pro X3 -> OK in all modes.
- Adobe Premiere 2.0 -> Fails in 2-pass mode due to the above issue.
- Virtualdub 1.9.10 -> OK in all modes.

Changes in Google VP8 Video Codec 1.2.0 :

- linked against libvpx 0.9.7-p1
- now multi-threaded
- bugfix of crash when input is YV12 or I420

http://www.optimasc.com/products/vp8vfw/index.html