[Ffmpeg-devel-irc] ffmpeg-devel.log.20151021

[burek]

[00:32:17 CEST] <cone-732> ffmpeg 03Andreas Cadhalpun 07master:95687dc310ba: avutil: install des.h, rc4.h and tree.h as public headers
[00:32:18 CEST] <cone-732> ffmpeg 03Andreas Cadhalpun 07master:3dfb643cd407: avcodec: remove unused avpriv_ac3_parse_header
[00:32:19 CEST] <cone-732> ffmpeg 03Andreas Cadhalpun 07master:451b6a990a11: avutil: merge avpriv_float_dsp_init into avpriv_float_dsp_alloc
[00:50:36 CEST] <cone-732> ffmpeg 03Tobias Rapp 07master:1ec8c1554ed8: avfilter/vf_psnr: Add support for writing stats to stdout
[02:19:43 CEST] <BBB> are all statics inited to zero?
[02:19:51 CEST] <BBB> I thought that was only true for static const (rodata stuff)
[02:20:08 CEST] <wm4> yes all are
[02:20:25 CEST] <wm4> const doesn't matter
[03:27:09 CEST] <cone-732> ffmpeg 03Timothy Gu 07master:6b41b4414934: huffyuvencdsp: Convert ff_diff_bytes_mmx to yasm
[05:26:55 CEST] <cone-732> ffmpeg 03James Zern 07master:6540fe04a3f9: libvpxenc: remove some unused ctrl id mappings
[05:49:22 CEST] <Timothy_Gu> jamrial: so does the alignment requirement depend on coding of the opcode (VEX-/non-VEX-coded) or the width of the register
[05:50:14 CEST] <Timothy_Gu> the instruction set reference just says "Legacy SSE"
[05:50:21 CEST] <Timothy_Gu> versus "AVX"
[05:51:43 CEST] <Timothy_Gu> oh that it's VEX-coded
[05:52:01 CEST] <Timothy_Gu> "With the exception of explicitly aligned 16 or 32 byte SIMD load/store instructions, most VEX-encoded,
[05:52:04 CEST] <Timothy_Gu> arithmetic and data processing instructions operate in a flexible environment regarding memory address
[05:52:07 CEST] <Timothy_Gu> alignment, i.e. VEX-encoded instruction with 32-byte or 16-byte load semantics will support unaligned load
[05:52:10 CEST] <Timothy_Gu> operation by default. "
[05:58:01 CEST] <jamrial> yeah, it's the instruction encoding. "legacy sse" referers to that, not the size of the reg
[06:31:29 CEST] <atomnuker> so far there have been no objections to adding Daala parsing support
[06:31:50 CEST] <atomnuker> so unless someone here has something to say, I'm getting ready to push
[06:53:11 CEST] <jamrial> atomnuker: just make sure to put the codec id in the right place, and bump libavcodec minor in the same commit
[06:53:58 CEST] <jamrial> atomnuker: also, maybe bump libavformat micro in the oggparsedaala commit. but not minor
[07:02:57 CEST] <cone-732> ffmpeg 03Rostislav Pehlivanov 07master:b7c9873bed7d: lavc: add AV_CODEC_ID_DAALA to the list of codec IDs and bump minor
[07:02:58 CEST] <cone-732> ffmpeg 03Rostislav Pehlivanov 07master:0f87cbdd51f4: lavf: add oggparsedaala and bump micro
[07:07:19 CEST] <atomnuker> my parser was tested by the other guy (who also added support for libdaala encoding & decoding) and it works
[07:07:36 CEST] <rcombs> daala hype
[07:08:16 CEST] <atomnuker> so, now a proper, full speed decoder which runs real time on my celeron can be started
[07:10:17 CEST] <atomnuker> with copius amounts of assembly, 4 space indentations and nice C90 inlines everywhere
[08:08:48 CEST] <fritsch> wm4: congrats to the new job - just seen it in the media - as you might know about the past (xbmc, plex) it was not a nice past at all - but yeah - they now did the right technical decision in hiring you. So congrats to this
[08:23:34 CEST] <atomnuker> whaaaaat, wm4 has a job? what will happen to mpv? libass? all the great popcorn worthy arguments with cehoyos?
[08:26:17 CEST] <fritsch> https://blog.plex.tv/2015/10/20/introducing-the-plex-media-player <- see
[08:28:15 CEST] <rcombs> as you can see, there are no plans to stop development of libass or mpv :)
[08:30:41 CEST] <atomnuker> I wasn't really concerned that :)
[08:31:07 CEST] <rcombs> hey, with some companies it's a legit concern
[09:05:13 CEST] <wm4> well the job is not that new
[09:07:34 CEST] <nevcairiel> doesnt rcombs also work for plex, or do i misremember
[09:07:42 CEST] <rcombs> yeah
[09:13:09 CEST] <wm4> fritsch: anyway, thanks - yeah, xbmc and plex apparently had a bumpy past, but obviously they're getting better with open source
[09:53:46 CEST] <fritsch> wm4: tomorrow today is already yesterday :-) so concentrate on the future
[12:20:39 CEST] <kierank> wm4: congratulations I guess
[12:46:31 CEST] <nevcairiel> this function pointer business is confusing
[12:46:38 CEST] <nevcairiel> we use both "func" and "&func" in the source
[12:46:47 CEST] <nevcairiel> both seem to work the same way
[12:46:52 CEST] <nevcairiel> which one is more C-correct?
[12:57:24 CEST] <nevcairiel> apparently both are equally valid in C
[12:57:26 CEST] <nevcairiel> oh well
[13:03:51 CEST] <wm4> isn't even &&&func valid? (don't quite remember)
[13:47:53 CEST] <thardin> wm4: no, &&foo gets counted as the address of a local variable
[13:48:09 CEST] <thardin> and &&&foo simply won't compile
[13:55:31 CEST] <nevcairiel> if someone feels like reading overly verbose windows code, review my tls schannel patch =p
[13:59:18 CEST] <__gb__> unary operator && is a GCC extension, that served the purpose of "computed gotos"
[13:59:27 CEST] <__gb__> mainly used in the past to implement fast VMs
[14:01:40 CEST] <__gb__> see literature for inline threaded dispatchers
[14:01:45 CEST] <wm4> nevcairiel: oh, nice
[14:05:15 CEST] <kierank> atomnuker: looking forward to http://www.theverge.com/2015/10/21/9575901/eurostar-new-train-design-pictures ?
[14:06:46 CEST] <J_Darnley> I was thinking those can't be Eurostar star trains they're too nice.  Then I scroll down and see what they're really like.
[14:07:18 CEST] <kierank> THERE IS A TRAC OUTAGE TONIGHT FROM 0000 - DON'T SAY YOU WEREN'T TOLD
[14:11:02 CEST] <__gb__> what? no more Alsthom TGVs?
[14:17:55 CEST] <kierank> they are a bit old
[14:28:26 CEST] <cone-848> ffmpeg 03Hendrik Leppkes 07master:4da52e363034: aacdec: fix strict prototype warning
[14:49:38 CEST] <j-b> kierank: they feel cheap.
[14:51:16 CEST] <Daemon404> nevcairiel, re: 4da52e363034, i was aware, but i personally think that warning is stupid.
[14:51:43 CEST] <nevcairiel> its 4 extra characters, so just add em :d
[14:51:49 CEST] <nevcairiel> its just C being C
[14:51:49 CEST] <Daemon404> does any compiler even care
[14:52:04 CEST] <RiCON> nevcairiel: what about http://j.fsbn.eu/Kogc.txt
[14:52:23 CEST] <Daemon404> RiCON, that is very wrong
[14:52:27 CEST] <nevcairiel> also entirely unrelated
[14:53:35 CEST] <RiCON> rtmpe works with schannel
[14:54:34 CEST] <RiCON> (with gmp)
[14:54:46 CEST] <nevcairiel> in any case, it should not link these without the user explicitly enabling them
[14:54:57 CEST] <nevcairiel> we dont usually do that
[14:55:28 CEST] <nevcairiel> hence why its tied to gnutls, since that adds deps on those libraries already anyway
[14:55:34 CEST] <Daemon404> s/should not/must not/
[14:55:36 CEST] <Daemon404> it changes the license
[14:56:03 CEST] <nevcairiel> i dont know whats gnutls license situation
[14:56:22 CEST] <Daemon404> it has a transitive dep on lgplv3
[14:56:34 CEST] <Daemon404> so it requires --enable-v3
[14:56:34 CEST] <nevcairiel> configure doesnt seem to enforce that
[14:56:46 CEST] <Daemon404> kinda wrong then
[15:03:06 CEST] <RiCON> right, gmp depends on lgplv3 or gplv2
[15:09:38 CEST] <iive> there must be versions of gnutls that are not gplv3. do we support them?
[15:16:57 CEST] <cone-848> ffmpeg 03Julian Scheel 07master:da43e9e157a3: mmaldec: Fix avpriv_atomic_get usage
[15:19:14 CEST] <RiCON> nevcairiel: gcrypt is lgpl so that could be used?
[16:01:47 CEST] <nevcairiel> the same limitation of not magically linking to an external library without user request applies, however
[16:22:21 CEST] <nevcairiel> wm4: how well does mmal work if i just take yuv420p from it? still usable for realtime playback?
[16:25:56 CEST] <wm4> low bitrate 720p just about works
[16:26:27 CEST] <wm4> but normally the opaque format is needed, then 1080p bluray streams are no problem
[16:26:47 CEST] <nevcairiel> i feared as much
[16:33:41 CEST] <RiCON> nevcairiel: what would be the proper way of supporting ffrtmpcrypt then? find corresponding support for crypt stuff in schannel?
[16:55:31 CEST] <nevcairiel> RiCON: you can still use gmp or gcrypt, just need to add an option to let the user specifically select it, instead of automatically using it
[16:55:47 CEST] <nevcairiel> i dont think schannel exposes the required functionality
[16:55:52 CEST] <nevcairiel> or any other windows component
[17:00:29 CEST] <RiCON> i remember looking for it the first time you mentioned the patch
[17:01:18 CEST] <RiCON> i think there is, but i couldn't tell for sure
[17:24:52 CEST] <mateo`> i have a quick question regarding the h264 codec extradata, it is always stored in the avcC format ?
[17:27:35 CEST] <nevcairiel> no
[17:27:46 CEST] <nevcairiel> either either that or just the sps/pps in annexb format
[17:27:50 CEST] <Compn> mateo` : in mp4 or other container ?
[17:27:51 CEST] <nevcairiel> -either
[17:28:18 CEST] <wm4> nevcairiel: what container stores it in annexb format?
[17:28:18 CEST] <mateo`> Compn: in AVCodecContext.extradata
[17:28:47 CEST] <nevcairiel> wm4: avi probably, but I was talking about what AVCodecContext can  contain
[17:29:04 CEST] <Compn> ... dont put h264 in avi 
[17:29:27 CEST] <wm4> avi? but of course!
[17:29:35 CEST] <wm4> the container that fucks up everything
[17:29:49 CEST] <Mavrik> MPEG2-TS is AnnexB
[17:30:06 CEST] <nevcairiel> but that doesnt store extradata
[17:30:18 CEST] <nevcairiel> not separately, anyway
[17:30:32 CEST] <Mavrik> Yep.
[17:30:37 CEST] <nevcairiel> but avformat will find it and extract it into AVCodecContext in AnnexB format, so you need to handle both
[17:30:58 CEST] <nevcairiel> incidentally, you can usually use the format of the extradata to determine if the bitstream is annexb or mp4
[17:31:48 CEST] <mateo`> is there a function somewhere that determines which kind is it ?
[17:32:08 CEST] <nevcairiel> if extradata[0] == 1 then avcC else annexb
[17:32:12 CEST] <Mavrik> Doesn't libx264 give you headers in AnnexB in libx264.c as well?
[17:32:31 CEST] <mateo`> nevcairiel: ok :)
[17:43:04 CEST] <RiCON> nevcairiel: "just need to add an option to let the user specifically select it" <- can/must that be done without repeating the tests?
[17:45:38 CEST] <ubitux> libavdevice/decklink_common.h:typedef struct AVPacketQueue {
[17:45:40 CEST] <ubitux> ugh.
[17:45:49 CEST] <ubitux> > decklink
[17:45:52 CEST] <ubitux> > define AV*
[17:47:42 CEST] <mateo`> nevcairiel: do you know if there is already a function that extract the pps/sps from the avcC extradata ?
[17:49:59 CEST] <wm4> I don't think there's any reusable function, but some code does it
[17:50:04 CEST] <wm4> like mp4toannex bsf
[17:50:10 CEST] <wm4> or the h264 code itself
[17:52:32 CEST] <mateo`> thanks, i'll look at mp4toannexb
[17:56:52 CEST] <ubitux> michaelni_: lol, like that swamp mail leak?
[17:57:22 CEST] <ubitux> nice, an fbi address
[18:03:09 CEST] <BBB> ?
[18:05:02 CEST] <RiCON> Daemon404: like this? http://sprunge.us/MUKB?diff (looks stupid)
[18:05:42 CEST] <ubitux> BBB: https://continuousassurance.org/
[18:05:51 CEST] <ubitux> we tried this for ffmpeg a while ago
[18:06:06 CEST] <ubitux> and i just received a mail from them about a security issue
[18:06:23 CEST] <ubitux> but all their users are in CC
[18:06:47 CEST] <ubitux> so we have many gov addresses, an fbi one, and some other interesting ones
[18:06:59 CEST] <BBB> hahaha
[18:07:05 CEST] <BBB> thats terrible
[18:07:10 CEST] <ubitux> yes
[18:07:12 CEST] <Gramner> hit reply all a few times to start an epic reply all chain that kills a few mail servers
[18:07:13 CEST] <BBB> wordpress vuln btw
[18:07:25 CEST] <BBB> omg
[18:07:31 CEST] <BBB> like, dont they keep their software uptodate?
[18:09:42 CEST] <kierank> ubitux: lol, yes
[18:09:44 CEST] <kierank> saw that
[18:56:25 CEST] <wm4> oh nice, git rebase now shows the rebase progress in comments when committing while rebasing (must be a new feature of git 2.6 or so)
[19:34:03 CEST] <Timothy_Gu> "michael.e.snowden2.ctr at mail.mil" LOL
[19:58:31 CEST] <Timothy_Gu> Gramner: any more comments on "https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-October/181728.html" :)
[20:30:54 CEST] <Gramner> Timothy_Gu: are you allowed to overread src in that code?
[20:33:16 CEST] <Gramner> if you are, then you could implify the trailing part to read an entire register and just write out parts of it
[20:33:21 CEST] <Gramner> simplify*
[20:40:24 CEST] <Timothy_Gu> Gramner: idk but the original code didn't so I assumed no
[20:40:42 CEST] <Gramner> fair enough
[20:41:48 CEST] <Gramner> ok, should be fine. it'd be nice if you could make a checkasm test though
[20:58:51 CEST] <atomnuker> kierank: I still dislike the eurostar
[20:59:24 CEST] <atomnuker> "Let's make it as close as possible to an aeroplane flight, including all the bad stuff like security and price!"
[21:00:23 CEST] <atomnuker> they even check your passport twice at gare du nord
[21:00:52 CEST] <Plorkyeran> everything but the speed of a plane
[21:01:18 CEST] <atomnuker> like, the booths are less than 25 meters apart in a straight walkway
[21:01:57 CEST] <atomnuker> what's the worst that can happen if you have a gun on the eurostar?
[21:02:13 CEST] <BBB> ...
[21:02:40 CEST] <atomnuker> "I'm derailing this train (with survivors) because I don't know how to control my speed!"
[21:03:05 CEST] <atomnuker> "Only the stewardess cared who I was until I pulled out my gun!"
[21:03:20 CEST] Action: J_Darnley resists the urge
[21:04:36 CEST] <atomnuker> "The passenger list has me, the stewardes and some doctor, but only one of you! First one to talk spares himself a few broken bones and a concussion by not gettin thrown out!"
[21:05:12 CEST] <J_Darnley> Lotta loyalty for a hired cleaner!
[21:05:23 CEST] <atomnuker> Suddenly another eurostar train pulls up on the other side
[21:05:36 CEST] <atomnuker> Must be someone on the inside since the stopped any train on those rails
[21:05:49 CEST] <J_Darnley> *turbulence intensifies*
[21:06:50 CEST] <J_Darnley> "At least you can talk."
[21:07:23 CEST] <J_Darnley> DaMN i MISSED A LINE
[21:07:33 CEST] Action: J_Darnley has fat fingers today
[21:07:47 CEST] <atomnuker> I think another Speed sequel except with a train would be awesome
[21:08:17 CEST] <atomnuker> Speek 4 could explore the dangers of a hijacked submarine
[21:08:21 CEST] <atomnuker> *Speed
[21:08:46 CEST] <Plorkyeran> which somehow plows through an island
[21:08:52 CEST] <atomnuker> There would be no need for a Speed 5 since there already was a Speed knockoff with Liam Neeson on a plane
[21:08:53 CEST] <Gramner> Speed 5: a mars rover
[21:09:00 CEST] <atomnuker> that could work
[21:09:20 CEST] <durandal_1707> starring k. K.
[21:10:58 CEST] <atomnuker> written by Philip K. Dick and directed by Cronenberg
[21:21:41 CEST] <Timothy_Gu> Gramner: ok i'll take a look at it
[21:26:17 CEST] <cone-848> ffmpeg 03Timothy Gu 07master:5e586e1befaa: huffyuvencdsp: Add ff_diff_bytes_{sse2,avx2}
[21:34:28 CEST] <Timothy_Gu> should I add Reviewed-by lines?
[21:35:16 CEST] <jamrial> Timothy_Gu: you didn't push the fixed version
[21:41:12 CEST] <Timothy_Gu> jamrial: wat
[21:41:15 CEST] <Timothy_Gu> oops
[21:43:19 CEST] <cone-848> ffmpeg 03Timothy Gu 07master:98da061461f5: huffyuvencdsp: Cherry pick changes left out in the last commit
[21:43:29 CEST] <Timothy_Gu> ok fixed
[22:02:54 CEST] <pico4743> I'm having problems with mp3 headers written by ffmpeg re:joint_stereo  and I've found the offending place in mp3enc.c, but a repair does not look simple.   Is this the place to discuss this?
[22:04:22 CEST] <J_Darnley> pico4743: if you want to try fixing it yes, people can probably guide you
[22:04:38 CEST] <J_Darnley> If you just want to make a bug report, do that on trac
[22:05:20 CEST] <pico4743> I'm willing to help, but new to your code.  on this one I could get in over my head, methinks
[22:07:29 CEST] <pico4743> I guess I'll start on trac. thanks
[22:08:00 CEST] <J_Darnley> Yes, a bug report is probably a good start
[22:08:30 CEST] <J_Darnley> it lets you post long paragraphs of text with a record of what's been said
[22:09:53 CEST] <pico4743> Am I understanding that trac is a mailing list?  I subscribe and then send email to ffmpeg-trac at avcodec.org?
[22:10:00 CEST] <J_Darnley> no and no
[22:10:09 CEST] <J_Darnley> http://trac.ffmpeg.org/
[22:10:29 CEST] <J_Darnley> oh wait, who owns that domain name?
[22:10:50 CEST] <J_Darnley> oh it redirects to ffmpeg.org
[22:11:13 CEST] <pico4743> no redirect for me.
[22:11:51 CEST] <J_Darnley> The Trac software might send emails from that address.
[22:12:37 CEST] <pico4743> oh, you mean the avcodec.org.  yeah what I was seeing was from https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-trac/
[23:06:29 CEST] <Gramner> http://www.theregister.co.uk/2015/10/21/microsoft_promises_clang_for_windows_in_november_visual_c_update/ that's pretty interesting
[23:06:46 CEST] <nevcairiel> i saw their talk on cppcon, it definitely is
[23:07:03 CEST] <nevcairiel> will have to see about getting ffmpeg to build with that
[23:08:14 CEST] <Gramner> shouldn't be too much of an issue I think, msvc2015 is pretty decent standards-wise and I doubt that would make it worse
[23:08:26 CEST] <nevcairiel> yeah likely just some build system dealing
[23:08:53 CEST] <Gramner> maybe we can finally get inline asm on x86-64 then
[23:11:56 CEST] <nevcairiel> thats one of my hopes as well
[23:12:11 CEST] <nevcairiel> not only that, but also on x86, since msvc doesnt understand the current syntax
[23:13:42 CEST] <kierank> THERE IS A TRAC OUTAGE TONIGHT
[23:13:59 CEST] <kierank> DO NOT COMPLAIN AND SAY YOU WEREN'T TOLD (mumble mumble certain people)
[23:14:12 CEST] <J_Darnley> WHO EVEN USES TRAC?
[23:14:33 CEST] <kierank> I AM TRYING TO MAKE IT REALLY REALLY CLEAR TO certain people (tm)
[23:14:57 CEST] <kierank> The fibre is being rerouted to make way for the Northern Line
[23:15:00 CEST] <wm4> nevcairiel: random question, does buffering dxva2 decoding help? i.e. does it inflict a high latency
[23:15:41 CEST] <nevcairiel> wm4: you mean like keeping a couple frames in a circle buffer before further processing them?
[23:16:01 CEST] <wm4> well, I just read them back to CPU immediately
[23:16:05 CEST] <nevcairiel> (ie. common pipelining)
[23:16:17 CEST] <nevcairiel> you wont like the answer though
[23:16:33 CEST] <nevcairiel> it helps nvidia, hurts intel
[23:16:39 CEST] <nevcairiel> no clue about amd
[23:16:39 CEST] <nevcairiel> :D
[23:16:42 CEST] <wm4> lol
[23:17:17 CEST] <nevcairiel> i think it helps nvidia because they do a DMA for you
[23:17:34 CEST] <wm4> well, I'm not buffering anything (because normally ffmpeg multithreaded decoding does this), so I guess I should add some more threads
[23:17:50 CEST] <nevcairiel> you dont need threads for that
[23:18:05 CEST] <nevcairiel> just keep an array of AVFrames and circle 2 through that
[23:18:35 CEST] <wm4> I see
[23:18:38 CEST] <nevcairiel> that alone can give you a 50% decoding performance boost
[23:19:38 CEST] <nevcairiel> but dont do it on intel gpus, for some reason it makes them slower
[23:19:50 CEST] <nevcairiel> (although not much, while the speedup for nvidia is real)
[23:20:51 CEST] <wm4> why does it hurt intel?
[23:21:03 CEST] <nevcairiel> if i knew
[23:21:32 CEST] <cone-848> ffmpeg 03Tobias Rapp 07master:18e8fac531cb: avfilter/vf_ssim: Add support for writing stats to stdout
[23:21:40 CEST] <nevcairiel> the difference for intel wasnt that big though, maybe 10%
[23:21:52 CEST] <nevcairiel> and their recent decoders are all really fast
[23:25:14 CEST] <nevcairiel> intel also really needs one of those movntdqa custom memcpys to be fast
[23:25:38 CEST] <nevcairiel> well, amd too
[23:26:10 CEST] <BBB> kierank: do you remember that vp9 ticket where the file eats all your memory?
[23:29:29 CEST] <kierank> BBB: https://trac.ffmpeg.org/ticket/4935
[23:30:16 CEST] <BBB> ty
[23:43:18 CEST] <atomnuker> kierank: what's happening with the northen line?
[23:43:42 CEST] <kierank> they are digging near/under the office so the fibre is getting rerouted
[23:43:58 CEST] <atomnuker> so you got like a letter telling you that?
[23:44:10 CEST] <kierank> yes, an email
[23:44:15 CEST] <kierank> I forwarded it to ffmpeg-devel
[23:44:34 CEST] <J_Darnley> Oh I remember seeing that
[23:44:35 CEST] <kierank> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/180554.html
[23:44:47 CEST] <J_Darnley> I didn't put that and this together though
[23:45:26 CEST] <atomnuker> virgin actually give out gigabit fiber too?
[23:45:32 CEST] <atomnuker> they're too big now
[23:45:35 CEST] Action: nevcairiel will giggle in the morning at the outraged comments about how trac was down and noone was told
[23:46:19 CEST] <kierank> atomnuker: it's a virgin point to point link I believe
[23:46:22 CEST] <atomnuker> I bet you need like a special license from the government to even rent out fiber here, let alone host stuff on it
[23:46:28 CEST] <kierank> from the office to our isp PoP
[23:46:54 CEST] <kierank> I don't have a licence
[23:47:16 CEST] <kierank> I have a contract that allows the fibre to pass through the building
[23:48:17 CEST] <kierank> avdev will go down as well (Timothy_Gu might affect you)
[23:48:21 CEST] <kierank> possibly BBB as well
[23:48:25 CEST] Action: J_Darnley loves the monopoly on fibre that got renewed here
[23:50:27 CEST] <atomnuker> I'm not sure how to feel about extending the Northern line
[23:50:56 CEST] <kierank> not sure why the trac server rebooted yesterday
[23:50:59 CEST] <kierank> looks like someone did
[23:51:44 CEST] <atomnuker> I bet this extension was made by the same guys who though it would be a good idea to have the circle line not make a circle
[23:51:59 CEST] <thardin> hrm, that mxfdec patch
[23:55:32 CEST] <kierank> atomnuker: why
[23:55:44 CEST] <kierank> we lack tube connectivity here
[00:00:00 CEST] --- Thu Oct 22 2015