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

[burek]

[01:08:53 CEST] <cone-485> ffmpeg 03Zhao Zhili 07master:2bfa7df9fefe: avfilter: fix typo in comments
[02:08:58 CEST] <cone-485> ffmpeg 03James Almer 07master:2e4f86e04ca6: ffprobe: fix output of packets_and_frames section in JSON format
[04:13:58 CEST] <taliho> michaelni: jamrial: I'm working on a patch where I call ff_h2645_packet_split and ff_h2645_packet_uninit in a loop
[04:16:20 CEST] <taliho> Since commit 22bec0d33f423 this doesn't work anymore because nal_buffer_size is not reset to zero in ff_h2645_packet_uninit 
[04:19:32 CEST] <taliho> I sent a patch to the mailing list
[04:20:30 CEST] <jamrial> taliho: i'm not seeing it
[04:21:02 CEST] <jamrial> but yes, that needs to be fixed
[04:23:08 CEST] <taliho> probably it's in the queue, I'll send you the link when it appears
[04:26:28 CEST] <taliho> I'm thinking now whether the extra member is actually needed
[04:27:06 CEST] <taliho> nals_allocated should be able to do the same job with some changes
[04:29:38 CEST] <jamrial> it's needed for av_fast_realloc()
[04:31:35 CEST] <mkver> But it might be worthwhile to add an av_fast_realloc() equivalent for arrays that stores the amount of allocated elements and maybe only allocates full elements.
[04:36:39 CEST] <taliho> ok yes, I see my mistake
[04:38:21 CEST] <taliho> mkver: yes, true. that would allow to remove the extra member
[04:53:22 CEST] <jamrial> taliho: got the patch, will apply
[04:57:27 CEST] <taliho> jamrial: thanks
[05:05:57 CEST] <cone-485> ffmpeg 03Andriy Gelman 07master:cebb446911fd: avcodec/h2645_parse: Reset nal_buffer_size on uninit
[05:05:58 CEST] <cone-485> ffmpeg 03James Almer 07master:1e0b6bc0b4d6: avcodec/av1_parse: simplify memset call
[05:05:59 CEST] <cone-485> ffmpeg 03James Almer 07master:62f47225825c: avcodec/av1_parse: Use av_fast_realloc() for OBU array
[15:54:53 CEST] <durandal_1707> is there nice way to check that m0 register is filled with zeros?
[15:57:12 CEST] <jamrial> PCMPEQ*?
[15:58:06 CEST] <durandal_1707> ptest
[15:59:00 CEST] <jamrial> that's sse4, though
[15:59:59 CEST] <durandal_1707> jamrial: so?
[16:00:35 CEST] <jamrial> i don't know what you're targetting, so just letting you know
[16:04:48 CEST] <BBB> so uhm... why do you want to test that the register is filled with zeros?
[16:05:00 CEST] <BBB> I mean, conditional coding isn't typically a thing in simd
[16:06:08 CEST] <BBB> there's pmovmskb if you want to do weird stuff, but typically simd wouldn't go between gprs and xmm regs
[16:06:15 CEST] <BBB> since it introduces a lot of latency etc.
[16:07:25 CEST] <BBB> (although I've never used ptest; so can't speak for its latency)
[16:07:35 CEST] <durandal_1707> to abort early, mecause if register is zero it is actually mask which tells that no calculations are used, so to stop early
[16:08:21 CEST] <BBB> steamroller ptest latency=14, pmovmskb bulldozer latency=10 :-/
[16:08:25 CEST] <BBB> well... 
[16:09:36 CEST] <durandal_1707> BBB: can i jz after it?
[16:10:01 CEST] <BBB> ptest yes
[16:12:43 CEST] <durandal_1707> huh, it appears to just add latency but to never trigger
[16:32:51 CEST] <cone-493> ffmpeg 03Paul B Mahol 07master:f069a9c2a65b: avfilter/vf_avgblur: fix heap-buffer overflow
[16:41:12 CEST] <cone-493> ffmpeg 03Paul B Mahol 07master:de598f82f8c3: avfilter/vf_edgedetect: fix heap-buffer overflow
[16:56:38 CEST] <cone-493> ffmpeg 03Paul B Mahol 07master:e1b89c76f663: avfilter/af_afade: fix heap-buffer overflow
[17:11:26 CEST] <cone-493> ffmpeg 03hwren 07master:e71c241beaaa: lavc/libxavs2: fix parameter setting result determination
[17:11:27 CEST] <cone-493> ffmpeg 03Michael Niedermayer 07master:ec9d48da1959: tools/target_dec_fuzzer: Also fuzz keyframe & disposal flags
[17:55:00 CEST] <j-b> morning
[17:56:13 CEST] <durandal_1707> 'evening
[18:03:49 CEST] <cone-493> ffmpeg 03Paul B Mahol 07master:f2598484b830: avfilter/vf_bm3d: make sure nb_jobs is at least 1
[18:05:02 CEST] <cone-493> ffmpeg 03James Almer 07master:dd01947397b9: avformat/latmenc: abort if no extradata is available
[18:14:41 CEST] <durandal_1707> jamrial: what to use for sign extend?
[18:16:38 CEST] <nevcairiel> ideally make the signature just use size_t if you can
[18:16:50 CEST] <nevcairiel> or ptrdiff_t or whatever is appropriate
[18:17:39 CEST] <nevcairiel> otherwise, use movsxdifnidn regq,regd
[18:18:42 CEST] <Mystnom> Hi all, just wanted to understand, is it permissible to call 'ff_filter_frame(outlink, output);' multiple times from activate()
[18:18:42 CEST] <jamrial> durandal_1707: to clear the higher 32 bits of the regs on x86_64. it's needed for win64 mainly
[18:19:12 CEST] <jamrial> but yeah, either make the parameters ptrdiff_t instead of int, or just movsxdifnidn them
[18:20:57 CEST] <durandal_1707> Mystnom: i think best not, you can easily make it call .activate again if there is still work to do, by using ff_filter_set_ready()
[18:26:57 CEST] <Mystnom> Apologies for asking lame questions I am a newbie. My filter queues the input frame, and asynchronously produces the output frames. there can be cases when it might consume around 20 input frames and after that start producing output frames. In such cases how would I make sure the activate() is called again
[18:28:06 CEST] <durandal_1707> Mystnom: ff_filter_set_ready(ctx, <some integer 1-100>)
[18:28:48 CEST] <durandal_1707> then if you are ready already, do not request for new frames from inputs
[18:30:12 CEST] <Mystnom> Thanks man
[18:40:10 CEST] <durandal_1707> Mystnom: also read doc/filter_design.txt if you haven't already
[18:53:48 CEST] <durandal_1707> buy me laptop with 1TB RAM!
[18:56:39 CEST] <Lynne> you want to run an elasticsearch instance to find text in all your files on the system?
[18:57:19 CEST] <durandal_1707> no, I need it for v360 vulkan project
[19:05:32 CEST] <Lynne> I'm waiting for the amd rx 5900 xt to be released
[19:07:01 CEST] <durandal_1707> Lynne: get nvidia instead
[19:08:01 CEST] <Lynne> I know its terrible
[19:08:40 CEST] <Lynne> only question is whether to get a ryzen or intel
[19:09:12 CEST] <Lynne> cores and unknown avx2 performance vs price and known avx2 performance (and avx512 slowdown)
[19:12:12 CEST] <JEEB> mobile or desktop? currently zen2 things seem to be quite nice even if you take into account the lower avx2 perf
[19:19:49 CEST] <durandal_1707> What is #8282 about?
[00:00:00 CEST] --- Wed Oct 16 2019