[00:06:43 CEST] <c3r1c3-Win> I have not heard ANYTHING about them moving to h.264. Given the recet release of their 3.5 SDK I would be greatly surprised if they did. [00:09:31 CEST] <c3r1c3-Win> Also there's not really much to reverse engineer. They're following certain standards (Zeroconf+SpeedHQ+TCP/IP+Some others) so there really isn't much (if anything) to reverse engineer. [00:13:33 CEST] <kierank> they have some homemade encryption [00:13:37 CEST] <kierank> and framing [02:12:38 CEST] <cone-039> ffmpeg 03Michael Niedermayer 07master:7719b8ccc790: avcodec/magicyuv: Check bits left in flags&1 branch [02:12:38 CEST] <cone-039> ffmpeg 03Michael Niedermayer 07master:d25c94524797: avcodec/h264_parser: Reduce needed history for parsing mb index [02:31:02 CEST] <kierank> This fixes a bug/regression with very small packets [02:31:02 CEST] <kierank> Fixes: output_file [02:31:03 CEST] <kierank> wow [02:31:07 CEST] <kierank> such helpful [08:08:04 CEST] <cone-043> ffmpeg 03Steven Liu 07master:387464bea5bd: from RTCTIME to N*23, step is 23 fix ticket: 7225 [10:51:37 CEST] <haasn> atomnuker: is it intended that your ffmpeg vulkan filter code stalls the pipeline on every upload? [10:52:18 CEST] <haasn> also if that's your intent, you're probably better off not bothering with the COMPUTE/TRANSFER qfs and just using GRAPHICS for the upload always [11:06:53 CEST] <atomnuker> stalls the queue? as in waiting for the fence [11:08:08 CEST] <haasn> yeah [11:08:16 CEST] <haasn> you dispatch an upload and then wait for it to complete before doing anything else [11:08:24 CEST] <haasn> during which time the GPU could be doing useful work [11:08:39 CEST] <haasn> also the transfer queues (DMA engine) are generally slower than uploading directly from the graphics queue [11:08:52 CEST] <haasn> they only exist _because_ they can run at the same time as the GPU is doing work [11:09:19 CEST] <haasn> you also stall on the download, so it's pretty much the worst case scenario [11:09:29 CEST] <haasn> I think you can even run the upload and the download simultaneously, in theory [11:09:42 CEST] <atomnuker> you can't not stall on download, can you? [11:09:45 CEST] <haasn> so you can download frame 0, filter frame 1 and upload frame 2 at the same time [11:09:47 CEST] <haasn> sure you can [11:10:00 CEST] <haasn> dispatch the download ahead of time, then do useful work in the meantime [11:10:07 CEST] <haasn> well maybe not for ffmpeg's filter design [11:10:23 CEST] <haasn> if ffmpeg expects filters to produce output in lockstep before it will give you more frames then you have to stall on the download [11:10:53 CEST] <haasn> in e.g. mpv's filter chain you can receive multiple frames before producing one frame of output [11:11:44 CEST] <atomnuker> you can do that here too, but there's no way to inform other parts of the code when a frame's ready, its always assume to be completed by the time its given off to non-hardware filters [11:11:56 CEST] <atomnuker> *assumed [11:14:19 CEST] <haasn> right, you'd have to maintain your own download queue [11:14:24 CEST] <haasn> and only hand them off once the fence passes [11:14:34 CEST] <haasn> blocking in case the queue would get too long [11:15:32 CEST] <haasn> it depends on the filter though [11:16:09 CEST] <haasn> for a filter that's primarily bottlenecked on PCIe bandwidth (e.g. RGB->YUV conversion or something simple like that) the difference will probably be moot [11:16:22 CEST] <haasn> since the amount of "useful work" you're missing out on amounts to a few µs at best per frame [11:16:42 CEST] <haasn> but for something like a more involved compute shader you'd definitely be wasting a lot of GPU power by waiting on transfers [11:37:14 CEST] <atomnuker> wouldn't be that much though, you have to block somewhere, at most you can move the blocking to the next time you submit a command queue for execution [11:43:42 CEST] <haasn> atomnuker: blocking and pipeline stalls are not the same thing [11:44:14 CEST] <haasn> pipeline stall = blocking when you have too little work queued for the GPU to be fully loaded [11:44:50 CEST] <atomnuker> oh, right [11:47:40 CEST] <atomnuker> haasn: so the correct way to deal with this would be to use per-frame semaphores on which to wait/signal during queue submissions, and only use a single fence at the end when you download (because there's no other choice here) [12:49:12 CEST] <haasn> atomnuker: yeah, or events (if they're on the same queue family) [12:49:20 CEST] <haasn> s/queue family/queue/ [12:49:35 CEST] <haasn> although in your case just a pipeline barrier would be enough in the single-queue case [12:52:05 CEST] <atomnuker> events? but you can't submit anything other than semaphores in VkSubmitInfo [12:52:48 CEST] <atomnuker> oh, you'd do that via a command [12:53:45 CEST] <atomnuker> semaphores would be cleaner here, we don't have complex multistage commands, just usually a single shader [12:54:18 CEST] <atomnuker> btw did moltenvk get support for events? [12:55:49 CEST] <haasn> I mean events are cheaper than semaphores [12:55:51 CEST] <haasn> and no [12:55:59 CEST] <haasn> semaphores require splitting your stuff into separate command buffers [12:56:09 CEST] <haasn> in fact I'd argue that semaphores are precisely what you need for "complex multistage commands" [12:56:18 CEST] <haasn> oh wait you mean -within- a buffer [12:56:21 CEST] <haasn> yeah fine [13:43:48 CEST] <atomnuker> yeah, each filter has its own command queue [13:44:23 CEST] <atomnuker> didn't know events were cheaper then semaphores, I though it would be the other way around [13:45:05 CEST] <atomnuker> since events are more flexible and can occur at any point in any command buffer [13:57:44 CEST] <haasn> command buffer scheduling is pretty expensive [13:57:48 CEST] <haasn> cheaper to have one big command buffer [13:57:53 CEST] <haasn> than many little small ones [20:51:36 CEST] <jamrial> whoa, libaom 1.0.0 [20:53:21 CEST] <JEEB> yup [20:53:39 CEST] <jamrial> is the library stable enough for this? [20:54:16 CEST] <jamrial> one thing is codec bitstream freeze, another is the reference encoder being stable for such a release [20:54:26 CEST] <JEEB> that's a good question [20:54:42 CEST] <BBB> were there stability issueS? [20:54:56 CEST] <jamrial> no idea, just wondering [20:55:21 CEST] <jamrial> i at least see a couple open issues reporting assertion failures and valgrind stuff [20:56:15 CEST] <jamrial> i'm going to bump the required version for the wrapper so we stop creating broken files, but will not remove the experimental flag for now [20:57:10 CEST] <atomnuker> BBB: MAKE [20:58:17 CEST] <BBB> <3 [20:59:14 CEST] <gnafu> :-o :-D [21:02:49 CEST] <January> atomnuker: rav1e tho [21:10:24 CEST] <atomnuker> decoder, not encoder [21:40:46 CEST] <thardin> ffav1 or xav1? [21:41:16 CEST] <gnafu> thardin: ffav1 for decoding, rav1e for encoding ;-). [21:41:32 CEST] <gnafu> Or EVE, I suppose. Right, BBB? [21:44:03 CEST] <January> atomnuker: time for rav1d then [21:44:52 CEST] <nevcairiel> thats what we call ffav1 =p [21:45:37 CEST] <January> nevcairiel: but ffav1 isnt rust [21:45:48 CEST] <Compn> our next codec needs to be uck... :P [21:45:56 CEST] <nevcairiel> January: and thats a bonus [21:46:06 CEST] <January> :d [21:53:16 CEST] <cone-357> ffmpeg 03James Almer 07master:a0ac49e38ee1: configure: bump minimum required version of libaom [21:53:31 CEST] <j-b> Can we do it in JS and then transpile it to C? :D [21:53:44 CEST] <haasn> ffav1 is dangerously close to ffv1 [21:54:25 CEST] <gnafu> j-b: I don't see why not. [21:54:43 CEST] <gnafu> I suspect it would get a lot more attention on HN than a regular ol' C version. [21:54:47 CEST] <nevcairiel> ffav1 is not actually a name we use [21:54:53 CEST] <nevcairiel> it would just be called "av1" [21:55:02 CEST] <j-b> to be sure to confuse it with av1 [21:55:05 CEST] <j-b> avi [22:01:29 CEST] <atomnuker> January: its not a bad thing; rust sucks [22:02:02 CEST] <j-b> Is the MP4/AV1 spec frozen or not yet? [22:02:54 CEST] <atomnuker> ff<codec> is just something people use to refer to ffmpeg implementations of codecs, I'm not aware of anyone using it for containers, let alone av1 [22:03:00 CEST] <atomnuker> erm *avi [22:47:43 CEST] <cone-357> ffmpeg 03Mark Thompson 07master:bd02b2c05df1: lavfi/vf_tonemap_opencl: Mark local tables static [22:47:44 CEST] <cone-357> ffmpeg 03Mark Thompson 07master:e7c0b44e747b: lavf/mpjpegdec: Mark local variable static [23:08:43 CEST] <cone-357> ffmpeg 03Michael Niedermayer 07master:6677c9862648: avcodec/escape124: Check buf_size against num_superblocks [23:08:44 CEST] <cone-357> ffmpeg 03Michael Niedermayer 07master:84bbdc255a12: avcodec/ffv1dec: Check state transition table [23:08:45 CEST] <cone-357> ffmpeg 03Michael Niedermayer 07master:78167b498f53: avcodec/cscd: Check output buffer size for lzo. [00:00:00 CEST] --- Tue Jun 26 2018