[FFmpeg-devel-irc] IRC log for 2010-06-26

[irc at mansr.com]

[00:00:09] <Honoome> mru: we cross-patched :P
[00:12:23] <mru> Honoome: why do you want to tablegenify aes anyway?
[00:12:27] <mru> those tables are tiny
[00:12:52] <Honoome> it makes it entirely non-cow
[00:13:05] <mru> only those pages
[00:13:18] <Honoome> true
[00:13:41] <mru> it's 8k we're talking about
[00:13:44] <Honoome> but one step at a time, you know..
[00:14:07] <mru> I'd start with the multi-megabyte tables
[00:14:26] <Honoome> they are almost all due to the STATIC_VLC that I said above :/
[00:14:59] <lu_zero> STATIC_VLC and friends are a tad convoluted imho
[00:15:40] <Honoome> lu_zero: you were supposed to go to bed an hour ago!
[00:15:46] <lu_zero> I know
[00:15:55] <j0sh_> lu_zero: thanks for the quick review btw
[00:16:15] <j0sh_> lu_zero: dont we need to strip the protocol identifier in fmtp
[00:16:32] <j0sh_> (i'm just cargo culting here, havent actually read the rfcs)
[00:16:44] <lu_zero> I see
[00:17:16] <j0sh_> all the other depacketizers strip out the protocol id, so it must do something
[00:17:25] <lu_zero> well
[00:17:26] <j0sh_> otherwise it would eat up the whole fmtp line
[00:18:10] <lu_zero> once you know with tag it is you have to parse it's value
[00:18:34] <lu_zero> just felt a bit excessive removing it by eating spaces/nonspaces one by one
[00:18:45] <Honoome> mru: if you want I can send tablegenification of cook and dvbsubdec :P
[00:19:59] <j0sh_> lu_zero: is therre a better approach?
[00:20:23] <j0sh_> lu_zero: other depacketizers do the same thing basically, but don't look for tabs and newlines either
[00:23:11] <j0sh_> lu_zero: i see what it does now, it just strips out the 'fmtp:xx' part
[00:24:39] <j0sh_> er, no. the protocol identifier is a numeric value, right?
[00:26:00] <lu_zero> wait
[00:26:18] <Honoome> mru: hmm I think I'll propose a couple of improvements over the tableprint.h in the next few days.. after updating a couple, I think I see an usable pattern
[00:26:28] <lu_zero> http://tools.ietf.org/html/rfc2327
[00:26:34] <lu_zero> that might be useful
[00:26:51] <mru> Honoome: that's reimar's territory
[00:27:16] <Honoome> I said propose ;)
[00:30:42] <j0sh_> lu_zero: i need to send you guys a picture of all the rfcs i printed out
[00:32:14] * Honoome hugs the sony reader
[00:32:21] <drv> i speak for the trees! ;)
[00:32:43] <lu_zero> ^^;
[00:32:49] <lu_zero> I'm a bit afraid
[00:33:08] <Honoome> j0sh_: you do know that there is a docbookified version of rfc2326 around? :P
[00:33:36] <j0sh_> Honoome: no, what's docbook?
[00:33:42] * j0sh_ needs a ebook reader
[00:33:42] <Honoome> argh :P
[00:34:16] <Honoome> go for one that supports adobe de if you have an osx or win system around.. adobe has been so nice as to provide de with a drm that was cracked easily :P
[00:34:33] <j0sh_> the nook looks sweet
[00:34:37] <lu_zero> docbook is a markup I like, Honoome is pretty good in writing docs with it
[00:34:52] * Honoome speaks XML!
[00:34:58] <j0sh_> i'm not gonna get a kindle, because a keyboard on a ebook reader is just stupid
[00:37:03] <lu_zero> Honoome: that would be understood quite badly here
[00:37:14] <lu_zero> look out for BBB and his tar pot
[00:37:25] * Honoome curses Reiman a bit for the choice of function names and decides he'll work on that tomorrow
[00:37:41] <Honoome> lu_zero: as long as it's not schilly's star, it's fine :P
[02:58:28] <Dark_Shikari> mru: ping
[03:18:32] <astrange> j-b: i can't test it (well, if i had a linux cd i could), i don't want to break it though
[07:50:05] <mru> Dark_Shikari: pong
[07:51:24] <Dark_Shikari> mru: just curious what your opinion is on this idea + api for x264
[07:51:33] <Dark_Shikari> since you have more experience designing/reviewing apis and such than I do
[07:51:38] <Dark_Shikari> http://pastebin.org/359789
[07:51:55] <Dark_Shikari> purpose: allow the calling application to begin sending packets before the frame is done being encoded.
[07:52:01] <mru> callbacks are always icky
[07:52:17] <Dark_Shikari> this callback is even better: it's actually basically a closure
[07:52:24] <Dark_Shikari> i.e. we pass back a nal, and a nal_encode function
[07:52:26] <Dark_Shikari> and say "call it please"
[07:52:28] <mru> let me read the comment
[07:53:44] <mru> why does the main output break with this?
[07:54:25] <Dark_Shikari> ideally we don't want to run the nal_encode twice for no reason
[07:54:32] <mru> ok
[07:54:36] <Dark_Shikari> if we've already given output via the callback, running it again seems stupid
[07:54:40] <Dark_Shikari> I mean, it doesn't cost much speed, it's just pointless.
[07:55:20] <Dark_Shikari> hmm, I should probably modify it to give x264_t *h to the callback too, for convenience.
[07:55:33] <Dark_Shikari> (none of the backend code is written, just the api)
[07:55:38] <mru> yes, do that
[07:56:04] <mru> otherwise running multiple encoder instances becomes very hard
[07:57:03] <Dark_Shikari> The other issue I realized we had is that it's impossible to figure out what the correct order of the packets is
[07:57:15] <Dark_Shikari> and lavc (and most decoders) won't handle out of order slices
[07:57:27] <Dark_Shikari> so we'll have to add something to the x264_nal_t to tell the calling app the start and end MB of each slice
[07:57:49] <Dark_Shikari> (because with sliced threads, nalu_process will be called out of order)
[07:58:34] <Dark_Shikari> (speaking of which, we're interested in adding support for that to lavc)
[07:58:40] <Dark_Shikari> i.e. be able to throw single, arbitrary slices at it
[07:58:46] <Dark_Shikari> in any order
[07:58:46] <mru> with this callback, does the x264_nal_t passed to it remain valid after it returs?
[07:59:01] <Dark_Shikari> It remains valid until x264_encoder_encode is called again.
[07:59:14] <Dark_Shikari> note an x264_nal_t is just a very small struct containing a few data values and a pointer.
[07:59:16] <mru> ah, yes it's right there
[07:59:32] <Dark_Shikari> So it's trivial to copy.
[07:59:40] <Dark_Shikari> the pointer, before nal_encode, points to the raw, unescaped data
[07:59:43] <mru> so the callback could just kick another thread to do the actual processing and return immediately?
[07:59:45] <Dark_Shikari> the pointer, after nal_encode points to the user buffer.
[07:59:46] <Dark_Shikari> Yes.
[07:59:53] <Dark_Shikari> That might be useful for large slices.
[08:00:03] <Dark_Shikari> For a small slice, like 1500 bytes, it would cost more time in thread spawning than doing the actual work.
[08:00:15] <Dark_Shikari> since nal_encode is basically asm
[08:00:27] <mru> you wouldn't be so stupid as to _spawn_ a thread there
[08:00:36] <Dark_Shikari> ok, true, but even a context switch woulnd't be worth it
[08:00:44] <Dark_Shikari> it probably takes 400 clocks to escape a 1500 byte slice
[08:01:02] <Dark_Shikari> Basically, the reason we give that guarantee is that it costs x264 nothing to do so (that's how it just already is)
[08:01:06] <Dark_Shikari> so we might as well.
[08:02:19] <mru> I was thinking one might have an output thread running all the time taking x264_nal_t from a ring buffer or something
[08:02:26] <Dark_Shikari> Yeah, you could do that or something.
[08:02:42] <Dark_Shikari> Also, the reason this came up is we got demoed a broadcom system that did per-slice output like this (in hardware)
[08:02:48] <Dark_Shikari> and, I mean, it's not at all a new idea
[08:02:51] <Dark_Shikari> but we figured we should do it too
[08:03:05] <mru> if it's easy to do and helps someone, why not
[08:03:11] <Dark_Shikari> broadcom was claiming 1080p @ 3ms encoding time with 300mw
[08:03:17] <Dark_Shikari> h264
[08:03:28] <Dark_Shikari> 'course, that was intra only.  They admitted latency would go up with inter compression.
[08:03:32] <mru> and psnr of 3 too
[08:03:37] <Dark_Shikari> lol
[08:04:06] <Dark_Shikari> Apparently my boss sorta scared him when he said "so how does the quality compare to x264"
[08:04:33] <Dark_Shikari> "oh shit our potential customers are comparing us to something that isn't shit.  whatever do we do"
[08:04:43] <j0sh_> Dark_Shikari: i have never used x264's api, so this may sound dumb
[08:05:01] <j0sh_> but why not have x264_nal_encode return the nal units, via an init option or whatever
[08:05:09] <Dark_Shikari> ?
[08:05:25] <Dark_Shikari> currently, when you call x264_encoder_encode, it gives you back completed nal units
[08:05:28] <Dark_Shikari> book it, done
[08:05:28] <j0sh_> since it sounds like its useless if you use the nalu_process callback
[08:05:31] <mru> ibc 2004 was hilarious
[08:05:31] <Dark_Shikari> at the end of each frame
[08:05:40] <mru> all the vendors were showing h264 encoders
[08:05:43] <Dark_Shikari> the new idea: make it so that you can get back the nalus the instant they are done
[08:05:47] <mru> all the encoders looked much more shit than mpeg2
[08:05:50] <Dark_Shikari> even if the whole frame isn't done yet
[08:05:55] <mru> because they _were_ mpeg2 encoders
[08:05:56] <Dark_Shikari> (If you want, not required)
[08:06:06] <Dark_Shikari> mru: 300mw is still pretty impressive.
[08:06:10] <j0sh_> right, why can't you just use the old interface for that
[08:06:13] <Dark_Shikari> Though I have a strong suspicion there is a lot of hardcoding going on
[08:06:23] <Dark_Shikari> i.e. it isn't flexible
[08:06:24] <mru> the only good demo there was from NTT
[08:06:36] <Dark_Shikari> j0sh_: how will the calling app know when the NAL units are returned?
[08:06:36] <mru> they'd spent like 3 weeks encoding a 5-minute clip
[08:06:44] <Dark_Shikari> lol
[08:06:55] <j0sh_> Dark_Shikari: same way it knows when a frame is complete?
[08:06:56] <mru> ok, I made that up
[08:07:03] <mru> but they'd done something insane
[08:07:20] <Dark_Shikari> j0sh_: when it returns?
[08:07:28] <Dark_Shikari> you mean have x264_encoder_encode encode one slice instead of one frame?
[08:07:32] <j0sh_> i suppose (never used x264 api)
[08:07:38] <mru> what bitrate does x264 need for good quality 1080p these days?
[08:07:44] <Dark_Shikari> it works the same way as ffmpeg
[08:08:45] <Dark_Shikari> i.e. you give it an input frame, it gives you an output frame
[08:08:49] <j0sh_> right
[08:09:10] <j0sh_> it just seems a bit hacky, having two interfaces to get the data, even thoug theyre for different purposes
[08:09:26] <j0sh_> s/get the data/get the same data
[08:10:28] <Dark_Shikari> j0sh_: here's why that won't work
[08:10:34] <Dark_Shikari> x264 encodes multiple slices at once
[08:10:42] <Dark_Shikari> therefore, any return method MUST be asynchronous
[08:10:48] <Dark_Shikari> because slices can finish at any point in time, possibly simultaneously
[08:10:53] <Dark_Shikari> and can be anywhere in the frame
[08:11:08] <Dark_Shikari> and it makes sense to have two interfaces -- a high level one and a low level one
[08:11:26] <Dark_Shikari> the high level one for most apps, the low level one for apps that need a special flexibility or feature
[08:11:27] <j0sh_> is x264_nal_encoder_encode a callback also?
[08:11:35] <Dark_Shikari> x264_nal_encode you mean?
[08:11:38] <Dark_Shikari> it's just an internal function.
[08:11:49] <Dark_Shikari> it converts an internal-to-x264 nal_t into a ready-for-output nal_t
[08:11:54] <j0sh_> err, encoder_encode
[08:12:01] <Dark_Shikari> x264_encoder_encode is just a synchronous call
[08:12:05] <Dark_Shikari> takes input frame, gives you output frame
[08:12:16] <Dark_Shikari> mru: depends on the clip, your definition of good quality, and the constraints =p
[08:13:49] <mru> nature scene, virtually no blockiness, no constraints
[08:14:14] <Dark_Shikari> virtually no blockiness -> let's just blur everything
[08:14:21] <mru> ok, no blur either
[08:14:23] <Dark_Shikari> but seriously, about 3-7mbps.
[08:14:27] <mru> ok
[08:14:39] <Dark_Shikari> parkjoy, a very hard clip (1080p50) takes ~10-15mbps
[08:14:45] <Dark_Shikari> or 5-7.5mbps at 25p
[08:14:46] <j0sh_> Dark_Shikari: got it. the distinction is between being synchronous and async
[08:14:50] <Dark_Shikari> j0sh_: yes
[08:14:56] <Dark_Shikari> there are other solutions for the problem
[08:15:07] <Dark_Shikari> Another option, for example, would be to have a condition variable
[08:15:14] <Dark_Shikari> and to broadcast whenever nal units are available to pick up
[08:15:19] <mru> I don't remember what bitrate that NTT clip was, but it was in that ballpark
[08:15:22] <Dark_Shikari> Or various other threading hacks
[08:15:29] <Dark_Shikari> All of them imo are uglier than a callback
[08:15:34] <Dark_Shikari> and less crossplatform
[08:15:37] <j0sh_> Dark_Shikari: that requires the thread to poll, doesnt it? hacky
[08:15:40] <Dark_Shikari> Yes.
[08:15:41] <Dark_Shikari> Hacky.
[08:15:57] <Dark_Shikari> So basically the idea is to have a callback and let the app handle its own synchronization problems
[08:16:03] <mru> callback makes sense here
[08:16:06] <Dark_Shikari> i.e. me being able to call the callback 4 times from different cores at the same time.
[08:16:25] <j0sh_> i agree. i think it was the wording that threw me
[08:16:55] <mru> this is missing one thing
[08:16:55] <Dark_Shikari> Of course, now we need to fix lavc to allow us to send it out of order slices.
[08:17:07] <mru> there's no way for the app to determine which order those slices go
[08:17:14] <mru> without looking inside the payload
[08:17:32] <Dark_Shikari> That's what I said earlier
[08:17:39] <Dark_Shikari> we can add variables to x264_nal_t
[08:17:52] <Dark_Shikari> to mark the start and end of each slice
[08:18:04] <mru> or a slice index
[08:18:07] <Dark_Shikari> Impossible
[08:18:10] <Dark_Shikari> we don't know how many slices there will be yet
[08:18:14] <mru> oh
[08:18:28] <Dark_Shikari> e.g. in the case of slice-max-size.
[08:18:33] <mru> right
[08:18:40] <Dark_Shikari> that threw my boss for a loop
[08:18:45] <Dark_Shikari> once he realized that was the case
[08:18:51] <Dark_Shikari> he was like "oh shit, this breaks half our assumptions"
[08:19:05] <Dark_Shikari> (the assumptions being "we know how many slices there are when we start sending packets")
[08:19:14] <Dark_Shikari> and their order
[08:19:17] <Dark_Shikari> and on receiving
[08:19:32] <Dark_Shikari> (currently our header for each packet contains index and count)
[08:27:08] <j0sh_> 1 slice == 1 nalu? or 1 slice == many nalus?
[08:28:07] <Dark_Shikari> former
[09:36:44] <KotH> nalu? is that a new currency? ;)
[09:37:19] <lu_zero>   KotH yup
[09:37:30] <lu_zero> btw you are in Geneve this week?
[09:37:36] <KotH> nope
[09:37:43] <KotH> but i can try to be there :)
[09:37:45] <lu_zero> =|
[09:38:09] <KotH> iirc rathann is still there too
[09:38:14] <KotH> when are you in geneva?
[09:38:34] <lu_zero> I'll be around there from tomorrow to tuesday
[09:38:51] <KotH> when tomorrow?
[09:38:58] <lu_zero> yet to be decided
[09:39:05] <lu_zero> I have to gather the other people
[09:39:21] <mru> say hi to my sister if you see her :-)
[09:39:35] <KotH> i can manage to be in geneva in the late afternoon/early evening tomorrow or on monday evening
[09:39:51] <KotH> mru: i dont have her phone number, yet ;)
[09:40:33] <spaam> KotH: do you think she will be cute? come.. female version of mru ;)
[09:40:53] <KotH> spaam: lol.. you dont even know mru
[09:40:59] <mru> KotH has met her
[09:41:01] <KotH> spaam: beside, i know her already :)
[09:41:11] <j0sh_> lu_zero: can i substitute my earlier series of patches for an emailed status update tonight? :)
[09:41:17] <spaam> KotH: but i have seen pictures of mru ;D
[09:41:34] <KotH> spaam: and we've all seen pictures of diegomax ;)
[09:41:35] <spaam> KotH: if you already know her.. then it cant be that hard to find her number :)
[09:41:44] <lu_zero> KotH: you are in sweden?
[09:41:48] <KotH> lol
[09:41:52] <spaam> KotH: haha yeah.. but i didnt do those pictures ;)
[09:41:57] <KotH> lu_zero: nope, in zürich
[09:42:19] <KotH> lu_zero: but i've met many people, strange and curious over all those years ;)
[09:42:46] <lu_zero> j0sh_: you disike reports a lot ^^?
[09:43:09] <j0sh_> lu_zero: only when i feel like i have nothing to say
[09:43:17] <mru> KotH: are you calling my sister strange?
[09:43:27] <mru> 'cause if you are, you're not far off the mark
[09:43:28] <spaam> mru: he did that
[09:43:35] <lu_zero> KotH: my mental image of mru sister would be some kind of female version of him, riding a llama in some kind of traditional swedish garments
[09:43:45] <spaam> mru: you know what you have to do with KotH !
[09:43:51] <KotH> lu_zero: rotfl
[09:43:53] <mru> lu_zero: the other sister
[09:44:04] <spaam> lu_zero: hahaha
[09:44:08] <lu_zero> mru: she's your sister, the blood is the same
[09:44:12] <spaam> mru: do you have two sisters? :O
[09:44:16] <mru> yes, two
[09:44:18] <spaam> pics?
[09:44:19] <mru> one has a llama
[09:44:29] <mru> the other is trying to blow up the universe at lhc
[09:44:34] <lu_zero> ah
[09:44:51] <lu_zero> the mental image gets even more interesting
[09:44:55] <j0sh_> am i too far off the mark when i say all of our sisters probably think we're weirdo computer geeks?
[09:45:09] <j0sh_> mine does, at least
[09:45:10] <mru> I know mine do
[09:45:19] <KotH> lu_zero: if i can manage to get hold of her, i'll introduce you
[09:45:26] <lu_zero> j0sh_: I have a wierd biology/medicine/whatever geek as sister...
[09:45:32] <KotH> mru: do you have me a number? :)
[09:45:39] <lu_zero> ok
[09:45:48] <lu_zero> be prepared to use japanese btw
[09:46:02] <KotH> j0sh_: sorry, no sister available on this end of the tubes
[09:46:11] <KotH> lu_zero: no prob
[09:46:28] * KotH makes a mental note to take his dictionary with him
[09:46:35] * lu_zero we'll pay the fact he didn't learn enough this weekend
[09:46:42] <KotH> lol
[09:46:47] <KotH> lu_zero: btw: why are you in .ge?
[09:46:59] <lu_zero> igf meeting
[09:47:11] <KotH> igf?
[09:47:21] <KotH> imaginary girl friend?
[09:47:26] <lu_zero> UN internet governance forum
[09:47:33] <KotH> ah..
[09:47:40] <KotH> sounds interesting
[09:47:50] <KotH> lu_zero: why didnt you tell me before, i would have taken a few days off
[09:48:06] <lu_zero> KotH: I do ALWAYS forget you are there =_=
[09:48:35] <lu_zero> usually I put you somewhere between tokyo and berlin
[09:48:40] <KotH> rotfl
[09:48:49] <lu_zero> my fault
[09:49:04] * lu_zero needs latitude or such service to remember positions
[09:49:09] <KotH> lu_zero: ok, then make a note somewhere that you are talking to a japanophile turkish living _in_switzerland_ :)
[09:49:33] <lu_zero> theheh
[09:49:34] <lu_zero> btw
[09:49:54] <lu_zero> I was serious when I was thinking about an ffcon in Tokyo or Sapporo
[09:50:30] * lu_zero should get the foundation website done and start asking for sponsorships
[09:50:35] <KotH> lu_zero: 47°25'N 8°33'E
[09:50:43] <mru> lu_zero: ffcon in japan is not practical
[09:50:58] <mru> too many devs would be unable to go
[09:51:05] <mru> even if we managed to sponsor the trip
[09:51:25] <Dark_Shikari> he just wants an excuse for a junket to japan
[09:51:49] <mru> I'd go, no question
[09:51:54] <pross-au> .jp is not exactly the centre of the FFmpeg universe
[09:51:56] <mru> but I know others are less flexible
[09:52:06] <lu_zero> pross-au: well you could make it
[09:52:07] <KotH> mru: having enough sponsors, it would be possible
[09:52:12] <mru> no
[09:52:14] <KotH> mru: visa is generally not so much a problem
[09:52:23] <mru> none needed for most of us
[09:52:23] <Dark_Shikari> imo there's better things to use the money on
[09:52:29] <mru> but that's not the issue
[09:52:32] <pross-au> Japan is expensive
[09:52:35] <lu_zero> Dark_Shikari: opinions?
[09:52:41] <mru> the issue is the 12-hour travel to get there
[09:52:46] <KotH> pross-au: but japanese is one of the three fflanguages
[09:52:54] <pross-au> three?
[09:52:58] <pross-au> Oh right.
[09:53:02] <KotH> pross-au: c, sweedish and japanese
[09:53:07] <Dark_Shikari> mru: 12 hours to get to europe too.
[09:53:09] <KotH> pross-au: and japan isnt that expensive
[09:53:15] <mru> Dark_Shikari: not for the euro devs
[09:53:15] <KotH> pross-au: zürich is more expensive than tokyo
[09:53:19] <mru> and those are many
[09:53:20] <Dark_Shikari> mru: well duh
[09:53:25] <Dark_Shikari> but it's not 12 hours to get to japan for the japan devs
[09:53:27] * Dark_Shikari ducks
[09:53:33] <lu_zero> given most of us are europeans I might really try to get something here (Torino)
[09:53:55] <lu_zero> Dark_Shikari: that gives me yet another idea for the website
[09:54:00] <Dark_Shikari> if we ever did have an ffcon in japan, I could try to get all the japanese x264 people to come
[09:54:00] <KotH> lu_zero: well, i have a potential location in northern germany that isnt too expensive
[09:54:15] <Dark_Shikari> but some of them are hikkikomori so it might be hard.
[09:54:15] <KotH> lu_zero: if i had the time, i would have organized something for september
[09:54:51] <lu_zero> Dark_Shikari: ouch
[09:54:52] <KotH> Dark_Shikari: there are ways to get hikkikomori out of their cave
[09:55:01] * KotH knows such people
[09:55:04] <lu_zero> KotH: name 3
[09:55:19] <KotH> lu_zero: 1) visit them at their place
[09:55:23] <KotH> lu_zero: 2) talk to them
[09:55:32] <spaam> *drusm*
[09:55:37] <KotH> lu_zero: 3) make them sense that you are not less strange than they are
[09:55:39] <KotH> lu_zero: 4)...
[09:55:43] <KotH> lu_zero: 5) profit
[09:55:48] <lu_zero> KotH: 3 is easy
[09:55:48] <Dark_Shikari> yeah, it's not impossible
[09:55:53] <Dark_Shikari> especially when they're already on irc a lot
[09:56:10] <KotH> lu_zero: besidde, they are japanese. ie easy to drag around
[09:56:19] <KotH> lu_zero: then give them some alc and they open up
[09:56:22] <Dark_Shikari> lol
[09:56:37] <KotH> been there, done that, succeeded
[09:56:38] <lu_zero> KotH: you mean pick them up and move them like they are small furniture?
[09:56:46] <KotH> lu_zero: exactly!
[09:57:01] <KotH> lu_zero: though, you only have to do it the first minute or two
[09:57:14] <lu_zero> KotH: well the Japanese friend I know are among the few with a extreme alcool resitance...
[09:57:15] <KotH> lu_zero: after they've left their cave, they will follow you like small dogs
[09:57:27] * twnqx likes northern germany
[09:57:35] <KotH> lu_zero: japanese can drink a lot....
[09:57:43] <KotH> lu_zero: more than you'd expect from the stories
[09:57:53] <lu_zero> KotH: japanese beer isn't drinking...
[09:57:57] <KotH> lu_zero: but, they are not used to european stuff, thus get pretty fast drunk here
[09:58:11] <lu_zero> I mean friends living here
[09:58:12] <KotH> lu_zero: then, is it food?
[09:58:17] <KotH> ah.. ok
[09:58:29] <lu_zero> drinking stuff that is strong for the locals...
[09:59:20] <lu_zero> j0sh_: good report =)
[10:01:57] <lu_zero> still first we should get a website
[10:04:20] <CIA-99> ffmpeg: mru * r23792 /trunk/common.mak: Fix brief make messages when CC etc are specified on command line
[10:05:21] <lu_zero> KotH: btw do you have my cellphone number?
[10:06:51] <KotH> if you have mine, then probably yes :)
[10:07:10] <mru> assurance of mutual destruction?
[10:07:20] <KotH> lu_zero: nope, i dont have it
[10:15:42] <lu_zero> mru: ?
[10:17:40] <lu_zero> btw swiss operators have pre-paid sim with good data plans?
[10:17:57] <mru> yes, good for them
[10:18:17] <lu_zero> mru: =P
[10:26:57] <Honoome> lu_zero: if you foresee asking me again for geneve, let me know about that as well :P
[10:30:31] <KotH> lu_zero: no idea
[10:30:36] <KotH> lu_zero: i never used prepaid
[10:34:14] * KotH goes off
[10:34:15] <KotH> bbl
[10:44:02] <janneg> lu_zero: for limited usage http://www2.coop.ch/coopmobile/ang_internet_datenoption.cfm?language=it is not too bad
[10:44:33] <janneg> 100M free, then 0.2 franc per MB
[10:45:39] * janneg has a sister in geneve too
[11:25:33] <lu_zero> uhmm
[11:27:04] <lu_zero> sounds interesting
[11:27:50] <lu_zero> 15chf is quite good
[11:41:19] <j-b> astrange: I have to say that linux isn't my priority care, but DxVA2 is :D
[11:42:21] * mru sends j-b off for priority adjustment
[12:15:29] * /join #ffmpeg-devel ...
[12:15:31] *** TOPIC: Welcome to the FFmpeg development channel. | Discussions about the development of FFmpeg itself are ontopic here. | Questions about using FFmpeg or developing with the libav* libraries should be asked in #ffmpeg. | FFmpeg 0.6 has been released! | This channel is now publicly logged.
[12:15:31] *** TOPICINFO: peloverde!~alex at cpe-173-88-148-20.neo.res.rr.com, 1276886498