Warum HDTV so "teuer"?

  • Ich frage mich, warum der VDR HDTV Empfang über xinelib und Grafikkarte so teuer ist? 720p HDTV Sendungen bringen mein System zum Zusammenbruch, während 1080p AVC Videos von Festplatte mit ~50% CPU Last laufen.


    Ist der VDR einfach noch nicht auf HDTV richtig angepaßt, oder woran liegt es daß der Hardwareverbrauch gegenüber SDTV so überproportional steigt?

  • Es liegt einfach nur daran:


    Keine Hardware-Unterstützung für Linux


    Egal ob ATI (UVD) oder NVIDIA (PureVideo) - beide haben schon Technik in Ihren neueren Grafikkarten/Chipsätzen drin mit denen das Abspielen von HDTV und auch SDTV unterstützt werden könnte. Nur kann man es mit Linux (und somit auch nicht mit VDR) nutzen.


    Hinzu kommt noch, das Videomaterial und Ausgangssignal nicht synchronisiert werden, weshalb man rechenintensiv einen Software-Deinterlacer braucht, damit es kein Geruckel z.B. bei Laufschriften oder schnellen Bewegungen gibt. Sparkie hat da aber schon wegweisendes Zustande gebracht.


    Ich selbst besitze ein Mainboard mit einer NVIDIA 7050PV Onboard-Grafik, die eigentlich PureVideo kann. Nur nutzen kann ich es nicht. Und es scheint sich auch mittelfristig nichts zu tun. Daher kann ich jedem nur von NVIDIA abraten. Werde mir wohl über kurz oder lang ein GA-MA78GPM-DS2H mit ATI-Onboard-Grafik zulegen. Langsam bewegt sich nämlich bei AMD/ATI was.


    Gruß


    Joe_D

  • Ich meine schon die gleiche Kette. Wenn ich unter Linux in meinen X-Server auf dem gleichen System (aus VDR heraus) über die xinelib Videos von Festplatte abspiele - wie gesagt 1080p AVC Videos mit auch teilweise hoher Bitrate, ist die CPU Last deutlich geringer, als wenn ich über Xinelib 720p ARTE HD Sendungen im Fernsehbetrieb anzeige - oder auch aufgenommene VDR Sendungen in 720p.


    Dieses Mißverhältnis verstehe ich nicht ganz, und bei 720p braucht man doch auch keinen Deinterlacer? Habe auch schon andere Berichte gelesen, die in die gleiche Richtung gehen. Irgendwas in VDR scheint vergleichsweise viel Rechenzeit zu brauchen, weil ab der Xinelib sind die Wege doch sonst identisch, oder?

  • Gibt halt unterschiedliche kompressionsmöglichkeiten.
    Ein leicht komprimiertes 1080p Video kann weniger Rechenpower zum decodieren benötigen als ein 720p Video das extrem encodiert ist.
    Man kann nicht einfach 2 Videos vergleichen, Du weisst ja gar nich wie die encodiert sind, und selbst beim gleichen encoder gibt es diverse Einstellungen.

  • Hi,
    Wie netvista-fan schon schrieb, vergleicht Du Aepfel mit Birnen :)
    Nimm doch mal nen HDTV Stream via VDR auf und schaue das Ergebnis mit xine und mit vdr an.
    Wenn die Unterschiede dann immer noch so gross sind, koennen wir weiterreden :)

  • Zitat

    Original von netvista-fan
    Gibt halt unterschiedliche kompressionsmöglichkeiten.
    Ein leicht komprimiertes 1080p Video kann weniger Rechenpower zum decodieren benötigen als ein 720p Video das extrem encodiert ist.
    Man kann nicht einfach 2 Videos vergleichen, Du weisst ja gar nich wie die encodiert sind, und selbst beim gleichen encoder gibt es diverse Einstellungen.


    ja und nein. die einstellungen am encoder machen net viel anderes als die quantisierung im frequenzbereich zu beinflussen.
    was allerdings einen dicken unterschied macht, ist die art und weise wie die bilder untereinander verbunden sind, also die sache mit den I-, P-, und B-Frames.
    ansonsten macht natürlich auch der codec ansich unterschiede. h264 ist wegen der blockgrösse und dem stärkeren gebrauch von predictive coding wesentlich rechenintensiver als h262.

  • Zitat

    Original von netvista-fan
    Gibt halt unterschiedliche kompressionsmöglichkeiten.
    Ein leicht komprimiertes 1080p Video kann weniger Rechenpower zum decodieren benötigen als ein 720p Video das extrem encodiert ist.
    Man kann nicht einfach 2 Videos vergleichen, Du weisst ja gar nich wie die encodiert sind, und selbst beim gleichen encoder gibt es diverse Einstellungen.


    Jedes beliebige 1080p Video, was ich habe (diverse Quellen und knapp 500GB Material), braucht wesentlich weniger Performance zum Abzuspielen, als irgendein beliebiges Stück aus einer ARTE HD 720p Sendung.


    Zum Vergleich mit einem mit x264 selbst-encodierten 1080p Video und ~25Mbps Bitrate läuft es besser als ein ~12Mbps 720p ARTE HD Stück. Bei allen Tests konnte ich ein Gefälle


    Das Encoding ist eine Sache auf die ich auch hinaus wollte, bzw. was die TV Sendung unterscheidet, daß diese sich so unvorteilhaft decodieren lassen. Mein Verdacht war nämlich, daß irgendwas in der Kette mit diesen Streams noch nicht so gut klar kommt.


    Zitat

    Original von helau
    Hi,
    Wie netvista-fan schon schrieb, vergleicht Du Aepfel mit Birnen :)
    Nimm doch mal nen HDTV Stream via VDR auf und schaue das Ergebnis mit xine und mit vdr an.
    Wenn die Unterschiede dann immer noch so gross sind, koennen wir weiterreden :)


    Werde ich machen, aber wie spielt VDR das denn ab? Verwendet er nicht Xine, wenn ich über die Xinelib und den X-Server gehe?

  • Zitat

    Original von slime
    ja und nein. die einstellungen am encoder machen net viel anderes als die quantisierung im frequenzbereich zu beinflussen.
    was allerdings einen dicken unterschied macht, ist die art und weise wie die bilder untereinander verbunden sind, also die sache mit den I-, P-, und B-Frames.
    ansonsten macht natürlich auch der codec ansich unterschiede. h264 ist wegen der blockgrösse und dem stärkeren gebrauch von predictive coding wesentlich rechenintensiver als h262.

    Haben evtl. etwas ungewöhnliche Frametyp Anordungnen einen derart großen Einfluß auf die Performance?


    Bisher haben die 2x2.4GHz Core 2 Duo mit einer NVIDIA 8500GT eben immer gereicht, um von den Daten her vergleichsweise popelige 720p Streams mit vergleichsweise niedriger Bitrate locker abspielen zu können. Was bei ARTE HD kommt (anderen HD Sender habe ich nicht), bringt aber das System an die Grenzen und darüber hinaus.

  • imho basiert das doch alles auf ffmpeg und wenn das bei bestimmten dingen timig oder threading probleme macht...


    diese schwierigkeiten gabs doch schon bei den testsendungen zu ostern - ungleichmäßige auslastung der kerne und dadurch problme beim dekodieren mit zwei kernen
    es geht ja nich nur einfach so darum das es sequentiell dekodoert werden kann - wenn man zwei kerne zum dekodoeren "benötigt" muss man auch noch alles richtig verteilen - das sind gleich zwei probleme auf einmal den richtigen code richtig ablaufen lassen (verteilen)
    ich denke die entwickler von ffmpeg sind nicht die hdtv freaks und sitzen vermutlich nicht in europa


    PS: mit der eHD gibs bei ArteHD keine probleme (dafür aber bei anderen dingen)
    PPS: such mal im forum ich glaube das problem ist nicht neu und wurde nach ostern schon mal beleuchtet

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!