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

[burek]

[00:50:02 CET] <Daemon404> michaelni, potentially, i suppose.
[00:50:13 CET] <Daemon404> i dont know what weeks gsoc is
[00:51:12 CET] <michaelni> timeline: (for anyone interrested what is when) https://developers.google.com/open-source/gsoc/timeline
[00:53:04 CET] <Daemon404> wow i didnt remember it being 4 months
[00:53:17 CET] Action: Daemon404 will probably have a week vacation somewhere in there
[00:53:29 CET] <Daemon404> as in disconnected
[00:53:54 CET] <michaelni> that should be no problem
[00:54:28 CET] <michaelni> some backup mentor or admin has to fill in that time
[00:54:49 CET] <Daemon404> i sure i could mentor
[00:54:59 CET] <michaelni> great, thanks
[00:55:10 CET] <Daemon404> maybe ill actually get a tshirt
[00:55:13 CET] <Daemon404> they never sent mine last time
[01:03:25 CET] <michaelni> BBB, wm4, are you potentially available as mentor for this years GSoC ?
[01:41:51 CET] <michaelni> Timothy_Gu, fatebeta is "502 Bad Gateway" after reboot
[01:42:22 CET] <BBB> michaelni: depends on project
[01:42:43 CET] <michaelni> BBB, whatever project you like
[01:45:16 CET] <BBB> I dont know yet, its quite far away
[01:45:17 CET] <BBB> maybe
[01:45:31 CET] <BBB> I dont have any fun projects in my head right now
[01:45:45 CET] <michaelni> i was asking because of "How many potential mentors have agreed to mentor this year?"
[01:46:07 CET] <jamrial_> Daemon404: http://fate.ffmpeg.org/report.cgi?time=20160216235604&slot=x86_64-archlinux-gcc-ubsan not sure which commit is at fault
[01:46:32 CET] <michaelni> jamrial_,  are you potentially available as mentor for this years GSoC ?
[01:47:17 CET] <jamrial_> michaelni: no, i don't think i could do it, sorry
[01:47:24 CET] <michaelni> ok :(
[01:47:39 CET] <michaelni> thanks anyway
[01:57:38 CET] <BBB> if you can suggest interesting projects I can re-consider it
[01:57:44 CET] <BBB> but I Cant think of anything fun right now
[01:58:01 CET] <BBB> I dont really want to do any filters, I dont think anyone cares for ffvp9 since its mostly done
[01:58:15 CET] <BBB> hevc is not appropriate for most students and is mostly grind work rather than new implementation work
[01:58:18 CET] <BBB> vp10 is too early
[01:58:26 CET] <BBB> etc.
[02:02:15 CET] <michaelni> some encoder maybe ? would need to be simple enough and interresting enough, maybe intra only something ?
[02:05:39 CET] <Daemon404> jamrial_, weird... but its 1am here, sleep time
[02:06:51 CET] <iive> michaelni: what happened with your 100fps filter?
[02:10:48 CET] <michaelni> i should work on it but i lack time
[02:16:30 CET] <iive> what is there to be done?
[02:42:05 CET] <Timothy_Gu> michaelni: manually started the server
[02:45:10 CET] <Timothy_Gu> never expected anyone to actually care about our codename https://i.iinfo.cz/images/298/ffmpeg-einstein-prev.jpg
[02:45:42 CET] <TD-Linux> ffmpeg has codenames?
[02:46:01 CET] <Timothy_Gu> https://www.ffmpeg.org/download.html
[02:47:35 CET] <TD-Linux> I named a libvorbis release ÄÄÄÄ
[03:56:44 CET] <BBB> michaelni: its hard to review asm if you move the code along with changing it
[04:21:49 CET] <michaelni> BBB, ill post a cleaner patch(set) for that one
[04:42:27 CET] <BBB> michaelni: ah much easier to read, ty
[04:43:07 CET] <BBB> lgtm
[04:54:26 CET] <michaelni> atomnuker, aac-pns seems to need a higher FUZZ factor on http://fatebeta.ffmpeg.org/report/loongson-fedora-gcc-4.8/20160216214610#failed_tests
[04:54:44 CET] <michaelni> this also may need backporting
[05:17:33 CET] <cone-228> ffmpeg 03Michael Niedermayer 07master:d07f6e5f1c36: swscale/x86/output: Move code into yuv2planeX_mainloop
[05:17:33 CET] <cone-228> ffmpeg 03Michael Niedermayer 07master:f6492a2ea8df: swscale/x86/output: Fix yuv2planeX_16* with unaligned destination
[09:49:58 CET] <cone-571> ffmpeg 03Paul B Mahol 07master:5589698e0bd6: avfilter/vf_drawbox: add alpha pixel formats support
[09:49:58 CET] <cone-571> ffmpeg 03Paul B Mahol 07master:4dc58803813f: avfilter/vf_drawbox: reindent
[11:28:19 CET] <atomnuker> michaelni: thanks for telling me, I'll try to fix it later today
[13:50:28 CET] <wm4> note to self: never engage Mats
[13:55:59 CET] <BBB> wbs: thanks for merging
[13:56:02 CET] <BBB> wm4: what happened?
[13:58:07 CET] <durandal_1707> it could get worse, sending mails directly to you
[14:58:05 CET] <wm4> michaelni: I wouldn't know for what
[15:46:00 CET] <ubitux> {nv12,nv21,yuv420p,yuv422p}_to_{argb,rgba,abgr,rgba}_neon 16 and 32 for aarch64 done.
[15:46:10 CET] <ubitux> need to add some prefetch and cleanups and it's good to go
[15:47:37 CET] <durandal_1707> got mail to respect copyright laws
[15:48:18 CET] <durandal_1707> from svnoreply at googlemail.com
[15:49:14 CET] <durandal_1707> including patent, trademark, trade secret etc
[15:49:23 CET] <nevcairiel> sounds bogus =p
[15:50:25 CET] <durandal_1707> its interesting scam
[15:52:06 CET] <rcombs> ubitux: wtb aarch64 yuv2yuv
[15:52:51 CET] <ubitux> better do rgb2yuv first
[15:53:00 CET] <nevcairiel> how often does that happen
[15:53:18 CET] <nevcairiel> yuv2rgb and yuv2yuv are at least used in various playback scenarious
[15:53:20 CET] <nevcairiel> -u
[15:54:02 CET] <J_Darnley> Speaking of scams, did anyone else recieve a "floss survey" today?
[15:54:09 CET] <nevcairiel> oh yeah
[15:54:16 CET] <nevcairiel> second time already, too
[15:54:20 CET] <nevcairiel> (not today, mind you)
[15:55:38 CET] <rcombs> I've been asking for some cleanup (logging, statics&) and confirmation this passes FATE and memcheck for a while, but haven't heard back, so here have a patch made of intrinsics and hardcoded cases: https://gist.github.com/541a7715a6213f71f91a
[15:55:56 CET] <J_Darnley> Aww.  The survey doesn't have as many free-form boxes as I want.  :(
[15:56:21 CET] <nevcairiel> rcombs: psh intrinsics, write asm files like a big boy! :D
[15:56:28 CET] <rcombs> nevcairiel: that's what I said
[15:57:09 CET] <rcombs> they preferred the intrinsics because it allows sharing between arm and aarch64 more easily, which I suppose isn't absurd
[15:57:28 CET] <rcombs> and maybe we should have something like x86inc.asm for arm/aarch64
[15:57:35 CET] Action: J_Darnley suggests they need to writea better assembler
[16:02:16 CET] <J_Darnley> LOL.  "please insert -1 if don't know" --> "Must be a number greater than 0"
[16:02:25 CET] <J_Darnley> A real good programmer wrote that!
[16:07:00 CET] <J_Darnley> This survey also heavily github centered
[16:07:09 CET] <J_Darnley> pull request this, pull request that
[16:07:18 CET] <nevcairiel> i just deleted the mail with no second thought
[16:07:37 CET] <J_Darnley> I'm just filling it with junk to see what's on the pages
[16:08:16 CET] <nevcairiel> but I think github didnt ínvent pull requests, it kind of came natural to the git flow
[16:08:41 CET] <wm4> wasn't pull request a term before github (curse you github)
[16:09:18 CET] <J_Darnley> maybe they didn't but I don't know a git tool that send an email saying "please pull changes from this branch"
[16:09:46 CET] <nevcairiel> maybe not a tool, but i think it was at least common practice in kernel development, and those guys invented git, so..
[16:09:51 CET] <Daemon404> you guys got that email?
[16:09:57 CET] <Daemon404> gmail put it in spam for me
[16:10:08 CET] <J_Darnley> Me too but I always look in spam
[16:10:09 CET] <nevcairiel> i should have spammed it instead of deleting it right away =p
[16:10:10 CET] <Daemon404> act
[16:10:14 CET] <Daemon404> ic
[16:11:44 CET] <J_Darnley> Well gmail can be overzealous in marking spam.  I found several winamp beta list mails in there when I checked.
[16:12:05 CET] <nevcairiel> didnt someone tell you, winamp died
[16:12:20 CET] <J_Darnley> Then why am I running a 2 day old beta?
[16:12:30 CET] <J_Darnley> I might be undead
[16:12:32 CET] <J_Darnley> *it
[16:13:57 CET] <cone-478> ffmpeg 03Michael Niedermayer 07master:c351126ee938: avcodec/eatqi: print error on mb decode failure
[16:13:58 CET] <cone-478> ffmpeg 03Muhammad Faiz 07master:7c11e727f640: avfilter/avf_showcqt: improve pts handling
[16:18:18 CET] <J_Darnley> There's the jackpot word
[16:18:21 CET] Action: J_Darnley cheers
[16:26:59 CET] <cone-478> ffmpeg 03Johan Ström 07master:6c31c99289e3: hlsenc: add use_localtime_mkdir option to automatically create time-based directory
[16:40:16 CET] <cone-478> ffmpeg 03Luca Barbato 07master:21c750f240b9: configure: Use `require` for the non-component options
[16:40:17 CET] <cone-478> ffmpeg 03Luca Barbato 07master:5e1beec944da: configure: Print which libraries will be built
[16:40:18 CET] <cone-478> ffmpeg 03Luca Barbato 07master:a2bb771a3cde: configure: Restore the --enable-everything behaviour
[16:40:19 CET] <cone-478> ffmpeg 03Derek Buitenhuis 07master:f97ee815cf25: Revert "configure: Revert recent changes to disable-everything"
[16:40:20 CET] <cone-478> ffmpeg 03Derek Buitenhuis 07master:470bfab47089: Merge commit '21c750f240b9d0c41a258d1adee2d9f75ff378b6'
[16:40:21 CET] <cone-478> ffmpeg 03Derek Buitenhuis 07master:3bff005be8ea: Merge commit '5e1beec944dacd6b4ed7d710125dd508c41ca969'
[16:40:22 CET] <cone-478> ffmpeg 03Derek Buitenhuis 07master:e8ebcb0034c5: Merge commit 'a2bb771a3cded8a05137c0effb34f61a2bc78e22'
[16:40:29 CET] <Daemon404> carl should be happy...
[16:50:46 CET] <nevcairiel> Carl is never happy
[16:53:07 CET] <Daemon404> true
[16:53:14 CET] <Paranoialmaniac> lol
[17:02:54 CET] <cone-478> ffmpeg 03Anton Khirnov 07master:c084d6d2cfb5: buffersrc: default SAR to 0 (unknown) rather than 1
[17:02:55 CET] <cone-478> ffmpeg 03Derek Buitenhuis 07master:ae3c0a9c1f66: Merge commit 'c084d6d2cfb570b10d8784eb20cc696dfb7c5605'
[17:03:51 CET] <wm4> michaelni: can you stop giving random people push access
[17:04:03 CET] <wm4> we've had some problems with this in the past
[17:04:41 CET] <Daemon404> wm4, what happened
[17:04:59 CET] <wm4> nothing
[17:05:06 CET] <Daemon404> o
[17:05:22 CET] <wm4> but someone sends a patch to some single libavfilter filter -> offer git write access
[17:05:36 CET] <wm4> that seems a bit premature in my opinion
[17:07:06 CET] <michaelni> he is the author of that filter
[17:07:24 CET] <nevcairiel> well since you cant limit push access to that single filter, it should still be done rather carefully
[17:07:42 CET] <cone-478> ffmpeg 03Anton Khirnov 07master:721a4efc0545: buffer: add support for pools using caller data in allocation
[17:07:43 CET] <cone-478> ffmpeg 03Derek Buitenhuis 07master:26abd5149ebf: Merge commit '721a4efc0545548a241080b53ab480e34f366240'
[17:08:39 CET] <wm4> michaelni: if he's a regular contributor who knows the rules and who behaved well it should be ok
[17:13:09 CET] <mateo`> I'm wondering what a decoder (the mediacodec one in my case) is supposed to return to signal that it has output all the remaining frames while he's been sent null avpackets to flush it, AVERROR_EOF ? Considering you can send a null avpacket but you are not guaranteed to return a frame at that time.
[17:13:35 CET] <cone-478> ffmpeg 03Anton Khirnov 07master:89923e418b49: lavu: add a framework for handling hwaccel frames
[17:13:36 CET] <cone-478> ffmpeg 03Derek Buitenhuis 07master:1a708780f3d4: Merge commit '89923e418b494e337683442ab896d754bc07341a'
[17:14:07 CET] <wm4> mateo`: return success (0)
[17:14:13 CET] <Daemon404> wm4, https://git.libav.org/?p=libav.git;a=commit;h=a001ce31bc2bcf875a39b5fb22dae49120293b42
[17:14:28 CET] <Daemon404> this should be ok to merge, no?
[17:14:31 CET] <wm4> Daemon404: yes
[17:14:36 CET] <Daemon404> since afaik the VDPAU code between both repos is identical
[17:14:37 CET] <Daemon404> right>
[17:14:45 CET] <wm4> it should be, yes
[17:15:00 CET] <wm4> but it doesn't even touch libavcodec yet
[17:15:14 CET] <michaelni> wm4, IMO he is, also ill point it out to him privately again just to be double sure but i think we dont have a problem with people ignoring rules
[17:15:30 CET] <Daemon404> wm4, yeah i know
[17:16:36 CET] <mateo`> wm4: so then, what is it supposed to return when it received a null avpacket but does not return a frame ?
[17:16:54 CET] <cone-478> ffmpeg 03Anton Khirnov 07master:a001ce31bc2b: hwcontext: add a VDPAU implementation
[17:16:55 CET] <cone-478> ffmpeg 03Derek Buitenhuis 07master:d779d8d771c0: Merge commit 'a001ce31bc2bcf875a39b5fb22dae49120293b42'
[17:21:32 CET] <Daemon404> i need someone with a VDPAU setup to test this next merge
[17:21:35 CET] <Daemon404> before a push
[17:21:38 CET] <Daemon404> who could i poke?
[17:21:53 CET] <wm4> I could test, if there's something to test at all
[17:22:05 CET] <wm4> oh right, ffmpeg_vdpau.c I suppose
[17:22:07 CET] <Daemon404> yep
[17:22:29 CET] <BBB> seeking in lavfi
[17:22:30 CET] <BBB> hm
[17:22:32 CET] <BBB> wonderful
[17:22:36 CET] <BBB> so& why is that a command
[17:22:40 CET] <BBB> thats probably ridiculous, no?
[17:22:45 CET] <wm4> BBB: it's for the movie_src only
[17:22:52 CET] <nevcairiel> BBB: because its a cheap-ass hack, not a generic solution
[17:22:53 CET] <wm4> which demuxes/decodes stuff
[17:22:55 CET] <BBB> shouldnt lavfi overall support seeking?
[17:23:02 CET] <BBB> or flushing, at least
[17:23:14 CET] <wm4> BBB: no, because mpeg has discontinuities anyway
[17:23:17 CET] <wm4> so you don't need flushing
[17:23:23 CET] <wm4> (god why am I bothering)
[17:23:24 CET] <BBB> ?????
[17:23:30 CET] <BBB> mpeg is broken shit
[17:23:34 CET] <Daemon404> wm4: curl http://pastebin.com/raw/2e2gZ9Gm | base64 -d | xz -d > patch.diff
[17:23:35 CET] <BBB> so we dont need a solution for a problem
[17:23:37 CET] <BBB> ?????
[17:23:37 CET] <Daemon404> can you test that
[17:23:43 CET] <wm4> Daemon404: give me a moment
[17:24:12 CET] <kierank> movie_src is becoming a mini gstreamer
[17:24:38 CET] <wm4> kierank: it was always the intention for lavfi to become gstreamer
[17:24:48 CET] <wm4> Daemon404: xz: (stdin): Unexpected end of input
[17:24:53 CET] <BBB> quick, let me unsubscribe
[17:24:57 CET] <wm4> actually base64: invalid input
[17:25:01 CET] <BBB> can we split lavc and lavfi in separate projects then?
[17:25:07 CET] <Daemon404> wm4, oh... maybe pastebin fucks it up
[17:25:08 CET] <kierank> split them all
[17:25:19 CET] <BBB> I dont want to make this political
[17:25:47 CET] <nevcairiel> movie_src in itself is a big hack because apps dont implement multiple-input support
[17:25:53 CET] <wm4> (IMO it's fine to try to recreate gstreamer/dshow/etc, but not in libavfilter and certainly not in the same repo as libavcodec)
[17:25:57 CET] <nevcairiel> so make the filter graph create its own inputs
[17:26:12 CET] <wm4> movie_src has no input
[17:26:14 CET] <wm4> only outputs
[17:26:18 CET] <nevcairiel> it is an input
[17:26:21 CET] <nevcairiel> its the point
[17:26:31 CET] <wm4> depends in the viewpoint I guess
[17:26:37 CET] <nevcairiel> otherwise whatever host app is used would need to support multiple inputs
[17:26:48 CET] <wm4> ffmpeg.c does! mpv also does
[17:27:04 CET] <wm4> and the libavdevice libavfilter wrapper (which also has some extra code for CCs)
[17:27:22 CET] <wm4> that libavdevice thing is actually the "main use" of moviesrc
[17:27:38 CET] <Daemon404> wm4, ... base64 tool is retarded
[17:27:48 CET] <Daemon404> it's because pastebin is CRLF
[17:27:51 CET] <wm4> so why use base64 at all
[17:27:56 CET] <Daemon404> cause im lazy
[17:28:13 CET] <michaelni> ./configure --enable-x11grab --enable-gpl fails "x11grab cannot be enabled", is that intended ?
[17:28:14 CET] <Daemon404> and copypasting patch from terminal breaks stuff
[17:28:17 CET] <wm4> git diff | curl -F 'sprunge=<-' http://sprunge.us
[17:28:25 CET] <Daemon404> michaelni, might be due to some recent merge of mine
[17:28:35 CET] <michaelni> yes it worked before
[17:28:35 CET] <Daemon404> wm4, oh cool.
[17:28:49 CET] <wm4> Daemon404: it returns a url for the raw data too
[17:29:14 CET] <nevcairiel> arent there even finished tools to do that so you dont have to remember the curl syntax
[17:29:43 CET] <Daemon404> wm4, http://sprunge.us/RaeU
[17:29:48 CET] <wm4> nevcairiel: a 2 line sh script?
[17:29:52 CET] <Daemon404> not even
[17:29:54 CET] <Daemon404> just an alias
[17:30:08 CET] <wm4> error: patch failed: ffmpeg_vdpau.c:30
[17:30:08 CET] <wm4> error: ffmpeg_vdpau.c: patch does not apply
[17:30:13 CET] <Daemon404> uh?
[17:30:17 CET] <Daemon404> git pull to master?
[17:30:21 CET] <wm4> ah wait
[17:30:24 CET] <nevcairiel> those tools probably just are scripts, but they offer a choice of hosts i think =p
[17:30:36 CET] <Daemon404> wm4, crlf?
[17:30:53 CET] <wm4> my repo was unclean
[17:30:55 CET] <wm4> now it applied
[17:30:58 CET] <Daemon404> ah
[17:31:01 CET] <nevcairiel> UNCLEAN!
[17:31:02 CET] <nevcairiel> :D
[17:31:19 CET] <Daemon404> git-clean ftw
[17:31:23 CET] <jamrial> git purge
[17:31:49 CET] <nevcairiel> git clean doesnt revert
[17:31:59 CET] <Daemon404> true
[17:33:25 CET] <Daemon404> michaelni, can you look at config.log
[17:33:28 CET] <Daemon404> i dont have any system with x11
[17:33:41 CET] <wm4> ffmpeg_vdpau.c:251:12: error: VDPAUContext {aka struct VDPAUContext} has no member named decoder
[17:33:41 CET] <wm4>      if (ctx->decoder)
[17:33:41 CET] <wm4>             ^
[17:34:11 CET] <Daemon404> it might be a tad hard for me to fix this without a vdpau system
[17:34:34 CET] <wm4> would it be useful if I beat this into working and then send a diff?
[17:34:46 CET] <Daemon404> yea
[17:35:39 CET] <Daemon404> lazy way of "fixing" a merge is: git merge -s ours <hash> && patch -p1 < a.patch && git commit -a -s --amend
[17:35:41 CET] <wm4> ah the entire function is actually unused now
[17:35:42 CET] <Daemon404> <_<
[17:35:48 CET] <wm4> -    if (vdpau_api_ver == 1)
[17:35:48 CET] <wm4> -        return vdpau_old_init(s);
[17:35:52 CET] <wm4> this removed its use
[17:35:57 CET] <Daemon404> right
[17:36:03 CET] <wm4>  ffmpeg: add vdpau_old to allow continued testing of the older (but not oldest) API
[17:36:03 CET] <Daemon404> why the heck was that there anyway?
[17:36:09 CET] <wm4> LOL
[17:36:10 CET] <Daemon404> it was hardcoded to 2
[17:36:13 CET] <Daemon404> yeah thats fucking dumb
[17:36:26 CET] <wm4> indeed
[17:36:31 CET] <nevcairiel> ffmpeg_vdpau.c actually used the crappy old api?
[17:36:35 CET] <nevcairiel> or well could
[17:36:39 CET] <Daemon404> if you edited the file
[17:36:41 CET] <wm4> I have no idea
[17:36:43 CET] <nevcairiel> just rip it out then, its scheduled for removal anyway
[17:36:48 CET] <Daemon404> thats what i did
[17:36:50 CET] <Daemon404> as wm4 noted
[17:36:53 CET] <wm4> I think it only tests av_vdpau_get_profile? but still uses hwaccel
[17:37:07 CET] <Daemon404> apologies for language above.
[17:37:14 CET] <wm4> ffmpeg_opt.o:(.data.rel.ro+0x1498): undefined reference to `vdpau_api_ver'
[17:37:41 CET] <wm4> ok an unused option
[17:38:04 CET] <Daemon404> oh.. wtf
[17:38:08 CET] <wm4> now uh how do I test it at runtime
[17:38:15 CET] <Daemon404> i dont know how to use vdpau via cli
[17:38:28 CET] <nevcairiel> make fate HWACCEL=vdpau =p
[17:38:48 CET] <nevcairiel> or ffmpeg -hwaccel vdpau -i ...
[17:38:51 CET] <Daemon404> i wonder if this will break some fate instance which tests the old apo
[17:38:57 CET] <nevcairiel> doubt we have those
[17:39:04 CET] <Daemon404> it would be a huge amount of crap to keep version=1 support
[17:39:05 CET] <Daemon404> i think
[17:39:09 CET] <wm4> [h264 @ 0x2aa4460] Hardware accelerated decoding with frame threading is known to be unstable and its use is discouraged.
[17:39:10 CET] <wm4> trollol
[17:39:15 CET] <Daemon404> :D
[17:39:34 CET] <nevcairiel> i wanted to write a patch to automatically make ffmpeg.c disable threads if hwaccel is requested
[17:39:36 CET] <nevcairiel> but i got lazy
[17:40:07 CET] <wm4> how do I disable threads for fate?
[17:40:10 CET] <Daemon404> i swear i heard that vdpau allows threads
[17:40:17 CET] <nevcairiel> fate automatically disables threads
[17:40:22 CET] <fritsch> Daemon404: where did you hear that?
[17:40:25 CET] <wm4> Daemon404: it does, it's not a problem with the hw api really
[17:40:28 CET] <nevcairiel> unless you run it with THREADS=x
[17:40:32 CET] <michaelni> Daemon404,is caused by  disable x11grab and later enable x11grab
[17:40:47 CET] <wm4> fritsch: it's specified to allow concurrent access
[17:40:49 CET] <Daemon404> michaelni, i dont recall merging anything relating to x11 latelt
[17:41:00 CET] <nevcairiel> Daemon404: configure  dependency changes
[17:41:06 CET] <fritsch> wm4: we talk about frame threading currently, right - which is something highly special
[17:41:07 CET] <nevcairiel> those things are borked as f'
[17:41:23 CET] <wm4> fritsch: yeah, libavcodec vs. pure vdpau API
[17:41:28 CET] <nevcairiel> there was another new patch on the ML to try to fix some fallout
[17:41:44 CET] <nevcairiel> ie. libav quality =p
[17:41:49 CET] <wm4> that's what you get for having a 7kloc sh script?
[17:42:08 CET] <nevcairiel> thats what you get for changing the status quo just to improve the failure messages a bit
[17:42:11 CET] <wm4>  746ae4adb7d1921800b9cc30257d7231 *tests/data/fate/vsynth1-mpeg1.mpeg1video
[17:42:11 CET] <wm4>  711835 tests/data/fate/vsynth1-mpeg1.mpeg1video
[17:42:11 CET] <wm4> -c126c7dd12e7161df192d253e3100475 *tests/data/fate/vsynth1-mpeg1.out.rawvideo
[17:42:11 CET] <wm4> +926e3b20178b3b89b36b7f9c1e8325e2 *tests/data/fate/vsynth1-mpeg1.out.rawvideo
[17:42:11 CET] <wm4>  stddev:    7.63 PSNR: 30.48 MAXDIFF:   84 bytes:  7603200/  7603200
[17:42:16 CET] <wm4> what does it mean
[17:42:22 CET] <nevcairiel> mpeg1 is not bitexact in hardware
[17:42:25 CET] <nevcairiel> stick to h264
[17:42:31 CET] <wm4> makes sense
[17:42:43 CET] <Daemon404> michaelni, im not seeing where it changed
[17:42:59 CET] <Daemon404> it could be merges exposed some existing bug, or introduced one
[17:42:59 CET] <nevcairiel> mpeg1/2 dont specify strictly enough for bitexact decoding in all decoders
[17:43:05 CET] <Daemon404> but i cant see where x11 specifically was affected
[17:44:12 CET] <michaelni> previously disable X enable X was ok now it fails, x11 is one path that did it it seems
[17:44:41 CET] <nevcairiel> Daemon404: like i said, there is at least 2 more unpushed patches on their ML that "fix" some behavior they broke...
[17:44:41 CET] <wm4> now h264-conformance-cvfc1_sony_c fails
[17:44:46 CET] <nevcairiel> wm4: thats cropping
[17:44:49 CET] <wm4> ok
[17:44:57 CET] <wm4> then I suppose everything is fine
[17:45:01 CET] <Daemon404> michaelni, ok
[17:45:13 CET] <wm4> Daemon404: http://sprunge.us/AbHB
[17:45:16 CET] <Daemon404> wm4, ok
[17:45:38 CET] <wm4> and yes the "old API" option is removed from ffmpeg
[17:46:10 CET] <Daemon404> michaelni, [libav-devel] [PATCH] configure: Use set_all to force the dependency refresh
[17:46:17 CET] <Daemon404> sounds like it is related
[17:47:27 CET] <michaelni> doing --enable-libpulse twice failed too
[17:47:28 CET] <cone-478> ffmpeg 03Anton Khirnov 07master:bd49be885e9a: avconv_vdpau: use the hwcontext API to simplify code
[17:47:29 CET] <cone-478> ffmpeg 03Derek Buitenhuis 07master:6b706ce85fa5: Merge commit 'bd49be885e9ad6bae599c54473ba2fa2957eb140'
[17:47:48 CET] <Daemon404> michaelni, that is mentioned in the patch i just talked about
[17:48:56 CET] <michaelni> what is the point of the changes that broke this ?
[17:49:20 CET] <Daemon404> to make things like --disable-protocols --enable-protocol=https work as intneded
[17:49:31 CET] <Daemon404> iirc in the past, it just left everything enabled
[17:49:36 CET] <nevcairiel> that seemed to work fine for me before, i used such syntax in my build files
[17:49:45 CET] <nevcairiel> and verified the outcome
[17:50:16 CET] <Daemon404> maybe i misremember; it's listed in the commit message
[17:50:41 CET] <Daemon404> hmm..
[17:50:57 CET] <Daemon404> next up are a whole boatload of patches related to lavu hwaccel api and cuda/nvenc
[17:51:05 CET] <Daemon404> this is likely over my head...
[17:51:07 CET] <wm4> blergh
[17:51:30 CET] <wm4> well lavu hwaccel is of course new, so no conflicts?
[17:51:40 CET] <wm4> but cuda/nvenc are a mess already
[17:51:52 CET] <Daemon404> nvenc: support CUDA frames as input
[17:51:57 CET] <Daemon404> stuff like this
[17:52:15 CET] <Daemon404> is the nvenc author on irc?
[17:52:18 CET] <Daemon404> he may be able to help.
[17:52:20 CET] <nevcairiel> could just skip that one and ping our maintainer for that if he is interested to add that
[17:52:40 CET] <Daemon404> indeed
[17:52:51 CET] <Daemon404> see above
[19:03:38 CET] <cone-478> ffmpeg 03Paul B Mahol 07master:38ed528fa5fe: avfilter/drawutils: >8 bit support
[19:05:18 CET] <cehoyos> Derek: Can you please revert this?
[19:05:39 CET] <cehoyos> Why are these merges necessary?
[19:07:11 CET] <BtbN> Daemon404, yes, I'm here. But I wonder how that's supposed to work. API-Only, so some application using CUDA has a way to send frames as On-GPU-Surfaces?
[19:07:30 CET] <cehoyos> Daemon404: Please revert the changes to configure, they are horribly broken.
[19:07:35 CET] <BtbN> Or is it that horrible nvidia-hack-patch that adds a full hw pipeline by monkey-patching litteraly everything.
[19:11:36 CET] <Daemon404> cehoyos, please give actual reasons.
[19:11:44 CET] <Daemon404> and actual usecases which are broken
[19:11:58 CET] <cehoyos> The following do not work correctly (some shamelessy stolen from Martin):
[19:12:02 CET] <cehoyos> ./configure --disable-everything
[19:12:03 CET] <Daemon404> there is alreaydy a fix for x11grab, and double disable/enable
[19:12:08 CET] <cehoyos> ./configure --enable-gpl --enable-gpl
[19:12:12 CET] <Daemon404> yes. there;s a fix.
[19:12:17 CET] <Daemon404> i just havent pushed it yet
[19:12:17 CET] <cehoyos> ./configure --disable-everything ---disable-network
[19:12:50 CET] <cehoyos> Please just revert this: These are just the first three things I tried.
[19:12:57 CET] <cehoyos> Why are you doing merges??
[19:13:11 CET] <Daemon404> cehoyos, i will not revert it if there is a fix.
[19:13:11 CET] <cehoyos> This is not only useless, it actually hurts development severly!
[19:13:17 CET] <Daemon404> if it is broken after the fix, we can talk.
[19:13:22 CET] <cehoyos> Where is a fix? Please point me to the fix!
[19:13:34 CET] <Daemon404> https://patches.libav.org/patch/59824/raw/
[19:14:03 CET] <Daemon404> [18:12] <@cehoyos> Why are you doing merges?? <-- because nevcairiel wanted a break.
[19:14:44 CET] <cehoyos> The patches neither fix --disable-everything nor --disable-networks
[19:14:52 CET] <cehoyos> No, I mean: Why are merges done at all?
[19:15:02 CET] <durandal_1707> they are doing evil merges, cehoyos 
[19:15:03 CET] <kierank> lol
[19:15:04 CET] <Daemon404> ... im not even going to dignify that with a response
[19:15:08 CET] <cehoyos> Please revert the changes to configure.
[19:15:19 CET] <Daemon404> cehoyos, how about you test the fix
[19:15:29 CET] <Daemon404> and stop beign so damn rude
[19:15:41 CET] <cehoyos> What?
[19:15:46 CET] Action: Daemon404 facedesk
[19:16:33 CET] <durandal_1707> cehoyos: could you wait 24h?
[19:16:54 CET] <cehoyos> The problem is not to wait now but that this breaks regression tests.
[19:17:01 CET] <Daemon404> i ran fate fully
[19:17:11 CET] <Daemon404> i linked you a possiblw fix
[19:17:18 CET] <cehoyos> If it will be fixed I don't care about changes but it can't stay like this, sorry.
[19:17:25 CET] <cehoyos> The fix does not work,, please read my posts!
[19:17:26 CET] <Daemon404> [18:13] <@Daemon404> https://patches.libav.org/patch/59824/raw/
[19:17:33 CET] <Daemon404> uh
[19:17:37 CET] <Daemon404> you did not say you tested it
[19:17:39 CET] <Daemon404> and that it didnt work
[19:17:44 CET] <Daemon404> please do point that out
[19:17:53 CET] <cehoyos> The patches neither fix --disable-everything nor --disable-networks <-- what else should this mean??
[19:18:02 CET] <cehoyos> [19:14] <cehoyos>
[19:18:40 CET] <Daemon404> considering i linked you one (single) patch, i did not think "patches" (plural) referred to it.
[19:18:54 CET] <durandal_1707> perhaps our configure is wastly different?
[19:18:54 CET] <cehoyos> Sorry, my fault!
[19:19:11 CET] <cehoyos> The patch you linked does not fix the issue with current configure in FFmpeg: Please revert the changes.
[19:19:53 CET] <Daemon404> give me more than 2 seconds to test this
[19:20:02 CET] <cehoyos> Please do!
[19:20:51 CET] <durandal_1707> cehoyos: can you wait?
[19:21:10 CET] <Daemon404> i cant see what is wrong with --disable-everything --disable-networks
[19:21:21 CET] <Daemon404> configure says networking is disabled if i do that
[19:21:33 CET] <Daemon404> (with the patch i linked above applied)
[19:21:33 CET] <cehoyos> It does not disable networks here;-(
[19:21:40 CET] <cehoyos> I have the patch applied.
[19:22:01 CET] <Daemon404> daemon404 at bbvm:~/dev/f/ffmpeg$ ./configure --disable-everything --disable-network | grep network
[19:22:04 CET] <Daemon404> network support           no
[19:22:22 CET] <cehoyos> Pleae compare the output of configure from yesterday with today.
[19:22:39 CET] <Daemon404> how about you tell me whats wrong
[19:22:40 CET] <Daemon404> with words
[19:22:40 CET] <durandal_1707> what changed?
[19:22:41 CET] <cehoyos> Or do "grep TCP config.h"
[19:22:46 CET] <Daemon404> because "output changed" is not a regression.
[19:22:52 CET] <cehoyos> network is not disabled, that is the difference.
[19:23:02 CET] <cehoyos> Of course not, you are right.
[19:23:07 CET] <Daemon404> i cannot reproduce this.
[19:23:17 CET] <Daemon404> daemon404 at bbvm:~/dev/f/ffmpeg$ grep TCP config.h
[19:23:17 CET] <Daemon404> #define CONFIG_MSNWC_TCP_DEMUXER 0
[19:23:17 CET] <Daemon404> #define CONFIG_TCP_PROTOCOL 0
[19:23:19 CET] <cehoyos> But if the relevant option is "--disable-network" and network is still enabled then it is a bug
[19:23:29 CET] <Daemon404> its not enabled
[19:23:45 CET] <cehoyos> I am on 38ed528fa5fe5cd1f47edb70090f65958fb1e8ce with the "raw" patch applied.
[19:24:16 CET] <Daemon404> even pre-patch it is not enabled
[19:24:34 CET] <Daemon404> i am on 6b706ce85fa56564986211b99d34e269066ca3d9
[19:24:56 CET] <Daemon404> let me pull to 38ed528fa5fe5cd1f47edb70090f65958fb1e8ce
[19:25:03 CET] <cehoyos> No, forget it!
[19:25:12 CET] <cehoyos> The only remaing issue is with --disable-everything.
[19:25:23 CET] <Daemon404> ok
[19:25:30 CET] <Daemon404> what is wrong with disable-everything
[19:25:31 CET] <cehoyos> It does not disable h264 and some demuxers (I thought the demuxers are related to network, but that may be wrong)
[19:26:40 CET] <jamrial> wouldn't that be something pulled by ffmpeg and/or ffprobe?
[19:27:01 CET] <jamrial> i know some filters are enabled that way
[19:27:24 CET] <Daemon404> cehoyos, where can i find martin's email?
[19:27:28 CET] <cehoyos> I am not talking about filters
[19:27:35 CET] <cehoyos> That is only related to enable-gpl
[19:28:41 CET] <cehoyos> Isn't it much easier for everybody of us if we just keep our working configure?
[19:28:44 CET] <jamrial> no, i mean, ffmpeg and ffprobe have select lines in configure that if i remember right override --disable-everything
[19:29:27 CET] <Daemon404> that shouldnt pull in h264
[19:29:31 CET] <cehoyos> Yes, you are absolutely right: ffmpeg does enable some filters with --disable-everything
[19:29:42 CET] <cehoyos> But currently several demuxers are enabled.
[19:29:49 CET] <Daemon404> i think i see what is pulling it in
[19:29:58 CET] <cehoyos> I thought this is network related but it may not be related at all.
[19:30:02 CET] <Daemon404> it's not
[19:30:20 CET] <cehoyos> Why do you believe it makes sense to try to fix this?
[19:30:51 CET] <cehoyos> Aren't you trippling the work like this?
[19:31:11 CET] <Daemon404> only yours.
[19:31:23 CET] <Daemon404> it fixes some other stuff, i'd like to have more than 5 bloody minutes
[19:31:24 CET] <Daemon404> to fix it
[19:31:33 CET] <Daemon404> instead of OMG REVERT NOW I CNAT HANDLE THIS FOR AN HOUR
[19:31:36 CET] <cehoyos> I am curious: What does it fix?
[19:31:44 CET] <kierank> cehoyos: can you shut up and let derek fix things
[19:31:54 CET] <cehoyos> I don't remeber shouting at you, please don't shout at me.
[19:32:04 CET] <kierank> or better still send a fix
[19:32:13 CET] <wm4> I have to second this
[19:32:20 CET] <cehoyos> Sorry, I don't understand why these patches have to be merged: Nobody claimed so far they fix anything.
[19:32:29 CET] <cehoyos> You want me to revert?
[19:32:29 CET] <wm4> don't bark just because it smells like Libav
[19:32:38 CET] <jamrial> no
[19:32:39 CET] <cehoyos> I only bark because it is broken.
[19:32:40 CET] <nevcairiel> bugs dont have to be fixed within 60 seconds, either contribute to help fix them, or sit by quietly and let derek work
[19:32:43 CET] <Daemon404> it's not broken
[19:32:46 CET] <Daemon404> nothing is failing
[19:32:51 CET] <Daemon404> it adds some extra compile time
[19:33:06 CET] <Daemon404> im looking ito it as we speak
[19:36:29 CET] <Daemon404> i think i see what is causing it
[19:46:57 CET] <Daemon404> ok
[19:47:00 CET] <Daemon404> i figured it out.
[19:47:08 CET] <Daemon404> cehoyos, i have a patch for you to test
[19:47:50 CET] <cehoyos> I am willing to test but please allow me to ask again: Why isn't it simpler to just revert?
[19:47:58 CET] <cehoyos> What is the advantage of the merged patch?
[19:48:26 CET] <Daemon404> some stuff (i think --disable-protocols) used to be incorrect
[19:48:42 CET] <Daemon404> however, your argument doesnt hold a lot of weight if nothing bad comes after fixing
[19:48:44 CET] <cehoyos> It worked fine here for years: Do you have an example of a non-working configure line?
[19:49:16 CET] <cehoyos> The real problem is: I only tested three configure lines and two didn't work, it's not easy to believe that this was the last issue.
[19:49:28 CET] <cehoyos> But I am still curious to hear what didn't work before:
[19:49:48 CET] <Daemon404> sorry, i dont buy your "revert now just in case" line
[19:49:53 CET] <cehoyos> I use --disable-everything (which includes --disable-protocols) every day so I believe I should have noticed.
[19:49:55 CET] <Daemon404> nor do i feel the need to have to defend it to you
[19:50:16 CET] <cehoyos> It would be enough if you could tell me what was fixed by the original patch...
[19:50:30 CET] <cehoyos> And as said: I only tested three lines, not more
[19:51:14 CET] <Daemon404> http://sprunge.us/bOAC
[19:51:21 CET] <Daemon404> with this patch, output matches
[19:51:41 CET] <Daemon404> i am not going to argue abotu reverting "just in case"
[19:51:49 CET] <Daemon404> if you feel so strongly, put it to the mailing list for a vote.
[19:51:58 CET] <cehoyos> Then please explain what was fixed!
[19:52:09 CET] <Daemon404> [18:49] <@Daemon404> nor do i feel the need to have to defend it to you
[19:52:11 CET] <cehoyos> Is the patch meant to be tested with the other patch, or just yours
[19:52:17 CET] <Daemon404> you are not the Almighty Gatekeeper
[19:52:24 CET] <cehoyos> No, definitely not!
[19:52:34 CET] <cehoyos> I just wonder why you are the new project maintainer...
[19:52:40 CET] <Daemon404> the patch i just libked applies to a clean git HEAD
[19:52:48 CET] <wm4> I wonder since when cehoyos was the project maintainer
[19:52:53 CET] <cehoyos> Is it meant to be tested together with the other patch?
[19:52:54 CET] <Daemon404> there's no such thing as a project maintainer
[19:52:57 CET] <Daemon404> more than one person can merge
[19:53:03 CET] <Daemon404> it is not the sole responsibility of one person
[19:53:06 CET] <cehoyos> I am not and I don't want to be (and I am not able to be)
[19:53:07 CET] <Daemon404> that would be stupid
[19:53:14 CET] <durandal_1707> since now
[19:53:46 CET] <cehoyos> You are the maintainer: You are committing unreviewed patches.
[19:54:15 CET] <cehoyos> Daemon404: Is the new patch meant to be tested together with the old patch or alone?
[19:54:15 CET] <jamrial> cehoyos: no, and please stop
[19:54:16 CET] <kierank> hahahahahahahahah
[19:54:18 CET] <durandal_1707> supreme overlord
[19:54:23 CET] <kierank> cehoyos: WOW
[19:54:27 CET] <jamrial> like, seriously, stop
[19:54:33 CET] <cehoyos> Stop what?
[19:54:42 CET] <cehoyos> Running --disable-everything every other day?
[19:54:44 CET] <Daemon404> cehoyos, alone
[19:55:01 CET] <kierank> cehoyos: do everyone a favour here and grow up
[19:55:09 CET] <kierank> instead of being the embarassment of the project
[19:55:22 CET] <jamrial> with all the stuff you're saying today. you could have just asked Daemon404 to check the regression you found, but instead came here asking for a revert and now start spouting things about maintainers
[19:56:14 CET] <durandal_1707> its free country, say wathever you want
[19:56:23 CET] <cehoyos> The following for example used to work, does not work anymore: configure --enable-libmp3lame --disable-libmp3lame --enable-libmp3lame
[19:56:27 CET] <Daemon404> durandal_1707, we're all in different countires, some may not be free!
[19:56:54 CET] <Daemon404> that's a separate bug 
[19:57:04 CET] <durandal_1707> wtf, I got headeache with that line
[19:57:23 CET] <cehoyos> jamrial: I asked last week the exact same question and I have two more: Why are we merging and what does the original configure patch fixes.
[19:57:43 CET] <cehoyos> Surprisinly, I don't get an answer, instead the usual accusaion that "I" should grow up
[19:57:55 CET] <cehoyos> (Which unfortunately doesn't hurt me at all, sorrry!)
[19:58:06 CET] <jamrial> we're merging because the changes may be useful. if they are not, or if they don't apply, the commit is added as a no-op
[19:58:09 CET] <durandal_1707> merging because it easier to follow
[19:58:13 CET] <Daemon404> you know what
[19:58:30 CET] <Daemon404> i dont volunteer my time helping an open soruce project 
[19:58:35 CET] <Daemon404> only to get shat on
[19:58:37 CET] <Daemon404> good day.
[19:58:42 CET] <kierank> cehoyos: look at the wonderful attitude you have
[19:58:50 CET] <wm4> cehoyos: thanks for pissing off someone who did hard work
[19:58:53 CET] <kierank> this is why we are a laughing stock
[19:58:58 CET] <cehoyos> I don't understand: What attitude are you talking about?
[19:59:02 CET] <wm4> cehoyos: yours
[19:59:06 CET] <cehoyos> Dreek?
[19:59:08 CET] <cehoyos> Hard work?
[19:59:09 CET] <wm4> cehoyos: yours
[19:59:12 CET] <jamrial> absolutely everything you've done today, cehoyos
[19:59:13 CET] <wm4> yes
[19:59:14 CET] <cehoyos> Are you jloking?
[19:59:15 CET] <wm4> merging is hard
[19:59:37 CET] <cehoyos> Why does he merge? There are enough bugs that people could look at!
[19:59:55 CET] <kierank> cehoyos: and when michael did it, it was fine for years?
[19:59:56 CET] <wm4> are you serious
[19:59:58 CET] <nevcairiel> just leave already before you drive more contributors off, thank you
[19:59:58 CET] <kierank> interesting double standard
[20:00:00 CET] <cehoyos> I am!
[20:00:06 CET] <jamrial> because we're interested in the changes made by libav
[20:00:22 CET] <cehoyos> And I still don't understand his attitude: I was testing a patch, and now he disappeared.
[20:00:24 CET] <kierank> This is the part where we act like adults and vote to ban carl
[20:00:27 CET] <kierank> but this won't happen
[20:00:29 CET] <cehoyos> What am I supposed to do now?
[20:00:40 CET] <jamrial> shut up, for starters. don't make things worse
[20:00:48 CET] <cehoyos> Very adult, yes!
[20:00:52 CET] <wm4> cehoyos: join another project?
[20:01:05 CET] <cehoyos> I like this project, you seem to prefer the dark side...
[20:01:08 CET] <nevcairiel> cehoyos: you are the one ranting over dereks work for the last hour, so give it a rest
[20:01:09 CET] <durandal_1707> mplayer
[20:01:09 CET] <jamrial> you turned what should have been regression report into a mess
[20:01:27 CET] <wm4> cehoyos: and stop with your pathetic Libav persecution complex
[20:01:39 CET] <atomnuker> come one guys, carl just reported stuff broke under some corner cases and everyone jumped up becase it's carl
[20:01:57 CET] <cehoyos> wm4: You haven't been the target of hate mails, afair, have you?
[20:02:12 CET] <wm4> I'm not interested in your affairs
[20:02:12 CET] <durandal_1707> he demanded revert
[20:02:26 CET] <cehoyos> I am happy if it gets fixed!
[20:02:40 CET] <cehoyos> But I am sure it is much easier to revert than to fix!
[20:03:06 CET] <cehoyos> So question to all the grown ups here: How do we proceed?
[20:03:08 CET] <jamrial> no, that's stupid
[20:03:08 CET] <durandal_1707> but Derek want to help
[20:03:22 CET] <kierank> cehoyos: we proceed by you not being a dick
[20:03:23 CET] <cehoyos> Derek disappeared: How does that help?
[20:03:25 CET] <kierank> but that's not possible
[20:03:26 CET] <wm4> cehoyos: apologize to derek
[20:03:29 CET] <kierank> he disappeared because of you
[20:03:32 CET] <cehoyos> About what?
[20:03:32 CET] <atomnuker> well, we patiently wait for a fix and try to help with it, simple as that
[20:03:34 CET] <kierank> and your disgusting behaviour
[20:03:48 CET] <jamrial> cehoyos: start by testing the patch derek wrote and report back if it fixed the bug you found
[20:03:59 CET] <jamrial> then drop the subject. you already did enough damage by being insufferable
[20:04:00 CET] <cehoyos> I did test it!
[20:04:05 CET] <cehoyos> I did post results here!
[20:04:10 CET] <cehoyos> What else do you want?
[20:04:36 CET] <wm4> anyway, drama is bad for the nerves, so have fun
[20:04:37 CET] <jamrial> did it work? did it fix the whole h264 with --disable-everything?
[20:05:00 CET] <cehoyos> No, from a quick test (only one line) it is still broken
[20:05:41 CET] <durandal_1707> now it will remain that because of you
[20:06:17 CET] <cehoyos> You mean without me reporting it would miracoulously have fixed itself?
[20:06:46 CET] <durandal_1707> if you only reported...
[20:06:47 CET] <cehoyos> Again: How do we continue?
[20:06:55 CET] <cehoyos> configure does not work correctly now...
[20:06:58 CET] <kierank> cehoyos: we continue by you apologising to derek
[20:07:14 CET] <jamrial> because instead of simply reported you turned this into a mess now derek is not here to fix the proble you found
[20:07:16 CET] <kierank> you clearly fail to realise it but you being rude to him is much worse than the minor bug
[20:07:16 CET] <cehoyos> For what exactly?
[20:07:21 CET] <cehoyos> Reporting an issue?
[20:07:26 CET] <cehoyos> Or suggesting a fix?
[20:07:31 CET] <jamrial> you didn't just repot
[20:07:38 CET] <kierank> cehoyos: http://zestbooks.net/how-not-to-be-a-dick/
[20:07:45 CET] <cehoyos> No, seriously: What can we do to fix the cofigure issue?
[20:07:53 CET] <nevcairiel> we are being serious
[20:07:53 CET] <cehoyos> Is there an alternative to reverting the change?
[20:07:54 CET] <jamrial> you reported, demanded a revert, then started criticizing merges, talked about maintainers, etc
[20:07:57 CET] <jamrial> you were annoying
[20:08:04 CET] <jamrial> you should have just reported
[20:08:07 CET] <jamrial> and waited for a fix
[20:08:10 CET] <jamrial> quietely
[20:08:13 CET] <cehoyos> No: I asked why merges are done and I did not recieve an answer.
[20:08:36 CET] <durandal_1707> I answered
[20:08:44 CET] <durandal_1707> and others
[20:08:45 CET] <kierank> can we vote to remove carl from the project
[20:08:47 CET] <cehoyos> Sorry, I missed it: Where is it?
[20:08:50 CET] <jamrial> and so did i
[20:08:56 CET] <jamrial> becuase we're interested in the changes added by libav
[20:09:14 CET] <cehoyos> jamrial: I am also interested in the patches, I just don't understand why they have to be merged without any review.
[20:09:17 CET] <jamrial> now, again, if you want to report something, do it, then don't mix it with your bullshit merge agenda
[20:09:29 CET] <kierank> cehoyos: and when michaelni did the merge for the last 4 years it was "reviewed" was it?
[20:09:31 CET] <durandal_1707> kierank: propose it on ml 
[20:09:33 CET] <kierank> interesting double standard
[20:09:40 CET] <kierank> durandal_1707: yes I will
[20:09:52 CET] <cehoyos> Why is it suddenly my agenda: For years, I have read from different people that the merges should stop, isn't now a good time?
[20:10:05 CET] <jamrial> no, it isn't
[20:10:06 CET] <durandal_1707> no
[20:10:18 CET] <cehoyos> keirank; You may have missed it but at that time FFmpeg had no choice, we had to do the merges.
[20:10:23 CET] <jamrial> can you shut up already? you already fucked up everything yet still go at it?
[20:10:28 CET] <jamrial> are you getting a kick out of this?
[20:10:37 CET] <cehoyos> What did I fuck up?
[20:10:42 CET] <jamrial> everything
[20:10:44 CET] <kierank> the entire multimedia community
[20:10:54 CET] <kierank> people like you are why we are a joke
[20:10:57 CET] <jamrial> the problem you reported is not fixed because you wouldn't shut up
[20:10:57 CET] <cehoyos> That's news to me!
[20:11:19 CET] <n00b81_> Stop with the exclamation marks dude
[20:11:22 CET] <durandal_1707> this is going nowhere
[20:11:23 CET] <jamrial> you should have just reported it then wait until it was fixed
[20:11:24 CET] <cehoyos> I always thought I helped the multimedia community not be taken over by thieves and copyright violators
[20:11:33 CET] <kierank> here we go
[20:11:39 CET] <jamrial> see? you can't keep issues separated
[20:11:43 CET] <cehoyos> Didn't I wait?
[20:11:44 CET] <jamrial> you keep pushing you shitty agenda
[20:11:50 CET] <kierank> jamrial: it's worse in person
[20:12:02 CET] <cehoyos> The agenda to stop the merges? As said, I don't think this is my agenda
[20:12:03 CET] <kierank> seriously carl, you have half a dozen people saying you are wrong
[20:12:07 CET] <jamrial> you're annoying, disrespectful, talk about things out of place all the time
[20:12:16 CET] <jamrial> you ruin everything every time you open your mouth
[20:12:32 CET] <cehoyos> But all this doesn't really help anybody: How can we fix configure?
[20:12:57 CET] <cehoyos> Sorry?
[20:13:03 CET] <cehoyos> Can you please undo this
[20:15:11 CET] <n00b81_> And you were so close to getting promoted to lead cheerleader captain too.
[20:15:50 CET] <n00b81_> sorry just lurking and enjoying this.
[20:15:52 CET] Action: n00b81_ leaves
[20:21:32 CET] <cone-478> ffmpeg 03Derek Buitenhuis 07master:02dfa64c088c: configure: Don't enable examples when --disable-everything is used
[20:31:21 CET] <cehoyos> Daemon404: Thank you, --disable-everything --disable-network still enables several demuxers that were not enabled before.
[20:31:32 CET] <kierank> he's not here
[20:31:34 CET] <kierank> I wonder why
[20:33:43 CET] <jamrial> cehoyos: he's not here, or did you miss the fact he left half an hour ago?
[20:33:58 CET] <jamrial> he didn't de-op or re-op you
[20:40:24 CET] <cehoyos> I know, I was hoping somebody forwards this to him, I am not convinced he reads -cvslog
[20:41:04 CET] <kierank> ...
[20:41:17 CET] <JEEB> I would recommend posting the cases where output differs together with the diff on the mailing list
[20:55:29 CET] <ubitux> where is tmm1 :(
[20:57:51 CET] <jas99> Hi guys
[20:57:58 CET] <jas99> anybody thr??
[20:58:45 CET] <ubitux> mmh, i must admit configure is quite broken currently
[20:58:46 CET] <jas99> knock knock!!
[20:59:00 CET] <jas99> oh hi ubitux
[20:59:44 CET] <ubitux> like, typically x11grab
[20:59:48 CET] <ubitux> pretty strange
[21:00:47 CET] <jas99> so ubitux completely ignored me
[21:00:55 CET] <jas99> pffff......
[21:01:50 CET] <kierank> that's what happens on irc
[21:01:56 CET] <kierank> you should just talk and see if someone responds
[21:02:03 CET] <jas99> lol iam new with irc
[21:02:12 CET] <jas99> you replied
[21:02:23 CET] <jas99> i feel happy :)
[21:02:38 CET] <jas99> hi @kierank
[21:03:01 CET] <kierank> hello
[21:03:23 CET] <jas99> so this is right place to discuss c++ libav lib
[21:03:26 CET] <jas99> right??
[21:03:38 CET] <ubitux> no
[21:03:51 CET] <cehoyos> jas99: Consider reading the channel topic, I believe it answers your question
[21:04:05 CET] <cehoyos> ubitux: Yes, could you send an email?
[21:04:28 CET] <jas99> oops
[21:04:39 CET] <ubitux> cehoyos: i feel like you already have a bunch of cases that fail; can you try --enable-x11grab to your list and send the mail instead?
[21:04:49 CET] <cehoyos> No.
[21:05:03 CET] <cehoyos> I mean: It would be much better if somebody else wrote the email, sorry
[21:05:04 CET] <ubitux> ok well then can you make me a list of the current failures?
[21:05:37 CET] <cehoyos> I had only tested two configure lines: "./configure --enable-libmp3lame --disable-libmp3lame --enable-libmp3lame" and "./configure --disable-everything"
[21:05:52 CET] <jas99> cehoyos: what about build issues??
[21:05:55 CET] <cehoyos> The first one is (I assume, I did not test) fixed by the non-yet-committed patch
[21:06:06 CET] <cehoyos> The second one enables several demuxers:
[21:06:32 CET] <cehoyos> asf, mpegts, rm and mov
[21:06:36 CET] <cehoyos> They were not enabled before.
[21:06:50 CET] <cehoyos> Sorry, wrong again: 
[21:07:09 CET] <cehoyos> i tested "./configure --disable-everything --disable-network" and this enables the following demuxers:
[21:07:14 CET] <cehoyos> asf, mpegts, rm and mov
[21:07:38 CET] <cehoyos> They were not enabled before, I just tested 2ec66ff8
[21:08:10 CET] <cehoyos> Version 2ec66ff8 enables no demuxers with "./configure --disable-everything --disable-network"
[21:09:13 CET] <cehoyos> Version 02dfa64c enables asf, mpegts, rm and mov with the same configure line
[21:09:23 CET] <iive> I really cannot believe what I'm reading here.
[21:10:09 CET] <ubitux> cehoyos: ok; i'm in the middle of review&testing, i'll do sth in the coming hour
[21:10:18 CET] <iive> Honestly, Derek commits something that he KNOWS is broken, and it is cehoyos fault for wanting to revert it?
[21:10:20 CET] <cehoyos> Don't worry, I have to leave now...
[21:10:31 CET] <cehoyos> I am not sure he knew it.
[21:10:51 CET] <cehoyos> He knew about --enable-gpl --enable-gpl but not the other issues.
[21:11:03 CET] <iive> And yes, Michael have been reviewing the merges and actually committing fixes right after them.
[21:11:23 CET] <iive> well, he could have waited, for these things to be fixed in libav before merging them.
[21:11:59 CET] <JEEB> he did do basic testing, such as making sure nothing breaks FATE (no idea how many configurations of it he did, of course)
[21:12:27 CET] <jamrial> iive: he did. that's why he reverted an old merge some weeks ago and now merged this stuff today
[21:13:37 CET] <cehoyos> Sorry, but I really don't think he reverted the old merge because he tested it...
[21:14:09 CET] <iive> jamrial: are you telling me the code he merged had no known bugs. Because the patch he pointed, indicates otherwise. the libav.org one
[21:14:45 CET] <jamrial> which patch?
[21:15:26 CET] <iive> <Daemon404> [18:13] <@Daemon404> https://patches.libav.org/patch/59824/raw/
[21:15:30 CET] <cehoyos> iive: Yes, but he didn't really know there were other issues.
[21:17:16 CET] <cone-478> ffmpeg 03Michael Niedermayer 07master:c4ac30909e50: avutil/hwcontext: Remove duplicate ;
[21:17:17 CET] <cone-478> ffmpeg 03Mark Reid 07master:f09449daa4f2: tests/fate: added dnxhr parser regression test
[21:19:08 CET] <cehoyos> Before I forget: Has anybody else seen this? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814807
[21:20:50 CET] <Compn> cehoyos : looks like persons' fate test sample is corrupted?
[21:21:01 CET] <cehoyos> No, unfortunately not.
[21:21:17 CET] <cehoyos> It looks reproducible between the last two runs.
[21:21:20 CET] <Compn> ah
[21:21:33 CET] <cehoyos> I suspect a gcc regression but who knows...
[21:21:38 CET] <nevcairiel> we have mips fate and it passes there
[21:21:49 CET] <cehoyos> With a different compiler.
[21:21:54 CET] <cehoyos> Do we really test 2.8.6?
[21:22:46 CET] <cehoyos> And with a different configure line
[21:26:56 CET] <durandal_1707> I can't enable x11grab_xcb any more
[21:29:04 CET] <jamrial> cehoyos: fate shows a couple 2.8.6 fate mips clients
[21:29:52 CET] <jamrial> gcc 4.4, though. that debian report uses gcc 5.3
[21:31:03 CET] <michaelni> if its imgtec mips probably best to CC the imgtec people if its loongson mips CC the loongson guys
[21:31:37 CET] <cehoyos> gcc-5_5.3.1-8 while gcc-5_5.3.1-7 worked well with FFmpeg 2.8.5
[21:31:54 CET] <cehoyos> I think it is older than imgtec vs loongson
[21:32:47 CET] <michaelni> the question is what hw it is, the hw manufactor is likely interrested to have it working be that a compiler bug or other
[21:33:50 CET] <cehoyos> There was a possibility to find out hw of Debian test systems, if I could just remember...
[21:34:26 CET] <cone-478> ffmpeg 03Aman Gupta 07master:2f26b67d557f: lavc/ccaption_dec: do not ignore repeated character commands
[21:34:27 CET] <cone-478> ffmpeg 03Aman Gupta 07master:5f5467e749f9: lavc/ccaption_dec: implement special and extended character sets
[21:34:29 CET] <cehoyos> Imagination Technologies
[21:34:49 CET] <RiCON> Timothy_Gu: "Environmnet" typo in fatebeta's header
[21:36:34 CET] <cehoyos> Last successes were on the same imgtec hardware and on "Cavium Octeon V0.3" by Movidis
[21:37:47 CET] <ubitux> cehoyos: --enable-libmp3lame x3 is fixed by the patch yes
[21:37:57 CET] <cehoyos> Loongson are mipsel (at least for Debian)
[21:38:04 CET] <cehoyos> ubitux: Yes, I had tested this.
[21:38:25 CET] <ubitux> you said "The first one is (I assume, I did not test) fixed by the non-yet-committed patch" so..
[21:38:31 CET] <ubitux> i had to test
[21:38:54 CET] <cehoyos> Sorry!
[21:39:04 CET] <ubitux> - dash ./configure --enable-gpl --enable-x11grab
[21:39:06 CET] <ubitux> x11grab cannot be enabled
[21:39:06 CET] <cehoyos> I had tested it before the latest commit to configure
[21:39:08 CET] <ubitux> :((
[21:39:21 CET] <cehoyos> It should not need --enable-gpl and it should be autodetected.
[21:39:42 CET] <ubitux> it needs it
[21:42:08 CET] <ubitux> x11grab was never autodetected btw
[21:42:14 CET] <cehoyos> Sorry, but I found another regression: libxcb is not autodetected anymore afaict
[21:42:15 CET] <ubitux> you might be mistaken with xcb
[21:42:27 CET] <cehoyos> I mean: It is not autodetected anymore.
[21:42:28 CET] <ubitux> well, that should be a good thing
[21:42:32 CET] <ubitux> ;)
[21:42:33 CET] <cehoyos> No?
[21:42:45 CET] <ubitux> we talked about that one already, but whatever
[21:42:49 CET] <cehoyos> That would be an undocumented unintended change of behaviour.
[21:42:56 CET] <ubitux> i'm sticking with x11grab right now
[21:43:06 CET] <ubitux> which is gpl, and always needed explicit enable
[21:43:16 CET] <cehoyos> Of course, you are right.
[21:43:44 CET] <cehoyos> Gtg, bye!
[22:07:53 CET] <michaelni> Do any (known) issues remain after the 3 configure patches i just posted?
[22:08:39 CET] <ubitux> michaelni: --disable-everything --disable-network now keeps some demuxer enabled
[22:08:53 CET] <ubitux> (it wasn't the case before)
[22:11:03 CET] <ubitux> michaelni: apparently, libxcb was also autodetected, which isn't the case anymore (but i don't care about that)
[22:26:31 CET] <michaelni> what does the original patch fix ?
[22:26:37 CET] <michaelni> i mean the merged one
[22:31:16 CET] <michaelni> the code that causes the problem looks "unclean" to me, it kind of messes the dependancy solver up
[22:32:15 CET] <michaelni> it looks almost like someone who doesnt understand the code is trying to "fix" it
[22:32:34 CET] <michaelni> but i might be wrong
[22:35:54 CET] <michaelni> does anyone have some testcases or something to test configure ?
[22:38:53 CET] <ethe> how does configure do the check_func, is there a way I can insert a macro depending on the OS for a specific function?
[22:40:38 CET] <ethe> I'm trying to have an optional check for a function depending on the OS
[22:41:32 CET] <ubitux> ethe: how about adding it to the SYSTEM_FUNCS list?
[22:41:55 CET] <ubitux> michaelni: adding regressions tests for configure sounds like a good idea
[22:42:12 CET] <michaelni> ubitux, yes that would be a very good idea
[22:42:22 CET] <ubitux> no idea about the original patch
[22:42:31 CET] <ethe> ubitux: what does that do?
[22:42:44 CET] <ethe> Maybe it'd help to explain what I'm actually trying to do
[22:42:57 CET] <nevcairiel> running configure takes ages on windows, please dont =p
[22:43:09 CET] <ubitux> nevcairiel: haha :)
[22:43:27 CET] <ubitux> ethe: it will test the existence of the function X and will define HAVE_X if so 
[22:43:43 CET] <ethe> oh. thanks
[22:44:03 CET] <ubitux> if you don't consider it a "system function", see how HAVE_LIST is built
[22:44:12 CET] <ubitux> you might find another list more appropriate
[22:45:27 CET] <ubitux> nevcairiel: maybe we could extract the whole enable/disable logic, and test it in standalone
[22:45:47 CET] <ubitux> that should be instant, since no fork or whatever would be involved
[22:46:50 CET] <ethe> although I still dont think that is the right solution; I've fixed issue #43, but you need to remove the non-osx sem_timedwait from line 2793 & 5755 to make it configure. What would be ideal is a way to change sem_timedwait checking to checking for dispatch_semaphore_wait if it's OSX (I'm also checking is this is in other OSes as well, I think it may be in FBSD)
[22:47:24 CET] <ethe> if dispatch_semaphore_wait is in*
[22:47:42 CET] <ubitux> michaelni: http://pastie.org/pastes/10726341/text
[22:49:33 CET] <ubitux> sounds weird that sem_timedwait is tested that way
[22:50:10 CET] <ubitux> maybe it should be in BUILTIN_LIST
[22:50:27 CET] <ubitux> with the other atomic, membarrier and friends
[22:55:02 CET] <iive> michaelni: carl asked quite significant question about these configure changes... what are they fixing/improving.
[23:16:12 CET] <ethe> ubitux I'm guessing that any function in the BUILTIN_LIST also gets a HAVE variable set?
[23:16:57 CET] <ubitux> yes, they end up in the sale HAVE_LIST in the end 
[23:17:10 CET] <ubitux> and there is no other usage afaict
[23:37:17 CET] <ethe> this is what I have so far: https://gist.github.com/anonymous/eb759174e887a6ddb765 at the moment HAVE_DISPATCH_SEMAPHORE_WAIT isn't actually set to 1 (although I'm not sure why), but if you manually set it, then it all works.
[23:40:13 CET] <ubitux> because it's not tested with the dispatch include at configure time probably
[23:40:23 CET] <ubitux> (you can check the config.log)
[23:41:21 CET] <ubitux> testing for the presence of the include could work, right?
[23:42:45 CET] <ethe> yes
[23:42:54 CET] <ubitux> like, maybe just add dispatch_dispatch_h to the HEADERS_LIST and add a check_header dispatch/dispatch.h along with the other
[23:43:06 CET] <ubitux> then you'll have a HAVE_DISPATCH_DISPATCH_H which you can check
[23:45:01 CET] <ethe> and leave sem_timedwait in BUILTIN_LIST?
[23:57:23 CET] <ubitux> ethe: i guess
[23:57:51 CET] <ubitux> ethe: your patch looks wrong though, because jack will fail to compile
[23:57:57 CET] <ubitux> even if configure passes
[23:58:08 CET] <ubitux> so you need to somehow keep the dependency mechanism
[23:59:14 CET] <ethe> yeah, if both HAVE_SEM_TIMEDWAIT and HAVE_DISPATCH_SEMAPHORE_WAIT are 0
[23:59:24 CET] <ethe> well it'd be HAVE_DISPATCH_DISPATCH_H now.
[00:00:00 CET] --- Thu Feb 18 2016