Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

XBMC gaat AMD's XvBA-technologie ondersteunen

De aankomende versie van XBMC gaat de XvBA-technologie van AMD ondersteunen. Hierdoor is het mogelijk om video's hardwarematig te versnellen op AMD Radeon-gpu's en Fusion-apu's. Onder andere films moeten zo soepeler afspelen.

De XvBA-technologie van AMD is tot nu een nog relatief weinig benut door mediaspelersoftware, maar de aankomende XBMC-versie, 'Eden' geheten, belooft het te gaan ondersteunen. Hierdoor kunnen bezitters van een recente Radeon-videokaart of een systeem met een Fusion-apu profiteren van hardwarematig versnelde video, zo schrijft Phoronix. Met name videobestanden die gecomprimeerd zijn met de h.264- of vc-1-codec zouden profiteren. Ondersteuning voor mpeg2, met name te vinden in dvd-bestanden, is echter nog niet aanwezig.

Om XvBA te kunnen gebruiken binnen XBMC, benut de opensource-mediaspelersoftware de inmiddels vrijgegeven codebase van AMD. Deze is verpakt in de xvba-va-driver. Om op Linux-systemen XvBA te kunnen gebruiken, dient AMD's propriëtaire fglrx-driver met versienummer 11.11 of hoger geïnstalleerd te worden.

Door Dimitri Reijerman

Redacteur

15-12-2011 • 19:12

51 Linkedin Google+

Submitter: Tweetyfrk

Reacties (51)

Wijzig sortering
Er zitten een paar fouten in het verhaal. De ondersteuning komt niet in Eden maar in Frodo. Er is momenteel een feature freeze, dus we zullen nog even moeten wachten op ondersteuning.

Verder werkt versnelling momenteel al wel voor AMD maar via een Wrapper die eerst de VAAPI aanspreekt. De calls worden vervolgens vertaald naar XvBA. De directe XvBA ondersteuning is nu net in ontwikkeling. Meer informatie en links naar waar testpackages gedownload kunnen worden op http://www.xbmcfreak.nl/e...t-xvba-interface-support/

[Reactie gewijzigd door Erhnam op 15 december 2011 19:52]

Inderdaad. Tevens is er nog geen goede afhandeling van foute input: wanneer er een incorrecte stream of een stream met "vreemde" parameters wordt ingevoerd, zal XBMC crashen. Onder andere hierdoor is XvBA met name als het gebruikt wordt i.c.m. PVR nog verre van stabiel, en PVR is nu juist een van de plaatsen waar ondersteuning van XvBA nuttig is (bijv. voor deinterlacing van 1080i).

De auteur van het artikel op phoronix.com wekt tevens de suggestie dat degene die de e-mail stuurde een developer is van Team XBMC; dit is niet het geval. De e-mail (en ook het verhaal hier) is naar mijn mening dan ook veel te voorbarig:
- deinterlacing werkt nog niet helemaal: het crasht nog vaak en geeft af en toe flikkerend of geen beeld, of heeft een verkeerd pallet in gebruik (dus vreemde kleuren). efficiente deinterlacing is een van de belangrijkste toevoegingen van XvBA, en dit werkt dus nog niet helemaal.
- de patches die XvBA support toevoegen aan de PVR branch zijn 3 dagen oud, en de auteur van de e-mail zegt dat er al een xbmc-pvr build is. als maintainer van XBMC's PVR branch wil ik hier aan toevoegen dat dit test builds zijn en dat deze nog lang niet stabiel zijn!
- er is nog een MPEG2 support
- of en wanneer sommige missende onderdelen of bugs kunnen worden opgelost is afhankelijk van de medewerking van ATI. er is wel al contact met ATI hierover.
- zoals Erhnam al zei is dit pas net onder ontwikkeling, en het zal niet in de komende release, maar de daarop volgende (Frodo) worden opgenomen.
Het is wellicht de moeite van het vermelden waard dat dit al kon dmv de VA-API abstraction layer. Deze laag ligt/lag bovenop VDPAU van Nvidia en XvBA van AMD. Het voordeel daarvan is dat de client software, in dit geval XBMC, alleen VA-API hoeft te ondersteunen en dat die layer dan de vertaling naar VDPAU/XvBA doet. Dit is vergelijkbaar met de DxVA layer onder Windows.

Wat er nu gebeurt is dat er direct gebruik wordt gemaakt van XvBA, net als op dit moment de VDPAU layer direct wordt aangesproken in het geval van Nvidia. Het voordeel van de directe methode is dat het makkelijker te installeren is en wellicht ook stabieler is.

