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

[burek]

[01:24:52 CET] <SortaCore> heyo
[01:24:53 CET] <SortaCore> what's the difference between h264_d3d11va and h264_d3d11va2?
[01:41:11 CET] <SortaCore> got answer on #ffmpeg (I asked there twice and was eventually redirected here)
[01:46:53 CET] <JEEB> hmm, I'm getting a funky amount of various linker errors when linking something against current FFmpeg with x86_64 mingw-w64
[01:47:01 CET] <JEEB> some of them even seemed to be avpriv o_O
[01:52:31 CET] <SortaCore> I have Windoze 10 64-bit with mingw64 if you guys need a test of master branch
[01:52:58 CET] <JEEB> building FFmpeg itself is a-OK still. when I try to link against the static lib I get wonky stuff
[01:53:44 CET] <SortaCore> yea, that's the scenario I'm doing it in
[01:53:45 CET] <atomnuker> I got the same issue here on linux so I switched to shared
[01:54:13 CET] <SortaCore> 32-bit, MS VS2015 toolchain, static library
[01:54:15 CET] <atomnuker> else there's some lavf/tak.c avpriv errors
[01:54:30 CET] <JEEB> right, so it's not specific to my toolchain or mingw-w64
[01:54:33 CET] <JEEB> that's good to know
[01:54:39 CET] <JEEB> might as well switch to shared then
[01:58:24 CET] <SortaCore> why don't you guys declare AVCodecParameters::format as a union?
[01:58:38 CET] <SortaCore> potential alignment problems?
[01:59:40 CET] <SortaCore> gotta be better than casting
[02:00:15 CET] <J_Darnley> no doubt: API legacy issues
[02:01:32 CET] <SortaCore> AVCodecParameters was relatively new, tho
[02:01:44 CET] <SortaCore> (or was it introduced last year when I last worked on this project)
[02:02:05 CET] <SortaCore> you can still use the format as int, though
[02:02:12 CET] <SortaCore> even as a union
[02:12:02 CET] <jamrial_> atomnuker, JEEB: do you know when it started happening? can you bisect?
[02:13:27 CET] <JEEB> maybe tomorrow^Wtoday after I get some sleep
[02:28:23 CET] <SortaCore> okay, on Windows, I'm getting error -17 "device failed" for h264_qsv, when screen is off, is there anything I can do about that?
[02:28:41 CET] <SortaCore> (cue someone saying "turn screen on")
[02:35:36 CET] <SortaCore> something like the "Allow Windows to turn off this device to save power" thing
[02:43:04 CET] <jamrial_> JEEB, atomnuker: looks like pkg-config creation is currently broken
[02:43:56 CET] <atomnuker> yeah, I thought so
[02:44:05 CET] <jamrial_> dependencies are not being written to them, so using them to get linker flags from say, lavf only, will not get you the lavc flags
[02:44:07 CET] <jamrial_> with shared this is not an issue
[02:47:21 CET] <jkqxz> SortaCore:  Make sure you are opening an Ex device.  (The original D3D9 interfaces had that problem.)
[02:52:00 CET] <SortaCore> it did say 9Ex, but that might have been for decoder
[02:52:40 CET] <SortaCore> I installed latest Intel gfx drivers and now if I plug something into my intel card, it shows black and my other screen has a moving mouse, but no picture
[02:52:51 CET] <SortaCore> so, a reboot may be in order...
[02:54:08 CET] <SortaCore> I'm gonna go for a walk first
[03:05:06 CET] <cone-179> ffmpeg 03James Almer 07master:d9ff1e4c8bdf: configure: fix writing library dependencies to config.sh
[03:05:12 CET] <jamrial> atomnuker, JEEB: fixd
[03:44:44 CET] <cone-179> ffmpeg 03Timo Rothenpieler 07master:3ee63f3fb70c: avformat/hlsenc: allocate space for terminating null
[03:55:20 CET] <cone-179> ffmpeg 03Steven Liu 07master:f3e34072aadf: avformat/img2enc: add frame_pts option for make output filename
[04:06:15 CET] <cone-179> ffmpeg 03Michael Niedermayer 07master:1828c549c3ec: avfilter/vf_*_qsv: Fix flags
[04:06:16 CET] <cone-179> ffmpeg 03Thomas Köppe 07master:43171a2a738f: Fix missing used attribute for inline assembly variables
[12:07:48 CET] <J_Darnley> How does checkasm control AV_CPU_* flags?
[12:07:57 CET] <J_Darnley> How does pass limited flags into functions that don't have an argument for flags?
[12:10:52 CET] <J_Darnley> Ah, it will use the force flags function m,entioned just the other day.
[12:11:33 CET] <J_Darnley> And that keeps state in avutil somewhere.
[12:19:04 CET] <J_Darnley> And if I understand the rest of this correctly I need to set function pointer based on those flags.
[15:57:14 CET] <BBB> j-b: pokey
[16:24:15 CET] <kierank> J_Darnley: any idea why ff_h264_loop_filter_strength_mmxext is mmxext?
[16:24:55 CET] <J_Darnley> Not without looking but I guess it uses things only from mmxext and not just mmx
[16:27:20 CET] <kierank> any idea why it's not sse?
[16:28:52 CET] <J_Darnley> I'll have a look
[16:29:37 CET] <nevcairiel> probably because lol-old
[16:34:38 CET] <J_Darnley> Initailly it looks like it could load 16-bytes but I think I see what would then be horizontal operations starting on line 1307 of avcodec/x86/h264_deblock.asm
[16:35:31 CET] <J_Darnley> Perhaps it could benefit from a naive change to xmm and just use movq
[16:36:37 CET] <J_Darnley> But that wouldn't be much of a speed gain
[16:36:57 CET] <J_Darnley> I think I did that early-on with my previous h264 patches.
[16:51:01 CET] <BBB> kierank: x264 has sse code for that
[16:51:10 CET] <BBB> kierank: I tried converting it once and I failed and then quickly lost interest
[16:51:19 CET] <BBB> probably copying what x264 has is much easier
[16:53:21 CET] <kierank> J_Darnley: also ff_h264_idct_add8_8_mmxext
[16:54:20 CET] <SortaCore> *lurks awaiting news of hwaccel*
[16:58:02 CET] <J_Darnley> that one sounds familiar
[17:00:17 CET] <J_Darnley> oh i've done idct8_add but not idct8_add8
[17:00:19 CET] <kierank> ff_h264_idct_add8_8_mmxext
[17:00:21 CET] <kierank> that too
[17:01:03 CET] <kierank> wait there was a dc one
[17:01:04 CET] <kierank> hmm
[17:01:11 CET] <kierank> very sample dependent
[17:01:29 CET] <J_Darnley> I think there are dc ones of all those idct functions
[17:23:39 CET] <jamrial> does anyone want to give porting the remaining lavu atomic usage to C11 atomics?
[17:24:05 CET] <jamrial> i'd like to get rid of the lavu atomic symbols before the unstable abi period is over
[17:42:04 CET] <BBB> all these blogs about firefox being fast again
[17:42:08 CET] <BBB> did anyone test the beta?
[17:54:46 CET] <J_Darnley> Nah.  I moved to Pale Moon long ago.
[17:55:06 CET] <atomnuker> yeah, its great, it does partial buffer updates so no longer wastes a full core animating a 1x1 area on a 4k screen
[17:55:57 CET] <atomnuker> it still doesn't support wayland though
[18:05:23 CET] <jamrial> BBB: i'm using 57 final which came out today, but have been using the beta for the past week
[18:05:39 CET] <BBB> jamrial: do you agree its fast?
[18:06:33 CET] <jamrial> it does seem faster with loading and tab switching, but then again i never use more than two or three extensions and never more than 10 tabs at a time, so maybe i'm not the one to ask :p
[18:07:23 CET] <BBB> have you seen it get incredibly slow and hang on tabs at times?
[18:08:20 CET] <jamrial> that used to happen with 56 and older to me every now and then, but haven't seen it happen with this one so far
[18:09:39 CET] <jamrial> i see about seven firefox processes. it used to be two or four
[18:09:48 CET] <jamrial> it does not seem to be related to how many tabs i have open
[18:13:05 CET] <BBB> hm.. ok, Ill have to retry the stable then
[18:27:38 CET] <jamrial> BBB: can i somehow persuade you to port all the avpriv_atomic_ptr_cas cases in the tree to C11's atomic_compare_exchange_strong? :P
[18:28:45 CET] <jamrial> i gave it a try some months ago and failed, since c11 atomics are a bit more strict with their atomic/volative variables
[18:28:56 CET] <jamrial> or perhaps the current avpriv_atomic_ptr_cas usage is just wrong
[18:30:03 CET] <BBB> what files?
[18:31:20 CET] <jamrial> libavcodec/utils.c libavcodec/parser.c libavformat/format.c libavfilter/avfilter.c libavutil/opencl.c
[18:31:24 CET] <jamrial> it's one per file or so
[18:32:04 CET] <BBB> I cant do opencl, I have no idea how to test it
[18:32:51 CET] <BBB> lockmgr?
[18:33:02 CET] <BBB> what the 
[18:33:04 CET] <BtbN> OpenCL testing should be pretty easy, since it can just run in software in lack of a GPU
[18:33:34 CET] <jamrial> BtbN: yeah, but he'd need the sdk
[18:33:48 CET] <BtbN> On Linux that's usually packaged
[18:34:08 CET] <BtbN> At least I don't remember having done anything special to get working opencl
[18:34:09 CET] <jamrial> ah, right
[18:34:35 CET] <BtbN> And since we only use opencl 1.1, it works pretty much everywhere
[18:34:51 CET] <BBB> I genuinely believe that the lockmgr one is one of the most obvious cases of duh, please dont do that Ive ever seen
[18:35:00 CET] <BBB> as in, it creates a race trying to fix a race
[18:37:37 CET] <BBB> theyre all michaelnis code in libavcodec/utils.c, so he should fix them
[18:37:40 CET] <BBB> Im not touching that
[18:38:02 CET] <BBB> parser same
[18:38:14 CET] <BBB> format same
[18:38:23 CET] <BBB> Im going to blindly guess avfilter is the same also
[18:38:46 CET] <jamrial> :(
[18:39:00 CET] <BBB> sorry, that code is a rabbit hole, Im not going down there
[18:39:07 CET] <BBB> I have a family that I love and a life that I like
[18:41:07 CET] <atomnuker> I'd do it if no one else bothers to in a few days once I'm free
[18:42:27 CET] <atomnuker> since you know, I hate everything but I'll bother myself to hate something less if I can
[18:43:43 CET] <BBB> this code seems related to making format/filter/codec/parser registration fast
[18:44:11 CET] <jamrial> fast, or race free?
[18:44:15 CET] <BBB> fast
[18:44:20 CET] <BBB> apparently somehow someone somewhere believes codec registration is a bottleneck in ffmpeg
[18:45:08 CET] <BBB> bbl, lunch
[18:46:06 CET] <J_Darnley> Is there a guide for setting up things so you can use CONFIG_LINUX_PERF in checkasm?
[18:48:26 CET] <SortaCore> RTSP streams detect YUVJ420P and similar deprecated formats, is that expected?
[18:53:01 CET] <durandal_1707> which our demuxers do not send packets when it should?
[18:56:02 CET] <atomnuker> jamrial: when are the YUVJ formats getting removed? they've been deprecated for a long time now
[18:56:23 CET] <jamrial> hell if i know. i've wondering the same for a long time
[18:56:56 CET] <durandal_1707> they cant be removed, michaelni set numerous traps so it never happens
[18:57:32 CET] <atomnuker> they don't even have deprecation guards or warnings
[18:57:41 CET] <atomnuker> why has no one bothred to do that?
[18:58:12 CET] <atomnuker> can they be removed without putting those and waiting for 2 years?
[18:58:23 CET] <atomnuker> they've been deprecated for much more than 2 years
[18:59:23 CET] <durandal_1707> even libav did not bothered/managed ...
[19:00:18 CET] <durandal_1707> some stuff in fate explicitly depends on j formats...
[19:00:38 CET] <SortaCore> I'm getting them detected in h264 native decoder if that helps >.>
[19:02:10 CET] <durandal_1707> the most obvious is: how one set color range for encoder?
[19:03:12 CET] <BtbN> I guess just via color_range in the CodecContext
[19:05:04 CET] <jkqxz> LongChair:  Rockchip seems to have made a new release without the MPP_DEC_GET_FREE_PACKET_SLOT_COUNT command.  (Reported here as <https://trac.ffmpeg.org/ticket/6834>.)
[19:05:11 CET] <jkqxz> LongChair:  What do we do with that?
[19:05:54 CET] <jkqxz> (It's in the 20170811 tagged tree but not in the 20171107 tagged tree.)
[19:06:01 CET] <LongChair> Yeah i have also noticed that . I have a PR ready and asked RK why they had removed that in their rebase
[19:07:46 CET] <michaelni> durandal_1707, it was me who deprecated yuvj formats in 98aea87b1a3a96b9d82deca09291aaec2f54399e
[19:08:34 CET] <ubitux> J_Darnley: --enable-linux-perf
[19:09:02 CET] <J_Darnley> Thanks, I will look at that later.
[19:09:41 CET] <LongChair> jkqxz: you can apply that on top of mpp  if  you need https://github.com/LongChair/mpp/commit/a68592b1d4b7424c0e9216457ba1c93846e6f323
[19:09:53 CET] <jkqxz> LongChair:  Ok.  I guess since it fails at configure it's basically fine, though the message isn't ideal.
[19:10:34 CET] <durandal_1707> atomnuker: first they need to be removed from usage, and thats hard imho
[19:11:13 CET] <jkqxz> (As long as they put it back at some point.)
[19:11:22 CET] <LongChair> yeah that's the plan 
[19:11:37 CET] <LongChair> i reported that on friday 
[19:12:38 CET] <atomnuker> durandal_1707: I was asking if hypothetically removal was very easy
[19:13:40 CET] <durandal_1707> atomnuker: dunno, maybe if one grasp why fate fails, i did patch for mjpeg more than year ago
[19:19:03 CET] <jkqxz> Wrt OpenCL stuff above, can't we just delete all the global state stuff?  (Which is why the locking is there.)
[19:20:12 CET] <jkqxz> (If I send the OpenCL hwcontext patches again is someone prepared to review them this time?)
[19:24:01 CET] <jamrial> i'd like to remove the current opencl stuff altogether. it's barely used by two filters...
[19:24:37 CET] <jamrial> i assume it has no replacement, and the maintainer is afaik active, so
[19:24:51 CET] <atomnuker> yep, same here
[19:25:44 CET] <atomnuker> reminder: its api was never declared stable so it can be removed
[19:25:46 CET] <jkqxz> Yeah, that's what I mean.  Delete the API stuff in libavutil and the filters using it, replace with hwcontext implementation which (a) has no global state, and (b) is actually useful.
[19:26:12 CET] <atomnuker> submit the patchset again with a patch to remove the old opencl stuff and I'll review and test it
[19:26:22 CET] <jkqxz> I wrote an unsharp filter on hwcontext to replace the existing one.  The deshake one is pretty nasty, though.
[19:26:45 CET] <jamrial> jkqxz: you could ask the current opencl stuff's maintainer for help/tips
[19:28:07 CET] <jamrial> the entire api is tagged as "experimental and its API and ABI may change without prior notice.", so i think we can safely remove everything
[19:28:17 CET] <jamrial> worst case, we leave the symbols in place returning ENOSYS for a while
[19:28:47 CET] <jkqxz> Last time I looked, Google didn't find any external code which touches them.
[19:29:04 CET] <jamrial> then the axe they shall get :P
[19:29:24 CET] <BtbN> it's pretty useless in its current variant anyway
[19:29:32 CET] <BtbN> Since it's upload/download inside every single filter
[19:29:45 CET] <BtbN> and almost no filters picked it up
[19:32:00 CET] <durandal_1707> just rm
[19:38:13 CET] <JEEB> woah @ that rpi3 HEVC decoder thing
[19:58:53 CET] <cone-952> ffmpeg 03Michael Niedermayer 07master:c897a9285846: avcodec/snowdec: Fix integer overflow in header parsing
[19:58:54 CET] <cone-952> ffmpeg 03Michael Niedermayer 07master:770c934fa163: avcodec/mdct_*: Fix integer overflow in addition in RESCALE()
[19:58:55 CET] <cone-952> ffmpeg 03Michael Niedermayer 07master:fca198fb5bf4: avcodec/aacdec_fixed: Fix undefined shift
[19:58:56 CET] <cone-952> ffmpeg 03Michael Niedermayer 07master:2afe05402f05: avcodec/aacpsdsp_template: Fix integer overflows in ps_decorrelate_c()
[19:58:57 CET] <cone-952> ffmpeg 03Aman Gupta 07master:480d33dfdc59: MAINTAINERS: add myself as videotoolbox* maintainer
[20:19:26 CET] <durandal_1707> atomnuker: just checked for yuvj removal one needs to add api so encoder will know what color ranges ar supported and thus swscale can do its job to do conversion
[20:20:10 CET] <atomnuker> avctx->color_range?
[20:20:28 CET] <cone-952> ffmpeg 03Aman Gupta 07master:52bf0febb3a8: avformat/http: fix stray quote in trace	logging
[20:20:40 CET] <jamrial> and for libavfilter, frame->color_rage should work the same
[20:22:51 CET] <SortaCore> so all that's needed for YUVJXXX -> YUVXXX is replacing the format and setting color_range to AVCOL_RANGE_JPEG?
[20:23:05 CET] <jamrial> maybe add color_range to AVFilterLink
[20:29:11 CET] <nevcairiel> no, since not all components understand or even have a color_range
[20:35:08 CET] <durandal_1707> and rawvideo which is used by fate ,  cant signal range
[20:46:50 CET] <tmm1> what is the policy on pulling patches from ffmpeg fork sources published by companies using ffmpeg
[20:47:31 CET] <durandal_1707> if they are useful get them
[20:48:13 CET] <JEEB> many of them will require at least some sort of rework though
[20:48:23 CET] <JEEB> since stuff doesn't have to be pretty to "work"
[20:48:50 CET] <J_Darnley> And people like using old code bases
[20:49:10 CET] <tmm1> sure, say i get a clean patch, and its a few line bugfix
[20:49:25 CET] <SortaCore> my h264_qsv is randomly dying with -17 device failed, even with screen on the whole time
[20:49:26 CET] <cone-952> ffmpeg 03Timo Rothenpieler 07master:f3f73f0893e2: avcodec: implement vp9 nvdec hwaccel
[20:49:27 CET] <tmm1> the thing is i have no idea who the copyright holder is, cuz all they published was a tarball with no git history
[20:49:27 CET] <cone-952> ffmpeg 03Timo Rothenpieler 07master:538de4354dcd: avcodec/nvdec: warn about thread count if applicable
[20:49:28 CET] <cone-952> ffmpeg 03Timo Rothenpieler 07master:8bcf5840ea2a: avcodec/nvdec: fix return value on error
[20:49:29 CET] <cone-952> ffmpeg 03Timo Rothenpieler 07master:237ccd8a165d: lavfi/paletteuse: check get_color return value
[20:49:30 CET] <cone-952> ffmpeg 03Timo Rothenpieler 07master:284b432662b6: avformat/fitsenc: validate input pixel format
[20:49:31 CET] <cone-952> ffmpeg 03Timo Rothenpieler 07master:c7ded42d5dfc: avfilter/vf_premultiply: fix memory-leak on failure
[20:49:32 CET] <cone-952> ffmpeg 03Timo Rothenpieler 07master:de6a1e32fd48: movenc-test: fix potential uninitialized read
[20:49:40 CET] <SortaCore> https://pastebin.com/raw/DdQXhNL3
[20:49:55 CET] <tmm1> is it kosher just to pull the patch and say where it came from, without knowing who specifically wrote it
[20:50:12 CET] <J_Darnley> I would say keep original author information, if possible
[20:50:15 CET] <atomnuker> yeah, just mention the repo/company
[20:50:17 CET] <JEEB> ^
[20:50:28 CET] <tmm1> ok makes sense
[20:50:47 CET] Action: J_Darnley missed that tarball line
[20:52:43 CET] <SortaCore> any ideas?
[20:53:13 CET] <SortaCore> this is rtsp with rtsp_transport = tcp
[20:53:34 CET] Action: J_Darnley has none
[20:54:06 CET] <JEEB> SortaCore: as far as I've heard QSV can be quite derpy - never built it
[20:55:37 CET] <BtbN> QSV randomly dieing or crashing sounds about normal
[20:55:54 CET] <BtbN> I know OBS put it into an external process, and just restarts it instantly when it messes up
[20:56:06 CET] <JEEB> sounds like the right way to do it
[20:56:22 CET] <durandal_1707>  mess
[20:56:28 CET] <BtbN> It tends to randomly fail, crash, or even worse, hard-freeze
[20:57:27 CET] <SortaCore> o joy
[20:58:50 CET] <tmm1> yea i've seen "device failed" -17 happen randomly all the time
[20:59:27 CET] <BtbN> OBS somehow manages to not lose a single frame when the external process dies
[20:59:50 CET] <tmm1> see https://trac.ffmpeg.org/ticket/5708
[20:59:51 CET] <SortaCore> so let's get it working in ffmpeg amirite
[21:00:03 CET] <BtbN> There is nothing one can do about it.
[21:00:14 CET] <BtbN> It's not being misused. It's just messing up on its own
[21:00:22 CET] <BtbN> Only Intel can fix it
[21:01:11 CET] <JEEB> I'm just thankful intel kind of fixed its jack with DXVA2
[21:01:57 CET] <SortaCore> on the bottom it says to Close() and Init(), what's the equivalent in ffmpeg, closing and re-opening the context?
[21:02:08 CET] <atomnuker> Gramner: how did you manage to get any gains out of avx512 in x264 with so much non-avx512 code and the downclocking?
[21:02:24 CET] <BtbN> Just turn off the downclocking I guess
[21:02:28 CET] <BtbN> And put a monster cooler on the CPU
[21:02:35 CET] <JEEB> SortaCore: sounds similar enough to try and reinit all the things
[21:02:43 CET] <tmm1> SortaCore: yea but then you lose any pending frames so it isn't really practical
[21:03:18 CET] <JEEB> unless you keep tabs on fed vs received
[21:03:18 CET] <atomnuker> BtbN: afaik you can't turn it off, the cpu will melt
[21:03:29 CET] <Compn> SortaCore : we're open to patches :)
[21:03:32 CET] <BtbN> You totally can turn of the AVX downclocking
[21:03:42 CET] <BtbN> If it's a good idea is entirely up to your cooling setup
[21:03:58 CET] <Gramner> results are cpu-dependent since avx offset is cpu-dependant
[21:04:20 CET] <SortaCore> @Compn I'm flattered but I'm not *that* familiar with QSV/ffmpeg
[21:04:20 CET] <Compn> SortaCore : maybe if intel bought us all qsv-enabled boxes to do testing on... and gave us specs and api (even the secret ones) then MAYBE we could fix it
[21:04:35 CET] <Gramner> I only have a single cpu and it's an ES. haven't touched any bios settings though so all default
[21:04:50 CET] <SortaCore> well, I have a device here I can test it on, whether I like that or not >.>
[21:05:05 CET] <Gramner> but up to 30% of overall runtime is spent in avx-512 in x264 depending on settings
[21:05:47 CET] <Compn> SortaCore : you are doing h264 , right ? do the other codecs crash equally ?
[21:05:59 CET] Action: Compn should read pastebin first
[21:06:01 CET] <SortaCore> well, I'm not sure about all the fiddling I need for each one
[21:06:20 CET] <SortaCore> atm I can use native, directx9, direct3d 11, nvidia
[21:06:26 CET] <Compn> oh 
[21:06:30 CET] <Compn> try using nvidia then ?
[21:06:31 CET] <SortaCore> qsv was first hwa I was going for as client wanted it
[21:06:35 CET] <Compn> ah
[21:07:07 CET] <SortaCore> having looked at the VLC code, it calls MFXVideoENCODE_Reset(sys->session, &sys->params); and that's the only time that function is used ever in vlc
[21:07:32 CET] <Compn> SortaCore : if it works in vlc use vlc ? 
[21:07:42 CET] <Compn> SortaCore : what ver ffmpeg btw ?
[21:07:47 CET] <SortaCore> I can't use VLC in a C++ project
[21:07:57 CET] <SortaCore> and I think I resynced it from master a week ago
[21:08:25 CET] <SortaCore> only change I did was making it so QSV only looks for any hardware implementation, instead of allowing software
[21:09:49 CET] <Compn> SortaCore : why is it looking for bgr24 ? swscaler : No accelerated colorspace conversion found from yuv420p to bgr24.
[21:09:56 CET] <Compn> SortaCore : that is where i'd say it is breaking
[21:10:29 CET] <Compn> also this is not ffmpeg development itself so probably we should move to #ffmpeg ...
[21:10:30 CET] <SortaCore> sometimes the user wants to watch the feed, that converts it to bitmap for an third-party GUI
[21:10:46 CET] <Compn> why not use ffmpegs' dshow output ?
[21:10:56 CET] <SortaCore> the window handle isn't created by my code
[21:11:29 CET] <Compn> return money and tell your client he is crazy
[21:12:03 CET] <SortaCore> he is but it pays hourly so it's ok by me
[21:12:30 CET] <Compn> what i mean is , ffmpeg can do multiple outputs at once
[21:12:43 CET] <Compn> depending on what you are doing
[21:12:57 CET] <SortaCore> I did tell him he could just run the application with the right commandlines
[21:13:02 CET] <Compn> are you doing multiple threads ?
[21:13:04 CET] <SortaCore> or even that I could write code to generate the commandlines
[21:13:18 CET] <SortaCore> possibly, once I get all these hwas working in single-threaded
[21:13:26 CET] <Compn> ok just making sure single threaded
[21:13:32 CET] <Compn> for testing
[21:17:17 CET] <SortaCore> trying to figure out where -17 is originally thrown so I can slap some Reset on it
[21:17:21 CET] <BtbN> nevcairiel, why is d3d11va so slow?
[21:17:41 CET] <SortaCore> isn't there a d3d11va2?
[21:17:51 CET] <BtbN> only in ffmpeg
[21:18:37 CET] <michaelni> is make distclean still supported ? here it does not delete any .o files
[21:18:59 CET] <BtbN> I get 290 FPS with d3d11va, vs. 350FPS with nvdec, vs. 550FPS with cuvid, vs. 650FPS sw dec. Strange stuff
[21:19:12 CET] <Compn> michaelni : did your makefile get corrupted ?
[21:19:38 CET] <michaelni> i very much doubt that
[21:20:32 CET] <nevcairiel> BtbN: seems just fine for me in my own implementation, ffmpeg.c is a bad benchmark for hwaccels imho
[21:21:02 CET] <jamrial> michaelni: let me check
[21:21:45 CET] <BtbN> nevcairiel, I feel like it's primarily about the download delay
[21:22:11 CET] <BtbN> yeah, it definitely is
[21:22:31 CET] <BtbN> adding -hwaccel_output_format d3d11 makes it happily do 700FPS
[21:23:29 CET] <BtbN> But the nvenc d3d11 patches work perfectly for me, and I don't see anything to complain about. So feel free to push, unless you still want to change stuff about it
[21:24:41 CET] <jamrial> geez
[21:24:48 CET] <jamrial> michaelni: does this fix it? https://pastebin.com/3EkDszyv
[21:25:19 CET] <BtbN> jamrial, there are also still some issues with stuff not pulling in -ldl when it should
[21:25:46 CET] <jamrial> BtbN: external lib checks?
[21:26:03 CET] <BtbN> Let me reproduce it, one second. It's a massive gentoo commandline still
[21:27:52 CET] <michaelni> jamrial, that removed my testfile, i had already removed the others so as far as i can tell it seems to work
[21:28:38 CET] <jamrial> distclean used to imply clean in library.mak, but that was removed in a recent commit
[21:29:04 CET] <jamrial> i figured Makefile makes more sense, but i can re add it to library.mak
[21:29:06 CET] <jamrial> what do you prefer?
[21:29:25 CET] <michaelni> who reviewed/approved the buggy commit?
[21:29:39 CET] <jamrial> it was a merge
[21:29:52 CET] <jamrial> that's why i'm looking at it
[21:36:44 CET] <BtbN> jamrial, for some reason it's still not building libavutil with -ldl even though hwcontext_cuda is enabled
[21:37:12 CET] <nevcairiel> BtbN: yeah i'll push it soon
[21:37:30 CET] <BtbN> So as this is building a shared version of the libs, it fails
[21:39:58 CET] <jamrial> BtbN: odd, cuda has a dep on libdl, and avutil pulls cuda deps
[21:40:22 CET] <BtbN> I think we already had this before, and it's some weird bug in configure?
[21:42:06 CET] <cone-952> ffmpeg 03James Almer 07master:e7e7d56a850d: Makefile: fix distclean target
[21:42:33 CET] <BtbN> "EXTRALIBS-avutil=-pthread -lm" in config.mak
[21:44:45 CET] <tmm1> is there an easy way to add a Reviewed-by or other signoff via git-rebase
[21:47:18 CET] <J_Darnley> There's an option for "signed off" in one of the git commands but I don't think it is rebase.
[21:47:18 CET] <BtbN> interactive rebase, edit, ammend --signoff --no-edit, continue
[21:47:52 CET] <BtbN> If it's the HEAD commit, just ammend away
[21:48:08 CET] <tmm1> pita for a large patchset
[21:48:10 CET] <tmm1> ok thanks
[21:49:31 CET] <BtbN> interactive rebase has a way to run a script on edit, and continue automatically
[21:49:36 CET] <jamrial> BtbN: btw, nvdec is missing a dep on cuda
[21:49:50 CET] <jamrial> a nvdec_deps="cuda" line
[21:49:56 CET] <BtbN> hm, right, only the individual codecs depend on it
[21:50:17 CET] <jamrial> also, lol at all the hwaccels dependign on "cuvid cuda"
[21:50:21 CET] <jamrial> cuvid implies cuda
[21:50:51 CET] <jamrial> removing cuda from all those checks and leaving cuvid alone will make configure slightly faster :p
[21:51:03 CET] <BtbN> There is a historical reason for that I think, but yeah, it can go now
[21:51:22 CET] <jamrial> ah
[21:51:43 CET] <BtbN> cuda used to mean "the actual SDK"
[21:51:50 CET] <BtbN> cuvid wasn't always dyn loaded
[21:52:23 CET] <jamrial> btw, maybe instead of having both cuvid and nvdec as modules in configure, we could keep nvdec only and make --enable-cuvid a deprecated alias for --enable-nvdec?
[21:54:01 CET] <BtbN> Yeah, that should be possible. If someone doesn't want all the cuvid decoders they can be disabled
[21:54:17 CET] <BtbN> hm, but how would one disable the decoder independend parts of it then?
[21:55:08 CET] <jamrial> --disable-decoder=list,of,cuvid,modules i guess
[21:55:49 CET] <BtbN> Yeah
[21:55:51 CET] <BtbN> which is _a lot_
[21:56:38 CET] <jamrial> so guess not then :p
[21:57:36 CET] <BtbN> I just realized something else... why are all the cuvid decoder deps in configure twice?
[21:57:44 CET] <BtbN> That seems like some merge duplicated all of them?
[21:59:16 CET] <BtbN> Oh. It's because of the fake hwaccel
[21:59:18 CET] <BtbN> nevermind
[21:59:40 CET] <jamrial> dep and select lines are not the same in any case
[21:59:48 CET] <BtbN> no, it's both _deps
[21:59:55 CET] <BtbN> but once for the hwaccel, once for the decoder
[22:00:37 CET] <jamrial> mmh, then i guess i can remove the dep line from the hwaccels, since they select the decoders
[22:02:19 CET] <BtbN> https://github.com/BtbN/FFmpeg/commit/4deb8bd90b86d616ce47152fc7b4b6ec32ab82ad
[22:02:28 CET] <BtbN> https://github.com/BtbN/FFmpeg/commit/cc37dd6b89432f6846e6d5d1f0046383f9ac6060 and for nvdec
[22:03:19 CET] <jamrial> name the second commit "factorize nvdec dependencies"
[22:03:30 CET] <jamrial> and should be good
[22:04:28 CET] <BtbN> gonna do a test configure run for safety
[22:05:06 CET] <BtbN> can you reproduce the missing -ldl on avutil btw.?
[22:05:28 CET] <cone-952> ffmpeg 03Rodger Combs 07master:a36a3d7fecdf: lavf/tls_securetransport: handle incomplete reads gracefully
[22:05:29 CET] <cone-952> ffmpeg 03Aman Gupta 07master:9c8922acadb5: This fixes a deadlock while reading a chunked https response, if multiple_requests=1 is also set. Without an EOF to signal the end of the last chunk, tls_read gets stuck forever trying to read more data than is available. This occurs with the http protocol reproducibly, because http.c always reads 4kb at a time, and the last chunk of an http response is often much smaller.
[22:05:38 CET] <BtbN> That commit message
[22:05:45 CET] <rcombs> &whoops, I should've fixed that
[22:05:47 CET] <rcombs> oh well
[22:06:44 CET] <rcombs> how the hell are you supposed to git-am from pipermail anyway
[22:07:06 CET] <rcombs> would anyone mind if I force-pushed over that
[22:07:19 CET] <BtbN> I don't think video lan lets you
[22:07:23 CET] <BtbN> but go ahead and try I'd say
[22:07:24 CET] <rcombs> one way to find out
[22:07:45 CET] <rcombs> nope it doesn't
[22:07:49 CET] <rcombs> welp, sorry, that's my bad
[22:09:17 CET] <BtbN> Was that supposed to be one commit, ammended to the other?
[22:11:13 CET] <cone-952> ffmpeg 03Timo Rothenpieler 07master:681c638fab4e: configure: fix cuda dependency on nvdec
[22:11:14 CET] <cone-952> ffmpeg 03Timo Rothenpieler 07master:578addcff64f: configure: factorize nvdec dependencies
[22:11:35 CET] <BtbN> Maybe it's 2 seconds faster now again
[22:11:58 CET] <jamrial> it still doesn't seem to pull -ldl for libavutil as you found out, though
[22:12:15 CET] <jamrial> maybe it's the same thing that affects videotoolbox that nevcairiel debugged some weeks ago
[22:14:00 CET] <jamrial> yeah, seems to be that
[22:14:20 CET] <jamrial> BtbN: https://pastebin.com/ZfKcaubZ makes -ldl show up in EXTRALIBS_avfilter for me, but not avutil
[22:15:15 CET] <BtbN> jamrial, cuvid/nvdec don't touch lavu at all, so that makes sense
[22:15:21 CET] <BtbN> only the generic cuda hwcontext stuff is in there
[22:15:34 CET] <BtbN> but both cuvid and nvdec also don't touch avfilter, so hmmm
[22:15:48 CET] <jamrial> cuda is enabled, and avutil should pull its deps, which include libdl
[22:15:51 CET] <rcombs> BtbN: no, it was supposed to be separate commits, but I pasted the second one into git-am and didn't amend the subject line into the message
[22:16:16 CET] <BtbN> rcombs, couldn't you just have grabbed it from patchwork?
[22:16:26 CET] <rcombs> hmm, lemme see
[22:16:29 CET] <BtbN> https://patchwork.ffmpeg.org/patch/6032/
[22:16:36 CET] <BtbN> curl https://patchwork.ffmpeg.org/patch/6032/mbox/ | git am
[22:17:37 CET] <rcombs> ah yup
[22:17:39 CET] <tmm1> oh that's cool
[22:17:40 CET] <rcombs> that would've worked
[22:18:03 CET] <rcombs> wish pipermail could link to that format
[22:18:31 CET] <BtbN> I still think we should steal freedesktops patchwork
[22:18:38 CET] <BtbN> It's way better than the plain original one
[22:19:48 CET] <BtbN> jamrial, yeah, it should. But for some reason doesn't.
[22:21:13 CET] <jamrial> BtbN: the reason is the bug (or intended behavior, as diego said it was) that collates all deps for one lib, then if another lib was to reuse them, it can't
[22:21:18 CET] <jamrial> or something like that
[22:21:20 CET] <jamrial> it's complex
[22:21:30 CET] <BtbN> irconically, --disable-everything --enable-cuda works just fine
[22:21:38 CET] <BtbN> proper deps on lavu
[22:21:55 CET] <jamrial> because all the lavc and lavfi modules are disabled :p
[22:23:23 CET] <jamrial> a solution could be adding entries for hwcontext stuff to configure, with their own dependencies
[22:23:51 CET] <BtbN> No way to actually fix the bug?
[22:24:14 CET] <BtbN> I assume it's the magic that happens in check_deps?
[22:24:27 CET] <jamrial> flatten_libs i think
[22:25:52 CET] <jamrial> diego doesn't consider it a bug but intended behavior
[22:26:05 CET] <jamrial> to stop recursion at some point
[22:26:23 CET] <nevcairiel> its mostly because shell is a terrible programming language
[22:26:32 CET] <BtbN> I don't see what's intended about not having required deps on libraries
[22:26:46 CET] <BtbN> What the hell does resolve() do
[22:27:46 CET] <jamrial> you'll awaken an ancient evil if you dig too much
[22:30:18 CET] <BtbN> lets see what monster it produces if I just comment the whole thing out
[22:30:25 CET] <JEEB> :D
[22:32:02 CET] <BtbN> https://bpaste.net/show/9d463ea978fc it certainly has a purpose
[22:32:34 CET] Action: JEEB double-blinks
[22:32:36 CET] <nevcairiel> yeah it definitely does things
[22:32:39 CET] <JEEB> I think I just broke the build with armv7
[22:32:50 CET] <BtbN> But even with that functions nullified: no -ldl in avutil
[22:32:54 CET] <BtbN> so it's not the one to blame
[22:33:13 CET] <nevcairiel> it doesnt strip things
[22:33:23 CET] <JEEB> http://up-cat.net/p/bfb48b5b
[22:33:25 CET] <nevcairiel> but it may be responsible for not adding it like it should
[22:33:39 CET] <BtbN> flatten doesn't seem to add anything, does it?
[22:34:22 CET] <nevcairiel> it would if a dep contains other dep entries
[22:35:03 CET] <JEEB> or is this just me needing a newer gas-preproc?
[22:35:19 CET] <SortaCore> mm I added some code to reset when it has device failed/lost, and now it's not having device failed *facepalm*
[22:35:26 CET] <nevcairiel> updating sure wouldnt hurt JEEB
[22:35:41 CET] <JEEB> alright
[22:38:56 CET] <SortaCore> why is this h264 decoding having so many errors when it's a tcp rtsp stream?
[22:40:40 CET] <SortaCore> cabac decode error, block missing for intra mode
[22:40:54 CET] <JEEB> nevcairiel: well, that didn't help
[22:41:01 CET] <JEEB> but it was a good idea indeed in general
[22:41:16 CET] Action: JEEB goes check FATE for armv7 clang based stuff
[22:44:47 CET] <JEEB> funky, we don't have any \o/
[22:45:48 CET] <SortaCore> do you guys want this evil patch for qsv
[22:46:13 CET] <JEEB> does it actually help and how hacky does it seem?
[22:46:37 CET] <JEEB> if yes, not really is the answer then make it shiny and post onto ffmpeg-devel
[22:47:29 CET] <SortaCore> how make patch?
[22:47:37 CET] <JEEB> you have the FFmpeg git tree, right?
[22:47:37 CET] <SortaCore> or I could just post the new code
[22:47:42 CET] <SortaCore> yea
[22:47:51 CET] <JEEB> set up your author information
[22:48:18 CET] <JEEB> git config --global user.name "My Name"
[22:48:21 CET] <SortaCore> yea
[22:48:25 CET] <JEEB> git config --global user.email "muh at email"
[22:48:28 CET] <SortaCore> I did those two, when I applied a patch earlier
[22:48:32 CET] <JEEB> ok
[22:49:00 CET] <JEEB> git status => git add those files that you poked => git commit ; the last part opens an editor for the commit message
[22:49:11 CET] <JEEB> the commit message usually starts with a prefix
[22:49:49 CET] <JEEB> qsvdec: or qsvenc: for QSV dec/enc generally it seems
[22:49:56 CET] <JEEB> then after that say what was done
[22:50:19 CET] <JEEB> "qsvenc: make the compression ratios go crazy", for example
[22:50:59 CET] <JEEB> wbs: does this ring a bell? http://up-cat.net/p/bfb48b5b
[22:56:29 CET] <SortaCore> okay, committed
[22:56:57 CET] <JEEB> is it one patch?
[22:57:06 CET] <JEEB> also is this on top of master?
[22:57:08 CET] <SortaCore> one file change yes
[22:57:18 CET] <SortaCore> and may be old master
[22:57:26 CET] <SortaCore> I don't know how to use patch
[22:57:38 CET] <JEEB> you have all your changes in FFmpeg committed, right?
[22:57:39 CET] <JEEB> git status
[22:57:43 CET] <JEEB>  is all OK?
[22:58:00 CET] <SortaCore> I made other changes but I kept them out the commit
[22:58:30 CET] <JEEB> ok, those might have to be stashed then before you swipe into the newest version as rebase tells you welp otherwise
[22:59:00 CET] <JEEB> you can do `git stash` and it should stash your other changes (`git stash pop` to get them back)
[22:59:42 CET] <SortaCore> ok, stash worked
[22:59:55 CET] <JEEB> `git remote` shows you what your remote is called, usually it's "origin" by default. `git fetch REMOTE` gets all the updates from that remote. then `git rebase REMOTE/master` puts your lonely commit on top of current remote's master
[23:00:20 CET] <JEEB> you can `git rebase --abort` if it can't auto-apply it
[23:00:27 CET] <JEEB> and it goes back to your previous point
[23:02:13 CET] <JEEB> fter that you can either utilize format-patch to generate a patch (or series of them), or you can use github/gitlab/etc to push your branch somewhere for review
[23:03:44 CET] <JEEB> `mkdir -p my_patches` and then `git format-patch -o my_patches REMOTE/master` for example would generate patches for all commits since REMOTE's master
[23:05:05 CET] <JEEB> or if you make a git repo somewhere you can `git remote add NAME URL` and push your current HEAD there with `git push REMOTE HEAD:REMOTE_BRANCH_NAME`
[23:05:37 CET] <JEEB> and yes, this is pretty much git 101
[23:05:38 CET] <JEEB> :)
[23:06:17 CET] <JEEB> (so many delicious ways of shooting yourself in the foot and then finding `git reflog` or the commands that completely reset your repository to a pristine state of HEAD)
[23:09:24 CET] <J_Darnley> reflog is wonderful but is verbose and can be a little daunting at first
[23:09:38 CET] <J_Darnley> could do with some date and times in there though
[23:09:44 CET] <JEEB> sure
[23:17:07 CET] <JEEB> http://up-cat.net/p/b2dd6037
[23:17:14 CET] <JEEB> time to see when this was last changed
[23:26:33 CET] <JEEB> the SIMD seems to build with GCC
[23:26:37 CET] <JEEB> but gas-preproc + clang fail
[23:29:19 CET] <nevcairiel> libav has armv7 android clang builds, and I believe they also have that part of the simd?
[23:29:56 CET] <JEEB> yea, it comes through wbs
[23:29:58 CET] <JEEB> so most likely
[23:30:30 CET] <BtbN> jamrial, ok, I know how to fix it
[23:30:30 CET] <nevcairiel> the configure is kinda lengthy https://fate.libav.org/armv7-linux-androideabi-clang-3.3-static/20171113062837
[23:30:33 CET] <BtbN> not to make it nice
[23:30:36 CET] <BtbN> *now
[23:30:43 CET] <BtbN> and I mean, actually fix it
[23:30:53 CET] <nevcairiel> thats what I once thought, but that code is insane
[23:30:54 CET] <cone-952> ffmpeg 03Aman Gupta 07master:e7a5249ab177: avcodec/videotoolboxenc: add hevc_videotoolbox encoder
[23:30:55 CET] <cone-952> ffmpeg 03Aman Gupta 07master:230b91cdfdd1: avcodec/videotoolboxenc: re-indent code
[23:31:26 CET] <jamrial> BtbN: oh cool
[23:31:34 CET] <JEEB> nevcairiel: not sure you need all that with a stand-alone toolchain
[23:31:36 CET] <JEEB> mine is http://up-cat.net/p/11fa76c6
[23:31:43 CET] <JEEB> still long of course
[23:31:47 CET] <BtbN> put the invocation to flatten_extralibs in a subshell, so its modifications to state do not carry over to the next invocation
[23:32:01 CET] <BtbN> So it flattens the dep tree of each library individually
[23:32:07 CET] <jamrial> wonder if it will make windows even slower :p
[23:32:27 CET] <BtbN> The non-subshell variant is to pushvar everything, and popvar at the end
[23:32:30 CET] <BtbN> That also works great
[23:32:35 CET] <BtbN> but on linux makes configure take 20 minutes
[23:32:40 CET] <nevcairiel> lol
[23:32:47 CET] <JEEB> :D
[23:32:51 CET] <jamrial> 20 min on linux would be about a day on windows, got it
[23:33:04 CET] <BtbN> On windows it's only like 5 more forks
[23:33:07 CET] <BtbN> that's not bad
[23:33:09 CET] <SortaCore> https://pastebin.com/raw/Q3rtqyVb
[23:33:58 CET] <SortaCore> also, why can h264_qsv be initialised with software implementations?
[23:34:04 CET] <SortaCore> I doubt that's ever wanted
[23:34:24 CET] <SortaCore> just change an enum value on one line and it's any hardware impl
[23:34:26 CET] <BtbN> jamrial, like, this: https://gist.github.com/0c63c1ba4691537bf04203922f8a19bd
[23:34:39 CET] <JEEB> SortaCore: 'grats on getting a format-patch out :)
[23:34:45 CET] <JEEB> also let me find you the docs on patch-checking
[23:35:10 CET] <JEEB> because there was IIRC a script to check your code for various common issues of which I can find one there
[23:35:11 CET] <jamrial> BtbN: is that the 20 min on linux version?
[23:35:17 CET] <JEEB> which is tabs instead of 4 spaces :)
[23:35:25 CET] <SortaCore> err
[23:35:28 CET] <SortaCore> there's an if missing
[23:35:30 CET] <BtbN> yes
[23:35:42 CET] <BtbN> Haven't come up with a nice subshell variant yet
[23:35:57 CET] <JEEB> somewhere here https://www.ffmpeg.org/developer.html#Contributing
[23:36:17 CET] <SortaCore> I just did a replace in Notepad++  <.<
[23:37:11 CET] <cone-952> ffmpeg 03Aman Gupta 07master:631296ff9922: avcodec/videotoolbox: use early return in videotoolbox_default_free
[23:37:12 CET] <cone-952> ffmpeg 03Aman Gupta 07master:b4b177049a88: avcodec/videotoolbox: extract videotoolbox_{start,stop} helpers
[23:37:13 CET] <cone-952> ffmpeg 03Aman Gupta 07master:d869928ca6e6: avcodec/videotoolbox: reset bitstream_size in end_frame
[23:37:14 CET] <cone-952> ffmpeg 03Aman Gupta 07master:6515e2834a51: avcodec/videotoolbox: print descriptive errors on decode failures
[23:37:15 CET] <cone-952> ffmpeg 03Aman Gupta 07master:dad42bc5a134: avcodec/h264, videotoolbox: return AVERROR_INVALIDDATA when no frames are produced
[23:37:16 CET] <cone-952> ffmpeg 03Aman Gupta 07master:76f169368da4: avcodec: add decode_params callback to AVHWAccel struct
[23:37:17 CET] <cone-952> ffmpeg 03Aman Gupta 07master:872add08540f: avcodec/h264: implement new decode_params callback for PPS/SPS
[23:37:18 CET] <cone-952> ffmpeg 03Aman Gupta 07master:9519983c0f39: avcodec/videotoolbox: use decode_params to propagate H264 PPS changes and restart on SPS changes
[23:37:19 CET] <cone-952> ffmpeg 03Aman Gupta 07master:403d10a8b3cd: avcodec/videotoolbox: create avcC even when h264 extradata is missing
[23:37:20 CET] <cone-952> ffmpeg 03Aman Gupta 07master:bd2d70c0b8f4: avcodec/videotoolbox: remove unnecessary if statement
[23:37:21 CET] <cone-952> ffmpeg 03Aman Gupta 07master:3a91b3ae7424: avcodec/hevc: implement new decode_params callback for VideoToolbox
[23:37:22 CET] <cone-952> ffmpeg 03Aman Gupta 07master:68ef503bb5f9: avcodec/videotoolbox: pass through hevc param changes to the decoder
[23:37:23 CET] <cone-952> ffmpeg 03Aman Gupta 07master:c8b1a151cef6: avcodec/videotoolboxenc: remove spurious warning
[23:37:24 CET] <cone-952> ffmpeg 03Aman Gupta 07master:5e577c586b78: avcodec/videotoolbox: fix whitespace
[23:37:29 CET] <SortaCore> stand by I'll make a patch that doesn't suck
[23:37:44 CET] <SortaCore> *slams git reset button*
[23:41:17 CET] <tmm1> SortaCore: does resetting it like that actually work?
[23:41:42 CET] <tmm1> afaik it will just create corrupted output
[23:44:31 CET] <BtbN> jamrial, https://github.com/BtbN/FFmpeg/commit/d122b678bbf3f7396f21f90e0eb840eaa2793a13
[23:45:19 CET] <SortaCore> git reset --hard
[23:45:29 CET] <SortaCore> and then I just repeat the changes >.>
[23:45:32 CET] <SortaCore> https://pastebin.com/raw/TGhEZEyK
[23:45:47 CET] <JEEB> lol, you can just do changes to the latest commit and `git commit --amend`
[23:46:01 CET] <JEEB> or just commit anew and then `git rebase -i REMOTE/master`
[23:46:13 CET] <JEEB> after which it opens an editor and you can squash things together
[23:46:16 CET] <BtbN> There's never a reason to do work twice with git
[23:46:26 CET] <SortaCore> I'm not familiar enough with git
[23:46:38 CET] <SortaCore> I just do the equivalent of a reboot when there's any confusion about what it will do
[23:46:49 CET] <JEEB> or at least do a non-hard reset :)
[23:46:58 CET] <JEEB> that way the state of the files stays
[23:47:07 CET] <SortaCore> and about Intel reset, VLC uses Reset like that, and it's better than a complete failure
[23:48:11 CET] <SortaCore> the Intel reset may retain the old frames, VLC doesn't seem to note anything about that
[23:48:33 CET] <SortaCore> it passes the same mfxSession and mfxVideoParams so fingers crossed?
[23:49:48 CET] <BtbN> jamrial, this in fact adds _a lot_ of libraries to those extralibs
[23:49:51 CET] <BtbN> not just -ldl
[23:50:00 CET] <BtbN> But I believe it is correct about them
[23:50:20 CET] <nevcairiel> if it didnt fail before, are they really needed? =p
[23:52:47 CET] <BtbN> It not failing before seems like pure luck, impossible to properly control
[23:53:02 CET] <BtbN> Doing a test build now, and if it works, I'll send it to the ml
[23:53:23 CET] <jamrial> BtbN: i'm running configure with it
[23:54:19 CET] <jamrial> uh, this added a lot of "_extralibs" lines to config.mak
[23:54:19 CET] <BtbN> Like, this is what it looks like now: EXTRALIBS-avutil=-pthread -lva -lva-drm -lva -lva-x11 -lX11 -lvdpau -lX11 libdl_extralibs -lm -lOpenCL -lva -ldl
[23:54:27 CET] <BtbN> instead of just -lm -pthread
[23:54:45 CET] <jamrial> https://pastebin.com/Kte3kxQJ
[23:55:07 CET] <jamrial> libdl_extralibs is of course not going to link
[23:55:12 CET] <durandal_1707> why probe format detection stops with first score instead of returning with highest possible score?
[23:55:15 CET] <BtbN> I'm not 100% sure how libdl_extralibs is able to creep in there. It calls a filter function later that is supposed to get rid of it
[23:55:42 CET] <jamrial> look at the pastebin, it's full of such entries
[23:57:03 CET] <SortaCore> what is it about publicising things that make a typo appear randomly
[23:57:19 CET] <BtbN> hm, is $() not a true subshell I wonder. But if not, it shouldn't cause this
[23:57:56 CET] <BtbN> Like, flatten_extralibs has a check at the very end: if test -n "$(filter '*_extralibs' $nested_entries)"; then
[23:58:00 CET] <BtbN> to prevent exactly that
[00:00:00 CET] --- Tue Nov 14 2017