[00:47] nite [02:47] hmm libva is in main, yet playback apps dont support it in ubuntu where they do in debian [02:47] (libva in main and supported? wth) [02:50] vlc supports it [02:50] not my vlc [02:50] its not on the list [02:51] list? [02:52] mplayer is a thorny issue since gbeauchesne's patches eliminated vdpau support, but that problem may be fixed now. i will ask him. certainly vaapi and vdpau need to coexist, not be mutually exclusive [02:53] http://sarvatt.com/downloads/scrot.png [02:53] no, no [02:54] you're looking in the wrong place [02:54] enable gpu accel [02:54] there was just a bug where a libdrm update broke mplayer/vlc/et all on intel in debian but i couldn't reproduce because vaapi wasnt an option http://paste.ubuntu.com/766476/ too [02:54] oh [02:54] ? [02:54] whatever the deal is the options were all enabled by default in debian [02:54] hmm, where should I be looking, i dont see it [02:55] input & codecs [02:55] enable gpu accel [02:55] start vlc from a cli and you can actually see it using libva [02:55] just ticking that enabled vaapi output? [02:56] yes it did [02:56] you can make sure it's working by starting it from the cli [02:57] vlc doesn't do 100% gpu decoding, so cpu usage should be higher than with mplayer/vdpau [02:57] ok that did work, and its not crashing here, go figure [02:58] a libdrm update in debian but not ubuntu broke things? [02:59] yeah i didn't pull it in yet [02:59] try mplayer -vo vaapi -va vaapi file.mkv [02:59] its not busted in edgers though which is confusing me [02:59] i pasted my mplayer -vo help output up there, vaapi isnt an option [03:00] then it hasn't been patched [03:00] mplayer is a straight sync from debian [03:00] like i said the patches eliminated vdpau in favour of vaapi [03:00] and mplayer was busted in debian [03:01] uau thinks vaapi's presentation queue is inferior to vdpau [03:01] for technical reasons i don't understand [03:02] uau's mplayer2 is preferable to mplayer at this point imo [03:02] doesn't vaapi talk to vdpau now anyway so it doesn't matter? [03:02] btw, does vdpau work well on snb? [03:02] why would it? no vdpau drivers.. [03:03] the mesa vdpau crap is gallium intel doesnt do gallium [03:03] i thought there was one [03:03] oh, intel is using vaapi? [03:03] yeah [03:03] well then does vaapi work well? [03:03] installing mplayer2 to see [03:04] i have no clue [03:04] stopped caring when dedicated devices replaced all my media centers, boxee box ftw :) [03:05] popcornhour [03:05] in oneiric mplayer2 doesn't know what -vo vaapi is [03:05] no vaapi in mplayer2 either unless im being an idiot [03:06] mplayer2 package installs /usr/bin/mplayer and no vaapi listed in mplayer -vo help [03:06] yah i'm on oneiric [03:07] http://gitorious.org/vaapi/mplayer [03:07] there's the patches [03:07] i guess they haven't been applied [03:07] how do you know about this bug? [03:09] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651316 [03:09] Debian bug 651316 in libdrm-intel1 "libdrm-intel1: X.org crashes when I try to play a video" [Grave,Open] [03:09] been trying to reproduce that [03:09] it takes down x? [03:09] its already fixed in x-x-v-intel [03:09] yea [03:10] libdrm update broke libva and it was crashing X, but i couldn't reproduce cus i couldn't use libva easily but it was used by default in debian [03:13] your libva stuff hasn't made it to debian yet [03:14] i'm working with siretart and others on it [03:14] but we have to make a new intel va driver package from my barebones beginning and nobody has stepped forward to assist [03:15] but i did contribute to the packaging of 1.0.15 [03:15] yeah i saw it in debian-multimedia, i'm using your stuff now [03:16] i just emailed gwenole with some questions about the mplayer patches so i will get back to you when he gets back to me [03:17] i didn't know vaapi had been left out of oneiric [03:17] i mean mplayer/vaapi [03:21] if you have to check the box in the input codec section doesn't that imply its ffmpeg/libav where it needs to be enabled? [03:21] i didn't check to see if we're behind there [03:22] well thats vlc [03:23] yeah i'm slow libva really is used there when you check it [03:26] there's vaapi code in libav, and anything that uses libav can use it. so by checking that box you're telling vlc to use it [03:27] mplayer still has to be patched, and totem could use it but for gstreamer getting in the way [03:27] gstreamer would have to be patched and them totem could use vaapi too [03:27] its still presenting the final stream via whatever output you picked and vaapi isn't an option in vlc, mixing in subtitles before presenting it to xv or gl. i guess mplayer does it different in -vo vaapi is an option [03:27] i don't know. i can ask gwenole [03:28] yeah one of the intel guys asked me to put libgstvaapi in edgers for that [03:28] the fluendo guys have a vaapi lib but you have to pay [03:29] if the presentation queue is xv or gl that would be inferior to vdpau and probably vaapi too [03:30] of course in mplayer you can use libav-mt with vdpau as the driver if you're on a multicore cpu [03:30] that seems to be how it works in vlc if you pick it in input codecs and are still using xv or gl to present it, thats why i was confused about where to enable it [03:30] maybe it uses the vaapi queue without telling the user explicitly === dzan|away is now known as dzan === yofel_ is now known as yofel === dzan is now known as dzan|away