| === chihchun_afk is now known as chihchun | ||
| robert_ancell | what's a good command to use the output of mirscreencast and produce a video file with reasonable compression? | 03:13 |
|---|---|---|
| RAOF | robert_ancell: Let me hunt down the email... | 03:15 |
| robert_ancell | RAOF, I figured this must have been recorded somewhere but my google-fu is not finding it | 03:15 |
| RAOF | mencoder -demuxer rawvideo -rawvideo fps=60:w=1920:h=1200:format=bgra /tmp/foo -ovc lavc -lavcopts vcodec=ffv1 -o all.avi | 03:17 |
| RAOF | Is one option. | 03:17 |
| RAOF | I don't think we have documented this anywhere, though. | 03:17 |
| RAOF | MPs welcome :) | 03:17 |
| RAOF | It'd be reasonably easy to translate that into a gstreamer pipeline that'd do the right thing, too. | 03:17 |
| robert_ancell | I should be able to convert that to a pipe right? In particular I'm running out of disk space too fast | 03:19 |
| RAOF | I *think* so? | 03:20 |
| RAOF | You certainly would be able to with gstreamer and fdsrc | 03:22 |
| RAOF | Urgh. How can our unittests fail in trunk? | 03:22 |
| robert_ancell | mirscreencast -m /run/lightdm-mir-0 --stdout | mencoder -demuxer rawvideo -rawvideo fps=60:w=1920:h=1200:format=bgra - -ovc lavc -lavcopts vcodec=ffv1 -o $1 | 03:23 |
| robert_ancell | I think that should do it | 03:23 |
| RAOF | Yeah, seems reasonable. | 03:23 |
| robert_ancell | except I need to adjust the size I guess.. | 03:23 |
| RAOF | And probably select a different vcodec; that'll give you lossless compression, which will be pretty good for a screencast but you may want more. | 03:23 |
| robert_ancell | It's probably better to encode fast and then re-encode when I'm done | 03:24 |
| RAOF | Yeah, not a bad plan. | 03:25 |
| RAOF | Intriguing. Tests fail when built with clang, pass with gcc. I guess I'll chalk this up to a compiler bug unless it persists. | 03:27 |
| robert_ancell | [ffv1 @ 0x7f8e54797b00]Error getting output packet. | 03:27 |
| robert_ancell | Muxer frame buffer cannot allocate memory! | 03:27 |
| robert_ancell | hmm | 03:27 |
| RAOF | Heh. g++'s error handling for “you missed a > on a template argument, doofus” remains gloriously opaque. | 03:34 |
| RAOF | Ok. Sped up our tests by a factor of 10, and they almost all still pass. | 03:37 |
| robert_ancell | Anyone know why Mir says it's outputting 60fps by screencast but it only appears to be 15fps? | 03:42 |
| RAOF | Possibly too slow to write? | 03:48 |
| robert_ancell | RAOF, I don't think so - it seems to generate an mp4 at 4x speed. If I set it to 15 it works fine | 03:50 |
| * RAOF makes the magic incantations which enable non-glacial speed on battery. | 03:52 | |
| === tvoss is now known as tvoss|test | ||
| === tvoss|test is now known as tvoss | ||
| alan_g | alf_: do you know why a Mir CI build tries to install libunity-mir1 etc.? https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/1795/console | 09:46 |
| alf_ | alan_g: looking | 09:46 |
| alf_ | alan_g: from what I understand, libunity-mir1 is already installed as part of the flashed image | 09:49 |
| alan_g | Oops! | 09:50 |
| alan_g | I'll pop over to ci-eng... | 09:50 |
| alan_g | CI he say: "/usr/include/android/system/graphics.h:269:5: error: 'size_t' does not name a type" ... I wonder if the android headers have been changed? | 10:26 |
| === chihchun is now known as chihchun_afk | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === alan_g is now known as alan_g|tea | ||
| dandrader | dednick, I guess your platform-api branches fixes those issues? http://paste.ubuntu.com/7663936/ | 14:26 |
| dednick | dandrader: yup | 14:27 |
| === alan_g|tea is now known as alan_g | ||
| === chihchun_afk is now known as chihchun | ||
| alan_g | greyback: does this test capture our current orientation requirements? http://paste.ubuntu.com/7664275/ | 15:45 |
| dandrader | alan_g, btw, gotta define mir_orienation_* values | 15:48 |
| dandrader | alan_g, is it an angle in degrees, counter-clockwise? | 15:49 |
| dandrader | alan_g, and will the app be able to query the value and not just receive events about it? | 15:50 |
| alan_g | dandrader: mir_toolkit/common.h line 120 | 15:50 |
| alan_g | dandrader: what I took from the discussion was the ability to send the events | 15:51 |
| alan_g | but I can add requirements... | 15:51 |
| dandrader | alan_g, yes. gotta have a line there explaining what those enum values mean | 15:51 |
| dandrader | documentation | 15:52 |
| greyback | alan_g: looks good yes | 15:54 |
| alan_g | dandrader: I only know what I see there. ;) | 15:54 |
| alan_g | greyback: do we need dandrader's suggestion of the client querying the orientation of a surface too? | 15:55 |
| greyback | alan_g: hmm, ideally yes a surface should be created with an orientation, or have a getter to read the orientation when it wants to. | 15:57 |
| * alan_g wonders if orientation should be a surface creation parameter? | 15:59 | |
| === dandrader is now known as dandrader|lunch | ||
| === dandrader|lunch is now known as dandrader | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === chihchun is now known as chihchun_afk | ||
| racarr_ | kgunn: dandrader: So I guess if by monday we havent come to an agreement re: input sender (gives tomorrow morning and friday) | 19:22 |
| racarr_ | we can do inputdispatcher | 19:22 |
| racarr_ | ugh 5 minutes until the pizza place opens but I cant wait ANY LONGER | 19:23 |
| racarr_ | ... | 19:23 |
| racarr_ | lol | 19:23 |
| kgunn | yeah...i think if you threaten alan with that, he'll suddenly love input sender :) | 19:23 |
| racarr_ | haha | 19:24 |
| racarr_ | using InputDispatcher isnt that bad | 19:25 |
| dandrader | racarr_, by inputdispatcher you mean exposing the whole android-input and letting us replace android::InputDispatcher | 19:25 |
| racarr_ | Yes. | 19:25 |
| dandrader | ok. I will have to dust off the patch I had for it :) | 19:25 |
| racarr_ | :) well maybe input sender will magically land in the morning lol, we will see | 19:25 |
| racarr_ | I'm sure InputDispatcher hasnt changed though | 19:26 |
| racarr_ | or android-input much at all | 19:26 |
| racarr_ | which is one of the reasons I think publishing android-input in a "privatized" library isn't that bad | 19:26 |
| dandrader | on the other hand. it will quite a bit of work to go back to that previous approach in qtmir.... | 19:26 |
| racarr_ | its additional ABI, but practically we dont change it rapidly at all. | 19:26 |
| racarr_ | Oh really ? :( | 19:27 |
| racarr_ | I imagined it would be almost plug/play InputSender->InputDispatcher-to-channel | 19:27 |
| === dandrader is now known as dandrader|afk | ||
| AlbertA | racarr_: ummm, do we really want to do that? | 19:37 |
| AlbertA | racarr_: don't we want to have the option to drop the android stuff completely at some point | 19:38 |
| racarr_ | AlbertA: it would be a privatized interface to unity-mir | 19:50 |
| racarr_ | if we arent able to land input-sender quick enough | 19:51 |
| AlbertA | racarr_: ummm didn't we just basically said no to privatized stuff even for our own examples? | 19:51 |
| racarr_ | Sure but 3 options | 19:52 |
| racarr_ | 1. Land input sender or something comparable | 19:52 |
| racarr_ | 2. Expose android-input for unity-mir | 19:52 |
| racarr_ | 3. Don't ship qt compositor | 19:52 |
| racarr_ | ;) | 19:52 |
| AlbertA | is there something really wrong with input sender? I haven't reviewed it yet | 19:53 |
| racarr_ | lol im not sure yet. my first review it just seemed kind of messy, but mostly as a consequence of the android bits....going to look more tomorrow | 19:54 |
| racarr_ | but there is some discussion between alf/alan_g about it too and | 19:54 |
| racarr_ | alan_g seems pessimistic about it. | 19:55 |
| racarr_ | s/tomorrow/this afternoon/ | 19:55 |
| AlbertA | racarr_: oh I see there's a dependency chain there | 19:57 |
| AlbertA | racarr_: it depends on another 2 mps | 19:57 |
| racarr_ | that too yes | 19:57 |
| AlbertA | I think I see the problem now | 19:58 |
| AlbertA | It's a massive diff overall | 19:58 |
| AlbertA | :) | 19:58 |
| racarr_ | aha yes that is a concern point | 19:59 |
| === josharenson1 is now known as josharenson | ||
| === dandrader|afk is now known as dandrader | ||
| racarr_ | i feel like im so close | 22:18 |
| racarr_ | to never again having to remember that the cursor | 22:18 |
| racarr_ | exists | 22:18 |
| racarr_ | soon we will do everything that xcursor does and the cursor will just be another renderable and it can fade in to memory lol | 22:18 |
| racarr_ | hmm. if the XCursorLoader fails to load any cursors do you think we should fall back to the builtin cursor | 22:20 |
| racarr_ | kind of weird to put logic in the server configuration | 22:20 |
| racarr_ | like that | 22:20 |
| racarr_ | I mean...there could be a...composite object that does that too... | 22:21 |
| racarr_ | or the XCursorLoader could have a builtin cursor (that seems the weirdest...) | 22:21 |
| racarr_ | seems like its still possible to hose the system if you crash the server at the right place in startup | 22:49 |
| racarr_ | cant even recover from ssh... | 22:49 |
| kdub_ | robert_ancell, cool, gtk! | 22:55 |
| racarr_ | Yeah! | 23:02 |
| racarr_ | ok coming back in a bit to finish off last bit of cursor loader and propose that to get one more thing off my mind lol and then work on groking input sender | 23:51 |
| racarr_ | but for now away for a while | 23:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!