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

[burek]

[06:04:33 CEST] <philipl> BtbN: https://github.com/philipl/nv-codec-headers/commit/d098cb44f6103a03476d16ac2bbe14ecbc9e1175
[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