Test Intel Wireless Display im Test: Kabellose Übertragung mit Fallstricken

[0x4A6F686E]

Du solltest nicht nur von h.264 ausgehen. Die Redakteure bei Heise sind in der Regel recht kompetent und Tomaten auf den Augen würde ich denen nicht unterstellen.

Wenn die Daten direkt am Chip abgegriffen werden, muss nicht unbedingt ein Videostream im herkömmlichen Sinne komprimiert werden. Es kann gut sein, dass es z.B. einer RDP-Übertragung ähnelt. Über den verwendeten Codec bzw. die technischen Details habe ich bisher leider noch nichts gefunden. Intel schweigt sich scheinbar vorerst aus.

HDTV in 720p braucht auch nicht unbedingt 16 MBit/s, um gut auszusehen. Die Datenraten bei ARD und ZDF sind nur so hoch, weil ziemlich viele 0x00-Bytes gesendet werden. Warum die das so machen, weiß der Geier. Wenn ich den TS jedoch demuxe und einen MKV daraus mache, fallen viele Null-Bytes raus.

Mal ganz davon abgesehen bin ich auch der Meinung, dass eine direkte HDMI-Verbindung an dieser Stelle die bessere (aber wenn es Kabellos sein soll auch die deutlich teurere) Lösung ist.

 

[Blutschlumpf]

Du darst nicht nen Film nehmen und gucken was der über die 2h an Bitrate hat.
Kann ja durchaus sein, dass du da auf 10MBit kommst, du aber einzelnen Szenen hast die mit 50MBit über ein paar Sekunden laufen.

Ich tippe mal die kommen nur deshalb mit 8MBit aus weil die maximale Auflösung so klein ist.
Und selbst da gibts bestimmt Bildinhalte mit denen man die Komprimierung überfordern könnte, ob das dann in der Praxis passiert ist ja wieder ne andere Sache.

 

[0x4A6F686E]

@Blutschlumpf:
Dessen bin ich mir bewusst. Schau' dir mal einen Transponder-Stream von ARD HD an, dann siehst du was ich meine.

Des weiteren ist in dem Heise-Artikel die Rede von maximal 8 MBit/s. Es wird also durchschnittlich weniger Bandbreite benötigt. Bei Videos sollen es 5 MBit/s durchschnittlich sein, nur bei schnellen Bildwechseln bis zu 8 MBit/s. Stellt sich natürlich die Frage, wie man 1366x768x24 @60(?)Hz in einen Stream mit max. 8 MBit/s stopft und die WiDiApp.exe dabei nur ca. 20% Last auf der CPU produziert. Mit h.264 wird da also eher nicht gearbeitet und daher kann man die Datenraten auch nicht vergleichen.

 

[Blutschlumpf]

Intel kann auch nicht zaubern und wenn die CPU-Last so gering ist wird die Kompression fast schon zwangsweise schlechter sein als bei aktuellen Videocodecs.

 

[0x4A6F686E]

Deswegen schrieb ich ja weiter oben schon, dass man es mit den gängigen Videocodecs nicht vergleichen sollte.

 

[BlackSkull]

Hört sich ja so weit recht gut an =) Nur leute die AMD haben sind son bissel in den Arsc* gekniffen