va-api mit Intel-Systemen - was kann welche CPU mit integrierter GPU?

Ich habe in meinem "Spiel-Mini-ITX" System einen Dual-Core Celeron G540 mit OPENELEC laufen.
Dabei geht 1080p Video hardwarebeschleunigt ohne Ruckler. CPU dümpelt immer mit 10% vor sich hin.

Gruß

Marcus

Zitat von Boss666

1.) Bislang ist immer von Intel-CPUs mit integrierter HD2000 oder HD3000 GPU die Rede. Also alles ab Corei3 der Sandy-Bridge-Generation. Umkehrschluss: Die Sandy-Bridge-basierten Celerons mit HD-GPU - nähere Infos, was das genau für eine GPU ist, fehlen wenn man sich auf ark.intel... versucht zu belesen - können nicht hergenommen werden oder reichen nicht für va-api aus?

Hi,

soweit ich da noch den überblick habe funktioniert ab der Sandybridge Generation das Bob deinterlacing. Auch die Ivybridge kann bob. Dann verließen sie ihn, weil leider die besseren deinterlacer nicht aktiviert werden. Bezüglich der Celerons kann ich dir nichts sagen. Produktiv kann man vaapi meiner Meinung nach nur für Progressiv vernünftig einsetzen.

Gruß
Atech

Zitat von Boss666

2.) Wie schaut es mit Intel-Ivy-Bridge und deren HD4000-Grafik aus? Ist da wiederum die Basis Ubuntu 12.04 (mit yaVDR 0.5) zu alt, damit va-api funktioniert? Zumindest von den Zahlen her, dürfte die doch leistungsfähiger sein?

Gleiches Spiel. die Leistung ist da aber man kann sie mangels fehlender vaapi implemetation nicht abrufen. Eben nur für "p" Wiedergabe und dann gibt es noch den 24p Bug. Der könnte aber mitlerweile ausgeräumt sein.

Für VDR Belange ist kein großer Unterschied bei den CPUs.

Alle SandyBridge HD, HD1000, HD2000, HD3000 haben die gleichen Dekoder.
Alle Ivy Bridge HD 2500, HD4000 haben die gleichen Dekoder.

Bis 1920x1080 und nur ein Stream sollte zwischen allen kein Unterschied sein.

Bei den Celeron/Pentium fehlt Quick Sync und Clear Video HD, daß sind Encoder
und zb. Hautton Filter.

Zuverläsig läuft bei mir Sandy Bridge, ob Ivy Bridge genauso läuft habe ich noch nicht
getestet.

Auf jeden Fall sollte man immer aktuelles Kernel, Intel X11 Treiber und libva mit
vaapi-intel verwenden.

Im Test haben die Intel GPUs einen genauso guten Deinterlacer wie NVidia:
http://www.anandtech.com/show/…ridge-an-htpc-perspective

Das Problem ist, daß va-api diese nicht zur Verfügung stellt.
Es darf gerne mal jemand auf der VA-API Mailingliste nerven gehen.

Also können im Moment nur Bob Deinterlacer mit Linux verwendet werden.

Johns

Zitat von johns

Zuverläsig läuft bei mir Sandy Bridge, ob Ivy Bridge genauso läuft habe ich noch nicht
getestet.

Bei mir läuft es hier im Testaufbau auch auf einer Ivy Bridge CPU mit HD4000 ganz ordentlich.
Einige Kanäle in der mitgelieferten channels.conf bingen den VDR zwar zum Absturz, dass kann aber daran liegen, dass ich nur eine DVB-S Karte drin habe. Ansonsten läuft es aber problemlos, auch Spulen, Schnittmarken setzen usw.

Zitat von johns

Alle SandyBridge HD, HD1000, HD2000, HD3000 haben die gleichen Dekoder.
Alle Ivy Bridge HD 2500, HD4000 haben die gleichen Dekoder.

Bis 1920x1080 und nur ein Stream sollte zwischen allen kein Unterschied sein.

Bei den Celeron/Pentium fehlt Quick Sync und Clear Video HD, daß sind Encoder
und zb. Hautton Filter.

