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

[burek]

[07:33:32 CEST] <mkver> It seems the IRC log has issues again: The last archived day was last Sunday.
[10:34:59 CEST] <termos> should this be resubmitted since it contains two attachments? don't want to spam the mailing list http://ffmpeg.org/pipermail/ffmpeg-devel/2019-October/251689.html
[11:03:55 CEST] <cone-785> ffmpeg 03Paul B Mahol 07master:fb7b222b9182: avfilter/af_arnndn: make sure that vad_output nb_neurons is always 1
[11:33:42 CEST] <cone-785> ffmpeg 03Paul B Mahol 07master:3488e0977c67: avfilter/vf_random: fix memory leaks
[11:33:43 CEST] <cone-785> ffmpeg 03Paul B Mahol 07master:ce40188bc046: avfilter/vf_amplify: cosmetics
[11:54:13 CEST] <cone-785> ffmpeg 03Paul B Mahol 07master:8f63c4e72a8c: avfilter/vf_dedot: fix crash
[12:17:13 CEST] <cone-785> ffmpeg 03Gyan Doshi 07master:9c820ebe90f3: doc/filters: fixes for scale filter
[12:31:08 CEST] <cone-785> ffmpeg 03Andreas Rheinhardt 07master:6aae32212041: avfilter/af_arnndn: Remove superfluous qualifier
[12:34:42 CEST] <cone-785> ffmpeg 03Andreas Rheinhardt 07master:097c917c1476: avcodec/ac3enc: Fix memleak
[12:48:49 CEST] <mkver> michaelni: Your recent cavs patch fails on lots of fate units (I haven't a fate box where it doesn't fail), but strangely it works for me (and apparently for you, too). Do you have any idea about this?
[12:49:14 CEST] <mkver> I haven't a fate->I haven't seen a fate box
[12:54:11 CEST] <durandal_1707> michaelni: fate gonna full yellow mode
[13:07:16 CEST] <michaelni> mkver, durandal_1707 ive a fix will push after a bit more testing
[13:13:43 CEST] <michaelni> ill push as soon as ive tested on 32/64 bit linux, mingw32/64, arm & mips
[13:22:30 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07master:0279e727e992: avcodec/cavsdec: Set ret on errors in decode_pic()
[13:51:54 CEST] <mkver> michaelni: What was the reason that the cavs test failed on only some machines?
[13:52:17 CEST] <michaelni> mkver, --enable-memory-poisoning
[16:46:20 CEST] <Lynne> I'd just like to point out --disable-safe-bitstream-reader still exist
[17:07:14 CEST] <jamrial> BBB: any opinion on the above ticket?
[17:09:06 CEST] <BBB> probably true
[17:09:20 CEST] <BBB> should be easy to fix right?
[17:09:35 CEST] <BBB> (in ffmpeg's libdav1d.c)
[17:14:42 CEST] <jamrial> BBB: so just "frame->reordered_opaque = avctx->reordered_opaque;", like ff_decode_frame_props() does for get_buffer2 decoders?
[17:15:22 CEST] <BBB> I think so
[17:15:31 CEST] <jamrial> ok
[17:22:00 CEST] <kierank> Lynne: you want all bitstream reads to be safe?
[17:22:11 CEST] <kierank> Or you want all decoders to have unsafe reads?
[17:24:56 CEST] <Lynne> obviously for all reads to be safe
[17:25:20 CEST] <Lynne> my point is there's a flag that undoes all work that has gone into safety and allows users to shoot themselves in the foot
[17:26:06 CEST] <Lynne> actually maybe not, because of the padding I don't see how overreads are possible
[17:39:28 CEST] <cone-785> ffmpeg 03Andreas Rheinhardt 07master:ba191c0ce044: vp9_superframe: Avoid allocations and copies of packet structures
[17:39:29 CEST] <cone-785> ffmpeg 03James Almer 07master:39d5acbd097b: avcodec/libdav1d: set AVFrame reordered_opaque
[17:40:01 CEST] <BBB> jamrial: ty
[17:40:09 CEST] <jamrial> no prob
[17:48:01 CEST] <nevcairiel> does that ensure it matches stuff based on threading delay? otherwise its sort of  useless
[17:48:26 CEST] <nevcairiel> but unless dav1d allows you to pass arbitrary data through with frames, its also not possible
[17:51:09 CEST] <nevcairiel> (the contract of that variable is that whatever is in  it when you pass in a packet gets associated to the frame that matches that packet, sort of like the timestamp, just for arbitrary data)
[17:52:25 CEST] <BBB> if you do it in get_buffer, it's fine
[17:52:34 CEST] <BBB> that's on decode-start-time, which matches packet input
[17:52:46 CEST] <BBB> if you do it upon frame return, it's indeed problematic with frame-mt
[17:52:48 CEST] <BBB> but he's not doing that
[17:52:51 CEST] <BBB> so it's ok
[17:54:24 CEST] <nevcairiel> it looks like  its in frame return to me?
[17:55:37 CEST] <nevcairiel> we dont  have an AVFrame before that point
[18:05:01 CEST] <BBB> I'm not sure
[18:05:11 CEST] <BBB> I thought ffmpeg allocated the frame dav1d decodes in
[18:06:15 CEST] <nevcairiel> it allocates a buffer, and then plugs it into a frame later
[18:12:13 CEST] <jamrial> maybe avctx->reordered_opaque should be mapped to Dav1dDataProps for the input packet, much like pts/pos/duration, then copied to frame->reordered_opaque on frame return
[18:28:23 CEST] <jamrial> nevcairiel, BBB: https://pastebin.com/eKAN54AR
[18:28:37 CEST] <jamrial> sucks that it's one extra alloc per input packet, but well
[18:28:58 CEST] <nevcairiel> you could only do it if its non-zero
[18:29:03 CEST] <nevcairiel> not that many people use it
[18:29:14 CEST] <jamrial> ah, true
[18:29:32 CEST] <nevcairiel> and its generally probably safer to check the p ointer to user_data before de-reffing i t
[18:42:06 CEST] <jamrial> nevcairiel: avctx->reordered_opaque seems to default to int64_max, not zero
[18:42:22 CEST] <nevcairiel> well then use that :D
[18:42:36 CEST] <nevcairiel> back in the very old days people did use it for timestamps
[18:42:39 CEST] <nevcairiel> so its probably NOPTS
[18:43:04 CEST] <jamrial> yes, it's nopts
[18:44:40 CEST] <jamrial> which makes me think people will use it for timestamps despite the decoder doing that internally just fine :p
[18:44:58 CEST] <nevcairiel> in old code perhaps
[18:45:13 CEST] <nevcairiel> but even more reason to get it right
[18:53:34 CEST] <cone-785> ffmpeg 03Andreas Rheinhardt 07master:b288a7eb3d96: avformat/mpegenc: Fix memleaks and return values
[18:53:35 CEST] <cone-785> ffmpeg 03Michael Niedermayer 07master:2fca09bce49c: avcodec/binkaudio: Check sample rate
[18:53:36 CEST] <cone-785> ffmpeg 03Andreas Rheinhardt 07master:eb17bf6fd3da: mpeg4_unpack_bframes: Avoid allocations and copies of packet structures
[18:58:11 CEST] <jamrial> BBB, nevcairiel: https://pastebin.com/JqMVHR78
[19:16:21 CEST] <Lynne> 0 is a valid timestamp
[20:08:12 CEST] <rcombs> there are 3 valid timestamps: 0, 1, and infinity
[20:12:52 CEST] <Lynne> doesn't account for mpegts overflows
[20:17:39 CEST] <nevcairiel> jamrial: yeah might want to skip on the non-zero check, if someone uses it for timestamps, otherwise seems fine, I guess, but didnt test
[21:07:15 CEST] <taliho> Why don't we support nvenc on Tegra? 
[21:21:52 CEST] <cone-785> ffmpeg 03Paul B Mahol 07master:295d99b4393d: avfilter/vf_adadenoise: add x86 SIMD
[21:21:53 CEST] <cone-785> ffmpeg 03Paul B Mahol 07master:71e33c6e01f6: avfilter/vf_atadenoise: add option to use additional algorithm
[21:21:54 CEST] <cone-785> ffmpeg 03Paul B Mahol 07master:0ae6fb276bd9: avfilter/x86/vf_atadenoise: add SIMD for serial too
[00:00:00 CEST] --- Fri Oct 18 2019