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

[burek]

[03:00:35 CEST] <jamrial> Chagall: ping the patches on the ml. devs in general don't look at patchwork
[03:28:07 CEST] <Chagall> jamrial: I did it once and got no answer, but will try one more time...
[13:55:55 CEST] <thardin> is there a compile-time constant for maximum Y res?
[13:58:57 CEST] <thardin> I only see INT_MAX, which seems excessive
[14:00:28 CEST] <thardin> nm, UINT16_MAX works well enough in this case
[14:16:41 CEST] <vel0city> durandal_1707: Maybe because of the post processing it does, or just the the colorspace transformation
[15:06:06 CEST] <kierank> thardin: we need to be able to handle Hubble telescope resolution
[15:06:41 CEST] <JEEB> that reference reminds me of https://www.youtube.com/watch?v=JRLVFn9z0Gc
[15:08:00 CEST] <thardin> kierank: I don't think even the hubble outputs that large frames
[15:08:37 CEST] <kierank> JEEB: I am slightly obsessed by that photo
[15:08:44 CEST] <kierank> Having seen an nrol launch
[15:08:51 CEST] <thardin> 65536x65536 isn't entirely outside the range of possibilities
[15:09:22 CEST] <thardin> not in cinepak however, which caps at 65535x65535
[15:09:53 CEST] <thardin> which means I save on a dynamic allocation
[15:10:50 CEST] <JEEB> kierank: fun :)
[15:15:56 CEST] <thardin> there we go, header and strip parsing refactored
[15:16:27 CEST] <thardin> michaelni_: I've made cinepak.c sanity check the size of each strip (which depends on mode)
[15:17:03 CEST] <thardin> and this parsing is separated from the actual decoding, so it should be nice and fast
[17:13:12 CEST] <Lynne> any way to reset some hwcontext-specific avframe state when a frame is being resued?
[17:18:51 CEST] <Lynne> else I'm left with a stale semaphore from the last frame that has no way to be signalled
[21:24:21 CEST] <Lynne> if anyone wants to test 5000 lines of vulkan apply  https://0x0.st/z4IJ.patch and https://0x0.st/z4Iy.patch
[21:25:13 CEST] <Lynne> will work on amd, does have vaapi/drm interop, and has the fastest avgblur shader ever writter
[21:25:43 CEST] <JEEB> nice
[21:45:08 CEST] <durandal_1707> Lynne: what is fps of shader?
[21:48:21 CEST] <durandal_1707> compared to cpu one
[21:59:01 CEST] <Lynne> durandal_1707: its not a fair comparison, but at 9x9 it gets 266 fps on CPU, ~110 on a 960m with just an upload, no download, 35 fps on an intel with mapping from vaapi, no download
[22:05:50 CEST] <durandal_1707> Lynne: what resolution?
[22:06:22 CEST] <Lynne> 1280x720, 8 threads for cpu
[22:07:48 CEST] <durandal_1707> if you cant make stupid avgblur faster than cpu than all is lost
[22:09:17 CEST] <Lynne> yeah, nevermind about the fastest avgblur shader ever written, opencl gets 500 fps on the 960m, I still need to optimize it
[22:09:21 CEST] <durandal_1707> or you use crappy gpu
[22:10:22 CEST] <Lynne> such a shame, the way it handled overlap with so little branches and 2*radius lookups max per instance was clever
[22:14:31 CEST] <BradleyS> nice work :)
[22:15:01 CEST] Action: BradleyS throws something at durandal_1707
[22:16:48 CEST] Action: durandal_1707 evades BradleyS hit
[22:18:22 CEST] <BradleyS> i underestimated your dexterity stat
[00:00:00 CEST] --- Mon Sep  2 2019