Hast du da sinvolle Unterlagen zu gefunden?
Also mehr als dieses übliche Marketing-Zeug?

Zitat von johns

Also können im Moment nur Bob Deinterlacer mit Linux verwendet werden.

Ich hatte mir letztens mal den Treiber näher angesehen, weil die Besseren Deinterlacer ja in der Doku beschrieben werden.
Der beschriebene kombinierte deinterlace-denoise-Filter wird auch so wie beschrieben aufgerufen, warum dann aber nur BOB raus kommt ist mir nicht ganz klar. Ich vermute mal, dass der Filter einfach nicht fertig programmiert wurde, bei dem Assambler-Zeug steig ich aber nicht durch. Irgendwie finde ich den Code für einen ausgefeilten Deinterlacer aber erstaunlich kompakt.

Der Intel Encoder wird im VA-API Intel Treiber benutzt: http://cgit.freedesktop.org/vaapi/intel-driver/
Früher war er nur um im vaapi-ext in wie weit sich dies verändert hat, habe ich nicht verfolgt.
Auf der VA-API Mailingliste gibts auch welche, die den schon verwenden.

Zu Clear Video HD habe ich nur Marketing-Zeug gelesen.

Zu dem advanced Deinterlacer: Du mußt im richtigen Branch gucken, in diesem sind die
richtigen "Shader" vorhanden. Wie ich mir das Letzte Mal angeguckt habe, war es im vaapi-ext.

Die Shader sind recht einfach, die müssen nur die Register richtig programmieren und dann
die Hardware aktivieren. Sowie ich es gesehen habe, macht die Arbeit eine spezielle Hardware
Einheit, deshalb ist die Programmierung recht einfach.

Sowie ich es sehe kann der aktuelle Shader, den Besten Hardware Deinterlacer.
Das was fehlt, ist das richtige Ansprechen des Shaders aus dem Treiber.
Der temporal spatial Deinterlacer braucht eine Referenceframe um temporal
zuarbeiten, diese wird aber nicht übergeben.
Die letzte Änderung im Treiber war,, diesen Shader gar nicht mehr zu verwenden.
Also nur Bob zumachen, davor wurde der Shader ohne diese Referenceframe
verwendet und hat damit nur Spatial gearbeitet.

Also für jemand der mit dem Treiber auskennt, sollte es kein großes Problem sein,
den Advanced Deinterlacer zu aktivieren.

Es kann natürlich sein, daß in diesem Hardwarefehler drin sind und sie deshalb
nicht angesprochen werden.

Ich bin zwar auf der VA-API Maillingliste angemeldet, aber ich habe nie die Zeit
und Motivation gefunden, dieses Thema anzusprechen.

Johns

Zitat von johns

Der Intel Encoder wird im VA-API Intel Treiber benutzt: http://cgit.freedesktop.org/vaapi/intel-driver/
Früher war er nur um im vaapi-ext in wie weit sich dies verändert hat, habe ich nicht verfolgt.
Auf der VA-API Mailingliste gibts auch welche, die den schon verwenden.

Ist der denn inzwischen schon vollständig?
Ich hatte irgendwo im Changelog gelesen, dass der bislang nur I-Frames kann.

Zitat von johns

Zu dem advanced Deinterlacer: Du mußt im richtigen Branch gucken, in diesem sind die
richtigen "Shader" vorhanden. Wie ich mir das Letzte Mal angeguckt habe, war es im vaapi-ext.

Die letzte Änderung im vaapi-ext ist jetzt 11 Monate her. Ich dachte, der ist nicht mehr aktuell.

Zitat von johns

Sowie ich es sehe kann der aktuelle Shader, den Besten Hardware Deinterlacer.

So habe auch ich die Beschreibung verstanden.

Zitat von johns

Das was fehlt, ist das richtige Ansprechen des Shaders aus dem Treiber.
Der temporal spatial Deinterlacer braucht eine Referenceframe um temporal
zuarbeiten, diese wird aber nicht übergeben

Ich hatte in dem noch immer aktuellen .19 geschaut und da sieht es prinzipiell nicht schlecht aus.
Das mit dem Referenceframe hatte ich zuerst auch gedacht, inzwischen bin ich da aber nicht mehr so sicher.
So wie es aussieht speichert der Shader das letzte Frame für den nächsten Lauf (PL_DNDI_ALG.asm).

