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

[burek]

[00:36:11 CEST] <durandal117> michaelni: everything points that something corrupts track_duration in movenc with that sample
[00:41:19 CEST] <michaelni> durandal117, sent 2 patches that fix the assertion but i didnt analyse this deeply
[00:42:01 CEST] <JEEB> lessee
[00:46:05 CEST] <JEEB> yeah, better let it be poked properly. that's just adding the same invalid checks elsewhere as well (at least the dts one is invalid as that one is int64 in mov and uint64 in isobmff)
[00:46:54 CEST] <JEEB> (as in, better not just hack away in the night as it is pretty late now)
[00:50:09 CEST] <michaelni> JEEB, whatever the check does it has to be done in mov_write_single_packet() too as that uses the dts/pts and messing with them afterwards will lead to inconsistencies
[01:11:00 CEST] <atana> Hi, I am a OPW aspirant and would like to take a project under FFmpeg organization.
[01:11:52 CEST] <durandal117> ok
[01:11:54 CEST] <atana> I have gone through the ideas page here https://trac.ffmpeg.org/wiki/SponsoringPrograms/Outreachy/2016-12
[01:12:21 CEST] <atana> can students also propose their own idea?
[01:12:30 CEST] <atana> *participants
[01:14:21 CEST] <durandal117> yes, they can
[01:15:37 CEST] <atana> ok
[01:16:15 CEST] <atana> durandal117: could you tell me more about the XPM encoder/decoder project?
[01:17:53 CEST] <durandal117> atana: what you want to know?
[01:19:44 CEST] <atana> durandal117: I don't know what XPM is. So, it would be good if you could give a brief overview, what is it used for? any links/refs for algorithm
[01:20:29 CEST] <durandal117> atana: https://en.wikipedia.org/wiki/X_PixMap
[01:20:45 CEST] <atana> thanks :)
[01:55:19 CEST] <durandal117> michaelni: shouldn't initial timestamp start at any +int64 number for mov muxer, one just need to adopt track->start_dts?
[01:56:43 CEST] <michaelni> durandal117, i have a patch that improves the pkt check just need to test a bit before posting
[02:12:21 CEST] <michaelni> durandal_1707, patch posted, is it ok to push the 3 ?
[03:17:37 CEST] <cone-758> ffmpeg 03Vignesh Venkatasubramanian 07master:7238c53048e4: libavformat/webm_chunk: Option to specify HTTP header
[10:59:04 CEST] <ubitux> where the fuck is the -vb option parsed in ffmpeg cli?
[11:01:29 CEST] <BtbN> nowhere, according to grep.
[11:01:43 CEST] <ubitux> it's parsed somewhere
[11:01:51 CEST] <ubitux> (and breaks with codecpar)
[11:03:29 CEST] <BtbN> there is "ab"
[11:03:32 CEST] <BtbN> and "b"
[11:03:35 CEST] <BtbN> but not vb
[11:03:50 CEST] <ubitux> try it
[11:04:44 CEST] <nevcairiel> opt_map calls check_stream_specifier (which is avformat_match_stream_specifier), which probably maps the "v" to a video stream, leaving a simple "b"
[11:05:04 CEST] <ubitux> ah!
[11:05:58 CEST] <nevcairiel> at least thats what would make sense to me
[11:06:17 CEST] <BtbN> yeah, avformat_match_stream_specifier does *spec == 'v'
[11:06:17 CEST] <ubitux> that makes sense, i'm going to dig that way
[11:06:19 CEST] <ubitux> thanks
[11:06:50 CEST] <nevcairiel> (or some other use of check_stream_specifier, it used in some more places)
[11:07:28 CEST] <nevcairiel> ie. in the MATCH_PER_STREAM_OPT macro
[11:46:52 CEST] <ubitux> ok i got it
[11:47:15 CEST] <ubitux> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=cmdutils.c;h=44f44cdb0b133a158c57aeb700c096a1748dbbd8;hb=HEAD#l565
[11:47:18 CEST] <ubitux> this ^
[11:47:45 CEST] <nevcairiel> so many ugly aliases for things
[11:47:46 CEST] <ubitux> -vb ’ opt="vb", so it searches for a "b" option
[11:48:05 CEST] <nevcairiel> didnt we conceptually deprecate those in favor of -b:v
[11:48:42 CEST] <ubitux> and then it matches libavcodec/options_table.h:{"b", "set bitrate (in bits/s)", OFFSET(bit_rate), AV_OPT_TYPE_INT64, {.i64 = AV_CODEC_DEFAULT_BITRATE }, 0, INT64_MAX, A|V|E},
[11:48:51 CEST] <ubitux> we did
[11:48:56 CEST] <ubitux> i'm going to adjust the fate test
[11:49:01 CEST] <ubitux> but i wanted to check what was going on
[11:49:21 CEST] <nevcairiel> why is the option failing anyway? shouldnt you still be able to set video bitrate?
[11:49:23 CEST] <ubitux> i still wonder if these aliases are useful though
[11:49:37 CEST] <ubitux> yeah i'm going to check why first
[11:50:20 CEST] <wbs> JEEB: btw, when setting the itsoffset stuff, you might want to set movflags frag_discont as well, to indicate that this packet isn't supposed to be "the start of the stream" but is supposed to look like a continuation on a previous stream (i.e. starting from a nonzero timestamp)
[11:54:34 CEST] <BtbN> ubitux, they are catering to ancient scripts that people still keep copying from stackoverflow
[11:57:12 CEST] <durandal_17> without frag_discont one get reported start to nonzero value
[12:10:55 CEST] <cone-026> ffmpeg 03Michael Niedermayer 07master:deabcd2c05b2: avformat/movenc: Factor check_pkt() out
[12:10:56 CEST] <cone-026> ffmpeg 03Michael Niedermayer 07master:28343139330f: avformat/movenc: Check packet in mov_write_single_packet() too
[12:10:57 CEST] <cone-026> ffmpeg 03Michael Niedermayer 07master:51000b994514: avformat/movenc: Make the packet check more tolerant
[12:38:55 CEST] <cone-026> ffmpeg 03Paul B Mahol 07master:5b509fafb07a: avfilter/vf_lut2: also export video input bit depth
[12:45:08 CEST] <atomnuker> hm, showcqt can output rgb as well
[12:48:03 CEST] <atomnuker> durandal_17: know any way to force showcqt to output rgb?
[12:49:21 CEST] <atomnuker> apparently it's set by config_output's outlink->format
[12:50:26 CEST] <atomnuker> (how does that behave when the input is audio?)
[13:00:46 CEST] <durandal_17> atomnuker: mpv input -lavfi-complex "[aid1]asplit[a][ao],[a]showcqt=size=hd720,format=rgb24[vo]"
[13:04:45 CEST] <atomnuker> neat, didn't know you could do that, didn't show up in the help for the filter
[13:57:23 CEST] <ubitux> ok bitrate issue in codecpar branch fixed with http://sprunge.us/FENZ
[13:57:41 CEST] <nevcairiel> that seems sensible
[13:57:58 CEST] <ubitux> this function acts as a option filter, "vb" becomes "b", which can then be found in lavc options
[13:58:50 CEST] <ubitux> but st->codec wasn't set anymore at this point, so the prefix 'v' wasn't set and thus failed to drop the prefix from the option
[13:59:02 CEST] <ubitux> onto the next issues.
[13:59:33 CEST] <ubitux> all subtitles broken, this is going to be fun
[13:59:51 CEST] <ubitux> codec tb shit incoming
[13:59:51 CEST] <nevcairiel> seems somewhat odd that it would use st->codec for switching, but then write the option into an encode ctx independent of that?
[14:00:29 CEST] <ubitux> dunno
[14:38:01 CEST] <JarJar> x
[14:43:03 CEST] <ubitux> ah, haha, pkt_timebase.
[15:36:59 CEST] <atomnuker> which decoders do not support AV_CODEC_CAP_DR1 currently?
[15:46:52 CEST] <durandal_17> atomnuker: h264_vda, libvorbis, maybe more
[15:47:32 CEST] <durandal_17> qsvdec_vc1
[15:50:45 CEST] <BBB> DR1 only makes sense for video
[15:50:50 CEST] <BBB> so libvorbis & ehm ...
[15:50:52 CEST] <BBB> well ...
[15:51:01 CEST] <JEEB> that's a good one
[15:54:47 CEST] <nevcairiel> DR1 just means buffers are allocated through get_buffer2 these days, so its used for audio as much as video
[16:07:28 CEST] <ubitux> jamrial: i took the mkv change in (the information was somehow ignored previously), the bitrate one is fixed (forgot a usage of codecpar in one place), the subtitles as well (setting pkt_timebase)
[16:08:20 CEST] <jamrial> ubitux: awesome
[16:08:32 CEST] <jamrial> and yeah, figured the mkv change was probably desired
[16:09:16 CEST] <ubitux> now i'm having an issue with remuxing mkv
[16:09:36 CEST] <ubitux> because the codec option -color_trc is not transmitted anymore (stream copy after all)
[16:10:26 CEST] <nevcairiel> that seems like a good thing
[16:10:35 CEST] <nevcairiel> :D
[16:10:59 CEST] <ubitux> well, it seems to be useful to "fix" wrong information
[16:11:04 CEST] <jamrial> nevcairiel: BBB made a test specifically to make sure that information is copied :p
[16:11:20 CEST] <ubitux> copied is the wrong term, set is better
[16:11:37 CEST] <Chloe> What's wrong with development discussion in IRC?
[16:11:39 CEST] <nevcairiel> jamrial: and its present in codecpar, so not sure where it would vanish to
[16:11:40 CEST] <ubitux> it has unknown trc, and the remux cli sets it
[16:11:41 CEST] <BBB> Chloe: nothing
[16:11:47 CEST] <BBB> Chloe: its totally fine
[16:11:50 CEST] <nevcairiel> Chloe: some people feel entitled because they dont like irc
[16:11:58 CEST] <nevcairiel> and we intentionally do this to leave them out
[16:11:59 CEST] <nevcairiel> or something
[16:12:07 CEST] <nevcairiel> they should just join if they want to take part
[16:12:11 CEST] <BBB> (it should be noted that nevcariel is being sarcastic)
[16:12:18 CEST] <nevcairiel> no way
[16:12:18 CEST] <BBB> (just to make sure people dont quote this out of context)
[16:12:37 CEST] <nevcairiel> they could still do that and just leave yours out
[16:12:42 CEST] <nevcairiel> if you go out of  context, might as well go all the way
[16:13:00 CEST] <Chloe> Aren't the irc logs online anyway?
[16:13:03 CEST] <nevcairiel> they are
[16:14:54 CEST] <nevcairiel> anyway why are people discussing so much anyway, its a vote, not a discussion =p
[16:17:37 CEST] <BBB> because some people spread misinformation
[16:17:40 CEST] <BBB> and thats never a good thing
[16:17:49 CEST] <BBB> Im still waiting for Marton to say his thing
[16:26:28 CEST] <cone-026> ffmpeg 03Pedro Arthur 07master:8433d953e4f1: swscale: fix for sliced scaling artifacts
[16:55:40 CEST] <jamrial> ubitux, BBB: commit 9c4943e shows why the color_trc test is failing now
[16:55:59 CEST] <BBB> theres a test failing?
[16:56:53 CEST] <ubitux> jamrial: mmmh
[16:56:53 CEST] <jamrial> BBB: ubitux is porting ffmpeg to codecpar. the test you added for color_trc remuxing in matroska is failing after that
[16:57:03 CEST] <BBB> oh I see
[16:57:50 CEST] <jamrial> libav directly removed this av_opt_set_dict call in a following commit
[16:58:26 CEST] <jamrial> since it seems encoder options don't belong in stream copy
[16:59:31 CEST] <ubitux> i just kind of adjusted the streamcopy parameter setting in my branch but it didn't really help
[16:59:48 CEST] <ubitux> there is indeed a confusion between which settings to use
[17:00:17 CEST] <nevcairiel> codecpar contains those settings, does it not? i would think stream copy would just copy the codecpar from demux to mux?
[17:00:52 CEST] <ubitux> in case of stream copy, we (and libav) do this:
[17:00:54 CEST] <ubitux> ret = av_opt_set_dict(ost->enc_ctx, &ost->encoder_opts);
[17:00:58 CEST] <jamrial> nevcairiel: the problem seems to be overwritting it from the command line
[17:01:06 CEST] <nevcairiel> oh right
[17:01:17 CEST] <nevcairiel> and cli probably targets some fake encoder ctx
[17:01:21 CEST] <ubitux> so the color trc is explicitely transfered to the "encoding context"
[17:01:27 CEST] <jamrial> ubitux: libav doesn't anymore: https://git.libav.org/?p=libav.git;a=commitdiff;h=1e93c1e30ff0e8bf6094a426ca60f005e9cdaed3
[17:01:42 CEST] <ubitux> now what we probably want is to actually fill the stream codecpar from this context
[17:09:53 CEST] <ubitux> ok this is going to be very annoying
[17:12:51 CEST] <jamrial> is it even correct for that matter to overwrite this kind of parameter from the command line in a stream copy?
[17:18:01 CEST] <ubitux> it makes sense to me
[17:18:55 CEST] <ubitux> well
[17:19:03 CEST] <ubitux> i think we need an AVClass in codecpar.
[17:19:08 CEST] <ubitux> :(
[17:19:52 CEST] <ubitux> so we can av_opt_set_dict(ost->st->codecpar, &ost->encoder_opts)
[17:19:57 CEST] <jamrial> which can't be done without a major bump at this point...
[17:20:13 CEST] <ubitux> right, so we're fucked \o/
[17:20:42 CEST] <ubitux> so. what solutions do we have now
[17:20:51 CEST] <jamrial> an ugly, long function that compares every codecpar field with those in the ost->enc_ctx and copies the ones that are different?
[17:20:57 CEST] <ubitux> :(
[17:22:17 CEST] <ubitux> or maybe use ost->encoder_opts to set a dummy codec (ost->enc_ctx maybe) which will be applied as soon as we create that new output stream
[17:22:19 CEST] <jamrial> avcodec_parameters_to_context(ost->enc_ctx, ost->st>codecpar) followed by av_opt_set_dict(ost->enc_ctx, &ost->encoder_opts) followed by ugly long compare function
[17:22:36 CEST] <ubitux> which will then be overriden with random other settings (hopefully not completely?)
[17:23:39 CEST] <jamrial> whatever the solution is should be temporary until we bump major anyway. it wont matter if it's ugly
[17:25:30 CEST] <ubitux> ok i have an idea
[17:28:36 CEST] <ubitux> in transcode_init(), i need to create an avcodec, import parameters from ist->codepar, apply encoders options on it, then use this codec context as source instead of input stream codecpar 
[17:29:20 CEST] <jamrial> sounds good if it works. better than a compare function for sure
[17:30:55 CEST] <jamrial> ubitux: can't you use the existing ost->enc_ctx for this?
[17:31:06 CEST] <ubitux> that's what i'm trying to do
[17:31:22 CEST] <jamrial> alright
[17:36:51 CEST] <ubitux> works.
[17:36:53 CEST] <ubitux>             par_src = avcodec_parameters_alloc();
[17:36:55 CEST] <ubitux>             avcodec_parameters_to_context(ost->enc_ctx, ist->st->codecpar);
[17:36:57 CEST] <ubitux>             av_opt_set_dict(ost->enc_ctx, &ost->encoder_opts);
[17:36:59 CEST] <ubitux>             avcodec_parameters_from_context(par_src, ost->enc_ctx);
[17:37:01 CEST] <ubitux> heh.
[17:41:37 CEST] <ubitux> ok, fate-hevc-paramchange-yuv420p-yuv420p10 now
[17:41:42 CEST] <ubitux> but i feel lazy
[17:42:00 CEST] <jamrial> heh, paramchange
[17:42:52 CEST] <ubitux> nope nope nope :(
[17:48:08 CEST] <ubitux> this is going to be too annoying
[17:48:21 CEST] <ubitux> i'm going back to nlmeans for now
[17:48:31 CEST] <ubitux> anyone is welcome in looking deeper into this
[17:48:42 CEST] <ubitux> i won't work on it this week end
[17:49:56 CEST] <durandal_1707> ubitux: what's missing?
[17:50:05 CEST] <ubitux> in what? nlmeans or codecpar?
[17:50:36 CEST] <durandal_1707> codecpar
[17:50:42 CEST] <ubitux> make fate passes
[17:50:50 CEST] <ubitux> at least fate-hevc-paramchange-yuv420p-yuv420p10 is failing
[17:51:26 CEST] <ubitux> then i need to do some cleanups (the codec options transfer in streamcopy)
[17:52:18 CEST] <ubitux> (codecpar branch on my github)
[17:53:14 CEST] <ubitux> fate-lavf-fate-mov_qtrle_mace6 seems to fail as well
[17:53:49 CEST] <ubitux> channel layout is not properly transmitted in fate-maxis-xa and fate-mxf-demux for some reason
[17:53:59 CEST] <ubitux> and actually a bunch of others
[17:54:19 CEST] <ubitux> so hevc param change (last frame pts broken), channel_layout thing
[17:54:40 CEST] <ubitux> dimension fuck up in fate-rv20-1239
[17:54:51 CEST] <ubitux> anyway, various fuckups
[18:35:54 CEST] <jamrial> ubitux: i think i found why the channel_layout is not transmitted in fate-maxis-xa. look at guess_input_channel_layout() in ffmpeg.c
[18:36:12 CEST] <jamrial> it's using ist->dec_ctx, which is correct for transcoding, but not for stream copy
[18:49:16 CEST] <ubitux> jamrial: oh.
[18:49:28 CEST] <ubitux> ok then
[18:50:05 CEST] <ubitux> thanks
[18:51:11 CEST] <jamrial> ubitux: libav didn't touch that function at all, though
[18:51:28 CEST] <ubitux> maybe they don't have such test?
[18:51:34 CEST] <jamrial> i'm compiling avconv to see if it also doesn't transmit the layout
[18:57:06 CEST] <jamrial> ubitux: yeah, doesn't transmit it, lol
[18:57:21 CEST] <ubitux> even HEAD?
[18:57:25 CEST] <jamrial> yeah
[18:57:34 CEST] <ubitux> ok well i'll fix it then
[18:57:36 CEST] <ubitux> thanks
[18:59:25 CEST] <jamrial> same as ffmpeg in your codecpar branch, avconv git head transmits the layout when transcoding but not with stream copy
[19:01:45 CEST] <jamrial> ubitux: guess they didn't notice it because their framecrc muxer doesn't print as many field values as ours
[20:21:50 CEST] <ubitux> jamrial: well, feel free to try to fix it, i'm tired of this
[20:22:52 CEST] <jamrial> ubitux: i'll give the channel_layout failure a try
[20:29:29 CEST] <jamrial> ubitux: http://pastebin.com/rL2mvctt fixes fate-maxis-xa and fate-mxf-demux
[20:29:37 CEST] <jamrial> dunno if it's the best solution
[20:30:17 CEST] <jamrial> we're kinda filling the cli with back and forth parameter copy function calls, haha
[20:30:45 CEST] <ubitux> :))
[20:32:14 CEST] <ubitux> feel free to work in a branch, i'll integrate your changes
[20:32:26 CEST] <ubitux> thanks for doing this
[20:32:27 CEST] <jamrial> that change is probably also needed for other things. there's a call to av_parse_video_size() above that changes width and height from ist->dec_ctx that would not be copied back to codecpar without this, assuming it's needed afterwards
[20:32:45 CEST] <ubitux> yeah i saw some dimensions failures
[20:32:55 CEST] <ubitux> how much tests are failing after this?
[20:34:11 CEST] <jamrial> if you mean fate-rv20-1239, i looked at it and it's lowres related. it seems to be ignoring the -lowres 1 command line option
[20:34:20 CEST] <jamrial> the above change doesn't fix it
[20:34:20 CEST] <ubitux> ah yeah
[20:34:27 CEST] <ubitux> the lowres thing, i know why it fails
[20:34:45 CEST] <jamrial> ah good
[20:35:06 CEST] <ubitux> i mean, pretty sure that's because i'm doing av_codec_get_lowres(st->codec)
[20:35:17 CEST] <ubitux> since lowres is, afaik, not in codecpar :p
[20:35:34 CEST] <jamrial> haha
[20:35:48 CEST] <durandal_170> lowres via avoptions
[20:37:16 CEST] <ubitux> oh and btw, the aac timing failures might be due to the drop of enc_ctx->delay = dec_ctx->delay; 
[20:37:20 CEST] <ubitux> under FF_API_AUDIOENC_DELAY
[20:37:29 CEST] <ubitux> which i didn't know how to handle (yet)
[20:48:32 CEST] <jamrial> ubitux: only four failures left
[20:48:51 CEST] <ubitux> :o
[20:49:09 CEST] <jamrial> copy-trac236, gaplessenc-itunes-to-ipod-aac, hevc-paramchange-yuv420p-yuv420p10 and rv20-1239
[20:49:39 CEST] <ubitux> gaplessenc-itunes-to-ipod-aac is probably due to that FF_API_AUDIOENC_DELAY thing
[20:50:16 CEST] <ubitux> there is probably an equivalent field though
[20:50:44 CEST] <jamrial> delay in codecpar is initial_padding, and it's apparently copied when you use avcodec_parameters_{to,from}_context
[20:51:14 CEST] <ubitux> mmh ok
[20:51:16 CEST] <jamrial> avcodecontext has delay and initial_padding. codecpar merged the two into a single initial_padding field
[20:51:35 CEST] <jamrial> one was for decoding and the other for encoding or some such
[21:25:59 CEST] <jamrial_> ubitux: i think i fixed gaplessenc-itunes-to-ipod-aac. let me run the whole fate set to see if i broke something else in theprocess
[21:36:27 CEST] <jamrial_> ubitux: nothing broke \o/
[21:36:30 CEST] <jamrial_> ubitux: basically, where you set pkt_timebase for subtitle streams i did the same for audio streams
[21:37:08 CEST] <ubitux> i don't want to know why
[21:37:19 CEST] <ubitux> because it's going to make me either sad or angry
[21:37:24 CEST] <ubitux> or both
[21:38:33 CEST] <durandal_170> why?
[21:43:55 CEST] <jamrial_> ubitux: pushed to codecpar branch on my github repo, same as my nick
[21:44:00 CEST] <jamrial_> so we're down to three failures
[22:08:41 CEST] <ubitux> jamrial_: nice, i'll merge that later
[22:08:51 CEST] <ubitux> durandal_1707: i fixed the exp lut accuracy
[22:08:59 CEST] <ubitux> if you want to retry nlmeans
[22:09:42 CEST] <durandal_1707> nice
[22:12:11 CEST] <ubitux> i'm going to simplify the whole integral business, add the ability to process chroma with different parameters, write some shitty doc, and submit
[22:12:20 CEST] <ubitux> i'll probably send a first patch tomorrow
[22:12:35 CEST] <ubitux> it's already pretty much usable
[22:12:42 CEST] <ubitux> be it wrt quality and speed
[22:15:04 CEST] <durandal117> ubitux: >8 bit support?
[22:15:16 CEST] <ubitux> in another life maybe
[22:15:36 CEST] <ubitux> you're going to hit annoying limitations with >8 bit support
[22:15:48 CEST] <durandal117> like?
[22:15:54 CEST] <ubitux> the integral shit
[22:16:51 CEST] <durandal117> hmm, tnlmeans doesn't have that code iirc
[22:17:07 CEST] <ubitux> and very large diff which will lead to the exp granularity to be shit on by hthe lut
[22:18:01 CEST] <ubitux> you might end up doing |a-b| instead of (a-b)² for the integral, but you'll need to adjust the math
[22:18:07 CEST] <ubitux> and analyse the consequences on psnr
[22:18:16 CEST] <ubitux> and i'm not exactly ready to do that
[22:18:20 CEST] <ubitux> at least not now
[22:51:29 CEST] <durandal117> ubitux: can't you do gbrp for free, also can't some more parameters be added?
[22:52:06 CEST] <ubitux> gbrp might be doable without much effort yes
[22:52:15 CEST] <ubitux> i'll add more parameters: ones for chroma
[22:55:48 CEST] <durandal117> ubitux: does 'simplify integral business' improves speed?
[22:56:51 CEST] <ubitux> probably very marginally, but will hopefully drop a lot of code
[22:57:34 CEST] <ubitux> the last thing to do in order to speed up things right now is to simd compute_safe_ssd_integral_image_c()
[22:57:45 CEST] <ubitux> but i'm not sure yet if it's its last form
[23:01:40 CEST] <ubitux> do you have speed issues?
[23:02:07 CEST] <ubitux> it looks relatively fast to me for a "similar block searching" denoiser
[23:02:17 CEST] <durandal117> just wondering can it be improved
[23:02:19 CEST] <ubitux> it's not meant to be used for real time
[23:02:33 CEST] <ubitux> but yeah, basically only the integral as simd to be done
[23:02:57 CEST] <ubitux> ah and maybe the weighting final pass
[23:03:21 CEST] <ubitux> line 432 to 442
[23:03:51 CEST] <ubitux> that one should be simdifiable as well
[00:00:00 CEST] --- Sat Sep 17 2016