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

[burek]

[12:52:36 CEST] <cone-600> ffmpeg 03Paul B Mahol 07master:0939c33b54db: avfilter/af_afir: calculate group delay too
[12:56:58 CEST] <cone-600> ffmpeg 03kjeyapal at akamai.com 07master:f848d384dd36: avformat/dashenc: Support HTTP Persistent for master.m3u8 as well
[12:56:59 CEST] <cone-600> ffmpeg 03kjeyapal at akamai.com 07master:e715b8e10d0d: avformat/dashenc: URL close unconditionally after DELETE segments
[12:59:49 CEST] <cone-600> ffmpeg 03Paul B Mahol 07master:18d391cffee3: avfilter: add chromahold filter
[17:14:30 CEST] <durandal_1707> what i shouldn't do next?
[17:33:18 CEST] <atomnuker> you totally shouldn't do a motion follow filter (that panorama video->image thing)
[17:48:38 CEST] <durandal_1707> atomnuker: that is very hard, and subject of active research
[17:50:26 CEST] <iive> doesn't the stabilize filter support that?
[17:53:44 CEST] <philipl> deinterlacer as a vulkan filter
[17:53:53 CEST] <philipl> definitely don't do that
[17:54:51 CEST] <atomnuker> well, I'd definitely prefer for it to be a vulkan filter
[17:55:18 CEST] <atomnuker> but I'm not sure how well that would work
[17:55:24 CEST] <philipl> I assumed we were secretly encouraging him to do things :-)
[17:55:48 CEST] <atomnuker> if hwaccels supply what ffmpeg uses (2 fields in 1 frame) then it'll be efficient
[17:56:04 CEST] <philipl> I believe they all do.
[17:56:26 CEST] <atomnuker> since you could do a single frame in place and only have to allocate a single new other frame (in case you're doubling the framerate, which you should be)
[17:57:30 CEST] <atomnuker> speaking of hwcontext_vulkan, I see finally the modifiers extension has been merged
[17:57:44 CEST] <philipl> yay
[17:57:59 CEST] <atomnuker> I should update the patchset with the comments from last month
[17:58:15 CEST] <atomnuker> grr, I'll have to install nvidia binaries to make sure vf_avgblur still works
[17:58:59 CEST] <atomnuker> because I can still crash the gpu on intel because mesa can't test because nothing exists which uses the multiplane stuff
[17:59:58 CEST] <jamrial> atomnuker: if it will require a recent vulkan release, make sure the configure checks are correct
[18:02:10 CEST] <durandal_1707> michaelni: does upstream ilbc code have that same bug?
[18:15:55 CEST] <michaelni> durandal_1707, dont know but the webrtc ilbc code IIRC had some check for the start
[20:23:52 CEST] <philipl> BtbN: I have just written the world's worst bob deinterlacer for cuda (just using memcpys)
[20:24:19 CEST] <BtbN> oh god
[20:24:39 CEST] <BtbN> I kinda want any future CUDA filters to be Vulkan instead
[20:24:53 CEST] <BtbN> But no idea how far the Vulkan infra itself is
[20:24:57 CEST] <philipl> The import/export restrictions make that awkward.
[20:25:04 CEST] <philipl> You can't export from cuda to vulkan
[20:25:17 CEST] <philipl> that means you always have to do a copy to transfer data into the vulkan filter
[20:25:29 CEST] <philipl> import the vulkan buffer/surface to cuda, then copy over.
[20:25:46 CEST] <BtbN> Isn't the API supposed to support mapping?
[20:25:54 CEST] <philipl> Yes, but it's import-to-cuda mapping
[20:26:07 CEST] <philipl> It's great for writing a cuda filter against a vulkan input...
[20:26:23 CEST] <philipl> This is, no doubt, deliberate on nvidia's part.
[20:27:30 CEST] <philipl> As for me, I now at least have a working skeleton for a deinterlacer. I took the field->frame logic from vf_yadif and ripped out the processing.
[20:27:58 CEST] <BtbN> CUDA filters are always going to be non-free, so I'm not sure how worth it that is
[20:28:57 CEST] <philipl> In so far as they are not GPL compatible, yes. But they are LGPL compatible based on how configure works and I think that's legally defensible.
[20:29:12 CEST] <BtbN> nope, they are not even LGPL compatible
[20:29:33 CEST] <BtbN> cuda-sdk hard-enforces non-free
[20:29:41 CEST] <philipl> It probably should not.
[20:29:56 CEST] <BtbN> Looking at the license in those headers and on the libs, it should
[20:30:06 CEST] <philipl> kernel loading api can be put in the dynloader (I intend to) and then you'd be saying nvcc output is inherently non-free which doesn't seem right
[20:30:34 CEST] <BtbN> Those are a lot of functions to put in the dyn-loader
[20:30:46 CEST] <philipl> It's a hard life.
[20:30:59 CEST] <BtbN> To the point where it becomes more than just questionable if they are really obtained in a way that's considered free
[20:32:46 CEST] <BtbN> It's also not about nvcc, but the license you have to accept in order to get nvcc. I would not call that (L)GPL compatible in any way
[20:40:27 CEST] <philipl> BtbN: *sigh*. Well, you work with what you've got.
[20:41:50 CEST] <JEEB> I would guess since vaapi has egl compatibility there's no problem with vulkan filters there
[20:42:01 CEST] <JEEB> not straight vulkan but at least within VRAM in that case
[20:42:29 CEST] <philipl> vaapi can export.
[20:42:39 CEST] <JEEB> then for nvidia I thought for decoding there was some compatbitiliy, otherwise the gpu renderer wouldn't do crap
[20:43:08 CEST] <philipl> You export a dmabuf and there's a vulkan extension to import it. And a bunch of silliness around describing the memory layout that is only just now sorted out.
[20:44:07 CEST] <philipl> the cuda interop is one way. So I wrote the mpv code to import the buffer (later image) from vulkan and fill it in from the cuda side.
[20:45:31 CEST] <philipl> amusingly/ironically, the cuda EGL interop does appear to let cuda export. It's the only API where they've done that.
[21:36:54 CEST] <philipl> BtbN: That ticket is weird.
[21:36:59 CEST] <philipl> I can't repro. It compiles fine for me.
[21:37:23 CEST] <BtbN> Do you have --enable-cuda-sdk?
[21:37:32 CEST] <philipl> No. Just enable-npp in this case
[21:37:46 CEST] <philipl> But the cuda headers are installed.
[21:37:46 CEST] <BtbN> shouldn't matter anyway
[21:37:49 CEST] <philipl> yeah
[21:37:58 CEST] <philipl> Might be a cuda 10 difference.
[21:38:11 CEST] <BtbN> I upgraded my sdk to cuda 10 now
[21:38:13 CEST] <BtbN> let's try again
[21:44:43 CEST] <BtbN> What's the proper syntax to do this: --extra-cflags='-IC:/Program\ Files/NVIDIA\ GPU\ Computing\ Toolkit/CUDA/v10.0/include'
[21:44:49 CEST] <BtbN> no matter how I try to escape it, it always fails
[21:46:06 CEST] <BtbN> It always splits the arguments on the spaces
[21:46:47 CEST] <philipl> Don't use \ if you are quoting
[21:46:51 CEST] <philipl> One or the other right?
[21:47:02 CEST] <BtbN> The quoting is in my local shell though
[21:47:06 CEST] <BtbN> that part works
[21:47:14 CEST] <BtbN> But configure passes it to cl.exe unquoted
[21:47:37 CEST] <philipl> Well, you're firmly in windows land with that :-P
[21:48:01 CEST] <philipl> I'm about to try on linux with cuda 10 sdk
[21:48:09 CEST] <BtbN> I'll just make a junction at C:\CUDA...
[21:49:54 CEST] <philipl> brute force solution
[22:00:12 CEST] <philipl> BtbN: Replicated problem
[22:00:32 CEST] <philipl> Seems cuda 10 specific.
[22:02:12 CEST] <cone-262> ffmpeg 03Martin Vignali 07master:02ad0416c06e: avfilter/setparams : merge setfield and setrange filter to setparams filter
[22:02:12 CEST] <cone-262> ffmpeg 03Martin Vignali 07master:8d3f364630a8: avfilter/setparam : add options to set color primaries, trc, space
[22:02:56 CEST] <philipl> BtbN: and to add insult to injury, nvcc is complaining that my gcc is too new. requires gcc-7. WTF
[22:03:07 CEST] <JEEB> lol
[22:03:19 CEST] <BtbN> philipl, try replacing the hwcontext_cuda_internal.h include with just hwcontext_cuda.h in... pretty much all cuda filters
[22:03:33 CEST] <BtbN> that seems wrong, the internal means avutil internal
[22:04:12 CEST] <philipl> yeah. I suspect that's it.
[22:04:35 CEST] <tmm1> is there any central place for offering ffmpeg feature bounties?
[22:04:47 CEST] <philipl> BtbN: but it needs internal for cudl functions.
[22:04:59 CEST] <JEEB> tmm1: the thing closest to that is the videolan.org bounties page
[22:05:11 CEST] <philipl> scale_npp doesn't use system cuda headers, but it kinda should, as they're going to be there.
[22:05:20 CEST] <JEEB> although I guess those are for stuff that go through videolan
[22:05:25 CEST] <BtbN> philipl, those don't do dyn-loading
[22:05:31 CEST] <BtbN> and we don't link against -lcuda
[22:05:33 CEST] <JEEB> https://wiki.videolan.org/Bounties
[22:05:34 CEST] <BtbN> so it has to use ffnvcodec
[22:05:59 CEST] <JEEB> tmm1: otherwise FFmpeg specific I don't think we have a bounty page yet
[22:06:13 CEST] <JEEB> could have one on a write-limited trac wiki page, if there's such a thing
[22:06:21 CEST] <philipl> BtbN: Ok. Well, then I need to conditionalise the type declaration?
[22:06:42 CEST] <BtbN> I have no idea, it might be outright impossible to add that type without giving it a different name on our end
[22:07:27 CEST] <BtbN> everything compiles fine on MSVC with CUDA 10 and the _internal removed
[22:08:01 CEST] <BtbN> hm, it just didn't enable the npp stuff, what
[22:08:06 CEST] <BtbN> oh, nvm
[22:12:31 CEST] <philipl> BtbN: I guess I'll just give it a different name then.
[22:12:40 CEST] <philipl> Annoying.
[22:14:22 CEST] <philipl> And I'd have to change the mpv code too. grr.
[22:14:28 CEST] <philipl> but that's not merged yet. OK
[22:14:51 CEST] <BtbN> I'm not a fan of renaming it
[22:15:11 CEST] <philipl> If you can think of an alternative, I'm all ears.
[22:15:35 CEST] <philipl> We could try and separate the declaration from the typedef
[22:15:53 CEST] <philipl> but in this error, it's already complaining the typedef is not the same.
[22:16:08 CEST] <JEEB> at some point I'd like to see people try to push nvidia to make all this mess less of a mess :P
[22:16:21 CEST] <BtbN> This isn't really nvidias fault
[22:16:36 CEST] <JEEB> yes, but the whole reason why we're reinventing headers etc
[22:20:51 CEST] <philipl>  * CUDA UUID types
[22:20:52 CEST] <philipl>  */
[22:20:52 CEST] <philipl> #ifndef CU_UUID_HAS_BEEN_DEFINED
[22:20:52 CEST] <philipl> #define CU_UUID_HAS_BEEN_DEFINED
[22:21:01 CEST] <philipl> They seem to have thought of this.
[22:24:12 CEST] <philipl> BtbN: https://github.com/philipl/nv-codec-headers/commit/136251482c65767c3be28a9014bdeecaa46fcc7c
[22:24:21 CEST] <BtbN> too slow :P
[22:24:28 CEST] <philipl> hah
[22:25:20 CEST] <philipl> Then I'll let you do the honours of closing the ticket
[22:31:32 CEST] <BtbN> The release procedure gets more annoying with nvidia releasing more and more SDK versions
[22:32:38 CEST] <philipl> Well, you can saw sdk 10 requires using the latest sdk
[22:32:41 CEST] <philipl> say
[22:32:53 CEST] <philipl> the cuda sdk 10 driver requirements are stricter than video sdk 8.2
[22:33:11 CEST] <BtbN> That's why all the functions are only optionally loaded
[22:33:20 CEST] <philipl> Yes, but I mean for this bug fix.
[22:33:27 CEST] <philipl> You don't need to fix it on the 8.0 and 8.1 branches
[22:33:35 CEST] <BtbN> I was talking about the now 3 branches I needed to update and release
[22:33:40 CEST] <BtbN> 8.0, 8.1 and 8.2
[22:33:42 CEST] <philipl> That's I'm saying too.
[22:33:55 CEST] <BtbN> I do need to fix it on the 8.0 and 8.1 branches
[22:34:01 CEST] <BtbN> as they all have the CUDA 10 functions
[22:34:13 CEST] <philipl> You backported the cuda 10 functions to all of them?
[22:34:14 CEST] <philipl> AH.
[22:34:37 CEST] <BtbN> The branches are identical, except for the video sdk updates
[22:35:28 CEST] <BtbN> And I think you can still build ffmpeg against the 8.0 one, and get a fairly low driver requirement, at the expense of a few features
[22:36:03 CEST] <philipl> Sure, but that's not done using the cuda 10 sdk - which has high driver requirements.
[22:36:20 CEST] <BtbN> Which is why I wanted it to be optional
[22:36:43 CEST] <philipl> Yes - I'm saying from the other perspective.
[22:36:52 CEST] <philipl> You don't want to require cuda 10 to use the SDK.
[22:37:06 CEST] <philipl> I'm saying you can require the latest 8.2 headers to use cuda 10 features at all.
[22:37:12 CEST] <philipl> ie: never backport the cuda 10 stuff
[22:37:37 CEST] <BtbN> eh, unless they go completely ham, I'll just keep doing it like that
[22:37:43 CEST] <philipl> ok
[22:38:14 CEST] <BtbN> If it gets too wild, I'll probably follow nvidias driver legacy versions
[22:38:22 CEST] <BtbN> keeping only SDKs that enable support for legacy cards
[22:58:00 CEST] <cone-262> ffmpeg 03Timo Rothenpieler 07master:2797bd5c81eb: avfilter/*_cuda: don't include internal header
[00:00:00 CEST] --- Mon Oct 22 2018