Real-time Implementierungen von MPEG-4 Codecs Benno Stabernack, Stabernack@HHI.de

1. Real-time Implementierungen von MPEG-4 Codecs Benno Stabernack, Stabernack@HHI.de Telefon: +49-30-31002-688 Fax:+49-30-31002-213 Heinrich Hertz Institut Berlin

2. Übersicht • Einleitung • Motivation • MPEG-4 • Zielplattformen • Generische Softwarearchitektur • Implementierungen • Vom Software IP zum ASIC • Zusammenfassung • Ausblick

3. Einleitung • Übersichtsvortrag über die Umsetzung einer generischen Softwarebibliothek für die prozessorbasierte Umsetzung von MPEG-4 RT Codecs • Überblick über die unterschiedlichen Anforderungen an eine Softwarebibliothek • Vorstellung des Konzeptes der Softwarebibliothek • Überblick über bereits umgesetzte MPEG-4 Videocodecs

4. Motivation • Einsatz verschiedener Prozessoren und Terminalplattformen für MPEG-4 RT Codecs erforderte in der Regel die Neuentwicklung spezieller Software, bzw. Hardware • Wiederverwendbarkeit war in der Regel nur in Teilen möglich • Optimierungen zu speziell um portabel zu sein • Verfügbare Referenzmodelle sind ungeeignet für die Umsetzung von RT-Codecs (andere Zielrichtung) • Keine weiteren Implementierungen verfügbar • Prozessorbasierte Lösungen technologisch machbar sind • Prozessorbasierte Lösungen immer mehr an Bedeutung gewinnen werden

5. MPEG-4 • MPEG-4 Video Standard sehr umfangreich • Nicht festgelegt auf bestimmte Applikationen • Unterteilt in Versionen, Profiles und Levels • Mehrere Versionen: • Version 1 (Basis Profile, wie Simple, Core, Main, etc...) • Version 2 (erweiterte Basis Profile, wie ACE) • Version 3 (Internet Streaming Profile) • Version 4 (Studio Profile) • Profiles kennzeichnen die benutzten Tools • I,P,B Frames • Arithmetische Shape Codierung • Global-, ¼ Pel Motion Compensation, Interlaced, etc ... • Levels geben die erforderliche Leistungsfähigkeit an, wie z.B.: • Bildauflösung • Anzahl der Videoobjekte • Framerate

6. Zielplattformen Win32 / Linuxbasierte PC • Intel / AMD x86 Familie • Super Skalare Rechnerarchitekturen • Splitted ALU Erweiterung • Multimedia extensions wie MMX, ISSE • Hardware Scheduler nimmt Lastverteilung vor • Unterstützung durch optimierende Compiler • Stark hochsprachenorientiert für C und C++ • Cachegröße unterschiedlich je nach Prozessortyp • Wenig Einfluss auf die Speichernutzung, ausreichend Speicher • Optimierungen können schon sehr effektiv im C-Code erfolgen • Seiteneffekte durch Betriebssysteme wie Linux oder Win32 sind zu erwarten • Hohe Leistungsfähigkeit bei einfacher Programmierung • Nutzung mehrer Prozessoren möglich • Hardwareunterstützung durch Grafikkarten für Motion Compensation, Farbraumkonvertierung und IDCT • Alle denkbaren Multimediaanwendungen, rein softwarebasiert

7. Zielplattformen DSPs / Mediaprozessoren • große Bandbreite unterschiedlicher Prozessorfamilien • Teilweise Splitted ALU Erweiterung • Unterschiedliche Prozessorarchitekturen wie VLIW, Harvard, etc .. • VLIW z.Zt. vorherrschende Architektur für Mediaprozessoren, wie Philips Trimedia, TI TMS320C6x, etc... • In der Regel kein Scheduler für Lastverteilung, da VLIW • Leistungsfähigkeit des Prozessors wird wesentlich bestimmt durch die Unterstützung der optimierenden Compiler • Hochsprachenorientiert für C und C++ • Cacheunterstützung je nach Prozessortyp, in der Regel Instruktionscache • Optimierte Speichernutzung Sache des Programmierers, Speicher knapp • Kenntnis der Compiler und der Prozessorarchitektur unabdingbar • Hohe Leistungsfähigkeit bei komplexer Programmierung • Teilweise Hardwareunterstützung durch Coprozessoren für VLD, Farbraumkonvertierung und IDCT • Spezialhardware für niedrige und mittlere Stückzahlen, typisch Multi Media Terminals, Internet Appliance, etc ...

