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

[burek]

[00:02:15 CEST] <philipl> wm4: I would just drop it.
[00:02:30 CEST] <philipl> In the mpv case, the user who refuses to upgrade can disable the hwdec in configuration
[00:02:44 CEST] <philipl> By the time 2.8 is released, the driver will have been out for a while.
[00:02:54 CEST] <philipl> Before then, you're expected to know how to take care of yourself
[00:03:49 CEST] <philipl> Worst case you can do a version check through vdpau but that will fail at a later stage and make the fallback hard to do gracefully.
[00:06:22 CEST] <wm4> well, mpv has hw decoding disabled by default, but other software might not be so conservative
[00:06:28 CEST] <wm4> though I don't remember what vlc does
[00:06:46 CEST] <j-b> disabled by default
[00:06:50 CEST] <j-b> it's too broken
[00:07:23 CEST] <j-b> The likelyhood of having correct drivers, correct vdpau version, correct version of libavcodec, corect fork is too small
[00:08:53 CEST] <philipl> That was my impression of most players.
[00:09:09 CEST] <philipl> Kodi defaults vdpau to on but I don't know how much internal version checking they do.
[00:12:51 CEST] <wm4> j-b: and on windows?
[00:12:53 CEST] <wm4> or osx
[00:13:01 CEST] <wm4> aka systems where hw decoding actually works
[00:17:28 CEST] <j-b> wm4: Windows, no, but we're thinking about it
[00:17:43 CEST] <j-b> wm4: iOS and Android, will be defaulted to true, though.
[00:18:26 CEST] <wm4> not like there's a choice
[00:19:55 CEST] <kierank> does cpu decoding really make much of a difference on mobile, say compared to the screen
[00:23:32 CEST] <philipl> My personal experience is that it does.
[00:23:58 CEST] <j-b> kierank: yes. significantly
[00:23:59 CEST] <philipl> You can feel the temperature difference in your hand - never mind that it won't decode in realtime for high resolution/bitrate anyway.
[00:24:18 CEST] <j-b> 4K HEVC on mobile is not hard to do those days
[00:24:32 CEST] <philipl> j-b: you mean in hardware, I assume.
[00:24:45 CEST] <philipl> I know my desktop won't software decode 4K HEVC smoothly :-)
[02:46:31 CEST] <llogan> do we need more FATE machines? perhaps some/any of the proposed donated servers could be used for FATE stuff.
[03:45:33 CEST] <Compn> llogan : better question is who is now maintaining fate machines and servers ?
[03:45:52 CEST] <Compn> the roots i've seen are mostly busy (reimar, beastd)
[03:46:03 CEST] <Compn> i cant even name the other roots because they arent here 
[03:46:04 CEST] <Compn> :P
[03:46:24 CEST] <Compn> michaelni was doing too much
[03:46:30 CEST] <Compn> maintaining a fleet of fate machines
[04:25:35 CEST] <cone-361> ffmpeg 03Michael Niedermayer 07master:d903b62750b3: avcodec/internal: improve min_size documentation for ff_alloc_packet2()
[04:25:35 CEST] <cone-361> ffmpeg 03Michael Niedermayer 07master:e322b7061f87: avcodec/dcaenc: clear bitstream end
[05:08:52 CEST] <llogan> finally, spam for "h.265" chinese cameras. what took them so long?
[05:09:06 CEST] <michaelni> Compn, the fate boxes need relatively little work, also we have some tickets related to fate: https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&keywords=~fate&col=id&col=summary&col=status&col=type&col=priority&col=component&col=version&order=priority
[05:09:45 CEST] <michaelni> but nothing of that is high importance or such
[05:10:17 CEST] Action: michaelni falls asleep
[05:44:14 CEST] <philipl> oooo. hi444pp was enabled in the new driver.
[06:53:39 CEST] <philipl> whoops. The high444p decoder is enabled but there's no support for 444 video surfaces. *sigh*
[07:13:06 CEST] <rcombs> philipl: driver for?
[07:33:44 CEST] <philipl> nvidia linux driver
[09:17:10 CEST] <wm4> philipl: so it decodes to 420?
[10:12:14 CEST] <ubitux> is it possible to return no frame in a hwaccel to wait for another roundtrip (more packets)? (still trying to figure out how to async in vtb)
[10:12:44 CEST] <nevcairiel> not in a hwaccel
[10:12:54 CEST] <nevcairiel> its expected to decode the slice its given and nothing else
[10:13:17 CEST] <nevcairiel> you would need a seperate decoder for that
[10:16:14 CEST] <ubitux> then stupid question; what's the downside of a decoder over an hwaccel?
[10:16:44 CEST] <nevcairiel> that depends how much the API in question does for you
[10:17:08 CEST] <nevcairiel> for one all these extra decoders usually dont export the same amount of metadata as the h264 decoder
[10:17:13 CEST] <nevcairiel> if any at all
[10:17:34 CEST] <nevcairiel> and of course the api needs to offer full bitstream parsing, frame re-ordering and whatnot
[10:17:39 CEST] <nevcairiel> things that the hwaccel doesnt use
[10:19:57 CEST] <ubitux> mmh ok
[10:21:54 CEST] <nevcairiel> its just generally a lot more code
[10:22:04 CEST] <nevcairiel> so unless there is a clear advantage, hwaccel is favorable
[10:22:31 CEST] <nevcairiel> and some APIs, like VDPAU, VAAPI and DXVA2, dont allow anything else anyway
[10:23:09 CEST] <ubitux> ok
[10:23:27 CEST] <ubitux> i'm still pretty confused on how i'm going to achieve a decent speed in the current state
[11:38:15 CEST] <wm4> michaelni: how do I reproduce your benchmark?
[11:49:31 CEST] <michaelni> wm4, assuming iam copy and pasting the right ones: time ./ffmpeg  -threads 1 -i matrixbench_mpeg2.mpg -vcodec huffyuv  -threads 1 -f null -    AND     time ./ffmpeg  -threads 1 -i matrixbench_mpeg2.mpg -vcodec rawvideo  -threads 1 -f null - 
[11:50:10 CEST] <wm4> and matrixbench_mpeg2.mpg is from where?
[11:53:58 CEST] <ubitux> wm4: http://samples.ffmpeg.org/benchmark/testsuite1/matrixbench_mpeg2.mpg
[12:09:16 CEST] <cone-801> ffmpeg 03Shiz 07master:2480da12a41e: configure: Silence error messages when probing compiler.
[12:51:34 CEST] <BBB> is my explanation to that qsv guy so bad?
[12:51:38 CEST] <BBB> or doesnt it make any sense?
[12:51:59 CEST] <nevcairiel> he has understanding problems
[12:52:13 CEST] <nevcairiel> or i just understand your comments because i know how its supposed to work
[12:58:00 CEST] <cone-801> ffmpeg 03Michael Niedermayer 07release/2.7:b1863e3d9484: avcodec/ffv1enc: fix assertion failure with unset bits per raw sample
[13:12:47 CEST] <cone-801> ffmpeg 03Matthieu Bouron 07master:f6518e51b8ed: lavf/mxfdec: support segmented frame layout as separate fields layout
[13:17:41 CEST] <BBB> nevcairiel: the bad thing is that it means after each change he does, well have to re-test seeking (flushing) as well as all these things re: bugs you found
[13:18:00 CEST] <BBB> does kieranks students seek-test help with that?
[14:22:49 CEST] <nevcairiel> i suppose it might actually
[14:27:21 CEST] <cone-801> ffmpeg 03Michael Niedermayer 07master:3f87a1706331: avcodec/dvbsubdec: Allow selecting the substream, or all substreams
[14:31:29 CEST] <ubitux> > Using the file extension .stem.mp4, this single file can be managed just like an mp3 file.
[14:31:34 CEST] <ubitux> what am i reading
[14:33:37 CEST] <wm4> didn't you know? music can be encoded using mp3 only
[14:33:49 CEST] <wm4> using other formats is a novel concept
[14:34:03 CEST] <wm4> and you need to convince users it's as convenient
[14:43:39 CEST] <ubitux> Shiz: thx for the patch
[14:47:17 CEST] <Shiz> np
[15:04:24 CEST] <cone-801> ffmpeg 03Carl Eugen Hoyos 07master:4c4f14c7179c: lavd/v4l2: Use AVSTREAM_PARSE_FULL_ONCE when reading a h264 stream.
[15:04:25 CEST] <cone-801> ffmpeg 03Carl Eugen Hoyos 07master:087c0a0a934a: lavc/dvbsub: Do not fail on clut depth 0.
[15:28:16 CEST] <cone-801> ffmpeg 03Paul B Mahol 07master:63c442e3b1fe: avfilter/avf_showspectrum: reindent
[15:36:29 CEST] <BBB> so if I push a mips patch, should I even bother testing it?
[15:36:44 CEST] <BBB> I mean, I dont have a mips system and I dont think I have a functional qemu setup lying around
[15:36:49 CEST] <wm4> heh
[15:36:55 CEST] <wm4> I'd say trust them
[15:37:03 CEST] <wm4> they're probably the only ones interested in this stuff anyway
[15:46:31 CEST] <iive> doesn't fate have mips systems?
[15:52:33 CEST] <BBB> it probably does
[15:52:46 CEST] <BBB> Id hate to turn it red on my first push since, well, ever
[15:52:56 CEST] <BBB> plus my push isnt working anyway
[15:57:00 CEST] <lglinskih> kierank: now my test compares raw frame's data using tiny_psnr.c, but my ref file is too big (6.3 Mb). And I don't know is it ok...all that I did))
[16:57:09 CEST] <philipl> wm4: No. It decodes to 444 but you can't create a 444 surface for it to write to. If you create a 420 surface and give that to the decoder, you just get garbage on screen, as you'd expect.
[16:58:09 CEST] <wm4> that's... bad
[17:00:38 CEST] <philipl> at least the user visible failure experience is unchanged in practice because we try and fail to create the 444 video surfaces first
[17:02:00 CEST] <kierank> lglinskih: hmm
[17:02:37 CEST] <kierank> lglinskih: I'll be back in 15 mins but I need to see how the psnr thresholds are decided in FATE
[17:05:57 CEST] <BBB> does anyone here regularly push and know how to solve ssh: connect to host source.ffmpeg.org port 2222: No route to host?
[17:06:10 CEST] <BBB> I think I had to chagne a port number somewhere but I forgot how/where
[17:06:38 CEST] <BtbN> .ssh/config?
[17:07:02 CEST] <BtbN> But so far i allways pushed to a videolan URL, and it worked fine.
[17:12:07 CEST] <BBB> whats your git push url?
[17:12:44 CEST] <ubitux> i'm using git at source.ffmpeg.org:ffmpeg
[17:12:54 CEST] <ubitux> and have no problem; but i don't push that often anymore
[17:13:03 CEST] <BtbN> url = git at git.videolan.org:ffmpeg.git
[17:13:18 CEST] <BBB> ubitux: thats what I have, and it doesnt work :(
[17:13:28 CEST] <BBB> do you have any special config in ~/.ssh/config?
[17:13:37 CEST] <ubitux> no
[17:13:38 CEST] <BtbN> propably caused by the server move, try pusing to videolan instead
[17:13:59 CEST] <ubitux> check your /etc/hosts
[17:14:00 CEST] <nevcairiel> BBB: if your ssh tries to use port 2222, then some ssh config is overriding the standard port of 22
[17:15:23 CEST] <BBB> ah indeed
[17:15:27 CEST] <BBB> my .ssh/config is messed up
[17:16:01 CEST] <BBB> let me see if pushing works
[17:16:06 CEST] <BBB> if I screw up, Im really sorry
[17:16:18 CEST] <cone-801> ffmpeg 03Shivraj Patil 07master:dec16372df3a: avcodec/mips: MSA (MIPS-SIMD-Arch) optimizations for VP8 functions
[17:16:29 CEST] <BBB> ok well that worked ok so far
[17:18:09 CEST] <BtbN> i think there are a few hooks in place to prevent the worst screwups
[17:25:22 CEST] <cone-801> ffmpeg 03Philip Langdale 07master:aa10f0aab0e2: avcodec/vdpau_hevc: Remove experimental flag
[17:25:23 CEST] <cone-801> ffmpeg 03Philip Langdale 07master:f038bbd4edd7: avcodec/vdpau_hevc: Properly signal the num_delta_pocs from the SPS RPS
[17:25:24 CEST] <cone-801> ffmpeg 03Philip Langdale 07master:3c8652208b1a: MAINTAINERS: Add myself to vdpau maintainers
[17:25:28 CEST] <lglinskih> kierank: fate can compare values of standard deviation or maxdist between bytes. For each test I can set expected value and "fuzz"
[17:25:55 CEST] <kierank> you should replicate that but I don't know where the "fuzz" numbers came from exactly
[17:42:30 CEST] <lglinskih> kierank: I don't know how to choose "fuzz" correctly, but by default it's 1.
[17:42:35 CEST] <kierank> ok
[17:47:51 CEST] <lglinskih> kierank: so is big size of the ref file ok?
[17:50:04 CEST] Action: kierank tries to find his copy of fate samples
[18:03:05 CEST] <BBB> lglinskih: typically yes, but for that reason we try to keep fate tests - esp. for non-bitexact audio sort stuff - very small
[18:27:45 CEST] <kierank> philipl: bitmoving favourited my troll
[18:32:38 CEST] <wm4> which troll?
[18:35:10 CEST] <kierank> https://twitter.com/obencoder/status/628294591129759744
[18:38:58 CEST] <wm4> right
[18:39:02 CEST] <wm4> I wonder how this makes sense
[18:50:43 CEST] <kierank> ooh got a response
[18:50:47 CEST] <kierank> https://twitter.com/bitmovin/status/628608598508081155
[18:53:29 CEST] <JEEB> because mass-mailing people is not spamming at all...
[19:01:59 CEST] <peloverde> what did they send?
[19:02:16 CEST] <kierank> "Maybe you are interested in testing our encoding service http://www.bitcodin.com , which encodes video 100x faster than realtime,..."
[19:03:25 CEST] <peloverde> wow that's super spammy, I was figuring it was going to be something like "halp with our half baked feature"
[19:06:44 CEST] <wm4> didn't ffmpeg.c have nanomsg support or something similar?
[19:08:47 CEST] <ubitux> wm4: there is a zmq filter
[19:09:02 CEST] <ubitux> and also on the cli you have an input
[19:09:30 CEST] <wm4> right, zmq
[19:09:32 CEST] <ubitux> maybe nanomsg would have been a better idea than ømq 
[19:09:46 CEST] <wm4> dunno
[19:09:56 CEST] <wm4> just looking for inspiration
[19:10:00 CEST] <ubitux> it has limited scope
[19:10:10 CEST] <ubitux> it's just for filter commands
[19:13:48 CEST] <lglinskih> kierank: can you review my new version of test? https://github.com/lglinskih/FFmpeg/commit/077a37ba763e265ed7fede22235a268b3e7dddfa
[19:14:45 CEST] <wm4> a non-ASCII ref file? that seems unfortunate...
[19:15:10 CEST] <kierank> yeah the printf("%c" thing is weird
[19:15:30 CEST] <wm4> maybe it could be done as hex if it has to be this way
[19:18:25 CEST] <philipl> kierank: haha.
[19:20:36 CEST] <lglinskih> kierank, wm4: I've tried to find how it was done in ffmpeg.c, but it always impossible for me (find any example of realization in ffmpeg.c) =/
[19:21:09 CEST] <lglinskih> so doing printf with %x is normal way?) 
[19:24:38 CEST] <wm4> yeah, I think I'd prefer it in hex
[19:25:11 CEST] <wm4> maybe %02x or so would format it correctly (not sure)
[19:25:27 CEST] <wm4> and I don't know what ffmpeg.c does either, but I'm lacking context
[19:26:48 CEST] <wm4> but maybe it's a matter of taste
[19:26:58 CEST] <wm4> do we have existing ref files that are binary?
[19:29:06 CEST] <nevcairiel> non-bitexact tests should just use the fate tools we have for such things, stddev checks or things like that
[19:31:03 CEST] <nevcairiel> how is that not bitexact though? is it a floating point thing or what?
[19:36:24 CEST] <wm4> it's decoded raw data
[19:36:28 CEST] <wm4> doesn't seem ideal either
[19:36:45 CEST] <wm4> lglinskih: I didn't follow this; why remove the hashing and dump the raw data directly to the ref file?
[19:39:32 CEST] <lglinskih> wm4: the main idea is to support non-bitexact codecs. So in that case we should compare frames with some deviation. As I understand crc isn't applicable for that target
[19:40:16 CEST] <wm4> right
[19:40:34 CEST] <nevcairiel> but even non-bitexact codecs should decode to the same frame on every system
[19:40:39 CEST] <nevcairiel> unless floating point or inexact simd
[19:40:42 CEST] <wm4> and apparently ffmpeg.c can do it, but you didn't find out how (I don't know either)
[19:42:00 CEST] <nevcairiel> i dont understand how storing binary data works around the "not bitexact" problem, but a hash of the binary data does not
[19:42:50 CEST] <wm4> hm, I think FATE doesn't do it with ffmpeg.c, but separate utils?
[19:42:59 CEST] <nevcairiel> probably
[19:43:02 CEST] <iive> imho, mpeg2 should always produce the same output using the same idct implementation.
[19:43:13 CEST] <nevcairiel> if framecrc in ffmpeg isnt enough, then it uses external test tools
[19:43:50 CEST] <nevcairiel> tiny_psnr maybe
[19:44:25 CEST] <iive> afair bitexact was introduced in encoders and muxers that use random numbers. (e.g. security while streaming)
[19:48:33 CEST] <lglinskih> hmmmmmmmmmm
[19:49:41 CEST] <JEEB> iive: it's also used for stuff like colorspace conversions where there are non-bitexact SSE(2) paths
[19:49:55 CEST] <JEEB> I remember having to add a bitexact flag to an encoder test
[19:50:05 CEST] <JEEB> because the source was generated in a non-bitexact way
[19:50:33 CEST] <lglinskih> so now my test is able to compare some sort of messy output with small deviation using tiny_psnr.c tool
[19:51:02 CEST] <lglinskih> but for most of codecs I can still use comparing of crcs?
[19:52:20 CEST] <kierank> if it's bitexact yes
[19:52:30 CEST] <kierank> but that's not most I think
[19:55:46 CEST] <nevcairiel> why not
[19:55:58 CEST] <nevcairiel> why would decoding results differ on different systems
[19:56:03 CEST] <nevcairiel> video doesnt often use floating point
[19:56:19 CEST] <nevcairiel> and you can force a specific IDCT to avoid differences there
[20:02:45 CEST] <BtbN> philipl, are you around? Could you have a quick look at https://github.com/BtbN/FFmpeg/commits/master the top three commits basicaly? First two ones are just cosmetic/trivials though.
[20:06:34 CEST] <kierank> nevcairiel, lglinskih: yes you're right - I'm mixing up encoder/decoder mismatch
[20:07:13 CEST] <nevcairiel> some video codec specs are not bitexact
[20:07:15 CEST] <nevcairiel> ie. mpeg2
[20:07:23 CEST] <nevcairiel> but thats a mismatch between different mpeg2 decoders
[20:07:38 CEST] <nevcairiel> avcodec should still be the same at all times =)
[20:11:02 CEST] <wm4> unless it selects an "optimized" idct for some obscure cpu?
[20:11:16 CEST] <BtbN> The twopass vbr seems to work, but i can't see a notable difference.
[20:11:23 CEST] <nevcairiel> yeah you can override the idct choice just in cas
[20:11:25 CEST] <nevcairiel> +e
[20:11:59 CEST] <cone-801> ffmpeg 03Hendrik Leppkes 07master:2ab5002e3cd2: ffmpeg: avoid scanf in keyboard command parsing
[20:12:00 CEST] <cone-801> ffmpeg 03Hendrik Leppkes 07master:99f8fc725de4: ffmpeg: remove access to private FILE struct members on Windows
[20:15:21 CEST] <lglinskih> What is bitexact flag used for?
[20:16:56 CEST] <ubitux> reproducible constant output
[20:17:57 CEST] <ubitux> which means disabling the printing of ffmpeg libs versions in meta of the outputs, or disabling optimizations that plays on architecture approximations, etc
[20:18:17 CEST] <ubitux> anything that would produce different results on different architecture, configuration, or eventually versions
[20:33:45 CEST] <cone-801> ffmpeg 03Henrik Gramner 07master:826790f59640: x86inc: Support arbitrary stack alignments
[20:33:46 CEST] <cone-801> ffmpeg 03Henrik Gramner 07master:f0b7882ceb79: x86inc: Drop SECTION_TEXT macro
[20:43:01 CEST] <BBB> nevcairiel: well, for e.g. scalable video (resolution changes), we invoke swscale before generating the crcs, and thus we depend on swscale being bitexact (which it isn't)
[20:43:10 CEST] <BBB> nevcairiel: I remember that being annoying at some point
[20:43:16 CEST] <BBB> so even video is sometimes not 100% easy
[20:43:22 CEST] <nevcairiel> i guess
[20:43:29 CEST] <nevcairiel> but those cases are known then
[21:21:14 CEST] <nevcairiel> mm i should really just re-do my fate VM entirely and cleanse the old stuff off of it before installing vs2015 on it
[21:22:52 CEST] <nevcairiel> it still has vs2010 installed on it, havent been running that for years :D
[21:23:49 CEST] <jamrial> lol
[21:23:56 CEST] <jamrial> vs2012 is still broken for that matter
[21:24:14 CEST] <jamrial> either whatever's wrong with c99-to-89 (or the lavc code failing the assertion) is fixed, or we just drop vs2012 support altogether
[21:24:45 CEST] <BtbN> I don't see a problem with dropping support for old msvc versions.
[21:25:17 CEST] <nevcairiel> you could beg BBB or wbs to look at it, not that i think they still care much about c99-to-c89, but they would be the ones to fix it
[21:25:46 CEST] <BBB> c99-to-c89 is likely utterly broken
[21:26:27 CEST] <BBB> I havent looked at that code for ages
[21:26:42 CEST] <BBB> wbs: wdyt?
[21:26:57 CEST] <BBB> who else wrote that thing& wasnt it derek also?
[21:27:14 CEST] <wm4> isn't c99-to-89 still useful for the things msvc2015 fails at?
[21:27:46 CEST] <wbs> wm4: no, it isn't useful after msvc2013
[21:28:01 CEST] <BBB> didnt he say 2012?
[21:28:11 CEST] <BBB> jamrial: whats broken?
[21:28:13 CEST] <wbs> wm4: it only does the c99 syntax fixes, like c99 designated initializers and such, it doesn't add any other c99 compat wrapping like fixing printf stuff or so
[21:28:18 CEST] <nevcairiel> BBB: Assertion failed: index_is_unique(&struct_array_lists[rec.parent->data.sal_idx], sai->index), file convert.c, line 1601
[21:28:25 CEST] <nevcairiel> in wmv2enc.c
[21:28:27 CEST] <wbs> BBB: yes, but wm4 asked about use on current versions
[21:28:35 CEST] <BBB> true
[21:28:41 CEST] <wm4> wbs: thinking about the msvc preprocessor handling varargs incorrectly (in general, not in context of ffmpeg)
[21:28:43 CEST] <jamrial> 2012 needs it, but some recent change triggered that assertion in the wmv2 encoder
[21:28:54 CEST] <jamrial> 2013 and newer don't use or need it at all
[21:29:10 CEST] <wbs> jamrial: do you have the really latest version of it? I've fixed some such crash in the last 12 months or so
[21:29:32 CEST] <jamrial> i don't have msvc. i'm looking at the fate client
[21:29:37 CEST] <wbs> ah
[21:29:38 CEST] <jamrial> http://fate.ffmpeg.org/report.cgi?time=20150804165024&slot=x86_32-msvc11-windows-native
[21:29:45 CEST] <nevcairiel> i cant build that thing, so unless someone provides binaries
[21:29:47 CEST] <jamrial> it's nevcairiel's
[21:29:56 CEST] <nevcairiel> its using 1.0.3
[21:30:05 CEST] <wbs> nevcairiel: I think Daemon404 might have done a new release at some point
[21:31:06 CEST] <nevcairiel> 1.0.3 is from december 2014
[21:31:12 CEST] <nevcairiel> only one change is missing in that, apparently
[21:31:58 CEST] <nevcairiel> and that seems unrelated
[21:32:23 CEST] <nevcairiel> i might just drop 2012
[21:33:27 CEST] <wbs> nevcairiel: fwiw, libav still builds just fine with 2010 and 2012; I don't see anything relating to the converter in that build report as such, only that the configure seems to be broken somehow (wrt _BitScanForward and such)
[21:33:40 CEST] <BBB> I dont see any suspcious code in wmv2enc.c as of this year
[21:33:44 CEST] <nevcairiel> i found the problem i think
[21:35:21 CEST] <cone-801> ffmpeg 03Carl Eugen Hoyos 07master:128e722bc101: lavf/swf: Fix auto-detection of compressed files.
[21:35:33 CEST] <nevcairiel> just need to make a build to verify
[21:36:30 CEST] <nevcairiel> suprising no other compiler at least warns about this
[21:36:38 CEST] <cone-801> ffmpeg 03Hendrik Leppkes 07master:bec062e57c11: wmv2enc: remove duplicate priv_class in codec definition
[21:37:07 CEST] <nevcairiel> merge gone wrong, i guess
[21:37:09 CEST] <BBB> -Wshadow?
[21:37:45 CEST] <nevcairiel> i think 2012 is going to work again now :d
[21:37:56 CEST] <BBB> oh I see
[21:38:04 CEST] <BBB> I dont think thats illegal in C
[21:38:09 CEST] <BBB> its incredibly stupid :D
[21:38:16 CEST] <BBB> Im happy for c99-to-c89 to abort on that
[21:38:46 CEST] <BBB> ty nevcairiel 
[21:39:23 CEST] <nevcairiel> guess i will re-install vs2012 on the new vm then
[21:42:22 CEST] <philipl> BtbN: looking now
[21:43:19 CEST] <philipl> BtbN: looks good to me
[21:44:50 CEST] <BtbN> I'm unable to spot any difference though. The encode fps don't change a bit, and the quality looks the same to me.
[21:44:58 CEST] <BtbN> bitrate is also unaffected
[21:45:19 CEST] <philipl> Yeah. But who knows how they implement this stuff under the covers. Might be designing the API for future hardware capabilities
[21:46:03 CEST] <philipl> Best feature in the new nvidia driver release is that it locks up on system resume every time
[21:46:10 CEST] <cone-801> ffmpeg 03Timo Rothenpieler 07master:bef740688d7d: avcodec/nvenc: Fix indentation
[21:46:11 CEST] <cone-801> ffmpeg 03Timo Rothenpieler 07master:3a20e5bc3b8c: avcodec/nvenc: Only set h264 parameter when encoding h264
[21:46:12 CEST] <cone-801> ffmpeg 03Timo Rothenpieler 07master:2ae45816b2f3: avcodec/nvenc: Add support for 2pass rc in vbr mode
[21:46:33 CEST] <BtbN> I gave up on using any kind of suspend/resume entirely.
[21:46:49 CEST] <BtbN> It just causes way too many issues, and a full boot only takes a few seconds anyway.
[21:47:09 CEST] <philipl> Up until this point it's been pretty reliable. It reached a peak before they rewrote their displayport device detection code.
[21:47:13 CEST] <wm4> I've used it for years with nv drivers without issues
[21:47:18 CEST] <philipl> Then it started crashing X if displays were off at resume time
[21:47:21 CEST] <philipl> Now I have this.
[21:47:50 CEST] <wm4> though when my nv card was new, the driver at the time caused random crashes (was fixed after a week or so)
[21:48:03 CEST] <philipl> They do a good job overall, but regressions happen.
[21:48:17 CEST] <philipl> Does anyone have any samples that exercise the weird baseline-only h.264 features?
[21:48:34 CEST] <BtbN> I stopped using open source drivers for nvidia when nouveau phyiscaly killed one of my cards. And the devs just shrugged it of as a known bug that could sometimes cause this.
[21:49:04 CEST] <philipl> BtbN: Progress requires sacrifice.
[21:49:25 CEST] <BtbN> The card was done, wasn't even recognized to be present anymore by the system.
[21:49:59 CEST] <BtbN> Aparently a bug in their reverse engineered firmware, massively overvolting something
[21:50:07 CEST] <philipl> haha.
[21:50:12 CEST] <philipl> But I am sorry for your loss.
[21:50:27 CEST] <BtbN> It was a 30¬ GT card, so not too horrible of a loss. Still annoying
[21:50:41 CEST] <wm4> amazing
[21:50:53 CEST] <philipl> I'm still impatiently awaiting their lowend cards with HEVC. I want to put my 980 back in so I can play Shadows of Mordor.
[21:50:57 CEST] <philipl> Runs like shit on a 970
[21:50:59 CEST] <philipl> 960 I mean
[21:51:09 CEST] <BtbN> 980 doesn't have hevc? oO
[21:51:13 CEST] <philipl> That's normal.
[21:51:21 CEST] <nevcairiel> 960 is the only card with the new decoder so far
[21:51:21 CEST] <wm4> oh there isn't one? how unfortunate since I need to buy a new GPU soon
[21:51:24 CEST] <philipl> They debute new video engines on the mid-range second wave cards
[21:51:35 CEST] <BtbN> Mordor runs great on my 760 though.
[21:51:36 CEST] <philipl> It's like intel tick-tock
[21:51:41 CEST] <nevcairiel> the 950 is coming out soon, it may have the new decoder as well
[21:51:46 CEST] <nevcairiel> no real low-end though
[21:52:03 CEST] <BtbN> i think the gt630 Rev. 2 is the best low-end you can get.
[21:52:05 CEST] <philipl> 950 will have it. but I need a single slot card to be able to fit it into the system as a second card
[21:52:14 CEST] <BtbN> It's already a bit luck if you want a kepler based gt card
[21:52:15 CEST] <philipl> 950 will probably still be two slot
[21:52:25 CEST] <nevcairiel> 950 may be low enough to get some custom single slot designs
[21:52:33 CEST] <nevcairiel> the 750 did at least, and it should be on a similar level
[21:52:46 CEST] <philipl> good point. I shall hope for the best
[21:53:07 CEST] <wm4> I just want something passively cooled
[21:53:11 CEST] <BtbN> I won't get any new cards until i get an entirely new PC
[21:53:16 CEST] <wm4> so it has ot be low-end, I guess
[21:53:19 CEST] <wm4> *to
[21:53:30 CEST] <nevcairiel> passive is rather rare these days
[21:53:33 CEST] <philipl> wm4: passive or silent? water cooled :-)
[21:53:46 CEST] <nevcairiel> although many GPUs come with a hybrid approach, they just turn off the fan until a certain temp is reached
[21:53:52 CEST] <nevcairiel> which you only do when you put 3D load on it
[21:53:59 CEST] <wm4> no fan and no whatever the fuck water cooling would require
[22:00:10 CEST] <philipl> https://www.pugetsystems.com/mineral-oil-pc.php
[22:01:45 CEST] <wm4> fucking hell
[22:02:11 CEST] <llogan> someone needs to get laid
[22:02:40 CEST] <wm4> even the goddamn PSU is in oil
[22:10:47 CEST] <lglinskih> kierank: resume: I should fix an output format (for codecs which uses some floating point values) and add bitexact flag to get the same crcs for non-bitexact codecs. Is it correct?
[22:48:26 CEST] <Daemon404> [20:30] <@wbs> nevcairiel: I think Daemon404 might have done a new release at some point <-- no not yet
[22:48:36 CEST] <Daemon404> https://github.com/libav/c99-to-c89/compare/release-1.0.3...master
[22:48:38 CEST] <Daemon404> the diff is... small
[22:48:53 CEST] <Daemon404> [20:32] <+nevcairiel> i might just drop 2012 <-- yeah i did
[22:48:57 CEST] <Daemon404> pre-c99 msvc is dead to me
[22:51:22 CEST] <philipl> Daemon404: Has microsoft finally shipped a c99 compliant msvc?
[22:51:48 CEST] <nevcairiel> 2013 already worked good enough for ffmpeg
[22:51:55 CEST] <nevcairiel> with a few hacks
[22:52:01 CEST] <nevcairiel> 2015 doesnt even need the hacks anymore
[22:52:13 CEST] <philipl> It only took them 16 years. Good work.
[22:52:21 CEST] <Daemon404> it's not 100% c99
[22:52:24 CEST] <Daemon404> it doesnt support VLAs
[22:52:26 CEST] <Daemon404> but i dont care
[22:52:29 CEST] <Daemon404> cause VLAs are evil
[22:52:32 CEST] <nevcairiel> arent VLAs optional
[22:52:34 CEST] <Daemon404> and you shouldnt use the
[22:52:34 CEST] <philipl> VLAs were downgraded for c11
[22:52:35 CEST] <wm4> philipl: msvc is somewhat c99 compatible; they don't support some C-only things (like the tgmath header), and their preprocessor is broken
[22:52:41 CEST] <Daemon404> nevcairiel, in c11 yes
[22:52:43 CEST] <philipl> Now they're optional.
[22:52:50 CEST] <philipl> Presumably so msvc could be c11 compliant
[22:52:53 CEST] <Daemon404> wm4, tgmath is shit
[22:52:57 CEST] <Daemon404> it should never have been made
[22:53:06 CEST] <wm4> not going to miss it
[22:53:12 CEST] <Daemon404> nobody is
[22:53:25 CEST] <Daemon404> yeah i wish theyd fix their preprox
[22:53:27 CEST] <wm4> but I miss a correct preprocessor
[22:53:28 CEST] <Daemon404> #define E(X) x
[22:53:30 CEST] <Daemon404> ^ msvc bs
[22:53:34 CEST] <Daemon404> s/X/x/
[22:54:18 CEST] <nevcairiel> tgmath is the only part of the c99 stdlib which is missing, which is pretty good
[22:54:24 CEST] <Daemon404> oh boy bitmovin followed me on twitter
[22:54:36 CEST] <Daemon404> even though they found me cause i liked a tweet from kierank mocking them
[22:54:37 CEST] <wm4> nevcairiel: wasn't there something else? but whatever
[22:54:53 CEST] <nevcairiel> "Our C99 Standard Library implementation is complete, except for tgmath.h (which is irrelevant in C++) and the CX_LIMITED_RANGE/FP_CONTRACT pragma macros."
[22:54:56 CEST] <nevcairiel> whatever those macros are
[22:55:42 CEST] <Daemon404> yeah that's cause 2015 had a major crt rewrite
[22:55:44 CEST] <Daemon404> allowing for it ot hapen
[22:55:47 CEST] <Daemon404> happen*
[22:56:12 CEST] <wm4> now I'm waiting for C11 support
[22:56:18 CEST] <nevcairiel> the new printf is nice, it finally warns you for format specifier and var datatype mismatches =p
[22:56:19 CEST] <wm4> I bet they'll never implement stdatomics.h
[22:56:22 CEST] <Daemon404> wm4, does gcc even have it?
[22:56:27 CEST] <wm4> yes
[22:56:32 CEST] <wm4> took a while
[22:56:38 CEST] <Daemon404> there wasn't much in c11 i wanted a lot
[22:56:38 CEST] <BBB> given c99 took 15 years
[22:56:41 CEST] <Daemon404> i can't think of any
[22:56:45 CEST] <BBB> c11 will be done around 2026
[22:56:50 CEST] <wm4> though it's easy to emulate with ancient atomic intrinsics
[22:56:59 CEST] <Daemon404> BBB, it will be done whenever the c11 headers make it to c++
[22:57:05 CEST] <BBB> c99 was equally easy to emulate, wm4
[22:57:16 CEST] <BBB> that was the whole point of c99-to-c89
[22:57:37 CEST] <Daemon404> some bits werent, so they were removed (VLA)
[22:57:39 CEST] <wm4> stdatomic.h requires compiler support, and is useful for C only
[22:57:42 CEST] <wm4> (C++ has its own shit)
[22:57:47 CEST] <BBB> true
[22:57:48 CEST] <wm4> ideal candidate to be ignored by MS
[22:57:50 CEST] <BBB> fortunately we dont use vla
[22:58:03 CEST] <BBB> although its sometimes nice for quick hack tests
[22:58:08 CEST] <Daemon404> we did before msvc support was added, BBB 
[22:58:15 CEST] <BBB> I know
[22:58:18 CEST] <BBB> mru insisted on it
[22:58:20 CEST] <BBB> I dont recall why
[22:58:28 CEST] <wm4> VLAs don't make much sense anyway
[22:58:29 CEST] <BBB> I can only guess some silly arm compiler didnt support it
[22:58:33 CEST] <wm4> either your buffer is bounded or not
[22:58:41 CEST] <wm4> and for both cases there's a good answer what to do
[22:58:45 CEST] <Daemon404> mru is one of those "if it is the standard, i must defend its use"
[22:58:47 CEST] <Daemon404> people
[22:58:57 CEST] <Gramner> the msvc printf stuff rewrite was way overdue, it was hilariously bad before. "Before this refactoring, the sprintf functions, which write formatted data to a character buffer, were implemented by wrapping the result buffer in a temporary FILE object and then deferring to the equivalent fprintf function"
[22:59:21 CEST] <wm4> Gramner: using a temporary FILE object is a good idea
[22:59:32 CEST] <Gramner> it's also slow
[22:59:35 CEST] <wm4> nope
[22:59:45 CEST] <wm4> musl had quite good results with this approach
[23:00:11 CEST] <wm4> of course musl code is all about being compressed and unreadable, but stil
[23:00:12 CEST] <wm4> l
[23:00:24 CEST] <Daemon404> we'll all care about musl when midipix works
[23:00:25 CEST] <Daemon404> and is public
[23:00:26 CEST] <Daemon404> so never.
[23:00:42 CEST] <wm4> snprintf is basically equivalent with the fast path for FILE I/O (you write to the IO buffer)
[23:00:50 CEST] <wm4> midipix is public now
[23:00:58 CEST] <Daemon404> iirc nto rentirely
[23:01:03 CEST] <Daemon404> and not in a feasibly workign state
[23:01:12 CEST] <wm4> the latter is probably true
[23:01:50 CEST] <smarter> Gramner: the part I liked the most in their description: "The CRT provides 142 different variations of printf, but most of the behavior is the same for all of the functions, so there are a set of common implementation functions that do the bulk of the work. These common implementation functions were all defined in output.c in the CRT sources(1). This 2,696 line file had 223 conditionally compiled regions of code (#ifdef, #else, etc.), over 
[23:01:50 CEST] <smarter> half of which were in a single 1,400 line function. This file was compiled 12 different ways to generate all of the common implementation functions. " http://blogs.msdn.com/b/vcblog/archive/2014/06/10/the-great-crt-refactoring.aspx
[23:02:17 CEST] <Daemon404> didnt they also say they were trying to commit to ABI stability for the core crt now
[23:02:20 CEST] <Daemon404> or something
[23:02:21 CEST] <Daemon404> post-2015
[23:02:35 CEST] <nevcairiel> yes
[23:02:41 CEST] <nevcairiel> splitting the crt in two parts
[23:02:47 CEST] <Daemon404> yes that was it
[23:03:07 CEST] <nevcairiel> the VCRuntime which remains compiler dependent (but is small), and the Universal CRT, which is a OS component now and remains stable
[23:03:12 CEST] <Gramner> smarter: maybe they were aiming for IOCCC with the old code
[23:03:15 CEST] <wm4> so when can mingw stop doing the "use an ancient msvcrt" bullshit?
[23:03:26 CEST] <Daemon404> wm4, they never will
[23:03:28 CEST] <nevcairiel> well only windows 10 ships with the new CRT natively
[23:03:45 CEST] <Daemon404> nevcairiel, still mingw should *not* be using msvcrt.dll by default
[23:03:50 CEST] <Daemon404> given vista is the lowest supported os
[23:04:09 CEST] <wm4> lowest supported OS by what?
[23:04:17 CEST] <Daemon404> the vendor itself.
[23:04:22 CEST] <wm4> lol
[23:04:31 CEST] <wm4> I sure wish XP would die
[23:04:58 CEST] <Daemon404> it is dead to me
[23:05:04 CEST] <Daemon404> xp users aren't people
[23:07:08 CEST] <nevcairiel> what I wish I could do is use a newer crt and static link that into a mingw build, like I do with my msvc builds
[23:07:12 CEST] <nevcairiel> but alas, thats not possible afaik =p
[23:07:47 CEST] <Daemon404> as in build with mingw + static crt?
[23:08:18 CEST] <Daemon404> man i remember the good old days of using a sketchy "dll2lib" converter to convert proprietary dll blobs into static libs....
[23:08:23 CEST] <Daemon404> maybe they were the bad old days.
[23:08:34 CEST] <wm4> not sure why you'd care about static linking
[23:08:38 CEST] <wm4> unless maybe for installers
[23:08:56 CEST] <Daemon404> wm4, because i was a stupid teenager?
[23:09:16 CEST] <wm4> well, nevcairiel 
[23:09:27 CEST] <nevcairiel> i dont want to ship the silly runtime dll
[23:09:40 CEST] <Daemon404> nevcairiel, they also discourage that
[23:09:50 CEST] <nevcairiel> its unsupported with 2015, i know
[23:10:18 CEST] <wm4> are you talking about static linking, or shipping the dll?
[23:10:20 CEST] <nevcairiel> static linking is also discouraged, but what can i do, i dont want to stick to ages old dev env just to avoid everyone screaming at me that they dont want to install runtimes
[23:10:23 CEST] <nevcairiel> so i static link :p
[23:10:39 CEST] <Daemon404> nevcairiel, you could embed teh dll as a resoource an load it at runtime
[23:10:44 CEST] <Daemon404> but that's incredibly evil
[23:10:53 CEST] <nevcairiel> app-local deployment (ie shipping the dll just in the folder) is entirely unsupported in vs2015
[23:10:53 CEST] <Daemon404> and probably will be caught as malware
[23:11:01 CEST] <nevcairiel> static linking is discouraged, but still possible
[23:11:21 CEST] <wm4> nevcairiel: so, how are you supposed to ship builds compatible to all windows versions?
[23:11:29 CEST] <wm4> use an old msvc?
[23:11:33 CEST] <Daemon404> wm4, do what games do
[23:11:34 CEST] <nevcairiel> ship the installer to the runtime
[23:11:37 CEST] <Daemon404> they bundke the runtime installer
[23:11:42 CEST] <Daemon404> and integrate it
[23:11:45 CEST] <Daemon404> all video games do this
[23:11:49 CEST] <Daemon404> every time you install a steam game
[23:11:50 CEST] <Daemon404> etc
[23:11:58 CEST] <wm4> so the installer calls the MS runtime installer?
[23:12:07 CEST] <Daemon404> with some flags yeag
[23:12:09 CEST] <BtbN> steam games can just tell steam to make sure some common runtime is installed
[23:12:11 CEST] <nevcairiel> or if you dont need XP support, you can also add a dependency in your manifest file, which will trigger windows update to install it
[23:12:16 CEST] <nevcairiel> although no idea how that really works
[23:12:20 CEST] <Daemon404> BtbN, same idea though
[23:12:21 CEST] <nevcairiel> i just read that its possible
[23:12:22 CEST] <Daemon404> it is silent to the user
[23:14:56 CEST] <nevcairiel> if you happen to use a MSI installer, it also has some magic ways to get the runtime through windows update
[23:15:07 CEST] <nevcairiel> but mostly, just bundle the vcredist installer
[23:15:26 CEST] <BtbN> Which is kind of a problem if you are packaging GPL software.
[23:15:33 CEST] <nevcairiel> as if anyone cares
[23:15:35 CEST] <nevcairiel> just do it
[23:15:35 CEST] <nevcairiel> :p
[23:15:49 CEST] <Daemon404> only one guy cares
[23:16:54 CEST] <nevcairiel> Who would have legal standing to complain? MS? They are not going to block you from building software for your apps. The dev of the app? Well if he doesn't want a windows version, he might use it to screw you, but usually, why would he not want his stuff shipped?
[23:18:13 CEST] <BtbN> It's kind of a dumb rule imo, i don't see what it tries to pretect.
[23:18:55 CEST] <Daemon404> nothing
[23:18:59 CEST] <Daemon404> it's pedantic nerds
[23:19:03 CEST] <Daemon404> and "M$" people
[23:23:31 CEST] <nevcairiel> somehow that reminded me that I wanted to continue looking into moving to LGPL
[23:25:07 CEST] <Daemon404> how would that even matter for you
[23:25:12 CEST] <Daemon404> it's a dshow filter
[23:25:19 CEST] <nevcairiel> companies keep asking
[23:25:33 CEST] <Daemon404> idiot companies?
[23:25:37 CEST] <nevcairiel> the legal situation is probably a bit grey
[23:25:41 CEST] <Daemon404> you sure dont link a dshow filter
[23:26:01 CEST] <nevcairiel> well they cant exactly ship it with their software
[23:26:09 CEST] <nevcairiel> or i dunno
[23:26:10 CEST] <Daemon404> why not
[23:26:15 CEST] <Daemon404> people ship e.g. x264.exe
[23:26:34 CEST] <nevcairiel> i dlopen avcodec with x264 static linked, does that make it ok?
[23:26:56 CEST] <nevcairiel> its the same thing really
[23:26:57 CEST] <Daemon404> who knows
[23:27:08 CEST] <nevcairiel> COM just puts dlopen duties into MS hands
[23:27:13 CEST] <Daemon404> i can write a x264 plugin for adobe premier
[23:27:19 CEST] <Daemon404> who goes after who for what?
[23:27:24 CEST] <Daemon404> it's just a shitty mes.
[23:27:42 CEST] <BtbN> I think the (L)GPL doesn't impose any restrictions on how to ship them.
[23:27:43 CEST] <nevcairiel> anyway, since LAV is like 99.9% all my code, relicensing shouldnt be that impossible
[23:27:49 CEST] <wm4> lawyers make up what's supposed to be acceptable
[23:27:50 CEST] <nevcairiel> just need to track down the 0.1%
[23:27:55 CEST] <wm4> techies don't get to decide
[23:27:58 CEST] <nevcairiel> but i've been lazy
[23:28:08 CEST] <nevcairiel> maybe some company offers to pay for the priviledge
[23:28:15 CEST] <Daemon404> you should ask
[23:28:30 CEST] Action: Daemon404 is reminded of yadif
[23:28:44 CEST] <JEEB> nevcairiel: also you don't have any dead bodies in the 0.1% yet (most probably)
[23:28:49 CEST] <JEEB> so it should be rather painless
[23:29:10 CEST] <nevcairiel> JEEB: i did base some of the code on some old mpc-hc code at the beginning though, need to try to find out if any of that is still left
[23:29:18 CEST] <JEEB> ah
[23:29:33 CEST] <wm4> according to some people, it doesn't matter if nothing is left
[23:29:34 CEST] <nevcairiel> mostly in the splitter, decoders are practically all mine
[23:29:43 CEST] <wm4> it still counts as derived from the original code
[23:29:51 CEST] <wm4> so the original authors still have rights on it
[23:30:17 CEST] <nevcairiel> I learned C from a book, do its authors have rights on all my code now? Its derived from that C knowledge, afterall
[23:30:32 CEST] <wm4> a lawyer would probably say no
[23:30:37 CEST] <wm4> but still insist on the former
[23:32:24 CEST] <nevcairiel> I suppose there is some logic in that, but it never was more than some concepts that i took and re-wrote, but I suppose since I read their code and then came up with mine based on that, it still applies
[23:32:29 CEST] <nevcairiel> nonsense still, but shrug
[23:33:13 CEST] <wm4> don't know, I just read that on some SO post anyway
[23:33:15 CEST] <nevcairiel> I could just replace the license file now and I bet noone would ever complain
[23:33:29 CEST] <wm4> maybe ask j-b, he's almost a license lawyer
[23:33:53 CEST] <nevcairiel> well he clearly doesnt agree, since they did re-license
[23:34:30 CEST] <nevcairiel> which included re-writing some parts of code
[23:35:51 CEST] <wm4> yeah, but not all code
[23:36:14 CEST] <wm4> and they probbaly did the rewrite parts in a lawyer approved way
[23:36:24 CEST] <wm4> which means pretend you didn't look at the replaced code
[23:44:45 CEST] <nevcairiel> i refactored things so often in the early times, that I could probably claim its not even influenced by the original much anymore .. other than knowing it was a bad concept =p
[23:45:09 CEST] <BBB> every time I hear a mplayer dev email on ffmpeg-devel@, I cringe
[23:45:12 CEST] <BBB> am I a bad person?
[23:45:32 CEST] <BBB> I think I start cringing already before Ive opened the email, but with every line I read, my cringing gets worse
[23:45:47 CEST] <BBB> I think my cringing gets worse because of the content of the email but I have not scientifically verified that hypothesis
[23:52:04 CEST] <llogan> IBM claims they will sponsor bounties for fixing issues related to POWER or z systems (they even mention FFmpeg).
[23:52:12 CEST] <llogan> https://www.bountysource.com/teams/ibm/issue_suggestions/new
[23:52:21 CEST] <nevcairiel> do they also send me such a system?
[23:52:53 CEST] <llogan> who knows, but don't ask me to ask them. i tend to never get replies.
[23:52:58 CEST] Action: llogan looks at Linode
[23:53:36 CEST] <llogan> huh, there is some power stuff on fate
[23:53:38 CEST] <nevcairiel> apparently that page sponsors you for  finding and reporting those issues, not necessarily fixing
[23:54:49 CEST] <nevcairiel> they'll probably open individual bounties once found
[23:55:06 CEST] <llogan> ah, here's the current list https://www.bountysource.com/teams/ibm/bounties
[23:57:54 CEST] <BBB> bounties really are the uber of software engineers
[23:58:13 CEST] <BBB> (or lyft)
[00:00:00 CEST] --- Wed Aug  5 2015