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

[burek]

[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