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

[burek]

[00:07:38 CEST] <jkqxz> akravchenko188:  Do you have code for a filter using it?
[00:12:29 CEST] <durandal_1707> ubitux: read james-stein type center pixel weights for non-local means image denoising
[00:17:59 CEST] <durandal_1707> i just noticed, you already found it :)
[00:21:34 CEST] <akravchenko188> jkqxz: not yet.
[00:22:05 CEST] <akravchenko188> jkqxz: will be ready in couple of days
[00:23:05 CEST] <jamrial> jkqxz: crap, forgot to mention the ticket #
[00:53:34 CEST] <atomnuker> nevcairiel: which commit broke/unsupported support for msvc 2013?
[00:53:43 CEST] <atomnuker> because jkqxz would like to know
[00:54:02 CEST] <nevcairiel> that still works
[01:00:10 CEST] <atomnuker> was it jamrial who said it didn't?
[01:00:13 CEST] <atomnuker> or ubitux 
[01:00:57 CEST] <nevcairiel> msvc was broken for a few days recently because of some new POSIX system functions that it didnt have, but that affected all versions and was fixed
[01:17:35 CEST] <JEEB> tmm1: nice. I would still fix the program update signaling to API clients, but that's one way of handling it. will test it after I get some sleep
[01:23:30 CEST] <atomnuker> okay, it was JEEB
[01:23:43 CEST] <atomnuker> who said apparently we don't care about the msvc c99 conversion thing
[01:25:31 CEST] <JEEB> which was for 2012 and older
[01:25:41 CEST] <JEEB> and IIRC we no longer test those in FATE so that was my assumption
[01:26:14 CEST] <JEEB> 2013 is when MS got trolled enough to actually update their C part
[01:26:26 CEST] <JEEB> aand actually advertised FFmpeg support
[01:26:42 CEST] <JEEB> (although it was semi-failing until VS2013 update 1 or 2)
[01:58:28 CEST] <tmm1> JEEB: yea, i think AVProgram entries are persistent so we could add a EVENT flag there
[01:59:11 CEST] <tmm1> i saw mythtv's ffmpeg fork has some hacks to detect program changes.. they just added a function pointer that gets invoked on changes
[02:00:56 CEST] <jamrial> tmm1: did you take a look at the valgrind error in mpegts since 9152c1e495?
[02:02:24 CEST] <tmm1> i pushed a commit earlier to fix it
[02:05:20 CEST] <JEEB> tmm1: right, a callback was one thing I was thinking about but I think someone here didn't like that idea
[02:05:24 CEST] <jamrial> tmm1: ah cool, thanks
[02:05:35 CEST] <JEEB> and yes, I just checked that AVPrograms didn't seem to get av_free'd
[02:05:52 CEST] <JEEB> the most they seem to be done is in add_pat_entry
[02:06:01 CEST] <JEEB> where av_reallocp_array is used
[02:06:11 CEST] <JEEB> but that's Program
[02:06:14 CEST] <JEEB> not AVProgram
[02:06:16 CEST] <tmm1> yea callback seems pretty hacky, i think an event flag would be ok
[02:06:30 CEST] <tmm1> yea i just figured that out earlier too, program vs avprogram and only programs are cleared
[02:06:54 CEST] <JEEB> yea, if it seems like AVPrograms stay around behind the same memory address then a flag in it would be OK
[02:07:16 CEST] <JEEB> because a client can then at first pick the AVProgram that interests it
[02:07:20 CEST] <JEEB> and then keep following it
[02:19:51 CEST] <klaxa> hmm, just realized i want to configure streams per server otherwise i'd have to either check and compare ports for multiple servers or disallow it making the <streamname> part in the url pointless and also seems like an unneeded restirction, however now the config file already looks a bit more complex :S https://gist.github.com/klaxa/cbb5df840746b4bed559f25d10a3d13b
[02:21:11 CEST] <klaxa> atomnuker, after having looked at the glauss readme i can see where you are coming from with suggesting lua, but don't you think it's a bit overkill?
[02:22:07 CEST] <klaxa> i've been mulling over this for much longer than i should have...
[02:22:35 CEST] <atomnuker> that's why we ought to do it properly
[02:22:59 CEST] <atomnuker> its not an overkill, lua is a common dep nowadays, and its quite lightweight
[02:23:19 CEST] <atomnuker> sure its powerful, its a programming language as well
[02:24:09 CEST] <atomnuker> but when you have complex issues you shouldn't implement nih programming languages in your config files
[02:24:30 CEST] <atomnuker> that's how M4 came about
[02:24:55 CEST] <klaxa> do we have complex issues though? i "just" need a few settings, nothing should go deeper than 2 levels
[02:25:38 CEST] <klaxa> i want to configure the bind address and port per httpd and a number of streams per httpd with a number of formats
[02:26:27 CEST] <klaxa> i'll read more of the configs in your repo to get an understanding of how it would look in lua
[02:28:09 CEST] <atomnuker> welp, just see how complicated ffserver configure files were: https://www.ffmpeg.org/sample.html
[02:28:50 CEST] <nevcairiel> they are modelled after apache config files apparently, its  really not that bad
[02:28:51 CEST] <klaxa> yeah i managed to get a stream working once
[02:29:13 CEST] <klaxa> but i also realized that ffserver could not *not* re-encode
[02:29:47 CEST] <klaxa> that's pretty much when i looked into alternatives and couldn't really find any
[02:29:49 CEST] <atomnuker> this works for a fixed amount of inputs and outputs, and I think it would be nice to be able to react to any new input streams (if allowed) and dynamically change settings
[02:30:58 CEST] <klaxa> dynamically as in while the server is running, add a new stream or something? i thought about that as well
[02:31:13 CEST] <klaxa> or remove a stream prematurely
[02:32:31 CEST] <klaxa> hmm... not sure how the config file is involved in that, but i think you got me convinced
[02:32:42 CEST] <klaxa> >rng_seed = os.time(),
[02:32:53 CEST] <klaxa> oh well, i can already think of tons of uses for things like that
[08:19:39 CEST] <cone-397> ffmpeg 03Vishwanath Dixit 07master:e3518821c95d: avformat/dashenc: configuring container format options
[09:06:56 CEST] <durandal_1707> ubitux: so how shall we proceed with nlmeans patches?
[09:21:25 CEST] <kylehyde6> Hey all! i want tohire a developer to help me in devel eit tables for ffmpeg
[09:58:48 CEST] <durandal_1707> atomnuker: is your non-power of 2 fft/dct anywhere near completion? this work is very important.
[10:26:51 CEST] <durandal_1707> kylehyde6: i can not understand what you have written
[10:27:27 CEST] <JEEB> EIT tables are a thing in MPEG-TS
[10:27:49 CEST] <JEEB> Electronic program Information Table I think?
[10:54:27 CEST] <kylehyde6> durandal_1707 i need somone to devel EIT tables , a developer
[10:55:10 CEST] <kylehyde6> yes ! jeeb
[10:55:23 CEST] <kylehyde6> and i want to devel eit tables because ffmpeg does not insert it
[12:27:54 CEST] <BtbN> enabling DMARC reporting on my domains and then sending a mail to ffmpeg-devel gets me 12 responses about DMARC violations. Nice
[12:29:08 CEST] <nevcairiel> mailing lists are basically screwed with all the fancy mail validation things, since they want to send mails originating from you
[12:29:27 CEST] <BtbN> that's SPF, I have that disabled
[12:29:33 CEST] <BtbN> or rather in "non-enforcing" mode
[12:29:55 CEST] <BtbN> It's complaining about "dkim=permerror (signature verify error: message body does not hash to bh value)"
[12:30:10 CEST] <nevcairiel> it also adds its footer
[12:31:50 CEST] <BtbN> That should not break dkim, since the footer is in its own MIME part, and the dkim header only applies to the first one
[12:32:05 CEST] <BtbN> but ffmpeg-devel breaks them somehow. It also breaks PGP/MIME signatures that way
[12:32:50 CEST] <BtbN> I feel like the mailman handling ffmpeg-devel is in need of an update?
[12:44:33 CEST] <jdarnley> From what I hear, the breakage started occurring "recently", so I assumed some update borked it.
[12:52:56 CEST] <BtbN> also quite possible
[14:35:25 CEST] <kierank> gagandeep: any progress?
[15:29:28 CEST] <gagandeep> kierank: right now reading huffman coding in finite state machines for understanding
[15:29:41 CEST] <gagandeep> you were right though, tables are ok
[15:29:57 CEST] <gagandeep> so either problem in entropy decoding or dequantization
[15:30:41 CEST] <kierank> you don't need to understand huffman tables
[15:30:47 CEST] <kierank> you just need to check values match and where they don't
[15:30:54 CEST] <kierank> 99% dequantisation
[15:31:03 CEST] <kierank> the thing about huffman coding is that it either works or it doesn't
[15:33:48 CEST] <gagandeep> also, in the comparison i did yesterday, for a range of pixel ffmpeg cfhd gave values like 5 then followed by some zeroes and then -5, but in testcfhd the same pixels were all 5
[15:34:31 CEST] <kierank> -5?
[15:34:32 CEST] <kierank> pixel?
[15:34:34 CEST] <kierank> impossible
[15:34:37 CEST] <kierank> can't have negative pixels
[15:35:20 CEST] <gagandeep> probably a problem in printf type
[15:35:33 CEST] <gagandeep> but only subband 8 gave different values
[15:36:06 CEST] <gagandeep> kierank: not pixels but transform values
[15:36:37 CEST] <gagandeep> after that inverse is performed, my bad i didn't mean pixels here but dequantized buffer before inverse
[19:13:15 CEST] <durandal_1707> atomnuker: so?
[19:14:51 CEST] <atomnuker> durandal_1707: yes, I hear you, I'm working on it, I know its important (for the 3d denoiser, right?)
[19:16:27 CEST] <durandal_1707> and siren
[19:18:31 CEST] <atomnuker> right
[19:19:20 CEST] <atomnuker> do you know of any place in the code that calls permute, does something to the coefficients and then calls to perform the transform in the standard power of two fft?
[19:19:32 CEST] <atomnuker> I'm trying to figure out if I need to leave an API for that or not
[19:20:11 CEST] <atomnuker> and I'm trying to figure out what to do in the case of fft vs mdct, since ffts are performed in-place but mdcts are not, and I'd like to not have 2 separate functions to do those
[19:21:44 CEST] <atomnuker> right now there's a single function av_ft_tx(ctx, dst, src), where src can be NULL if the transform is in-place
[19:22:45 CEST] <atomnuker> the function takes in a void pointer to a buffer since I don't want to have multiple functions for double FFTs, RDFts, or integer FFTs
[19:23:42 CEST] <durandal_1707> i doubt anything use permute the way you described
[19:26:35 CEST] <atomnuker> I'll keep that merged into the tx function then
[20:13:55 CEST] <JEEB> durandal_1707: btw were you ever at VDD?
[20:20:21 CEST] <atomnuker> nope
[20:22:10 CEST] <JEEB> unfortunate
[20:22:23 CEST] <atomnuker> yep
[20:48:22 CEST] <cone-174> ffmpeg 03Aman Gupta 07master:64bf915cd851: avformat/mpegts: fix incorrect indentation
[21:11:11 CEST] <tmm1> can someone add a sample to fate-suite for me?
[21:12:01 CEST] <tmm1> >curl -o fate-suite/mpegts/pmtchange.ts http://0x0.st/secA.ts
[21:12:39 CEST] <JEEB> wonder if it was jamrial or michaelni who has access to the suite
[21:23:55 CEST] <jamrial> tmm1: done
[21:25:17 CEST] <tmm1> jamrial: thanks!
[21:35:21 CEST] <atomnuker> heh, someone just linked an explosives manual on #ffmpeg
[21:40:01 CEST] <jdarnley> oooh forbidden knowledge
[21:49:16 CEST] <wm4> what do they want to blow up
[22:41:26 CEST] <akravchenko188> jkqxz: hi. I am implementing amf converter/scaler. I am new in FFmpeg, if you don't mind I will ask a few questions here, or better to write in forum?
[22:41:58 CEST] <atomnuker> could you just map amf frames to vulkan and opencl?
[22:42:08 CEST] <atomnuker> and use a scaler that's already implemented
[22:44:01 CEST] <jkqxz> akravchenko188:  Generally here is much easier for discussion, so sure.
[22:46:22 CEST] <jkqxz> atomnuker:  I meant that you should make an explicit test for the declaration-as-clause-1-of-for-loops thing.  Like, actually try to compile it in configure and reject the compiler if it fails.
[22:46:44 CEST] <jkqxz> Anything else leaves the danger of people managing to get further and then complaining that some files don't compile.
[22:49:41 CEST] <akravchenko188> 1) amf converter/scaler I am going to integrate is hw accelerated colorspace converter;memory type converter(from/to DX9/DX11/OpenCL + Vulkan in coming);scaler;crop. what name to use? vf_scaler_amf/vf_converter_amf
[22:50:39 CEST] <jkqxz> What is the actual dependency on AMF in it?
[22:51:57 CEST] <akravchenko188> this component implemented in AMF
[22:52:59 CEST] <akravchenko188> to use in in FFmpeg I need to implement filter which wraps is and reuses hwcontext_amf
[22:53:26 CEST] <jkqxz> So the input is a DX11 texture (or one of the others), that gets mapped in to AMF, some AMF component operates on it, the output gets mapped to DX11 again and sent to the output?
[22:54:16 CEST] <akravchenko188> right, but input memory type can be different then output memory type
[22:54:59 CEST] <jkqxz> How will that work?  Do you need AMF -> DX11/others device derivation as well?
[22:56:28 CEST] <akravchenko188> yes
[22:57:16 CEST] <jkqxz> Hmm, that probably means we want to distinguish device_derive_from and device_derive_to (like map_from and map_to, etc.).
[22:58:12 CEST] <jkqxz> (Given that, it may be more straightforward to start with input matching output.)
[22:59:12 CEST] <jkqxz> But coming back to your question, if you do both scaling and colour conversion then it should probably be called vf_scale_amf and offer at least the same interface as the other vf_scale(_foo) filters.
[22:59:30 CEST] <jkqxz> It's not a problem to do more on top of that with extra private options.
[22:59:55 CEST] <akravchenko188> ok, lets have vf_scale_amf name
[23:01:22 CEST] <atomnuker> jkqxz: as I said, I am unaware of any compiler not supporting this, not even a 14 year old gcc version which tests on fate, apart from msvc
[23:01:45 CEST] <atomnuker> so I'd like to take my chances and if someone does report an issue I'll make a test
[23:02:23 CEST] <jkqxz> Did you ask on the user mailing list for anyone?
[23:02:27 CEST] <atomnuker> (besides, another compile test will likely make windows people angrier as it would add a few tens of seconds to configure)
[23:02:36 CEST] <atomnuker> jkqxz: ask what?
[23:04:18 CEST] <jkqxz> Whether anyone uses funny compilers which might run into problems if the coding rules are changes.
[23:05:44 CEST] <atomnuker> I think you're overthinking this
[23:05:50 CEST] <akravchenko188> jkqxz: I have read code of QSV scaler, there is AV_PIX_FMT_QSV pixel format. I think here we dont need AV_PIX_FMT_AMF, we just need to create frame contexts of OpenCL and DX11 types in scaler amf
[23:06:30 CEST] <cone-174> ffmpeg 03Marton Balint 07master:2dbe936bf7f9: avformat/webm_chunk: always use a static buffer for get_chunk_filename
[23:06:31 CEST] <cone-174> ffmpeg 03Marton Balint 07master:1b2471039b23: avutil/hwcontext_cuda: fix YUV420P cuda_get_buffer
[23:08:13 CEST] <akravchenko188> jkqxz: is there way to reuse hwcontext_amf created earlier in pipeline? for exampe we have decoder -> amfscaler->some opencl filters -> amfscaler -> amf_encoder
[23:09:11 CEST] <akravchenko188> or any other contexts
[23:09:39 CEST] <jkqxz> If the input device is derived from an AMF device then derivation will recover the original device.
[23:12:04 CEST] <akravchenko188> ok, thanks. I will read hwcontext machinery more detaily
[23:12:54 CEST] <jkqxz> If you have derivation the other way then you can do e.g. "-init_hw_device vaapi=a:some_args -init_hw_device d3d11va=d at a -hwaccel_device d -i ... -vf hwmap=derive_device=amf,..." and the hwmap instance will recover the original AMF device.
[23:13:30 CEST] <jkqxz> Oops, s/vaapi/amf/.  (This can be useful for the libmfx + opencl + vaapi/d3d cases.)
[23:15:01 CEST] <akravchenko188> ok, I think I got idea
[23:17:16 CEST] <akravchenko188> jkqxz: are you going to push patch with initial hwcontext_amf? or there are some issues?
[23:17:53 CEST] <jkqxz> I don't think it should be pushed without an actual use-case?
[23:17:53 CEST] <cone-174> ffmpeg 03Marton Balint 07release/4.0:7931e01540a1: avformat/webm_chunk: always use a static buffer for get_chunk_filename
[23:18:33 CEST] <jkqxz> Remember that you are defining external API here, it can't be changed once applied.
[23:21:46 CEST] <cone-174> ffmpeg 03Mark Thompson 07master:136260eb88e8: hwcontext: Do not call device_init again when deriving an existing device
[23:21:47 CEST] <cone-174> ffmpeg 03Mark Thompson 07master:989c5a84acff: lavu/Makefile: Fix alignment and ordering
[23:24:02 CEST] <akravchenko188> jkqxz: ok, no problem, we can postpone it until scaler is ready. I just wanted to make sure there's nothing there which breaks main concepts
[23:27:51 CEST] <BBB> atomnuker: wheres your av1 decoder again?
[00:00:00 CEST] --- Wed May 16 2018