| === JanC_ is now known as JanC | ||
| === JanC is now known as Guest64473 | ||
| === JanC_ is now known as JanC | ||
| fritsch | bschaefer: https://github.com/fritsch/xbmc/commit/372a3ff88360ded6fb09692621cbfe88d34aa9f0 works for me quite fine on X11 | 19:31 |
|---|---|---|
| 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:32 |
| 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:33 |
| 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:34 |
| * 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:35 |
| bschaefer | o sweet :) | 19:36 |
| bschaefer | i was just reading its somewhere between 128 < 128 + 64 | 19:36 |
| 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:37 |
| 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:38 |
| bschaefer | or you ment anytime you access the m_X11Display | 19:39 |
| bschaefer | you'll need to lock, that makes sense | 19:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| * 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| * 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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 | 19:59 | |
| 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:00 |
| 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:02 | |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:25 |
| * bschaefer can dig around | 20:26 | |
| fritsch | or map it to another key, e.g. ctl-o | 20:34 |
| bschaefer | good idea | 20:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!