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

[burek]

[00:26:50 CEST] <philipl> Lynne: hi
[14:04:20 CEST] <durandal_1707> STOP MOVING SWSCALE INTO LAVC
[14:04:30 CEST] <durandal_1707> JUST STOP!!!
[14:13:30 CEST] <cone-300> ffmpeg 03Paul B Mahol 07master:79d14a3cc8e9: avfilter/vf_v360: remove intermediate variables
[14:13:31 CEST] <cone-300> ffmpeg 03Paul B Mahol 07master:51a2f02117df: avfilter/vf_v360: add fixed pixel padding options
[15:28:18 CEST] <Lynne> durandal_1707: I was wondering if I'm the only one seeing that patch for what it was, as usual
[15:31:09 CEST] <durandal_1707> Lynne: what's blocking vulkan pushing to master?
[15:32:15 CEST] <JEEB> I think he was just tired of bikeshedding etc
[15:32:40 CEST] <durandal_1707> i did not noticed any
[16:18:36 CEST] <Lynne> who's tired of bikeshedding?
[18:14:13 CEST] <kierank> durandal_1707: I AGREE
[18:14:16 CEST] <kierank> BUT BIG CORPORATES DO THIS
[18:18:30 CEST] <kierank> durandal_1707: I support you
[18:18:43 CEST] <BBB> huh?
[18:26:51 CEST] <kierank> BBB: there's a guy trying to merge colourspace conversion into an encoder
[18:26:57 CEST] <kierank> that old chestnut
[18:33:00 CEST] <cone-504> ffmpeg 03Andreas Rheinhardt 07master:25a501b5287b: avutil/opt: Fix type specifier
[18:33:00 CEST] <cone-504> ffmpeg 03Michael Niedermayer 07master:0e8b7709a92a: avcodec/sunrast: Fix return type for "unsupported (compression) type"
[18:33:00 CEST] <cone-504> ffmpeg 03Michael Niedermayer 07master:0728d644973c: avcodec/sunrast: Fix indention
[19:15:36 CEST] <BBB> kierank: lol
[19:15:44 CEST] <BBB> kierank: one of these stupid game codecs again?
[19:15:47 CEST] <BBB> or a real codec this time?
[19:15:48 CEST] <kierank> BBB: no, v210
[19:16:02 CEST] <BBB> is v210 even a codec?
[19:16:13 CEST] <BBB> it's just a particular way of writing 422-10bit, right?
[19:17:10 CEST] <kierank> yes
[19:17:29 CEST] <kierank> debatable whether it's a codec or a pixel format
[19:18:30 CEST] <BBB> i see patch now
[19:18:34 CEST] <BBB> that's fun
[19:18:40 CEST] <BBB> big name, expert, important
[19:18:44 CEST] <BBB> all the buzzwords
[19:18:46 CEST] <BBB> <3
[19:32:16 CEST] <cone-504> ffmpeg 03Paul B Mahol 07master:05a2ce932654: avformat/y4m: do not try to seek if pts is less than 0
[19:57:45 CEST] <cone-504> ffmpeg 03Paul B Mahol 07master:b4d2bea64722: avfilter/v360: reduce size of some struct members
[20:49:51 CEST] <philipl> Lynne: I've been taking a look at map_to_cuda
[20:49:59 CEST] <philipl> jkqxz: Could use your thoughts on this one.
[20:50:42 CEST] <philipl> We want to map a vulkan hw frame to cuda. Due to a vulkan image not mapping to the same thing as what PIX_FMT_CUDA represents, we can't directly map and need to do a gpu side copy.
[20:50:52 CEST] <philipl> So far so good. Lynne wrote this for going from cuda to vulkan.
[20:52:11 CEST] <philipl> So, we need to allocate the dst frame from a cuda device context. The approach I've started with is to support deriving a cuda context from a vulkan context and then doing a hwmap=derive_device=cuda in the filter chain.
[20:53:00 CEST] <philipl> So when I get to the map callback, I want to do av_hwframe_get_buffer, but because the cuda context is derived, it actually triggers an infinite recursion as it tries to go back to the source context to map the frame.
[20:53:24 CEST] <philipl> So I want a non-derived cuda context where av_hwframe_get_buffer actually allocates.
[20:54:06 CEST] <philipl> but of course I also want to make sure the cuda context is on the same physical device as the vulkan context or none of this works.
[20:54:11 CEST] <philipl> Is there a way to get what I want?
[22:17:22 CEST] <Lynne> philipl: sounds good, the way I did it in the vulkan hwcontext was to just manually reinitialize the internal frames pool in the map function in case it isn't
[22:17:55 CEST] <Lynne> avhwdevice* are always initialized properly and that's all that's needed to init the frames pool, but I'm not sure how it is for cuda
[22:20:47 CEST] <Lynne> btw why does cuda have the concept of mipmaps when its purely a compute API?
[22:27:32 CEST] <philipl> Lynne: I guess because they expect to interact with textures. That basic concept has been in the language since very early on.
[22:27:46 CEST] <philipl> Given that, I don't know why the interop is so awkward.
[22:37:33 CEST] <cone-504> ffmpeg 03Paul B Mahol 07master:a8925d264a95: avfilter/vf_v360: fix mercator_to_xyz()
[22:37:34 CEST] <cone-504> ffmpeg 03Paul B Mahol 07master:043038ea56ab: avfilter/vf_v360: fix xyz_to_mercator()
[22:37:35 CEST] <cone-504> ffmpeg 03Paul B Mahol 07master:4ba45a95df1b: avfilter/vf_v360: adjust h for mercator input/output
[22:38:13 CEST] <philipl> Lynne: Yeah, you can init the vulkan pool using private functions. The equivalent cuda context calls are also private.
[22:38:36 CEST] <philipl> And we can't easily implement map in the cuda context because it depends on the vulkan images being initialised correctly with all the export flags, etc.
[22:38:53 CEST] <philipl> Might have to brute force it and add a cuda helper to do pool init from the outside.
[22:40:02 CEST] <Lynne> are you talking about initing the cuda pool with vulkan frames?
[22:40:33 CEST] <Lynne> if the vulkan->cuda interop is in the cuda hwcontext there's nothing private it should need outside of the cuda hwcontext
[22:41:53 CEST] <philipl> Lynne: Yeah, if I was to implement in the interop in the cuda hwcontext, I'd be able to init the pool just fine, but we couldn't guarantee that the vulkan frames were exportable.
[22:42:13 CEST] <philipl> So I think we really still want the interop in the vulkan hwcontext, but then I need  a way to init the cuda context's pool.
[22:42:42 CEST] <philipl> Basically, I need a helper that I call to 'un-derive' the context so it uses its own allocator.
[22:52:41 CEST] <Lynne> philipl: if they're not exportable then you should just error out
[22:53:39 CEST] <Lynne> users can always create a avhwframescontext for vulkan themselves, with usage flags or a queue that does not permit exporting
[22:54:33 CEST] <Lynne> but if you need to export internal cuda stuff for use in vulkan, you can put them in hwcontext_cuda_internal.h as we already use that for cuda->vulkan device deriving
[22:55:03 CEST] <philipl> Lynne: yeah, so that's basically my plan.
[22:58:34 CEST] <jkqxz> It sounds like what you want isn't really mapping as currently defined by the API.
[22:58:38 CEST] <jkqxz> If the destination is just any CUDA frame with the right properties, can you derive the device followed by making a new CUDA frames context and then use transfer?
[22:59:19 CEST] <jkqxz> (That case could be added to the hwmap filter if wanted.)
[22:59:48 CEST] <philipl> jkqxz: Yeah, it's not really mapping. It's really a transfer, but I'm not sure how you set that up to work as-is. 'hwmap' is the only way to indicate a shift from one context to another right?
[22:59:58 CEST] <philipl> We sort of need a hwtransfer filter right?
[23:01:09 CEST] <jkqxz> That would work.
[23:01:11 CEST] <philipl> jkqxz: so right now, I've implemented derive_device in hwcontext_cuda and then have a 'hwmap=derive_device=cuda' filter which triggers the map operation on the hwcontext_vulkan side.
[23:01:47 CEST] <philipl> At the time the map is called, there's already a dervied hwframesctx which won't work. I'm not sure where I'd interpose to fix that.
[23:01:49 CEST] <jkqxz> Adding it to the hwmap filter might be nice for filter graphs, but it sounds like the API-level part does need to be different.
[23:01:59 CEST] <philipl> Perhaps that is not worth it and I should just write the hwtransfer filter.
[23:03:09 CEST] <philipl> The brute force thing to do is have some 'underive' function that would clear the source_frames and re-init the context.
[23:03:19 CEST] <philipl> which is rather silly
[23:05:02 CEST] <jkqxz> Do you even want the mapping semantics from the outside?  (Specifically, the behaviour where it will copy back a writable mapping when you unmap.)
[23:05:17 CEST] <philipl> No
[23:06:24 CEST] <philipl> The only realistic pipelines here are nvdec -> vulkan filters -> non-nvidia sink, and nvdec -> vulkan filters -> nvenc. It's all one way transfers.
[23:06:53 CEST] <philipl> and due to the interop limitations, each hand off is a GPU copy
[23:07:22 CEST] <philipl> but highly invasive on the vulkan hwcontext due to having a bunch of cuda-side state that must be carried with the frames.
[23:10:35 CEST] <philipl> Would it do the right thing if transfer_data_from implemented a cuda path and then we added a format=cuda to the filter chain before nvenc?
[23:11:06 CEST] <philipl> I guess probably not due to lack of correctly initialised dst frame
[23:11:43 CEST] <jkqxz> There isn't any auto-hwtransfer anywhere.  A hwupload could do it?
[23:13:49 CEST] <philipl> Yeah, if the hwupload accepts the vulkan pix fmt, which it won't today.
[23:13:54 CEST] <philipl> I can experiment.
[23:14:34 CEST] <jkqxz> I guess you want hwtransfer which is basically identical to hwupload except accepts different input formats?  Or something like that.
[23:14:39 CEST] <philipl> Yeah
[23:14:53 CEST] <philipl> This seems like it might lead somewhere useful.
[23:15:10 CEST] <philipl> but I have to take a break now. Will come back to it later.
[23:35:30 CEST] <mkver> jkqxz: Can you take a look at these two patches: http://ffmpeg.org/pipermail/ffmpeg-devel/2019-September/249814.html They are in response to ticket #8126.
[00:00:01 CEST] --- Mon Sep 23 2019