[06:04:33 CEST] <philipl> BtbN: https://github.com/philipl/nv-codec-headers/commit/d098cb44f6103a03476d16ac2... [07:11:45 CEST] <geri> hi [07:11:49 CEST] <geri> someone here? [07:12:10 CEST] <geri> how can i concatinate horizontally and vertically video with ffmpeg? [17:43:58 CEST] <BtbN> philipl, looks good, feel free to push. [17:44:30 CEST] <BtbN> That's the third individual UUID type defined by nvidia... [18:02:14 CEST] <philipl> hah. [18:02:39 CEST] <philipl> thanks [18:03:28 CEST] <philipl> pushed. [18:40:45 CEST] <durandal_1707> wtf, now people who top post say sorry for top posting! what is happening? perhaps carl started to reply off-list with his usual mantra? [19:36:02 CEST] <durandal_1707> michaelni: nobody gives anything for free any more [19:36:52 CEST] <atomnuker> well our servers are hosted for free [19:44:07 CEST] <cone-843> ffmpeg 03Daniel Molkentin 07master:d95c5b003c04: libavfilter/ebur128: add target level option for EBUR128 visualization filter [19:44:07 CEST] <cone-843> ffmpeg 03Daniel Molkentin 07master:1cee8f03cf01: libavfilter/ebur128: add target value to statistics line [19:44:07 CEST] <cone-843> ffmpeg 03Daniel Molkentin 07master:d587390988e1: libavfilter/ebur128: add gauge option [19:44:07 CEST] <cone-843> ffmpeg 03Daniel Molkentin 07master:d445bcb137fa: libavfilter/ebur128: introduce target range [19:44:07 CEST] <cone-843> ffmpeg 03Daniel Molkentin 07master:4069d2d08707: libavfilter/ebur128: add scale parameter [19:44:08 CEST] <cone-843> ffmpeg 03Daniel Molkentin 07master:a628fa1feca4: libavfilter: bump micro version to 101 [20:07:28 CEST] <cone-843> ffmpeg 03Paul B Mahol 07master:7a6d88ee6269: avfilter/af_afir: remove again option, merge it with gtype [20:33:36 CEST] <durandal_1707> atomnuker: are you paid to work in multimedia or you are working in web stuff? [20:43:03 CEST] <atomnuker> web stuff? god no, never have [20:43:17 CEST] <atomnuker> am paid to work on av1 for now [20:46:12 CEST] <durandal_1707> atomnuker: and FFv2? [20:48:50 CEST] <atomnuker> for fun, lol, like everything I've done for the project (with exception of dirac/vc2 from 2.5 years ago) [20:57:17 CEST] <jamrial> is there anything to gain by making avcodec_default_get_buffer2() allocate a single contiguous buffer for all planes instead of separate ones? [20:58:13 CEST] <durandal_1707> our allocator can alloc max 4gb? [21:02:42 CEST] <jamrial> INT_MAX or so by default, it seems [21:05:09 CEST] <atomnuker> shouldn't do anything, all planes are always aligned so even on old arm CPUs there shouldn't be a delay continuously reading each pixel [21:05:47 CEST] <durandal_1707> nano-optimization [21:05:51 CEST] <atomnuker> in 99% of the cases they're allocated and freed together, so shouldn't cause fragmentatioin [21:06:14 CEST] <atomnuker> yeah, you'd save some work for the allocator but that's nanooptimization territory [21:10:14 CEST] <jkqxz> Yeah, it makes sense that it should be irrelevant in terms of normal use. [21:10:34 CEST] <jkqxz> There could be some consequences of the large virtually-contiguous allocations, though. [21:11:11 CEST] <jkqxz> It might make memory pressure worse on systems with small address space (i.e. 32-bit systems), though case where that matters are hopefully rare. [21:11:32 CEST] <jkqxz> On the other hand, it could lead to better use of huge pages where they are available. [21:54:33 CEST] <BtbN> Nvidia has a bunch of APIs that absolutely expect the buffer to be continous, and only want one pointer and the stride as input. [21:58:01 CEST] <atomnuker> how... unflexible, with vulkan you're suggested to put padding in between the planes and in some cases are required to do so [21:58:36 CEST] <atomnuker> though that's only on intel and maybe amd, nvidia's minimal alignment for a mappable buffer is 1 [21:59:54 CEST] <jkqxz> Presumably that is with offsets (somehow constrained) for the planes after the first, not requiring the planes to directly follow each other? [22:01:08 CEST] <BtbN> Nvidia just doesn't really want/expect you to use plain memory there. But a CUarray instead [22:01:18 CEST] <BtbN> Which abstracts that stuff away [22:01:29 CEST] <philipl> yeah [22:20:33 CEST] <nevcairiel> if you map sysmem onto gpu textures in d3d, its also one big buffer only, no separate planes [22:23:59 CEST] <BtbN> Using actual CUDA pointers is convenient though, as they behave exactly like normal pointers in pretty much all aspects [00:00:00 CEST] --- Thu Oct 11 2018