8. Zielplattformen RISC Cores • Embedded Prozessoren für „System on a Chip“ Implementierungen • In der Regel 32 Bit Cores, wie ARM Risc, Argonaut Risc, MIPS, etc ... • unterschiedliche Erweiterungen, wie Multiplizierer, Barrelshifter, Sättigungsfunktionen, etc • Leistungsfähigkeit des Prozessors wird ebenfalls wesentlich durch die Unterstützung der optimierenden Compiler bestimmt • Nicht ausschließlich Hochsprachenorientiert • Assembleroptimierungen in der Regel erforderlich • Cacheunterstützung je nach Prozessortyp, in der Regel Instruktionscache • Optimierte Speichernutzung Sache des Programmierers, Speicher knapp • Kenntnis der Compiler und der Prozessorarchitektur unabdingbar • Niedrige bis mittlere Leistungsfähigkeit bei komplexer Programmierung • In der Regel keine verfügbare Hardwareunterstützung für Bildsignal-verarbeitung • Teilweise Unterstützung für Coprozessor- und Instruktionserweiterungen • Coprozessoren müssen selbst entworfen werden • großer Aufwand für Hardware- und Softwareimplementierung • hohe Stückzahlen , wie Mobilfunkterminals

9. Generische Softwarearchitektur Warum eine generische Softwarebibliothek ? • Großes Spektrum von unterschiedlichen Zielplattformen (Prozessorarchitekturen) müssen abgedeckt werden. • Optimierungen müssen je nach Prozessorarchitektur an unterschiedlichen Stellen vorgenommen werden. • Optimierungen erfordern hohe Kenntnis der verwendeten Software • Großes Spektrum an unterschiedlichen Anforderungen in Bezug auf Versions, Profiles und Levels, d.h. Anforderungen an Komplexität und Realzeitfähigkeit variieren stark • Großes Spektrum an unterschiedlichen Terminalplattformen soll abgedeckt werden • Parameter, wie Speicherbedarf und Codegröße, können stark voneinander abweichen • Wiederverwendbarkeit einer gemeinsamen Softwarebasis wichtig für Investitionsschutz • Verifikationsaufwand reduziert sich auf die prozessorspezifischen Optimierungen und die eigentliche Softwarebibliothek

10. Generische Softwarearchitektur Wie sollte eine generische Softwarebibliothek konzipiert sein? • Toolstruktur von MPEG-4 sollte widergespiegelt werden • Stark Modularisiert weniger Funktionen pro Datei • Module kommunizieren über Pointer auf Datenstrukturen. Dadurch erhöht sich die Kontrolle über die Speicherverwaltung • Vermeidung von Standardbibliotheksfunktionen so weit wie möglich (z.B. Memset, Memcpy ) • Verwendung selbstdefinierter Datentypen • Auf C, bzw. C++ beschränkt • Assemblerfunktionen nicht als Inline Code schreiben, sondern in externe Dateien auslagern • Einsatz von Integer Arithmetik und gängigen Optimierungen , wie z.B. Verwendung von Shiftoperationen als Ersatz für Multiplikationen • Zu jedem optimierten Programmteil existiert eine Referenzimplementierung als reiner C-Code • Teststrukturen sind im Code bereits vorhanden (design for test) • Datenstrukturen werden selbstständig initialisiert und nicht vom evtl. nicht vorhandenen Betriebssystem • Versionsmanagement mittels Makefile und Skriptfile, oder kommerzieller Tools wie z.B. Clear Case

