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