[02:24:54 CET] <JC_Yang> do anyone strive to make ffmpeg build with -Wall -Werror cleanly? don't you think there might be hidden bugs due to the warnings spreading in every corners? [02:31:47 CET] <qeed> hard bugs are logic bugs and bugs cant be detected from static analysis [02:53:41 CET] <JC_Yang> yes, probably, but why not first make it warnings clean? is this excuse strong enough to support the left-warning-as-is decision? I encounter a weird bug recently, in the matroska muxer. I implement my own filters to just feed valid packets(with valid dts/pts, all of them are guaranteed to be >0 while as input) to the muxer, but, ocassionally the muxer run into a warning saying "Starting new cluster due to timestamp". I modify the codes to also [02:53:41 CET] <JC_Yang> print out the dts/pts and all locally relate timestamp info, I'm shocked to see that the dts/pts are negative numbers!!! I am not familiar to the codebase, I don't know a reliably and easy way to trigger the bug, and considering the -Wsign-compare and alike warnings spreading everywhere, I doubt... [02:55:48 CET] <BBB> not all warnings are useful [02:55:56 CET] <BBB> some are plain wrong [02:56:06 CET] <BBB> and can only be fixed by code obfuscation or things like that [02:56:20 CET] <BBB> ohwell [02:57:19 CET] <BBB> JC_Yang: negative timestamps are common if you literally interpret some media formats [02:57:28 CET] <BBB> if you dont want it, just subtract the first ts from all following [02:57:29 CET] <BBB> simple [02:57:48 CET] <BBB> most people dont care, they just care about video and audio alignign [03:10:22 CET] <kepstin> also, "starting new cluster" in mkv is normal, clusters have a timestamp, then blocks within a cluster use an offset from the cluster timestamp, and any time that offset would overflow it has to start a new cluster. [03:10:27 CET] <kepstin> iirc? [03:11:37 CET] <kepstin> i wish the mkv spec was more readable :/ [09:32:38 CET] <j-b> 'morning [12:05:17 CET] <J_Darnley> Following on from my question last week about a strobe... [12:05:45 CET] <J_Darnley> What filter can number each frame? drawtest? [12:05:47 CET] <J_Darnley> uh [12:05:51 CET] <J_Darnley> drawtext [14:05:34 CET] <January> jamrial: https://0x0.st/s6n0.patch this look ok? Will send to ML [14:49:18 CET] <nevcairiel> January: while you're in there, did you also s ee https://trac.ffmpeg.org/ticket/7521 ? [14:49:49 CET] <nevcairiel> ssize_t is apparently not quite portable [14:50:25 CET] <January> nevcairiel: do we not have a helper for this somewhere? [14:51:45 CET] <nevcairiel> no, ssize_t is practically unused in ffmpeg, outside of a few platform specfic modules which probably just dont get used anywhere else [14:52:39 CET] <nevcairiel> fread by definition returns size_t though [14:52:40 CET] <jkqxz> The return value of fread() is not ssize_t, anyway. The < 0 check is also wrong. [14:52:54 CET] <jkqxz> Yeah, that. [14:55:55 CET] <January> right I was previously just using read(2), this should fix MSVC then https://0x0.st/s65m.patch [14:56:39 CET] <nevcairiel> seems fine [14:56:48 CET] <nevcairiel> (on that aspect) [16:46:47 CET] <cone-772> ffmpeg 03Paul B Mahol 07master:7e1add2c51d7: doc/filters: add small description to geq filter section [17:02:50 CET] <cone-772> ffmpeg 03Michael Niedermayer 07master:88e3807aafd3: avcodec/vp3: Do not initialize unused tables for keyframes in unpack_superblock() [17:02:51 CET] <cone-772> ffmpeg 03Michael Niedermayer 07master:f56318081777: avcodec/vp3: Reuse local variable in unpack_superblocks() [17:02:52 CET] <cone-772> ffmpeg 03Michael Niedermayer 07master:b5e7e437f4c8: avcodec/vp3: Do not recalculate coded_fragment_list for keyframes [17:02:53 CET] <cone-772> ffmpeg 03Michael Niedermayer 07master:4885ff663bec: avcodec/vp3: reindent unpack_superblocks() [20:07:31 CET] <haasn> atomnuker: you should put film grain into ffv2/daala2 and make it good :^) [20:10:17 CET] <durandal_1707> ffv2 is lossless [20:12:07 CET] <durandal_1707> supposed to be? [20:12:41 CET] <gnafu> I don't believe so. I'm pretty sure atomnuker is working on a lossy video codec using technologies from Daala. [20:13:12 CET] <JEEB> it's like the third thing that's been called "ffv2" ever since pengvado's thing [20:13:33 CET] <JEEB> and yes, atomnuker's "presentation" thing mostly was about lossy coding schemes and ranting [20:13:33 CET] <gnafu> https://github.com/atomnuker/FFmpeg/tree/exp_ffv2_daala [20:14:05 CET] <JEEB> also TIL that someone made an independent implementation for FFV1 [20:14:12 CET] <JEEB> for the archivist community [20:14:35 CET] <JEEB> or to verify the spec, I guess [20:14:51 CET] <durandal_1707> nooooooo, ffv2 must be lossless! [20:15:12 CET] <JEEB> durandal_1707: don't worry - it's just his hobby project :P [20:15:14 CET] <atomnuker> it'll be fiiine, its winter again, I have to work on an encoder [20:16:01 CET] <durandal_1707> serious devs can code when it is hot [20:19:12 CET] <atomnuker> best works with simd asm [20:19:23 CET] <atomnuker> this summer was too hot for even that [20:22:27 CET] <durandal_1707> gonna write some simd before it becomes too cold? [20:23:26 CET] <atomnuker> I am, I have some almost finished av1 simd for dav1d [20:24:50 CET] <BBB> 8) [20:25:15 CET] <j-b> I finally watched the FFv2 presentation, calmly. [20:25:19 CET] <j-b> very cool [20:25:53 CET] <durandal_1707> j-b: calmly? something was bad? [20:26:08 CET] <j-b> durandal_1707: during VDD, I'm always in rush :) [20:26:18 CET] <j-b> So I can't enjoy the conf as well as I should [20:26:38 CET] <kierank> j-b: the nttw sessions are nice [20:26:43 CET] <kierank> They are super keen about oss [20:26:49 CET] <JEEB> I mean, it mentions nice techniques etc, but I think the response towards the "I thought this was lossless, why was this mostly about lossy coding techniques?" wasn't too great :) [20:26:59 CET] <JEEB> kierank: yea that kind of came out of the woodworks for me [20:27:03 CET] <JEEB> seemed like a nice event [20:27:07 CET] <kierank> They are not jaded like us [20:27:17 CET] <kierank> They love carl [20:27:23 CET] <kierank> Like durandal_1707 does [20:27:25 CET] <durandal_1707> shit [20:27:42 CET] <kierank> LOL [20:29:17 CET] <BBB> nttw? [20:29:35 CET] <kierank> No time to wait [20:31:12 CET] <JEEB> where was that btw? [20:31:27 CET] <JEEB> it could make my list of "events I'd like to visit" for next year [20:31:50 CET] <JEEB> ah, london [20:34:44 CET] <JEEB> will have to keep in mind next year :) [20:34:51 CET] <JEEB> (on where it's going to be held etc) [20:36:11 CET] <durandal_1707> it could be remote only conference [20:42:30 CET] <cone-403> ffmpeg 03Mark Thompson 07master:c0692cb2bb3b: vaapi_encode_mpeg2: Fix width/height columns/rows confusion [20:43:22 CET] <jkqxz> Not sure how that happened. I really think I tested it with non-square video... [20:44:28 CET] <j-b> kierank: I will watch nttw tehn [20:51:27 CET] <durandal_1707> how to name filter which would add black(or solid color) frames to beginning or end of video, delaying original video or padding it? [20:51:53 CET] <BradleyS> tpad [20:52:00 CET] <BradleyS> temporal pad [20:52:02 CET] <atomnuker> colorpad [20:53:02 CET] <kierank> durandal_1707: you were invited [20:53:07 CET] <kierank> I would have payed [20:53:26 CET] <kierank> Dave rice said you write good filters [20:53:40 CET] <durandal_1707> kierank: i cant leave country - i'm mafia boss [20:56:17 CET] <durandal_1707> besides, i want to avoid to meet voldemort/saruman in person [20:56:51 CET] <kierank> Lol [20:57:55 CET] <BradleyS> the eye sees all [21:09:15 CET] <uartie> jkqxz: thx :) [21:17:03 CET] <jkqxz> uartie: Do you have a CI setup somewhere which is catching that? [21:17:34 CET] <uartie> jkqxz: yup [21:18:03 CET] <uartie> we are currently running ci internally at intel [21:19:22 CET] <uartie> jkqxz: what's your take on #7523 [21:19:38 CET] <uartie> seems odd that [h264_vaapi @ 0x264d240] Slice count rounded up to 45 (from 4) due to driver constraints on slice structure. [21:21:17 CET] <jkqxz> Just looking at that now... [21:22:37 CET] <jkqxz> The i965 driver doesn't offer support for any slice layouts at all in LP, though it does say it can support up to 32 slices. [21:22:58 CET] <uartie> yeh, saw that [21:23:10 CET] <uartie> bug in i965? [21:23:29 CET] <jkqxz> Looks like it. [21:23:43 CET] <jkqxz> Assuming it does actually support slices. [21:24:01 CET] <uartie> yeh, not sure. iHD should support it though [21:24:57 CET] <uartie> but 45 seems odd [21:25:46 CET] <jkqxz> 45 is just the number of rows. Does it support the EQUAL_ROWS mode? (1 slice per row, MPEG-2 style.) [21:26:15 CET] <uartie> hmm, not sure [21:27:52 CET] <uartie> i'll cc iHD maintainer [21:28:41 CET] <jkqxz> Yeah, it supports 12 = EQUAL_ROWS | MAX_SLICE_SIZE. [21:29:44 CET] <jkqxz> Since the only fixed layout it says it supports is single rows, the request for 4 slices got rounded up to 45 because that's the number of rows in your 720 lines. [21:29:58 CET] <uartie> i see [21:30:09 CET] <uartie> ugh, trac won't let me modify cc [21:34:38 CET] <jkqxz> (Relevant caps: <http://ixia.jkqxz.net/~mrt/ffmpeg/skylake_ihd>.) [21:36:10 CET] <uartie> yup, just saw that in iHD code [21:38:18 CET] <jkqxz> Hmm, the second slice header coming out of iHD is very broken. first_mb_in_slice is correct, but then slice_type and everything after is just rubbish. [21:41:23 CET] <uartie> i can transfer the bug to iHD if you'd like. Or did u want to debug more and file it? [21:43:59 CET] <jkqxz> Go ahead. The driver seems to have only used part of (or overwritten some of?) the slice header, so I'd just be looking in the driver code at this point. [21:44:19 CET] <uartie> kk [21:56:23 CET] <durandal_1707> let's see who knows what 'group delay' means: [22:43:12 CET] <durandal_1707> i need to add group delay drawing to aiir filter IR filter response [00:00:00 CET] --- Tue Oct 30 2018