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

[burek]

[02:16:31 CEST] <cone-121> ffmpeg 03Limin Wang 07master:cbc63d61b284: avfilter/vf_scale: split the scale_frame function from filter_frame for activate function support
[03:25:43 CEST] <philipl> Lynne: It works, but only for VkBuffers. If you try and call it on memory bound a VkImage, you'll get an error. The end result is that due to ffmpeg only defining the hw format as a cudeviceptr, you still have to do a copy on the vulkan->cuda transfer (cuMemcpy2d from array to device memory).
[03:26:54 CEST] <philipl> Technically, we could introduce a second hw format that maps to a cuarray to allow a zero copy transfer, and nvenc now supports cuarrays as input so it would have value, but adding a second hw format for the same hw is weird and would probably be a hard sell.
[03:27:01 CEST] <philipl> BtbN certainly doesn't think it's worth it.
[03:29:41 CEST] <philipl> Separately, CUarrays don't map well to our AVFrame design. They don't have a direct allocation size and pools work with a size rather than dimensions. I experimented with a CUarray format a few years ago and it was awkward and I never quite got it working.
[10:52:57 CEST] <cone-219> ffmpeg 03Paul B Mahol 07master:85386c36e331: avfilter/vf_v360: add aliases for some projections
[12:42:12 CEST] <Lynne> philipl: it would be fine, just deprecate the old version along with the old cuda hwaccel which afaik didn't support it
[12:53:26 CEST] <BtbN> We're not gonna deprecate the current pixel format... Specially not if the other version has a bunch of known issues and limitations.
[12:53:41 CEST] <BtbN> Both hwaccel-decoders, old and new, cannot output arrays either.
[12:54:39 CEST] <BtbN> If we'd want to make the nvdec hwaccel output arrays, it would be forced to sync immediately after every frame to copy. Slowing it down immensely.
[12:55:07 CEST] <BtbN> The cuvid decoders could output arrays quite easily however.
[12:55:14 CEST] <BtbN> Because they make a copy anyway
[12:56:45 CEST] <BtbN> I wouldn't block patches that add an Array-Based pixel format, but I feel like others would.
[12:57:15 CEST] <BtbN> If we go that route, we also cannot get rid of the CUdevptr based format, simply because that's what nvdec inevitably outputs.
[16:54:45 CEST] <cone-564> ffmpeg 03Calvin Walton 07master:3ad5d4df9ce7: lavfi/concat: allow to support inputs with different frame rates
[21:09:14 CEST] <cone-564> ffmpeg 03Paul B Mahol 07master:a13b61b7fd05: avfilter/vf_v360: disallow too low h_fov/v_fov
[21:09:15 CEST] <cone-564> ffmpeg 03Paul B Mahol 07master:973051e3bd56: avfilter/vf_v360: add stereographic output projection
[21:09:16 CEST] <cone-564> ffmpeg 03Paul B Mahol 07master:8a1f0cb9e3a2: doc/filters: update v360
[23:33:15 CEST] <Lynne> seems like intel gpus deal with caching better than nvidia
[23:33:37 CEST] <Lynne> a naive avgblur has no performance loss over a caching one
[23:33:54 CEST] <Lynne> on nvidia, a caching one is 18% faster
[00:00:00 CEST] --- Mon Sep  9 2019