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

[burek]

[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