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 Grafikkarte Udo 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.
Du schaust hier aber bei den GK, die meist mehr kosten als die CPU... Der normale Weg ist die HW Einheit der CPU, der leistungseffizienter ist.
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!
Ich habe ja oben schon eine umfangreiche Liste von Nvidia verlinkt. Wer es danach noch nicht glaubt, der ist nicht mehr zu retten.
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.