Zitat von johns

Die letzte Änderung im Treiber war,, diesen Shader gar nicht mehr zu verwenden.
Also nur Bob zumachen, davor wurde der Shader ohne diese Referenceframe verwendet und hat damit nur Spatial gearbeitet.

In der .19 ist der Aufruf zumindestens noch drin, sofern ich da nicht irgendwo übersehen habe, dass er gar nicht benutzt wird.
Ab welcher Version ging denn nur noch BOB? Ich kenne nämlich nicht anderes.
Spatial wäre zumindestens besser als der aktuelle Zustand.

Zitat von johns

Es kann natürlich sein, daß in diesem Hardwarefehler drin sind und sie deshalb
nicht angesprochen werden.

Hardwarefehler eher nicht, das müsste dann auch bei anderen Betriebssystemen auftreten.
Wenn ist da ein Wurm in dem Assambler-Zeug.

Zitat von SHF

Ist der denn inzwischen schon vollständig?
Ich hatte irgendwo im Changelog gelesen, dass der bislang nur I-Frames kann.

So genau habe ich nicht aufgepasst.

Zitat

Die letzte Änderung im vaapi-ext ist jetzt 11 Monate her. Ich dachte, der ist nicht mehr aktuell.

So habe auch ich die Beschreibung verstanden.

Ich hatte in dem noch immer aktuellen .19 geschaut und da sieht es prinzipiell nicht schlecht aus.
Das mit dem Referenceframe hatte ich zuerst auch gedacht, inzwischen bin ich da aber nicht mehr so sicher.
So wie es aussieht speichert der Shader das letzte Frame für den nächsten Lauf (PL_DNDI_ALG.asm).

In der .19 ist der Aufruf zumindestens noch drin, sofern ich da nicht irgendwo übersehen habe, dass er gar nicht benutzt wird.
Ab welcher Version ging denn nur noch BOB? Ich kenne nämlich nicht anderes.
Spatial wäre zumindestens besser als der aktuelle Zustand..

Alles anzeigen

Ich habe mal etwas tiefer gesucht, der aktuelle Branch mit den richtigen Deinterlacer Shadern ist im Moment "staging".

src/shaders/post_processing/gen5_6/Core_Kernels/DNDI.inc ist der Shader für Sandy Bridge.
Die dazu gehörige C Funktion ist pp_nv12_dndi_initialize in src/i965_post_processing.c.

Diese müsste eine Alte Fläche für den Temporalen Deinterlacer übergeben.
Dazugehörige Documentation ist IHD_OS_Vol4_Part1.pdf 2.8.6.1 Input and Output Frames

Das Problem ist das Intel im Moment nur 2.8.6.3 First Frame Special Case verwendet.

sampler_dndi[index].dw6.dndi_first_frame = 1

Die Documentation der Register ist auf Seite 107.

Somit wird nur ein Spatial Filter angewandt.

Im alten Branch habe ich durch:

