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

[burek]

[00:00:26 CEST] <hanna> that explains it
[00:00:32 CEST] <jamrial> nevcairiel: any reason you didn't submit 543dc6060c to the ml?
[00:00:36 CEST] <hanna> doesn't it reuse the SIMD-accelerated block search from x264 etc?
[00:01:29 CEST] <nevcairiel> jamrial: its kind of ugly and I didnt test much with a variety of hardware
[00:01:39 CEST] <jamrial> ah
[00:02:13 CEST] <nevcairiel> i tried to put it into the flags member, but that one has too much logic baked into it for sanity
[00:03:09 CEST] <durandal_1707> hanna: no its all c and lgpl,  x264 is gpl
[00:03:22 CEST] <atomnuker> also x264 doesn't expose them
[00:03:42 CEST] <jamrial> nevcairiel: was going to say, sounds like it fits better as a flag than its own field
[00:03:56 CEST] <atomnuker> it uses the good old snow encoder obmc
[00:04:07 CEST] <hanna> ah okay
[00:04:17 CEST] <hanna> well I would be interested in perhaps writing a compute shader accelerated version of this
[00:04:22 CEST] <nevcairiel> flags is really more a "refs", every bit set in it indicates its still being held on to for various reasons
[00:04:23 CEST] <hanna> if you can help me with the algorithm
[00:04:25 CEST] <JEEB> sounds cool
[00:04:30 CEST] <nevcairiel> and flags == 0 has special meaning
[00:04:49 CEST] <nevcairiel> so it got ugly to put anything unrelated in there
[00:05:44 CEST] <jamrial> nevcairiel: flags2 :D
[00:06:32 CEST] <nevcairiel> would rather rename flags at that point
[00:06:37 CEST] <durandal_1707> hanna: read the code ,  its straight forward
[00:07:51 CEST] <nevcairiel> in any case sending empty dummy frames to the hardware doesnt really help it, and can even have negative effects, but I haven't confirmed yet if this applies to all hardware or if some might require it
[01:05:31 CEST] <thebombzen> I'm not sure if this is a bug in NVCC or in FFmpeg, but I can't compile CUDA anymore. I recently updated gcc to 7.2, or it might have been a recent patch on git master, and now libavfilter/vf_scale_cuda.ptx won't compile
[01:06:20 CEST] <JEEB> it's the nvcc thing derping IIRC
[01:06:42 CEST] <JEEB> related thing https://trac.ffmpeg.org/ticket/6648
[01:08:07 CEST] <thebombzen> that's the exact error I'm getting
[01:10:55 CEST] <thebombzen> googling it said add -std=c++11 to your cxxflags, but I tried adding it to --extra-cxxflags and --nvccflags and it didn't work
[01:11:24 CEST] <JEEB> anyways, it's the nvcc derping with the new glibc
[01:11:33 CEST] <JEEB> (not related to the GCC itself as far as I can tell)
[01:11:39 CEST] <JEEB> (most likely glibc got updated, too)
[01:11:57 CEST] <thebombzen> probably? but that error is the same one I'm getting, so yea
[01:12:11 CEST] <thebombzen> I'm also on Arch, as was the person who reported that
[02:15:44 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:4306ddd87d09: avcodec/diracdec: Check weight_log2denom
[02:15:45 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:c55478835275: avcodec/diracdsp: fix integer overflow
[02:15:46 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:ef8db67c9295: avcodec/h264idct_template: Fix integer overflow in ff_h264_idct_add()
[02:15:47 CEST] <cone-087> ffmpeg 03James Cowgill 07release/3.3:8aa32a8d5c6b: swscale: fix gbrap16 alpha channel issues
[02:15:48 CEST] <cone-087> ffmpeg 03Steven Siloti 07release/3.3:fd871e24e65b: avformat/utils: fix memory leak in avformat_free_context
[02:15:49 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:1dbfcd65b26d: avcodec/h264_slice: Fix overflow in slice offset
[02:15:50 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:818f73542daf: avcodec/aacdec_fixed: fix invalid shift in predict()
[02:15:51 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:86b5a3d35dd2: avcodec/dirac_dwt: Fixes integer overflows in COMPOSE_DAUB97*
[02:15:52 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:dcf02ee6c691: avcodec/mpeg4videodec: Clear mcsel before decoding an image
[02:15:53 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:f5c6ce899fa5: avcodec/ffv1dec_template: Fix undefined shift
[02:15:54 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:a33e375d7d4c: avcodec/diracdec: Check perspective_exp and zrs_exp.
[02:15:55 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:02d224406f40: avcodec/diracdec: Fixes integer overflow
[02:15:56 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:99491bd260d3: avcodec/zmbv: Check decomp_size
[02:15:57 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:53dae9585f1f: avcodec/pixlet: fixes integer overflow in read_highpass()
[02:15:58 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:16772e43ef5a: avcodec/snowdec: Fix off by 1 error
[02:15:59 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:f5227c50b739: avcodec/fic: Fixes signed integer overflow
[02:16:00 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:253b7829e4f5: avcodec/dirac_dwt_template: Fix integer overflow in vertical_compose53iL0()
[02:16:01 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:736ef73f9c04: avcodec/pixlet: Fixes: undefined shift in av_mod_uintp2()
[02:16:02 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:4a122a0879d5: avcodec/me_cmp: Fix crashes on ARM due to misalignment
[02:16:03 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:6ce9b2c1fec1: avcodec/aacdec_template: Fix running cleanup in decode_ics_info()
[02:16:04 CEST] <cone-087> ffmpeg 03Vitaly Buka 07release/3.3:b6a79b841dcd: avcodec/utils: Fix signed integer overflow in rc_initial_buffer_occupancy initialization
[02:16:05 CEST] <cone-087> ffmpeg 03Vitaly Buka 07release/3.3:c8890413520a: avformat/mov: Fix signed integer overflows with total_size
[02:16:06 CEST] <cone-087> ffmpeg 03Vitaly Buka 07release/3.3:9739a269fb4d: avformat/aviobuf: Fix signed integer overflow in avio_seek()
[02:16:07 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:deca5e734913: avformat/rtpdec_h264: Fix heap-buffer-overflow
[02:16:08 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:eea01de3ff15: avcodec/hevc_ps: Check delta_pocs in ff_hevc_decode_short_term_rps()
[02:16:09 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:5474a7e93b8e: ffprobe: Fix null pointer dereference with color primaries
[02:16:10 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:85ffdcd8ffe4: ffprobe: Fix NULL pointer handling in color parameter printing
[02:16:11 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:305f37e5be00: avformat/hls: Fix DoS due to infinite loop
[02:16:12 CEST] <cone-087> ffmpeg 03Yi and  *®() 07release/3.3:6447815dfbbe: avformat/asfdec: Fix DoS due to lack of eof check
[02:16:13 CEST] <cone-087> ffmpeg 03Yi and  *®() 07release/3.3:4ff1fcd3caa2: avformat/cinedec: Fix DoS due to lack of eof check
[02:16:14 CEST] <cone-087> ffmpeg 03Yi and  *®() 07release/3.3:6bd562e04440: avformat/rmdec: Fix DoS due to lack of eof check
[02:16:15 CEST] <cone-087> ffmpeg 03Yi and  *®() 07release/3.3:8cb0f2c4e55d: avformat/rl2: Fix DoS due to lack of eof check
[02:16:16 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:e910f15fcbb7: avformat/mvdec: Fix DoS due to lack of eof check
[02:16:17 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:b5f0302eeb74: avcodec/sbrdsp_fixed: Fix undefined overflows in autocorrelate()
[02:16:18 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:25ff26aaac97: avcodec/hevc_ps: Fix undefined shift in pcm code
[02:16:19 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:cd221a86a6a3: avcodec/snowdec: Fix integer overflow in decode_subband_slice_buffered()
[02:16:20 CEST] <cone-087> ffmpeg 03Yi(SÑ) 07release/3.3:e6a8d110d7e8: avformat/nsvdec: Fix DoS due to lack of eof check in nsvs_file_offset loop.
[02:16:21 CEST] <cone-087> ffmpeg 03Yi(SÑ) 07release/3.3:c01f799314c3: avformat/mxfdec: Fix DoS issues in mxf_read_index_entry_array()
[02:16:22 CEST] <cone-087> ffmpeg 03Yi(SÑ) 07release/3.3:9d3a7c82a669: avformat/mxfdec: Fix Sign error in mxf_read_primer_pack()
[02:16:23 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:73427f5c7499: avcodec/diracdec: Fix integer overflow in INTRA_DC_PRED()
[02:16:24 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:fef0ccc40132: avcodec/dirac_dwt: Fix multiple overflows in 9/7 lifting
[02:16:25 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:8a640fc7cb5e: avcodec/dirac_vlc: Fix invalid shift in ff_dirac_golomb_read_32bit()
[02:16:26 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:d9cf9f5af822: avformat/mov: Fix DoS in read_tfra()
[02:16:27 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:b61e5a878c84: avformat/asfdec: Fix DoS in asf_build_simple_index()
[02:16:28 CEST] <cone-087> ffmpeg 03Mark Wachsler 07release/3.3:1df91b48a39a: libavcodec/h264_parse: don't use uninitialized value when chroma_format_idc==0
[02:16:29 CEST] <cone-087> ffmpeg 03Michael Niedermayer 07release/3.3:8eb8882af5cc: avcodec/dirac_vlc: limit res_bits in APPEND_RESIDUE()
[02:37:39 CEST] <atomnuker> kierank: x264's commerical license is basically LGPL, right?
[02:37:47 CEST] <kierank> no idea
[02:37:53 CEST] <kierank> ask j-b 
[02:37:54 CEST] <atomnuker> https://mailman.videolan.org/pipermail/x264-devel/2010-July/007508.html
[02:38:07 CEST] <kierank> why?
[02:39:29 CEST] <atomnuker> JEEB said the other day in #ffmpeg it was fully commerical (e.g. you didn't have to release modifications)
[02:40:02 CEST] <kierank> there was a time where i cared about that but now i don't
[03:03:06 CEST] <cone-087> ffmpeg 03James Almer 07master:27a86b8ece6f: avfilter/vf_convolve: use av_clip_uint8
[03:15:56 CEST] <iive> atomnuker: it is not LGPL, it is fully commercial and you have to give modifications back to x264, is what I understand from this email.
[03:24:31 CEST] <kode54> amazing
[03:25:03 CEST] <kode54> so apparently, if I want an implementation of iTunes gapless MP3 tag support in, I have to write a test for it, and craft a public domain test vector
[03:25:56 CEST] <kode54> is there a test framework that can already handle opening a given stream file into a context for me, so I can just verify that the length of the file is correct?
[04:50:00 CEST] <jamrial> kode54: what do you mean?
[04:50:08 CEST] <kode54> well
[04:50:36 CEST] <kode54> first I wrote and contributed an implementation that supports reading named comment tags from ID3v2, which has been integrated
[04:50:56 CEST] <kode54> then I wrote something that reads the iTunSMPB tag, parses it, and applies it to MP3 files with iTunes gapless info
[04:51:15 CEST] <kode54> but someone on the mailing list told me it would not be applied until I included some tests
[04:51:29 CEST] <jamrial> what's the patch/thread name?
[04:52:34 CEST] <jamrial> adding a test is not a requirement for a new feature. it's encouraged (to detect regressions in the future) but the lack of a test should not prevent a feature to be added
[04:54:40 CEST] <kode54> http://ffmpeg.org/pipermail/ffmpeg-devel/2017-January/206198.html
[04:54:49 CEST] <kode54> poster asked for a fate test, whatever that is
[04:55:04 CEST] <kode54> I can make a test, but I need to know where I should design it and put it
[04:55:21 CEST] <kode54> basically, I can encode some short test content with iTunes, and verify that their reported lengths are correct
[04:55:56 CEST] <kode54> it's a slightly annoying tag to deal with, since it requires parsing ID3v2 first
[04:56:38 CEST] <kode54> the tag contains hex encoded fields for pregap, total stream sample count, and a file byte offset of the last six packets of the file
[04:56:41 CEST] <jamrial> kode54: fate is https://ffmpeg.org/fate.html
[04:57:02 CEST] <jamrial> it's our intergrated test system, to detect regressions and such
[04:58:19 CEST] <jamrial> what you were asked was for a sample file (which would be uploaded to the samples repository), and a test using it
[04:58:29 CEST] <jamrial> in this case a simple demuxing test should suffice i guess
[04:58:42 CEST] <kode54> just needs to open the file and check its length
[04:58:51 CEST] <jamrial> the patch can go in without the test, but ideally one should be added. mp3 demuxing can be easily broken
[04:58:58 CEST] <kode54> right
[04:59:02 CEST] <kode54> I will make a test
[04:59:23 CEST] <kode54> does it need to be a full avformat session startup/shutdown?
[04:59:41 CEST] <jamrial> you don't need to write a test program
[04:59:44 CEST] <kode54> oh
[05:00:01 CEST] <jamrial> a simple fate test can just run a ffmpeg cli command
[05:00:16 CEST] <jamrial> check the tests folder in the repo
[05:00:46 CEST] <jamrial> tests/fate has a bunch of Makefiles with recipes to run different tests
[05:00:59 CEST] <jamrial> look at gapless.mak specifically
[05:02:14 CEST] <jamrial> you say this just changes the duration value? does it affect timestamps and such?
[05:08:49 CEST] <kode54> it changes mp3->start_pad and mp3->end_pad, (MP3DecContext) and applies the start_pad + 529 to AVStream start_skip_samples
[05:09:21 CEST] <kode54> subtracting the 529 (decoder delay) from the end pad if it's large enough
[05:09:39 CEST] <kode54> oh yeah
[05:09:45 CEST] <kode54> and it affects the duration returned to the caller
[05:10:21 CEST] <kode54> it affects stream duration field and bitrate field
[05:10:29 CEST] <kode54> not sure if the seek table is built yet by that point
[05:10:49 CEST] <jamrial> the three of those MP3DecContext fields seem to only be looked at if the encoder is lame, lavf or lavc, at least on git head
[05:10:51 CEST] <kode54> called from mp3_parse_vbr_tags
[05:11:39 CEST] <jamrial> ah wait, start_skip_samples is an AVStream field
[05:11:46 CEST] <kode54> it applies duration to AVStream->duration if the itunes function affects it (returns that value 0 if not, prompting caller to ignore it)
[05:12:35 CEST] <kode54> I had to redo the comments patch too
[05:12:45 CEST] <kode54> because iTunes writes v2.2 tags
[05:13:44 CEST] <kode54> I can encode a test file, assuming there's some public domain audio I should use first?
[05:16:53 CEST] <jamrial> kode54: use https://0x0.st/7rk.wav, and try to make the encoded file as short as possible
[05:17:01 CEST] <jamrial> 30 audio frames or so, for example
[05:17:59 CEST] <kode54> well, then I'll need to trim it to 30 frames worth of audio
[05:18:11 CEST] <kode54> or I'll have to construct my own gapless header
[05:18:16 CEST] <kode54> I wonder if itunes encodes files that short?
[05:19:12 CEST] <jamrial> it can be longer if needed. the point is that it should not be too big since it will be added to the fate samples repository
[05:19:19 CEST] <kode54> right
[05:19:41 CEST] <jamrial> and because the more frames the file has, the bigger the reference output of the cli will be
[05:21:02 CEST] <jamrial> use ffmpeg to trim the above wav to whatever amount of frames you think itunes will accept
[05:23:13 CEST] <jamrial> then look at gapless.mak, near the end of the file, and duplicate one of the existing probegaplessinfo tests for your sample
[05:24:05 CEST] <jamrial> name the test fate-gaplessinfo-itunes3 for example
[05:28:40 CEST] <kode54> I'll need to build my own stuff to ffprobe it first
[05:29:04 CEST] <kode54> is there any way to make configure spew out tons of useless info before it completes?
[05:29:45 CEST] <kode54> oh well, building, then I'll assemble a test
[05:39:02 CEST] <Compn> yes there is a way to get configure to do that
[05:39:15 CEST] <Compn> i forgot how :)
[05:56:00 CEST] <kode54> so how do I generate one of those gaplessinfo files?
[05:59:46 CEST] <jamrial> kode54: add your test in gapless.mak poiting to your sample in the fate repo folder, then run "make testname GEN=1"
[06:00:02 CEST] <jamrial> as i said, the name can be fate-gaplessinfo-itunes3 for example
[06:01:05 CEST] <jamrial> if you didn't sync the whole fate samples repo somwhere (like 1gb of samples) then just create an empty folder with the expected hierarchy and put the sample there
[06:01:39 CEST] <jamrial> use SAMPLES=/path/to/samples as part of the make options if you didn't run configure with --samples
[06:02:33 CEST] <jamrial> if you want to sync the whole samples repo, run make fate-rsync and wait
[06:03:02 CEST] <kode54> ran fate-rsync to get the command line
[06:03:06 CEST] <kode54> running it on a NAS4Free instance
[06:03:44 CEST] <jamrial> you don't really need the whole thing if you're not planning on running the whole suit
[06:03:53 CEST] <kode54> probably not
[06:04:03 CEST] <jamrial> for this test, just your sample in the expected folder is enough
[06:04:25 CEST] <kode54> is there a gapless folder?
[06:04:57 CEST] <jamrial> yes, look at fate-gaplessinfo-itunes2
[06:05:05 CEST] <jamrial> $(TARGET_SAMPLES)/gapless
[06:06:01 CEST] <kode54> what about that other gapless mp3 sample?
[06:06:39 CEST] <jamrial> that's used by fate-gapless-mp3
[06:07:09 CEST] <jamrial> not sure what kind of gapless information it uses, but certainly not itunes
[06:27:21 CEST] <cone-047> ffmpeg 03Diego Biurrun 07master:cbe181c8e161: build: Skip generating .version files when cleaning
[06:32:11 CEST] Action: jamrial sleeps
[09:48:20 CEST] <durandal_1707> atomnuker: i will add weston capture format demuxer and decoder,  ok?
[12:38:48 CEST] <JEEB> atomnuker: what I said you released libx264 changes to x264 LLC, that's why you get those pastebins on #x264dev
[12:39:09 CEST] <JEEB> but as far as I know you don't have to give those changes to people who request, although I might be incorrect of course :P
[12:51:24 CEST] <atomnuker> durandal_1707: nope, don't do specific protocols unless you want to end up with 10 or more
[12:51:30 CEST] <atomnuker> the sway guys made one
[12:51:36 CEST] <atomnuker> the orbment guy made one
[12:51:43 CEST] <atomnuker> the kde guys have one
[12:51:48 CEST] <atomnuker> the gnome guys have one too
[12:51:53 CEST] <atomnuker> and of course weston
[12:52:12 CEST] <atomnuker> and whatever other nih their own protocol
[12:52:38 CEST] Action: JEEB at one point was doing a wl_shell compatibility modes for ivi_shell
[12:54:04 CEST] <atomnuker> the DRI capture one jkqxz wrote would be way more useful
[12:57:17 CEST] <JEEB> I'm not even trying to compete there, just mentioned a Yet Another NIH'd protocol (ivi_shell)
[12:57:34 CEST] <JEEB> and how to make it actually useful you had to add a wl_shell compatibility layer ;)
[12:57:53 CEST] <iive> what is this about?
[12:58:21 CEST] <JEEB> wayland protocols
[12:59:11 CEST] <iive> for capturing screen?
[12:59:56 CEST] <JEEB> according to the nearby back-log it seems like he is dis-recommending durandal_1707 from doing something specific to some wayland protocol, since there's so many of them
[13:28:34 CEST] <durandal_1707> wcap from recording screen,  simple rle codec
[13:38:30 CEST] <jkqxz> It's just a simple codec which gets used in the capture files, not a protocol.  Makes sense for ffmpeg to be able to take it as input from files.
[13:38:51 CEST] <JEEB> yea
[13:38:53 CEST] <jkqxz> (Dunno why they had to make a new codec for it - maybe they have some GPU magic to compute it quickly?  Or just pointless NIH.)
[18:03:43 CEST] <jkqxz> Would there be much protest if I proposed deleting the old opencl stuff entirely?
[18:03:49 CEST] <jkqxz> It was added in early 2013, abandoned a few months later, and hasn't changed since.
[18:04:40 CEST] <jkqxz> There is a load of pointless external API only used by the two filters in lavfi, using a lot of global state in lavu.
[18:19:40 CEST] <atomnuker> not at all, go right ahead
[18:20:15 CEST] <atomnuker> I can convert them to vulkan compute once I get chromaticaberration running
[18:21:07 CEST] <jkqxz> I'm also going to submit OpenCL hwcontext, which might sour you to the idea :P
[18:21:27 CEST] <atomnuker> yes, it would, my vulkan hwcontext is done
[18:21:46 CEST] <jkqxz> (Including interop with Beignet, IntelMediaBlob, DXVA2, D3D11 and ARM Mali.)
[18:22:09 CEST] <atomnuker> yeah well I have an interopt with cuda, though its untested
[18:23:06 CEST] <atomnuker> do you seriously think people are going to write opencl crap even if there's all these interops?
[18:23:24 CEST] <jkqxz> No idea.  People seem to like GPU-only stuff.
[18:23:50 CEST] <atomnuker> opencl is old news, outdated, hardly supported, and one one seems to know how to write stuff for it
[18:24:06 CEST] <atomnuker> (those that do give up and leave it bitrotting)
[18:24:08 CEST] <jkqxz> OpenCL is supported on pretty much every device you get nowadays, unlike Vulkan.
[18:24:20 CEST] <atomnuker> for now...
[18:24:43 CEST] <atomnuker> though support can hardly be called support
[18:24:58 CEST] <atomnuker> beignet is crappily packaged and quite heavy
[18:25:10 CEST] <jkqxz> I was a bit shocked that it all worked with the Rockchip MPP stuff, I admit.
[18:25:28 CEST] <atomnuker> you need extra library crap everywhere
[18:25:44 CEST] <atomnuker> rather than a single library with vulkan
[18:25:46 CEST] <jkqxz> ?  Beignet is fine, it's just one library.
[18:26:16 CEST] <atomnuker> fine? its crap, doesn't even have the right name
[18:27:05 CEST] <atomnuker> should have been called libopencl and been the only one
[18:27:32 CEST] <jkqxz> Um, no.  The ICD loader exists so that you can use multiple implementations properly.
[18:27:59 CEST] <atomnuker> and ICD loader? vulkan handles that stuff for you
[18:28:04 CEST] <atomnuker> how outdated
[18:28:10 CEST] <jkqxz> Nothing should be called libopencl except the ICD loader.
[18:28:19 CEST] <jkqxz> How does vulkan do it?
[18:29:22 CEST] <atomnuker> dunno, I don't think anyone has tried to support multiple implementations (because obviously there should only be one and its called mesa) but its there on paper
[18:30:26 CEST] <jkqxz> True, but unfortunately proprietary drivers exist.
[18:30:54 CEST] <jkqxz> Is there mesa/nouveau vulkan for nvidia then?  I thought that didn't exist.
[18:30:54 CEST] <atomnuker> I think they've started to go extinct as far as linux goes
[18:31:30 CEST] <atomnuker> nope, nouveau doesn't support vulkan yet, but amdgpu does and its faster than the binary
[18:31:36 CEST] <jkqxz> For Intel they died a long time ago, AMD still clings to it but Mesa is basically better at everything.
[18:32:06 CEST] <atomnuker> see, a few years ago it was 1/3, now its 2/3, that's progress
[18:32:46 CEST] <atomnuker> (also on my laptop nouveau is faster because DRI_PRIME is efficient and primusrun is a horrid hack)
[18:33:52 CEST] <atomnuker> are you going to port the filters too when you send your opencl patches?
[18:34:15 CEST] <jkqxz> What about Imagination, ARM, Vivante, Qualcomm?  Not much progress really.
[18:34:42 CEST] <jkqxz> No.  Does anyone use those?  (unsharp and deshake)
[18:35:02 CEST] <jkqxz> They're pretty embedded in the current external API and untangling looks hard.
[18:35:21 CEST] <atomnuker> but you're still going to provide some filters, right?
[18:36:31 CEST] <jkqxz> In the first implementation, only a program filter.  I had an overlay filter in libav, but it's kindof stalled on colour conversion issues (should just rewrite it requiring the user to deal with it).
[18:36:33 CEST] <jamrial> jkqxz: the current opencl stuff is pretty much unmaintained and used by two low usage filters, so yeah, IMO it can go if it will be replaced by a better implementation
[18:37:02 CEST] <atomnuker> jkqxz: a program filter?
[18:37:12 CEST] <jkqxz> "run this pixel shader" filter.
[18:37:55 CEST] <jamrial> it was written by some amd guy some time ago, who stopped submitting patches after a while
[18:37:58 CEST] <BtbN> jkqxz, I tried adding opencl to some other filters. The maintainer actually reacted.
[18:38:01 CEST] <jamrial> he was not happy his request to make opencl automatically detected was denied, i recall
[18:38:16 CEST] <BtbN> And had such high compatiblity requirements for the OpenCL code that I'd have had to gimp it so much that it'd be slower than CPU
[18:40:37 CEST] <jkqxz> Which filters did you try to add it to?
[18:40:40 CEST] <atomnuker> jkqxz: that doesn't count, lets make it a gentleman's agreement to not submit hwcontexts until there's something using them without runtime requirements
[18:41:37 CEST] <atomnuker> (I'm very concerned if opencl doesn't get any filters right away no one will try to write some unless there's an actual example)
[18:41:39 CEST] <jkqxz> I've been sitting on the code for more than a year.
[18:42:18 CEST] <atomnuker> my vulkan code is more than a year old too
[18:42:36 CEST] <jkqxz> What's wrong with the "run this pixel shader" filter?  At least OpenCL is required to have a compiler at run-time :P
[18:43:14 CEST] <atomnuker> you won't release any pixel shaders to go along with it, and if you do, there's no excuse to not making it an actual usable filter
[18:43:47 CEST] <jkqxz> It is an actual usable filter.
[18:44:08 CEST] <atomnuker> not by itself it isn't
[18:46:05 CEST] <jkqxz> What filters are you actually intending to write?
[18:48:46 CEST] <atomnuker> chromatic aberration (also not intending, I have the shaders, tested them with my mpv vulkan vo)
[18:49:34 CEST] <atomnuker> I just need the 400 or so lines of boilerplate to spawn a pipeline and run them
[18:50:58 CEST] <atomnuker> though the possibilities are endless considering I found shadertoy
[18:54:58 CEST] <atomnuker> so I need to figure out how to not duplicate those 400 or so lines on every filter
[18:56:43 CEST] <c3r1c3-Win> write a function to setup said 400 lines and pass in the needed values (like filter name and handle and etc)? (well actually a series of functions, not a single one).
[18:57:52 CEST] <atomnuker> its more complicated than that, the vertex buffer and the fragment shader data are difficult to setup and are well integrated with pipeline creation
[18:59:35 CEST] <atomnuker> I'll probably just make some structs to serve as descriptors to make the actual descriptors
[18:59:51 CEST] <atomnuker> https://www.shadertoy.com/view/Md2GDw <- I should do this one too
[19:00:40 CEST] <jamrial> jkqxz: the RockChip stuff, can't it be hwaccels instead decoders?
[19:00:54 CEST] <jamrial> i thought we were trying to move out of adding more hw decoders
[19:01:20 CEST] <jkqxz> There is no usable hwaccel interface.  It's a full stream decoder only.
[19:01:27 CEST] <Compn> stop worrying about 400 lines :P
[19:03:11 CEST] <jkqxz> jamrial:  I have this series <https://lists.libav.org/pipermail/libav-devel/2017-September/084804.html> to make the hwaccel/full decoder situation more sane.  It's significantly worse to apply to ffmpeg because there is much more crazy shit, though.
[19:03:34 CEST] <jamrial> cleaning crazy shit is what i'd love to do
[19:03:46 CEST] <BtbN> jkqxz, color/chromakey
[19:03:46 CEST] <jamrial> the incoming major bump gets rid of some things, like the old vdpau stuff
[19:04:01 CEST] <jamrial> and xvmc
[19:04:25 CEST] <iive> do you remove xvmc completely?
[19:04:44 CEST] <jamrial> iive: apparently no, it's one of the things i asked about in the patch i sent in question
[19:04:46 CEST] <iive> because the ifdef-ery with FF_API_XVMC removes only the old implementation
[19:04:47 CEST] <jkqxz> Bringing it across at the major bump would make sense.  It technically has some externally visible effects in deleting all the fake hwaccels (which shouldn't be externally visible at all), but on a major bump that would be ok.
[19:05:01 CEST] <iive> jamrial: where is the patch?
[19:05:18 CEST] <iive> what thread
[19:05:19 CEST] <jamrial> the ml
[19:05:23 CEST] <jamrial> it's called "Bump major versions of all libraries"
[19:05:58 CEST] <jamrial> the deprecation removes the decoders and most pixfmts except one, and leaves the hwaccels in place
[19:06:10 CEST] <jamrial> this is unlike libav, where there were no hwaccels and everything was removed
[19:06:52 CEST] <iive> well, I did unpdate xvmc to use hwaccels, and mplayer has been using the new api for years
[19:07:19 CEST] <jamrial> it's the one thing i couldn't test, which is why i asked for help/confirmation nothing broke
[19:07:36 CEST] <JEEB> did anyone actually verify xvmc to have been working the last few years?
[19:07:41 CEST] <iive> ok, will test
[19:07:43 CEST] <jamrial> but the patch has been mostly ignored so far
[19:07:57 CEST] <JEEB> since IIRC it only worked with a certain subset of cards circa... 2006 or so?
[19:08:14 CEST] <iive> JEEB: nvidia and radeon and probably intel
[19:09:30 CEST] <JEEB> umm
[19:09:50 CEST] <JEEB> oh, ok. some via s3 thing had xvmc?
[19:10:39 CEST] <JEEB> except openChrome no longer has a web site?
[19:11:10 CEST] <JEEB> ok, this has a nice list https://wiki.archlinux.org/index.php/XvMC
[19:11:16 CEST] <iive> no s3 had something else, that did more stuff, like vlc decoding, drequant
[19:11:28 CEST] <cone-076> ffmpeg 03Michael Niedermayer 07master:981f04b2ae2d: avcodec/scpr: optimize shift loop.
[19:11:28 CEST] <cone-076> ffmpeg 03Jesse Liu 07master:8e17cd20b9cd: add missing ignore files
[19:14:28 CEST] <JEEB> iive: the openchrome driver implemented xvmc interfaces anyways, which is why I noted it :P
[20:27:51 CEST] <jkqxz> Why does calling ff_framesync2_dualinput_get() try to make copies of the input frames?  As compared to ff_framesync2_dualinput_get_writable(), shouldn't the whole point be that it doesn't?
[20:28:54 CEST] <jkqxz> Or is there an ff_framesync2_dualinput_get_and_really_dont_copy_i_mean_it_this_time() somewhere?
[20:32:13 CEST] <nevcairiel> who knows why lavfi does anything
[20:32:43 CEST] <jkqxz> People are meant to have been poking this thing recently.
[20:34:25 CEST] <nevcairiel> maybe someone didnt understand how frame refcounting works
[20:35:16 CEST] <jkqxz> It seems that it always makes a copy of the primary input.  The _writable version is talking about the secondary input only.
[20:35:19 CEST] <jkqxz> Wtf.
[20:40:10 CEST] <durandal_1707> you never asked me so i will not answer
[20:46:15 CEST] <jkqxz> Should I ask you?
[21:02:13 CEST] <jamrial> durandal_1707: answer him, please. he asked in general
[21:03:02 CEST] <jamrial> jkqxz: beware, though, that Nicolas is the one writing this lavfi stuff, and he doesn't take criticism well
[21:09:03 CEST] <durandal_1707> jkqxz: you came to that via looking code or by practice?
[21:09:06 CEST] <jkqxz> I'm aware, which is why I don't really want to touch it at all if possible.
[21:09:31 CEST] <jkqxz> durandal_1707:  Both.  I wrote some code and it tried to clone hardware frames (which doesn't work), and then I looked at it.
[21:10:28 CEST] <durandal_1707> its not designed for hw frames, and copy may not always be needed
[21:10:46 CEST] <jkqxz> How can I contrive circumstances to ensure that copy is never needed?
[21:11:58 CEST] <durandal_1707> you cant, copy is needed by design, how framesync works it needs copy of frame
[21:12:35 CEST] <jkqxz> I don't write on the primary input frame at all.
[21:12:42 CEST] <durandal_1707> but feel free to ask Nicolas,  via ml so he is forced to reply
[21:13:48 CEST] <jkqxz> Would adding a ff_framesync2_dualinput_get_readonly(), which calls ff_framesync2_get_frame() with get == 0 for both inputs be considered sensible?
[21:14:21 CEST] <jkqxz> (Or is there some internal reason I haven't understood  why that doesn't work.)
[21:17:02 CEST] <durandal_1707> jkqxz: you dont need to add dualinput helper for that, call raw framesync2
[21:18:36 CEST] <jkqxz> Example?
[21:19:14 CEST] <jkqxz> vf_premultiply?
[21:20:28 CEST] <durandal_1707> hstack,vstack,remap etc
[21:23:03 CEST] <kierank> durandal_1707: can you come to vdd and give lecture on libavfilter
[21:24:42 CEST] <durandal_1707> kierank: no, i will be with people who actually use it only
[21:24:50 CEST] <kierank> so yourself
[21:25:47 CEST] <jkqxz> And apparently some gluttons for punishment.
[21:26:07 CEST] <jkqxz> durandal_1707:  Thank you, that makes more sense.
[21:26:10 CEST] Action: kierank uses it but statically links a known-good ffmpeg version
[21:26:26 CEST] <durandal_1707> nay, see qctools folks
[21:31:23 CEST] <jkqxz> durandal_1707:  Right, that works much better.  Thank you!
[21:31:46 CEST] <jkqxz> (Apparently it pays to have some idea how stuff works.)
[21:31:50 CEST] <durandal_1707> with hw frames?
[21:31:57 CEST] <jkqxz> Yes.
[21:33:02 CEST] <durandal_1707> why would you need hw frames for framesync at all? hw filters are for single big stuff
[21:33:27 CEST] <jkqxz> OpenCL overlay filter (e.g. subtitles on video).
[21:33:56 CEST] <durandal_1707> noòooo opencl is absurd
[21:34:50 CEST] <jkqxz> How so?  Pixel shaders do exactly what you want here, and the win is doing transcode on the GPU only.
[21:35:07 CEST] <durandal_1707> what speed gain do you get?
[21:35:34 CEST] <durandal_1707> i still may write simd for gbrp/yuv444 case
[21:37:21 CEST] <atomnuker> durandal_1707: its for when the data's already on the GPU, so you don't have to download -> overlay -> upload but just do an upload and overlay on the GPU
[21:37:40 CEST] <atomnuker> uploading and downloading can be extremely slow, especially on 4k video and up
[21:38:07 CEST] <jkqxz> Yeah.  It's definitely for GPU-only cases.
[21:38:17 CEST] <BtbN> I wish it was possible to map CUDA to OpenCL
[21:38:40 CEST] <durandal_1707> so you are all on 4k, i switched from sd to hd
[21:38:54 CEST] <atomnuker> BtbN: haha, you can do that with vulkan (and it'll be faster than opencl, I guarantee it)
[21:39:06 CEST] <atomnuker> (if only because nvidia gimp opencl performance)
[21:39:11 CEST] <jkqxz> For my silly PNG overlay test, it's like 3x speedup for 1/6x CPU, but that's including hardware decode on the GPU.
[21:39:22 CEST] <BtbN> Not really, no. There is no working interop for that yet either
[21:39:43 CEST] <atomnuker> BtbN: but what about the VK_NV_external_memory thing?
[21:39:50 CEST] <BtbN> It's a draft
[21:40:23 CEST] <atomnuker> what are they doing there, they write extension after extension
[21:40:36 CEST] <jkqxz> Hmph.  I'm going to have send this shit to the ML now, because atomnuker challenged me into actually writing a filter.
[21:40:57 CEST] <jkqxz> It still needs stupid conversions in real transcode because there is no nv12a format.
[21:41:35 CEST] <atomnuker> jkqxz: where do you need to convert and what? the overlay (e.g. subtitles) or the video?
[21:42:03 CEST] <jkqxz> Both.  I want to overlay rgba on nv12, so I do yuva420p on yuv420p.
[21:42:35 CEST] <jkqxz> rgba on rgb0 could work too, I guess, but that's probably memory bandwidth because of the lack of subsampling.
[21:43:18 CEST] <BtbN> I also kinda want to write CUDA variants of the color/chromakey and despill filters. They are way too slow on CPU
[21:43:34 CEST] <BtbN> And GPUs are just made for that kinda task
[21:43:35 CEST] <jkqxz> (I generally test on Intel / VAAPI / Beignet), VAAPI is able to convert these things pretty much instantly so it doens't really matter.
[21:44:38 CEST] <atomnuker> jkqxz: couldn't you write your kernel to support yuva420p on nv12 overlaying?
[21:44:53 CEST] <jkqxz> If I made it less general.
[21:45:27 CEST] <jkqxz> <http://sprunge.us/BJJg>
[21:46:30 CEST] <jkqxz> (This is of course a case where pixel shaders are /exactly/ what you want, so OpenCL is pretty good.)
[21:47:36 CEST] <BtbN> The primary problem with using Vulkan as general-purpose compute/pixel shader platform is the lack of standard shaders
[21:47:37 CEST] <atomnuker> how fast are conversions like that (nv12 to yuv420p) in opencl?
[21:48:04 CEST] <atomnuker> BtbN: there's a standard, its what glslang accepts as input
[21:48:20 CEST] <atomnuker> (also SPIRV but writing SPIRV asm doesn't seem fun unlike x86)
[21:48:57 CEST] <BtbN> glslang is just a SPIR-V generator by chance, is it?
[21:48:59 CEST] <jkqxz> No idea, I'm doing conversions in other layers.  (VAAPI, primarily.)
[21:49:02 CEST] <BtbN> And I heard it's pretty terrible
[21:49:18 CEST] <jkqxz> Since mapping VAAPI -> OpenCL is completely free.
[21:51:59 CEST] <atomnuker> BtbN: nope, its not a spirv generator, its a validator which can convert
[21:52:22 CEST] <BtbN> Yeah, you'd either need to commit the SPIR-V to ffmpeg, or bundle a version of glslang into ffmpeg, as they change it all the time
[21:52:29 CEST] <atomnuker> its also tolerable crap if you don't use the API
[21:52:33 CEST] <atomnuker> nope
[21:52:35 CEST] <jkqxz> Hmm.  I wonder whether we could have common spirv for multiple APIs in ffmpeg.
[21:52:42 CEST] <atomnuker> BtbN: I'll just depend on it
[21:52:54 CEST] <BtbN> Will be fun when the interface suddenly changes
[21:53:04 CEST] <BtbN> they don't seem to care about api/abi compatiblity
[21:53:35 CEST] <atomnuker> BtbN: the cli? its a reference and plenty of other programs depend on it, so I doubt they'll change it
[21:53:57 CEST] <BtbN> they all bundle/sub-module it for the reason that it's a moving target
[21:54:22 CEST] <thardin> that capture decoder has an impressive amount of sigsegv and infinite loop potential
[21:56:06 CEST] <jkqxz> Oh, durandal_1707 wrote the wcap thing.  Is it actually usable?  Are the files it makes sanely sized for reasonable use-cases?
[21:58:11 CEST] <durandal_1707> its rle so its not that much useable for storage, scpr is much better in that case if you wish to write encoder for it
[21:59:01 CEST] <thardin> looks like a pretty awful format. just simple deflate would likely be better
[21:59:18 CEST] <durandal_1707> but if you have high motion its files will be huge
[22:00:58 CEST] <durandal_1707> deflate is slow iirc
[22:01:24 CEST] <jkqxz> The specification made it look like it will immediately saturate your disk bandwidth on non-flat content.
[22:01:34 CEST] <thardin> there are fast setting. even in RLE mode it would likely be faster
[22:01:51 CEST] <thardin> or at least not bloat the data as much
[22:22:55 CEST] <atomnuker> what is wcap?
[22:26:32 CEST] <durandal_1707> atomnuker: weston capture, screen recorder
[22:30:52 CEST] <Compn> durandal_1707 : whats the best screen capture codec ?
[22:30:56 CEST] <Compn> :)
[22:31:12 CEST] <Compn> where is ff screen capture codec? "ffsc" ? durandal_1707!!! you could make this
[22:31:19 CEST] <durandal_1707> Compn: HEVC
[22:31:25 CEST] <Compn> just like ffv1...
[22:33:20 CEST] <durandal_1707> Compn: ffv2 or ffvx with ffv1 compresion ratio and utvideo decode speed
[22:56:05 CEST] <jkqxz> Does anyone want to coment on kmsgrab?  Has anyone tested it at all?
[23:00:27 CEST] <atomnuker> I'll test it
[23:00:53 CEST] <atomnuker> (code wise I've looked at it and looks good)
[23:01:25 CEST] <jkqxz> I've tried in on Intel (works cleanly with VAAPI) and AMD (works, but hard to use the result).
[23:02:00 CEST] <jkqxz> Be nice to know if it works at all Nvidia, I could believe it just barfs totally.
[23:04:53 CEST] <atomnuker> knowing how fragile their vulkan driver is (it causes kernel oopses if you do something obviously wrong) I don't have high hopes
[23:05:46 CEST] <nevcairiel> if its so obviously wrong, don't do it? :)
[23:06:52 CEST] <jkqxz> "Doctor, doctor, it hurts if I do this."
[23:07:58 CEST] <atomnuker> nevcairiel: the thing is nothing is obvious in vulkan and the validator passed with flying colors
[23:09:25 CEST] <atomnuker> jkqxz: where are the patches to remove the old opencl crap?
[23:09:41 CEST] <BtbN> I'm pretty sure the maintainers will complain about removing it.
[23:09:51 CEST] <BtbN> They do still respond to mails
[23:10:41 CEST] <jkqxz> Not written yet, because we can't apply them until the version bump.
[23:10:53 CEST] <jkqxz> (lavfi depends on the lavu symbols.)
[23:12:56 CEST] <atomnuker> jkqxz: "No handle set on framebuffer: maybe you need some additional capabilities?"
[23:13:33 CEST] <BtbN> VK_NV_external_memory seems to be win32 only...
[23:13:54 CEST] <atomnuker> jkqxz: if I run it as root - "Failed to create surface from DRM object: 18 (invalid parameter)."
[23:14:33 CEST] <jkqxz> Platform?
[23:15:36 CEST] <atomnuker> linux
[23:15:49 CEST] <jkqxz> And yeah, you need to run it as root if something else (X or Wayland, say) is DRM master.
[23:16:25 CEST] <jkqxz> (Well, CAP_SYS_ADMIN.)
[23:16:26 CEST] <BtbN> https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/blob/master/include/vulkan/vulkan.h#L4124 looks very Windows specific.
[23:16:43 CEST] <BtbN> Would probably need a CUDEVPTR addition from nvidia to be useful
[23:17:47 CEST] <jkqxz> OPAQUE_FD sounds like exactly what all real people would want.
[23:17:48 CEST] <atomnuker> jkqxz: why is there a hwmap filter?
[23:18:01 CEST] <BtbN> jkqxz, if you have system memory, or an fd, maybe
[23:18:03 CEST] <jkqxz> Can you turn CUDA images into DRM objects?
[23:18:06 CEST] <BtbN> no
[23:18:17 CEST] <atomnuker> oh to map kms to vaapi frames
[23:19:08 CEST] <jkqxz> hwmap is the best filter evar!
[23:20:49 CEST] <atomnuker> doing -vf hwdownload,format=bgr0 yields junk, though the image is there
[23:21:07 CEST] <BtbN> jkqxz, the OPAQUE_FD expects a file descriptor returned by getMemoryFdKHR
[23:21:15 CEST] <atomnuker> (maybe its some special gpu tiled format)
[23:21:17 CEST] <BtbN> and getMemoryFdKHR uses the same enum I linked for the memory it is able to turn into an fd
[23:21:28 CEST] <BtbN> so no dice there either
[23:21:39 CEST] <BtbN> Will have to wait for nvidia to add CUDA interop there
[23:21:43 CEST] <BtbN> which should be trivial for them
[23:21:50 CEST] <iive> most cpu do use 8x8 tiles (blocks)
[23:21:54 CEST] <iive> gpu
[23:22:37 CEST] <jkqxz> Yeah, you getting tiled formats is annoying.  We don't have any untiler.
[23:23:12 CEST] <jkqxz> For Intel at least you can map through an untiler in the MMU, but that requires quite a bit more specific magic.
[23:23:32 CEST] <jkqxz> (Hence mapping to VAAPI being the easiest use-case.)
[23:23:39 CEST] <BtbN> at least nvidia doesn't in their API
[23:23:45 CEST] <BtbN> if they do it internally, it's nicely hidden
[23:24:06 CEST] <atomnuker> jkqxz: yeah, seems like mapping drm->vaapi fails here
[23:24:23 CEST] <atomnuker> (removing the kms part and feeding in some video with hwupload works)
[23:25:26 CEST] <jkqxz> Intel?
[23:25:30 CEST] <jkqxz> AMD?
[23:26:30 CEST] <atomnuker> intel
[23:26:36 CEST] <atomnuker> I'll try on another machine and on x11
[23:29:28 CEST] <jkqxz> X11 vs. anything else shouldn't make any difference.
[23:30:05 CEST] <jamrial> jkqxz: no way to implement the opencl version of overlay into the existing filter, much like deshake does with the old lavu opencl api?
[23:30:51 CEST] <jkqxz> It's not useful to do.  You need AV_PIX_FMT_OPENCL input and output.
[23:31:59 CEST] <jkqxz> (Auto-upload/download is an abomination.  It's not a cheap operation at all, it should never be transparent.)
[23:32:28 CEST] <jkqxz> (Since the whole point of this stuff is to make things faster, not to do things you couldn't do some other way.)
[23:34:59 CEST] <jkqxz> atomnuker:  On things to test with, do you have any of the ARM platforms with Vulkan implementations?  Do they work sensibly at all?
[23:38:24 CEST] <BtbN> I know the Nvidia ones do, but that's about to be expected
[23:39:00 CEST] <atomnuker> jkqxz: no, but I don't think I've heard bad things from people who have worked with them
[23:43:41 CEST] <atomnuker> jkqxz: works perfectly on another machine, cpu activity is around 27% for hevc encoding
[23:43:45 CEST] <atomnuker> even on wayland
[23:48:53 CEST] <philipl> BtbN: vk_khr_external_memory(_fd) are supported on linux.
[23:48:59 CEST] <philipl> The early vk_nv version might be win32 only
[23:49:07 CEST] <philipl> but there's not documentation on how to do cuda interop
[23:49:38 CEST] <philipl> maybe you just pass a cudaPtr to it and it works, but I've never been in a position to try
[23:52:15 CEST] <jkqxz> atomnuker:  Nice!  And you get everything except the mouse?  (It is possible that things use KMS overlay planes, and unfortunately this method would require capturing them separately and then blending them afterwards to match what the GPU would do on its own output, which doesn't sound very fun.)
[23:53:12 CEST] <jkqxz> Well, the mouse is also an overlay plane and could be captured, but there doesn't seem much point.
[23:53:31 CEST] <nevcairiel> some people might want it if they make demo videos of things
[23:53:48 CEST] <nevcairiel> show where to click and whatnot
[23:54:33 CEST] <atomnuker> yeah, I get everything except the mouse, though it seems the hardware encoder can't handle 60fps at 2560x1440 so I have to downscale it
[23:55:02 CEST] <atomnuker> (or maybe its the scaler, I'm also playing a 60fps video so the gpu has some load)
[23:55:05 CEST] <jkqxz> hevc_vaapi?  They set the default speed down in recent versions, set -compression_level 7.
[23:55:13 CEST] <atomnuker> (or maybe its the scaler, I'm also playing a 60fps video so the gpu has some load)
[23:55:51 CEST] <atomnuker> yep, compression level=7 makes it almost realtime
[23:57:02 CEST] <jkqxz> IMO that was a stupid change (people use hardware encoders for speed / low CPU use, not for quality), but oh well.
[23:57:48 CEST] <atomnuker> damn, even switching VTs works without corruption or dropped frames
[00:00:00 CEST] --- Mon Sep 11 2017