[03:14:10 CEST] <cone-973> ffmpeg 03Ruiling Song 07master:0fc464631aaf: lavfi/opencl: add more opencl helper macro [12:15:19 CEST] <cone-105> ffmpeg 03Paul B Mahol 07master:1e01f66822a0: avfilter/af_astats: count number of NaNs/Infs/denormals for floating-point audio too [12:51:05 CEST] <durandal_1707> ubitux: ping [12:55:22 CEST] <iive> atomnuker1, which metro game are you playing? the first or the latest (exodus)? [12:56:07 CEST] <nevcairiel> he did say 2033, thats the first one [12:59:27 CEST] <durandal_1707> iive: what are you playing now? some trolish game? [13:01:09 CEST] <ubitux> durandal_1707: pong [13:01:19 CEST] <ubitux> durandal_1707: i will check the lut3d patch(es) tonight [13:03:52 CEST] <durandal_1707> ok [13:08:22 CEST] <iive> durandal_1707, your constant trolling is annoying. grow up. [13:08:35 CEST] <durandal_1707> ubitux: there is also subtitle patch [16:44:44 CEST] <mkver> Is FFmpeg (the project) actually requiring the range of int to be the typical 32bit range? [16:45:20 CEST] <JEEB> no idea if we support something like DJGPP with 16bit ints [16:45:29 CEST] <mkver> I'm asking because ff_log2_c in libavutil/intmath.h would fail if the unsigned int were 64bit. [16:45:40 CEST] <JEEB> I would bet there's a lot of stuff that would fail with 16bit ints [16:45:45 CEST] <JEEB> mkver: oh, *bigger* :D [16:45:52 CEST] <JEEB> sounds like kool stuff [16:46:35 CEST] <mkver> I'm actually interested in bigger ints. Lots of things would fail with 16bit ints -- lots of constants would overflow etc. [16:46:40 CEST] <jamrial> no, even djgpp has 32 bits ints [16:46:45 CEST] <JEEB> ok [16:46:54 CEST] <JEEB> kind of expected since almost everything expects that nowadays [16:48:30 CEST] <mkver> If 32int are expected and implicitly assumed, then shouldn't this be explicitly mentioned somewhere (probably in the list of C language features here: https://www.ffmpeg.org/developer.html#C-language-features)? [16:48:30 CEST] <nevcairiel> basically, we dont support anything where int is not 32-bit, what would even have that? [16:49:47 CEST] <philipl> wikipedia says "HAL Computer Systems port of Solaris to the SPARC64" [16:50:30 CEST] <mkver> I don't know. I think some of the Cray supercomputers have 64bit ints (everything except char is 64bit on that plattform if I remember correctly). But I am just asking because I saw this implicit assumption on ff_log2_c. [16:52:44 CEST] <mkver> My actual concern is because of a bug in the Matroska muxer. [16:54:02 CEST] <mkver> If you reserve a certain size for cues in the front and said size happens to be 1 byte more than the needed size, then the cues will be written normally and afterwards there will be an attempt to fill in the hole with an EBML void element. [16:54:03 CEST] <jamrial> if the function takes an int, then it's assumed to be for 32 bits ints. in some cases, a version for 64 bit integers is also available, usually using a prefix like 64 or ll, and int64_t as argument [16:54:27 CEST] <mkver> Ok, so int is only supposed to be 32bit. [16:54:36 CEST] <jamrial> sorry, suffix [16:54:38 CEST] <jamrial> and yes [16:55:19 CEST] <mkver> Of course, a one byte hole can't be filled by a void element and one runs into an assert (that the hole to be filled has to be at least two bytes long). [16:56:18 CEST] <mkver> There are two ways to solve this problem: The first is: Error out on this edge case. The second is: If this is so, then write the cues length field on one byte more than necessary. [16:57:11 CEST] <nevcairiel> wouldnt that excess byte still cause validation troubles [16:57:44 CEST] <mkver> No. It is completely spec-compliant to write the length of an EBML element with more bytes than necessary. [16:58:00 CEST] <JEEB> sounds like mp4 [16:58:05 CEST] <JEEB> where you could have just extra stuff at the end [16:58:09 CEST] <nevcairiel> how does a reader know the content ended when there is still stuffing at the end [16:58:19 CEST] <JEEB> or wait I don't remember [16:58:23 CEST] <JEEB> disregard muh comment [16:59:21 CEST] <mkver> No, I don't put the stuffing at the end. An EBML element goes like this: EBML ID, EBML length followed by the payload (whose length is given by the EBML length field except in the unknown-length case). [16:59:33 CEST] <mkver> It is legal to write the EBML length field on more bytes than needed. [16:59:47 CEST] <nevcairiel> oh, you just want to make the length inefficient [17:00:06 CEST] <mkver> I only want to make the length in this very edge case inefficient. [17:00:50 CEST] <nevcairiel> well that would work if the content is already being written to a dynbuf anyway [17:01:00 CEST] <mkver> The current Matroska muxer writes the lengths of lots of elements (like clusters) on the maximum amount of bytes (namely eight). I have a patchset on the mailing list to change this. [17:01:23 CEST] <mkver> Exactly! We already write the cues to a dynbuf. [17:01:41 CEST] <mkver> So it is possible to adapt the length of the length field as needed. [17:02:00 CEST] <nevcairiel> unless its already maxed out, but that would be a lot of cues and not realistic [17:02:31 CEST] <mkver> If int is 32bit, it is not only not realistic, but impossible. [17:02:53 CEST] <nevcairiel> oh right its equipped for writing 64-bit sizes [17:03:55 CEST] <mkver> That's of course the reason for my question: Do I need an #ifdef for big ints? [17:04:03 CEST] <nevcairiel> no [17:04:17 CEST] <mkver> Good. Then I'll remove it again. [17:04:33 CEST] <nevcairiel> you can put an assert if you want to be sure this never happens in case something changes in 10 years or so [17:05:07 CEST] <mkver> Yes, that's what I thought, too. [17:33:22 CEST] <cone-356> ffmpeg 03Michael Niedermayer 07master:f857753f56f8: avcodec/gdv: Check input palette size before rescale() [20:47:12 CEST] <durandal_1707> how to mark sidedata used and not longer needed for packet? [20:48:39 CEST] <jamrial> remove it? [20:49:29 CEST] <durandal_1707> how? [20:50:33 CEST] <durandal_1707> removing all side data is bad idea [20:50:45 CEST] <JEEB> I think you could unlink specific side data? [20:50:52 CEST] <JEEB> not that I've tried to do it myself [00:00:00 CEST] --- Sat Apr 27 2019