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

[burek]

[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