[00:50:15 CET] <cone-641> ffmpeg 03Andreas Rheinhardt 07master:3f086a2f665f: avcodec/mpeg4videodec: Fix nonsense warning [00:50:15 CET] <cone-641> ffmpeg 03Michael Niedermayer 07master:d227ed5d5983: avcodec/mpeg4videodec: Check idx in mpeg4_decode_studio_block() [08:52:06 CET] <buhman> I was looking at https://github.com/ammen99/wf-recorder , and it seems like wlr-screencopy-v1 should just be implemented in ffmpeg, and exposed via `-f wlr-screencopy-v1` [08:53:00 CET] <buhman> would a well-written patch to add that be accepted, or is that considered "too new"? [08:57:51 CET] <JEEB> buhman: if it's a stable API and you add proper configure checks etc I don't see any reason WhyNot? [08:58:04 CET] <JEEB> without looking what that screen capture API is, of course [08:58:35 CET] <buhman> sure; seems like a fun project [09:03:26 CET] <JEEB> also talking of libavdevice, do any modules there use the "packed AVFrame" stuff? [09:04:18 CET] <JEEB> since stuffing raw video into AVPacket never felt too great since you couldn't put all of the colorspace info there [09:05:10 CET] <JEEB> ah, in avformat at least y4m encoder uses AV_CODEC_ID_WRAPPED_AVFRAME [09:06:02 CET] <JEEB> and the vapoursynth "demuxer" uses it as input [09:06:10 CET] <JEEB> surprising how few libavdevices use it, though [09:06:13 CET] <JEEB> (for input) [09:06:31 CET] <JEEB> oh, kmsgrab does :D [18:15:33 CET] <nevcairiel> jamrial: didn't we remove the block on tree vectorize some time ago? I added it to my own extra cflags at that point after all. [18:16:01 CET] <jdarnley> I recall it was allowed for a time [18:16:08 CET] <jdarnley> Then bogs like that came in [18:16:20 CET] <jdarnley> and the block was restored [18:16:21 CET] <durandal_1707> it is still not disabled for clang [18:16:38 CET] <nevcairiel> I think it's still allowed because bikeshedding [18:17:15 CET] <nevcairiel> Oh yeah and definitely only was GCC [18:18:56 CET] <jamrial> nevcairiel: we removed it but then readded it because gcc still generated crap code with it [18:19:07 CET] <nevcairiel> Apparently it is disabled now yeah [18:19:23 CET] <nevcairiel> But not for clang which the report is using [18:19:26 CET] <jamrial> and yeah, now that you mention it, -fno-tree-vectorize is checked for gcc only [18:19:43 CET] <jamrial> does that flag work with clang? [20:12:09 CET] <Gramner> is DECLARE_ALIGNED supposed to be part of the public API? including avformat.h redefines that macro if the code contains a macro with that name [20:12:48 CET] <Gramner> feels like it should either have an appropriate prefix or not be exposed in public headers [20:14:11 CET] <jamrial> it's not meant to be public [20:15:54 CET] <jamrial> no wait, mem.h, so looks like it is [20:17:50 CET] <jamrial> and yeah, it could use a prefix [20:21:41 CET] <Gramner> same goes for DECLARE_ASM_ALIGNED and DECLARE_ASM_CONST. I'm not sure the value of having those public [22:50:23 CET] <atomnuker> holy shit an aacenc patch from someone with an apple email [22:51:05 CET] <nevcairiel> I don't see anything [22:51:20 CET] <atomnuker> http://ffmpeg.org/pipermail/ffmpeg-devel/2019-March/240867.html [22:51:49 CET] <nevcairiel> Oh that old one [22:51:56 CET] <atomnuker> also >made with git 2.20.1.windows.1 [22:52:33 CET] <nevcairiel> Mac.com is available for anyone, in case you're thinking he is an employee [22:52:52 CET] <nevcairiel> It's iCloud email [22:53:26 CET] <atomnuker> oic [22:53:55 CET] <atomnuker> I always thought mac.com was a fan website (or was at some point) but it redirects to apple [22:59:38 CET] <j-b> Oliver is really cool. [23:24:41 CET] <cone-280> ffmpeg 03James Almer 07master:dcf64b599d31: avcodec/libdav1d: route dav1d internal logs through av_log() [23:24:41 CET] <cone-280> ffmpeg 03James Almer 07master:2a31bf2a3507: avcodec/libdav1d: move the pix_fmt enum array up in the file [23:24:41 CET] <cone-280> ffmpeg 03James Almer 07master:28746a0e2088: avcodec/libdav1d: use a custom picture allocator [23:24:41 CET] <cone-280> ffmpeg 03James Almer 07master:36bb2cc200d0: avcodec/libdav1d: consistently use AVERROR return values [23:24:51 CET] <jamrial> nevcairiel: ^ [23:25:54 CET] <jamrial> the buffer pool based allocator should give it a slight boost, similar to how it would be once and if it gets ported as native decoder using get_buffer2 [23:32:35 CET] <atomnuker> I wonder why intel are not trying to add their av1 encoder to lavc as a wrapper, since they're trying to get their hevc one in [23:33:35 CET] <jamrial> not mature enough? [23:34:38 CET] <TD-Linux> also very nearly the same api, so once they get the hevc one through review they can copy paste [23:45:53 CET] <cone-280> ffmpeg 03Vittorio Giovara 07master:38a413213216: libdav1d: Add support for reading hdr10 metadata [23:45:54 CET] <cone-280> ffmpeg 03James Almer 07master:f6803cfbd2d7: avcodec/libdav1d: unref the frame on failure [23:46:05 CET] <jamrial> nevcairiel: color metadata ^ [23:49:08 CET] <BBB> woohoo dav1d patches [23:49:30 CET] <nevcairiel> neat jamrial [23:49:31 CET] <BBB> the sad thing is that "ffdav1d" is not faster than tools/dav1d b/c of the bufferpool [23:49:43 CET] <BBB> s/not/now/ [23:49:46 CET] <nevcairiel> heh [23:49:49 CET] <BBB> (wow that was freudian) [23:49:55 CET] <BBB> sorry [23:50:06 CET] <BBB> let me restate that just so it's clear: [23:50:12 CET] <nevcairiel> we like being faster [23:50:20 CET] <BBB> the sad thing is that "ffdav1d" is now faster tha tools/dav1d b/c of the bufferpool [23:50:30 CET] <BBB> maybe tools/dav1d needs a bufferpool also ;) [23:50:32 CET] <nevcairiel> is the dav1d executable assumed to even get any real world use? [23:50:54 CET] <BBB> no, but if it helps cheat performance tests I'm happy [23:51:05 CET] <BBB> I guess we can also just use ffmpeg -c:v libdav1d [23:51:29 CET] <jamrial> google uses it for something, seeing they requested annex-b support for it [23:53:36 CET] <nevcairiel> i'll update my ffmpeg copy tomorrow and pull in dav1d instead of aom [23:54:08 CET] <jamrial> and a buffer pool in dav1d would not be cli exclusive. it would benefit any library user that doesn't implement their own allocator [23:55:50 CET] <atomnuker> nevcairiel: I don't think you can disable the libaom decoder and its always that one which gets chosen by default [23:56:40 CET] <nevcairiel> i can build without aom =P [23:57:34 CET] <jamrial> you sure can disable it. and it get chosen by default because of ordering in codec_list.c [23:57:51 CET] <jamrial> we could swap the order at this point, i guess [23:57:54 CET] <nevcairiel> i dont build any encoders, so i'll just throw out aom [00:00:00 CET] --- Wed Mar 13 2019