11. Generische Softwarearchitektur Encoder Lib • MPEG-4 Simple Profile • MPEG-4 Core Profile (- Shape) • MPEG-4 ACE Profile (Advanced Coding Efficieny) • ITU H.263 • Total ca. 35.000 Codezeilen Decoder Lib • MPEG-4 Simple Profile • MPEG-4 Core Profile (- Shape) • MPEG-4 ACE Profile (Advanced Coding Efficieny) • ITU H.263 • MPEG-2 Main Profile • MPEG-1 • Total ca. 26.000 Codezeilen

12. Implementierungen PC-basiert MPEG-4 ACE Profile Videoencoder • Simple / Core – Profile Subset • ¼ Pel, B-Vops und Global Motion Estimation / Compensation • Realzeitfähig für CIF (352 x 288) Auflösungen bei 25FPS und ca. 1,5 Mbit/s Ausgangsdatenrate • Dual Pentium III Plattform (2 x 650 MHz) • Multi Threaded Architektur • MMX / ISSE Optimierungen für Bewegungsschätzung, DCT/IDCT und Bewegungskompensation • Ohne Optimierungen ca. 3-4 FPS • Lauffähig unter Linux und Win32 • Komplette Bibliothek plus Wrapperfunktionen und Systemintegration

13. Implementierungen PC-basiert MPEG-4 ACE ProfileVideoencoder • Entwickelt für DMB Broadcast Anwendungen bei 1,5 MBits /s • Videointerface für Echtzeitaufnahmen mit SVHS Eingang • digitaler Videorecorder • Komfortable Benutzerschnittstelle

14. Implementierungen PC-basiert MPEG-4 ACE Profile Decoder • Simple / Core – Profile Subset • B-Vops und ¼ Pel-, Global Motion Compensation • Realzeitfähig für CIF (352 x 288) Auflösungen bei 25FPS und ca. 1,5 Mbit/s Eingangsdatenrate • Pentium II / Celeron Plattform 400 MHz • C++ Wrapper für Systemintegration • MMX Optimierungen für Bewegungscompensation, IDCT • Ohne Optimierungen ca. 5 FPS • Codesubset ca. 19.000 Codezeilen • Lauffähig unter Linux und Win32 • Buffer to Buffer API

15. Implementierungen DSP-basiert Simple Profile Decoder • Realzeitfähig für CIF (352 x 288) Auflösungen bei 25FPS und bis zu 1,5 Mbit/s Eingangsdatenrate • DSP-Plattform Texas Instruments TMS 320C6201 @ 200MHz • VLIW Architektur • Assembler Optimierungen für Bewegungskompensation • Hohe Optimierung der Speicherverwaltung • Ohne Optimierungen ca. 10 FPS • Codesubset ca. 10.000 Codezeilen • Eigenes Hardwaremodul • Mobile Broadcastterminals

16. Implementierungen DSP-basiert Core Profile Decoder • Realzeitfähig für CIF (352 x 288) Auflösungen bei 15FPS und bis zu. 500 kBit/s Eingangsdatenrate • DSP-Plattform Philips Trimedia TM1300 @ 133MHz • VLIW Architektur • Ohne Optimierungen des C-Codes realzeitfähig • Codesubset ca. 14.000 Codezeilen • Lauffähig unter PSOS Real Time Operating System • Einsatz des Image Coprozessors für Farbraumkonvertierung • Internet Appliance Anwendungen • Mobile Broadcastterminals

17. Vom Software IP zum ASIC • PC und DSP Implementierung auf leistungsfähigen Plattformen sind die Pflicht! • Ein „System on a Chip“ stellt die Kür dar! • Wie weit lässt sich das vorgestellte Softwarekonzept auch bei Hardwareentwicklungen einsetzen ?