Architectureel gezien is het via VA-API dus handiger, maar dit is sneller en makkelijker.
Ook toevallig, afgelopen weekend net debian wheezy geinstalleerd met xbmc en XvBA drivers gebruikt werkt als een tiet, met geluid over HDMI.
wheezy is handig zodat je de laatste kernel en drivers hebt, echter let wel op: tip.
als je deze installeert, dan moet de radeon firmware ook geladen worden anders zie je niets.
wat ik gedaan heb was kaal wheezy installeren met ssh server.
na de reboot zie je niets, even inloggen met ssh, en apt-get install firmware-linux-nonfree firmware-linux , reboot en je hebt weer beeld.

( en gebruik niet de netinstaller van wheezy dat gaat (nog) niet werken, mist kernel drivers )
Openelec is een project om een volledig OS op basis van XBMC te maken. Op een Linux basis zetten ze XBMC en de Linux installatie is volledig geoptimaliseerd voor die ene taak. Je kunt het installeren op een USB stick en vanaf daar draaien. XBMC zelf is dus gewoon een programma binnen je Linux installatie, Openelec is een totaalpakket voor een media center oplossing.

Doordat Openelec XBMC gebruikt doet en werkt het dus ook hetzelfde. Wat dus ook betekend dat XBMC al VAAPI ondersteunde, zoals hierboven aangegeven. VA-API heeft een backend voor XvBA en via deze weg kon XBMC dus al video decoding op de GPU doen. Met deze toevoeging in XBMC wordt VA-API echter buitenspel gezet. En wat ik ervan lees is dat geen slecht idee. XvBA lijkt op zichzelf al "rot" te zijn doordat AMD het niet altijd even goed heeft aangepakt. Daarnaast lijk het met het VA-API backend niet veel beter te zijn, aangezien de ontwikkeling daarvan ook al tijde stil lijkt te liggen.
Openelec maakte juist deze week bekend dat het ook XVBA support krijgt/heeft.

Zie http://openelec.tv/news/i...sion-project-xvba-support

Openelec werkte trouwens al maanden echt super op mijn E350 HTPC.
OS. Wat in het verhaaltje helemaal mist is dat XvBA voor Linux (en waarschijnlijk andere *nix varianten) is. Google verteld mij zo snel dat UVD voor Windows is. Wat ze dus al jaren op Windows hebben met UVD via een DirectX API, hebben ze nu ook op Linux voor de Xv API.
Als ik zo snel naar het bronartikel op Phoronix kijkt lijkt het erop dat XvBA juist van AMD zelf is, en dat het al lang bestaat, maar een enorme puinhoop was. Een constant veranderende API etc. Vervolgens is er een VA-API (Xorgs Video Acceleration API) backend toegevoegd zodat hun "brakke" XvBA in ieder geval ook aangesproken kon worden via de gestandaardiseerde VA-API (wat XBMC dus al kon). Toen is op een gegeven moment de ondersteuning voor VA-API ook weer weg gevallen. En hoe ik het lees hebben ze een tijd terug in een soort "wanhoopspoging" maar alles van XvBA "op straat gegooid" in de hoop dat anderen ermee verder zouden gaan. Waarna XBMC het nu uiteindelijk (als eerste) heeft opgepakt om het maar rechtstreeks te ondersteunen.

Daarom ben ik het ook eens met NightFox89's reactie. NVidia heeft dit allemaal wel goed geregeld. Ja, ze bepalen alles zelf aan VDPAU, maar het werkt wel, en wordt goed ondersteund. NVidia lost regelmatig bugs erin op en voegt nieuwe dingen toe, en er zijn voldoende applicaties die (rechtstreeks) VDPAU gebruiken voor het decoden van video. Volgensmij was VDPAU ook de eerste API onder Linux voor het decoden van video onder Linux. Daarna is VA-API pas ontstaan en een VA-API backend voor VDPAU is er zelfs pas sinds kort. Maar dit VA-API backend was eigenlijk ook niet (direct) nodig, want VDPAU was eigenlijk al de enige op dit gebied en daarmee dus ook het meest geïmplementeerd. Het VA-API backend is dan ook meer "vooruitdenken" dat het voor video applicaties makkelijker is om video decoding via alle soorten videokaarten te doen dan om ervoor te zorgen dat video decoding uberhaupt gebruikt wordt op hun eigen videokaarten.

[Reactie gewijzigd door RobertMe op 15 december 2011 19:53]

Op dit item kan niet meer gereageerd worden.


OnePlus 7 Pro (8GB intern) Nintendo Switch Lite LG OLED C9 Google Pixel 3a XL FIFA 19 Samsung Galaxy S10 Sony PlayStation 5 Smartphones

'14 '15 '16 '17 2018

Tweakers vormt samen met Tweakers Elect, Hardware Info, Autotrack, Nationale Vacaturebank, Intermediair en Independer de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2019 Hosting door True