HD mit xineliboutput + vdr-sxfe - warum so CPU-intensiv?

  • Ich hab (noch) keine DVB-S2-Karte bei mir installiert, wollte aber mal testen ob ich HD-Material flüssigen wiedergeben kann.
    Als Hardware habe ich einen Athlon 64 X2 4200 auf einem Mainboard mit Geforce 6150 IGP, das Display hat eine Auflösung von 1366x768.


    Unter Windows kann ich damit 1080p-Trailer (QT und WMV) mit ~40% CPU-Last abspielen während unter vdr-sxfe + xineliboutput schon 720p-Trailer ruckeln (90-120% Wert für den vdr-sxfe Prozess in top).
    Als Treiber verwende ich die Nvida CS-Treiner 185.18.31, Kernel ist ein 2.6.28-686.


    Ist diese schlechte Performance normal oder geht das nur mir so?

  • Die 6150 ist leider nicht VDPAU-fähig.
    Ich frag mich halt, woher diese extreme Diskrepanz kommt zwischen Windows und Linux kommt und ob ich vielleicht etwas verkonfiguriert habe.
    In der Vergangenheit hatte ich auch schom mal mit XvMC für vdr-sxfe rumgespielt, was die 6150 kann, allerdings nur für MPEG-2 und eben nicht für H.264.

  • Der Windows Treiber verwendet Hardware Beschleunigung und der Linux Treiber erst seit VDPAU.

    VDR:
    Hardware: Thermaltake DH102, Zotac ION ITX-F-E, 2Gig Ram, TechnoTrend
    dual DVB-S2 6400, TechnoTrend Connect CT-3650,


    Software: EasyVDR 1.0

  • Mal mit dem mplayer testen, z.B. mit mplayer-plugin oder mmsv2 oder etc.
    tuts bei mir über mms um einiges besser als über xine, quasi Ruckelfrei mit GF7200 und 2,1GHz X2 BE2350 bei 720p
    Leichte beschleunigung ala xv gibts natürlich, aber der rest läuft über die cpu.

  • Zitat

    Original von rüsseltier
    Die 6150 ist leider nicht VDPAU-fähig.
    Ich frag mich halt, woher diese extreme Diskrepanz kommt zwischen Windows und Linux kommt und ob ich vielleicht etwas verkonfiguriert habe.
    In der Vergangenheit hatte ich auch schom mal mit XvMC für vdr-sxfe rumgespielt, was die 6150 kann, allerdings nur für MPEG-2 und eben nicht für H.264.


    rüsseltier


    Das Prinzip xineliboutput ist IMHO sehr CPU intensiv. Brauchst gar nicht so weit zu vergleichen, allein bei der Wiedergabe von SDTV via xineliboutput oder softdevice zeigt das xineliboutput min. das die doppelte CPU Last bei subjektiv schlechterer Bildqualität verursacht. Hatte ich hier schon mal angeschnitten. Leider habe ich keine Antwort darauf, noch eine anderweitig bekommen.


    Da sich die Bildqualität aber mit und aufgrund VDPAU massiv verbessert hat und das für HDTV z.Zt. der güldene Weg ist ....


    Kind regards
    hummingbird_de

    HowTo: APT pinning

    Einmal editiert, zuletzt von fnu ()

  • Jetzt wird es seltsam:
    Mit mplayer auf einem nackten X11 (ohne VDR/vdr-sxfe im Hintergrund) spielt die 1080p-Datei ruckfrei mit 40-60% Last ab. Die 720p-Datei begnügt sich sogar nur mit 20-30%.
    Kann mir das jemand erklären?
    Irgendwo muss Xine/vdr-sxfe da doch massiv sinnlos Rechenzeit verbraten, oder?


    Das Mplayer-Plugin kann ich leider nicht testen, das scheint nur zu funktionieren wenn die Ausgabe über eine FF-Karte läuft.

  • Zitat

    Original von hummingbird_de
    Das Prinzip xineliboutput ist IMHO sehr CPU intensiv.


    Ich könnte es nachvollziehen, dass die CPU-Last hochgeht wenn das Hauptmenü oder andere Menüelemente eingeblendet sind und damit rechenintensiv zuammengefügt werden müssen, aber bei der nackten Wiedergabe von HD-Dateien bzw. -Stream?
    Da müsste doch viel weniger Last da sein, oder?


    Testweise wolllte ich eben mal fbxine die Dateien abspielen lassen, das klappt aber überhaupt nicht ("Video port failed."). Kann man sonst irgendwie noch mit xine etwas per Kommandozeile abspielen lassen?

  • Zitat

    Originally posted by rüsseltier
    Ich frag mich halt, woher diese extreme Diskrepanz kommt zwischen Windows und Linux kommt und ob ich vielleicht etwas verkonfiguriert habe.


    poste doch bitte mal deine setup.conf, config_xineliboutput und xorg.conf

  • Zitat

    Original von sparkie
    poste doch bitte mal deine setup.conf,



    Zitat

    config_xineliboutput


    Hmm, gibt es bei mir nicht.


    Zitat

    und xorg.conf


    Ich hab mal nur das relevante rauskopiert:


    Wie ist das eigentlich bei vd-sxfe/xineliboutput?
    Läuft da permanent ein Prozess, der das VDR-Overlay mit dem Livebild verschmilzt? Dann würde es mich nicht wundern, dass auch ohne Menü ständig so viel Last da ist. Wenn das nur on-Demand (also wenn auch wirklich eine Menü oder die Kanalinfo zu sehen ist) laufen würde, dann bräuchte man doch gar nicht diese ganzen Verrenkungen mit VDPAU.

  • kann auf den ersten Blick keine Fehler in der Config sehen.


    Zitat

    Ich könnte es nachvollziehen, dass die CPU-Last hochgeht wenn das Hauptmenü oder andere Menüelemente eingeblendet sind und damit rechenintensiv zuammengefügt werden müssen, aber bei der nackten Wiedergabe von HD-Dateien bzw. -Stream?


    konfigurationsabhaengig kostet OSD EInblendung u.U. gar keine Rechenzeit, da sie hardwaremaessig ueberlagert wird.


    aber ist doch klar, dass bei Dekodierung von HD-Material ohne VDPAU die CPU-Last hochgeht?
    Wenn dann zudem die Erkennung 'use_progressive_frame_flag=1' wieder mal nicht klappt, da die Flags im Source-Material falsch gesetzt sind, hast du noch obendrein die CPU-intensiven Deinterlacer dabei.

  • Zitat

    Original von sparkie
    konfigurationsabhaengig kostet OSD EInblendung u.U. gar keine Rechenzeit, da sie hardwaremaessig ueberlagert wird.


    Sowie das Bild aussieht, ist es in SW hochskaliert und kein Hardware-Overlay. HW-Overlay gibt es AFAIK nur, wenn man z.B. xvmc als Ausgabedevice für vdr-sxfe angibt, was ich nicht tue, weil das Menu dann wesentlich schlechter (=grobpixeliger) ist.


    Zitat

    aber ist doch klar, dass bei Dekodierung von HD-Material ohne VDPAU die CPU-Last hochgeht?


    Um den Faktor 3-4 gegenüber Mplayer, der auch kein VDPAU zur Verfügung hat?
    Irgendwas muss da doch hochgradig ineffizient laufen.


    Zitat

    Wenn dann zudem die Erkennung 'use_progressive_frame_flag=1' wieder mal nicht klappt, da die Flags im Source-Material falsch gesetzt sind, hast du noch obendrein die CPU-intensiven Deinterlacer dabei.


    Hab es eben mal abgeschaltet, es macht keinen Unterschied.


    Ich denke es mir halt so:
    Wenn es möglich wäre, das effizienter hinzubekommen, wäre HD auch ohne vdpau möglich.

  • sparkie


    IMHO kannst Du da nichts optimieren, ich habe das selbst auf mehreren Maschinen mit SDTV im Vergleich zu softdevice nachvollziehen können.


    Erst letztens hier in einem anderen Thread, ein und die selbe Maschine stellte SDTV mit softdevice (XV) bei 50% CPU dar, während xineliboutput mit remote FE (XV) die Maschine bei 100% CPU quasi einfror. Dort hatte ich schon die Frage in den Raum gestellt, warum das so ist und ob diese Resourcen bei VDPAU evtl. auch so un-optimiert verwendet werden ...


    rüsseltier


    Zitat

    Original von rüsseltier
    Wenn es möglich wäre, das effizienter hinzubekommen, wäre HD auch ohne vdpau möglich.


    Definitiv nein! Evtl. noch CPU schonender, aber nicht ohne. Man benötigt für die aufwändige .h264 Decodierung, einen HW-unterstützten Algorithmus wie diesen.


    Kind regards
    hummingbird_de


    PS.: Mein Traum wäre ja der VDPAU Support in softdevice :whatever

    HowTo: APT pinning

  • Zitat

    Original von hummingbird_de


    Definitiv nein! Evtl. noch CPU schonender, aber nicht ohne. Man benötigt für die aufwändige .h264 Decodierung, einen HW-unterstützten Algorithmus wie diesen.


    Wieso nicht?
    Wenn mplayer beim Dekodieren von x.264 mit einem Viertel der Ressourcen auskommt, dann sollte doch auch vdr-sxfe in die nähe davon kommen können, zumindest wenn kein Menü eingeblendet ist.
    Klar kommt man mit VDPAU bei HD auf 5-10% Last was ich so gelesen habe, aber wenn es auch ohne VDPAU mit 20-30% CPU Last gehen würde, dann wäre das für nicht-VDPAU-fähige Systeme (z.B. auch ATI) eine bessere Lösung, als sich nur deswegen eine neue Grafikkarte reinzuhängen. Ich kann mir nicht vorstellen, dass das effizienter ist, als es die CPU machen zu lassen (ausser man hat einen VDPAU-fähigen IGP).

  • Zitat

    Original von rüsseltier
    Ich kann mir nicht vorstellen, dass das effizienter ist, als es die CPU machen zu lassen (ausser man hat einen VDPAU-fähigen IGP).


    Definitiv ist spezialisierte HW effizienter, oder hast Du unsere geliebten DXR3 & FF Karten schon vergessen?


    Für eine schöne YUV Ausgabe von SDTV benötigt man bis heute nicht mehr als eine DXR3 Karte mit Spezialkabel und einen passiv gekühlten Celeron333 oder PIII 500.


    Aber die Idee mit dem ffmpeg könnte man weiterverfolgen, da softdevice ffmpeg zum decodieren nutzt. Stellt sich die Frage ob softdevice mit einem DVB Stream in der Auflösung 1280x720 umgehen kann ...


    [EDIT]
    Bin mir fast sicher, das softdevice das könnte. Hatte es mal ausprobiert, also die HD Showcases der ÖR Sender noch über DVB-S kamen.
    [/EDIT]


    Kind regards
    hummingbird_de

    HowTo: APT pinning

    Einmal editiert, zuletzt von fnu ()

  • Zitat

    Original von hummingbird_de


    Definitiv ist spezialisierte HW effizienter, oder hast Du unsere geliebten DXR3 & FF Karten schon vergessen?


    Ja, sicher, aber bei 30% CPU-Last gegenüber 10% CPU-Last habe ich wieviel Watt Mehrverbrauch in der CPU? 5, 10 Watt?
    Und wieviel Watt säuft im Gegenzug eine separate Grafikkarte + Lüfter im System?


    Nochmal: wenn es in Software systemunabhängig (= nicht nur NV-Chipsätze) bei geringer Last machbar wäre, warum nicht?
    Momentan wird scheinbar ja extrem lahmer Code in vdr-sxfe/libxine mit Extra-Hardware-Einsatz (VDPAU) erschlagen.

  • Hmm, lass es mich mal diplomatisch formulieren, wenn ich könnte, würde ich versuchen es zu ändern. Da ich aber kein guter Programmierer bin, kann ich es nicht. Also muß ich mit dem leben was da ist und ich werde ja nun auch nicht gezwungen es zu verwenden.


    Eine blöde Situation, ich sehe was evtl. nicht gut läuft (und nicht erst seit gestern) kann aber nur Feedback geben, hoffen und bis zu etwaigen Veränderungen das Beste daraus machen.


    Kind regards
    hummingbird_de

    HowTo: APT pinning

  • Zitat

    Original von hummingbird_de
    Hmm, lass es mich mal diplomatisch formulieren, wenn ich könnte, würde ich versuchen es zu ändern.


    Dito. :o)


    Ich hab Petri Hintukainen mal gemailt.
    Er meint, dass es da wohl ein Problem geben muss, weil xineliboutput ebenso wie Mplayer auf die FFMPEG-Libs zur Dekodierung zurückgreift und daher ohne Menü etwa genausoviel CPU-Last haben sollte. Mal kucken.
    Das wäre natürlich toll, wenn das optimiert werden könnte (oder ein fieser Bug ist) und DVB-S2 dann auch normalen Systemen auch ohne VDPAU machbar wäre.

Jetzt mitmachen!

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