[00:15] <llogan> michaelni: thanks [00:25] <lukaszmluki> Hi, question quite peculiar, but do you know any method to test if conversion from AV_PIX_FMT_YUV420P into AV_PIX_FMT_ARGB is bugged? :) [00:27] <lukaszmluki> I test opengl shader, and when i force ARGB format i get A and G components swapped [00:27] <lukaszmluki> at least it looks this wat [00:34] <wm4> it's very unlikely that it's bugged [00:34] <wm4> maybe you're confusing component and byte orders? [00:34] <wm4> it's not always easy to tell with these RGB formats [00:35] <lukaszmluki> i use the same code for all rgb's and this is the only now working [00:36] <lukaszmluki> i don't say its bugged, but i dont see error in my code and wanted to check another posibility :) [00:37] <lukaszmluki> I was hoping ffmpeg allows some doube conversion to check it [00:41] <lukaszmluki> I use av_pix_fmt_desc_get() and offset_plus1 and it returns correct values [00:41] <lukaszmluki> and all other formats are working with it [00:41] <lukaszmluki> ok, thx anyway [00:41] <wm4> I guess pixdesc being wrong is a real possibility [00:41] <wm4> but it's also hard to use [00:42] <lukaszmluki> nah, i debugged it and this part seems ok [00:42] <lukaszmluki> I just try to print alphas now :P [00:51] <lukaszmluki> wm4: BTW, why you dont want to develop devices as (de)muxers? [00:51] <wm4> because the API is not made for this [00:51] <wm4> and you'll have to add weird things to the generic muxer API to make devices non-crappy [00:52] <wm4> it's just a bad hack, and now you want to build on it [00:52] <wm4> bad idea. [00:52] <lukaszmluki> this is right, but on other hand if we add and real muxers ignore it is not end of the world [00:53] <lukaszmluki> i mean muxers dont implement callbacks for devices [00:53] <saste> lukaszmluki, can try with alphamerge or extractplanes [00:53] <saste> uhm no alphaextract [00:53] <wm4> lukaszmluki: that doesn't make it any better [00:56] <lukaszmluki> thx Stefano, will check it. [00:57] <lukaszmluki> wm4: personally i don't have nothing about separation from muxers, but it will big break of current api/approach [00:58] <wm4> maybe so [01:00] <lukaszmluki> saste: but does't it really allow to prove to conversion is ok or corrupted? [01:04] <Timothy_Gu> michaelni: is there a reason why the Libav Git remote is called "qatar"? [01:06] <Compn> makes it easier to grep ? [01:06] <Compn> (hi timothy) [01:06] Action: Timothy_Gu wave hand [01:07] <Timothy_Gu> compn: maybe... [01:07] <Compn> is there a reason ubuntu ships an 'ffmpeg' package for years and years ? [01:07] Action: wm4 suspects it was because the existence of Libav couldn't be acknowledged or accidentally be spread [01:08] <Compn> which is actually libav package [01:08] <Compn> and an outdated ffmpeg binary that says its deprecated ? [01:09] <wm4> yes, there's a reason: the debian maintainers are also Libav devs [01:09] <Timothy_Gu> compn: well, if I am Libav, and I want to get rid of the ffmpeg.c cruft with unwanted stuff, I'd call it 'deprecated' [01:10] <Timothy_Gu> compn: for the reason ubuntu still ships ffmpeg package, is because the fear that removing that would break millions of blog posts, shell scripts, etc. etc. [01:10] <Compn> but the message is the entire ffmpeg program is deprecated [01:10] <Compn> not any particular piece of cruft [01:10] <Timothy_Gu> compn: it is for Libav [01:10] <Compn> also if you wanted to get rid of cruft, why git rename ffmpeg.c avconv.c in the first place :p [01:12] <Compn> hilarious circular logic, its deprecated , why ship it? because it would break things. its breaking things already. well its in transistion. for 3+ years? [01:12] <wm4> the main reason ffmpeg.c printed deprecated on Libav was because avconv.c was not a direct replacement [01:12] <wm4> but slightly different command line semantics or something [01:13] <wm4> but even if that is right, it sure was a clumsy move [01:13] <Compn> its like breaking the wheels on your car and then building another car you have to learn how to drive again [01:13] <Compn> and then trying to sell the broken car [01:13] <wm4> I mean it was clumsy PR-wise [01:14] <wm4> I really hate ffmpeg CLI [01:14] <wm4> I can never get it do what I want [01:14] <Compn> you like mencoder better? admit it! [01:14] <wm4> and I frequently make it overwrite my input files [01:14] <Compn> i ... admit i overwritten a input sample file the other day :( [01:14] <wm4> well, mpv's encoding functionality has mencoder compatible options AFAIK [01:14] Action: Compn inserts grammar into that sentence [01:15] <Timothy_Gu> wm4: I always found it weird why mpv has encoding feature [01:15] <Compn> wm4 : it actually can encode things, not just vaporware ? [01:15] <wm4> Timothy_Gu: me too, but why not [01:15] <wm4> Compn: yes [01:15] <Compn> neat [01:16] <wm4> but it uses ffmpeg, there's not a single line of mencoder code in there [01:16] <Compn> i never would suggest that :) [01:16] <Timothy_Gu> wm4: what advantage does that have over ffmpeg.c [01:17] <Compn> Timothy_Gu : it doesnt overwrite his input files ? [01:17] <Compn> :P [01:17] <wm4> this [01:18] <wm4> Timothy_Gu: for a serious reply, you'll have to ask divVerent [01:18] <Timothy_Gu> wm4: in #mpv ? [01:19] <wm4> no, that channel is inhabited by pokemon fans [01:19] <cone-200> ffmpeg.git 03Diego Biurrun 07master:14abeaa43d02: build: Separate building programs linking against libav* from building av* [01:19] <cone-200> ffmpeg.git 03Michael Niedermayer 07master:5ded4332f195: Merge commit '14abeaa43d021afdce9119d906891abe89c03b88' [01:19] <wm4> we're in #mpv-player [01:19] <Compn> wm4 : at least you have good company :P [01:19] <Compn> ohhh [01:19] <Compn> :P [01:20] <Timothy_Gu> Any ideas about elenril's vdpau patch (or commit, rather) to ffmpeg/avconv? [01:20] <Timothy_Gu> Why does it like duplicates so many lavc code? [01:20] <wm4> it's not supposed to be fast, but for testing [01:20] <wm4> it does? [01:21] <Compn> reimar said it would be nice as a decoder, instead of hardcoded in ffmpeg.c [01:21] <Compn> i think [01:21] <wm4> like this vda thing? [01:23] <Timothy_Gu> Why does lavc have a special HWAccel infrastruct? Why don't we just make them like a normal codec? [01:23] <Compn> so we can fallback to normal codecs if they fail ? [01:23] <Timothy_Gu> compn: yeah [01:23] <Compn> really i have no idea [01:23] <Compn> i just make things up and cause trouble :) [01:24] <wm4> I have no idea either [01:24] <Compn> ask carl :) [01:24] <wm4> for fallback, and because it's Better(tm) [01:24] Action: Compn waves to carl [01:24] <wm4> but uh, I'm doing my own fallback anyway [01:24] <wm4> because lavc's didn't work until recently [01:25] <wm4> Compn: these movtext subtitles contain weird things like "cc608:AAAAEcX//JQm/YCA/wMi/oj//gAA0.000" [01:25] <Compn> wm4 : some kind of encoding, no doubt [01:26] <Timothy_Gu> If so that would save VLC & MPlayer and family (& ffmpeg.c) so many code [01:26] <wm4> and the duration of each sub packet is only 30ms [01:26] <wm4> Timothy_Gu: fallback isn't much code [01:26] <Compn> Timothy_Gu : i've always asked if ffmpeg could include all the vdpau glue code so we can eliminate and combine forces with vlc and mplayer :) [01:27] <wm4> Compn: what do these subs look like in flash player? [01:27] <Compn> wm4 : like closed captioning [01:27] <Compn> "CEA-608", used to be the standard for closed captioning for NTSC TV broadcasts in the United States, [01:27] <wm4> Compn: vdpau is not easy because decoding and display depend on each other, basically [01:27] <Compn> "cc608" [01:27] <Timothy_Gu> compn: but why didn't ffmpeg do that [01:27] <wm4> Compn: and what does it look like [01:27] <wm4> Timothy_Gu: because things are not as simple [01:28] <Compn> wm4 : dont you have quicktime installed ? [01:28] <wm4> no [01:28] <Timothy_Gu> wm4: that is a concise answer [01:28] <Compn> wm4 : black bg, white text [01:29] <wm4> Timothy_Gu: the long version would require explaining how vdpau works [01:29] <Compn> Timothy_Gu : i dont know. libav devs removed a lot of glue code and libcode from ffmpeg [01:29] <Compn> and apis... [01:29] <wm4> Compn: uh, so, they just dumped CCs into a mov_text track? [01:29] <Compn> like libxvid etc [01:29] <Compn> wm4 : no, thats how dumb apple encodes its closed captions > http://documentation.apple.com/en/finalcutstudio/workflows/index.html#chapte... [01:29] <Timothy_Gu> wm4: and what about va-api? [01:30] <Compn> in mov [01:30] <wm4> Timothy_Gu: same issue... and also dxva and vda [01:30] <wm4> Compn: also, vlc knows to error out correctly [01:30] <wm4> and doesn't interpret it as movtext [01:31] <Compn> its mov_text , just a diff type of ... parsing that mplayer doesnt have [01:31] <Compn> like utf characters [01:31] <Compn> represented in /abc/def i think [01:31] <wm4> Timothy_Gu: the main problem is that you just have to share the hw device handle with lavc [01:32] <wm4> maybe lavc could handle some more aspects of hwaccel api usage, but the basic problem is the same [01:32] <Timothy_Gu> wm4: why are all hwaccels so stupid? [01:32] <Timothy_Gu> wm4: why are all hwaccels API's so stupid? [01:33] <wm4> dunno, but I'd say they're not as bad as opengl (which has an implicit context etc.) [01:33] <Compn> Timothy_Gu : because nvidia made vdpau ? [01:33] <wm4> the only really bad thing about vdpau is preemption [01:33] <Compn> and they wrote the patches for ffmpeg... [01:33] <Compn> (and mplayer) [01:34] <Compn> (everyone blames mplayer) [01:34] <wm4> yeah... mplayer's craptastic internals might actually have contributed to ffmpeg's hwaccel api being so low level [01:34] <Compn> lol [01:34] <wm4> but the "real" hwaccel still came later [01:34] <wm4> so you can still blame ffmpeg plenty [01:35] <wm4> lu_zero on libav actually wants to improve the hwaccel api [01:35] <llogan> Timothy_Gu: it's called qatar because they claimed to have moved to qatar or something [01:35] <llogan> http://misc.socialbladeshow.com/afd/screenshots/10781-l.jpg [01:35] <Compn> the qatar thing was an april fools joke, a few years back, iirc [01:36] <Timothy_Gu> llogan: that's weird [01:36] <wm4> lol [01:36] <Timothy_Gu> wm4: that's nice... as long as they don't ABI anymore [01:36] <llogan> Timothy_Gu: i won't be able to look at your web patches for at least another day or two. i just had some hardware failure to deal with... [01:37] <wm4> Timothy_Gu: if they do it, it will be a 100% API break [01:37] <Timothy_Gu> Gotta go [01:39] <Compn> wm4 : stupid links in apple documentation are 404 :\ [01:39] <Compn> llogan : did you do a scan of ffmpeg website for broken links ? [01:39] <llogan> not for a long time [01:39] <Compn> someone should do that [01:40] Action: Compn volunteers to be lazy [01:41] <iive> there must be a script of project that does it. [01:42] <Compn> yes the w3c validator does it [01:42] <Compn> if you want to run it iive :) [01:43] <iive> i have no idea what that is... sounds painful. [01:43] <Compn> timothy worked a lot on the undocumented options in ffmpeg [01:43] <llogan> Compn: by now you could have validated at least one page [01:45] <BBB> ok well that was a silly bug [01:45] <Compn> http://validator.w3.org/checklink [01:45] <Compn> llogan : ok, running now [01:47] <Compn> http://americancensorship.org/images/stop-censorship-small.png is 404 [01:48] <Compn> heh [01:48] <Compn> bunch of soc urls are dead [01:49] <Compn> one mphq mailing list post is 404 [01:50] <wm4> ? [01:50] <wm4> how does this happen? [01:53] <Compn> ml gets rebuilt once in a while [01:53] <Compn> the numbers all change [01:53] <Compn> link to old number > 404 [01:54] <Compn> file a bug with mailman [02:13] <lukaszmluki> i'm an idiot :) [02:14] <cone-200> ffmpeg.git 03Diego Biurrun 07master:ab81f24ad43b: build: Integrate multilibrary examples into the build system [02:14] <cone-200> ffmpeg.git 03Michael Niedermayer 07master:6d34aa245df8: Merge commit 'ab81f24ad43bddf77ddd25cba86780c1c884996c' [02:14] <cone-200> ffmpeg.git 03Michael Niedermayer 07master:325c918fa3d6: Makefile: Fix building progs out of progs_g [02:14] <cone-200> ffmpeg.git 03Michael Niedermayer 07master:f1db007e008d: doc/Makefile fix PROGS [02:15] <lukaszmluki> spending whole night to figurei swapped columns with rows of the matrix [02:19] <BBB> hm the scalability of this thing isn't fantastic [02:19] <BBB> 9.7 -> 6.0 for 1 -> 2 threads, but only 6.0 -> 5.2 for 2 -> 4 threads :( [02:19] <BBB> the 2-pass really is hurting [02:55] <cone-200> ffmpeg.git 03Diego Biurrun 07master:5145ccf02b17: aacsbr: Add some const casts to silence warnings in ff_sbr_apply() [02:55] <cone-200> ffmpeg.git 03Michael Niedermayer 07master:a9a3afec1a9c: Merge remote-tracking branch 'qatar/master' [03:12] <llogan> michaelni: if the current crop of spam filters is working adequately then i don't think we'll need more if they slow down trac (i'm not sure if the current ones do or not). [03:13] <llogan> also we can contact http:bl to periodically download the DNS zone file instead of querying the remote DNS server each time if it causes slowness. [03:14] <michaelni> feel free to close the ticket in that case (and reopen if the spam issue seems not resolved at a later point) [03:14] <michaelni> about slowness, no idea, did you notice a slowdown ? [03:15] <llogan> no, but i haven't really done much with trac since [03:15] <llogan> just thinking out loud... [03:15] <michaelni> also note that there are 2 threasholds and when the score is above them then external services wont be contacted [03:15] <michaelni> for a submission [03:16] <llogan> ok. i'll wait a few days to a week and if things seem good i'll close ticket unless you do first [09:01] <plepere> aaaaarg. why does asm hate me so much ? [09:02] <plepere> doing a call <function> gives me a seg fault [09:02] <plepere> call put_hevc_mc_pixels_2_8 wroks [09:02] <plepere> but call put_hevc_epel_v_8_8 [09:02] <plepere> does not [09:02] <plepere> *works [09:03] <plepere> both functions are fully functional [09:03] <plepere> doing the call after the function declaration [09:13] <kurosu> calling convention changes across abis [09:13] <kurosu> ie whether an arg is in a reg, and what regs, and what order of regs [09:13] <kurosu> plepere: http://en.wikipedia.org/wiki/X86_calling_conventions#Microsoft_x64_calling_c... [09:14] <kurosu> I prefer avoiding doing calls if possible, but I know this bloats code [09:15] <kurosu> also, are you doing work/reserving space on the stack and are you restoring it properly ? [09:15] <kurosu> anyway, afk [09:15] <plepere> hmm [09:15] <plepere> it's working on a function with 6 arguments [09:16] <plepere> so you're saying that if I call a function, I should manually load the arguments from the stack to the registers beforehand ? [09:18] <plepere> thanks anyway. :) [09:20] <ubitux> plepere: it depends. [09:20] <plepere> I found the error. I'm apssing too many arguments [09:20] <plepere> *passing [09:21] <ubitux> also, can't you avoid the call with macrotization? [09:22] <plepere> ubitux : I'm having different functions for different levels of optimisation depending of width size. I'm testing the width to see which function to call. [09:22] <plepere> in the end, we will probably go through pointers directly, but at the moment, it's simpler for the higher-levels [09:23] <ubitux> ok [09:31] <plepere> if using macros can help, then I'm ready to do it, but I never used macros before. [10:00] <cone-395> ffmpeg.git 03Stefano Sabatini 07master:4c4710a745ae: configure: define CONFIG_THIS_YEAR at the configure level [10:35] <ubitux> i see some more complains about restoring hall of fame [10:35] <ubitux> shame* [10:37] <cone-395> ffmpeg.git 03Stefano Sabatini 07master:8bf7ea8ac210: cmdutils: remove this_year constant, use CONFIG_THIS_YEAR instead [10:53] <ubitux> BBB: what is this 2 pass thing? [11:34] <oden> hello. trying to understand what security fixes has been fixed in 0.10 since 0.10.6 to 0.10.10. http://ffmpeg.org/security.html does not say. [12:24] <michaelni> oden, ill try to update the page, but 0.10 is quite old [12:25] <cone-395> ffmpeg.git 03Kostya Shishkov 07master:de44dfc7c0ec: vc1: Reset numref if fieldmode is not set [12:25] <cone-395> ffmpeg.git 03Michael Niedermayer 07master:0290a646ac66: Merge commit 'de44dfc7c0ec02bda7d846ef713145c890bfae3f' [12:33] <BBB> ubitux: evil stuff [12:33] <ubitux> can you summarize the concept? [12:33] <BBB> ubitux: remember bw probability updates? i.e. where one frame's distribution helps update the prob tables for the next frame? [12:34] <cone-395> ffmpeg.git 03Kostya Shishkov 07master:56d061ce9da9: metasound: add last missing modes (8kHz @ 6kbps per channel) [12:34] <cone-395> ffmpeg.git 03Michael Niedermayer 07master:ac021fdc4063: Merge commit '56d061ce9da954560892e3551513d5ecc0439846' [12:34] <ubitux> BBB: ok, yes [12:34] <BBB> let's say yes [12:34] <BBB> so this means I can't start the next frame until the previous frame has updated its prob tables [12:35] <BBB> else I'll get garbage [12:35] <ubitux> oh ok [12:35] <BBB> so I can't do interleaved mode decoding and reconstruction [12:35] <BBB> because then I can only start the next frame when the prev frame is done [12:35] <BBB> which is not very helpful [12:35] <BBB> so we do 2pass decoding [12:35] <BBB> pass 1: bitstream parsing (i.e. decode_mode only) [12:35] <BBB> pass 2: everything else (recon_inter/intra and loopfilter_sb) [12:36] <ubitux> i see [12:36] <ubitux> you were mentioning samples in "threading" mode, so i guess with a different prob update method? [12:42] <BBB> ubitux: yeah, that uses fw only, so we can do what vp8 did [12:42] <BBB> ubitux: but I have no samples for that, so no idea if it works at all [12:57] <cone-395> ffmpeg.git 03Kostya Shishkov 07master:a16577d98572: MSN Audio support [12:57] <cone-395> ffmpeg.git 03Michael Niedermayer 07master:8c87658fdc65: Merge commit 'a16577d9857206089fd8bce6a342b31dbd7fb9b0' [12:57] <cone-395> ffmpeg.git 03Michael Niedermayer 07master:cd51d9a98403: Revert "avcodec/gsmdec: reject unsupported msn audio modes" [13:11] <cone-395> ffmpeg.git 03John Stebbins 07master:1eaac1d6f7bb: mpeg12dec: Extract CC user data into frame side data [13:11] <cone-395> ffmpeg.git 03Michael Niedermayer 07master:625b29037e52: Merge commit '1eaac1d6f7bb8e52d82e1a114c88a59a9a8e5025' [13:12] <oden> michaelni: thanks. [13:19] <mraulet> michaelni:https://github.com/OpenHEVC/FFmpeg/commit/211c39ade87bc079eabc862a6b684544dc... [13:19] <mraulet> fix valgrind [13:21] <cone-395> ffmpeg.git 03Anton Khirnov 07master:c6080d890090: lavc: remove mp3_header_(de)compress bitstream filters [13:21] <cone-395> ffmpeg.git 03Michael Niedermayer 07master:75ec40b083ff: Merge remote-tracking branch 'qatar/master' [13:27] <cone-395> ffmpeg.git 03gcocherel 07master:3c846fda1ca3: HEVC : valgrind fix : vps_list [13:27] <michaelni> mraulet, applied, thanks [13:43] <BBB> ubitux: want to help amending patches? I'll only have time this weekend [13:44] <BBB> babies fuss too much to be able to do anything right now [13:44] <ubitux> i'm not really available currently [13:45] <ubitux> i mean, it doesn't look like it, but i have a job too :( [13:50] <BBB> lol :) but I have kids [13:51] <BBB> anyway I'll update this weekend or so [14:13] <BBB> ubitux: ok fixed the indent and missig alloc check on github [14:14] <ubitux> i'll try to have a look tonight [14:14] <ubitux> it's not a RFC btw right? [14:14] <ubitux> it's complete? [14:26] <smarter> ubitux: I think you can generate samples without backward probability updates using vpxenc --frame-parallel=1 [14:27] <smarter> also I guess you could combine tile-mt and frame-mt to decode the modes faster? [14:29] <ubitux> mmh ok [14:29] <ubitux> speaking of libvpx [14:29] <ubitux> i should test for the annoying encoding bug with vp8 [14:29] <ubitux> with libvpx itself [15:10] <plepere> I remember someone posting an example of calling a C function from asm here, but I can't get my hands on it. :/ [15:13] <ubitux> cd libavcodec/x86 [15:13] <ubitux> git grep call [15:14] <plepere> why git ? [15:16] <plepere> anyways, it works. thank you [15:25] <ubitux> plepere: because git grep rox ofc [15:25] <plepere> yes, found out that git grep is unrelated to git .:p [15:26] <nevcairiel> calling C functions from asm is problematic in many cases though, so make sure you really need it [15:26] <ubitux> plepere: it is. [15:26] <plepere> nevcairiel : it's for a slow pass. [15:27] <plepere> ubitux, ok, I give up T_T [15:27] <nevcairiel> emulating all the calling conventions between win64, win32 and linux is just a bit complicated :d [15:27] <plepere> ok ok [15:29] <plepere> r7d is a byte ? [15:29] <nevcairiel> d is double-word, 32-bit [15:29] <plepere> so w is 16 [15:58] <michaelni> oden, security page updated, ill add CVE# where they are missing as soon as they are assigned [16:10] <oden> michaelni: thanks. so 0.10.10 has no sec flaw fixes? [16:24] <michaelni> oden, there where some things backported that may or may not be security relevant, for example a infinite loop fix, also there was some fixes merged from libav that i belive where redundant and fixed previously. also i dont think any ffmpeg version or fork from the 0.10 times is completely free of security issues [16:24] <ubitux> does anyone know if anton has me in ignore list? [16:27] <av500> on irc? [16:30] <ubitux> yes [16:31] <ubitux> i raised a bug in the hwaccel yesterday and provide him an avconv backtrace but he didn't react [16:31] <ubitux> and i asked something about arm offsets after the mpegcontextenc update he did [16:31] <oden> michaelni: ok. thanks. it's quite difficult to tell these days. [16:33] <michaelni> oden, yes, iam aware of that, ill try to keep the security page more upto date in the future [16:34] <ubitux> av500: maybe i'm wrong about the arm offsets so he thought it didn't matter to answer me, but if i'm right he might be interested about it [16:34] <oden> michaelni: great. [16:36] <ubitux> av500: well it seems he actually ignores me, so feel free to forward my hwaccel backtrace from the other day and the arm offset thing [16:47] <ubitux> well i guess i should stop reporting them bug & fixes [16:47] <ubitux> it seems it's still seen as a "you show us than ffmpeg is better than libav" [16:47] <ubitux> &like i would try to demonstrate something we know since years& [16:47] <ubitux> whatever [16:48] <ubitux> </rant> [18:18] <cone-395> ffmpeg.git 03Stefano Sabatini 07master:7de3b1394b71: lavd/sdl: add event handler thread [18:19] <cone-395> ffmpeg.git 03Stefano Sabatini 07master:7467b4f71b4b: lavd/sdl: factorize overlay rect size in a separate function [18:19] <cone-395> ffmpeg.git 03Stefano Sabatini 07master:0464d272ff9d: lavd/sdl: move compute_overlay_rect() before event_thread() [18:19] <cone-395> ffmpeg.git 03Stefano Sabatini 07master:b23dea27fdb6: lavd/sdl: allow to change window size [18:19] <cone-395> ffmpeg.git 03Stefano Sabatini 07master:35349bbb97eb: lavd/sdl: apply misc cosmetics to options [18:39] <cone-395> ffmpeg.git 03Stefano Sabatini 07master:704331196910: lavd/sdl: add delay when no events are found in the event queue [20:19] <llogan> the new trac looks nice [20:20] <llogan> especially stuff like `-option` in the wiki [20:30] <Timothy_Gu> llogan: what do you mean? What's the `-option? [20:31] <llogan> that's WikiFormatting markup for "monospace" font style [20:32] <llogan> http://trac.ffmpeg.org/wiki/WikiFormatting#FontStyles [20:32] <llogan> previously it was not as easy to see a difference between the normal text and the monospace text which i used to differientiate options and commands [21:49] <Timothy_Gu> Is cone-* ("irker irc client") related to VLC? [21:51] <JEEB> it's a bot hosted by VideoLAN, the git repository is currently hosted by VideoLAN as well [21:51] <JEEB> VideoLAN provides such services for various projects [21:56] <Timothy_Gu> JEEB: then why did it quit? [21:57] <Timothy_Gu> JEEB: http://naevis.jbkempf.com [21:57] <Timothy_Gu> JEEB: "Chaussure" down? [21:58] <JEEB> ask that from videolan? [00:00] --- Wed Nov 27 2013