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

[burek]

[00:14:20 CEST] <rcombs> is there a reason nvenc isn't FF_CODEC_CAP_INIT_THREADSAFE
[00:37:40 CEST] <cone-556> ffmpeg 03Paul B Mahol 07master:ccaeabd092d3: avfilter/vf_v360: fix fov calculation for stereographic output
[00:37:41 CEST] <cone-556> ffmpeg 03Paul B Mahol 07master:f705dc9a7453: avfilter/vf_v360: increase h_fov max limit
[00:37:42 CEST] <cone-556> ffmpeg 03Paul B Mahol 07master:0f0f5188acc6: avfilter/vf_v360: remove w/h changing for flat output
[00:38:48 CEST] <Lynne> durandal_1707: forgot to git add; here's working patches: https://0x0.st/zJls.patch https://0x0.st/zJlf.patch
[00:39:33 CEST] <durandal_1707> scared to use website with git?
[00:44:03 CEST] <Lynne> I'm just lazy, but a git repo woulnd't help at the rate I'm rewriting the commits
[03:53:53 CEST] <cone-446> ffmpeg 03Aman Gupta 07master:ab4835f41885: avcodec/v4l2_m2m_enc: add support for -force_key_frames
[03:53:53 CEST] <cone-446> ffmpeg 03Aman Gupta 07master:ac52e06e56fd: avcodec/v4l2_m2m: disable info logging during device probe
[03:53:53 CEST] <cone-446> ffmpeg 03Aman Gupta 07master:7bb6898b16f3: avcodec/v4l2_m2m: fix av_pix_fmt changing when multiple /dev/video* devices are probed
[03:57:22 CEST] <cone-446> ffmpeg 03Dave Stevenson 07master:d61cf1b1ebc2: avcodec/v4l2_buffers: Add handling for NV21 and YUV420P
[04:11:21 CEST] <philipl> Lynne: I can try and look over an updated patch. It's also possible something is buggy. The testing they do of this stuff is clearly questionable - remembering that the VkImage interop launched completely broken, and I had a fun time tracking down someone to report the bug through.
[04:17:03 CEST] <cone-446> ffmpeg 03Aman Gupta 07master:c0c794619671: avcodec/v4l2_m2m: decouple v4l2_m2m helpers from AVCodecContext
[04:17:04 CEST] <cone-446> ffmpeg 03Lukas Rusak 07master:f9b0f88aa471: avcodec/v4l2_m2m_dec: fix indentation and add M2MDEC_CLASS macro
[04:17:05 CEST] <cone-446> ffmpeg 03Aman Gupta 07master:84540b2b847c: avcodec/v4l2_m2m_enc: fix indentation and add M2MENC_CLASS macro
[04:17:06 CEST] <cone-446> ffmpeg 03Aman Gupta 07master:b3b958c19e30: avcodec/v4l2_buffers: teach ff_v4l2_buffer_avframe_to_buf about contiguous planar formats
[04:17:07 CEST] <cone-446> ffmpeg 03Aman Gupta 07master:2b21bb4a87cb: avcodec/v4l2_buffers: split out AVFrame generation into helper method
[04:17:08 CEST] <cone-446> ffmpeg 03Aman Gupta 07master:d620b1f9de57: avcodec/v4l2_buffers: split out V4L2Buffer generation into helper method
[04:17:09 CEST] <cone-446> ffmpeg 03Lukas Rusak 07master:40a433e34b3e: avcodec/v4l2_buffers: split out v4l2_buf_increase_ref helper
[04:25:30 CEST] <Lynne> philipl: actually don't yet, there's a problem with my semaphores
[04:26:19 CEST] <Lynne> I destroy them (checking if they're NULL ofc) on every memcpy, but that's causing the next push call to hang
[04:26:34 CEST] <Lynne> if I let them leak its fine
[04:27:45 CEST] <Lynne> I need to call cuSignalExternalSemaphoresAsync right after the 2d memcpys, right?
[04:33:00 CEST] <cone-446> ffmpeg 03Lynne 07master:6b22e28f4c85: opusdsp: adjust and optimize C function to match assembly
[04:33:08 CEST] <cone-446> ffmpeg 03Lynne 07master:4ce1e13b5465: checkasm: add opusdsp tests
[04:49:04 CEST] <cone-446> ffmpeg 03Jun Zhao 07master:44b55a8c9c87: lavfi/anequalizer: fix memory leak in error handling path
[04:49:05 CEST] <cone-446> ffmpeg 03Jun Zhao 07master:944d76a3e056: lavfi/sinc: fix memory leak in error handling path
[05:07:36 CEST] <philipl> Lynne: yes, after the copy. You want to create the semaphores (one for signalling the write to vulkan and one signalling the read completion back to cuda) when you export the frame and keep the semaphores around for the remainder of the frame lifetime.
[05:07:45 CEST] <philipl> That's all part of minimising the expensive operations.
[05:08:31 CEST] <philipl> I suspect that if you destroy a semaphore after signalling, but before the signal is acknowledged, you'd get the hang.
[05:10:55 CEST] <philipl> haasn implemented a particular pattern in libplacebo around this where you explicitly hand-off and take back images to the external API and that ensures the semaphores are signalled and awaited at the right times.
[05:11:28 CEST] <philipl> So you could do a bunch of operations in vulkan and then export the image, so you only signal once, and then can immediately await on the cuda side.
[05:16:31 CEST] <haasn> 05:08 <philipl> I suspect that if you destroy a semaphore after signalling, but before the signal is acknowledged, you'd get the hang. <- haven't double checked but this sounds quite bad
[05:18:28 CEST] <haasn> we refcount semaphores in libplacebo and only release them once the last operation using them is fully completed
[05:18:48 CEST] <haasn> but I think if you import the semaphore into libplacebo, that would probably create an internal copy in the driver
[05:18:57 CEST] <haasn> so it might be enough that libplacebo is still holding on to it
[06:15:55 CEST] <philipl> haasn: to clarify, I meant the cuda side of that. I'm not making a statement about just dealing with the semaphore in vulkan.
[13:37:40 CEST] <thardin> whups, ibc is this weekend not in like two weeks
[13:40:27 CEST] <kierank> lol
[13:40:32 CEST] Action: kierank in amsterdam
[13:44:48 CEST] <thardin> noice
[14:56:58 CEST] <j-b> me too
[15:14:30 CEST] <cone-164> ffmpeg 03Paul B Mahol 07master:cb41c2af92f2: avfilter/vf_v360: really fix FoV selection
[15:14:30 CEST] <cone-164> ffmpeg 03Paul B Mahol 07master:783ea9c1c519: avfilter/vf_v360: extend max limit to vertical fov
[15:26:50 CEST] <cone-164> ffmpeg 03Andriy Gelman 07master:78b86c30d386: avcodec/h2645_parse: simplify memset call
[16:25:46 CEST] <cone-164> ffmpeg 03Paul B Mahol 07master:7ce7002664fb: avfilter/vf_v360: refactor FoV calculation for stereographic
[16:45:22 CEST] <cone-164> ffmpeg 03Paul B Mahol 07master:efc73b13ac39: avfilter/vf_v360: remove pointless special case when allocating stuff
[18:27:45 CEST] <durandal_1707> Lynne: did you broke fate?
[18:30:47 CEST] <mkver> According to http://fate.ffmpeg.org/, no.
[18:58:06 CEST] <Lynne> that reminds me, could people run ./tests/checkasm/checkasm  --test=opusdsp --bench on a non-skylake cpu?
[18:59:32 CEST] <Lynne> the deemphasis function was tricky to order, a single "noop" reorder in operations and you get 20k+ decicycles per execution
[19:00:56 CEST] <tmm1> is my understanding of pkt_dts in https://patchwork.ffmpeg.org/patch/14877/ correct?
[19:01:08 CEST] <Lynne> on both my CPUs I get around ~8.5x speedup
[19:40:24 CEST] <cone-164> ffmpeg 03Aman Gupta 07master:8dc973dc8919: avcodec/v4l2_buffers: read height/width from the proper context
[19:40:25 CEST] <cone-164> ffmpeg 03Aman Gupta 07master:3475758a3791: avcodec/v4l2_m2m_dec: set pkt_dts on decoded frames to NOPTS
[19:40:26 CEST] <cone-164> ffmpeg 03Aman Gupta 07master:fac834b2ae0b: avcodec/v4l2_context: expose timeout for dequeue_frame
[19:40:27 CEST] <cone-164> ffmpeg 03Maxime Jourdan 07master:584ac1ad0bb5: avcodec/v4l2_m2m_dec: fix dropped packets while decoding
[20:16:41 CEST] <mkver> jkqxz: Mark, if one wants to add a user data unregistered SEI in h264_metadata and the call to ff_cbs_h264_add_sei_message fails, the allocated buffer (with the string) will leak. One could either add code to fix this in h264_metadata or in ff_cbs_h264_add_sei_message. I prefer the latter (one can then simply call cbs_h264_free_sei_payload). What do you think?
[20:21:26 CEST] <mkver> tmm1: Your recent patches broke compilation.
[20:22:18 CEST] <mkver> See e.g. http://fate.ffmpeg.org/log.cgi?time=20190911181643&slot=aarch64-linux-gcc-7.3.0&log=compile
[20:31:16 CEST] <cone-164> ffmpeg 03Aman Gupta 07master:80c9237b2f9a: avcodec/v4l2_m2m_dec: fix compile
[20:33:40 CEST] <tmm1> thx for heads up
[22:08:55 CEST] <cone-164> ffmpeg 03Aman Gupta 07master:0085c4d47856: avcodec/v4l2_buffers: use correct timebase for encoder/decoder
[22:08:56 CEST] <cone-164> ffmpeg 03Maxime Jourdan 07master:b81a1c5bea34: avcodec/v4l2_context: set frame SAR using VIDIOC_CROPCAP
[23:31:24 CEST] <Lynne> philipl: could you check https://0x0.st/zJdt.patch https://0x0.st/zJdv.patch for what I'm missing that's causing the hangs?
[23:31:51 CEST] <Lynne> error handling and cleanup is done, that's the only thing left for the hwcontext I can think of
[23:33:00 CEST] <Lynne> not sure what's left to do with the filters and the abstractions either
[23:34:24 CEST] <Lynne> there's still vf_overlay_vulkan that I've ignored but I don't want to have to deal with pixel format conversions there now
[00:00:00 CEST] --- Thu Sep 12 2019