VDPAU wird sporadisch nicht genutzt bei HD-TV via Streamdev-Schnittstelle

  • Hallo!


    Mir ist durch einen Zufall aufgefallen, dass beim TV-Sehen über Xbmc-PVR nicht immer VDPAU zum Rendern der Videodaten verwendet wird.


    Zu passieren scheint es völlig willkürlich --> Beim Betrachten der Daten zum gerade aktiven Stream wird das normale h264-Modul angeführt anstatt dem mit vdpau im Namen. Die CPU-Auslastung ist zugleich entsprechend hoch anstatt gegen 0 zu gehen wie sonst.


    Stoppe ich die Wiedergabe und starte ich den selben Kanal erneut wird zumeist wieder VDPAU verwendet.


    Getestet habe ich es nur bei den HD-Kanälen (also die, die h264-codiert senden), inwiefern mpeg2-Kanäle davon betroffen sind, bzw. ob hierfür überhaupt VDPAU gedacht ist, weiß ich nicht.


    Ist dieses Problem bekannt oder kann man selbst dagegen etwas tun?


    Ich habe hier noch die entsprechenden Einträge aus meiner xbmc.log bei Start einer TV-Wiedergabe ohne Verwendung von VDPAU (die scheinen mir von denen der hier bereits bekannten VDPAU-Probleme abzuweichen)


    Derzeit ist der Wegfall von VDPAU nicht wirklich ein Problem für mich, da mein Rechner HD-Content auch mittels Software ohne merkliche Probleme rendern kann.
    Ich spiele aber mit den Gedanken meinen aktuellen HTPC irgendwann zu "verwerten" und auf weniger hungrige Hardware mit einer Atom/ION Kombination zu wechseln. Ich nehme dabei an, dass ein Atom 330 durchaus Probleme beim Abspielen der HD-TV-Kanäle hätte ...

  • Ich nehme an, dass Du momentan mein aktuelles XBMC-Paket xbmc - pvr-testing-18~hepi-karmic26177+9 verwendest? Wenn das so ist, warte mal noch ein paar Tage ab, bis ich ein neues, sauberes Paket mit pingpongs aktuellen Merges aus dem trunk gemacht habe und teste dann nochmal, ob das Problem noch auftritt.


    Unterdessen kannst Du Dir mal einen aktuellen Trunk-Build (also kein pvr-testing2) besorgen und testen, ob es dort auch auftritt. Wenn ja, müsstest Du wohl am besten ein Ticket im XBMC-Trac aufmachen, da dann der Fehler nicht bei pingpong liegt.


    Gruß
    hepi

  • Weil es mir gerade eingefallen ist:


    Ich möchte den Vorschlag einbringen bei Erstellung eines neuen Xbmc-Paket die jeweilige Vorgängerversion auch noch in deinem Repository zu belassen.


    Sollten bei einem Update Regressions auftreten (zB Wegfall der VDPAU-Unterstützung, wie es ja der Fall war) könnte man so mit der Paketverwaltung einfach wieder auf die vorherige Version downgraden.


    Man bräuche sich so nur zurückzulehnen und abzuwarten, da man ohnehin wieder auf die alte Version zurückgestiegen ist.


    Beim VDPAU-Problem vor rund 2 Wochen ist dies nicht gegangen, wäre aber sehr praktisch gewesen ...

  • Zitat

    Original von löwe
    Ich möchte den Vorschlag einbringen bei Erstellung eines neuen Xbmc-Paket die jeweilige Vorgängerversion auch noch in deinem Repository zu belassen.


    Die Vorgängerversion ist normal noch zwei-drei Tage im Repository, (und kann per apt-get install mit Angabe der Versionsnummer installiert werden), dann wird sie automtatisch gelöscht, außer, ich baue an einem Tag mehrere Pakete. Im Archiv finden sich auch noch viele ältere Pakete zum manuellen Download und Installation per dpkg -i. Links dazu gibt's im anderen Thread.


    Gruß
    hepi

  • Der Kommentar im Ticket heisst soviel wie "fixing impossible?"


    problem is that the demuxer does not provide the correct dimensions (it's set to 0x0). fixing this would involve opening the sw codec to read the dimensions, then reopen using vdpau when we know the dimensions.


    Früher war das Problem nicht vorhanden...

    VDR im Keller:
    AMD Athlon II X2 220 2,8 GHz / 2GB RAM / 2x TechnoTrend 1600 DVB-S2 / Debian 6.0 / VDR 1.7.14 (+vdr-streamdev +iStreamdev + VDR-Admin-AM + Sky Komplett und HD+ Abo an /dev/ttySx )
    4x 2 TB als Raid 5 + 2x 8 GB SLC IDE SSD als Raid 1


    VDR Clienten 2x XBMC:
    Schlafzimmer: Revo an 23" LCD, Karmic + XBMC 10.0+pvr
    Wohnzimmer: HTPC an 40" LCD, Karmic + XBMC 10.0+pvr, Athlon X2 64 5400, BlueRay, nVidia 9400 GT, BlueRay unter Win7)
    2x iPhone 4 (iStreamdev)

  • So weit ich das verstehe dürfte das zum Glück nicht der Fall sein :D


    Aus dem Kommentar:


    dzt. Ablauf:
    1. Schicken des Video-Streams durch den Demuxer
    2. Demuxer ermittelt Dimensionen
    3. VDPAU wird mit den Demensionen aus dem Demuxer initislisiert


    Das Problem ist nun, dass der Demuxer statt den Dimensionen manchmal gar nichts liefert (ist mit 0x0 beschrieben im Kommentar) --> VDPAU stürzt deshalb beim Initialisieren ab --> Xbmc führt ein Fallback auf Software-Rendering aus, was ja bekanntlicherweise immer klappen sollte


    Was im Kommentar vorgeschlagen wird, ist Folgendes:
    1. Statt VDPAU Starten des Software-Renderers für den Video-Stream
    2. Gleich zu Beginn ein Abwürgen des Software-Renderers, dafür aber von ihm die Dimensionen auslesen (der SW-Renderer erkennt die Dimensionen ja richtig, sonst könnte er diese Videostreams nicht wiedergeben, und er kann sie ja offensichtlich abspielen)
    3. Mit den vom SW-Renderer ausgelesenen Dimensionen die Initialisierung von VDPAU durchführen
    4. Den Stream mit VDPAU abspielen.



    Ich würde, nachdem im Bug-Kommentar von spiff ja alles Notwendige schön aufgeschlüsselt ist, noch weiter gehen:


    1. Schicken des Video-Streams durch den Demuxer
    2. Demuxer ermittelt Dimensionen
    3. Wenn die Dimesionen des Demuxers 0x0 sind, dann Start des SW-Renderes, gleich später Abwürgen dessen und die Dimeinsionen darauf merken
    4. Initialisierung von VDPAU mit den zuvor gewonnenen Dimensionen (unabhängig woher diese stammen --> Demuxer oder SW-Renderer)
    5. Wiedergabe des Streams mit VDPAU



    Ein Bugfix ist schon möglich, und mit meiner 5er-Grupper hier dürfte sich die Performance damit auch nur dann verschlechtern, wenn VDPAU jetzt versagt; bei der normalen Wiedergabe sollte damit alles gleich bleiben, da dafür auf den SW-Decoder verzichtet wird. Ist ja auch nicht notwendig, denn solche Streams funktionieren jetzt ja auch schon ohne ihn.

  • Ist leider in der aktuellen Revision (hepi) immer noch aktuell dieses Problem.

    VDR im Keller:
    AMD Athlon II X2 220 2,8 GHz / 2GB RAM / 2x TechnoTrend 1600 DVB-S2 / Debian 6.0 / VDR 1.7.14 (+vdr-streamdev +iStreamdev + VDR-Admin-AM + Sky Komplett und HD+ Abo an /dev/ttySx )
    4x 2 TB als Raid 5 + 2x 8 GB SLC IDE SSD als Raid 1


    VDR Clienten 2x XBMC:
    Schlafzimmer: Revo an 23" LCD, Karmic + XBMC 10.0+pvr
    Wohnzimmer: HTPC an 40" LCD, Karmic + XBMC 10.0+pvr, Athlon X2 64 5400, BlueRay, nVidia 9400 GT, BlueRay unter Win7)
    2x iPhone 4 (iStreamdev)

  • Hab es grad mit pvr-testing-24~hepi-karmic27740+2 geprüft. VDPAU wird nun wunderbar genutzt :)

    VDR im Keller:
    AMD Athlon II X2 220 2,8 GHz / 2GB RAM / 2x TechnoTrend 1600 DVB-S2 / Debian 6.0 / VDR 1.7.14 (+vdr-streamdev +iStreamdev + VDR-Admin-AM + Sky Komplett und HD+ Abo an /dev/ttySx )
    4x 2 TB als Raid 5 + 2x 8 GB SLC IDE SSD als Raid 1


    VDR Clienten 2x XBMC:
    Schlafzimmer: Revo an 23" LCD, Karmic + XBMC 10.0+pvr
    Wohnzimmer: HTPC an 40" LCD, Karmic + XBMC 10.0+pvr, Athlon X2 64 5400, BlueRay, nVidia 9400 GT, BlueRay unter Win7)
    2x iPhone 4 (iStreamdev)

Jetzt mitmachen!

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