18. Vom Software IP zum ASIC Architekturstudie für ein prozessorbasiertes MPEG-4 Terminal für Mobilfunkanwendungen • ISO14996-2 MPEG-4 Video Simple Profile / ITU H.263 • 32kBit/s - 384 kBit/s Eingangsdatenraten • QCIF, CIF 12 FPS Output • ISO 14996-3 MPEG-4 Audio WB-Celp / G.723.3 Celp • 8kBit/s – 32kBit/s Eingangsdatenraten • 8 kHz – 44,1kHz Output • Prozessorbasierte Unterstützung für die Systemintegration • Eingeschränkte Grafikfähigkeiten • Diverse Schnittstellen für Audio, Video, Speichererweiterung • Möglichst wenig dedizierte Hardwareblöcke • Nutzung von Embedded DRAM für Single Chip Lösung • Gegebener Prozessor des Technologieherstellers

19. MP4 Terminal ASIC • Single Chip Lösung • Prozessorbasierter Video Decoder mit Media Extensions • Flexibler TFT Controller mit Farbraumkonvertierung und RGB Grafikeingang • Prozessorbasierter Audio Decoder • Sync. Serial Interface für Audio DACs • 10MBit Embedded DRAM • Flexible Host Port Interface • Multi Media Card Interface • System Processor • General Purpose I/Os • Programmierbare Low-Power Modi • Static VHDL Design • 0.25 µ / 0.18 µ @ 120Mhz

20. Argonaut Risc Core Eingesetzter Prozessor • Argonaut RISC Core (ARC) • Liegt als VHDL Beschreibung vor • 32 Bit Datenpfad, 32 Bit Load Store Adressbus • 32 Bit Instruktionsbus, 32 Bit Instruktionsadressbus • 32 General Purpose Register / Auxiliary Register • 4 stufige Pipeline • Single Cycle Instruktionen • Erweiterbar um neue Instruktionen und vordefinierte Hardwareblöcke • Typische Taktrate 120 MHz, je nach verwendeter Technologie auch höher

21. Videopart • Lose Kopplung zwischen Videoprocessor (VPU) und Ausgabeeinheit (VOB) • Rechenzeitgewinn durch quasi autonome Komponenten • Buffer to Buffer Konzept • Double Buffer für Ausgangsvideodaten • Farbraumkonvertierung findet erst beim Auslesen im TFT Controller statt • TFT Controller Dual Ported • Graphic Output Buffer wird über bestehenden Systemcontroller angesteuert

22. Argonaut Risc Core Evaluierung • ARC muss zusätzlich mit Barrelshifter, Multiplizierer und 2kByte Instruktionscache erweitert werden (Argonaut Komponenten) • IDCT und Farbraumkonvertierung werden als Coprozessoren hinzugefügt (HHI IPs) • Speichersystem, bzw. Speicherzugriffe müssen stark optimiert werden (DRAM Page Mis.), ROM Tabellen, SRAM • Beibehaltung der gegebenen Softwarestruktur • Assembleroptimierungen für Bewegungskompensation • Codesubset ca. 10.000 Codezeilen

23. Video Processing Unit

24. Video Output Buffer

25. Audio Processing Unit

26. Zusammenfassung Die Implementierung einer eigenständigen Softwarebibliothek ist gerechtfertigt, wenn • die Software portabel in Bezug auf unterschiedliche Prozessorplattfomen und Terminalarchitekturen entwickelt wird • die Software Optimierbarkeit und Skalierbarkeit in Bezug auf Rechenleistung und Speicherbedarf berücksichtig • die Erweiterbarkeit auf neue Codierungsverfahren gegeben ist • von Beginn eine Komplettlösung angestrebt wird • gewissenhaft gegen die verfügbaren Referenzmodelle getestet wird • eine vollständige Dokumentation der Software erstellt wird Vorteile: • Time to Market kann erheblich reduziert werden • Verifikationsaufwand verringert sich wesentlich • Reine Hardwareentwicklungen können ebenfalls von der Software als Referenzmodell profitieren

27. Ausblick • Unterstützung weiterer Prozessoren • Erweiterung der Software um neue Codierungsverfahren • Testen, Testen, Testen ...

28. Fragen ? Kommentare ?