[03:13] <robert_ancell> what's a good command to use the output of mirscreencast and produce a video file with reasonable compression?
[03:15] <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:17] <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:19] <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:20] <RAOF> I *think* so?
[03:22] <RAOF> You certainly would be able to with gstreamer and fdsrc
[03:22] <RAOF> Urgh. How can our unittests fail in trunk?
[03:23] <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:24] <robert_ancell> It's probably better to encode fast and then re-encode when I'm done
[03:25] <RAOF> Yeah, not a bad plan.
[03:27] <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:34] <RAOF> Heh. g++'s error handling for “you missed a > on a template argument, doofus” remains gloriously opaque.
[03:37] <RAOF> Ok. Sped up our tests by a factor of 10, and they almost all still pass.
[03:42] <robert_ancell> Anyone know why Mir says it's outputting 60fps by screencast but it only appears to be 15fps?
[03:48] <RAOF> Possibly too slow to write?
[03:50] <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:52]  * RAOF makes the magic incantations which enable non-glacial speed on battery.
[09:46] <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:49] <alf_> alan_g: from what I understand, libunity-mir1 is already installed as part of the flashed image
[09:50] <alan_g> Oops!
[09:50] <alan_g> I'll pop over to ci-eng...
[10:26] <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?
[14:26] <dandrader> dednick, I guess your platform-api branches fixes those issues? http://paste.ubuntu.com/7663936/
[14:27] <dednick> dandrader: yup
[15:45] <alan_g> greyback: does this test capture our current orientation requirements? http://paste.ubuntu.com/7664275/
[15:48] <dandrader> alan_g, btw, gotta define mir_orienation_* values
[15:49] <dandrader> alan_g, is it an angle in degrees, counter-clockwise?
[15:50] <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:51] <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:52] <dandrader> documentation
[15:54] <greyback> alan_g: looks good yes
[15:54] <alan_g> dandrader: I only know what I see there. ;)
[15:55] <alan_g> greyback: do we need dandrader's suggestion of the client querying the orientation of a surface too?
[15:57] <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:59]  * alan_g wonders if orientation should be a surface creation parameter?
[19:22] <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:23] <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:24] <racarr_> haha
[19:25] <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:26] <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:27] <racarr_> Oh really ? :(
[19:27] <racarr_> I imagined it would be almost plug/play InputSender->InputDispatcher-to-channel
[19:37] <AlbertA> racarr_: ummm, do we really want to do that?
[19:38] <AlbertA> racarr_: don't we want to have the option to drop the android stuff completely at some point
[19:50] <racarr_> AlbertA: it would be a privatized interface to unity-mir
[19:51] <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:52] <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:53] <AlbertA> is there something really wrong with input sender? I haven't reviewed it yet
[19:54] <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:55] <racarr_> alan_g seems pessimistic about it.
[19:55] <racarr_> s/tomorrow/this afternoon/
[19:57] <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:58] <AlbertA> I think I see the problem now
[19:58] <AlbertA> It's a massive diff overall
[19:58] <AlbertA> :)
[19:59] <racarr_> aha yes that is a concern point
[22:18] <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:20] <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:21] <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:49] <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:55] <kdub_> robert_ancell, cool, gtk!
[23:02] <racarr_> Yeah!
[23:51] <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