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

[burek]

[09:32:00 CEST] <cone-772> ffmpeg 03Marton Balint 07master:a5c17cf43e42: avformat/mxfdec: drop invalid index table segments when sorting them
[12:35:12 CEST] <durandal_1707> JEEB: found anything?
[12:39:27 CEST] <durandal_1707> just any other 'f' variant that's not black at start would be good
[12:40:31 CEST] <JEEB> I started falling asleep at the end
[12:40:57 CEST] <durandal_1707> lol
[12:49:52 CEST] <JEEB> so I decided to not fall asleep in my chair
[12:50:04 CEST] <JEEB> so I just gave up and hit the bed some time past midnight
[17:02:28 CEST] <BBB> what does a deep learning filter from rgb8 to rgb10 actually do?
[17:03:08 CEST] <nevcairiel> any algorithm that needs to invent new data can be trained to do it better
[17:03:11 CEST] <nevcairiel> if its useful...
[17:04:13 CEST] <BBB> can it?
[17:04:15 CEST] <nevcairiel> adding bits properly can help to retain or even refine gradients and things like that, so there is a difference between doing it badly or properly
[17:05:05 CEST] <BBB> fair enough lets see what it ends up with
[17:07:47 CEST] <nevcairiel> apparently its also supposed to do HDR, not just increasing bitdepth
[17:41:08 CEST] <BBB> so, call me stupid and stuff
[17:41:22 CEST] <BBB> but HDR is just different matrix coefficients, whitepoints etc.
[17:41:32 CEST] <BBB> we already have filters that do the correc ttheoretical conversion between them
[17:41:36 CEST] <BBB> not to mention zscale doing that too
[17:41:47 CEST] <BBB> I know machine learnign is all the buzz, but sometimes theory does it just fine, no?
[17:42:50 CEST] <jamrial> i thought the new hot thing was blockchain
[17:49:41 CEST] <BradleyS> nope, still bacon
[17:51:33 CEST] <BBB> isnt livepeer a youtube-blockchain thingy?
[17:58:42 CEST] <atomnuker> I agree, I'd rather take a mathematically sound approach than a neural network that's been trained in some unknown way
[17:59:06 CEST] <atomnuker> it could screw up, but the former approach wouldn't
[17:59:24 CEST] <atomnuker> could we stop adding more neural networks plz?
[17:59:53 CEST] <atomnuker> it makes sense for stuff like noise removal but this is just wankery no one will use
[18:03:26 CEST] <j-b> (and unfree)
[18:03:46 CEST] <nevcairiel> i dont think there is a pure mathematical approach to HDRify an image
[18:04:03 CEST] <nevcairiel> because you are trying to invent contrast that wasnt there before
[18:04:20 CEST] <nevcairiel> so we're again inventing data, and that process can be trained
[18:05:08 CEST] <atomnuker> there isn't, but there's a reasonable approach that yields more or less accurate representation as if shown on non-hdr output
[18:05:41 CEST] <atomnuker> I don't see training helping here other than for hollywood style white clipping on highlights
[18:05:46 CEST] <nevcairiel> whats the point of converting the image in such a way that it keeps looking like SDR? Might as well output it in SDR
[18:05:54 CEST] <nevcairiel> presumably you want it to look like HDR afterwards =p
[18:06:02 CEST] <atomnuker> you'd like it shown on an hdr output
[18:06:12 CEST] <nevcairiel> thats your assumption
[18:06:20 CEST] <nevcairiel> but maybe they also want it to be actual HDR
[18:06:28 CEST] <nevcairiel> some TVs have such features
[18:06:33 CEST] <nevcairiel> they are a bit hit and miss
[18:06:34 CEST] <nevcairiel> but hey
[18:06:35 CEST] <atomnuker> it will be hdr if it has to be shown on an hdr monitor
[18:06:51 CEST] <atomnuker> it would have to be otherwise reproduction would be messed up
[18:07:15 CEST] <nevcairiel> there is a difference between "being SDR in a HDR envelope" and actually "being HDR"
[18:07:33 CEST] <BBB> I look forward to the HDRificiation artifact gallery that will doubtlessly result from this
[18:08:20 CEST] <atomnuker> if you want to have HDR-like clipping results other filters exist to get you that
[18:08:59 CEST] <atomnuker> an sdr->hdr filter should try to get the most accurate and closest to the original rep in the target colorspace
[18:09:13 CEST] <nevcairiel> thats, like, your opinion
[18:09:18 CEST] <atomnuker> no, it isn't
[18:09:35 CEST] <nevcairiel> thats not a HDR filter, thats a conversion to PQ
[18:09:45 CEST] <nevcairiel> the result doesnt have any resemblence of higher dynamic range
[18:09:52 CEST] <durandal_1707> ban neural networks now!
[18:09:59 CEST] <atomnuker> and there's nothing wrong it that
[18:10:09 CEST] <nevcairiel> except that may not be what someone wants?
[18:10:11 CEST] <atomnuker> there is higher dynamic range compared to the original
[18:10:16 CEST] <atomnuker> they can tune it!
[18:10:20 CEST] <nevcairiel> just because you dont want that doesn't mean its not something people like
[18:10:23 CEST] <atomnuker> filters exist to do that
[18:10:46 CEST] <atomnuker> I've been telling you, a neural network filter isn't the correct place to do this
[18:11:16 CEST] <nevcairiel> You've been ranting about how bad that e ntire process is, not telling anything
[18:13:00 CEST] <atomnuker> I have been arguing about whether a more correct approach would be as I've been saying rather than an absolutely unmaintainable neural network filter
[18:24:27 CEST] <BBB> nevcairiel: j-b/atomnuker do have a point about the unmaintainability of the whole nn stack
[18:24:56 CEST] <BBB> if we dont know how they are generated and all the filter says is that it does some A to Z conversion that is hard to objectively check, then how do we know its not just a turdificator?
[18:25:08 CEST] <BBB> I could probably push a turd filter by calling it nice name and saying "nn"
[18:25:18 CEST] <BBB> nn = nice name or neural network
[18:25:26 CEST] <BBB> but that doesnt mean it *actually* does something
[18:25:35 CEST] <BBB> so how do we guarantee that code in ffmpeg does what the docs say it does?
[18:25:55 CEST] <BBB> most code can be objectively checked; I dont know how to check a nn set of coefficients beyond trusting the author
[18:26:14 CEST] <BBB> do we trust intel dudes? googlers? russians? no-name contributors?
[18:26:18 CEST] <BBB> anonymous contributions?
[18:26:21 CEST] <j-b> For the same reason you provide your PSD/XCF/AI files for your png images, because they are the source; you need to provide the source that got you those numbers.
[18:26:35 CEST] <nevcairiel> its empirically obtained data, such data can by its pure nature not be objectively checked
[18:26:53 CEST] <BBB> so on what basis do we accept the patch?
[18:26:59 CEST] <j-b> In the case of NN, you need to document in a executable way, a way to created those data
[18:27:10 CEST] <BBB> if I commit a vp9 decoder whihc converts vp9 bitstreams to nothing, it wouldnt be accepted
[18:27:11 CEST] <j-b> In the case of NN, you need to document in a executable way, a way to recreate those data.
[18:27:25 CEST] <BBB> if I commit a NN filter which convers rgb8 to nothing, how do we know that this is nothing instead of rgb10?
[18:27:28 CEST] <BBB> I say its HDR
[18:27:30 CEST] <BBB> but is it?
[18:27:32 CEST] <BBB> how do we know?
[18:27:39 CEST] <j-b> Re-runing twice will give you different results, sure, but you have the source.
[18:27:39 CEST] <BBB> can we check that the filter does what it says it does?
[18:27:50 CEST] <j-b> Here, you need to trust the author that his set was good.
[18:27:53 CEST] <BBB> right
[18:27:58 CEST] <BBB> I dont want to just trust the author blindly
[18:28:00 CEST] <j-b> and you cannot check that he did select correctly.
[18:28:09 CEST] <j-b> and if the author dies, you cannot maintain the code.
[18:28:15 CEST] <BBB> and just because the dude has an intel email address means nothing
[18:28:23 CEST] <j-b> It might be cool, but this is not "Free Software'
[18:28:37 CEST] <BBB> it sounds cool, we dont know if it is cool
[18:28:41 CEST] <BBB> because we dont know
[18:28:42 CEST] <BBB> :-/
[18:28:48 CEST] <j-b> THis is exactly like that that Intel put some binary blobs for the VP8 decoding in the Linux open source driver
[18:29:10 CEST] <BBB> brb
[19:06:06 CEST] <atomnuker> BBB: if you disagree please put forward a reply in the email thread
[19:06:22 CEST] <atomnuker> but I'm starting to feel like starting a revert war
[19:06:44 CEST] <atomnuker> not being able to reproduce the weights is utterly unscientific and unacceptable
[19:07:48 CEST] <atomnuker> and I'm getting j-b's point that its a bunch of embedded binary junk in an open source project
[19:08:26 CEST] <atomnuker> (I wouldn't mind if he pitched in the ML thread too)
[19:16:29 CEST] <j-b> I already did, on the previous patch
[19:16:44 CEST] <j-b> and paul thought I was against his code (which I'm not, of course)
[19:16:53 CEST] <j-b> I just want more documentation of the process.
[19:17:07 CEST] <j-b> and I also don't want distribution to patch FFmpeg too much.
[19:19:22 CEST] <durandal_1707> JEEB: give moar KB2f, only stuff on internet is >= KB2g
[19:20:44 CEST] <atomnuker> yep, I agree, if there was a reproducable way to get and potentially improve the weights it would work, but they didn't provide such code in our tools dir or anywhere
[19:22:28 CEST] <durandal_1707> so I guess you are against sofalizer filter too? because you can not generate sofa files?
[19:24:16 CEST] <kepstin> I'm not even sure where you'd find training data for that anyways - maybe get the same movies in blu-ray and ultrahd blu-ray and try to get it to reproduce the results of the hdr conversion?
[19:25:42 CEST] <kepstin> i'd suspect that having it compare hdr video and a tone-mapped/downconverted version of the same video would give poor results, it might overfit to just being a reversal of the particular tone mapping method used.
[19:25:59 CEST] <JEEB> yea
[19:26:09 CEST] <JEEB> I don't see why > neural networks
[19:27:08 CEST] <durandal_1707> it's future, computers will think for us
[19:28:23 CEST] <kepstin> that said, ffmpeg *does* already have a neural net based filter, nnedi - but it requires an external blob of training data.
[19:28:59 CEST] <kepstin> I wonder if maybe it would just make sense to have a filter which is a fairly generic way to apply a neural net to the video, not specialized to a particular use.
[19:32:37 CEST] <BBB> that too
[19:32:49 CEST] <BBB> theres a maintenance argument to be made for that
[19:32:55 CEST] <BBB> if youhave 100 10-tap 2d filters
[19:33:00 CEST] <BBB> do we need simd for all of them?
[19:33:03 CEST] <BBB> or can that be shared?
[19:33:11 CEST] <BBB> (the answer should be obvious)
[19:36:45 CEST] <BBB> atomnuker: so & Ive burned myself on a few too many troll^threads in the past, so Im not quite ready to re-engage yet
[19:36:49 CEST] <atomnuker> durandal_1707: no, there's a standard way to generate sofa files
[19:36:58 CEST] <BBB> I think we need an enforceable CoC to get people to behave normally
[19:37:02 CEST] <atomnuker> and we also don't ship any sofa files ourselves
[19:37:04 CEST] <BBB> until then Ill mostly stay away from the ML
[19:37:17 CEST] <BBB> too much crap for my delicate sensitive taste
[19:37:41 CEST] <atomnuker> its not arguing, its posting an opinion
[19:37:46 CEST] <durandal_1707> crap on ml?
[19:37:48 CEST] <atomnuker> you can choose to defend it or not
[19:40:39 CEST] <BBB> if I dont defend it, Ill be called out for FUD that Im unwilling to even stand for
[19:40:43 CEST] <BBB> so itll be pointless
[19:40:49 CEST] <BBB> might just as well shout into space
[19:43:12 CEST] <atomnuker> nothing wrong with that
[19:43:45 CEST] <atomnuker> and no one will call you out for fud, you're just being irrational
[19:52:25 CEST] <BBB> sorry :(
[19:52:43 CEST] <BBB> I highly encourage you guys to all accept an enforceable CoC, I think it would make things a lot better
[19:53:01 CEST] <BBB> I know its unrelated to nn etc., but I do think itll be useful
[19:53:38 CEST] <jamrial> the issue is who/how to enforce it, as i said in a mail some weeks ago
[19:54:29 CEST] <jamrial> the voting committe is inneficient, and by now "outdated". as in, the list of members has names of people that are awol
[19:54:41 CEST] <gnafu> If someone wants to pay me a full-time salary, I'll gladly be a CoC enforcer ;-).
[19:55:13 CEST] <gnafu> Any companies looking to take me on for that?
[19:55:16 CEST] <jamrial> heh
[19:55:28 CEST] <gnafu> I love rules, and being a stickler.
[19:55:47 CEST] <gnafu> Especially if they need to be followed by someone else, and I can just observe and guide.
[19:56:23 CEST] <BBB> I understand the problem, and I think were just kicking the can down the lane in doing nothing
[19:56:25 CEST] <BBB> thats not acceptable
[19:56:42 CEST] <BBB> its like having a crasher in a decoder and not fixing it because we cant agree on how to fix it
[19:56:44 CEST] <BBB> thats not a fix
[19:56:52 CEST] <BBB> its just the same bug without anyone fixing it
[19:57:02 CEST] <BBB> its what the term bitrot comes from
[19:57:07 CEST] <BBB> our community suffers from bitrot
[19:57:14 CEST] <BBB> we need to work that out by shaking it up a little
[20:00:49 CEST] <atomnuker> its fine, you're just having misconceptions about it being broken
[20:01:05 CEST] <atomnuker> that's the main problem imo
[20:01:16 CEST] <BBB> ok
[20:01:22 CEST] <jamrial> i don't agree, atomnuker
[20:02:24 CEST] <jamrial> the project has some considerable issues in behavior and general policy
[20:03:47 CEST] <jamrial> what can/should go in should be able to be discussed without shit flinging
[20:04:01 CEST] <atomnuker> I do think people's misconceptions are the problem, some people were adamant that we never removed anything despite throwing out thousands of lines of code, they were adamant that decisions could never be made despite reaching a solution most people were happy with (the lavc postprocess, the new iterate api and the compile time lists)
[20:06:22 CEST] <atomnuker> the process is bumpy, sure, but it does yield results, if at the cost of having to fiercely defend opinions
[20:08:17 CEST] <BBB> you are allowed to call it bumpy, and continue going down this road
[20:08:19 CEST] <BBB> but Im not going along
[20:08:28 CEST] <BBB> do whatever you think is best
[20:08:36 CEST] <durandal_1707> we should pick our president
[20:08:53 CEST] <BBB> if you think its best to re-engage me into this community, then my best recommendation would be to adopt an enforceable CoC
[20:09:04 CEST] <atomnuker> a conflict free system wouldn't be able to yield optimal results, you'd get something that's a typical designed-by-committee deal where internally no one is unhappy but everyone's unhappy when they actually have to use it
[20:09:15 CEST] <BBB> maybe you dont think its broken, thats great! I think it is
[20:09:37 CEST] <atomnuker> BBB: it is enforcable, its just that no one has asked because we're all too nice!
[20:09:45 CEST] <gnafu> atomnuker: I don't think the problem is conflict itself, but unreasonable levels of disrespectful conflict.
[20:09:46 CEST] <atomnuker> again, misconceptions
[20:09:52 CEST] <BBB> *ahem* derek *ahem*
[20:10:09 CEST] <atomnuker> we didn't have one at the time
[20:10:11 CEST] <gnafu> Conflict is necessary, healthy, and good.  But just like anything, there are good and bad kinds.
[20:10:39 CEST] <durandal_1707> why derek always need to be so special?
[20:10:48 CEST] <atomnuker> the coc was enforced too, if you remember, 2 years ago to carl
[20:10:55 CEST] <jamrial> how is it enforceable? we've called for a vote in more than one ocassion and gotten no votes/result
[20:10:56 CEST] <atomnuker> so don't call it unenforcable!
[20:10:59 CEST] <atomnuker> it was enforced
[20:11:06 CEST] <atomnuker> but you still stick to your misconceptions!
[20:12:32 CEST] <jamrial> to carl? nothing came out of that. michael unilaterally decided to ban carl, himself and derek for a day to "solve" the issue and then everyone just said fuck it and stopped caring
[20:12:43 CEST] <atomnuker> yes it did, he was banned for a whole week from the ML
[20:12:46 CEST] <atomnuker> and no one liked it
[20:12:49 CEST] <jamrial> there was a call for a vote to ban carl from the project. nobody voted after the above
[20:12:52 CEST] <atomnuker> even people who voted for it
[20:14:31 CEST] <atomnuker> not to mention the stuff Compn pulled off some time ago, he enforced the coc and no one liked it
[20:14:51 CEST] <TimothyGu> I don't think that's a reason not to enforce the coc
[20:14:56 CEST] <TimothyGu> "no one liked it"
[20:15:09 CEST] <atomnuker> its not that its unenforcable, its just that we're too nice
[20:15:10 CEST] <TimothyGu> it's necessary for the further growth of the project, to encourage *new* people
[20:15:34 CEST] <atomnuker> bugger off, it isn't, no one looks at CoCs until they're after blood
[20:16:05 CEST] <TimothyGu> strong opinion, but misguided
[20:16:52 CEST] <atomnuker> I do think we're actually the most liberal bunch of people working on a large project; we'd accept patches from anyone who's done anything
[20:17:04 CEST] <atomnuker> criminals included
[20:17:17 CEST] <atomnuker> most CoCs don't offer that
[20:18:08 CEST] <TimothyGu> That's not necessarily a good thing
[20:21:27 CEST] <atomnuker> the mailing list is for judging patches, not people
[20:22:05 CEST] <TimothyGu> and making it possible for people to do the former
[20:23:06 CEST] <atomnuker> which it is, unless misconceptions are involved
[20:24:15 CEST] <atomnuker> what I've gotten at is that your original point about newcomers seeking inclusiveness is moot; we include everyone, even dead people
[20:25:13 CEST] <TimothyGu> Yeah, and my point is including toxic people (a single toxic person even) excludes more people than it includes
[20:27:03 CEST] <atomnuker> and yet when we tried to exclude someone you've seen what happens!
[20:27:09 CEST] <gnafu> atomnuker: Like Elvis, yeah?  {:-]
[20:28:11 CEST] <atomnuker> now, suppose there was a person calling everyone an asshole who never did patches and just spammed the mailing list, he'd be banned, right?
[20:28:16 CEST] <atomnuker> the system works!
[20:29:41 CEST] <gnafu> As someone who's never submitted patches, I wonder if I should put that theory to the test ;-).
[20:30:20 CEST] <durandal_1707> try it!
[20:31:10 CEST] <gnafu> That's why I feel like I could be a good CoC enforcer.  I can be objective, because I only lurk on IRC and use ffmpeg; I've not contributed code or stirred up trouble on the ML.
[20:31:26 CEST] <atomnuker> don't do anything like the "remove eggplant" fiasco from a few years ago and you won't be called an asshole
[20:31:57 CEST] <atomnuker> we've had enforcers before, they don't work
[20:32:03 CEST] <atomnuker> so thanks but no thanks
[20:32:19 CEST] <j-b> no, you never had actual enforcers
[20:32:42 CEST] <atomnuker> we did, Compn, and we judged that free discussion was more important
[20:32:42 CEST] <durandal_1707> let j-b be our president/enforcer!
[20:33:04 CEST] <atomnuker> again, misconceptions
[20:33:05 CEST] <j-b> durandal_1707: I am not sure you want that.
[20:33:23 CEST] <j-b> You want a few people elected that can do that.
[20:33:34 CEST] <j-b> but, I kicked quite a few people from the VLC project for behavior
[20:33:59 CEST] <durandal_1707> really? last time when?
[20:34:12 CEST] <j-b> hmm, one month ago, or two.
[20:34:38 CEST] <j-b> we kick people from forum, remove commit access, ban from mailing lists, etc...
[20:35:17 CEST] <durandal_1707> here you are only auto-banned
[20:35:26 CEST] <j-b> and there is no week where I don't warn someone for behavior
[20:36:03 CEST] <j-b> I did it on Friday, for example.
[21:02:37 CEST] <durandal_1707> i wrote SIMD for overlay filter - you should worship me!
[21:18:43 CEST] <jamrial> BBB: regarding av1 packet/TU splitting, a frame header obu may be follwed by two or more tile group obus, and not strictly just one, right?
[21:18:52 CEST] <BBB> yes
[21:18:58 CEST] <BBB> each tile group has header bits to indicate its range
[21:19:12 CEST] <BBB> and you can parse the bits to see how many/which TGs you need for 1 frame worth of data
[21:19:26 CEST] <BBB> now, its true that it totally SUCKS that you need to parse the whole frame header to parse the tile group header
[21:19:33 CEST] <BBB> since it relies on knowing how many tiles are in a frame
[21:19:41 CEST] <BBB> and the tile bits are at the very end of the frame header
[21:19:45 CEST] <BBB> but ohwell
[21:19:56 CEST] <BBB> ¯\_(Ä)_/¯
[21:20:36 CEST] <jamrial> but you only need to parse the whole frame header to get to the tile group header if they are both contained in a single frame obu
[21:21:30 CEST] <jamrial> if they are frame header obu + one or more tile group OBUs, you can skip to the tile group obus by just looking at the obu sizes in question
[21:22:01 CEST] <BBB> no
[21:22:22 CEST] <BBB> lets say the first tile group covers tile 1-2 and the second tile group covers tile 3-4
[21:22:26 CEST] <BBB> how would you know there are 4 tiles?
[21:22:40 CEST] <BBB> you need to parse the frame header :-/
[21:23:48 CEST] <jamrial> so i can't just say "i found a frame header, lets include it and every tile group that follows it into a packet and split as soon as i find some other obu"?
[21:24:12 CEST] <BBB> in TCP, sure
[21:24:18 CEST] <BBB> I mean, it just happens to work
[21:24:23 CEST] <BBB> but in general, no
[21:26:19 CEST] <jamrial> a bsf only works with complete packets. isn't the parser's job to decide what is and then build a complete packet if needed?
[21:26:52 CEST] <BBB> ¯\_(Ä)_/¯
[21:27:03 CEST] <BBB> whether its a parser or a bsf or a unicorn, something has to assemble packets
[21:27:14 CEST] <BBB> and for that, you need to know which tile groups together make one frame worth of input data
[21:27:24 CEST] Action: gnafu votes for a unicorn, every time.
[21:37:36 CEST] <durandal_1707> this Carl guy, watches unicorns every day I believe
[21:44:38 CEST] <jamrial> BBB: well, a split bsf injected by the decoder will not be able to wait for data and combine it. that's what parsers are meant to do from within libavformat generic code
[21:45:28 CEST] <BBB> so what is the distinct job assignment of a parser vs. a splitter then?
[21:45:36 CEST] <BBB> I understand parser = create one obu unit
[21:46:00 CEST] <BBB> but how does the parser vs. splitter know which obus make one frame worth of input data?
[21:46:12 CEST] <BBB> someone needs to parse the headers
[21:49:03 CEST] <nevcairiel> historically the parser would do that
[21:49:52 CEST] <jamrial> i can write the splitter bsf, which will take whatever is sent to avcodec_decode_video2 or avcodec_send_packet (normally a full temporal unit) and split it internally to be consumed by the decoder
[21:50:20 CEST] <jamrial> as nevcairiel, the parser would have to actually make sure you get complete data from the demuxer
[21:51:22 CEST] <jamrial> i guess a bsf could just request more data and actually combine stuff, but no codec currently does that as that's the job of parsers
[21:51:43 CEST] <jamrial> i don't even know if the generic code autoinserting bsfs would like that
[21:52:24 CEST] <jamrial> currently, for vp9, the parser does nothing with data (just marks keyframes), and the split bsf splits what's expected to be a full superframe
[22:02:44 CEST] <durandal_1707> JEEB: i desperately need sample
[22:07:49 CEST] <JEEB> durandal_1707: finished my food now so what you want is !black stuff in first frame?
[22:08:01 CEST] <durandal_1707> yes
[22:08:16 CEST] <JEEB> that one thing I linked with stuff in middle wasn't good enough I guess?
[22:08:34 CEST] <durandal_1707> its is good, but i need something more complicated shape
[22:08:38 CEST] <JEEB> ok
[22:08:55 CEST] <durandal_1707> just to confirm if bitstream parsing is fully ok
[22:08:56 CEST] <JEEB> time to iterate over files
[22:09:50 CEST] <JEEB> uhh, this first one I found is kind of dim in the beginning but it mostly seems to use the full thing
[22:09:55 CEST] <JEEB> or you want something bright?
[22:10:44 CEST] <JEEB> oh hey
[22:10:46 CEST] <JEEB> bright stuff
[22:10:49 CEST] <durandal_1707> yes
[22:12:00 CEST] <JEEB> ok, found something with brightness at start
[22:12:16 CEST] <durandal_1707> is it KB2f?
[22:12:30 CEST] <JEEB> yes
[22:12:38 CEST] <JEEB> I mean I'm still going through xcom videos
[22:12:39 CEST] <JEEB> lol
[22:12:42 CEST] <durandal_1707> great
[22:13:26 CEST] <JEEB> also why the fuck does this sample have like 9 audio tracks
[22:13:36 CEST] Action: JEEB shrugs
[22:15:02 CEST] <JEEB> durandal_1707: hopefully this is gut enough https://0x0.st/sVLw.bk2
[22:25:47 CEST] <JEEB> durandal_1707: was that good enough?
[22:29:49 CEST] <durandal_1707> JEEB: perfect!
[22:29:58 CEST] <JEEB> najs
[22:56:49 CEST] <jdarnley> Gah!  Do I need to explictly include some header to have START/STOP_TIMER work with --enable-linux-perf?
[22:57:27 CEST] <jdarnley> I ask because I get this all-to-common error "error: implicit declaration of function syscall"
[23:01:32 CEST] <atomnuker> no, you shouldn't, its only needed on arm
[23:04:57 CEST] <atomnuker> works fine without it here
[23:44:13 CEST] <cone-772> ffmpeg 03Lou Logan 07master:0e554bf4b9de: doc/mailing-list-faq: user lists are subscribe only
[23:44:22 CEST] <jdarnley> Ah, I missed that I must include it first so that it can get the _GNU_SOURCE define right.
[23:45:04 CEST] <jdarnley> it being timer.h
[00:00:00 CEST] --- Wed Jul 25 2018