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

[burek]

[00:03:20 CET] <cone-618> ffmpeg 03Ganesh Ajjanagadde 07master:b8e19808071c: avfilter/vf_ssim: use log10 instead of log()/log(10)
[00:04:15 CET] <nevcairiel> Daemon404: turns out mingw doesnt define SECBUFFER_ALERT, thats why i had the define in there
[00:06:50 CET] <cone-618> ffmpeg 03Ganesh Ajjanagadde 07master:b45daad2aa34: ffmpeg: use log10 instead of log()/log(10)
[00:12:39 CET] <cone-618> ffmpeg 03Ganesh Ajjanagadde 07master:0fe5dcd66041: avfilter/avf_showvolume: use log10 instead of log()/M_LN10
[00:14:46 CET] <cone-618> ffmpeg 03Ganesh Ajjanagadde 07master:b7fb7c4542af: avutil/mathematics: make av_gcd more robust
[00:19:25 CET] <Daemon404> nevcairiel, lul.
[00:22:05 CET] <nevcairiel> wbs: thanks for the review, i've addressed all comments and pushed a revised (and rebased) version
[00:42:52 CET] <BBB> I feel that my reviews are completely and utterly useless
[00:42:55 CET] <BBB> I ask a very specific thing
[00:42:58 CET] <BBB> and its just not done
[00:42:59 CET] <BBB> :(
[00:43:49 CET] <nevcairiel> then bikeshed it and block submitting until it is
[00:43:54 CET] <nevcairiel> =p
[00:44:12 CET] <BBB> I thought I did
[00:44:22 CET] <BBB> and he just pushed it saying I didnt feel like doing it"
[00:44:48 CET] <nevcairiel> thats not acceptable behavior
[00:45:15 CET] <nevcairiel> if you dont agree, you can always argue your point, but just discarding feedback and pushing anyway is just wrong
[01:00:43 CET] <wm4> well...let's be more careful when giving push rights to someone (point taken)
[01:05:06 CET] <Plorkyeran> nope gotta give push access to everyone that can figure out how to use git and has something to push
[01:08:02 CET] <michaelni> I suggested ganesh to join IRC, if he does, maybe that would help communication
[01:08:55 CET] <jamrial> pushing even though he got a negative review is not good at all
[01:10:28 CET] <michaelni> yeain... but maybe this is just a misunderstanding
[01:10:49 CET] <michaelni> iam not sure i cant know of course ...
[01:12:24 CET] <michaelni> also i approved some of the patches so blame falls on me too for adding to the confusion
[01:15:56 CET] <BBB> I dont disagree with the approval
[01:15:59 CET] <BBB> I think the patches were fine
[01:16:11 CET] <BBB> I just asked that for each affected file, we confirm libavutil/libm.h is included
[01:16:17 CET] <BBB> Im not too worried about ffmpeg.c or vf_*.c
[01:16:29 CET] <BBB> Im worried about the more weird edge-cases in the corners of our codebase
[01:16:31 CET] <nevcairiel> (the answer btw is: it isn't)
[01:16:44 CET] <BBB> a user doesnt care if which file blows up his compilation
[01:16:55 CET] <BBB> _any_ file that blows up compilation is equally annoying for users that cannot code
[01:16:59 CET] <BBB> they expect quality from us
[01:17:12 CET] <BBB> its not hard to verify, it takes a minute or less per file, and the number of affected files was well below 20
[01:17:20 CET] <BBB> it probably takes 5 minutes in total
[01:17:33 CET] <BBB> and if its missing somewhere, you just saved a user an incredibly annoying headache
[01:18:01 CET] <nevcairiel> from a quick look, at least the 3 changes that now use log2 are broken on soem systems
[01:18:08 CET] <nevcairiel> log10 doesnt seem to have that same problem
[01:18:08 CET] <BBB> :(
[01:23:19 CET] <wm4> lol
[01:23:32 CET] <wm4> called it
[01:25:48 CET] <cone-618> ffmpeg 03Carl Eugen Hoyos 07master:2f1d6d45af42: lavc/cdg: Add transparency support.
[01:26:46 CET] <michaelni> nevcairiel, which file broke ?
[01:26:54 CET] <michaelni> snowenc.c contained log2 before
[01:27:54 CET] <nevcairiel> i didnt see that avutil/common.h also includes internal.h because its hidden under some evil ifdef .. it didnt make sense to me since common.h is installed and internal isnt
[01:30:05 CET] <michaelni> if i intentionally break libm.h then libavcodec/zmbvenc.c fails build so it must be incuded there too
[01:30:45 CET] <michaelni> same for nellymoserenc
[01:31:48 CET] <nevcairiel> like i said, I only had a very brief look, and didnt notice that common.h includes internal.h under some ifdef, and I didn't look much closer because installed headers usually dont include private headers .. but this one does :)
[01:32:33 CET] <nevcairiel> in any case, that nothing actually broke is just luck, and not the point
[01:33:36 CET] <nevcairiel> and I'll go sleep now, i actually have to work in the morning!
[01:34:35 CET] <cone-618> ffmpeg 03Carl Eugen Hoyos 07master:bd1d67efe830: lavc/proresdec2: Fix slice_count for very high resolutions.
[02:43:07 CET] <cone-618> ffmpeg 03Michael Niedermayer 07master:a7af002b5f4c: avformat/oggparseogm: Enable parser for mpeg4
[03:07:53 CET] <canaar> In ffserver.c, in the function close_connection(HTTPContext *c) , what does http://pastebin.com/fWRwAnBq this exactly do?
[04:04:29 CET] <cone-618> ffmpeg 03Michael Niedermayer 07master:203dc14693c6: avformat/3dostr: Remove redundant ;
[04:04:30 CET] <cone-618> ffmpeg 03Steven Robertson 07master:b38e685c0537: vf_lut: Add support for RGB48 and RGBA64.
[04:10:09 CET] <Timothy_Gu> michaelni: in 7a62e94a269d9b8993f5987d1a0895bc348c52a8, why is the bit magic version disabled?
[04:12:15 CET] <michaelni> i suspect that 11 years ago when i wrote that, the enabled code was faster
[04:12:56 CET] <michaelni> gcc likely converts the ifs to branchless code
[04:13:36 CET] <michaelni> but maybe it doesnt dunno
[08:34:25 CET] <cbsrobot> did anyone compile zimg in visual studio? does it compile?
[11:37:20 CET] <cone-260> ffmpeg 03Nicolas George 07master:e8e7eb150f15: ffmpeg_filter: check encoder before using it to set frame size.
[14:27:16 CET] <Daemon404> oh good, drama
[14:27:21 CET] <Daemon404> didnt have enough of that lately.
[14:42:31 CET] <BtbN> So he realy doesn't like getting his stuff reviewed.
[14:43:20 CET] <Daemon404> it just sounds like your standard young person / student
[14:43:33 CET] <Daemon404> with respect to defending your code to the death.
[14:44:13 CET] <BtbN> Anyone happens to know how I can get a propper patch that git am likes out of Thunderbird?
[14:44:36 CET] <Daemon404> yes
[14:44:37 CET] <J_Darnley> Save as, maybe?
[14:44:43 CET] <Daemon404> save it as a .eml
[14:44:53 CET] <Daemon404> you can drag/drop from the email list to a folder
[14:44:54 CET] <Daemon404> if you are lazy
[14:45:01 CET] <Daemon404> (like me)
[14:45:03 CET] <BtbN> It saves as some strange base64 encoded thing then, which fails to apply.
[14:45:11 CET] <Daemon404> that doesnt sound right
[14:45:19 CET] <Daemon404> view-source the email
[14:45:19 CET] <nevcairiel> git am generally can read base64 encoded mails
[14:45:28 CET] <Daemon404> oh, maybe it includes utf-8
[14:45:31 CET] <wm4> sigh, drama
[14:45:46 CET] <BtbN> oh, just saw the response from michael to that mail. The patch actualy _is_ malformed...
[14:45:50 CET] <Daemon404> :D
[14:46:05 CET] <Daemon404> i thought about setting up a patchwork or plaid for ffmpeg-devel before
[14:46:12 CET] <BtbN> yes please
[14:46:15 CET] <Daemon404> but so far devs are fine with saving fro ma client
[14:46:18 CET] <Daemon404> so i didnt bother
[14:46:48 CET] <BtbN> I prefer basicaly anything over applying patches from a ML
[14:47:06 CET] <Daemon404> i literally only use patchwork to dl the patches
[14:47:13 CET] <Daemon404> none of its organizational features
[14:49:01 CET] <BtbN> Beeing able to just pull patches from some git repo would be great.
[14:49:24 CET] <Daemon404> i prefer patch files myself, but i was also raised on patch/diff
[14:49:36 CET] <Daemon404> ill look into setting up plaid maybe later today
[14:50:08 CET] <BtbN> It parses the ML, or how does it work?
[14:50:19 CET] <Daemon404> it doesnt
[14:50:27 CET] <Daemon404> it is an email subscribe to the ML
[14:50:35 CET] <Daemon404> example: http://plaid.libav.org
[14:50:52 CET] <Daemon404> and patchwork: http://patches.libav.org
[15:00:50 CET] <durandal_1707> gmail is not showing messages yet for me for some reason
[15:16:06 CET] <mateo`> q!
[15:23:05 CET] <iive> durandal_1707: maybe it categorized them as spam?
[15:37:56 CET] <durandal_1707> nope, its just late
[16:12:10 CET] <wm4> I now have a sample m4a file, with png album art marked as jpeg
[16:12:38 CET] <nevcairiel> wm4: run the format probing on the image buffer :D
[16:12:51 CET] <Daemon404> just memcmp the first 4 bytes
[16:12:58 CET] <Daemon404> thats what other libs do
[16:13:03 CET] <wm4> do you think it's worth fixing it?
[16:13:14 CET] <Daemon404> depends if these are from apple itself
[16:13:17 CET] <Daemon404> which means common.
[16:13:23 CET] <nevcairiel> i wouldnt care, most apps that use the coverart that I expose dont care about the mimetype
[16:13:30 CET] <wm4> definitely looks like it's written by itunes
[16:13:39 CET] <nevcairiel> they just  see an image and do their own probing
[16:13:55 CET] <Daemon404> nevcairiel, problem we have is that we add it as a stream
[16:13:57 CET] <Daemon404> with a codec id
[16:14:03 CET] <Daemon404> and attached_pic data
[16:22:00 CET] <nevcairiel> yeah but what can you do, either you trust the codec id provided by the container, or you dont
[16:22:05 CET] <nevcairiel> we do usually trust it
[16:23:44 CET] <nevcairiel> not that I would be against very barebone image codec probing for the 2-3 most common formats
[16:24:21 CET] <Daemon404> there are only 3 formats for album art
[16:25:29 CET] <J_Darnley> Well, you say that...  flac allows arbitrary formats
[16:25:31 CET] <nevcairiel> i've seen bmp album art
[16:25:38 CET] <Daemon404> yes that is number 3
[16:25:48 CET] <nevcairiel> i wouldn't have included it in my 3
[16:25:54 CET] <nevcairiel> more like jpg, png, gif
[16:25:59 CET] <Daemon404> mov has no gif type
[16:26:05 CET] <Daemon404> for covr atoms
[16:26:06 CET] <nevcairiel> mov aint alone in the world!
[16:26:21 CET] <Daemon404> yeah but id3 or w/e does retarded stuff
[16:26:26 CET] <Daemon404> base64 encode anything and put it in a tag
[16:36:08 CET] <jamrial> isn't that what ogg does?
[16:36:21 CET] <Daemon404> yes
[17:07:53 CET] <nevcairiel> hey another cannot mux aac-adts into mkv ticket
[17:08:05 CET] <nevcairiel> should poke rcombs more to finish it =p
[17:08:26 CET] <rcombs> did anyone still have any actual issues?
[17:08:35 CET] <nevcairiel> dunno
[17:08:50 CET] <nevcairiel> maybe I should find the old patchset and give it another look
[17:08:53 CET] <rcombs> there were a couple people saying they'd like the deinit method added
[17:08:59 CET] <Daemon404> nevcairiel, it is kind of weird that it does it automagically for h264
[17:09:01 CET] <Daemon404> but nto aac
[17:09:15 CET] <rcombs> but it's not essential to fix the aac issue
[17:10:03 CET] <nevcairiel> Daemon404: the big difference is that for h264 it actually has the extradata it needs, just in a different format, while for aac the extradata is missing and no way to recover it right now at the time it needs it
[17:10:19 CET] <rcombs> ^
[17:10:40 CET] <rcombs> though with this I'd expect there'll be some movement to doing that in bitstream filters instead of within individual muxers
[17:10:43 CET] <nevcairiel> ff_isom_write_avcc takes care of converting the extradata into the appropriate format
[17:11:28 CET] <nevcairiel> (but you still need the bitstream filter to actually convert everything else, methinks)
[17:11:34 CET] <nevcairiel> or was that the other way around
[17:11:39 CET] <nevcairiel> might have been the other way around
[17:11:41 CET] <nevcairiel> i keep forgetting
[17:12:06 CET] <nevcairiel> annexb->mp4 converrsion is  simpelr than the other side, in any case
[17:13:00 CET] <nevcairiel> because you dont need to do any magic
[17:13:11 CET] <nevcairiel> just r eplace the 4 byte annexb startcode with the 4 byte length code
[17:13:56 CET] <nevcairiel> i'll dig for the auto-bsf patchset on the weekend and give it another review
[17:14:05 CET] <nevcairiel> you dont happen to have it in a github branch or something do you?
[17:14:32 CET] <rcombs> I can stick it on one
[17:14:33 CET] <rcombs> just a sec
[17:14:57 CET] <Daemon404> nevcairiel, i just notice its a pretty common issue for users (the annexb bsf too)
[17:15:06 CET] <Daemon404> and the warnigns give no hint on what to do to fix it
[17:15:19 CET] <nevcairiel> with the aac mkv situation, there is nothing they can do
[17:15:21 CET] <nevcairiel> unfortunately
[17:15:29 CET] <Daemon404> pretty sure there's a bsf
[17:15:36 CET] <nevcairiel> but its not enough
[17:15:41 CET] <nevcairiel> still lacking extradata
[17:15:44 CET] <Daemon404> orly?
[17:15:47 CET] <Daemon404> ive used it for mp4
[17:15:50 CET] <Daemon404> and it seemed to work
[17:16:01 CET] <nevcairiel> mp4 cheats by having headers at the end of the file
[17:16:16 CET] <rcombs> and then breaks in the cases where they aren't
[17:16:22 CET] <Daemon404> ah.
[17:16:28 CET] <nevcairiel> mkv needs the extradata during write_header
[17:16:38 CET] <nevcairiel> but its not present yet, since the bsf infra was not designed for that
[17:17:00 CET] <Daemon404> you can dick with the API and get it to work
[17:17:05 CET] <Daemon404> by beying 'clever'
[17:17:08 CET] <nevcairiel> surely
[17:17:10 CET] <Daemon404> cli cant thogh
[17:17:23 CET] <nevcairiel> this "cleverness" is really what rcombs put into generic code now =p
[17:17:29 CET] <Daemon404> ive used it for dash mp4
[17:17:34 CET] <Daemon404> which have extradata at the start
[17:17:42 CET] <Daemon404> the api i mean
[17:17:52 CET] <rcombs> dash does clever things
[17:17:54 CET] <nevcairiel> i think there is actually a hack in place that delays writing the header until the first frame
[17:17:57 CET] <rcombs> yup
[17:18:01 CET] <nevcairiel> so it has extradata then
[17:18:04 CET] <rcombs> I had a hand in that as well
[17:18:14 CET] <Daemon404> yep
[17:18:43 CET] <Daemon404> you can still be 'clever' with the api, its just much uglier
[17:19:40 CET] <Daemon404> e.g. by opening two encoders
[17:19:45 CET] <Daemon404> and stashing packets and stuff
[17:19:50 CET] <Daemon404> and copying extradata once available
[17:19:52 CET] <Daemon404> brb puking
[17:20:04 CET] <Daemon404> s/encoders/muxers/
[17:20:41 CET] <nevcairiel> or just do what rcombs now did, and just delay writing the header in generic code until the bsf spits out extradata
[17:21:07 CET] <nevcairiel> which in thsi case it does once the first proper adts frame comes along
[17:21:29 CET] <wm4> <nevcairiel> just r eplace the 4 byte annexb startcode with the 4 byte length code <- don't consumers want the SPS/PPS extracted and put into extradata?
[17:21:48 CET] <nevcairiel> wm4: parser does that already anyway
[17:26:00 CET] <nevcairiel> the big difference to the other direction is that mp4->annexb actually requires insertion of the sps/pps at the appropriate positions
[17:26:05 CET] <nevcairiel> which is not as trivial
[17:26:36 CET] <wm4> what's the problem? that the other NALs refer them by numbers?
[17:27:24 CET] <nevcairiel> mostly finding the right spot, and then checking if the stream maybe already contains them because duping them would be weird
[17:28:52 CET] <rcombs> nevcairiel: https://github.com/rcombs/FFmpeg/tree/auto-bsf took a minute due to a few rebase conflicts
[17:29:04 CET] <Daemon404> nevcairiel, when i did it manually, i just plopped the sps/pps at the start
[17:29:07 CET] <Daemon404> once.
[17:29:14 CET] <rcombs> (av_free_packet -> av_packet_unref)
[17:29:19 CET] <nevcairiel> Daemon404: strictly speaking thats not a compliant stream
[17:29:28 CET] <nevcairiel> but yeah
[17:29:36 CET] <Daemon404> which bit of it would be noncompliant here
[17:29:37 CET] <rcombs> nevcairiel: probably works with lav*-based things
[17:29:38 CET] <Daemon404> the numbering?
[17:30:01 CET] <nevcairiel> random access might break, as it may not f ind the sps then
[17:30:26 CET] <nevcairiel> most tools will probably find it when its at the start of the file
[17:30:27 CET] <Daemon404> i dont think the spec mandates that though
[17:30:37 CET] <Daemon404> afaik its entirely compliant to have only one./
[17:30:41 CET] <nevcairiel> the annexb spec wants sps/pps before IDRs afaik
[17:30:49 CET] <Daemon404> requries, or recommends?
[17:31:13 CET] <nevcairiel> who knows
[17:31:15 CET] <nevcairiel> lets find out!
[17:31:21 CET] <Daemon404> i dont ave the spec on me
[17:31:23 CET] <Daemon404> effort
[17:31:24 CET] <rcombs> does anyone actually care much
[17:31:26 CET] <rcombs> 'cause I do
[17:31:36 CET] <Daemon404> im curious
[17:31:38 CET] <rcombs> (have the spec, not care)
[17:31:41 CET] <Daemon404> it affects me in to tangible way
[17:31:45 CET] <Daemon404> but im curious.
[17:31:47 CET] <Daemon404> in no*
[17:31:50 CET] <nevcairiel> the only time I convert to annexb is for some hardware decoders
[17:31:55 CET] <nevcairiel> which dont need any in-band sps
[17:32:16 CET] <Daemon404> i do for hls segmenting from progressive mp4s
[17:32:32 CET] <nevcairiel> all hls streaming i do is from live re-encodes
[17:32:38 CET] <Mavrik> And of course any kind of MPEG2-TS streams :)
[17:32:40 CET] <nevcairiel> x264 will do the right thing, i hope =p
[17:32:41 CET] <Daemon404> hls is easy though
[17:32:46 CET] <Daemon404> each segment has exactly 1 sps/pps
[17:32:48 CET] <Daemon404> at the start
[17:32:50 CET] <Daemon404> the end./
[17:33:02 CET] <Daemon404> (iirc)
[17:33:35 CET] <nevcairiel> i dont think hls actually mandates that
[17:33:49 CET] <nevcairiel> it was all kinds of weird in that 
[17:34:12 CET] <rcombs> Annex B itself doesn't care
[17:34:31 CET] <nevcairiel> its probably in the mpeg2ts specs for h264 transport
[17:34:34 CET] <nevcairiel> whichever standard that was
[17:34:35 CET] <Daemon404> youre right
[17:34:41 CET] <Daemon404> i was thinking of PAT/PMT
[17:34:49 CET] <Daemon404> not sure how i conflated the two
[17:39:19 CET] <nevcairiel> cant find it in the mpeg2-ts spec, oh well
[17:39:29 CET] <nevcairiel> but its definitely more portable if the sps/pps is repeated
[17:39:55 CET] <nevcairiel> someone may cut your mpegts file
[17:43:24 CET] <kierank> probably implicit in the definition of a random access point
[17:44:23 CET] <Mavrik> Also some players just don't handle seeking well if there's no SPS/PSS before each IDR.
[17:44:34 CET] <Mavrik> (Mostly cheap STBs.)
[18:15:36 CET] <cone-777> ffmpeg 03Michael Niedermayer 07release/2.8:6a0e10ae0df1: avcodec/ffv1dec: Clear slice coordinates if they are invalid or slice header decoding fails for other reasons
[18:15:37 CET] <cone-777> ffmpeg 03Michael Niedermayer 07release/2.8:c8a1324d1ecd: avcodec/ffv1dec: update progress in case of broken pointer chains
[18:15:38 CET] <cone-777> ffmpeg 03Michael Niedermayer 07release/2.8:81a2ad762b69: avcodec/ffv1: Initialize vlc_state on allocation
[18:15:39 CET] <cone-777> ffmpeg 03Michael Niedermayer 07release/2.8:6ac9d6303f0d: avcodec/opusdec: Fix extra samples read index
[18:15:40 CET] <cone-777> ffmpeg 03Kieran Kunhya 07release/2.8:2f5f940befc5: opusdec: Don't run vector_fmul_scalar on zero length arrays
[18:15:41 CET] <cone-777> ffmpeg 03Lucas de Andrade 07release/2.8:fcb8ee98f686: avformat/hls: update cookies on setcookie response
[18:43:36 CET] <cone-777> ffmpeg 03Ganesh Ajjanagadde 07master:20a30077c365: avutil/mathematics: correct documentation for av_gcd
[18:48:40 CET] <cone-777> ffmpeg 03Ganesh Ajjanagadde 07master:191f611906c2: avutil/wchar_filename: add av_warn_unused_result
[20:08:03 CET] <cone-777> ffmpeg 03Ganesh Ajjanagadde 07master:47af5db721ed: all: fix enum definition for large values
[20:46:19 CET] <atomnuker> "I am looking for a way to channel frittered away energy obtained during my transition from undergraduate to graduate life and its associated increase in flexibility of time allocation."
[20:46:34 CET] <atomnuker> what's up with this sentence?
[20:47:28 CET] <Compn> its a run on sentence
[20:47:52 CET] <Compn>  https://en.wikipedia.org/wiki/Run-on_sentence
[20:50:58 CET] <atomnuker> not exactly what I asked, but whatever, ML drama
[20:51:36 CET] <Compn> oh 
[20:51:41 CET] <Compn> i'm staying far away from that one
[20:56:04 CET] <cone-777> ffmpeg 03Marton Balint 07master:d9611864c2b7: ffprobe: add support for printing packet strings metadata as packet tags
[21:00:32 CET] <BBB> isnt drama our middle name
[21:00:42 CET] <BBB> ffdrampeg
[21:01:40 CET] <Compn> it does not have to be
[21:04:56 CET] <fritsch> na, that's ours ... kodirama
[21:05:44 CET] <BBB> dramplayer?
[21:05:52 CET] <BBB> soooooooo easy :D
[21:06:10 CET] <iive> WWF
[21:06:30 CET] <BBB> wwf?
[21:07:43 CET] <iive> it's WWE now, the wrestling
[21:08:18 CET] <iive> south park had an episode comparing it to a theater drama. and it is full of drama :)
[21:09:46 CET] <BBB> oh I see
[21:09:47 CET] <BBB> :D
[23:03:19 CET] <cone-777> ffmpeg 03Muhammad Faiz 07master:306808f10fe8: avfilter/showcqt: fix dependency with avformat
[23:14:42 CET] <durandal_1707> kierank: how many rounds you run AFL?
[23:15:02 CET] <kierank> they told me on the afl irc just to run it once 
[23:15:05 CET] <jamrial> re showcqt, wonder why did the --disable-avformat fate client didn't fail
[23:34:48 CET] <cbsrobot> BBB: did you try zimg on osx ?
[23:35:20 CET] <BBB> no
[23:36:28 CET] <cbsrobot> i've a patch to make it run on osx, but not sure if it's right
[23:36:36 CET] <cbsrobot> are you c++ savvy ?
[23:37:21 CET] <BBB> not really
[23:37:25 CET] <BBB> I mean, I can read/write it
[23:37:30 CET] <BBB> but Im by no means an expert
[23:37:35 CET] <cbsrobot> can you have a look: https://gist.github.com/anonymous/84e14543cbc3691f83c5
[23:38:42 CET] <BBB> anonymous? :-p
[23:38:47 CET] <cbsrobot> well
[23:39:14 CET] <cbsrobot> the zimg community is very annonymous
[23:39:49 CET] <durandal_1707> animes weirdos
[23:40:00 CET] <JEEB> not really, just the author who has a history of being an internet troll
[23:40:20 CET] <JEEB> I have a hazy memory of him being on #mplayer ages ago...
[23:40:23 CET] <BBB> the last two changes look weird
[23:40:34 CET] <BBB> the variable names suggest these are intended to be ints
[23:40:38 CET] <BBB> why use float abs functions?
[23:41:01 CET] <BBB> the rest is fine I think, but I dont maintain that stuff so what do I know
[23:42:24 CET] <cbsrobot> the rror was: src/zimg/resize/filter.cpp:112:14: error: call to 'abs' is ambiguous
[23:43:36 CET] <JEEB> anyways, the guy takes in PRs from github as usual
[23:43:42 CET] <JEEB> as far as I can see
[23:43:46 CET] <BBB> Im pretty sure they want the int here, not the abs
[23:43:51 CET] <BBB> eh
[23:43:53 CET] <BBB> int, not double
[23:44:11 CET] <cbsrobot> ok
[23:44:12 CET] <cbsrobot> thanks
[23:44:39 CET] <cbsrobot> I'll probably sent it as PR afterwards
[23:45:10 CET] <JEEB> and yes, the guy seems to have been on freenode before
[23:45:19 CET] <JEEB> "#mplayer anon32" gives results
[23:45:21 CET] <BBB> this supposedly happens when you include both float and int math headers in the same file
[23:59:34 CET] <cbsrobot> seems to be a typo
[23:59:45 CET] <cbsrobot> -#include <cstdint>
[23:59:52 CET] <cbsrobot> +#include <cstdlib>
[00:00:00 CET] --- Sat Oct 31 2015