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

[burek]

[05:08:20 CEST] <cone-704> ffmpeg 03Michael Niedermayer 07master:62f07825ba11: avcodec/vp3: Check that there will be sufficient input for the coded fragments in unpack_superblocks()
[06:51:30 CEST] <cone-704> ffmpeg 03Karthick Jeyapal 07master:c76a6c93bfc3: avformat/dashenc: Add documentation for http method option
[11:09:45 CEST] <durandal_1707> all developement appears dead
[11:38:24 CEST] <cone-596> ffmpeg 03Tomas Härdin 07master:10ed9f2b1293: Add IRC nicknames
[13:55:58 CEST] <BBB> does anyone agree it would be useful to know *why* ossfuzz runs out of diskspace wtih the iterate api? or is that just me?
[14:03:53 CEST] <JEEB> yes, be it ossfuzz's fault or a current feature of the iteration API
[14:04:02 CEST] <JEEB> it would be a NiceToKnow thing
[14:05:13 CEST] <wbs> JEEB: it has been mentioned multiple times in discussions around the new iterate api
[14:05:42 CEST] <JEEB> well BBB brought it up like the details aren't known
[14:05:42 CEST] <wbs> previously, you could build a full libavcodec with everything, but when statically linking, if you don't call the avcodec_register() function, you can just link in the single codec you wanted to use
[14:06:29 CEST] <wbs> now with the new iterate api, linking in a single codec with static linking out of a full build won't work and you'll end up linking in every single codec
[14:06:31 CEST] <JEEB> and now they're all there linked which of course raises some space requirements
[14:06:50 CEST] <BBB> so doesnt that mean ossfuzz should use disable-everything --enable-codec=bla?
[14:06:59 CEST] <BBB> or am I totally misunderstanding things here?
[14:07:06 CEST] <wbs> no, that's probably the right thing to do
[14:07:16 CEST] <BBB> I also wasnt aware hd space was expensive
[14:07:28 CEST] <durandal_1707> they are lazy, they do not want to do the right thing
[14:07:36 CEST] <nevcairiel> its probably to simplify the setup, they can build all the codecs in one go and then just link the ones they want - at least thats how it used to work
[14:07:43 CEST] <BBB> I mean I probably sound like an ass, but Ive always been of the opinion that a test build should be as identical as possible to the prod build
[14:08:32 CEST] <BBB> anyway, tnx for explaining, thats all I needed to know, so its not actually a bug in ffmpeg or anything, its just a cost thing on their end
[14:09:12 CEST] <BtbN> That can't be more than 100MB extra or so. Or does that multiply a lot with the fuzzer?
[14:09:32 CEST] <wbs> I think it does one build per codec
[14:09:48 CEST] <durandal_1707> what!!!
[14:13:55 CEST] <JEEB> well, that minimizes code
[14:14:10 CEST] <wbs> this is all in the normal code in git master already, do a "git grep target_dec", you can do e.g. "make target_dec_aac_fuzzer"
[14:44:06 CEST] <Compn> annoying email worm finally found a correct email to spoof to the list
[15:41:07 CEST] <durandal_1707> atomnuker: at what percentage is your fft/dct ?
[15:41:26 CEST] <durandal_1707> ubitux: are you alive?
[15:41:45 CEST] <ubitux> durandal_1707: yeah sorry, i'll look at your patch later today
[15:41:55 CEST] <ubitux> patches*
[15:46:36 CEST] <klaxa> ok, so first on my list is having a configuration file by the end of the week, i think we determined that .ini should be good enough for the things i want to configure, here is what i think a sample configuration could look like: https://gist.github.com/klaxa/44ae10accbbb2feef3ffd043d60fdf57
[15:47:30 CEST] <klaxa> since ini is rather simple to parse, should i just parse it myself or is there a small library i should take a look at?
[15:50:45 CEST] <JEEB> probably I'd recommend not NIH'ing parsing of any config file format
[15:51:05 CEST] <JEEB> I only remember a library for JSON, json-c (pkg-config 'json'), though
[15:51:12 CEST] <JEEB> since that was what we used at my previous place
[15:52:12 CEST] <JEEB> https://github.com/01org/murphy/blob/master/src/common/json.c
[15:52:33 CEST] <JEEB> I didn't code any of this I think, but just for reference should it ever become useful
[15:53:38 CEST] <klaxa> i've used json-c for another project before
[15:54:07 CEST] <JEEB> did it drive you insane?
[15:54:09 CEST] <klaxa> hmm... json is basically as simple to write as ini
[15:54:17 CEST] <klaxa> not at all
[15:54:28 CEST] <klaxa> my jsons were about as simple as i see them becoming here
[15:54:34 CEST] <JEEB> :)
[15:54:51 CEST] <klaxa> and json can even work with lists (for the format field) so it has some benefits over ini
[15:54:58 CEST] <JEEB> yup
[15:55:24 CEST] <JEEB> it seems to be the go-to thing for various configuration bits in various places due to its web origins and relative readability
[15:56:06 CEST] <klaxa> true, the server even already logs in json, i think json it is
[16:00:24 CEST] <klaxa> ok, updated with json https://gist.github.com/klaxa/44ae10accbbb2feef3ffd043d60fdf57 i'm wondering if i'm missing something, but especially with json and when using json-c it should be pretty easy to add things later on
[16:03:19 CEST] <durandal_1707> adding uneeded depedencies is considered harmful for project
[16:04:23 CEST] <klaxa> NIH'ing things is also considered harmful, which one is it? :)
[16:04:58 CEST] <cone-242> ffmpeg 03Paul B Mahol 07master:e3a697eda3b7: avfilter/vf_amplify: check if array is availabe before using it
[16:04:58 CEST] <cone-242> ffmpeg 03Paul B Mahol 07master:80b474875e72: avfilter/vf_srcnn: use function to get number of threads
[16:05:09 CEST] <JEEB> It's a stand-alone application that might as well not be in the FFmpeg repo. So its needs should be considered. So if he already found usefulness in JSON's typing with things like arrays, then so be it
[16:05:27 CEST] <JEEB> giving vague comments about things does not help, and it's not an ffmpeg.c dependency anyways.
[16:05:51 CEST] <JEEB> and to be honest, NIH'ing JSON output in ffprobe.c was borderline
[16:05:56 CEST] <JEEB> at least output is simpler than parsing
[16:06:26 CEST] <durandal_1707> just implement stupid parsing configuration file imho
[16:07:18 CEST] <gagandeep> kierank: i have found the problem with the deinterlacing, its dequantization
[16:07:33 CEST] <kierank> gagandeep: ah good
[16:07:46 CEST] <gagandeep> the subband 7, 8, 9
[16:07:59 CEST] <gagandeep> they have very large difference in values
[16:08:37 CEST] <gagandeep> i was skeptical before jumping in p frames as i was not able to figure out deinterlacing so i took some time in it
[16:08:55 CEST] <gagandeep> it will need to do something with fsm and codebook to fix it
[16:09:43 CEST] <JEEB> durandal_1707: alright. you've got your opinion, klaxa's got his opinion, and most likely klaxa's mentor has an opinion. at some point it is going to get reviewed and then it will be found out how to proceed. we're all cool.
[16:10:36 CEST] <gagandeep> kierank: how do i go about codebook and dequantization
[16:10:40 CEST] <durandal_1707> if ffserver is separate project i do not care
[16:10:55 CEST] <kierank> gagandeep: codebook is correct i think
[16:11:15 CEST] <kierank>  dequant maybe wrong
[16:11:40 CEST] <gagandeep> kierank: i was also looking into dequant before in cineform but now i will need to see it seriously
[16:12:49 CEST] <gagandeep> ok, now i can see p frames without being afraid of why interlace didn't work even after tracing the whole function
[16:16:43 CEST] <gagandeep> kierank: but i am seeing only subband 8 having different values, you sure this is not a problem with tables? though i don't know how fsm is being used for dequant properly right now
[16:17:41 CEST] <gagandeep> i mean subband 7 and 9 have very minor variation but subband 8 has large value variations for the same pixel when compared to testcfhd
[16:18:29 CEST] <gagandeep> oh no, subband 9 is also messed up
[16:24:35 CEST] <kierank> ah
[16:24:43 CEST] <kierank> must be dequant, I doubt the tables are wrong
[16:39:40 CEST] <atomnuker> klaxa: no ini, use lua
[16:39:49 CEST] <atomnuker> no json either, use lua
[16:39:57 CEST] <atomnuker> I'll give you some code to do the parsing
[16:44:02 CEST] <atomnuker> klaxa: https://github.com/atomnuker/glauss/blob/master/input/parser.c#L753
[16:44:37 CEST] <atomnuker> and here is how you read a table of settings after init - https://github.com/atomnuker/glauss/blob/master/input/parser.c#L964
[16:47:54 CEST] <atomnuker> let me repeat - ffserver or in fact pretty much every project needs a script-like config file
[16:48:05 CEST] <atomnuker> have you seen the insane lengths people go to have custom behaviour?
[16:48:36 CEST] <atomnuker> if you wanted to have custom functions in json what would you do?
[16:48:48 CEST] <atomnuker> wrap C code in strings and pass them off as values?
[16:50:18 CEST] <JEEB> sure, I was going to also say that the config files were lua in that project I linked, but I had no idea what the requirements were in this case
[16:50:55 CEST] <JEEB> if INI was being discussed then at least JSON would have been more typed
[16:59:18 CEST] <atomnuker> lua config files look something like this - https://github.com/atomnuker/glauss/blob/master/DOCS/examples/fluid.lua#L2
[17:00:28 CEST] <wm4> lua is idiotic for config files
[17:00:41 CEST] <JEEB> some people really like it
[17:00:47 CEST] <JEEB> because then you can write a window manager in lua
[17:00:51 CEST] <JEEB> (which I was developing)
[17:01:10 CEST] <JEEB> but it really depends on the requirements
[17:02:16 CEST] <atomnuker> its perfect for config files, its what it was designed for, and its a million times more readable than json
[17:04:42 CEST] <sfan5> lua was designed as a programming language, not a config file syntax
[17:05:12 CEST] <sfan5> sure, using it for configs matches the "embeddable" aspect. other than that, not so much
[17:05:12 CEST] <iive> i like the lua config file idea/example
[17:06:04 CEST] <iive> sfan5, i think the idea is that people won't have to write their own scripts to configure ffserver, they will write them directly in lua
[17:07:21 CEST] <sfan5> ah, using lua does make sense in that context
[17:11:30 CEST] <wm4> atomnuker: that lua example is also a subset of extended json
[17:11:48 CEST] <wm4> also lua can't distinguish between objects and arrays, that's a huge wtf
[17:11:56 CEST] <wm4> and its stack API is annoying and error prone
[17:12:16 CEST] <wm4> and I bet you don't handle OOM and other lua errors correctly
[17:12:24 CEST] <wm4> because it's fucking hard
[17:12:48 CEST] <durandal_1707> should use python instead
[17:13:15 CEST] <iive> let's cut directly to rust :P
[17:34:50 CEST] <cone-242> ffmpeg 03Reino Wijnsma 07master:1548d2a5a547: configure: add pkg-config check for libmysofa
[18:28:53 CEST] <cone-242> ffmpeg 03Paul B Mahol 07master:a27cab9eca63: avfilter/vf_blend: add timeline support to tblend filter
[18:28:54 CEST] <cone-242> ffmpeg 03Paul B Mahol 07master:2bde38c0ab6c: avfilter/vf_lut2: add timeline support to tlut2 filter
[18:32:20 CEST] <jdarnley> atomnuker: I
[18:32:32 CEST] <jdarnley> atomnuker: I'll support you on your Lua crusade
[18:33:01 CEST] <jdarnley> durandal_1707 might too.  I think he wrote a bit for lavfi some time ago.
[18:34:19 CEST] <durandal_1707> no, use Rust
[19:08:50 CEST] <wm4> wow atomnuker got his embedtls benchmarks
[19:09:59 CEST] <kierank> I don't see why atomnuker pushed back so hard
[19:10:07 CEST] <kierank> it's a good ssl library
[19:10:19 CEST] <kierank> or is this some kind of "older is better" fantasy
[19:10:33 CEST] <nevcairiel> who knows why anyone does anything, half the people s eem to just hate everything
[19:11:00 CEST] <durandal_1707> yes, i agree
[19:11:29 CEST] <wm4> kierank: because we have a dozen of them already
[19:11:45 CEST] <wm4> and it isn't even fully license compatible apparently?
[19:11:54 CEST] <kierank> it's gpl, no?
[19:12:16 CEST] <durandal_1707> we have bunch of non-free "crap"
[19:12:19 CEST] <wm4> wikipedia says apache 2.0, "GPLv2 still available"
[19:12:26 CEST] <nevcairiel> its apache 2.0, which is a perfectly fine license, just the gpl people hate it
[19:12:32 CEST] <nevcairiel> but they also dual license as gpl
[19:12:52 CEST] <wm4> I still don't know whether or not this is compatible to LGPL
[19:12:58 CEST] <wm4> (2.1+)
[19:13:07 CEST] <wm4> though that's all I care about
[19:13:36 CEST] <durandal_1707> MIT is fine too
[19:26:36 CEST] <cone-242> ffmpeg 03Aman Gupta 07master:42a03e770006: avformat/mpegts: initialize section_buf to fix valgrind test failure
[20:06:34 CEST] <jdarnley> > Dear user of ffmpeg.org, administration of ffmpeg.org ...
[20:06:44 CEST] <jdarnley> I doubt the veracity of that email.
[20:06:45 CEST] <JEEB> :D
[20:07:20 CEST] <wm4> did anyone try to use bearssl?
[20:07:31 CEST] <wm4> it was suggested by nicolas and it's MIT
[21:02:19 CEST] <cone-242> ffmpeg 03Carl Eugen Hoyos 07master:20b88076223b: configure: Mention the dash demuxer in the libxml2 help text.
[22:41:43 CEST] <akravchenko188> jkqxz: hi, I have sent updated patch. Could you please review it? Thanks.
[22:48:43 CEST] <ubitux> durandal_1707: RE patch1/2; what do you mean by "better"?
[22:48:51 CEST] <ubitux> does it fix the edges or something?
[22:49:34 CEST] <ubitux> is this part of the nlm litterature?
[22:49:49 CEST] <durandal_1707> ubitux: it fixes smearing of edges
[22:50:15 CEST] <ubitux> would you mind posting a picture for before + after?
[22:50:44 CEST] <durandal_1707> ubitux: try it with:  -vf nlmeans=s=4:r=65:p=7:a=.8 with that sample
[22:50:54 CEST] <ubitux> ok
[22:51:14 CEST] <ubitux> and what's that amount thing?
[22:51:19 CEST] <ubitux> how is that different that strength?
[22:51:23 CEST] <durandal_1707> less blurring
[22:51:32 CEST] <ubitux> yeah but, what difference in semantic with strength?
[22:52:36 CEST] <j-b> Can someone explain to me what is the pkg-config that Carl is trying to solve?
[22:52:42 CEST] <j-b> I really don't get it
[22:52:57 CEST] <ubitux> he doesn't want to install pkg-config because some users may not want to install it
[22:53:03 CEST] <nevcairiel> he has a super broken setup himself and tries to fix all the shit
[22:53:10 CEST] <JEEB> even in a local prefix?
[22:53:22 CEST] <JEEB> and if pkg-config is an ass to compile into al ocal prefix, you always have pkgconf
[22:53:30 CEST] <JEEB> which fedora now has used as pkg-config for at least two releases
[22:53:32 CEST] <ubitux> also, he said several times he doesn't understand pkg-config
[22:53:37 CEST] <j-b> pkg-config-lite is trivial to build
[22:53:43 CEST] <JEEB> or that yes, j-b
[22:53:51 CEST] <JEEB> I also genuinely asked which systems that would be
[22:53:52 CEST] <ubitux> j-b: tbh, we tried every arguments
[22:54:00 CEST] <JEEB> but seemingly he just took that as facetious
[22:54:04 CEST] <JEEB> even though I specifically it was not
[22:54:08 CEST] <JEEB> (´4@)
[22:54:11 CEST] <j-b> Yeah, I read those
[22:54:18 CEST] <j-b> I thought I was missing something obvious.
[22:54:44 CEST] <j-b> I hate pkg-config like everyone else. But it solves a solution and is the standard now.
[22:55:02 CEST] <atomnuker> it won't matter as much once meson support gets more complete
[22:55:11 CEST] <j-b> true
[22:56:03 CEST] <JEEB> yes, pkg-config has issues and probably pkgconf still has issues - but it's the de facto solution and even works for android compilation for me
[22:56:51 CEST] <durandal_1707> ubitux: try it, it will better preserve details
[22:57:14 CEST] <ubitux> but then, any reason to keep strength?
[22:57:18 CEST] <ubitux> anyway, sure i'm going to test in a moment
[22:57:51 CEST] <ubitux> it's a really weird semantic; does any other nlmean implementation have both options?
[22:58:24 CEST] <ubitux> michaelni: i saw your report about the nlm test, i'll fix it asap, and i'm able to reproduce, sorry about the delay
[23:01:34 CEST] <jkqxz> jamrial:  I think we're all agreed now on using your fix for zero-length NAL units in h2645_parse.  Do you want to apply it?
[23:02:46 CEST] <jamrial> jkqxz: sure, one sec
[23:02:50 CEST] <jkqxz> akravchenko188:  The stray line with the trailing whitespace is still there?
[23:04:55 CEST] <jkqxz> And there is another.  (git complains about those - try applying it yourself.)
[23:07:27 CEST] <ubitux> durandal_1707: wait, from the beginning you meant the shapes/content edges, not the frame edges?
[23:07:49 CEST] <JEEB> &32
[23:08:09 CEST] <ubitux> durandal_1707: can you reproduce the "edge glitches" without `a` option?
[23:08:32 CEST] <durandal_1707> ubitux: yes
[23:09:12 CEST] <durandal_1707> ubitux: the handbrake have fixed weight for such pixels...
[23:12:03 CEST] <cone-242> ffmpeg 03James Almer 07master:9a09f4c54ab8: avcodec/h2645_parse: skip NALUs with no content after stripping all the trailing zeros
[23:13:37 CEST] <jamrial> jkqxz: done
[23:14:23 CEST] <jkqxz> Thank you!
[23:15:12 CEST] <ubitux> durandal_1707: can you provide parameters without `a` for testing patch1/2?
[23:17:16 CEST] <durandal_1707> ubitux: just try without it, and with 1st patch and without 1st patch
[23:23:14 CEST] <ubitux> ok i can reproduce
[23:23:24 CEST] <ubitux> nlmeans=s=4:r=65:p=7 seems enough to see a difference
[23:25:04 CEST] <akravchenko188> jkqxz: if I understand correctly, if you check some lines before it is another function with on the same place which looks like I added new line
[23:28:10 CEST] <jkqxz> akravchenko188:  <https://0x0.st/se8M.txt>
[23:30:35 CEST] <ubitux> durandal_1707: so what's the logic of this patch? afaiu, you're saying the current state of the pixel weigth as much as the one from the patch with the closest difference proximity
[23:31:14 CEST] <ubitux> did you take this from a paper or something? i'd say it simply smooth more
[23:32:06 CEST] <akravchenko188> jkqxz: oh, I see, I will test applying patch
[23:33:15 CEST] <ubitux> durandal_1707: maybe https://arxiv.org/pdf/1211.1656 ?
[23:34:26 CEST] <durandal_1707> ubitux: how it smooths more? without it i see broken edges with most parameters
[23:35:26 CEST] <ubitux> i'd say it looks broken but it's simply less denoised because less similar patches were found i'd 
[23:35:38 CEST] <ubitux> i think that's what we're observing here
[23:36:44 CEST] <ubitux> and your patch, afaiu, is basically saying "ok this patch doesn't look that close, but it's best we could find so we will consider its weight equal to the current one
[23:36:49 CEST] <ubitux> i'm not saying it's wrong
[23:37:05 CEST] <ubitux> i'm trying to understand why it seems to help, and what's the theory here
[23:37:31 CEST] <ubitux> we can't adjust such as studied algorithm randomly because it tweaking it looks better on one sample 
[23:37:47 CEST] <ubitux> so i was wondering where it's coming from etc
[23:38:30 CEST] <ubitux> (also, this is in the inner loop, it probably makes the filter slower, better think about it)
[23:38:46 CEST] <ubitux> how are other implementations behaving on this sample?
[23:39:07 CEST] <ubitux> do they also have the glitches? do they fix it differently?
[23:54:33 CEST] <durandal_1707> ubitux: read this docs: http://avisynth.nl/index.php/TNLMeans
[23:55:49 CEST] <akravchenko188> jkqxz: I have sent updated patch fixing trailing whitespace.
[23:59:23 CEST] <akravchenko188> jkqxz: I didnt know about such issues detection before. Thanks
[00:00:00 CEST] --- Tue May 15 2018