=== JanC_ is now known as JanC === JanC is now known as Guest64473 === JanC_ is now known as JanC [19:31] bschaefer: https://github.com/fritsch/xbmc/commit/372a3ff88360ded6fb09692621cbfe88d34aa9f0 works for me quite fine on X11 [19:32] that's basically your work with some kodi glue and proper closing of the handle [19:32] that will really make VAAPI X11 unaware which is really great [19:33] thanks very much for that [19:33] :) yeah was reading the code [19:33] and *all* the direct calls for the x11 display it self was only used to get the va display [19:34] jep [19:34] "historic reasons" [19:34] yeah it happens :) [19:34] we use glx via vaPutSurface before [19:34] used [19:34] oo yeah that makes sense [19:34] which was _the only_ way [19:34] to use vaapi for a very long time [19:34] fritsch, here is a cheap RAII for the fd http://paste.ubuntu.com/23467327/ [19:34] (since i wasnt cleaning it up before) [19:34] o i see, well seems like DRM/EGL is a very nice cross display server [19:35] * bschaefer was going to look into making a better look up of /dev/dri/renderD [19:35] and to check for kernel >= 3.15 [19:35] there is a better one [19:35] let me find it out - I just "patched it together" for a wayland packager [19:36] o sweet :) [19:36] i was just reading its somewhere between 128 < 128 + 64 [19:37] fritsch, also the other thing i wanted to ask: CSingleLock lock(g_graphicsContext); [19:37] was that just needed to get the X11 display? [19:37] the problem here is [19:37] * bschaefer didnt dig around to much about the thread saftey [19:37] that rendering in that does only work from thread 1 [19:37] so whenever you access the display stuff [19:37] you need to make sure to use a more or less global lock :-( [19:37] which DRM will also solve for us [19:37] in that regard [19:38] i see, but there was no g_Windowing usage there before? [19:38] it just did a XOpenDisplay() vs a g_Windowing.GetDisplay(); [19:39] or you ment anytime you access the m_X11Display [19:39] you'll need to lock, that makes sense [19:40] fritsch, also the check of the ret of vaInit was only needed because i wasnt checking the FD (was getting a -1 on KMS/mir) [19:41] looking again [19:41] it was used from decoder thread [19:41] yeah, please pick what you need from that commit [19:41] it's yours :-) [19:41] not mine [19:41] :) [19:41] i just fixed it up a bit [19:42] yeah, anyone can take it :) [19:42] concerning the RAII - I think explicit close is fine [19:42] we have the destroy context anyways [19:42] so, something explicit is done never the less [19:42] yeah thats fine, i was checking when i manually hit exit it wasnt hitting the dtor anyway (not sure why) [19:42] * bschaefer assumes someone kills the thread in an unkind way :) [19:42] but do it how you prefer it, you know what you are doing :-) [19:43] * bschaefer spend yesterday just reading about drm/vaapi soo still figuring things out [19:43] you exactly hit the 4 points that needed adjustment [19:43] but yeah ill attempt to clean it up and would most likely be better in a different branch [19:43] so all fine [19:43] jep [19:43] (as this branch would also affect x11 less confined) [19:44] This change can also be PRd separately [19:44] yeah i agree [19:44] then we can discuss it and you can base your other MIR work on that then [19:44] * bschaefer should figure out git a bit more [19:44] sounds good! [19:45] what kernel version has ubuntu 14.04? [19:45] 3.13 right? iirc? [19:45] dang let me check im always way to far on the ubuntu version ... on yakkety atm [19:45] 14.04.4 should have a far newer one [19:45] i have zero issues dropping support for any kernel < 4.0 anyways [19:46] as we require vaapi 0.34 anyways [19:46] well then that makes things easier :) [19:46] which only 16.04 or later ship (of the supported ones) [19:46] it's intel gpus - things were pretty rough back at 3.13 [19:46] looks like 3.16 [19:46] nope [19:46] that can't be :-) [19:46] * bschaefer checks the actual [19:46] source list [19:47] http://packages.ubuntu.com/trusty/linux-image-generic [19:47] 3.13 [19:47] let's see what the debian stable guys are doing [19:47] yeah there we go [19:48] 3.16 [19:48] no problem - just write a comment above it [19:48] and fine [19:48] sounds good, sounds like if you dont have vaapi 0.36 you disable it anyway [19:48] jep [19:49] cool, ill try doing a branch directly from xbmc vs fork [19:49] it should all run on 16.04 (concerning vaapi) [19:49] what do you mean by that? :-) [19:49] I'd just fork kodi once to your repo, that you did [19:49] now create a seperate branch: vaapi-dropx11-dependency [19:49] well dont think i can fork again... i know bzr but not git very well :) [19:49] ooo [19:49] from my fork dang... well ive been pusing to master in my fork [19:49] you already forked on github :-) [19:50] by clicking fork [19:50] right, then i didnt branch [19:50] in my fork haha [19:50] jep, you dev on your master [19:50] not a problem [19:50] stash everything or commit it locally [19:50] then add xbmc-upstream as remote, by doing [19:50] hmm how do i go back to xbmc master then branch from that? So i can avoid the mir changes? [19:50] git remote add xbmc-upstream https://github.com/xbmc/xbmc.git [19:50] since the vaapi stuff is differnet [19:51] * bschaefer will just have to read up on git [19:51] i just tell you [19:51] now do in your master: git commit -m "Squash me later, clean me up" -a [19:51] followed by: [19:51] git fetch xbmc-upstream [19:51] git checkout -b vaapi-drop-x11 xbmc-upstream/master [19:51] now you are on a vanilla new branch of kodi's master [19:51] oo that make sense [19:51] cool, thanks! [19:52] now either cherry-pick the commit you have in your master [19:52] by doing: git log master [19:52] finding the id [19:52] and doing: git cherry-pick id [19:52] that will apply just that commit on top [19:52] you can also add me as remote [19:52] o so i can pick from your commit [19:52] vs commit this [19:52] git remote add fritsch https://github.com/fritsch/xbmc.git [19:52] git fetch fritsch [19:53] git cherry-pick b044a9ff578d3fddb4a717e266d5e6f8b32bb678 [19:53] that gets you my commit I showed you [19:53] now do your changes, commit them [19:53] git commit -m "squash me" -a [19:53] now comes the git magic after you are finished with everything: [19:53] git fetch xbmc-upstream [19:53] git rebase -i xbmc-upstream/master [19:54] now squash the squash commit in the first one (writing squash in front of it instead of pick) [19:54] that happens on the rebase? [19:54] afterwards: git push -f origin vaapi-drop-x11 [19:54] on the rebase it uses the xbmc-upstream/master branch [19:54] as a given base [19:54] and tries to apply your commits on top of it [19:54] to *base* the changes against (something i wish bzr had) [19:54] you can see them (-i <- interactive) [19:55] and either pick them, or squash them [19:55] o cool, ill be using that [19:55] pick 1234 [19:55] squash 4567 [19:55] fritsch, from there do a pull request from that branch? [19:55] that will squash 4567 into 1234 [19:55] jep exactly [19:55] sweet [19:55] you should never rebase if you are the upstream [19:55] as rebasing means: loosing history [19:55] * bschaefer now knows git until something goes wrong horribly :) [19:55] :-) [19:55] yeah, just ping me - I can help you [19:56] cool, and thanks again! [19:56] oki, so let's as next step try to get that DRM PR out to us [19:56] i hope I convince everyone to branch in a very near future [19:56] do the PR now before clean up? [19:56] (for at lease conversation) [19:56] nope, after you are finished with everything [19:57] o ok sounds good [19:57] as you like it [19:57] yeah [19:57] then we can discuss on the final commit [19:57] concerning printf and kodi [19:57] * bschaefer likes printf [19:57] for kodi we use CLog and its static method Log [19:57] there is LOGNOTICE, LOGDEBUG, LOGERROR [19:57] i tried looking for this log before... [19:57] notice spams everything, LOGDEBUG only when debug logging is enabled [19:57] ERROR makes it red in the log [19:57] hehe [19:58] is it an env var? [19:58] nope [19:58] or compile time? [19:58] you include it [19:58] #include "utils/log.h" [19:58] i mean umm how do i read these logs? [19:58] all that stuff lands in ~/.kodi/temp/kodi.log [19:58] tail -f ~/.kodi/temp/kodi.log [19:58] o ok thats where i was missing [19:59] fritsch, yeah i usually use printf for my own debugging to stdout/err but usually switch to loggers :) [19:59] * bschaefer will attempt to just use the logger [20:00] For DIVX: Player Settings (Expert Hierarchy) -> Enable Mpeg4 [20:00] we have it disabled by default. As you know: in the times of divx and mpeg-4 [20:00] the standard was not so standard as h264 was [20:00] o dang, yeah i can imagine [20:00] hehe [20:02] oki, for the DRM change I think it won't make it into v17 - as it is a majore change and we are near to RC [20:02] yeah i agree (it has possible problems not tested out) [20:02] but if the code is written and ubuntu will ship mir + kodi [20:02] you can easily pick your "upstream" commit [20:02] into your package as upstream backport patch [20:02] yeah i can also push a pathc [20:02] yeah [20:02] * bschaefer was my plan :) [20:03] that's why it's brilliant if we get it upstream [20:03] if it wasnt part of the release [20:03] we often need to cope with the other way round :-( [20:03] * bschaefer prefers upstream == less patches [20:03] distros patch and patch [20:03] yeah [20:03] and we don't see the patches - and more severe - cannot tell what is wrong [20:03] gets very crazy trying to debug someones binary when they have all these patches [20:03] yeah! [20:03] if you can make the first mir release with a fully mir aware kodi + hw accel [20:03] people will realize something: it's easy to use mir [20:04] and it just works [20:04] at the end ubuntu is aimed at the desktop [20:04] not at the frickler, that is hacking everything together [20:04] so out of the box experience is the most important for such a goal [20:04] yup, soon *hopefully* people will realize they wont even notice what display server they are running [20:04] that's the goal, exactly [20:04] yup :) [20:05] perhaps there is even a "better way" of surface sharing without egl [20:05] with just drm [20:05] i know there is, but zero copy rendering is not just about copying [20:05] but yeah, displaying it directly [20:05] current limitation with vaapi is, that there is no way to transfer yuv420p10 [20:05] via egl / mesa [20:06] means: hevc-10 decoded content we can currently not display [20:06] (won't work on your laptop anyways) [20:06] need to wait for the T470 [20:06] o so its planned but not released? [20:06] but we are working on that with the mesa guys [20:06] very nice! [20:06] i have a poc already that decodes and shows what is missing for the render part [20:07] basically we miss the R16 G16 and RG16 transfer format [20:07] also, to really see the difference between a hw accel vs software for the video... [20:07] should i just stress my system? [20:07] * bschaefer cant really tell when software seems to render fine [20:07] i assume the embedded devices will be a big difference [20:08] https://github.com/fritsch/xbmc/blob/372a3ff88360ded6fb09692621cbfe88d34aa9f0/xbmc/cores/VideoPlayer/DVDCodecs/Video/VAAPI.cpp#L1238 <- see [20:08] you can do: kodi-send -a PlayerDebug [20:08] there you see render skips and render drops [20:08] if you don't get any skips [20:08] all fine [20:08] ooo very good to know [20:08] if you want to test mir's throughput [20:09] there is a 3840x2160p60 <- 60 progressive frames [20:09] of a h264 big buck bunny [20:09] that's a good throughput test [20:09] o geez, yeah that sounds like a good test [20:09] * bschaefer goes to download [20:09] as you run windowed, make sure to set the scaling to bilinear [20:09] your broadwell (T450) won't be fast enough to do it with lanczos3 [20:10] fritsch, well the screenshots i usually show is in the X11 platform (ie. Mir on X) [20:10] which is not great for throughput testing [20:10] since theres the added X11 layer [20:10] * bschaefer will test on the metal for that in KMS which will be fullscreen [20:10] you can press enter while playback [20:11] go to the video settings comming up [20:11] and choose: Deinterlace-Method: VAAPI-MCDI [20:11] and Scaling-Method: Bilinear [20:11] and do: save for all videos [20:11] normally we prefer lanczos3 (quality of course) [20:11] but it makes no sense to upscale 1080p to 1080 display with a lanczso scaler [20:11] :-) as nothing is scaled [20:12] hmm i only see VAAPI-Bob, VAAPI-MotionAdaptive [20:12] and motion comp [20:12] jep [20:12] mcdi <- motion compensation deinterlacing [20:12] the "translation" guys :-) [20:12] had fun [20:12] http://forum.kodi.tv/showthread.php?tid=231955 <- here is a bit of a read up why vaapi is as it is now [20:13] o cool im trying to read up a bit more on this whole thing [20:13] and also some settings - but "slow" :-) too much information currently [20:13] don't stress yourself, please - I am a bit in ahurry, that's why I post so much information [20:13] hehe [20:13] o no worries :) [20:13] i can always re-read the logs (which i usually end up doing to double check things) [20:14] oki, then I wish you good luck on the rest of the way to a working mir + vaapi [20:14] i think if you have some nice screenshots up and running [20:14] thanks, and thanks again for all the info! [20:14] the "linux bild zeitung" <- german for news paper stuff [20:14] will make something about it [20:14] phoronix.com [20:15] yeah ill make sure to get some screen shots of mir + x11 as well [20:15] to show both still working [20:15] not for me - if you want some positive publicity about "how easy it is" to support mir [20:15] then www.phoronix.com is a good thing ... (only for that ;-)) [20:15] true, depends on how its spinned :) [20:15] we sometimes ask them to publish things whenever hw vendors don't make good drivers [20:16] there was a "fglrx time" [20:16] in shorT: their driver sucked, their xvba sucked, we made it public. amd oss devs implemented vdpau with us [20:16] we dropped fglrx completely [20:16] :) [20:16] tadaaa :-) dead of fglrx in linux world for any video decoding stuff [20:17] and since then we still work with the amd oss devs together, especially when we plan new stuff [20:17] wayland support, egal buffer sharing [20:17] and so on [20:17] nice! That helps a lot i can imagine! [20:17] oki - afk now :-) good luck with all the stuff [20:17] and do not hessitate to ping me [20:17] thanks! (only about noon here) [20:17] or send me an email [20:17] or github [20:17] whatever you prefer [20:17] cool, sounds good [20:25] bschaefer: PlayerProcessInfo -> just press "o" [20:25] (so, now I am really gone) [20:25] but this does not show PlayerDebug info [20:25] ill hvae to use that debug command from above i assume? [20:26] * bschaefer can dig around [20:34] or map it to another key, e.g. ctl-o [20:36] good idea