HDTV mit Intel X4500HD-Grafikchip Test und Ergebnisse

    Mahlzeit,


    habe die Tage mal das Intel-System mit dem intel dg45fc-Mainboard auf einen aktuellen Softwarestand unter Linux gebracht um mal zu sehen, was damit im Moment bezüglich HDTV geht.


    Hier mal eine kleine Zusammenfassung, was damit möglich ist und wo es im Moment noch zwickt:


    1. Softwarestand:


    - Debian Sid vom 01.07.2010
    - Kernel 2.6.34
    - X-Server 1.8.1 mit aktuellem Intel-Treiber 2.12.0


    http://intellinuxgraphics.org/2010Q2.html


    - Angepasste xorg.conf damit das Display (Samsung 650B) 50 Hz ausgibt.


    - aktuelle xine-lib-1.2 und aktuelles xine-plugin/vdr-xineliboutput-plugin


    2. Hardware siehe hier:


    http://wbreu.htpc-forum.de/min…lsystemfuerhdtv/index.php


    Eingebaut ist für den Test eine Intel Core2Duo 7200er CPU.


    3. Testfazit:


    3.1 Grundsätzlich kann das System sowohl mit xineliboutput als auch mit xine HDTV in 1920x1080 ausgeben, und das auch weitgehend ruckelfrei! Allerdings ist dann die CPU-Last bei ca. 70 bis 80% wenn das OSD auch noch geöffnet ist. SD-Wiedergabe ist durchgehend kein Problem, gerade beim xineliboutput-Plugin (vdr-sxfe-Wiedergabe) wird durch dessen Software-Scaling ein sehr gutes Bild auf den LCD ausgegeben (Deinterlacer = TvTime Vertical Blend (ffmpeg)).


    Laufschriften sind durch die 50 Hz absolut kein Problem. Ausgabetreiber der ist jeweils XV, da im Moment weder xxmc noch xvmc mit der xinelib/xine/xineliboutput und dem aktuellem Inteltreiber funktionieren.


    Insoweit ist die Hardware schon tauglich für einen VDR.


    3.2 Festgestellte Probleme:


    - Mit dem vdr-xine-plugin ist die Videoausgabe hervorragend aber das OSD sieht in allen möglichen Einstellungsvarianten (SHQ/X11/...) sehr ausgefranst und damit sehr sehr bescheiden aus. Bei X11 ist das OSD nicht transparent. Zudem sieht mir das Deinterlacing? sehr schwach aus. Was da auch immer als Deinterlacer genommen wird....
    Auch die CPU-Last ist bei geöffnetem OSD sehr hoch, da wäre wohl ein sauberes OSD-Scaling notwendig ähnlich dem xineliboutput-Plugin.


    - Mit dem xineliboutput-Plugin in der lokalen Variante ( -l sxfe ) geht erstmal gar nichts. Sobald man die Einstellung so macht und den VDR startet, kommt nur noch das VDR-No-Signal-mpg und das wars. Im Log steht, dass der VDR keine Daten empfängt und damit steht.
    Sieht so aus, als ob xineliboutput-sxfe hier ein Problem mit dem Video-Treiber xv hat, denn der selbe source geht auf dem vdpau-Rechner ganz sauber. Das ist aber nur eine Vermutung meinerseits, eventuell zwickt es ja auch woanders.


    - Mit der remote-Variante (-l none --remote=37890) sieht es schon besser aus.


    Hier gibts es sofort ein Bild und soweit ist auch alles sauber. Das OSD sieht dann gut aus, wenn man das Videoscaling aktiviert und auf 1920x1080 einstellt, und in den OSD-Einstellungen Software wählt, dann bleibt das OSD auch transparent und sieht echt super aus.


    Grundproblem ist hier, dass die TvTime-Deinterlacer Greede 2 Frame und Greedy Low Motion auf diversen Sendern (Sat.1, Pro Sieben, kabel eins, ...) zu Bildstehern führen. Soll heißen, man hört nur noch Ton und das Bild steht. Mit allen anderen Deinterlacern ist das Problem nicht da.


    3.3 Hardware-Features die nicht genutzt werden:


    - Beim aktuellen Intel-Grafiktreiber ist im Moment keine 1080i-Ausgabe über den X-Server möglich:


    Code
    [  1755.640] (II) intel(0): Not using mode "1920x1080@50i" (interlace mode not supported)
