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

[burek]

[00:00:20 CET] <nevcairiel> i'm not only talking about the msvc thing, but the original patch that broke it as well
[00:00:30 CET] <nevcairiel> just get rid of it, let him rework in peace, or maybe just forget
[00:02:07 CET] <nevcairiel> i should stop caring and just maintain my own fork, revert all the shit from andreas
[00:02:24 CET] <BBB> thats barely any better
[00:02:39 CET] <BBB> but broken/controversial stuff is pushed too fast nowadays, not just by him
[00:02:50 CET] <BBB> In The Old Days, Everything Was Better
[00:05:22 CET] <wm4> BBB: by who else, ganesh?
[00:05:32 CET] <wm4> I say take push rights from those two
[00:06:12 CET] <BtbN> Time to move to Github and do PR-Only. With automatic sanity checks and forced reviews before anything can be merged.
[00:06:36 CET] <BBB> yeah, I asked ganesh to revert a patch that he committed with me as reviewer/approver, except I never reviewed it, and I certainly did not approve of it
[00:06:39 CET] <BBB> he refused
[00:08:44 CET] <nevcairiel> everyone that sends 3 patches gets push access these days
[00:11:40 CET] <jamrial> BBB: you should have told ganesh that his "nack" meant jackshit since the patch was never approved and he even went and said you reviewed it
[00:11:43 CET] <jamrial> followed by a revert
[00:14:22 CET] <iive> ganesh again?
[00:14:31 CET] <jamrial> no, this was a week or so ago
[00:15:08 CET] <durandal_1707> even if patch improves code?
[00:15:53 CET] <BtbN> If someone pushes something and claims that I approved/reviewed it in the commit, and I clearly didn't, I'd just push a revert, no matter what the patch is.
[00:16:58 CET] <jamrial> basic netiquette, which ganesh seems to lack
[00:17:12 CET] <BBB> jamrial: I hate to get into bitchfights, I guess...
[00:18:13 CET] <nevcairiel> BBB: its annoying if you try to be nice and follow the rules, while the others dont, isnt it
[00:19:15 CET] <BBB> annoying, or maybe just frustrating
[00:19:26 CET] <jamrial> if he does anything like that again he should have his push access revoked
[00:20:05 CET] <iive> i'm starting to think that you all are talking about 2 or 3 different things here...
[00:21:11 CET] <jamrial> iive: no, this is about ganesh. the earlier stuff was about andreas
[00:23:57 CET] <iive> jamrial: so.. ganesh have pushed a patch, without waiting for review, approved by himself and this patch breaks stuff?
[00:24:31 CET] <iive> or worse, he says it is approved by somebody who haven't approved it for real.
[00:25:24 CET] <BBB> that, yes
[00:28:56 CET] <durandal_1707> the push acess should be given for contributing big stuff
[00:30:29 CET] <jamrial> iive: he pushed a patch that never made it to the ml in the first place
[00:30:35 CET] <jamrial> he sent something, was told it was ok if he made a simple change before pushing, then he instead did a full rewrite and pushed something completely different saying it was reviewed
[00:30:48 CET] <durandal_1707> Not oneliners
[00:30:53 CET] <jamrial> then, when the person that "reviewed" it asked for it to be reverted, he said "no"
[00:31:46 CET] <iive> oh.. what a mess.
[00:37:52 CET] <iive> what patch is that?
[00:44:22 CET] <jamrial> isfinite fallback
[03:17:33 CET] <nevcairiel> plot twist: the msvc "fix" patch doesn't actually work, my fate boxes are still broken
[07:14:54 CET] <andrewrk> nevcairiel, please give a spoiler alert before saying something like that
[07:15:00 CET] <andrewrk> some of us having seen that movie yet
[12:34:01 CET] <durandal_1707> filter_design still mentions obsolete stuff
[13:01:39 CET] <BtbN> This msvc patch discussion is getting stupid...
[13:03:35 CET] <wm4> it's just because andreas is being stubborn and impatient
[13:04:03 CET] <BtbN> "You're very quick to suggest a revert here" Dude, you pushed it after _5 minutes_
[13:05:37 CET] <nevcairiel> Feel free to tell him on the ML
[13:13:48 CET] <Daemon404> so uh
[13:13:57 CET] <Daemon404> isnt this *why* one restricts push access
[13:14:06 CET] <Daemon404> to stop this sorts of stupid things
[13:14:13 CET] <Daemon404> revert wars / hack pushes
[13:15:16 CET] <nevcairiel> Don't tell us, tell whoever gives push access out these days
[13:15:33 CET] <wm4> nevcairiel: michaelni does
[13:20:03 CET] <durandal_1707> clearly that power should be given to comitte 
[13:24:13 CET] <Daemon404> "
[13:24:15 CET] <Daemon404> Thus I object to reverting this before the regression caused by 31741ae is fixed."
[13:24:18 CET] Action: Daemon404 sighs
[13:25:24 CET] <wm4> that's a load of bullshit
[13:25:46 CET] <Daemon404> of course it is
[13:25:54 CET] <Daemon404> it's like policing a high school
[13:25:58 CET] <nevcairiel> that guy should be thrown out of the project for such BS
[13:26:20 CET] <nevcairiel> breaking git master and objecting to fixing it until his pet peeve is fixed?
[13:26:21 CET] <nevcairiel> seriously?
[13:27:16 CET] <Daemon404> [21:53] <@Daemon404> you must be new to debianland
[13:28:39 CET] <JEEB> lol
[13:34:39 CET] <nevcairiel> also, everyone feel free to call him out on his BS on the ML, otherwise he'll come back with arguments like how noone objects
[13:34:58 CET] <wm4> and now for something completely different
[13:35:05 CET] <wm4> can we even have vaapi in libavutil?
[13:35:09 CET] <wm4> or will we regret this later
[13:35:14 CET] <nevcairiel> probably regret
[13:35:21 CET] <nevcairiel> why cant avfilter devepn on avcodec anyway
[13:35:25 CET] <nevcairiel> it does for some other filters already
[13:36:03 CET] <Daemon404> nevcairiel, i just dont have the energy to argue with people on the ML today
[13:36:22 CET] <Daemon404> especially the sort who have boundless energy to defend their positiosn to the death
[13:37:30 CET] <wm4> Daemon404: maybe time to use the power of voting?
[13:37:40 CET] <nevcairiel> so we have a fix in a month?
[13:37:50 CET] <wm4> lol
[13:40:47 CET] <jkqxz> The only reason that vaapi code is against avutil was because of the dependency.  Other than the hardware context setup, I don't really think it should be a public API at all.
[13:42:07 CET] <atomnuker> so why are the videolan guys so persistent about hwaccel + frame threading? don't they know it breaks stuff
[13:42:23 CET] <wm4> atomnuker: courmisch is, AFAIK
[13:42:47 CET] <nevcairiel> he is just insistent that he knows his solution cant possibly be faulty
[13:42:48 CET] <wm4> and whether it breaks stuff or not seems to be a complex question
[13:42:50 CET] <nevcairiel> thats just how he is
[13:43:31 CET] <Daemon404> reply sent
[13:44:30 CET] <Daemon404> atomnuker, it works for them because they have extensive locking, apparently?
[13:44:34 CET] <Daemon404> i dont know enough to take either side
[13:44:47 CET] <nevcairiel> for their d3d11 hwaccels its even worse
[13:44:59 CET] <nevcairiel> they added a mutex into the avcodec code for this locking purposes
[13:45:00 CET] <Daemon404> but i think it's BS for andreas to demand a revert here instead of pursing both projects
[13:45:48 CET] <wm4> maybe arguing with us is easier
[13:45:59 CET] <wm4> path of least resistance
[13:46:36 CET] <Daemon404> i said as much
[13:46:37 CET] <durandal_1707> just revert it, if he revert that fork of
[13:46:46 CET] <Daemon404> revert wars get people nowhere
[13:47:15 CET] <Daemon404> might be eaisest to round everybody involved up with a shotgun for cleansing^Wdiscussions
[13:47:53 CET] <durandal_1707> michaelni: why are you giving commit rights to random people
[13:48:30 CET] Action: Daemon404 already regrets involvement today, should have played games and hada pint instead
[13:48:36 CET] <mateo`> if master is broken and a fix is not likely to be expected soon enough, just revert until a proper patch is sent (that's my opinion).
[13:48:47 CET] <Daemon404> thats everyone's opinion (except his)
[13:49:08 CET] <mateo`> and that's not some kind of war, just a generic rule that should apply to everyone
[13:49:26 CET] <nevcairiel> his opinion is to leverage it to get his other controversial topics done
[13:49:37 CET] <nevcairiel> which is just childish BS and doesnt belong into our project
[13:49:56 CET] <nevcairiel> if they work like that in debian, fine, but if this becomes standard here I rather move on
[13:50:34 CET] <Daemon404> actually...
[13:50:41 CET] Action: Daemon404 lunch pint &
[13:50:44 CET] <durandal_1707> well if michaelni disappears who to contact for commit rights policy?
[13:51:12 CET] <nevcairiel> some others have root access, i forget
[13:51:32 CET] <durandal_1707> Compn?
[13:51:49 CET] <durandal_1707> j-b?
[13:52:17 CET] <wm4> durandal_1707: andreas is not just random, it's reasonable to have given him commit access at this point IMO
[13:52:35 CET] <wm4> but with behavior like this, we should think about removing it again
[13:52:36 CET] <nevcairiel> its also reasonable to expect him to behave mature
[13:53:16 CET] <durandal_1707> no, rule should be write at least one decoder from scratch
[13:53:32 CET] <Daemon404> wm4, vlc, in the past, have locked all parties invokved out of direct pushes for some amount of time
[13:53:33 CET] <nevcairiel> can I invent my own format first?
[13:53:48 CET] <nevcairiel> and then write a decoder for it?
[13:54:00 CET] <Daemon404> nevcairiel, you forgot to 'standardize' it at SMPTE
[13:54:04 CET] <JEEB> lol
[13:54:06 CET] <nevcairiel> thats a given
[13:54:18 CET] <j-b> durandal_1707: we have commit rights control.
[13:54:20 CET] <durandal_1707> if anime people use it
[13:54:35 CET] <j-b> durandal_1707: but we're moving to code.videolan.org (aka gitlab) to make all those issues easier to deal with.
[13:55:19 CET] <durandal_1707> gitlab? So serious?
[13:55:28 CET] <j-b> durandal_1707: yes. Why?
[13:56:57 CET] <durandal_1707> its company
[13:57:59 CET] <j-b> durandal_1707: it's open source. fully.
[13:58:09 CET] <wm4> (unlike github)
[13:58:22 CET] <Daemon404> i dont think you would want to see github's source code
[13:58:43 CET] <JEEB> it's unicorn blargs
[13:59:59 CET] <j-b> Daemon404: I would, tbh.
[14:00:07 CET] <j-b> btw, hi from London :)
[14:00:16 CET] <Daemon404> oh hi
[14:00:29 CET] <Daemon404> some meeting?
[14:00:49 CET] <j-b> some transits :)
[14:00:55 CET] <Daemon404> ah right
[14:00:58 CET] <j-b> leaving again for the land of freedom
[14:01:03 CET] <Daemon404> i saw this on social media this morning
[14:01:09 CET] <Daemon404> headed to land of weed
[14:01:58 CET] <Daemon404> as for github: their codebase is supposedly terrifying and unchangeable, baed on my feature requests with tehe github enterprise team (and testimaony from githubbers)
[14:33:38 CET] <cone-336> ffmpeg 03Paul B Mahol 07master:547d41207804: avfilter: update some comments
[14:41:21 CET] <cone-336> ffmpeg 03Clément BSsch 07master:17d41220d81d: lavfi/pthread: fix perameters/parameters typo
[14:47:16 CET] <Compn> durandal_1707 : i dont have git admin rights. that falls to the git admins. 
[14:47:58 CET] <Compn> which i dont know exactly who is git admin, but i think  vlc git admins are the same
[14:51:07 CET] <durandal_1707> michaelni: do you know anything on how avoid oom scenario with fps filter and vfr content?
[14:56:16 CET] <BtbN> wm4, isn't that cache the whole idea of that copy function? It's supposed to fit into the CPU cache, which makes the entire copy process faster.
[14:56:42 CET] <BtbN> I'll try to turn it into yasm, and do some benchmarks
[14:57:12 CET] <wm4> BtbN: nevcairiel did experiments on it and found the cache isn't needed, or something
[14:58:04 CET] <nevcairiel> the whole point of the copy function is using the special copy instruction
[15:00:44 CET] <BtbN> That function also looks like it expects the source and destination to be 64 bit aligned
[15:00:56 CET] <BtbN> 64 byte
[15:10:35 CET] <nevcairiel> its designed for gpu copying, where this is usually a given
[15:18:08 CET] <ubitux> wm4: so a readorder that keeps incrementing even after flushing is really what you need?
[15:18:33 CET] <ubitux> that is same event at the same time could show up later with a different readorder
[15:19:06 CET] <ubitux> (which is also the case with a reset to zero now that i think about it)
[15:19:17 CET] <wm4> ubitux: yeah, basically I want to disable ReadOrder's functionality (I'm preventing duplicates manually by checking the packet's pos field)
[15:19:30 CET] <ubitux> alright, i'll adjust the patchset to allow this then
[15:19:33 CET] <ubitux> anything else?
[15:19:46 CET] <wm4> I don't think so
[15:19:50 CET] <ubitux> ok, thx
[15:20:34 CET] <durandal_170> does anybody know when filter's filter_frame will be called
[15:21:34 CET] <durandal_170> when another filter calls request_frame?
[15:31:44 CET] <durandal_170> looks like nobody knows, so I will do the work
[15:36:49 CET] <Daemon404> durandal_170, you probably know lavfi better than almost everyone
[15:43:52 CET] <durandal_170> looks like presence of another audio stream triggers filter_frame
[15:44:26 CET] <durandal_170> video alone works great
[16:30:46 CET] <cone-336> ffmpeg 03Timothy Gu 07master:af54a36fc42d: avdevice: Mark decklink_common.h as unconditional SKIPHEADER
[16:30:47 CET] <cone-336> ffmpeg 03Timothy Gu 07master:bd4d19208123: common.mak: Use CCFLAGS for assembly generation as well
[16:33:22 CET] <cone-336> ffmpeg 03Timothy Gu 07master:61fb70c3866b: decklink: Header cleanup
[16:47:49 CET] <kierank> going to push this libquvi thing soon
[16:47:56 CET] <nevcairiel> noone complained?
[16:49:39 CET] <kierank> nope
[16:49:45 CET] <RiCON> everyone's using ytdl
[16:51:50 CET] <Daemon404> ^
[16:52:21 CET] <nevcairiel> usually there is at least one crazy person that complains about removals
[16:53:13 CET] <cone-336> ffmpeg 03Michael Niedermayer 07master:3130556c0eb0: avformat: Document urls a bit
[16:53:14 CET] <cone-336> ffmpeg 03Michael Niedermayer 07master:a7305c780b54: Print the whitelists if entities are not found on them
[17:02:38 CET] <kierank> hmm why can't I push
[17:02:51 CET] <kierank> I always forget which url I am meant to use for pushing
[17:03:02 CET] <nevcairiel> the ssh url
[17:09:16 CET] <cone-336> ffmpeg 03Kieran Kunhya 07master:2d40a09b6e73: avformat: Remove support for libquvi
[17:10:47 CET] <kierank> ok what other crap needs to go?
[17:11:59 CET] <kierank> atomnuker: can I get rid of libvo-aacenc
[17:20:12 CET] <wm4> redundant prores encoders maybe?
[17:20:18 CET] <atomnuker> kierank: not sure, I've checked out its popularity in debian and arch
[17:20:19 CET] <atomnuker> https://qa.debian.org/popcon.php?package=vo-aacenc
[17:20:20 CET] <wm4> also, old vdpau hwaccel
[17:20:36 CET] <durandal_1707> Carl will complain, so just send mail for voting 
[17:20:37 CET] <wm4> atomnuker: isn't it just installed as part of the ffmpeg build
[17:20:46 CET] <philipl> wm4: did I not push that change?
[17:20:53 CET] <kierank> atomnuker: I mean is our encoder better and a superset of libvo-aacenc now?
[17:20:58 CET] <atomnuker> wm4: no, debian's ffmpeg isn't compiled with neither fdk_aac or libvo-aac
[17:21:05 CET] <wm4> philipl: when?
[17:21:11 CET] <atomnuker> kierank: yes, it is
[17:21:25 CET] <kierank> then there is no reason for libvo-aacenc to exist
[17:21:34 CET] <wm4> kierank: +1
[17:21:36 CET] <atomnuker> yeah, for ffmpeg there is none
[17:21:46 CET] <philipl> wm4: clearly not
[17:21:52 CET] <atomnuker> but still kinda curious what pulls libvo-aacenc in debian
[17:22:00 CET] <JEEB> kitchen sink
[17:22:02 CET] <wm4> philipl: I mean, my ffmpeg checkout is a week old already
[17:22:05 CET] <kierank> wm4: anything non-contentious?
[17:22:10 CET] <atomnuker> kierank: anyway, +1 for removing libvo-aacenc
[17:22:17 CET] <philipl> wm4: no I didn't. I did it for mplayer :-P
[17:22:30 CET] <wm4> philipl: so mplayer can't use the old hwaccel anymore?
[17:22:36 CET] <philipl> wm4: right.
[17:22:39 CET] <wm4> lol.
[17:22:42 CET] <JEEB> at this point as far as I can see vo-aacenc has no place in FFmpeg
[17:22:53 CET] <wm4> so there's literally no reason to keep the old vdpau hwaccel
[17:23:02 CET] <philipl> wm4: carl admitted to me that I'd removed his biggest argument in favour of keeping it
[17:23:33 CET] <JEEB> it was useful for a very brief moment of time when faac "became" nonfree and fdk-aac still wasn't there. although it still wasn't much better than lavc's own encoder
[17:23:41 CET] <JEEB> + it only supported stereo
[17:27:24 CET] <RiCON> also, aacplus
[17:27:42 CET] <RiCON> any reason to use it instead of fdk?
[17:33:48 CET] <kierank> wm4: ok, what else need scrapping?
[17:34:46 CET] <wm4> I don't keep a list... asf comes to mind, but that one is very controversial
[17:35:13 CET] <wm4> do we really need libschroedinger support?
[17:36:06 CET] <kierank> libxavs is crap
[17:37:32 CET] <durandal_1707> yes, remove
[17:38:36 CET] <kierank> hmm why did the ffmpeg github not update
[17:39:16 CET] <kierank> libnut...
[17:42:30 CET] <wm4> is libopenjpeg still controversial?
[17:42:35 CET] <kierank> if I need to decode alpha channel, how do I make sure it looks ok?
[17:43:02 CET] <atomnuker> kierank: we still have 2 prores decoders and 2 prores encoders (didn't we have 3 encoders?)
[17:43:21 CET] <kierank> lol yeah
[17:43:42 CET] <wm4> hm, crystalhd support
[17:43:58 CET] <wm4> didn't someone here implement that originally, maybe BtbN?
[17:44:07 CET] <BtbN> hm?
[17:44:12 CET] <wm4> atomnuker:  DEVIL. prores               Apple ProRes (iCodec Pro) (decoders: prores prores_lgpl ) (encoders: prores prores_aw prores_ks )
[17:44:30 CET] <wm4> BtbN: crystalhd
[17:44:35 CET] <BtbN> Never heard of that
[17:44:50 CET] <wm4> oh right, it was philipl 
[17:44:52 CET] <durandal_1707>  Just remove
[17:44:52 CET] <wm4> sorry
[17:45:41 CET] <wm4> libgsm?
[17:46:17 CET] <cone-336> ffmpeg 03Ronald S. Bultje 07master:9cf81e573c70: lavfi: recognize GBR9-14P as RGB in ff_fill_rgba_map().
[17:52:14 CET] <atomnuker> wm4: the prores_aw and prores encoders both use the same file with the same init/encode_frame/close functions
[17:52:50 CET] <wm4> atomnuker: oh
[17:53:07 CET] <cone-336> ffmpeg 03Paul B Mahol 07master:3b9f41a9c681: avfilter/vf_zoompan: rewrite so it doesn't cache all output frames
[17:53:37 CET] <atomnuker> wm4: can't find anything that would change the output, so I think it's just a duplicated (for compatibility?) entry
[18:08:17 CET] <durandal_1707> encoders have different features
[18:08:57 CET] <durandal_1707> decoders should do same, thus one should be removed
[18:11:06 CET] <durandal_1707> libgsm decoders should probably be removed
[18:11:49 CET] <nevcairiel> its funny how the one prores decoder is called prores_lgpl, but the other one is also lgpl
[18:11:50 CET] <nevcairiel> i r confused
[18:18:04 CET] <BBB> the origin is different
[18:18:12 CET] <BBB> the lgpl one was always lgpl, the other one was originally gpl
[18:19:14 CET] <BBB> it was written by bcoudurier together with maxim, the lgpl one was written by maxim himself alone
[18:19:19 CET] <BBB> or something like that
[18:19:54 CET] <BBB> then something something and before you know it you have two decoders, of which one is gpl so youtube cant steal it
[18:19:59 CET] <nevcairiel> someone should figure out which is better and just drop the other
[18:20:04 CET] <BBB> and then the lgpl one gets optimized so its better
[18:20:13 CET] <BBB> and then he relicenses so people dont kick his decoder out
[18:20:21 CET] <BBB> again something something
[18:20:48 CET] <nevcairiel> currently the default seems to be the one not called lgpl
[18:20:54 CET] <nevcairiel> so just drop the other one
[18:21:01 CET] <BBB> I believe I wrote simd for the maxim (lgpl) one
[18:21:10 CET] <BBB> first make sure its not slower
[18:23:54 CET] <BtbN> nevcairiel, do you happen to still have that non-buffer copy function somewhere? It might be nice to have it in avutil, since that vaapi stuff that's about to land could make good use of it.
[18:24:48 CET] <nevcairiel> BtbN: the existing vdpau and dxva2 stuff could also use it, but we consider those things more of developer tools than user features =p
[18:25:25 CET] <BtbN> There's no harm in making it public api though, who knows who finds it usefull
[18:25:26 CET] <wm4> well there are people who are interested in full hw transcoding pipelines, like rcombs 
[18:25:37 CET] Action: Daemon404 is still not exactly sold on 650+ lines of vaapicrap in avutil
[18:26:01 CET] <wm4> so why can't we have a libavvaapiutil
[18:28:32 CET] <nevcairiel> i only have it in intrinsics, so someone would have to properly yasm it, but the basics are pretty simple: read 64-byte (ie. one cache line) using 4x movntdqa, write them out using 4x movntdq (no a), the 4x unroll is important due to the way movntdqa's internal cache works
[18:29:03 CET] <nevcairiel> (note: sse4)
[18:30:46 CET] <nevcairiel> either enforce a 64-byte stride on the buffers in the documentation, or add trailing code to copy more fine-grained remainders
[18:31:02 CET] <jamrial> saste started a patch for this some time ago
[18:31:09 CET] <jamrial> but the problem was in the glue
[18:31:09 CET] <nevcairiel> his approach was way too generic
[18:31:18 CET] <nevcairiel> dealing with unaligned memory and whatnot
[18:31:26 CET] <nevcairiel> just make it a strict definition of what it expects as input
[18:31:39 CET] <jkqxz> The vaapi filter thing isn't exactly vital.  It helps improve performance when you're using it with ffmpeg, but everything it does can be done in software instead there.  Other things using libav* would hopefully know what they're doing enough that they could implement whatever fragments of it they needed themselves.  If dropped, the bits currently in libavutil could go in libavcodec instead.
[18:32:01 CET] <nevcairiel> I still think that avfilter filter should just depend on avcodec
[18:32:04 CET] <nevcairiel> other filters do
[18:32:06 CET] <nevcairiel> so why not this one
[18:32:27 CET] <jkqxz> That's allowed?
[18:32:34 CET] <BtbN> i wonder how to do it the other way around, there seems to be no store-equivalent for movntdqa
[18:32:36 CET] <nevcairiel> optionally, yes
[18:32:50 CET] <wm4> jkqxz: essentially anything is allowed as long as there are no cycles
[18:32:57 CET] <nevcairiel> BtbN: dont think there is a upload instruction, just use normal moves
[18:33:13 CET] <BtbN> so basicaly, a normal memcpy would be fine for that direction?
[18:33:27 CET] <nevcairiel> if said memcpy is simd'ed
[18:33:32 CET] <nevcairiel> which any sane OS probably should do
[18:33:50 CET] <jkqxz> Normal memcpy() is indeed pretty much fine for the other direction, in the vaapi case.
[18:34:50 CET] <jkqxz> (To the Intel weird memory.  There might be other sorts of weird memory which want a different approach.)
[18:35:34 CET] <nevcairiel> in any case, yes avfilter can depend on avcodec, many filters already do, see configure 6070-6096
[18:35:46 CET] <nevcairiel> i would probably feel a bit better to have vaapi code in avcodec
[18:38:03 CET] <jkqxz> Likewise.  I will make that change.
[18:40:04 CET] <wm4> anyway this is pretty orthogonal to which API should be public and which not
[18:43:16 CET] <jkqxz> I was wanting the hardware context stuff (+ locking) to be public, and everything else not, at least initially.  The other parts are mainly avoiding internal duplication - they could be convenient to offer to users, but are not in any way vital to operation.
[18:44:23 CET] <wm4> yeah
[18:44:24 CET] <cone-336> ffmpeg 03Timothy Gu 07master:fe71fde24685: configure: Maintain alphabetical order of components
[18:45:30 CET] <cone-336> ffmpeg 03Timothy Gu 07master:794b015035a5: Changelog: Add entry on libquvi being removed
[18:45:30 CET] <jkqxz> But the cross-library dependency is getting in the way of that.
[18:48:57 CET] <BtbN> I wonder if another shared library, which is entirely non-public, would make sense
[18:49:40 CET] <wm4> libavpriv
[18:50:03 CET] <jamrial> pls no
[18:50:16 CET] Action: Daemon404 weeps
[18:51:11 CET] <Timothy_Gu> RiCON: patch to remove aacplus sent
[18:52:06 CET] <Timothy_Gu> also is there any reason to use FAAC nowadays?
[18:52:18 CET] <jamrial> or vo-aac
[18:52:31 CET] <jamrial> every guide i found says it sucks
[18:52:44 CET] <BtbN> With the current state of the native aac encoder, there isn't realy any reason to use anything else
[18:53:02 CET] <nevcairiel> testing purposes
[18:53:12 CET] <Timothy_Gu> kierank: I'm running a cron job that updates the GitHub mirror every hour
[18:53:35 CET] <jamrial> fdk should be enough for both external decoder and encoder
[18:53:56 CET] <Daemon404> yes id rather keep both
[18:54:07 CET] <Daemon404> fyi we use fdk for weird aac streams the internal decoder cant handle
[18:54:19 CET] <Daemon404> (both = fdk enc/dec)
[18:54:35 CET] <Timothy_Gu> let's remove faac after aacplus then :)
[18:54:48 CET] <nevcairiel> which would that be Daemon404
[18:54:55 CET] <Daemon404> i need to double check
[18:55:04 CET] <jamrial> the only thing i couldn't play with ffaac was some latm in ts stream, which fdk handled right
[19:02:50 CET] <kierank> Timothy_Gu: ah right thought it was automatic
[19:03:12 CET] <kierank> Oooh can we get rid of faac too?
[19:03:22 CET] <wm4> it's strange how github has no way to auto-update forks
[19:03:26 CET] <wm4> so most forks are outdated
[19:03:36 CET] <nevcairiel> yeah i've always wondered that
[19:03:40 CET] <wm4> hundreds and thousands of outdated forks
[19:05:17 CET] <Timothy_Gu> wm4: https://github.com/FFmpeg/FFmpeg/pull/115
[19:05:58 CET] <Daemon404> lol
[19:07:27 CET] <wm4> lol
[19:27:01 CET] <kierank> any less ugly way to do
[19:27:03 CET] <kierank>             output[(2*i+0)*out_stride] = clip ? av_clip_uintp2(output[(2*i+0)*out_stride], clip) : output[(2*i+0)*out_stride];
[19:27:34 CET] <kierank> ?
[19:27:55 CET] <kierank> I don't want to macro this
[19:28:11 CET] <BtbN> Just a normal if, that does nothing if !clip?
[19:28:42 CET] <kierank> oh yeah lo
[19:28:43 CET] <kierank> l
[19:52:23 CET] <wm4> michaelni: somehow your recent hls changes must have broken hls playback in mpv (while it works in ffplay)
[19:52:44 CET] <wm4> do I need to do something special?
[19:53:56 CET] <wm4> oh, it's probably because I don't give libavformat the filename/URL
[19:54:06 CET] <wm4> because libavformat tends to do stupid stuff when I do that
[19:55:07 CET] <wm4> michaelni: so does this count as regression Y/N
[19:56:55 CET] <nevcairiel> didnt it say that without any filename it would still accept it
[20:00:02 CET] <wm4> ah if I pass NULL instead of "" as filename it works, lol
[20:00:42 CET] <wm4> but I once changed it from NULL to "" to fix a crash
[20:00:58 CET] <wm4> in rtp_probe within libavformat, apparently
[20:01:47 CET] <wm4> indeed, it still accesses the filename unconditionally, and will crash if it's NULL
[20:01:52 CET] <wm4> bipolar libavformat
[20:04:17 CET] <wm4> I don't really think that this new HLS check increases security anyway...
[20:09:09 CET] <michaelni> i can revert the filename extension check if people feel its not usefull? otherwise ill fix the "" case
[20:10:03 CET] <wm4> well, I'm not sure what other API users who expect HLS to work use
[20:10:33 CET] <wm4> what exactly does the extension check prevent?
[20:10:44 CET] <nevcairiel> i just pass the filename,  since i let avformat open the file directly
[20:10:51 CET] <nevcairiel> do you pass the m3u8 using custom io?
[20:10:57 CET] <wm4> yes
[20:13:42 CET] <durandal_170> Daemon404: Nicolas tells me libavfilter is not designed to return multiple frames from .filter_frame
[20:15:34 CET] <Daemon404> i did tell you it was a fundemental problem with lavfi
[20:15:38 CET] <Daemon404> (or so i was told)
[20:18:04 CET] <michaelni> wm4, the idea was to prevent users from getting the hls demuxer when clicking on files that look like other formats like mkv as hls does remote connections and stuff which is potentially unexpected
[20:19:12 CET] <michaelni> durandal_170, returning multiple frames from filter_frame should work but isnt optimal as the frames might pile up and overload available memory
[20:19:29 CET] <Daemon404> michaelni, that is the exact problem he was addressing
[20:19:54 CET] <durandal_170> michaelni, BBB: so what is buggy in flac encoder?
[20:20:06 CET] <BBB> I responded to your email
[20:20:10 CET] <BBB> read it
[20:20:20 CET] <michaelni> the solution for frame pileup should be to return each frame in response to request_frame
[20:20:38 CET] <durandal_170> I have, but dunno what to fix
[20:21:30 CET] <durandal_170> *flac
[20:21:50 CET] <BBB> make the return value of encode_frame (count_*) and count_header byte-aligned
[20:21:53 CET] <BBB> I bet you that will fix it
[20:22:05 CET] <BBB> otherwise, more generally, figure out which part of count_* and write_* differs in size
[20:22:14 CET] <BBB> I think its the byte-alignment missing in count
[20:22:18 CET] <BBB> but it may be something else
[20:22:24 CET] <BBB> goodluck, Im watching toy story with my kids
[20:31:07 CET] <cone-336> ffmpeg 03Paul B Mahol 07master:8a343443796a: avfilter/vf_zoompan: unbreak filtering with video input
[20:31:08 CET] <cone-336> ffmpeg 03Paul B Mahol 07master:f42eae96b22d: avfilter/vf_zoompan: fix pts handling
[20:41:57 CET] <BtbN> michaelni, so a potential filter that potentialy produces multiple output frames per input frame is a problem?
[20:43:08 CET] <nevcairiel> wonder how long I have to come up with cases where andreas patch doesnt work before we can revert it
[20:48:11 CET] <nevcairiel> BtbN: deint filters like yadif and w3fdif do that, so its probabvly a different thing they are talking about
[20:49:25 CET] <BtbN> I don't get why it's not reverted yet. What's there to argue about? Current master is broken, no fix available. The only benefit of it beeing broken is questionable bit-perfect out-of-tree builds, which won't hurt anyone of they get in a bit later.
[20:49:47 CET] <durandal_170> filter that return huge number of frames
[20:49:48 CET] <BtbN> If he finaly fixes it, there is no problem pushing it again, after propper review.
[20:50:57 CET] <Gramner> indeed, the proper way to handle accidental breakage like this with no simple/obvious fix should be to revert it and resubmit once you're confident that it's fixed
[20:51:57 CET] <michaelni> BtbN, IIUC/IIRC anderas patch also fixed out of tree builds with gdb (that is it didnt find the source files) that is if i dont misremember
[20:54:57 CET] <nevcairiel> i never heard of such a problem before, so either noone does out of tree builds, or its something how debian builds their things
[20:58:34 CET] <nevcairiel> in any case, please express the opinion that we should just revert and try again without a broken live tree on the ML, if I do that again it won't do any good anyway
[21:13:09 CET] <BBB> what is currently still broken?
[21:13:21 CET] <nevcairiel> now andreas answer is to simply not allow this use-case
[21:13:29 CET] <nevcairiel> i'm done arguing with such arguments
[21:20:33 CET] <iive> what is out of tree builds? ones where the .o .a .so files are created in other directory than the source?
[21:21:52 CET] <nevcairiel> Yes
[21:30:22 CET] <Daemon404> i think thats about 6 people who said revert now
[21:30:28 CET] <Daemon404> this is somewhat ridiculous.
[21:32:13 CET] <atomnuker> durandal_170: in the latest patch you sent, that *2 is to account for the custom sample rate at the end of the frame header, right?
[21:32:37 CET] <atomnuker> but the spec says that can be either 8 or 16 bits, so shouldn't that be conditional
[21:32:47 CET] <durandal_170> yes, it takes 16 bits
[21:33:13 CET] <durandal_170> the other is 0
[21:34:12 CET] <atomnuker> ah, yeah, I see
[21:43:21 CET] <cone-336> ffmpeg 03Timothy Gu 07master:ce36cb08ed46: Revert "decklink: Header cleanup"
[21:56:12 CET] <cone-336> ffmpeg 03Paul B Mahol 07master:3e7d6849120d: avcodec/flacenc: fix calculation of bits required in case of custom sample rate
[22:00:43 CET] <atomnuker> I remember asking how good our FLAC encoder is compared to libflac
[22:01:05 CET] <nevcairiel> Didn't you also say that it's better
[22:01:19 CET] <atomnuker> yes, just did comparisons, at the highest compression level we beat it by 20 bytes (for a 35 megabyte file)
[22:01:37 CET] <atomnuker> but we take 12 seconds on my machine and libflac takes 3.89 seconds :/
[22:01:49 CET] <nevcairiel> Heh
[22:02:04 CET] <jamrial> worth 20 bytes!
[22:02:26 CET] <nevcairiel> Libflac got a bunch of simd over recent versiona
[22:02:30 CET] <nevcairiel> versions
[22:02:34 CET] <atomnuker> you can also enable multi_dim_quant which apparently does something crazy and should compress it with alien technology
[22:02:43 CET] <nevcairiel> Hehe
[22:02:59 CET] <atomnuker> but that would literaly take longer than a day to compress the same file
[22:06:14 CET] <nevcairiel> Really this slow?
[22:07:01 CET] <Daemon404> i was never able to make flac beat wavpack in compression, even with its (no joke) --super-secret-totally-impractical-compression-level
[22:07:34 CET] <atomnuker> you and your wavpack
[22:07:57 CET] <jamrial> i think the best compression i've seen was monkey's audio
[22:08:04 CET] <jamrial> but it was also pretty slow
[22:08:08 CET] <Daemon404> lossless audio is a crapshoot
[22:08:28 CET] <atomnuker> wavpack would be better and more accepted if it didn't have the semi-lossless mode IMO
[22:08:45 CET] <jamrial> our flac decoder is mighty fast compared to every other lossless decoder we have
[22:08:46 CET] <Daemon404> i agree it should have been removed / not existed
[22:08:56 CET] <Daemon404> jamrial, it has to be
[22:08:59 CET] <Daemon404> the flac format is terrible
[22:09:00 CET] Action: Daemon404 runs
[22:09:36 CET] <Daemon404> although thats parsing, i suppos.e
[22:11:27 CET] <atomnuker> as in, ogg-in-flac or just plain flac?
[22:11:36 CET] <atomnuker> *flac-in-ogg
[22:12:48 CET] <Daemon404> i can only speak for plain flac, but i think flac in ogg also needs some nutty parsing
[22:17:31 CET] <durandal_170> Libflac uses mt for encoding?
[22:19:41 CET] <atomnuker> maybe in the future if I'm bored I'd write a modern lossless audio format, with vector quantization, entropy encoding, something obscure and alien to encode the quantization errors and whatever else impractical-for-embedded-systems technology I could think of
[22:20:21 CET] <atomnuker> an FFA1 to FFV1
[22:20:57 CET] <durandal_170> Thats sonic
[22:21:11 CET] <atomnuker> that S stands for Simple
[22:21:29 CET] <nevcairiel> Potential gains would seem to be small in the grand scheme of things, wouldn't they. Over existing codecs anyway
[22:21:38 CET] <atomnuker> and that I stands for 'I make bigger files than the input'
[22:22:06 CET] <durandal_170> why is sonic encoder still in codebase?
[22:22:13 CET] <atomnuker> nevcairiel: probably, but it'd be fun and you'd know that you're getting the best compression level there is
[22:22:58 CET] <durandal_170> somebody please send patch to remove Sonic
[22:23:09 CET] <nevcairiel> Andreas arguments are getting more flimsy by the minute
[22:23:25 CET] <atomnuker> durandal_170: what's wrong with sonic?
[22:25:18 CET] <durandal_170> crapware, abandonware, pissing code
[22:25:38 CET] <durandal_170> nobody touch it
[22:25:54 CET] <durandal_170> and its still useless
[22:26:35 CET] <durandal_170> does libav have native vorbis encoder?
[22:35:57 CET] <rcombs> I should resend my patches to use a system cert bundle by default
[22:36:06 CET] <rcombs> and verify TLS by default
[22:36:15 CET] <rcombs> now that OS X and Windows have native TLS code
[22:37:10 CET] <JEEB> nice
[22:37:43 CET] <nevcairiel> I would just turn it off again
[22:37:58 CET] <nevcairiel> There is no sufficient feedback mechanism for API users
[22:38:09 CET] <nevcairiel> Log messages are not useful
[22:38:19 CET] <JEEB> right
[22:39:53 CET] <durandal_170> michaelni: sonicls is not bitexact
[22:44:13 CET] <durandal_170> probably because of last small frame
[22:44:34 CET] <durandal_170> size not stored anywhere
[22:49:31 CET] <durandal_170> buy what margin is libflac encoder faster then our?
[22:49:40 CET] <durandal_170> *by
[22:51:06 CET] <atomnuker> durandal_170: 3.34 times faster
[22:52:09 CET] <atomnuker> but they are nearly identical when I reduce the compression level by 2
[22:52:48 CET] <atomnuker> probably something to do with the amount of LPC passes it does
[22:53:02 CET] <durandal_170> well, for fast mode out doesn't have mt
[22:53:43 CET] <durandal_170> decoder does use multiple threads
[23:08:37 CET] <Timothy_Gu> RiCON: you here?
[23:10:04 CET] <RiCON> Timothy_Gu: yes
[23:59:09 CET] <Timothy_Gu> ubitux: seems like eglibc doesn't have pthread_setname_np either
[23:59:30 CET] <nevcairiel> sounds like a configure check will be needed
[23:59:45 CET] <Timothy_Gu> should we revert this commit :p
[00:00:00 CET] --- Mon Jan 25 2016