diff --git a/src/i965_drv_video.c b/src/i965_drv_video.c
index 7096fd3..09a752e 100755
--- a/src/i965_drv_video.c
+++ b/src/i965_drv_video.c
@@ -3201,9 +3201,9 @@ i965_PutSurface(VADriverContextP ctx,
         pp_flag |= I965_PP_FLAG_AVS;
 
     if (flags & VA_TOP_FIELD)
-        pp_flag |= I965_PP_FLAG_TOP_FIELD;
+        pp_flag |= I965_PP_FLAG_TOP_FIELD | I965_PP_FLAG_MCDI;
     else if (flags & VA_BOTTOM_FIELD)
-        pp_flag |= I965_PP_FLAG_BOTTOM_FIELD;
+        pp_flag |= I965_PP_FLAG_BOTTOM_FIELD | I965_PP_FLAG_MCDI;
 
     src_rect.x      = srcx;
     src_rect.y      = srcy;

Den Deinterlacer wieder aktiviert. Der Spatial Filter war deutlich besser als der Bob.
Wobei er den Effekt hatte, das am Anfang eine Linie flimmerte und dann das Flimmern
verschwand.

Ich würde einfach mal auf der Mailingliste fragen, warum es noch keinen gescheiten
Deinterlacer gibt, bevor wir jetzt rumrätzeln.

In staging ist auch die API, die dann benutzt werden soll http//cgit.freedesktop.org/vaapi/libva/tree/va/va_vpp.h?h=staging
Als ich das letzte Mal geguckt habe, war die aber für Intel noch nicht implementiert.
Sobald da etwas vernünftiges rauskommt, baue ich die API in mein Ausgabe Plugin.

Johns

Zitat von Boss666

Ich verstehe zwar nur Bahnhof von dem, worüber Ihr Euch hier austauscht, wenn aber der Thread hilft für ein besseres Deinterlacing bei den integrierten Intel-GPUs weiterzukommen, umso besser...

Wirklich den Überblick hab ich da auch nicht, was da von meiner Seite kommt ist alles nur gefährliches Halbwissen :D.
Ich hatte mir das nur an einem Abend in Weihnachts-Feiertagen mal angesehen und das auch nur, da ich eher zufällig über die Beschreibung der Arbeitsweise des Deinterlacers in deren Dokumentation gestolpert bin. Da war ich dann doch neugierig, ob da so schon im Treiber ist oder nicht.

Eigentlich hatte ich gehofft da irgendwo eine sinnvolle Gegenüberstellung der Fähigkeiten der einzelnen Grafikkerne zu finden, aber Fehlanzeige.
Bislang konnte ich jedenfalls noch keine wirklichen Unterschiede/Einschränkungen der Grafikeinheiten (HD - HD4000) im Bereich Decoding / Deinterlacing finden.
Da würde mich auch noch immer eine gescheite Übersicht interessieren. Besonders da im Mac die besseren Deinterlacer wohl nur mit der HD3000 gehen sollen, das verunsichert mich etwas.

Ach so, weil du nach der HD-4000 Unterstützung fragtest. Ich hab bislang mit den Paketen gearbeitet, die bei Debian Wheezy dabei waren und es ging seit Anfang an.
Der Kernel ist 3.2.0. An die ursprüngliche Version den Inteltreibers kann ich mich nicht erinnern, aktuell ist die 1.0.17 drauf.

Zitat von johns

Ich würde einfach mal auf der Mailingliste fragen, warum es noch keinen gescheiten
Deinterlacer gibt, bevor wir jetzt rumrätzeln.

Erstmal vielen Dank für die ganzen Informationen!
Viel rumrätseln werde ich da nicht, aber den Treiber aus dem "staging" Branch werde ich mir mal bauen. Den Spatial Deinterlacer muss ich mir einfach ansehen!

Momentan wird da viel an der Unterstützung der kommenden Haswell-CPUs gearbeitet, ich denke es hat für Intel Priorität die Grafik da bis zum Verkaufsstart brauchbar um laufen zu bringen.
Wenn danach sich noch immer nichts Richtung Deinterlacing tut muss man wohl mal anfangen etwas zu nerven.

Zitat von johns

In staging ist auch die API, die dann benutzt werden soll http//cgit.freedesktop.org/vaapi/libva/tree/va/va_vpp.h?h=staging
Als ich das letzte Mal geguckt habe, war die aber für Intel noch nicht implementiert.
Sobald da etwas vernünftiges rauskommt, baue ich die API in mein Ausgabe Plugin.

Das ist mir auch aufgefallen, momentan scheint nur Deinterlacing an oder aus zu gehen.
Wenn der Deinterlacer brauchbar wäre, könnte ich aber damit leben.

Um die ganze Deinterlacer-Diskussion auch mal für die Allgemeinheit zusammen zu fassen:
Der hochwertige Deinterlacer ist prinzipiell schon im Treiber vorhanden (die hardware-nahen Teile).
Laut johns Aussage scheint zumindestens Spatial-Deinterlacer aktivierbar zu sein und auch zu funktionieren. Ich gehe mal davon aus, dass Temporal-Teil auch funktionieren wird, der ist nur nicht so einfach mal zu aktivieren.
Die Funktionsweise dieser Hardware-Deinterlacer ist auch in der Dokumentation (ab Seite 39) recht ausführlich und verständlich beschrieben. Wenn man nach der Beschreibung geht sollte der Deinterlacer auch zu dem in der Lage sein, was Nvidia derzeit bietet.
Wo es fehlt ist "lediglich" die Anbindung an die Libva, also die Verbindung von vaapi zum Treiber.

Es fehlt also eigentlich nicht mehr viel, bis die Deinterlacer auch unter Linux laufen. Die Anpassungen am Treiber sind mehr oder weniger nur Fleissarbeit, die wichtigen Teile sind schon da. Wenn sich mal jemand, der Ahnung hat, der Sache annimmt dürfte die Anpassung nicht lange dauern. Sofern da nicht doch noch irgendwas im Argen liegt, besteht also durchaus Hoffnung ...

Hier gibt es noch die offizielle Übersicht, was welche GPU mit VAAPI dekodieren kann: https://01.org/linuxgraphics/community/vaapi
Leider keine Angaben zu Auflösungen und Deinterlacern.
Und die Sandy-/Ivy-Bridge Celerons sind garnicht erwähnt.

Ich zitiere Mal eine Mail die ich letztens an das yaVDR Team geschrieben habe:

Zitat

Nachdem ich ja die IvyBridge (G1610, DH77EB) HW hier habe, hatte ich mir mal wieder die Mühe gemacht und SHD mit Intelgrafik gestestet.

Ist mit Ubuntu etwas mühsam, aber basierend auf Precise habe ich alles zum Laufen gebracht, VDR 1.7.33 aus unserem unstable-vdr, SHD eine Spielversion von seahawk1986. 720p mit IvyBridge läuft super, 1-3% CPU, skaliert sehr schön auf FullHD. Aber Hardware Bob für 576i & 1080i war in keiner Konstellation nutzbar, die GPU stieg sofort aus, nur johns' Software Bob war nutzbar. 576i läuft rund aber 1080i nicht wirklich fehlerfrei, damit nicht sinnvoll nutzbar. Leistungsaufnahme bei 720p ~ 37W, DH77EB, Celeron G1610, 2x4GB, 1x WD10EADS, BeQuiet L7 300W, hier steckte noch die mPCIe Bridge (ngene) ohne Tuner drin.

Johns' meinte meine SW/Treiber Kombination sollte mit SandyBridge gehen, also die Platte an mein Fujistsu D3017-S11 (Q67) mit Celeron G460 angeschlossen, 720p auch nur 1-3% CPU, aber die gleichen Interlaced Fehler, ein Tip von Johns hat dann geholfen. Als AccelMethode das ältere UXA nutzen und alle Intel Stromspar-Features (!) abschalten. Damit konnte ich HW Bob einschalten, aber 576i Bild eher noch schlechter als bei SW Bob, 1080i noch weniger gut nutzbar, grünes Bildflackern bei Anixe & Servus TV. Leistungsaufnahme ohne Stromspar-Features bei 720P ~ 40W, Fujitsu D3071-S11, Celeron G460, 2x4GB, 1xWD10EADS, BeQuiet L7 300W, hier ist noch eine L4M V5.5 eingebaut gewesen.

Zum Vergleich beide liegen im Desktop-Modus bei etwa 26W.

So wie es aussieht werden die Treiber von Intel immer besser, wie auch die IvyBridge Grafik unter Windows leistungsfähig ist. Aber die Sparbemühungen laufen wohl entgegen der Nutzbarkeit für sinnvolle Video-Wiedergabe im Hinblick auf den VDR. Mein zukünftiger Haupt-VDR läuft voll ausgestattet auch mit nur 40W und ich habe ein bomben Bild dank Nvidia-Grafik für alle Format, temporal bei 1080i, spatial bei 576i. Von nix kommt halt nix, das hatten wir bei Nvidia schon gesehen und hier hat Hardware-Bob ein tolles Bild …

Alles anzeigen

Die Leistungsaufnahme steigt hier bei 720p um ca. 12-14W an, das ist mehr als bei aktuellen Nvidia Karten, die einen solchen Mehrverbrauch nur bei 1080i haben, welcher dann aber ein geniales Bild mit min. temporal als Deinterlacer hat. 40W schaffe ich ebenso mit dem "NVS 300" VDR aus meiner Signatur und da ist ein optisches Laufwerk drin, ebenso eine aktive DVB-S2 Dual Karte, ein gut lesbares recht großes VFD und eine MCE Empfänger dran, fehlerfreies Bild mit SHD, temporal_spatial bei 576i, temporal bei 1080i und mit Nvidia's Bob hält Intel nicht mal im Ansatz mit.

Mal sehen ob das Intel jemals hinbekommt, weil mit weniger als wir mit Nividia Karten haben kann sich angesichts der eher hohen Leistungsaufnahme niemand zufrieden geben, also in Bezug auf Verfügbarkeit der Funktion, Qualität der Deinterlacer etc. Intel's Bob ist schlecht, anders kann man es IMHO nicht sagen.

Regards
fnu

Der einzige Vorteil der Intellösung wäre, ein sauberer Boot, da man hier dann modesetting benutzen kann. Also Boot und sauberer Übergang ins X ohne Flackern. Angesichts der Probleme und das das jetzt schon seit Jahren nur begrenzt gut ist muss man/kann man sich wohl ans Flackern gewöhnen. (https://wiki.archlinux.org/index.php/Kernel_Mode_Setting)

Zitat von fnu

Die Leistungsaufnahme steigt hier bei 720p um ca. 12-14W an,

Bei mir (HD4000) sind es etwa 9-10W zwischen VDR aus und laufendem VDR mit Ausgabe. Das schliesst auch schon die DVB-Karten usw. ein.
Einen Unterschied zwischen 560i und 720p sehe ich übrigens keinen. (1080i konnte ich mangels Material noch nicht testen.)
Ohne Ausgabe braucht der Rechner bei gestartetem VDR auch ca. 6-8W mehr.

Zitat von fnu

Intel's Bob ist schlecht, anders kann man es IMHO nicht sagen.

Für meinen Geschmack auch nicht schlechter als jeder andere BOB .
Der Spatial ist da schon besser, der kommt in etwa an johns Software Spatial ran.

Zitat von steffen_b

Der einzige Vorteil der Intellösung wäre, ein sauberer Boot, da man hier dann modesetting benutzen kann.

Du vergisst da die mini mikro ITX Pralinenschalchtelgehäuse-Freaks.
Wenn man unbedingt so klein bauen will hätte der Wegfall der Grafikkarte deutliche Vorteile.

Zitat von SHF

Bei mir (HD4000) sind es etwa 9-10W zwischen VDR aus und laufendem VDR mit Ausgabe.

Rechnet es Euch ruhig schön, habe durchaus Verständnis das es Euch nicht passt, das die €170,- CPU kaum mit eine €20 Grafikkarte mithalten kann, aber nichts weniger kann der Anspruch sein. Bei dem Preis ist sogar der Vergleich zu einer Nvidia Quadro FX 580 oder 600 nur gerechtfertigt und die brauchen beide nicht mehr Leistung für das Beste Bild das man aktuell bekommen kann ...

Zitat von SHF

Einen Unterschied zwischen 560i und 720p sehe ich übrigens keinen.

Netter Versuch, Bruder Grimm ...

Das ist technisch schon gar nicht möglich oder Dein Monitor ist so lausig schlecht und klein, das er kein Maßstab sein kann ...

Zitat von SHF

Für meinen Geschmack auch nicht schlechter als jeder andere BOB

Tja, dachte ich auch bis ich dieses schreckliche Bild der Intelgrafik gesehen habe. Johns hat das in SW sichtbar besser gelöst ...

Hast Du jemals eine Nvidia Karte für die VDR Ausgabe benutzt?

Regards
fnu

Zitat von fnu

Rechnet es Euch ruhig schön, habe durchaus Verständnis das es Euch nicht passt, das die €170,- CPU kaum mit eine €20 Grafikkarte mithalten kann, aber nichts weniger kann der Anspruch sein.

Ich rechne garnichts schön, das ist der aktuelle Messwert.
Den I5 hab ich halt in meinem Arbeitsrechner (aus ganz anderen Gründen), der muss jetzt mal für die Tests herhalten.
... und wer sagt dir, dass da nicht noch eine andere Grafikkarte drin ist ?

Zitat von fnu

Netter Versuch, Bruder Grimm ...

Das ist technisch schon gar nicht möglich oder Dein Monitor ist so lausig schlecht und klein, das er kein Maßstab sein kann ...

Ich sprach über den Verbrauch!
Bei der Bildqualität gibt es, je nach Sendung, natürlich beträchtliche Unterschiede.

Zitat von fnu

Tja, dachte ich auch bis ich dieses schreckliche Bild der Intelgrafik gesehen habe. Johns hat das in SW sichtbar besser gelöst ...

Ich habe es gerade mit den aktuellen Treibern getestet, und einen wesentlichen Unterschied sehe ich da nicht.
Bei beiden wackelt das Bild schrecklich.

Zitat von fnu

Hast Du jemals eine Nvidia Karte für die VDR Ausgabe benutzt?

Natürlich und nicht nur eine, ich hab mir sogar extra ein ION-Netbook als tragbaren Player angeschafft.
An den Temporal-Spatial-Deinterlacer von Nvidia kommt die Intel-Lösung momentan nicht ran und das hab ich auch nie behauptet!
Die Tatsache ist übrigens auch hinreiched bekannt und wurde hier im Thread auch schon einmal erwähnt (siehe oben) und das reicht.

Zitat von SHF

Ich sprach über den Verbrauch!

Na dann schreibs auch so ...

Ja, das ist analog zu den Nvidia Karten wo 576i & 720p auch in etwa die gleiche Leistungsaufnahme haben. Ich hatte bei 576i mit der Intelgrafik Augenschmerzen und konnte das Meßgerät nimmer sehen ...

Zitat von SHF

Bei der Bildqualität gibt es, je nach Sendung, natürlich beträchtliche Unterschiede.

Dank für die Klarstellung, ich dachte schon was geht hier denn ab ...

Zitat von SHF

Bei beiden wackelt das Bild schrecklich.

johns' SW Bob war für mein Geschmack hier besser und vorallem stabiler ...

Regards
fnu

Moin,

Also BOB müsste gleich BOB. Laut Definition wird einfach das obere
Halbbild für die erste Frame und das Untere für die zweite.

Es kann natürlich sein, daß die Hardwaredekoder doch etwas mehr
machen. Das war bei den ersten Treibern von Intel für VA-API aus
dem vaapi-ext Branch so.

Also ich habe nochmal den aktuellen Stromverbrauch gemessen.

Kernel 3.7.6 (i915.powersave=1 i915.i915_enable_fbc=1 i915.i915_enable_rc6=1)
Intel 2.21.3 / libva 1.1.0 / libva-intel 1.0.19
HDMI + Netz 1Gbit + IR angeschlossen.
G620 / H61M-ITX / 8GB / SanDisk SDSSDP064G / BeQuiet 80mm Lüfter
Netzteil ist ein 120 Watt aus dem Lian Li PC-Q09 + 72 Watt MW A2102GS/F2USB
Energiemesser wie immer Conrad 3000

Idle (mit und ohne X11) 14.6 Watt
576i (RTL) 19.0 Watt
720p (1 HD) 19.7 - 20 Watt
1080i (Anixa HD) 18.1 - 19.1 Watt

Also hier sind es nur 5 Watt Mehrverbrauch für SDTV.

VDR 1.7.38 stürtze hier ab, mit Speicherkorruption. 1.7.36 funktionierte mit
der selben Konfiguration. Da muß ich noch mal suchen. Edit: habe etwas
weitergesucht, scheint am Gentoo Extension Patch zuliegen. Edit2: an yaepg
liegt es.

Johns

Der Verbauch idle ist jetzt auf 13.3 Watt gesunken.
Entweder lag es an i915.i915_enable_rc6=7 oder einfach ist nach einiger Zeit noch mehr
Hardware schlafen gegangen. Kann auch am neuen 3.8 Kernel liegen.

Johns