[  1755.640] (II) intel(0): Not using mode "1920x1080@60i" (interlace mode not supported)
[  1755.640] (II) intel(0): Not using mode "1920x1080@59.94i" (interlace mode not supported)


    - libva-Unterstützung (h264-Hardwareacceleration) für den VDR nicht möglich


    4. Ist es möglich HDTV-Sender auszugeben?


    Trotzdem ist es möglich mit dem System HDTV-Sender (Servus TV, ZDF HD, ARD HD,...) zu sehen, und das auch noch weitgehend ruckelfrei und mit dem Ausgabetreiber XV, alerdings mit hoher CPU-Last, da die CPU dann das Deinterlacing übernimmt.


    So wie ich das beurteile hat sich in der aktuellen ffmpeg-Version wieder etliches zum Guten gewendet, da das threading auf die beiden CPU's wieder sauber funktioniert und somit auch sehr sehr selten der Datenstrom stockt.


    sparkie, hast du schon mal den FRC-Patch auf HDMI getestet? Wäre der da auch möglich?
    In Kürze sollen beim Intertreiber nämlich die Interlaced-Modes möglich sein....


    Ich mach mich jetzt mal an die libva mit XBMC und TVHeadend als TV-Source, mal sehen was da möglich ist.


    Gruß
    Wolfgang

    Na, das ist ja dann noch ein weiter Weg, aber sicher auch ein spannender!


    Im groben deckt es sich mit den Erfahrungen meines Testsystems auf Basis des Intel DB43LD. (Der vom Camp.) Bei mir ist CPU (Celeron E3400) und Chipsatz (GMA 4500 ohne HD) allerdings leistungsmäßig nicht ganz der Dekodierung gewachsen, weil nie so geplant gewesen. Trotzdem ist das HD-Bild durchaus ansehnlich, mit gelegentlichen Rucklern, und immer noch erstaunlich leise, trotz hoher Last.


    Eine gute Perspektive hat das ganze, wenn es klappen sollte, die 1080i-Ausgabe zu aktivieren, und dann noch ein FRC-Patch zur sendersynchronen Frame-Ausgabe dazu kommt. Dann kann das Deinterlacing wieder dem Fernseher überlassen werden, wo es imho hin gehört.



    Gruß,


    Udo

    Hallo Wolfgang


    erst mal vielen Dank fuer deinen ausfuehrlichen Testbericht. Klingt ja bereits recht vielversprechend. Das Deinterlacing Problem sehe ich derzeit allerdings als die groesste Huerde an.
    Deinterlacing kann IMHO sinnvoll nur per GPU oder TV erfolgen.


    Zitat

    Originally posted by wbreu
    sparkie, hast du schon mal den FRC-Patch auf HDMI getestet? Wäre der da auch möglich?
    In Kürze sollen beim Intertreiber nämlich die Interlaced-Modes möglich sein....


    meine letzten Tests auf diesem Gebiet sind schon ueber ein Jahr her. Grundsaetzlich scheint FRC auch mit DVI moeglich zu sein.
    Es sehe allerdings Probleme, wenn Audio ueber HDMI genutzt wird. Ich vermute FRC in der Weise, wie es heute implementiert ist kollidiert mit der Audio Uebertragung ueber HDMI. Es besteht
    aber die Hoffnung, dass Intel vielleicht schon einen 'offiziellen' Mechanismus fuer FRC vorgesehen hat. Ich hatte leider noch keine Zeit die Specs genauer durchzulesen.


    Nachdem wir unter Intel (im Gegensatz zu VDPAU) wenigstens mal wieder OpenSource haben, koennte es sich lohnen hier weiterzuforschen.


    Auf den Tag bin ich gespannt, wenn die Intel Source Basis mal wieder interlaced Modi unterstuetzt:) Dann koennte ich endlich mal meine Entwicklungsumgebungen auf KMS hochziehen.


    - sparkie

    Zitat

    Original von tbshl-vdr
    Hallo,


    um das Deinterlacing mal anzusehen kann das Testprogramm hier Tester gesucht libva genommen werden.


    Gruss,
    Thomas


    Hallo Thomas,


    das habe ich gerade probiert, jedoch gelingt mir keine Wiedergabe mit dem Tool.


    libva-Version 0.31.1


    libva: va_openDriver() returns -1


    Fehlermeldung auf der Konsole:


    h264 number of reference frames exceeds max


    oder


    h264 mmco: urref short failure


    Sorry für die schlechten Fehlermeldungen, aber ich bekomme den Ausgabetext auf der Konsole im X-Server nicht kopiert.


    Kann man das irgenwie umleiten in ein log-File?


    Gruß
    Wolfgang

    Zitat

    Original von wbreu
    Sorry für die schlechten Fehlermeldungen, aber ich bekomme den Ausgabetext auf der Konsole im X-Server nicht kopiert.


    Was ist denn das für ne Konsole?
    Umleiten ganz normal (vatest ... >log.txt) bzw. '2>" um auch die stderr-Meldungen von ffmpeg usw. zu haben, aber die hier "h264 number of reference frames exceeds max" usw. sind eh erstmal uninteressant bzw. tauchen auch nur am Anfang auf wenn noch nicht genug Daten zum dekodieren da sind.


    Es muss aber noch "libva: Trying to open ..." da sein, dann musst Du mal sehen obs die Datei auch gibt, bei mir "/usr/lib/va/drivers/nvidia_drv_video.so", was wiederum ein Link nach /usr/lib/dri ist.
    Jedenfalls muss "libva: va_openDriver() returns" 0 sein.


    Das Backend ist auch installiert?

    Hi,


    Am Moment gibt's nur vaapi h.264 Unterstutzung für die I 3-5-7 Core von Intel (zusammen mit ein 2.6.35 Kernel).
    Vaapi für X4500HD ist unterwegs, normal für Endes dieses Jahr.


    Phoronix Intel HDTV vaapi


    Freundlichen Gruss,
    Steven

    VDRserver : Asrock n3700 + 8 GB ram + HDD Toshiba 3 TB (video) + 2 x 500 Gb (home) + Sandisk SSD 64 GB (OS) + Digital Devices Octopus Cine S2 + DD DVB T/T2-Operating System : Ubuntu Server (headless) 14.04 64 bit mit stable yavdr ppa


    VDRclient : Wetek Hub mit Libreelec (8.2 community build von kszaq)

    2 Mal editiert, zuletzt von steefjeqv ()

    Zitat

    Original von wbreu
    Das steht hier auf der Mailingliste:


    http://lists.freedesktop.org/a…fx/2010-March/006404.html


    Ah, danke.


    Zitat

    Original von wbreu
    Evtl. ist dann das auch mein Problem mit vatest?


    Geladen werden müsste das Backend aber schon:


    http://www.phoronix.com/forums…ad.php?t=21126#post105519


    Zitat


    On a new Debian/Ubuntu distribution with libdrm 2.4 or newer then you can use vainfo and mplayer -va vaapi -vo vaapi. But ONLY for MPEG2 currently. Next year this might change - the script will be the same.


    Zitat

    Original von wbreu
    Der Terminal ist der xterm.


    Markieren, und dann mit mittlerer Maustaste einfügen.

    Zitat

    Originally posted by sparkie
    Es besteht aber die Hoffnung, dass Intel vielleicht schon einen 'offiziellen' Mechanismus fuer FRC vorgesehen hat. Ich hatte leider noch keine Zeit die Specs genauer durchzulesen.


    jetzt bin ich die Specs


    VOL_1_graphics_core
    VOL_2_3D_media_web_updated
    VOL_3_display_registers_updated
    VOL_4_subsystem_core


    aus http://intellinuxgraphics.org/documentation.html mal etwas genauer durchgegangen. Ich sehe leider nicht, dass diese Intel Chipsaetze
    'native' FRC unterstuetzen. Sprich: die erforderliche dynamische Frame Rate Anpassung fuer Live-TV ist wieder
    nur (wenn ueberhaupt) nur mit Tricks moeglich.


    Ein weiteres grosses Problem, wenn das Deinterlacing nicht von der GPU erledigt wird:
    Man kann keine konstante Videoaufloesung zum TV hin mehr nutzen. Ansonsten muessten
    die beiden Fields (even und odd) separat auf der Grafik skaliert werden, was aber zu Artefakten
    fuehrt.


    Wenn keine konstante Videoaufloesung zum TV nutzbar ist wird die Zeit fuer einen Kanalwechsel fuer Sender mit unterschiedlicher vertikaler Aufloesung u.U. zum Trauerspiel.
    Viele TVs brauchen ewig, um hier wieder neu zu syncen.


    Das duerfte den wenigen existierenden FF-HD Nutzern auch schon aufgefallen sein:)
    Die FF-HD hat ja bekanntlich ebenfalls keine HD Deinterlacer an Bord.


    Also fuer HDTV bleibe ich der Ansicht, dass das Deinterlacing auf der GPU
    die besten Ergebnisse verspricht. Das ist derzeit nur mit nVidia GPUs moeglich.


    GPUs ohne vernueftigen Deinterlacer eignen sich fuer Live-TV mit Interlaced Formaten nur sehr bedingt.


    Lasse mich aber gerne vom Gegenteil ueberzeugen:)


    - sparkie

    Nabend,


    auch hier ein weiterer Zwischenstand:


    Den Fehler mit dem lokalen sxfe habe ich gefunden, => das Plugin screenshot hat die Ausgabe des Bildes beim Start blockiert. Wenn es nicht geladen wird, löppert die lokale Variante von xineliboutput ebenfalls sehr sehr sauber.


    Auch echtes HDTV (Fußball-WM sei Dank!) sieht super aus, aber auch hier schient xineliboutput die Probleme mit den beiden Greedy-Deinterlacern zu haben.....


    Was schön ist, mit xv-Ausgabe gibt es diverse Seiteneffekte (Tonstörungen beim Umschalten, kleinere Ruckler oder eben den Sync-Effekt) wie bei der vdpau-Variante absolut gar nicht. Solche Effekte habe ich bisher mit diesem System noch gar nicht beobachtet...


    Es scheint so, dass die ganze vdpau-Geschichte hier wirklich zu Fehlerintollerant ist,
    => soll heissen, auf jeden kleinen Zucker wird sofort reagiert und das sieht man dann sofort im Bild oder im Log => Framedrops.


    Einziger Nachteil ist die höhere CPU-Last (die CPU macht das komplette Deinterlacing im Threading), aber dafür hat man eben keine zusätzliche Grafikkarte eingebaut.


    Jetzt amch ich mich mal an die Mplayer(mit libva)-Einbindung, mal sehen wie die Geschichte läuft.


    Eventuell bekomme ich die nächsten zwei Wochen noch eine Mini-ITX-Clarkdale-System an den Test ( bin schon am Organiseieren...), dann könnte man die Qualität von h264 gleich mal antesten.


    sparkie, danke für deine Mühen, ich sehe dass trotzdem positiv, wenn man sich das Bild unter Windows ansieht, kommen mit den richtigen Treibern gute Deinterlacer zum Einsatz. Mal sehen was da Intel noch so offenlegt bei zukünftigen Treiberupdates.


    Gruß
    Wolfgang

    hey wolfgang,


    eine Frage OT, wie hast du den quer liegenden Lüfter auf Deinem Bild befestigt?


    gruß und dank vdr-box

    Zitat

    Original von vdr-box
    hey wolfgang,


    eine Frage OT, wie hast du den quer liegenden Lüfter auf Deinem Bild befestigt?


    gruß und dank vdr-box


    Hi,


    hinten ist der Lüfter mit isoliertem Draht an den USB-Kablen fixiert und vorne ebenfalls, sieht man direkt auf dem Foto, der schwarze Isolierdraht.


    Der Lüfter ist ein leiser 80 der mit 1200 U/min dreht, er sorgt für die Kühlung der beiden Kühlkörper für Chipsatz und Grafikkarte.


    Gruß
    Wolfgang

    Zitat

    Original von Copperhead
    Wie gibt denn xine aus? mit VAAPI?


    Xine ist leider noch aussen vor, da gibts noch nix, dass das möglich macht,
    leider....


    Im Moemnt geht nur via XV an xine anzudocken, siehe erster Post.


    Gruß
    Wolfgang

    Zitat

    Original von wbreu
    Xine ist leider noch aussen vor, da gibts noch nix, dass das möglich macht,


    Fast nix ;)
    Naja , nichts ausser hier (es sei denn natürlich, jemand anderes macht da auch was).
    Allzulang sollte es auch nicht dauern bis ich was bereitstellen werde, wie irgendwo schon erwähnt, Ausgabe an sich geht, OSD (mit u.a. der Einschränkung auf Video-Grösse) auch, Medienwiedergabe könnte noch etwas problematisch werden, aber das lass ich evtl. erstmal aussen vor.
    Es ist mittlerweile aber sehr wahrscheinlich, dass ich da auch etwas eigenständiges ala softdevice machen werde.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden