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

[burek]

[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