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

[burek]

[00:05:55 CEST] <mkver> Have there been changes to the mail server? My new patchset has been delivered almost instantaneously.
[00:06:44 CEST] <BtbN> That's how mails usually go
[00:08:34 CEST] <mkver> My mails have usually been stuck for several minutes.
[00:17:28 CEST] <cone-380> ffmpeg 03Guo, Yejun 07master:104d44138be1: libavcodec/libx264: add a flag to output ROI warnings only once.
[00:17:28 CEST] <cone-380> ffmpeg 03Guo, Yejun 07master:85e338ab0da6: libavcodec/libx265: add a flag to output ROI warnings only once.
[05:24:14 CEST] <cone-478> ffmpeg 03Jun Zhao 07master:5f13859873a4: lavf/4xm: fix memory leak in error handing path
[10:46:24 CEST] <JEEB> I'll attempt to post this on the mailing list tonight as well, but I'd like to get responses with regards to handling end-of-stream in MPEG-TS
[10:46:30 CEST] <JEEB> should this be handled by:
[10:46:54 CEST] <JEEB> a) the framework, utilizing whatever is the current way of doing end-of-stream if a stream disappears from its PMT
[10:47:09 CEST] <JEEB> b) the API client, following the PMT updates through the AVProgram's pmt_version field
[10:48:22 CEST] <cone-703> ffmpeg 03Pavel Skakov 07master:eb5d0f18ff60: lavc/tiff: correct the default value of YCbCrSubsampling to 2x2
[12:08:21 CEST] <durandal_1707> cehoyos: where is that sample?
[12:08:44 CEST] <cehoyos> Uploading it now (400MB), will take ~15 minutes
[12:16:29 CEST] <cehoyos> durandal_1707: http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket8199/
[12:17:09 CEST] <cehoyos> command line is: ffmpeg -ss 9:00 -i ds9-s01e05-repro-02.mkv -filter:v "dejudder,fps=30000/1001,fieldmatch,decimate" -f null -
[12:51:22 CEST] <durandal_1707> silly one line bug
[13:07:17 CEST] <jdarnley_obs> C has no guarantee about the actual order and position of arrays on the stack, right?
[13:07:55 CEST] <cone-703> ffmpeg 03Paul B Mahol 07master:0d05aa052cdd: avfilter/vf_v360: add sinusoidal format
[13:07:55 CEST] <jdarnley_obs> That would be relying on the implementation and arch, right?
[13:07:56 CEST] <cone-703> ffmpeg 03Paul B Mahol 07master:2962101e407e: avfilter/vf_fieldmatch: fix more leaks
[13:07:57 CEST] <cone-703> ffmpeg 03Paul B Mahol 07master:da9890f6c7d2: avfilter/vf_fieldmatch: forward status back from output to all input links
[13:07:58 CEST] <cone-703> ffmpeg 03Paul B Mahol 07master:55b32584b80e: avfilter/vf_premultiply: forward status back from output to all input links
[13:08:48 CEST] <jdarnley_obs> Basically, I can't assume that a checkasm test will always have arrays on stack in the order I write them in source.
[13:10:11 CEST] <jdarnley_obs> Ah, but I think that doesn't matter in this case because I can make the ones used for assembly larger to contain the overwrite.
[13:14:57 CEST] <cehoyos> vmovdqa %ymm1,(%rdi) <- how much alignment does rdi need here (avx2)?
[13:15:11 CEST] <cehoyos> rdi            0x7fffffffcc70   140737488342128
[13:15:13 CEST] <jdarnley_obs> 32 bytes
[13:15:19 CEST] <jdarnley_obs> 0x20
[13:15:46 CEST] <jdarnley_obs> or the 0x?0 number must be even
[13:15:47 CEST] <cehoyos> Who is responsible for the alignment? FFmpeg or libx264? (ticket 8200)
[13:16:53 CEST] <cehoyos> x264_8_load_deinterleave_chroma_fenc_avx2() is the crashing function
[13:16:53 CEST] <jdarnley_obs> Probably ffmpeg, if it is reading from input data.
[13:22:59 CEST] <jdarnley_obs> Does asan check arrays on the stack properly to see if there is an out of bound use of one?
[13:23:31 CEST] <jdarnley_obs> Or do i need to malloc for that to work?
[13:27:21 CEST] <nevcairiel> eh if there was a fundamental issue like that guy tries to claim, there would've been many errors before
[13:28:23 CEST] <nevcairiel> there is probably some dumb reason like he disables asm in ffmpeg but enables it in x264 which  means that ffmpeg uses less alignment by default
[13:28:42 CEST] <JEEB> usually filters are related
[13:28:51 CEST] <JEEB> like crop etc which don't touch the image bytes, but can f.ex. crop
[13:29:07 CEST] <JEEB> or a filter which would generate a new image buffer but doesn't align it
[13:29:21 CEST] <JEEB> I think with codec cropping you might not need decoding, even?
[13:29:31 CEST] <cehoyos> No filters in his command line
[13:29:41 CEST] <JEEB> yes
[13:29:46 CEST] <cehoyos> no specific configure option for asm
[13:29:57 CEST] <cehoyos> Is a minimum compiler needed for avx2?
[13:31:31 CEST] <nevcairiel> no, only nasm/yasm is tested, but thats independent of the alignment determination
[13:32:20 CEST] <JEEB> was there some arch etc check for the alignment to use with av_malloc and friends?
[13:32:54 CEST] <nevcairiel> #define ALIGN (HAVE_AVX512 ? 64 : (HAVE_AVX ? 32 : 16))
[13:32:54 CEST] <nevcairiel> thats it ^
[13:35:15 CEST] <nevcairiel> and on x86 all those HAVE's are true un less you disable them in configure
[13:37:15 CEST] <cehoyos> He is using super new x264 with gcc 4.8.5
[13:37:35 CEST] <nevcairiel> its possible that something is j ust screwed up from the old compiler
[13:38:38 CEST] <BBB> x264 expects 32byte alignment of stack 
[13:40:14 CEST] <BBB> is the stack 32byte aligned?
[13:40:14 CEST] <BBB> in ffmpeg, it usually is not, so maybe need to manually re-align it upon x264 lib entry
[13:40:14 CEST] <BBB> first of all, figure out if the buffer is stack or heap
[13:40:14 CEST] <nevcairiel> shouldnt the x264 header set this attribute to make that happen, like we do in ffmpeg when called from msvc
[13:40:14 CEST] <BBB> hopefully :)
[13:40:14 CEST] <BBB> let's figure out if the $rdi is stack or heap
[13:40:14 CEST] <BBB> cehoyos: p $rdi && p $rsp
[13:40:14 CEST] <BBB> (as (void*))
[13:40:14 CEST] <cehoyos> BBB: ?
[13:40:14 CEST] <BBB> what is the value of $rsp?
[13:40:14 CEST] <cehoyos> rsp            0x7fffffffcc28   0x7fffffffcc28
[13:40:23 CEST] <BBB> ty, so it's stack
[13:40:25 CEST] <BBB> what platform? win64?
[13:40:34 CEST] <cehoyos> Red Hat
[13:40:38 CEST] <BBB> ah
[13:40:58 CEST] <BBB> lookslike a bug in x264 then
[13:41:13 CEST] <BBB> I don't think that memory area is far enough from rsp to be allocated in ffmpeg, so it's likely internal to x264
[13:41:26 CEST] <BBB> one of the x264 devs would know better though
[13:41:47 CEST] <BBB> it's possible it's a compiler bug also
[13:45:40 CEST] <BBB> looks like this value in ac_energy_mb/plane:         ALIGNED_ARRAY_32( pixel, pix,[FENC_STRIDE*16] );, line 246 of ratecontrol.c
[13:45:56 CEST] <BBB> so that's likely the stack re-alignment code in x264
[13:46:00 CEST] <BBB> which requires compiler support
[13:46:10 CEST] <BBB> so i support your conclusion to recompile with a newer compiler and try again
[14:05:43 CEST] <jdarnley_obs> "upgraded" but still 4.8.5
[14:13:41 CEST] <cone-703> ffmpeg 03Paul B Mahol 07master:9c3e1c19376e: avfilter: add sierpinski video source
[14:18:06 CEST] <cone-703> ffmpeg 03Paul B Mahol 07master:402dbd4633a7: avfilter/Makefile: fix case for sierpinski
[14:50:36 CEST] <jdarnley_obs> dammit!  why are no tools cacthing where this problem happens
[15:04:32 CEST] <jdarnley_obs> oh wtf
[15:04:39 CEST] <jdarnley_obs> I had no idea checkasm did that
[15:05:00 CEST] <jdarnley_obs> the "ref" function here is ssse3
[15:05:27 CEST] <jdarnley_obs> I guess I assumed ref would always be the C
[15:05:38 CEST] <jdarnley_obs> that would explain this overwrite
[15:08:22 CEST] <durandal_1707> https://www.youtube.com/watch?v=fk1bxHi6iSI
[15:17:35 CEST] <jamrial> jdarnley_obs: are you sure? sounds unlikely
[15:18:15 CEST] <jdarnley_obs> It is what I saw in my copy
[15:18:45 CEST] <jdarnley_obs> the ssse3 function was called from call_ref
[15:19:03 CEST] <jdarnley_obs> but maybe I should double check that the source wasn't changed
[15:22:28 CEST] <jdarnley_obs> yes, valgrind trapped on an invalid write
[15:22:46 CEST] <jdarnley_obs> that was in ssse3
[15:22:57 CEST] <jdarnley_obs> going up I get to call_ref
[15:23:36 CEST] <jdarnley_obs> maybe the cpp macros throw it off
[15:24:01 CEST] <jdarnley_obs> or maybe I just broke things when I copied and hacked up checkasm for another project
[15:31:10 CEST] <wbs> I think it might be that call_ref calls the "previous" version of the function, not necessarily the C function, as checkasm itself doesn't really know or care what is C and what is each simd instruction set - just previous and current function
[15:31:55 CEST] <jdarnley_obs> yes, I do see the logic in that
[15:32:29 CEST] <jdarnley_obs> I guess that would work for things (in theory) that don't have a C version
[15:32:41 CEST] <jamrial> wouldn't that result in every version after the first one wrong to also fail?
[15:32:54 CEST] <jdarnley_obs> whereas whatever with cpuflags 0 wouldn't
[15:33:42 CEST] <wbs> jamrial: possibly
[16:51:07 CEST] <durandal_1707> jamrial: looked at http://trac.ffmpeg.org/ticket/8183 its about av1
[16:51:44 CEST] <kierank> suhwan should get job at google
[17:03:26 CEST] <cehoyos> durandal_1707: Why is sierpinski not gray8?
[17:04:28 CEST] <durandal_1707> cehoyos: to make you happy
[17:04:49 CEST] <cehoyos> Or is there colour?
[17:05:30 CEST] <durandal_1707> yes, black and white
[17:34:17 CEST] <cone-183> ffmpeg 03Michael Niedermayer 07master:f8406ab4b9f4: avcodec: add max_samples
[17:34:17 CEST] <cone-183> ffmpeg 03Michael Niedermayer 07master:68c80dc31245: tools/target_dec_fuzzer: Set max_samples
[17:34:17 CEST] <cone-183> ffmpeg 03Michael Niedermayer 07master:121bf1b3b8de: avcodec/decode: Check max_samples in get_buffer_internal()
[17:35:11 CEST] <durandal_1707> michaelni: you added max_samples field to avcodec, I will revert it
[17:47:25 CEST] <michaelni> durandal_1707, i wont stop you if you feel so strong about it. but we need something equivalent and it seemed that it was the preferred solution by most people who commented in the thread
[17:49:22 CEST] <cone-183> ffmpeg 03Paul B Mahol 07master:d58752bcb923: avformat/aiffdec: fix signed integer overflow
[17:56:05 CEST] <BBB> cehoyos: for 8200, the guy knows that after upgrading the compiler, he has to recompile x264 from source, right?
[17:56:11 CEST] <BBB> just sayin'
[17:56:30 CEST] <BBB> i can't verify from the bug whether he recompiled x264 after installing a newer compiler or not
[18:04:46 CEST] <cone-183> ffmpeg 03Paul B Mahol 07master:1a17a66b0989: avformat/sdsdec: fix undefined behaviour
[18:17:05 CEST] <durandal_1707> what you think about adding slice threading to *stack filters, in case of xstack and overlaps results may not be same with different number of threads
[18:20:40 CEST] <philipl> Lynne: I've got a bunch of other stuff distracting me, but I have a plan for getting the transfer stuff all working and I've proven the key parts to myself. Maybe by the end of the week.
[18:21:06 CEST] <cehoyos> BBB: I don't know, I will probably try to reproduce with old gcc later.
[18:41:49 CEST] <Lynne> philipl: take your time, not like I know myself whether I'll even send it to the ML or the trash bin
[18:42:35 CEST] <durandal_1707> Lynne: what? no trash bin please! its useful!
[19:22:23 CEST] <jamrial> durandal_1707: fix sent to the ml
[21:45:29 CEST] <Lynne> I wish the hdcd filter was a decoder...
[21:45:48 CEST] <durandal_1707> Lynne: blasphemy
[21:56:28 CEST] <cone-183> ffmpeg 03Paul B Mahol 07master:44095564d48b: avfilter/vf_stack: simplify main processing path
[21:56:29 CEST] <cone-183> ffmpeg 03Paul B Mahol 07master:631f7acc6c48: avfilter/vf_stack: add slice threading
[21:56:30 CEST] <cone-183> ffmpeg 03Paul B Mahol 07master:20242bc76292: avfilter/vf_zoompan: forward status back from output to input
[21:56:31 CEST] <cone-183> ffmpeg 03Paul B Mahol 07master:ced3b8c61e96: avfilter/vf_zoompan: fix leaks
[22:57:20 CEST] <cone-183> ffmpeg 03Limin Wang 07master:3def984a98c3: avcodec/dnxhdenc: return error if av_malloc failed
[00:00:00 CEST] --- Thu Sep 26 2019