Video-Codec-IP bewerten: Bandbreite, Latenz und Qualität zwischen H.264/H.265 Hard- und Software-Encoding
Jedes Videoprojekt kommt an Codec-Entscheidungen nicht vorbei: Vierkanal-1080p-Stitching braucht Streaming, Kameranetzwerke brauchen Backhaul, maschinelles Sehen braucht Speicherung. Hardware-Codec-IP oder Soft-Core? Welche Bitrate hält das Bild klar? Bleibt die Latenz unter einem Frame? Dieser Artikel rechnet Bandbreite, Latenz und Ressourcenaufwand von Hardware- vs. Software-Encoding als klares Kalkulationsgerüst für die Auswahl auf.
Zuerst unterscheiden: Hardware-Codec-IP, Soft-Core-Codec und CPU/GPU-Software-Encoding sind nicht dasselbe
Es gibt drei Routen für Video-Codec auf FPGA, mit Ressourcenaufwand und Latenz, die sich um eine Größenordnung unterscheiden:
| Route | Implementierung | Ressourcenaufwand | Latenz | Typischer Einsatz |
|---|---|---|---|---|
| Hardware-Codec-IP | Integrierter Hard-Codec-Engine im FPGA (Xilinx VCU / Hersteller-Hardcodeckern) | Fast keine Logikzellen | Niedrig (1–3 Frames) | Mehrkanal-1080p/4K-Echtzeit-Encoding und Streaming |
| Soft-Core-Codec | In RTL geschriebene Codec-IP (nutzt LUT/BRAM/DSP) | Hoch (einzelnes 1080p nutzt 30 %+ Logik) | Mittel (3–8 Frames) | Kein Hard-Codec, benutzerdefinierter Algorithmus nötig |
| CPU/GPU-Software-Encoding | ARM/PC-Kern führt x264/x265-Software-Encoder aus | Nutzt CPU-Kerne, keine FPGA-Logik | Hoch (10+ Frames) | Nicht-Echtzeit, Offline-Transkodierung, wenige Kanäle |
Kernurteil: Wenn Ihr FPGA eine Hard-Codec-Engine hat (wie Zynq UltraScale+ VCU), nutzen Sie zuerst Hardware-Encoding; bei reinen FPGAs ohne Hard-Codec (Kintex-7/Virtex-7-Klasse) ist Mehrkanal-Echtzeit-Encoding der einzige Grund, Soft-Core-IP in Betracht zu ziehen; Einzelkanal-Nicht-Echtzeit nutzt einfach CPU-Software-Encoding.
Erstes Konto: Bandbreite (welche Bitrate hält das Bild klar)
Codec-Ausgabe ist ein Bitstrom, und Bitrate bestimmt direkt Speicher und Übertragungsbandbreite. Zuerst berechnen, wie viel Bandbreite vier Videokanäle brauchen:
H.264 1080p@30fps typische Bitratenreferenz:
| Qualitätsstufe | Einzelkanal | Vier Kanäle gesamt | 4K Einzelkanal |
|---|---|---|---|
| Niedrig (Überwachungsgrad) | 2 Mbps | 8 Mbps | 8 Mbps |
| Mittel (Technikgrad) | 4–6 Mbps | 16–24 Mbps | 16–20 Mbps |
| Hoch (Ausstellungsgrad) | 8–12 Mbps | 32–48 Mbps | 30–40 Mbps |
H.265 spart etwa 40–50 % Bitrate gegenüber H.264: bei gleicher Qualität beträgt H.265 Vierkanal-1080p-Mittelqualität etwa 10–12 Mbps, 4K-Einzelkanal etwa 10–12 Mbps.
Erfahrungswerte: Maschinelles Sehen/industrielle Prüfung, H.264 4 Mbps reicht, um Details klar zu erkennen; Bildschirme/Ausstellungsbereiche, H.265 8 Mbps aufwärts. Fangen Sie nicht mit 20 Mbps an — Speicher- und Backhaul-Bandbreite explodieren.
Zweites Konto: Latenz (wann Hardware-Encoding tatsächlich sinnvoll ist)
Echtzeitvideo ist latenzempfindlich: Industriekameras brauchen geschlossenen Regelkreis, Fernbedienung braucht Handnachführung, Latenzarmes Streaming muss unter einem Frame bleiben.
| Stufe | Hardware-Codec-IP | Soft-Core-Codec | CPU-Software-Encoding |
|---|---|---|---|
| Encoding-Latenz | 1–2 Frames (33–66 ms @30fps) | 3–6 Frames (100–200 ms) | 10–30 Frames (300 ms–1 s) |
| Decoding-Latenz | Innerhalb 1 Frame | 2–4 Frames | 5–10 Frames |
| Ende-zu-Ende (inkl. Transport) | <100 ms | 200–400 ms | 500 ms+ |
Für Fernbedienung/Operationsnavigation/industriellen Regelkreis ist Hardware-Encoding die einzige Wahl — Software-Encoding und Soft-Core-Latenz können einfach nicht mithalten. Für nachträgliche Speicherwiedergabe reicht Software-Encoding, keine Logikressourcen nötig.
Drittes Konto: Ressourcenaufwand (wie viel Logik frisst Soft-Core wirklich)
Bei FPGAs ohne Hard-Codec-Engine für Echtzeit-Encoding: Wie viel Ressource frisst Soft-Core-IP tatsächlich? Am Beispiel Einzelkanal-1080p@30fps-H.264-Encoding:
| Ressource | Nutzung (einzelnes 1080p H.264-Encoding) | % von XCKU15P | % von DUK7325T |
|---|---|---|---|
| LUT-Logikzellen | ~80K | ~15 % | ~40 % |
| BRAM | ~6 Mb | ~10 % | ~25 % |
| DSP | ~120 | ~10 % | ~30 % |
Kernschluss: Einzelkanal-1080p-Soft-Encoding auf XCKU15P (Kintex UltraScale+) ist machbar, aber vier Kanäle gleichzeitig nutzen 60 %+ Logik; DUK7325T (Kintex-7-Klasse) Einzelkanal-Soft-Encoding frisst bereits 40 % der Ressourcen, Mehrkanal muss Hardware-Encoding nutzen oder auf CPU-Software-Encoding wechseln.
Der echte Engpass von Hardware-Codec-IP: nicht Rechenleistung, sondern Konfiguration
FPGAs mit Hard-Codec-Engine (wie Zynq UltraScale+ VCU) haben feste Encoding-Fähigkeit — wie viele 1080p-Kanäle, wie viele 4K-Kanäle ist in Hardware festgelegt. Die echten Fallstricke liegen in der Konfiguration:
1. Bitratensteuerungsmodus: CBR (konstante Bitrate) für Übertragung, VBR (variable Bitrate) für Speicherung; falsche Wahl führt zu unscharfem Bild oder Bandbreitenexplosion.
2. GOP-Länge: Längeres GOP gibt höhere Kompression, aber langsameren Random-Access und Seek; Überwachung GOP 2–4 Sekunden, Live-Streaming GOP 0,5–1 Sekunde.
3. B-Frames: B-Frames aktivieren spart Bitrate, erhöht aber Latenz; für Latenz-arme Szenarien B-Frames abschalten, Bitrate steigt 20–30 %.
4. Auflösungsumschaltung: Hard-Codec-Engine braucht Neuinitialisierung beim Auflösungswechsel, kann nicht wie Software-Encoding dynamisch umschalten.
Hardware-Encoding ist nicht “konfiguriert und fertig” — Bitratensteuerung, GOP und B-Frames bestimmen direkt die endgültige Bildqualität und Bandbreite; justieren Sie beim Debuggen am tatsächlichen Bild, nicht nach Gefühl.
Auswahlentscheidung: welche Route für welches Szenario
Die drei Konten zusammenführen und nach Szenario wählen:
| Szenario | Empfohlene Route | Begründung |
|---|---|---|
| Mehrkanal-1080p-Echtzeit-Streaming (≥4 Kanäle) | Hardware-Codec-IP | Niedrige Latenz, keine Logiknutzung, Mehrkanalparallel |
| Einzelkanal-4K-Display | Hardware-Codec-IP (H.265) | 4K-Soft-Encoding nutzt zu viel Ressource |
| Maschinelles Sehen Speicherwiedergabe | CPU-Software-Encoding (H.264) | Nicht-Echtzeit, spart FPGA-Logik |
| Reiner FPGA ohne Hard-Codec + Mehrkanal-Encoding | Soft-Core-IP + niedrigere Auflösung | Nicht genug Logik, Kanäle oder Auflösung reduzieren |
| Fernbedienung/latenzarmer Regelkreis | Hardware-Codec-IP (B-Frames aus) | Latenz muss unter einem Frame bleiben |
Board-Auswahl-Empfehlung: wie man Boards für Codec-Projekte wählt
- XCKU15P Core Board (DUKU15P): Kintex UltraScale+ große Logikressource, geeignet für Mehrkanal-Soft-Core-Codec oder Hochbandbreiten-Videolinks, reichliche Logikreserve.
- DUF7690T (FudanMicro JFM7VX690T): Inlands-Virtex-7-Klasse, große Ressourcen, geeignet für Video-Codec-Links in Inlandsprojekten.
- DUK7325T (FudanMicro JFM7K325T): Inlands-Kintex-7-Klasse, mittlere Ressourcen, geeignet für Einzelkanal-Encoding oder Nicht-Echtzeitszenarien, kostenorientierte Projekte.
Der Kern der Codec-Auswahl ist nicht “welche IP hat die stärkste Leistung”, sondern “wie viele Kanäle, welche Auflösung, welche Latenzanforderung hat Ihr Szenario” — definieren Sie zuerst die Szenarioparameter, rechnen Sie dann auf Bandbreite, Latenz und Ressourcenaufwand zurück, und wählen Sie dann Hardware- oder Software-Encoding. Wählen Sie nicht zuerst die IP und passen Sie dann das Szenario an.
Weiterlesen
- [Vierkanal-1080p-Stitching und 4K-Ausgabe: FPGA-Videolink-Praxis](/article/four-channel-1080p-4k-output/)
- [PCIe-Bandbreitenplanung: DMA, DMA-Engines und Mehrkanaldaten-Verteilung](/article/pcie-bandwidth-planning/)
- [10G/25G-Glasfaser-Backhaul: Glasfaser-Links und FPGA-Lichtports-Anbindung](/article/10g-25g-fiber-backhaul/)
