Hi Leute,
diese Frage ist evtl. jetzt etwas abstrakt:
Ich habe auf dem STM32F7 jetzt schon einige Displayansteuerungen mit dem
integrierten LCD Controller + SDRAM realisiert und verstehe inzwischen
ganz gut wie z.B. JPEG decoding in Hardware läuft, wie man verschiedene
Grafiklayer (low-level) auf sehr einfachen Videobeschleunigern nutzt wie
z.B. auf uCs mit LCD controllern.
Ich frage mich aber - hier würde es mir reichen wenn es mir jemand mal
abstrakt erklärt - was eigentlich passiert, wenn ich z.B. im Chrome ein
4K Video abspiele?
Vermutung: Chrome greift über eine Open-GL oder Direct-X Schnittstelle
auf das System zu, die wiederum über Grafiktreiber dann z.B. das h264
video in die GPU-Hardware "schaufelt". Das Decoding passiert dann auf
der Grafikkarte oder auf der CPU? Wenn ja wie kommen die
Bildinformationen dann in den "Framebuffer" - und das ganze dann noch
getunnelt über eine serielle Schnittstelle wie PCI-Express. Wie
funktioniert das ganze DMA Konstrukt in einem richtigen PC im Vergleich
zu einer einfachen DMA in einem uC?
Wie sind hier die ganzen Treiber abstrahiert, dass man flüssig in einem
Browser z.B. Videos abspielen kann und das Video decoding über
verschiedenste Grafik + Prozessorchips hinweg funktioniert?
Wie schafft es die Hardware, wenn das Video auf der GPU dekodiert wird,
das Audio-Signal durch die CPU rückwärts in die Soundkarte zu bringen
sodass Video + Ton dann immer noch synchron sind etc.. etc.. etc..
Hoffe mir kann das jemand halbwegs erklären.
Vielen Dank!
Also bei mir kommt der Ton mit über HDMI. Das dürfte heute sozusagen
Standard sein.
Der ton muss so also bei vielen nicht mehr zwangsweise zurück durch den
halben PC zur Soundkarte.
Also genau weiß ich es nicht, denke aber, daß die Daten von der GPU via
DMA-Transfer aus dem Hauptspeicher geladen werden und daß der
Hardware-Dekoder schlau genug ist um das Video passend zu skalieren und
direkt in den Grafikspeicher zu schreiben - zumal er ja Teil der GPU
ist. Es würde nur wenig Sinn machen, ihn die Videodaten in den
Hauptspeicher schreiben zu lassen um sie dann extra wieder auf die
Grafikkarte zu kopieren.
Die Audiodaten sind heute Spielkram für einen modernen PC, wird aber
auch alles via DMA-Transfer laufen. Entweder über die GPU und DVI
digital oder zum Audio-Codec auf dem Board bzw. Soundkarte.
Der Trick bei sämtlicher Hardwarebeschleunigung ist, daß man der
Hardware nur sagt wo sie ihre Daten findet und was sie mit den Daten
machen soll. Um den Rest kümmern sich dann sowas wie GPU,
DMA-/Speichercontroller und die Codecs von alleine, so daß sich die CPU
mit anderen Dingen beschäftigen kann.
Das läuft heute alles über DMA-Controller. Bei den Intel 386 CPUs konnte
man damals für die Festplattenzugriffe (!!) DMA im Bios manuell an- und
abschalten. Heute ist das Standard
Robert schrieb:> Das Decoding passiert dann auf der Grafikkarte
So ist es.
> Wenn ja wie kommen die Bildinformationen dann in den "Framebuffer"
Das ist gar nicht nötig. Unsere Grafikkarten haben nämlich schon lange
nicht mehr nur einen Framebuffer, der das Bild Pixel für Pixel
repräsentiert, sondern sie können viele Teilbilder ganz alleine zu einem
Gesamtbild kombinieren. Sogar mit Transparenz-Effekten.
Bei der Video-Wiedergabe legt der Video-Player einfach nur einen Bereich
fest, wo das Video ausgegeben werden soll und schaufelt dann die Daten
rüber. Den Rest erledigt die Grafikkarte weitgehend selbstständig.
> Wie funktioniert das ganze DMA Konstrukt in einem richtigen PC> im Vergleich zu einer einfachen DMA in einem uC?
Da gibt es keinen Unterschied. Der DMA Kontroller kann Daten von einer
Quelle zu einem Ziel übertragen. wobei sowohl Quelle als auch Ziel I/O
Schnittstellen oder RAM sein kann. Auch das RAM der Grafikkarte.
> Wie sind hier die ganzen Treiber abstrahiert, dass man flüssig in einem> Browser z.B. Videos abspielen kann und das Video decoding über> verschiedenste Grafik + Prozessorchips hinweg funktioniert?
Genau weiß ich es nicht. Ich denke, du wirst viele Infos dazu in der
Dokumentation von DirectX bzw. OpenGL finden
> Wie schafft es die Hardware, wenn das Video auf der GPU dekodiert wird,> das Audio-Signal durch die CPU rückwärts in die Soundkarte zu bringen> sodass Video + Ton dann immer noch synchron sind
Audio-Wiedergabe ist nicht Aufgabe der Grafikkarte, soweit ich weiß. Die
Synchronisation zwischen Audio und Video ist Aufgabe der Software, die
auf dem Hauptprozessor läuft. Natürlich informiert die Grafikkarte die
Software darüber, welche Zeitmarke gerade zu sehen ist.
Im Gegensatz zu den Grafikkarten, die immer mehr von alleine machen,
sind die handelsüblichen Soundkarten in Consumer PC immer dummer
geworden. Falls dich das interessiert, dann schaue Dir mal die
Beschreibung der Soundblaster AWE32. Die war lange Zeit das Maß der
Dinge im Consumer Bereich. Ich hatte sie damals mit einem Midi
Synthesizer Board von Roland erweitert. Das war alles sau teuer, dafür
kauft man sich heute einen kompletten PC.
Mittlerweile sind die Hauptprozessoren so Leistungsstark, dass sie das
allen nebenbei machen, so dass (salopp gesagt) ein simpler D/A Wandler
den allermeisten Leuten zur Audioausgabe genügt.
Stefan ⛄ F. schrieb:>> Das Decoding passiert dann auf der Grafikkarte>> So ist es.
Meines Wissens nach findet das in nicht in der Grafikkarte statt.
Die Grafikkarte zeigt nur den dekodierten Stream an.
Moderne CPUs haben dafür eine dezidierte HW Einheit, ältere
machen es in SW.
> Das Decoding passiert dann auf der GrafikkarteUdo K. schrieb:> Meines Wissens nach findet das in nicht in der Grafikkarte statt.
Schauen wir mal, was Nvidia dazu sagt:
https://developer.nvidia.com/video-encode-decode-gpu-support-matrix
Man kann jetzt nicht generell sagen, dass alle Grafikkarten alle Video
Formate decodieren. Aber es sind schon recht viele.
Irgendwie habe ich Zweifel, das es immer so schön abläuft.
Es gibt 2 sich widersprechende Anforderungen.
Zum einen ändern Videoanbieter, denken wir an Apple HEVC oder YouTube,
ständig ihr Videoformat, der eine führt H.265 ein, der andere ändert
ständig die Verschlüsselung. Da kann man nix an die Graphikkarte
schicken, es müsste ja bei jeder Änderung der Kunde alles neu kaufen. Es
muss also viel mehr in Software gemacht werden, als für gute Performance
zuträglich wäre.
Zum anderen möchten Videoanbieter, dass man das Signal z.B. von blue Ray
nicht mitschneiden kann, sondern es HDMI verschlüsselt bis zum Monitor
geleitet wird. Da kann man eigentlich noch nicht mal Ton von Bild
trennen. Es kann also viel weniger in Software gemacht werden weil nicht
decodiert werden man, als sinnvoll wäre.
Udo K. schrieb:> Du schaust hier aber bei den GK, die meist mehr kosten als die CPU...
Nö. Auch Tablets und Smartphones decodieren die meisten Videos in der
GPU.
MaWin schrieb:> Da kann man nix an die Graphikkarte> schicken, es müsste ja bei jeder Änderung der Kunde alles neu kaufen
Das ist oft so, aber nicht immer. Denn der Mikrocode der Grafikkarte
wird zusammen mit ihrem Treiber aktualisiert.
Meines Wissens nach frägt der Monitor/Endabspielgerät die Berechtigung
auf einem parallelen Kanal vor dem Abspielen ab (oft I2C).
Nur wenn er die Antwort bekommt, dass der Stream legal ist,
spielt er ab. Da wird im Endgerät nichts entschlüsselt, sondern
darauf vertraut, dass die HW Hacker anderes zu tun haben.
Die ganzen Videoformate sind meist Container, die neben
der Videoinfo auch Zusatzinfo enthalten. Die Zusatzinfo ändert sich
relativ oft, ist aber nicht rechenintensiv (daher SW).
Die HW Dekoder sehen nur Datenblöcke, und nicht die Zusatzinfo.
MaWin schrieb:> der andere ändert> ständig die Verschlüsselung. Da kann man nix an die Graphikkarte> schicken, es müsste ja bei jeder Änderung der Kunde alles neu kaufen.
Teilweise wird die Arbeit aufgeteilt. Die CPU entschlüsselt z.B. den
Stream und die GPU dekomprimiert ihn.
Stefan ⛄ F. schrieb:> Udo K. schrieb:>> Du schaust hier aber bei den GK, die meist mehr kosten als die CPU...>> Nö. Auch Tablets und Smartphones decodieren die meisten Videos in der> GPU.
Titel gelesen?
>> MaWin schrieb:>> Da kann man nix an die Graphikkarte>> schicken, es müsste ja bei jeder Änderung der Kunde alles neu kaufen>> Das ist oft so, aber nicht immer. Denn der Mikrocode der Grafikkarte> wird zusammen mit ihrem Treiber aktualisiert.
Träumst du das, oder weisst du das?
Udo K. schrieb:> Titel gelesen?
Ja doch. Es geht um PC. Und was steckt in jedem halbwegs aktuellen PC
drin? Eine GPU, die Videos dekodieren kann und 3D Effekte berechnet.
Selbst in den allermeisten Laptops der untersten Preisklasse steckt
bereits ein kombinierter Chips mit CPU und GPU drin.
Udo K. schrieb:> Träumst du das, oder weisst du das?
Ich weiß das. Bei meinem Laptop (mit dedizierter Nvidia GPU) kamen
mehrfach neue unterstützte Videoformate durch Treiberupgrades hinzu.
Udo K. schrieb:> Stefan ⛄ F. schrieb:>> Udo K. schrieb:>>> Du schaust hier aber bei den GK, die meist mehr kosten als die CPU...>>>> Nö. Auch Tablets und Smartphones decodieren die meisten Videos in der>> GPU.>> Titel gelesen?
Ein Tablett/Smartphone ist auch eine Version von einem Personal Computer
Stefan ⛄ F. schrieb:> Udo K. schrieb:>> Träumst du das, oder weisst du das?>> Ich weiß das. Bei meinem Laptop (mit dedizierter Nvidia GPU) kamen> mehrfach neue unterstützte Videoformate durch Treiberupgrades hinzu.
Mein Laptop hat zwar auch eine Nvidia für CAD, die fährt aber nur hoch,
wenn es sein muss. 0815 Zeugs wie Video wird über die stromsparende
Intel Grafik gemacht. Dekodieren macht der HW Block in der CPU.
Aber dein Laptop macht das vielleicht anders :-)
Udo K. schrieb:> Mein Laptop hat zwar auch eine Nvidia für CAD, die fährt aber nur hoch,> wenn es sein muss.> 0815 Zeugs wie Video wird über die stromsparende> Intel Grafik gemacht. Dekodieren macht der HW Block in der CPU.
Dann hast du sogar zwei GPU's, eine von Intel und eine von Nvidia. Diese
Kombination ist nicht ungewöhnlich.
Schau Dir doch einfach den Linux Quellcode an :-)
auf einem PC wird das ganze in verschiedene Teilaufgaben aufgeteilt und
je nach Hardwareverfügbarkeit verteilt.
- Downloaden des Streams,
- Entschlüsseln SSL,
- Entpacken des Datencontainers,
- Dekodieren des Videostreams
- Dekodieren des Audiostreams
- Komposition des Bildes
- Synchronisation Ton & Audio
Selbst innerhalb des Videodecoders kann bzw wird nochmal aufgespalten
werden, so dass die Graka eventuell nur einen Teilbereich des Dekodings
übernimmt. Zwischen den ganzen Teilschritten stehen ausgeklügeltes DMA.
Nicht nur die CPU, sonder auch die Graka, Netzerkkarte... können
selbständig DMAs auslösen. Es werden im übrigenen nicht nur ein, sondern
viele Framebuffer benutzt, die munter hin und her gewechselt werden.
Da das ganze sehr modular ist, spielt es auch nur eine untergeordnete
Rolle wenn in einem Codec was geändert wird, das Grundprinzip bleibt ja
gleich. Selbst bei einem gänzlichen neuen Codec, kann man eventuell
bestimmte Teilmnodule eine vorhandenen Hardware mitbenutzen, so dass man
zumindest eine Teilbeschleunigung erreichen kann. (Neue Codecs basieren
oftmals auf bekannten Mechanismen und erweitern diese nur)
MaWin schrieb:> Zum anderen möchten Videoanbieter, dass man das Signal z.B. von blue Ray> nicht mitschneiden kann, sondern es HDMI verschlüsselt bis zum Monitor> geleitet wird.Udo K. schrieb:> Meines Wissens nach frägt der Monitor/Endabspielgerät die Berechtigung> auf einem parallelen Kanal vor dem Abspielen ab (oft I2C).> Nur wenn er die Antwort bekommt, dass der Stream legal ist,> spielt er ab. Da wird im Endgerät nichts entschlüsselt, sondern> darauf vertraut, dass die HW Hacker anderes zu tun haben.
Ich glaube, da täuschst du dich. Der Datenstrom wird tatsächlich bis zum
Monitor verschlüsselt. Siehe zum Beispiel diesen HDMI-Transmitter-Chip
ADV7513:
https://www.analog.com/media/en/technical-documentation/data-sheets/ADV7513.pdf
Im Blockdiagramm gibt es einen HDCP-Encryption-Block, der aktiv wird,
wenn geschützte Inhalte wiedergegeben werden. Bei BlueRay ist das z.B.
gängige Praxis zwischen Player und Fernseher. Ein nicht HDCP-fähiger
Fernseher wird keine kopiergeschützten Videos wiedergeben. Auch
zwischendrin Audio ausschleusen ist nicht möglich, weil der Datenstrom
entschlüsselt werden müsste. Das ärgert die audiophilen, die so das
qualitativ schlechte Audio vom Fernseher abnehmen müssen. Auf die
mangelnden Fähigkeiten der Hacker verlässt sich da niemand.
HDMI-Splitter funktionieren deswegen mit geschützten Inhalten auch nicht
ohne weiteres. Oder auch schön, wenn der Fernseher nur einen alten
HDCP-Standard unterstützt und man die BlueRay deswegen nicht ansehen
darf...
Wie das allerdings am PC gemacht wird, wenn das Videobild nur einen Teil
des Bildschirms einnimmt? Wahrscheinlich wird das Videosignal pauschal
verschlüsselt, wenn möglich. Youtube zum Beispiel setzt teilweise HDCP
ein, also muss es irgendwie gehen.
(Das der Datenstrom im Transmitter-Chip erneut verschlüsselt wird, heißt
eigentlich, dass im PC das Video auch mal unverschlüsselt vorliegen
müsste...)
Udo K. schrieb:>> MaWin schrieb:>>> Da kann man nix an die Graphikkarte>>> schicken, es müsste ja bei jeder Änderung der Kunde alles neu kaufen>>>> Das ist oft so, aber nicht immer. Denn der Mikrocode der Grafikkarte>> wird zusammen mit ihrem Treiber aktualisiert.>> Träumst du das, oder weisst du das?
Das ist blühender Unsinn. Chrome (weil es vom TO genannt wurde), aber
auch andere Videoplayer laufen auch auf Systemen, wo es gar keine
"Treiber" für die Grafikkarte im herkömmlichen Sinn gibt.
Videodecodierung läuft keineswegs 100% auf der GPU. Und wenn doch, dann
steckt die Software nicht in einem ominösen "Mikrocode der
Grafikkarte", sondern wird erst unmittelbar, bevor des Decodieren
stattfinden soll, in die Grafikkarte geladen.
Der Treiber kommt da nur dahingehend ins Spiel, wenn das Betriebssystem
Infrastruktur hat, um solche Shader-Programme zu verwalten. Dann kippt
der Treiber die bei der Installation ins System und der Videoplayer
fragt das System, ob es etwas passendes für Videoformat X hat. Praktisch
ist das aber nur für Windows mit DirectX so.
Je nachdem, welches Videoformat abgespielt werden soll, welche
Shader-Primitiven vorhanden sind und wieviele Shader die Grafikkarte
hat, verteilt der Videoplayer die verschiedenen Decodier-Schritte auf
GPU und CPU. Im Zweifel kann das auch alles die CPU machen.
Wer Details wissen will, schaue einfach in den Quellcode eines
Videoplayers. Z.B. vlc. Oder mplayer (mpv).
Elias K. schrieb:> Ich glaube, da täuschst du dich. Der Datenstrom wird tatsächlich> bis zum Monitor verschlüsselt.
Ganz andere Baustelle.
HDMI überträgt Pixeldaten zum Monitor. Die werden nach der Decodierung
des Videostreams neu verschlüsselt. Mit der Verschlüsselung des Videos
hat das nur dahingehend zu tun, daß ein konformer Videoplayer das
Abspielen eines "geschützten" Videos verweigern muß, wenn die
Schnittstelle zum Monitor keine Verschlüsselung bietet.
Moin,
Robert schrieb:> Das Decoding passiert dann auf> der Grafikkarte oder auf der CPU?
Das Decoding passiert ueblicherweise weder auf der CPU noch auf der GPU,
sondern in einer unscheinbaren weiteren kleinen Einheit, die eben nix
anderes kann, als verschiedene Videostandards zu en/decodieren.
Allzuviel kann man an dieser Einheit auch nicht per SW/Microcode-Update
machen.
Teilweise macht die dann auch nicht die komplette Decodierung, sondern
nur rechenintensive Teile. Aber so tief lassen sich die Chiphersteller
immer ungern in die Karten gucken.
In diese Einheit rein geht ueblicherweise ein Pointer auf ein Stueckchen
Videostrom, was im Speicher steht und ein Pointer auf einen (noch)
freien Speicherbereich, wo dann das decodierte Bild hingeschrieben wird.
Das steht dann aber noch im YUV Farbraum und ueblicherweise mit in hor.
und ver. unterabgetasteter Chromainfo dort rum (oder wie auch immer das
Format des komprimierten Videos war). Muss also dann von einer weiteren
HW-Komponente - die ist dann tatsaechlich in der GPU -
farbraumkonvertiert (dabei die Chromas hochinterpolieren, etc. )und
skaliert werden. Dann kanns in den Framebuffer und angezeigt werden.
> Wenn ja wie kommen die> Bildinformationen dann in den "Framebuffer" - und das ganze dann noch> getunnelt über eine serielle Schnittstelle wie PCI-Express. Wie> funktioniert das ganze DMA Konstrukt in einem richtigen PC im Vergleich> zu einer einfachen DMA in einem uC?
Nicht viel anders. Bloss gabs frueher im PC halt den/die dedizierten DMA
Controller, mittlerweile kann jeder Furz eben auch so an der CPU vorbei
auf den Speicher zugreifen, ohne dass das ueber einen uebergeordneten
DMA controller gehen muss.
> Wie sind hier die ganzen Treiber abstrahiert, dass man flüssig in einem> Browser z.B. Videos abspielen kann und das Video decoding über> verschiedenste Grafik + Prozessorchips hinweg funktioniert?
Bei Linux hast du z.b. einen Kerneldriver, der sich um die Hardware
kuemmert, darauf setzen dann so libraries wie die libva, libvdpau auf,
die sich um die Videobeschleunigung kuemmern.
> Wie schafft es die Hardware, wenn das Video auf der GPU dekodiert wird,> das Audio-Signal durch die CPU rückwärts in die Soundkarte zu bringen> sodass Video + Ton dann immer noch synchron sind
Die komprimierten Audio- und Videodaten sind ueblicherweise unterteilt
in Schnipsel mit einer bestimmten zeitlichen Laenge. D.h. beim Video
ueblicherweise ein Bild, das dauert dann bei z.b. 50fps eben 20msec.
Beim Audio z.b. 1024 Samples/ 48kHz = 21.333msec.
Dazu werden ausserhalb der eigentlichen Audio/Video Elementarstroeme
dann noch jeweils PTS (PresentationTimestamps) uebertragen, die angeben,
wann das betreffende Stueckchen Audio/Video dargestellt werden soll.
Kapitel Ver/Entschluesselung:
Sind die komprimierten AV-Daten verschluesselt, entschluesselt das
ueblicherweise eine Standardlib wie z.b. openssl bzw. fuer DVB gaebe es
noch die libdvbcsa. Mit den heutigen CPUs gibts da keine
Performanceprobleme, ueblicherweise will man ja auch nicht gleich 256
verschiedene Kanaele gleichzeitig entschluesseln.
HDCP: Da wird das Signal zum Monitor hin von der Graphik"karte"
verschluesselt, damit nur "echte" Monitore das wieder entschluesseln und
darstellen koennen. Und nicht z.b. irgendwelche
Encoder/Aufzeichnungsgeraete. Und nur "echte" Monitore koennen sich dann
gegenueber der Graphikkarte authentisieren, und koennen sich per I2C
Verbindung dann auf Schluessel einigen.
So zumindest der fromme Wunsch.
Gruss
WK
Axel S. schrieb:> HDMI überträgt Pixeldaten zum Monitor. Die werden nach der Decodierung> des Videostreams neu verschlüsselt.
Danke für die Klarstellung. Ich meinte das schon genau so. Du hast es
aber besser zusammen gefasst.
Wir wissen doch, dass Udok keine Ahnung hat.
Sehr geil war seine Behauptung, dass das AMD AVX anders sei as das Intel
AVX!
Als Matlab dann die Intellib in den Debugzustand versetzt hat damit die
Intellib bei AMD nicht die Handbremse anzieht war der Udoktroll dann auf
einmal sehr leise.
->
https://www.heise.de/newsticker/meldung/Matlab-Update-beschleunigt-AMD-Ryzen-Prozessoren-automatisiert-4693213.html
Ansonsten hat er auch hier wieder keine Ahnung, sämtliche halbwegs
modernen GPUs, egal ob AMD, Intel, Nvidia, könne Videos in HW
dekodieren.
Nur eben nicht alle exotischen Formate.
Gucken wir uns doch mal die HD Grafik eines i5-2500 an.
Was steht dann da unter "Intel® HD-Grafik 2000"?
"
ntel® Quick-Sync-Video bietet schnelle Videoumwandlung für tragbare
Medienplayer, Online-Veröffentlichung sowie Videobearbeitung und
-entwicklung.
"
sowie
"
Intel® Quick-Sync-Video bietet schnelle Videoumwandlung für tragbare
Medienplayer, Online-Veröffentlichung sowie Videobearbeitung und
-entwicklung.
"
Diese GPU kann sogar encodieren!
Dergute W. schrieb:> Das Decoding passiert ueblicherweise weder auf der CPU noch auf der GPU,> sondern in einer unscheinbaren weiteren kleinen Einheit, die eben nix> anderes kann, als verschiedene Videostandards zu en/decodieren.
Und wo ist das Ding, wenn es nicht in der CPU ist? Und wichtiger: Gibt
es das Ding auch auf Systemen, bei der die CPU keine integrierte GPU
hat?
Auf https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video steht
"Certain low-end and high-end parts (including multi-socket Xeons and
some Extreme Edition CPUs expected to be used with a dedicated GPU) do
not contain the hardware core to support Quick Sync."
Über das AMD-Gegenstück VCE seht hier
https://en.wikipedia.org/wiki/Video_Coding_Engine :
Since 2012 it is integrated into all of their GPUs and APUs except
Oland.
Über das UVC https://en.wikipedia.org/wiki/Unified_Video_Decoder steht
ähnliches drin.
Moin,
Markus K. schrieb:> Und wo ist das Ding, wenn es nicht in der CPU ist?
Es ist natuerlich auf dem selben Die wie die CPU oder die GPU, hat aber
eben nix oder nur genausoviel wie irgendwelche andere
Nicht-CPU/GPU-Hardware (z.b. Cache, Cryptounit,...) auf dem Die mit der
CPU zu tun.
> Und wichtiger: Gibt> es das Ding auch auf Systemen, bei der die CPU keine integrierte GPU> hat?
Ich nehme mal an: Nein. Was aber keine technischen Gruende, sondern
schlicht Kaufmaennische haben wird. Eine Kombi aus CPU und HW-Videocodec
ohne Graphikeinheit wird sich wohl nur zum transcodieren und da auch nur
eingeschraenkt (weil ja fuer Farbraumkonversion, chroma-up/downsampling,
aenderung der Aufloesung noch Zeugs aus der GPU noetig ist) nutzen
lassen. Und so gross und preissensitiv wird der reine Transcodermarkt
wohl nicht sein, dass sich sowas lohnt, auf den Markt zu bringen.
Das ist ja jetzt auch nicht nur beim PC so, mit dem Videocodec in HW
neben der GPU, sondern bei allen Tablet und Smartphonechips, die
irgendwie erfolgreich sind/waren.
Gruss
WK
