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

[burek]

[04:06:55 CET] <cone-532> ffmpeg 03James Almer 07master:21cd0228beca: avcodec/libopenjpegdec: fix mixed declarations and code
[04:06:55 CET] <cone-532> ffmpeg 03James Almer 07master:99388eb091d0: avcodec/libopenjpegenc: fix mixed declarations and code
[08:27:34 CET] <ubitux> mmh... fftw3...
[08:27:40 CET] <ubitux> why not simply improve our asm
[08:31:05 CET] <nevcairiel> because everyone can plug in an external library, improving our asm takes brains
[08:31:18 CET] <ubitux> maybe it is just for benchmark?
[08:32:23 CET] <nevcairiel> that would bbe a silly thing to add to the code
[10:03:20 CET] <ubitux> michaelni: do you want time to look at the sws/aarch64 hscale patch later, or i can apply?
[10:29:54 CET] <durandal_1707> so ok to apply j2k parser?
[11:54:33 CET] <ubitux> so for some reason
[11:54:49 CET] <ubitux> with ffmpeg -i dsc00451.jpg -vf scale=1024x1024 -f null -
[11:55:05 CET] <ubitux> on x86, it's going through yuv2yuvX_sse3
[11:55:18 CET] <ubitux> while on aarch64, it's going into yuv2planeX_8_c
[11:56:24 CET] <ubitux> why isn't it using ff_yuv2planeX_8_sse2 for example?
[11:56:31 CET] <ubitux> (on x86)
[11:57:35 CET] <ubitux> mmh it's also actually entering yuv2planeX_8_c
[11:57:37 CET] <ubitux> now i'm confused
[12:21:48 CET] <michaelni> durandal_1707 feel free to apply
[12:22:45 CET] <michaelni> ubitux, if you think the code is ok feel free to apply, iam no aarch64 asm guy
[12:23:03 CET] <ubitux> you're still sws guy so i was asking
[12:23:54 CET] <ubitux> michaelni: while i have you, did you see my sws question about the scale filters the other day?
[12:24:08 CET] <ubitux> @ubitux michaelni: double p = -2.196152422706632; (libswscale, spline code), is this 3*(1-sqrt(3)) or just a coincidence?
[12:24:10 CET] <ubitux> @ubitux i lack too much knowledge about this code to have meaningful remarks but it looks like it could involve the filter parameter
[12:24:12 CET] <ubitux> @ubitux sth like param * (1-sqrt(3)), like in other algorithms
[12:24:14 CET] <ubitux> this one ^
[12:30:17 CET] <ubitux> :(
[12:34:31 CET] <michaelni> ubitux, didnt see the spline question, must have missed it
[12:37:44 CET] <michaelni> ubitux, looks like 3*(1-sqrt(3))
[12:37:44 CET] <kierank> michaelni: did you see h264 segfault?
[12:39:17 CET] <michaelni> ubitux, anything could involve the filter param, why this one? does it look better for an image, if so please elaborate / provide the image
[12:39:33 CET] <michaelni>  & testcase
[12:39:49 CET] <michaelni> kierank, hmm, i dont immedeatly remember
[12:40:20 CET] <kierank>  https://trac.ffmpeg.org/ticket/5371#comment:1
[12:40:46 CET] <ubitux> michaelni: i was merely looking at the code trying to understand; that constant was/is an enigma to me, and when i saw it was apparently 3*(1-sqrt(3)) and that the other p computation in other filters were involving either 3 or param[0], i was wondering if there was any relationship
[12:41:13 CET] <ubitux> and if that p computation shouldn't be matching
[12:43:57 CET] <michaelni> ubitux, i suspect (but dont really remember) that numerical value was the result of some numerical optimization to result in a spline with continous derivates at the control points and specific properties at the ends
[12:44:20 CET] <michaelni> but i could be totally wrong
[15:07:14 CET] <atomnuker> how come so many video parsers check for PARSER_FLAG_COMPLETE_FRAMES yet only flac in libavformat enables that flag
[15:11:27 CET] <nevcairiel> its set if need_parsing is AVSTREAM_PARSE_HEADERS
[15:11:31 CET] <nevcairiel> which is rather commonb
[15:11:33 CET] <nevcairiel> -b
[15:12:33 CET] <nevcairiel> if a container knows its always split properly already, then it sets this and avoids the overhead
[15:48:05 CET] <ubitux> oh, i saved 4 mul and 1 add
[15:48:10 CET] <ubitux> let's do better.
[15:48:15 CET] <ubitux> zomg speed
[15:48:49 CET] <kierank> ubitux: can I ask why you use filters of specific sizes
[15:49:26 CET] <ubitux> common size of gl textures, and inputs are of known size
[15:51:13 CET] <Daemon404> tep2 next week, nevcairiel? wm4? ubitux?
[15:51:30 CET] <wm4> sure
[15:51:32 CET] <ubitux> i'm going to take some holidays, so it sounds perfect to me
[15:51:40 CET] <Daemon404> cool.
[15:51:42 CET] <JEEB> holidays... sounds so good...
[15:51:44 CET] <ubitux> i'll probably add a "sub_time_base" to codecpar
[15:51:44 CET] <Daemon404> i'd haunting me.
[15:51:49 CET] <JEEB> I'll probably get more active in a few weeks
[15:51:50 CET] <Daemon404> it's*
[15:51:58 CET] <JEEB> been doing long days for almost a year now
[15:52:12 CET] <wm4> Daemon404: what does "fiel" mean on the etherpad
[15:52:17 CET] <Daemon404> fiel atom
[15:52:21 CET] <wm4> oh
[15:52:25 CET] <Daemon404> the diff for those files is all a missinfg fiel atom
[15:52:29 CET] <Daemon404> related to ->field_order
[15:52:35 CET] <Daemon404> probably something i nffmpeg.c
[15:54:06 CET] Action: wm4 curses ffmpeg.c with foam coming from the mouth
[16:04:30 CET] <ubitux> foam or fiel ?
[16:04:37 CET] Action: ubitux goes out
[16:16:07 CET] <cone-671> ffmpeg 03Clément BSsch 07master:277408b7f16e: sws/aarch64/yuv2rgb: save a few mul and add
[16:38:18 CET] <nevcairiel> Daemon404: the field order problem is simple, ffmpeg.c derives the field order during playback from the frames, and then sets avctx->field_order appropriately, which doesnt seem like its "wrong" to do so in general .. and mov writes all its headers at the end of muxing, but codecpar only gets "generated" once when opening the muxer, and not updated afterwards
[16:38:38 CET] <nevcairiel> so in short, the compat code just doesnt cover such a use case
[16:38:59 CET] <nevcairiel> the use-case in itself doesnt seem entirely wrong, not sure its ever claimed anywhere you cant modify the avctx after opening the muxer
[16:39:22 CET] <nevcairiel> (in the past it was used for encoding even, it would get modified all the time)
[16:39:51 CET] <nevcairiel> we could add some hack-ish thing to refresh the value, or in particular only the field_order value, or something
[16:43:44 CET] <Daemon404> nevcairiel, hmm
[16:44:34 CET] <nevcairiel> it would of course get fixed for ffmpeg.c when its moved to codecpar, but there is a reason its not done in the same step, it allows to test the compat :)
[16:45:28 CET] Action: Daemon404 thinks the whole field_order thing is a tad iffy, but eh
[17:46:54 CET] <cone-671> ffmpeg 03Thilo Borgmann 07master:4ebf0b109cdb: lavu/dict: Add new flag to allow multiple equal keys.
[17:46:55 CET] <cone-671> ffmpeg 03Thilo Borgmann 07master:4d251723c0a1: lavfi: Add coreimage filter for GPU based image filtering on OSX.
[17:51:29 CET] <ubitux> -#define LIBAVFILTER_VERSION_MINOR  39
[17:51:31 CET] <ubitux> +#define LIBAVFILTER_VERSION_MINOR  40
[17:51:33 CET] <ubitux>  #define LIBAVFILTER_VERSION_MICRO 102
[17:51:35 CET] <ubitux> :(
[17:53:28 CET] <Daemon404> context?
[17:53:39 CET] <ubitux> 102 ’ 100 for micro
[17:53:46 CET] <Daemon404> i know
[17:54:02 CET] <ubitux> from last commit(s)
[17:54:03 CET] <nevcairiel> thilos commit, probably
[17:54:05 CET] <Daemon404> o ok
[17:55:00 CET] <wm4> I sure like how that dict API change was just pushed without proper discussion
[17:55:16 CET] <nevcairiel> wasnt there an discussion with people expressing concerns?
[17:55:30 CET] <wm4> just me
[18:33:04 CET] <BBB> I feel nowadays most concerns are just noe addressed
[18:33:18 CET] <BBB> if you ignore and push quickly, you dont have to address concerns
[18:33:24 CET] <BBB> not the first time that happens
[18:35:59 CET] <jamrial> if that happens, the person with the concerns should revert the commit
[18:36:03 CET] <jamrial> if people actually showed some resistance when this happens, and there was some concequence for those pulling this crap (no more commit rights for example) it would stop happening
[18:36:47 CET] <jamrial> but so far apathy and "whatever, fuck it" tends to favor the person pulling this crap
[18:41:58 CET] <BBB> I just feel Im too old to get into fights about this stuff
[18:42:16 CET] <Daemon404> it's a fundementaimbalance
[18:42:33 CET] <Daemon404> the people wanting to push thier (bad) code have 10x more energy to argue their point
[18:44:08 CET] <Daemon404> ... as i spot a ganesh patch to add fftw
[18:44:09 CET] <Daemon404> sigh.
[18:45:21 CET] <kierank> durandal_1707: do we have a moving zoneplate like gstreamer?
[18:52:13 CET] <wm4> "I believe I've figured out exactly what caused it: a commit to FFmpeg from Feb 9th that changed the optimization settings on GCC 4.9 or higher to not disable tree vectorization anymore when using [the default opt level of] -O3.  If I add -fno-tree-vectorize to FFmpeg's extra-cflags to force the old behavior, then mpv is fine.  I was using GCC 5.3.0."
[18:52:21 CET] <wm4> does anyone know about such an issue?
[18:52:45 CET] <wm4> (this is on 32 bit Windows)
[18:53:15 CET] <atomnuker> there was a large discussion around that, most people thought that gcc's vectorization was mature enough
[18:54:29 CET] <wm4> "thought"
[18:56:44 CET] <atomnuker> that bug says otherwise
[18:56:59 CET] <jamrial> it's not quite there yet. try to run fate vsynth tests on gcc 5.3 x86_64 linux with cpuflags set to 0, and watch huffyuv crash because of a miscompilation of diff_bytes_c()
[18:57:24 CET] <jamrial> nobody noticed or cared since there are asm versions for that
[18:58:31 CET] <jamrial> admitedly, the code in question is weird and was written this way because we disabled tree vectorization
[18:59:24 CET] <jamrial> every other c boilerplate dsp function compiles fine
[19:00:29 CET] <BBB> if it miscompiles, we should re-disable it
[19:00:32 CET] <BBB> and report bug to gcc
[19:01:11 CET] <jamrial> i tried to make a standalone test case but couldn't reproduce it that way
[19:01:39 CET] <jamrial> and didn't want to report yet another bug with instructions to compile ffmpeg and run a test suite
[19:02:20 CET] <nevcairiel> optimization bugs are hard to reproduce in minimal cases, unfortunately
[19:02:32 CET] <durandal_1707> kierank: wut?
[19:02:41 CET] <kierank> moving zoneplate filter
[19:03:08 CET] <jamrial> it's also far from important or critical, seeing we mmx optimized versions, so unless you're still rocking a pentium from 1993 you'll be fine
[19:03:45 CET] <wm4> " Atom Z3735F (Silvermont)"
[19:03:45 CET] <kierank> what other libs can we get rid of apart from dcadec
[19:05:10 CET] <durandal_1707> kierank: what it does?
[19:05:16 CET] <jamrial> libwavpak?
[19:05:24 CET] <jamrial> we have both decoder and encoders for that
[19:05:36 CET] <kierank> durandal_1707: https://www.youtube.com/watch?v=aRqkGs0o6h0
[19:05:37 CET] <durandal_1707> nothing because of Carl
[19:05:47 CET] <kierank> and it goes up and down
[19:05:47 CET] <durandal_1707> libnut
[19:05:58 CET] <atomnuker> whoa, we have a wavpack encoder
[19:06:54 CET] <durandal_1707> kierank: why you need it?
[19:07:03 CET] <kierank> it's a standard test pattern
[19:07:07 CET] <jamrial> someone could take the celt parts of the opus interal decoder and write an actual celt decoder, so we can get rid of libcelt
[19:07:21 CET] <nevcairiel> would that be enough to do that?
[19:08:32 CET] <durandal_1707> atomnuker: wavpack supports floats, which is awesome
[19:09:39 CET] <durandal_1707> kierank: I guess I will write one
[19:09:59 CET] <wm4> what do you think about making ffmpeg more modular
[19:10:05 CET] <wm4> like having external filters
[19:10:35 CET] <durandal_1707> nice idea, but my hands are tied
[19:10:58 CET] <llogan> durandal_1707: but then you can make compiz 3d desktop effect!~!!~11!!
[19:11:01 CET] <wm4> tied?
[19:11:25 CET] <durandal_1707> libav does mandate API
[19:11:42 CET] <kierank> I want to write a lower level lavfi api
[19:12:09 CET] <wm4> as in? no buffersrc/sink?
[19:12:13 CET] <durandal_1707> llogan: I still have no idea what is that..
[19:12:25 CET] <kierank> wm4: yeah just send things to filters manually
[19:12:39 CET] <wm4> durandal_1707: developing in Libav is actually less painful than in ffmpeg (shorter compile times, less insanity, less resistance to remove insanity)
[19:13:12 CET] <nevcairiel> if compile time is an argument for you, you are the one with insanity =p
[19:13:38 CET] <durandal_1707> less filters, decoders, demuxers, muxers, encoders..
[19:13:43 CET] <jamrial> wm4: --disable-everything --enable-what-i-want :p
[19:14:21 CET] <durandal_1707> but yes I get your idea
[19:14:29 CET] <llogan> durandal_1707: i guess he wants a VV->V filter? "cube spin" transition/wipe.
[19:14:36 CET] <wm4> doesn't help if you change central headers and then want to rerun fate with everything and such
[19:14:55 CET] <nevcairiel> our fate also tests substantially more
[19:14:57 CET] <nevcairiel> so there is that :p
[19:15:20 CET] <jamrial> and overall coverage is still poor
[19:15:28 CET] <nevcairiel> thats true
[19:15:39 CET] <durandal_1707> llogan: for free? No way
[19:15:46 CET] <wm4> and before michaelni got enough of merging, you didn't have to care about the ffmpeg side of things
[19:21:14 CET] <atomnuker> less insanity, less resistance to remove insanity << plenty of insanity got removed, the remaining insanity is there because people think there's a resistance to removing the insanity
[19:21:47 CET] <kierank> there is
[19:22:42 CET] <jamrial> atomnuker: carl put himself as "maintainer" of libutvideo just to have an argument against removing it
[19:22:56 CET] <llogan> what do we have yet? ffserver, libutvideo, several prores encs
[19:23:30 CET] <atomnuker> I'm sure if someone submits a patch again and properly explains why it needs to be removed it will be removed
[19:23:46 CET] <llogan> that would be the third attempt, IIRC.
[19:24:02 CET] <BBB> Im willing to fix the prores debacle as part of libav agreeing to merge our two projects back together
[19:24:06 CET] <BBB> I think I offered that before
[19:24:18 CET] <nevcairiel> thats never going to happen
[19:24:20 CET] <atomnuker> third time's always lucky... I think
[19:24:26 CET] <kierank> Our prores encoded files don't even work on real hardware
[19:24:30 CET] <BBB> then well have multiple prores encdecoders for a very long time
[19:24:30 CET] <jamrial> atomnuker: that's what happened last time. patch + arguments in favor of removing it. the result was carl doing what i said above
[19:24:34 CET] <nevcairiel> they are happy to live in their ignorant bubble, even if noone uses their project anymore
[19:25:00 CET] <BBB> I think they would be happier if we were nicer to them
[19:25:05 CET] <BBB> calling them ignorant doesnt help
[19:25:18 CET] <nevcairiel> i called their bubble that, not them!
[19:25:19 CET] <nevcairiel> :D
[19:25:26 CET] <llogan> kierank: with either encoder? (there are two, right?)
[19:25:41 CET] <BBB> you called them out for living in it
[19:25:50 CET] <kierank> llogan: yes
[19:26:21 CET] <nevcairiel> BBB: but thats what they do, may not be pretty but its the truth, ignore everyone else and work away
[19:27:39 CET] <kierank> They'll cherry pick so they aren't ignoring per se ;)
[19:28:28 CET] <llogan> I think Ronald has a better perspective though, having more experience working with them. also, one of them seem quite sensitive given the emails i got regarding responses on mailing list
[19:29:01 CET] <durandal_1707> kierank: are you saying that libav prores is better?
[19:29:07 CET] <BBB> I meet them occasionally
[19:29:12 CET] <BBB> so I talk with them about this stuff, yes
[19:29:29 CET] <BBB> I assume Daemon404 talks about this too, although maybe it got old after a while
[19:29:50 CET] <durandal_1707> where you meet them?
[19:29:59 CET] <BBB> durandal_1707: we all live in NY
[19:30:02 CET] <kierank> durandal_1707: no
[19:30:20 CET] <BBB> nevcairiel: blunt question - why are you interested in merging? do you work for some video ingestion company also?
[19:31:00 CET] <llogan> kierank: can you give a few examples of this hardware?
[19:31:27 CET] <jamrial> from what i've seen, they will work with you if your objective is to do something for the project. they will accept patches and maybe help you writing them
[19:31:33 CET] <kierank> Hyperdeck pro
[19:31:56 CET] <jamrial> they will however not work with you if your objective is to find some common solution between the two projects even with the argument of doing it for the sake of the end user
[19:32:27 CET] <durandal_1707> exactly
[19:33:21 CET] <llogan> kierank: oh, BM. i couldnt even get one of their capture devices to work for me...
[19:33:35 CET] <wm4> I'm interested in merging the projects because there are still some talented devs in Libav, and the split is causing lots of friction (having to merge their commits etc.)
[19:34:52 CET] <jamrial> wm4: they seemingly have no interest in a merge, and we have some really big boulders in the way of progress, like carl runing every attempt at diplomacy
[19:35:43 CET] <wm4> can we just fire carl
[19:36:10 CET] <jamrial> it would be nice if he at least stopped screaming "thieves and liars" like a broken record every time some remotely related subjects come up
[19:36:22 CET] <Compn> wm4 : combine powers with j-b to merge projects
[19:36:28 CET] <Daemon404> well he could also stop harass everyone via private email too
[19:36:30 CET] <Daemon404> but that wont happen
[19:37:54 CET] <kierank> Because certain people (TM) support Carl
[19:38:34 CET] <jamrial> support, or tolerate?
[19:38:41 CET] <atomnuker> excommunicate?
[19:38:59 CET] <kierank> Support and/or tolerate
[19:39:01 CET] <durandal_1707> that's possible?
[19:39:29 CET] <BBB> Im exactly with wm4, I want a merge because they have some very talented devs and I dont want them to just die out
[19:39:35 CET] <kierank> Yes ban him
[19:40:50 CET] <durandal_1707> tell him what is going to happen if he continues that
[19:40:56 CET] <nevcairiel> BBB: that would be my motivation as well, but i also dont have any delusions of that going well
[19:41:24 CET] <kierank> I will but we need people who stay silent like michaelni and ubitux to do what is best for the community
[19:42:20 CET] <ubitux> i highly doubt carl is the reason libav doesn't want to merge
[19:42:21 CET] <durandal_1707> also when is next meeting going to happen?
[19:42:44 CET] <ubitux> just like michael wasn't really the reason of not merging back either
[19:42:53 CET] <kierank> ubitux: irrespective of the merge he is the cancer of our community
[19:42:57 CET] <jamrial> ubitux: his attitude certainly doesn't help
[19:43:18 CET] <kierank> Creating a hostile environment does not attract new devs
[19:43:19 CET] <ubitux> i'll stay neutral
[19:43:19 CET] <jamrial> carl's i mean
[19:43:36 CET] <kierank> ubitux: and so you are part of the problem then
[19:43:39 CET] <BBB> carls behaviour at VDD was not exactly appreciated, to say it softly
[19:44:04 CET] <durandal_1707> what he did?
[19:44:07 CET] <BBB> they dont care as much about michaels
[19:44:23 CET] <BBB> as in, they can live with it, its not that they like it but it wont kill them to accept it
[19:44:29 CET] <BBB> carls behaviour is a hard blocker
[19:44:52 CET] <llogan> i appreciate some of the work he does on trac
[19:45:03 CET] <BBB> carl does not take criticisim or constructive suggestions to behavioural changes well, and tends to instead subtly insult the person asking him questions instead
[19:45:19 CET] <ubitux> kierank: i'm fine having him around, and i don't consider him an hindrance to the project; that's my own judgement and you're free to disagree, but i won't go into the witch hunting 
[19:45:21 CET] <BBB> the work he does on trac should not require his destructive behaviour towards libav users or developers
[19:45:26 CET] <BBB> I dont see how the two are connected
[19:45:41 CET] <kierank> ^this
[19:45:44 CET] <Compn> i dont think theres anyone on either project who cause too much trouble
[19:45:49 CET] <BBB> I could perfectly well imagine him continuing to write patches and do trac work, but without insulting libav users or developers
[19:46:41 CET] <kierank> ubitux: it is the attitude of saying "ah but he works on trac and sends patches which makes his insults ok" which is disgusting
[19:46:51 CET] <durandal_1707> Don doesn't want to leave admin of some ffmpeg commits stats web page...
[19:47:01 CET] <kierank> I have had this argument with atomnuker repeatedly as well
[19:47:23 CET] <ubitux> kierank: i'm not OK with the insults, but i don't want to be involved in social issues
[19:47:39 CET] <Daemon404> and thats why this is doomed to fail
[19:47:42 CET] <wm4> note that the resistance against cleanup isn't going to attract Libav either
[19:48:06 CET] <ubitux> it's not like i'm going to stop you from doing police work
[19:48:10 CET] <wm4> (although they'll probably remain stupidly stubborn on this anyway)
[19:48:11 CET] <kierank> ubitux: then by extension you approve Carl's behaviour
[19:48:18 CET] <kierank> Whether you like it or not
[19:48:21 CET] <Daemon404> ^
[19:48:26 CET] <jamrial> BBB: he wont change until he sees some real consequences for his toxic behavior. so far in his mind he seems to think the criticism is just a vocal minority and that the fact nothing bad happens ever is because of an implicit overall approval from the project
[19:48:45 CET] <ubitux> kierank: and i also approuve you doing the witch hunting which i do not want to be part of
[19:48:58 CET] <durandal_1707> insults can't be tolerated
[19:49:11 CET] <ubitux> something happened with him again btw?
[19:49:13 CET] <atomnuker> kierank: I did neversay it's okay
[19:49:19 CET] <BBB> jamrial: probably true, yes& are you suggesting I get back into policing?
[19:49:21 CET] <ubitux> or it's just the usual circle jerk? :)
[19:49:32 CET] <kierank> ubitux: so it's fine to have racists, sexists, homophobes in FFmpeg just as long as they write patches?
[19:50:11 CET] <ubitux> could be ok yes
[19:50:21 CET] <kierank> Then your views are abhorrent
[19:50:53 CET] <ubitux> tsss.
[19:50:59 CET] <llogan> i think i would have remembered racist stuff...
[19:51:08 CET] <llogan> etc.
[19:51:10 CET] <ubitux> we was just doing an analogy
[19:51:18 CET] <ubitux> about tolerating the intolerable
[19:51:22 CET] <durandal_1707> ubitux: he was dick on irc, remmember?
[19:51:39 CET] <Compn> the thing is, if it was just get rid of carl to merge the projects we would have done that already
[19:51:44 CET] <ubitux> yes? not like everyone has been without his flaws here
[19:52:05 CET] <ubitux> but again, why are we suddenly talking about carl?
[19:52:36 CET] <jamrial> because we started talking about libav and a potential merge
[19:52:52 CET] <jamrial> and the reasons it hasn't happened yet surfaced. hence carl
[19:52:56 CET] <ubitux> and so we needed a culprit about the situation?
[19:53:03 CET] <ubitux> which led to this stupid drama
[19:53:04 CET] <Compn> ubitux : there must be a scapegoat
[19:53:06 CET] <ubitux> while nothing happened?
[19:53:09 CET] <Compn> right
[19:53:22 CET] <Compn> nothing happened, no one talked about merging
[19:53:33 CET] <Compn> just kierank and daemon dont like carl
[19:53:36 CET] <ubitux> it's hard to believe there is so much emotional shit still hanging around
[19:55:08 CET] <llogan> so, how about that sports team?
[19:55:18 CET] <durandal_1707> no, everything happened, who can summon irc meeting?
[19:56:39 CET] <durandal_1707> ubitux: I wouldnt call it emotional shit
[19:57:04 CET] <ubitux> then what's with this sudden witch hunting and rage quits?
[19:57:43 CET] <durandal_1707> you said it all
[19:57:58 CET] <ubitux> then i got accused of not helping and being the reason of the drama
[19:58:08 CET] <llogan> burn him!
[19:58:14 CET] <ubitux> i can't call this being rational
[19:58:44 CET] <durandal_1707> writting patches and spreading shit is bad
[19:59:04 CET] <jamrial> kierank kinda overreacted, i agree with you in that regard
[19:59:54 CET] <ubitux> anyway, sure for an irc meeting
[20:00:00 CET] <ubitux> what do you want to discuss?
[20:00:09 CET] <ubitux> aside from kicking out carl
[20:00:12 CET] <ubitux> for no reason
[20:00:14 CET] <ubitux> :D
[20:00:21 CET] <durandal_1707> you don't want to have someone extremist to be part of project
[20:00:33 CET] <Compn> are you calling carl extremist?
[20:00:57 CET] <ubitux> i really think it doesn't matter to have a despisable person in the projet
[20:01:05 CET] <ubitux> BUT it shouldn't be expressed on the project ground
[20:01:15 CET] <durandal_1707> no, but he is certainly problematic personality
[20:01:21 CET] <ubitux> like, it's pretty ok if carl has his hate twitter stream
[20:01:28 CET] <ubitux> but doesn't express his view on the trac and mailing list
[20:02:01 CET] <durandal_1707> hmm, that is questionable
[20:02:14 CET] <michaelni> "so it's fine to have racists, sexists, homophobes in FFmpeg just as long as they write patches?" <-- if theres any racism, sexism, or gender/sexual preferance based attacks, please step in and do something about it, talk with the people involved and make it clear to them that this is not acceptable, also if that fails inform one of the maillist admins or irc ops about it
[20:02:23 CET] <ubitux> anyway, i'm obviously ok with punishment as part of actions within ffmpeg realm
[20:02:54 CET] <ubitux> (i won't do it personally because i don't feel like being too much involved in this, but feel free to)
[20:03:23 CET] <phh>    v bv 
[20:03:28 CET] <phh> fail
[20:04:10 CET] <llogan> phh: VBV can be achieved with -maxrate and -bufsize
[20:10:36 CET] <llogan> due to spam the cvslog entries for web commits may be delayed because messages "from" ffmpeg-cvslog are not set to go to queue until i make an appropriate filter
[20:10:50 CET] <llogan> *are set to go to queue
[20:15:44 CET] <Compn> i mean
[20:15:51 CET] <Compn> kierank and daemon should just say it
[20:15:54 CET] <Compn> they go or carl goes
[20:16:35 CET] <durandal_1707> why coreimage filter have m extension?
[20:16:52 CET] <nevcairiel> because its objective c
[20:19:20 CET] <BBB> Compn: I dont think they want carl to go
[20:19:41 CET] <BBB> Compn: I think they would like carl to be quiet when it comes to libav matters or responding to libav users or devs
[20:23:03 CET] <Compn> maybe i misread then
[20:54:28 CET] <BBB> Compn: we all agree carl is very valuable and does lots of good stuff, like trac work and patches to address a whole bunch of bugs that usually come from user reports
[20:54:50 CET] <BBB> Compn: all of that is very valuable and helpful and we dont want to lose that, just like we dont want to lose the libav contributors by killing libav
[20:56:20 CET] <Compn> i would love to find a solution 
[20:56:31 CET] <Compn> maybe people just dont want to work with each other
[20:56:34 CET] <Compn> cant change that BBB
[20:57:16 CET] <BBB> we can try :) Im not that pessimistic
[20:57:31 CET] <BBB> lots of people tell me you cant write a vp9 decoder that is faster than the fastest vp8 decoder
[20:57:41 CET] <BBB> lots of things cant be done according to naysayers
[20:57:43 CET] <BBB> Im a yaysayer
[20:58:04 CET] <BBB> its easy to say cant be done, but heroes are born when you do these thigns anyway
[20:58:09 CET] <BBB> We Can Do This
[20:58:22 CET] <wm4> no we can't!
[20:59:03 CET] Action: llogan signs up for BBB's motivational speech series, "How to Collaborate Powerfully"
[20:59:15 CET] <BBB> \o/
[20:59:19 CET] <BBB> my first subscriber ever
[20:59:29 CET] Action: BBB awards llogan a plaque for being the first BBB follower ever
[21:11:07 CET] <llogan> does anyone here know anyone what actually uses ffserver?
[21:11:56 CET] <JEEB> quite a bit of people on #ffmpeg are trying to use it, which most community members seem to try and not have happen as it has been noticed that almost nobody uses it from the core group
[21:12:35 CET] <JEEB> and in most cases you have better alternatives, such as nginx-rtmp (which takes in rtmp and delivers HLS/DASH with its NIH'd muxer to the clients)
[21:13:20 CET] <wm4> "trying to use it"
[21:13:22 CET] <wm4> I  love that
[21:13:30 CET] <JEEB> yes
[21:13:34 CET] <wm4> it's like ffserver has masochistic devs behind it
[21:13:36 CET] <wm4> err
[21:13:38 CET] <wm4> sadistic
[21:13:42 CET] <wm4> S&M devs
[21:14:19 CET] <llogan> i'm considering a survey on the ML asking if anyone actually uses it (successfully).
[21:14:25 CET] <wm4> not like ffmpeg CLI is much nicer (just look what at the result if you naively try to transcode a file, if you can even guess the syntax)
[21:14:51 CET] <J_Darnley> At least people can tell you how to use ffmpeg.
[21:15:04 CET] <JEEB> basically <join #ffmpeg> -> "hi I just found ffserver but I can't wrap myself around it" -> "uhh, hi. the thing is barely if at all maintained. unless you think you can start maintaining it, please just try using ffmpeg and maybe an actual separate streaming server such as *cast or nginx-rtmp instead"
[21:15:07 CET] <TD-Linux> the problem is with ffserver, no one can tell you how to use the alternatives either
[21:15:20 CET] <J_Darnley> People who know how to use ffserver don't exist or want to keep the secret sauce to themselves.
[21:15:41 CET] <JEEB> yeah, I've seen people note that they use ffserver in production, but it's definitely some sort of black arts
[21:15:47 CET] <wm4> why don't the ffserver defenders try to write a good ffmpeg-based streaming server?
[21:15:57 CET] <wm4> to replace it
[21:15:58 CET] <nevcairiel> because thats effort
[21:16:04 CET] <JEEB> probably because ffserver already exists and might be doing what they need :D
[21:16:05 CET] <J_Darnley> Because the competition might use it!
[21:16:23 CET] <llogan> or if i submit a patch to prune it, will any actual users defend it?
[21:16:43 CET] <JEEB> probably not, just people who have heard of people using it
[21:16:51 CET] <TD-Linux> llogan, it would be nice to make a mapping of all of ffserver's features to other open source projects
[21:16:54 CET] <wm4> oh fuck ganesh going on about intrinsics and inline asm again
[21:17:08 CET] <JEEB> or if you're lucky, that one guy who posted patch or so a few months ago
[21:17:24 CET] <llogan> TD-Linux: is such a thing even possiburu? does anyone actually know ffserver's features?
[21:17:44 CET] <TD-Linux> llogan, that's the point of the exercise in making the mapping :)
[21:17:51 CET] <JEEB> wm4: if he wants to optimize stuff just tell him to start conversion of the openhevc crap into proper asm :V
[21:17:56 CET] <JEEB> will keep him busy for a while
[21:18:57 CET] <wm4> he doesn't want to write yasm
[21:19:04 CET] <JEEB> unsurprising
[21:19:10 CET] <wm4> for some reason he thinks inline asm is better
[21:19:35 CET] <JEEB> intrinsics I can kind of understand, those are shared by a lot of compilers and are supported for both 32bit and 64bit
[21:19:47 CET] <JEEB> inline asm for archs that don't need to have that... eww
[21:20:03 CET] <ethe> is yasm much better than intrinsics?
[21:20:23 CET] <J_Darnley> I think so
[21:20:24 CET] <TD-Linux> in general yes, because you can do sane register allocation
[21:20:36 CET] <J_Darnley> 1 instruction for movd rather than a dozen functions
[21:21:01 CET] <ethe> ah right. yeah, that would make sense.
[21:21:31 CET] <TD-Linux> though for some things I've been able to make intrinsics that compile identically to hand written assembly
[21:21:34 CET] <JEEB> of course, as can be seen by the openhevc stuff, you can still gain nicely by doing intrinsics
[21:22:03 CET] <JEEB> you will get some extra from making it proper asm, but at that point it becomes a case of "is it worth it time-wise"
[21:23:11 CET] <JEEB> nev seems to be maintaining the openhevc patches from when they last tried to kind of upstream things in his fork so they could be built with latest FFmpeg
[21:24:09 CET] <wm4> and everyone uses them
[21:24:41 CET] <JEEB> yeah, since they enable much faster playback - even though they are intrinsics
[21:38:28 CET] <jamrial> it's not so much "getting a bit more performance than intrinsics" as it's "making sure we're not dependant on the compiler doing a good job"
[21:39:03 CET] <JEEB> true that
[22:02:51 CET] <nevcairiel> this thilo guy reads like an argument with carl, just less bad english
[22:09:01 CET] <nevcairiel> and of course noone else will ever say anything to the topic, adn the guy never ever see that his behavior wasnt quite perfect
[22:14:35 CET] <cone-057> ffmpeg 03Paul B Mahol 07master:e2298b3fccde: avcodec/jpeg2000dec: account two last bytes from end of bytestream as EOC marker
[22:14:35 CET] <cone-057> ffmpeg 03Paul B Mahol 07master:585cfabb799d: avcodec/jpeg2000dec: add slice threading support
[22:16:27 CET] <wm4> nevcairiel: there's an ease of contributing vs. code quality trade-off
[22:17:07 CET] <wm4> I'm not sure where it should be, and also the requirements seem to be quite inconsistent in ffmpeg
[22:17:50 CET] <ethe> Timothy_Gu: could I get a link to that gist again (the one with the asm explained), I'd like to convert the rest of the inline to yasm? (but I lost the patch because I had to reimage)
[22:18:01 CET] <nevcairiel> getting changes to a public API reviewed and OKed isnt an outrageous requirement
[22:18:07 CET] <ubitux> llogan: pretty sure the ffserver users will not answer to the survey
[22:18:30 CET] <ethe> remove it and see how long it takes people to notice
[22:19:10 CET] <ubitux> pretty sure you can apply this logic to about 70% of the code
[22:19:20 CET] <ubitux> and no one will notice until about 1 month to a year
[22:19:33 CET] <ubitux> that doesn't mean we should do that
[22:19:49 CET] <nevcairiel> how obnoxious ffserver has been, i bet it causes complaints within a week
[22:20:01 CET] <Daemon404> nobogy using ffserver SHOULD be using it
[22:20:07 CET] <Daemon404> it's the best solution to 0 problems
[22:20:17 CET] <ubitux> the thing is, ffserver users aren't using ffmpeg/master
[22:20:24 CET] <ubitux> they're with their centos etc
[22:20:37 CET] <nevcairiel> so, ffmpeg 0.8?
[22:20:38 CET] <ubitux> so unless you get phoronixed, no one will tell
[22:20:42 CET] <jamrial> so they will not care if ffserver is gone in 3.1? :p
[22:21:06 CET] <Daemon404> why dont you ask the "maintainer" to make it kosher with tep2, or rm it
[22:21:09 CET] <Daemon404> end of story
[22:21:15 CET] <Daemon404> if it cant be done, rm it.
[22:21:21 CET] <ubitux> is it blocking tep2?
[22:21:27 CET] <nevcairiel> who knows
[22:21:31 CET] <ubitux> if it's just vomitting warning it doesn't matter
[22:21:32 CET] <nevcairiel> i have no idea how it works
[22:21:39 CET] <Daemon404> ubitux, it will break when stuff deprecated in tep2 is removed
[22:21:44 CET] <Daemon404> it uses ffm to serialize an avctx or some shit
[22:21:45 CET] <nevcairiel> thats 2 years
[22:21:51 CET] <ubitux> that ^
[22:21:51 CET] <Daemon404> and uses it to "communicate"
[22:22:06 CET] <ubitux> so it will automatically be deleted in 2 years
[22:22:11 CET] <ubitux> unless the maintainer does his job
[22:22:11 CET] <nevcairiel> but i dont know if it starts breaking to some degree if ffmpeg.c uses codecpar instead of codec
[22:22:15 CET] <Daemon404> ubitux, sure ok
[22:22:19 CET] <Daemon404> thats the same deal :P
[22:22:29 CET] <nevcairiel> i have no idea how ffserver interacts with avformat
[22:22:33 CET] <ubitux> less aggressive than dropping it in a merge
[22:22:35 CET] <ubitux> ;)
[22:22:37 CET] <nevcairiel> is it self-contained, or does it use ffmpeg.c?
[22:22:43 CET] <wm4> I don't even understand what ffserver does
[22:23:04 CET] <nevcairiel> or do you use ffmpeg.c on the clientside of a ffserver?
[22:23:05 CET] <JEEB> it's weird, you have ffm files yet often you see people also using ffmpeg with it
[22:23:19 CET] <ubitux> wm4: it serves feed which you push to it with ffmpeg only, because it's abusing a weird cache file
[22:23:20 CET] <Daemon404> it uses ffm to configure the other side
[22:23:27 CET] <TD-Linux> on my TODO list for a while has been to set up a webcam using the various open source live streamers so I can actually recommend one to people
[22:23:42 CET] <Daemon404> TD-Linux, probably OBS is your best bet
[22:23:44 CET] <TD-Linux> (other than icecast)
[22:23:45 CET] <nevcairiel> if it uses all these crazy properties in the ffm, then those will no longer be communicated to the decoder after tep2 if it uses ffmpeg.c
[22:23:46 CET] <Daemon404> lots of people on twitch use it
[22:23:49 CET] <nevcairiel> so who knows what happens
[22:24:06 CET] <TD-Linux> Daemon404, but OBS is only a source client right?
[22:24:13 CET] <Daemon404> yeah
[22:24:23 CET] <Daemon404> i bet vlc can view it though :P
[22:24:28 CET] <Daemon404> not that that is ag reat soluton
[22:24:31 CET] <Daemon404> solution*
[22:24:41 CET] <JEEB> OBS can push to something like nginx-rtmp tho
[22:24:43 CET] <TD-Linux> I was thinking of things more like Icecast but for HLS or DASH
[22:24:52 CET] <nevcairiel> i used obs with nginx-rtmp last year
[22:24:53 CET] <nevcairiel> worked ok
[22:24:59 CET] <Daemon404> TD-Linux, then you want to do what jeeb said
[22:25:06 CET] <Daemon404> nginx has modules for dash and hls and rtmp
[22:25:11 CET] <Daemon404> iirc obs can feed this
[22:25:15 CET] <nevcairiel> it can
[22:25:23 CET] <TD-Linux> ok I'll try out nginx-rtmp and see how it goes
[22:25:32 CET] <nevcairiel> dash didnt really work for me with nginx, but i didnt spend too much time on it
[22:25:39 CET] <nevcairiel> just used rtmp since i had only a small client base
[22:25:39 CET] <JEEB> it has some NIH'd muxer
[22:25:48 CET] <JEEB> for both HLS and DASH output
[22:25:58 CET] <Daemon404> the hls muxer was pretty decent iirc
[22:26:01 CET] <Daemon404> minimal mpegts overhead
[22:26:09 CET] <Daemon404> a certain large cdn uses it
[22:26:12 CET] <Daemon404> (not akamai)
[22:27:47 CET] <TD-Linux> looks like it lacks a webm muxer as well
[22:28:31 CET] <Daemon404> because nobody cares about streaming webm live
[22:28:32 CET] <kierank> what do we need faac for?
[22:28:33 CET] <Daemon404> except youtube
[22:28:38 CET] <Daemon404> kierank, we dont
[22:28:45 CET] <ubitux> durandal_1707: zoneplate demo somewhere?
[22:28:46 CET] <kierank> ok that's getting choppe
[22:28:53 CET] <J_Darnley> heaac, no?
[22:29:02 CET] <JEEB> faac has no he-aac
[22:29:15 CET] <J_Darnley> oh, is that fdk then?
[22:29:17 CET] <JEEB> fdk-aac and already removed libaacplus were the only he-aac encoders
[22:29:22 CET] <JEEB> ye
[22:29:30 CET] <Daemon404> fdk isnt gonna be removed any time soon
[22:29:44 CET] <JEEB> yeah, and it shouldn't be until we get a good HE-AAC encoder
[22:29:58 CET] <nevcairiel> its also still better at LC
[22:30:10 CET] <nevcairiel> although claudio is working on more improvements
[22:30:11 CET] <wm4> Daemon404: that's sad, webm should be relatively nice for streaming?
[22:30:23 CET] <wm4> although no reason not to use mpegts I guess
[22:30:27 CET] <durandal_1707> ubitux: its moving circles around
[22:30:41 CET] <ubitux> what's the use case?
[22:31:00 CET] <Daemon404> wm4, nice in what way
[22:31:14 CET] <Daemon404> it's webm dash.
[22:31:17 CET] <durandal_1707> kierank needs it, look at yooutube video's
[22:31:27 CET] <ubitux> url?
[22:31:29 CET] <wm4> Daemon404: I mean as opposed to fragmented crap
[22:31:37 CET] <Daemon404> wm4, webm *dash*
[22:31:40 CET] <Daemon404> it IS fragmented
[22:31:48 CET] <wm4> yeah, I didn't get that before
[22:33:35 CET] <durandal_1707> ubitux: on phone now, for usecase search 4k zoneplate on YouTube 
[22:34:57 CET] <ubitux> ok thx
[22:35:06 CET] <jamrial> ubitux: as kierank posted above https://www.youtube.com/watch?v=aRqkGs0o6h0
[22:35:18 CET] <ubitux> i missed that, thx
[22:35:34 CET] <ubitux> is this a stress test for wavelet codecs?
[22:36:03 CET] <TD-Linux> Daemon404, webm fragements aren't really 1:1 comparable to mp4 fragmenting though
[22:36:09 CET] <ubitux> i wonder what kind of artifacts it raises
[22:36:59 CET] <TD-Linux> as all the stuff it uses was already there (cue points)
[23:25:11 CET] <llogan> kierank: i don't see very many users using libfaac anymore
[23:25:37 CET] <kierank> I see
[23:35:22 CET] <Compn> kierank / Daemon404 : so did you want carl to leave or carl to stop harassing libav and users? i wasnt clear on what you were saying.
[23:35:41 CET] <llogan> here we go again...
[23:42:56 CET] <BtbN> Would it be worthwile merging vf_hwupload and vf_hwdownload from libav? Or is that about to happen anyway, and the merges just haven't got that far yet?
[23:43:40 CET] <BtbN> https://git.libav.org/?p=libav.git;a=commit;h=07a844f32ebb78503981df017fa3ebfedb75fe1c it seems to be rather new
[23:44:18 CET] <Daemon404> BtbN, all new merges are waiting on the tep2 work
[23:44:29 CET] <BtbN> ah
[23:44:29 CET] <JEEB> so feel free to contribute to the TEP2 effort
[23:44:32 CET] <JEEB> :)
[23:44:35 CET] <BtbN> What even is that?
[23:45:39 CET] <BtbN> I'm thinking about writing a NVCUVID based h264 decoder, and that automated CUDA hwframe up/downloading would come very handy there.
[23:54:16 CET] <BtbN> Uhm, isn't that check incomplete?
[23:54:17 CET] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=configure;h=feb0bc287bc8c7e6f730d7b62a75212617fbec89;hb=HEAD#l5519
[23:54:36 CET] <BtbN> Or does check_lib automaticaly fail/disable cuda somehow?
[23:57:08 CET] <BtbN> Yeah, it is. --enable-cuda works even on systems without CUDA.
[23:57:26 CET] <nevcairiel> should fail to compile i guess
[23:57:47 CET] <BtbN> Yeah, it fails to build, but shouldn't configure fail already? What else is the point of that check_lib call?
[23:59:41 CET] <BtbN> https://gist.github.com/ccf56f8a31fbe004d1b2 like this
[00:00:00 CET] --- Sat Mar 26 2016