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

[burek]

[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