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

[burek]

[03:18:24 CEST] <cone-053> ffmpeg 03Jun Zhao 07master:0a347ff42223: lavf/matroskaenc: Fix memory leak after write trailer
[04:03:34 CEST] <jamrial> half the fate clients haven't yet synced the new sample, so it all looks very yellow
[13:19:03 CEST] <nevcairiel> its been three days and some fate clients still lack a sample?
[13:19:12 CEST] <nevcairiel> are they using a different sample source or some other nonsense?
[15:30:25 CEST] <cone-424> ffmpeg 03Carl Eugen Hoyos 07master:d6a8392224c0: lavf/movenc: Pass correct pointer to av_log().
[15:50:08 CEST] <cone-424> ffmpeg 03Tristan Matthews 07master:1ec777dcdd03: avformat/matroskaenc: fix leak on error
[17:12:54 CEST] <cone-424> ffmpeg 03Jeremy Dorfman 07release/4.1:420fe39aff3d: avformat/av1: Initialize padding in ff_isom_write_av1c
[17:12:55 CEST] <cone-424> ffmpeg 03Tristan Matthews 07release/4.1:cf7a5c655c04: avformat/matroskaenc: fix leak on error
[18:50:14 CEST] <philipl> BtbN: well, that was a generally unhelpful response re nvenc.
[18:51:14 CEST] <BtbN> What they propose is not really sensible possible in the context of ffmpeg
[18:51:25 CEST] <BtbN> It is if you embed nvenc into an application
[18:57:10 CEST] <philipl> Worst case you add some flag to indicate you're using it with a fixed frame pool and don't need to unregister every time?
[19:12:41 CEST] <nevcairiel> that seems like a rather hacky option
[19:13:21 CEST] <philipl> It is. Maybe it can be detected? I have not thought hard about it.
[19:13:23 CEST] <nevcairiel> before doing anything I would definitly try to get nvidia to comment on it
[19:13:36 CEST] <philipl> the nvidia guys said don't unregister until you free the frame.
[19:13:39 CEST] <philipl> which we can't really do.
[19:15:21 CEST] <nevcairiel> does this problem apply to cuda input, software input, or both?
[19:16:54 CEST] <philipl> The 'problem' is that unregistering after unmap (when the buffer is actually going to be reused) causes a throughput bottleneck in nvenc. That applies to every scenario, although it's only detectly in extreme parallel encoding situations.
[19:17:07 CEST] <philipl> s/detectly/detectable/
[19:17:32 CEST] <philipl> The guy in the ticket has three big quadroos and wants to do 60 parallel encodes on one system for whatever reason.
[19:17:55 CEST] <nevcairiel> 60 encodes doesnt seem like it would run any faster then 2x 30 encodes in series
[19:18:17 CEST] <philipl> Depending on the exact pipeline setup, there may be a fixed buffer pool being reused all the time, in which case delayed unregistration is fine.
[19:18:34 CEST] <philipl> Or there may be buffers getting deallocated and newly allocated each time, in which case it is not fine.
[19:18:44 CEST] <philipl> I'm not sure which pipelines are which.
[19:18:54 CEST] <philipl> nevcairiel: and yes, one would asssume that is so if full utilisation occurs.
[19:21:44 CEST] <nevcairiel> even the big quadro cards dont have more encoding resources. some get a second nvenc engine, and thats it, afaik?
[19:22:35 CEST] <philipl> They may have an additional engine, but nvidia also lifts the artifical limit on the number of parallel encodes on a single engine.
[19:22:50 CEST] <nevcairiel> you can lift that with mild driver hacking on c onsumer cards too
[19:23:10 CEST] <philipl> I don't know how silly this guy's scenario is (but I have suspicions), but it is true that the official nvidia recommendation is not to unregister all the time. It's relatively expensive and they don't consider that a bug.
[19:23:37 CEST] <nevcairiel> our architecture doesnt really allow anything else and still feeling "clean" tho
[19:24:08 CEST] <nevcairiel> I wonder what happens if you dont unregister and then dont use a fixed pool
[19:24:35 CEST] <philipl> Presumably some sort of resource leak that eventually leads to errors the next time you try to register.
[19:25:16 CEST] <nevcairiel> thats the only place we unregister, isn't it? so the pool is never unregistered, and presumably if you make enough pools or something, it might also result in that?
[19:25:57 CEST] <nevcairiel> or maybe nvenc cleans it up when the session is closed
[19:27:18 CEST] <philipl> I would hope so. Presumably someone could use a custom pool implementation that actually did full allocations and deallocations (rather than maintaining a pool) and that would create the pathological scenario?
[19:27:22 CEST] <nevcairiel> tying that to the frames lifetime would be ideal, but alas we can't exactly have encoders messing with the incoming avframe
[19:28:08 CEST] <philipl> I asked BtbN if we could register a deallocation hook, but that requires keeping the nvenc alive - unless we convince ourselves that closing the session cleans things up and then we just need a weak reference.
[19:28:13 CEST] <philipl> Still messy, but not crazy.
[19:28:52 CEST] <philipl> We sort of do this on the decoder side where frames are owned by the encoder and returned via a custom pool. The frames hold a decoder ref.
[19:29:14 CEST] <philipl> but in that case the decoder is the actual allocator.
[19:29:27 CEST] <philipl> s/encoder/decoder/
[19:30:46 CEST] <BtbN> That's done via a custom deallocator in the buffer pool
[19:30:54 CEST] <BtbN> nvenc can't do that, since it's not allocating the frames
[19:31:22 CEST] <philipl> We'd need to add a new buffer pool mechanism for generic deallocation callbacks.
[19:32:15 CEST] <BtbN> Which would actually need to be attached to the internal buffer pool, not to the frame
[19:32:20 CEST] <BtbN> since the frame _does_ get freed eventually
[19:32:24 CEST] <BtbN> the underlying buffer does not
[19:33:50 CEST] <philipl> Yes.
[19:41:52 CEST] <siperman> hello
[19:42:19 CEST] <siperman> someone can help applying a patch to solve an issue to ffmpeg
[19:42:20 CEST] <siperman> ?
[19:45:06 CEST] <Kwiboo> philipl: I added get+release callbacks for buffer pool in https://github.com/Kwiboo/FFmpeg/commit/42e3ab0b889a736fcbbdb50086b1a64584438d43 when I was looking for a resource leak in my v4l2 request api hwaccel + kodi, not sure if something like that is what you had in mind with mechanism for generic deallocation callbacks
[19:46:36 CEST] <philipl> Kwiboo: it's not quite that. We would need to attach a callback from a frame consumer (the nvenc encoder) that would fire when the buffer was eventually deallocated (and not when the frame is freed)
[19:46:46 CEST] <philipl> So it's not something you set up at bool init time.
[19:46:55 CEST] <philipl> s/bool/pool/
[19:49:50 CEST] <Kwiboo> philipl: I see, a little bit more complex scenario
[20:00:45 CEST] <siperman> hello
[20:02:46 CEST] <siperman> i have a problem with Inconsistent UDP output packet size
[20:02:53 CEST] <siperman> can someone help me
[20:02:54 CEST] <siperman> ?
[23:17:45 CEST] <cone-114> ffmpeg 03Jarek Samic 07master:1c50d61a5a68: libavutil/hwcontext_opencl: Fix channel order in format support check
[00:00:00 CEST] --- Wed Apr 10 2019