[03:40:41 CEST] <rcombs> wow this samsamsam reply [03:41:08 CEST] <rcombs> >Anyway we are talking about safety but parser for mp4 atoms missing checking and there is quite easy to make segfault of the libavformat when try to prepared mp4 file. [03:41:08 CEST] <rcombs> >I understand that you want to have maximum safety with new code but I hope you know that ffmpeg at all is not safety. [14:10:22 CEST] <cone-396> ffmpeg 03Jun Zhao 07master:385cafb07ac1: lavc/vaapi_encode_h265: Enable VBR mode [14:10:23 CEST] <cone-396> ffmpeg 03Jun Zhao 07master:e4a6eb70f471: lavc/vaapi_encode: Change the slice/parameter buffers to dynamic alloc. [14:10:24 CEST] <cone-396> ffmpeg 03Mark Thompson 07master:b264810ef7a3: hevc: Add names for reserved NAL unit types [15:23:46 CEST] <JEEB> ah, `{"threads", "set the number of threads", OFFSET(thread_count), AV_OPT_TYPE_INT, {.i64 = 1 }, 0, INT_MAX, V|A|E|D, "threads"}` [15:29:03 CEST] <rcombs> I'm not entirely sure why that's set to 1 [15:29:18 CEST] <rcombs> ffmpeg.c (or is it ffmpeg_opt.c) sets it to 0, except when probing [15:29:20 CEST] <gh0st__> I had the same problem /w thread_count [15:37:58 CEST] <JEEB> yea, it sets to zero => nonzero return => "auto" [15:39:06 CEST] <BBB> back when the default was chosen, I believe someone (I cant remember who) complained that making the default zero (auto) would mean that the behaviour changed [15:39:14 CEST] <BBB> a trollwar followed [15:39:21 CEST] <BBB> and the end result was the default being 1, not 0 [15:40:46 CEST] <JEEB> I think you still have to poke around with threads for libvpx [15:40:51 CEST] <JEEB> since for it zero == one [15:42:59 CEST] <ubitux> i thought <whatever> == one with libvpx [15:45:44 CEST] <JEEB> vp9 encoder lately'ish enabled threading [15:45:50 CEST] <JEEB> as in, within N months [16:10:25 CEST] <kierank> eugh [16:10:26 CEST] <kierank> av_log_set_level(AV_LOG_DEBUG); [16:13:32 CEST] <kierank> avfilter_graph_alloc_filter [16:13:36 CEST] <kierank> just silently dies [16:13:36 CEST] <kierank> lovely [16:13:43 CEST] <JEEB> o_O [16:53:35 CEST] <durandal_170> kierank: really? [16:53:58 CEST] <kierank> if filter is not compiled in yes [17:10:58 CEST] <JEEB> ah [17:11:16 CEST] <JEEB> still probably not supposed to happen :) [17:17:55 CEST] <durandal_170> JEEB: you working on that? [17:24:11 CEST] <wm4> does it return an error code? [17:24:18 CEST] <wm4> (which of course will be completely useless) [17:24:59 CEST] <nevcairiel> its not like log messages are particularly helpful for api users =p [17:26:02 CEST] <kierank> wm4: the av_get_filter does [17:27:54 CEST] <BBB> ubitux: libvpx has tile threading (enc and dec, afaik) [17:28:22 CEST] <BBB> ubitux: ffvp9 single-threaded is almost as fast as libvpx with 2 tile threads, but still [17:28:25 CEST] <BBB> its something [17:32:08 CEST] <JEEB> durandal_170: nope, got onto train and going home :p [17:36:46 CEST] <rcombs> wm4: inb4 error code -1 [17:39:08 CEST] <BBB> error code -1 still beats randomly palced abort()s [18:06:39 CEST] <RiCON> BtbN: http://sprunge.us/cCiW [18:08:36 CEST] <atomnuker> iive: why do you have to mess with pic at all in your code? [18:09:18 CEST] <atomnuker> none of the asm I've written has had to deal with that [18:12:14 CEST] <iive> because I have a "table" lookup. so addr+reg, [18:15:46 CEST] <iive> when using pic, you can have only [rpi+const] no second register in there. [18:16:01 CEST] <iive> rip [18:16:50 CEST] <atomnuker> const_int32_offsets? [18:17:05 CEST] <atomnuker> what does $-const_int32_offsets mean? [18:17:08 CEST] <iive> masks [18:17:36 CEST] <iive> $ is the current address, it just calculates the offset from the start of the define. [18:18:25 CEST] <atomnuker> so you pick const_float_0_5 or const_float_1 or const_float_sign_mask on runtime? [18:18:41 CEST] <iive> what do you mean by pick? [18:19:06 CEST] <atomnuker> load one without a jump into a register [18:19:22 CEST] <iive> ?? [18:19:58 CEST] <iive> you mean, like `addps m0, [const_blabla]` ? [18:20:16 CEST] <atomnuker> e.g. in c code memcpy(out, stack_start + selection*sizeof(const_float_0_5), sizeof(const_float_0_5)) [18:20:41 CEST] <iive> that's even more confusing. [18:20:57 CEST] <atomnuker> what are you looking up and in which table? [18:21:16 CEST] <iive> oh [18:21:37 CEST] <iive> the sign mask is also used as padding mask [18:22:14 CEST] <iive> to filter out the extra padding of the input data and pad the tmpX[N+1]=0.0 [18:22:31 CEST] <iive> [N] actually too. [18:23:30 CEST] <atomnuker> so what do you look up? [18:24:39 CEST] <iive> the mask [18:25:41 CEST] <atomnuker> but its 0x80000000 everywhere [18:26:42 CEST] <iive> it's unaligned access and it reads into the follow up zeroes [18:27:17 CEST] <iive> aka, padding=0, (aligned access) would load the whole sign mask. [18:27:55 CEST] <iive> padding=(mmsize-1), would load only one 0x80000000 and the rest is zero. [18:28:15 CEST] <atomnuker> there's vmaskmov for this, isn't there [18:28:26 CEST] <iive> no [18:28:40 CEST] <iive> it needs the mask beforehand [18:31:50 CEST] <atomnuker> movaps m2, [const_float_sign_mask] [18:32:16 CEST] <atomnuker> where do you do the lookup into const_float_sign_mask? [18:32:43 CEST] <iive> and maskmov is around 3000 cycles on Ryzen. [18:34:11 CEST] <iive> movups m2, [pic_base_const_align_abs_edge + r4 - mmsize] [18:39:09 CEST] <atomnuker> if you know that the padding is never going to be larger than mmsize couldn't you just pcmpeqd [18:39:54 CEST] <atomnuker> rather PCMPGTW [18:40:24 CEST] <atomnuker> where you have 0, 1, 2, 3 in the second register and the padding splatw'd across the first register [18:41:08 CEST] <atomnuker> so as padding increases so would the resulting parts of the register be filled with 0 [18:41:20 CEST] <atomnuker> so then you just AND them to look right [18:43:01 CEST] <iive> it's a lot more instructions [18:43:20 CEST] <iive> and it goes over integer domain and back [18:44:28 CEST] <iive> get the padding from gprs into m0 [18:44:35 CEST] <iive> broadcast it [18:44:43 CEST] <iive> load offsets [18:44:51 CEST] <iive> compare [18:45:01 CEST] <iive> and with sign [18:47:45 CEST] <iive> then move result from int to float domain, and hope you get just 1 cycle penalty [18:50:32 CEST] <atomnuker> integer domain and back penalty is missing from anything newer than 2011 and its a lot less messy than touching pic yourself [18:50:47 CEST] <atomnuker> besides you do this once at init [19:14:25 CEST] <iive> what is the problem with pic? [19:27:09 CEST] <iive> atomnuker: what is your problem with pic? [20:00:39 CEST] <iive> atomnuker: [20:13:38 CEST] <durandal_170> atomnuker is speechless [20:13:41 CEST] <atomnuker> iive: I don't like it because its messy and can be avoided [20:15:16 CEST] <iive> well, if you have something that is faster and works the same, then I'm on to it [20:15:34 CEST] <iive> if you want to make the code bigger and slower, for no real reason or benefit [20:15:41 CEST] <iive> then NO [20:44:43 CEST] <atomnuker> if I have something that's slower and bigger when put into your code I'll rewrite the entire search then [20:51:21 CEST] <iive> good luck with that. [21:54:29 CEST] <kierank> wm4: oh wow that email [21:56:19 CEST] <BtbN> how do you even mess up a reply that bad? [21:56:57 CEST] <wm4> well there is a user-agent [21:57:35 CEST] <wm4> "GWP-Draft" [21:57:39 CEST] <wm4> whatever that is [21:58:14 CEST] <BtbN> Google gives nothing useful for that [22:00:12 CEST] <kierank> lol [22:33:23 CEST] <philipl> wm4: "...so I wrote my own mail client." Now you have two problems. [22:36:05 CEST] <philipl> https://generatewp.com/allow-multiple-recipients-wordpress-mail/ [22:36:07 CEST] <philipl> I bet that's it. [22:36:11 CEST] <philipl> and that's terrifying. [22:39:22 CEST] <wm4> what the hell [22:42:56 CEST] <JEEB> lol [22:45:40 CEST] <Mavrik> ... how? [22:45:56 CEST] <Mavrik> "Let me use my WordPress as a mail client?" O.o [22:51:29 CEST] <atomnuker> if the chromium folks want to save space they can just clean up the code of libvpx [22:51:45 CEST] <atomnuker> abstraction over abstraction over abstraction to do a dct [22:52:10 CEST] <atomnuker> additional 2d dcts on top of that which are only used for rdo [22:53:01 CEST] <nevcairiel> for odd reasons they get set strict size constraints for their thrid-party plugins, no matter what they do [22:54:28 CEST] <atomnuker> libvpx is third party too [22:54:31 CEST] <Mavrik> Probably some silly thing like lack of space on Chromecast or Home devices. [22:55:09 CEST] <nevcairiel> atomnuker: its still a single library though, and they probably expect entire ffmpeg to be the same size as vpx =p [23:00:56 CEST] <kierank> at the same time it's very difficult to remove junk from ffmpeg [23:01:12 CEST] <jamrial_> they are already removing two thirds of the stuff in libavutil in a custom way, leaving only md5, crc and the avcodec relevant modules [23:02:48 CEST] <atomnuker> kierank: its very easy to remove certain things [23:03:05 CEST] <atomnuker> yet for some like lavr its very hard (thanks nevcairiel) [23:03:13 CEST] Action: kierank uses lavr [23:03:19 CEST] <atomnuker> and you [23:03:47 CEST] <kierank> hmmm seems --disable-ffserver is the culprit [23:04:03 CEST] <kierank> if you add that then junk like ffm muxer and asf goes away [23:04:24 CEST] <jamrial_> ffm sure, but asf how? [23:04:55 CEST] <kierank> oh lets do this fairly and use a new ffmpeg [23:05:01 CEST] <jamrial_> isn't that wmv? [23:05:07 CEST] <nevcairiel> it is [23:05:22 CEST] <nevcairiel> but who knows what ffm all pulls in [23:07:09 CEST] <kierank> --disable everything pulls in: [23:07:10 CEST] <kierank> asf mov mpegts rm rtsp [23:07:30 CEST] <kierank> cuda cuvid nvenc [23:07:41 CEST] <kierank> most of it goes away with --disable-ffserver [23:07:49 CEST] <kierank> except that cuda stuff which I explicitly remove [23:08:01 CEST] <BtbN> why does that not fall under disable everything? [23:08:02 CEST] <jamrial_> ffserver_select="ffm_muxer rtp_protocol rtsp_demuxer" [23:08:06 CEST] <jamrial_> rtp probably pulls the asf stuff [23:08:41 CEST] <jamrial_> BtbN: disable-everything doesn't disable ffmpeg/ffplay/ffprobe/ffserver [23:08:48 CEST] <jamrial_> that's done by disable-programs [23:09:03 CEST] <BtbN> cuda/nvenc I mean [23:09:13 CEST] <BtbN> I see no reason why it should be enabled in a disable-everything build [23:09:37 CEST] <kierank> why can't --disable-everything disable programs [23:10:22 CEST] <nevcairiel> because thats what --disable-all does, i guess [23:10:27 CEST] <nevcairiel> (confusing, i know) [23:10:45 CEST] <kierank> yeah just seen that [23:10:46 CEST] <kierank> news to me [23:10:51 CEST] <nevcairiel> speaking of odd build things, configure on windows enables x11 [23:10:58 CEST] <nevcairiel> which apparently has no system dependencies whatsoever [23:11:11 CEST] <JEEB> hah [23:11:12 CEST] <nevcairiel> doesnt cause any issues either [23:11:15 CEST] <nevcairiel> but its just there [23:11:20 CEST] <jamrial_> really? it doesn't for me [23:11:22 CEST] <kierank> note --disable-all still does [23:11:22 CEST] <kierank> cuda cuvid nvenc [23:11:44 CEST] <kierank> cuda_deps_any="dlopen LoadLibrary" [23:11:50 CEST] <kierank> everyone has those so I guess it works [23:11:55 CEST] <nevcairiel> jamrial_: xlib to be precise [23:12:20 CEST] <nevcairiel> https://pastebin.com/wuT8uzJZ shrug [23:13:41 CEST] <jamrial_> kierank: not really, but it doesn't hurt for those that don't since it just fails if you try to use it [23:14:13 CEST] <kierank> but it means shipping bloat [23:14:13 CEST] <jamrial_> nevcairiel: oh lol, i see CONFIG_XLIB=yes in my config.mak [23:15:45 CEST] <jamrial_> nevcairiel: https://pastebin.com/Ptx0HR2P maybe [23:17:48 CEST] <nevcairiel> yeah guess its just never disabled [23:17:57 CEST] <jamrial_> grep -r CONFIG_XLIB * --> no results [23:18:19 CEST] <nevcairiel> is it used as a dep for other things? [23:18:22 CEST] <nevcairiel> or just old? [23:18:30 CEST] <jamrial_> within configure, for those headers [23:19:15 CEST] <nevcairiel> seems never used anywhere [23:19:24 CEST] <jamrial_> xv_outdev_deps="X11_extensions_Xvlib_h XvGetPortAttribute" [23:19:39 CEST] <nevcairiel> that sounds like a dumb way to do it [23:19:47 CEST] <jamrial_> probably [23:19:48 CEST] <nevcairiel> why not just depend on xlib [23:21:59 CEST] <BtbN> hm, so disable-everything does disable all the encoders/decoders [23:22:07 CEST] <BtbN> Don't understand how cuvid and nvenc survive that [23:22:52 CEST] <nevcairiel> it disables everything in COMPONENT_LIST, which doesnt include the libraries themself, only actuel encoders/decoders [23:23:12 CEST] <BtbN> But that should mean no actual code is left? [23:23:14 CEST] <kierank> https://www.irccloud.com/pastebin/Ng6t7Czt/ [23:23:20 CEST] <kierank> cuda stuff is in avutil [23:23:26 CEST] <nevcairiel> the avutil hwcontext stuff remains, indeed [23:23:52 CEST] <nevcairiel> could extend disable-everything to in clude those, especially the autodetected stuff [23:28:04 CEST] <wm4> funny, all this bullshit about not having autodetection by default (which severely confuses users), and it gets it wrong anyway [23:28:31 CEST] <wm4> you'd almost think autodetection everything by default is ok, and --disable-everything should just disable everything [23:28:52 CEST] <wm4> instead of using autodetection only "sometimes" and --disable-everything not actually disabling everything [23:29:14 CEST] <nevcairiel> i would like an option like --disable-external-shit [23:29:36 CEST] <nevcairiel> i dont want unexpected external deps on anything [23:29:46 CEST] <nevcairiel> but i dont want to have to deal with enabling all internal components again manually [23:30:23 CEST] <nevcairiel> these days I have to ldd binaries before i can be sure i can ship them [23:31:20 CEST] <nevcairiel> speaking of, i should probably make a new build and finally get off my ass and implement hw decoding on linux now that all the hwcontext stuff does all the hard work for me [23:33:04 CEST] <jamrial_> is this about $dayjob stuff? [23:33:29 CEST] <nevcairiel> yea [23:36:04 CEST] Action: kierank wants --disable-every-bloody-thing [23:37:45 CEST] <atomnuker> nevcairiel: why are you not using lswr? [23:38:39 CEST] Action: kierank wonders whether to troll atomnuker with that site [23:39:23 CEST] Action: kierank uses avr because it had public patch review [23:46:15 CEST] <nevcairiel> I dont particularly remember why I used lavr when I did, but spending time to change it is time i'm not getting back :) [23:46:50 CEST] <atomnuker> kierank: last time you told me you liked its API better now you tell me another reason [23:47:03 CEST] <kierank> not mutually exclusive [23:47:17 CEST] <atomnuker> I don't believe any of you has a good reason [23:47:22 CEST] <kierank> and during one of the many flamewars about this have gone on record about this [23:47:25 CEST] <kierank> on various MLs [23:49:45 CEST] <atomnuker> sure, I love reading outdated reasons which are irrelevant now on various topics [23:50:00 CEST] <atomnuker> kinda like, I dunno, "ffmpeg never removes things" [23:50:13 CEST] <kierank> ffmpeg pushes stuff without any public review [23:50:16 CEST] <kierank> like swresample [23:50:17 CEST] <kierank> hmmm [23:51:06 CEST] <atomnuker> sure, like people experienced in dsp are particularly common, especially those who know about resapling [23:51:37 CEST] <kierank> people should still have commented on the API [23:51:50 CEST] <atomnuker> its a decent API, I don't mind it [23:51:50 CEST] <kierank> at the time it was a copy paste of swscale... [23:52:07 CEST] <kierank> then it was patched after complaints to use avframe [23:53:34 CEST] <kierank> oh well north korea is firing missles [23:53:39 CEST] <kierank> see you all in the afterlife [23:54:02 CEST] <JEEB> kierank: my phone buzzed a lot during the last 30min :D [23:54:11 CEST] <kierank> ohshit [23:54:23 CEST] <JEEB> but it seems like it a) passed and b) broke down in three parts, is in the pacific ocean now [23:54:57 CEST] <JEEB> j-alert sent a message like "passed this area, if you find anything weird please do not go close to it and inform officials" [23:56:41 CEST] <gh0st__> kierank: "oh well north korea is firing missles", I hope to finish my assembly before that. =) [00:00:00 CEST] --- Tue Aug 29 2017