[00:26:35 CEST] <kierank> hello [00:39:11 CEST] <durandal_1707> kierank: !? [00:58:19 CEST] <kierank> durandal_1707: ? [02:40:02 CEST] <cone-248> ffmpeg 03Kevin Mark 07master:114e8716214d: doc/filters: Clarify scale2ref example [03:55:44 CEST] <cone-248> ffmpeg 03Michael Niedermayer 07master:357f2316a084: avcodec/ivi_dsp: Fix runtime error: left shift of negative value -2 [03:55:45 CEST] <cone-248> ffmpeg 03erankor 07master:15bd309af830: movenc: encryption with time code track fix [03:55:46 CEST] <cone-248> ffmpeg 03Michael Niedermayer 07master:fe8c9420dd5b: avcodec/aacps: Check border_position to be monotone [03:55:47 CEST] <cone-248> ffmpeg 03Michael Niedermayer 07master:7c36ee216f1e: avcodec/sbrdsp_template: Fix: runtime error: signed integer overflow: 849815297 + 1315389781 cannot be represented in type 'int' [03:55:48 CEST] <cone-248> ffmpeg 03Michael Niedermayer 07master:ca6776a99390: avcodec/libfdk-aacdec: Correct buffer_size parameter [03:55:49 CEST] <cone-248> ffmpeg 03Michael Niedermayer 07master:7f50c25124a0: avcodec/wnv1: More strict buffer size check [03:55:50 CEST] <cone-248> ffmpeg 03Michael Niedermayer 07master:6c3a63fc3d1b: avcodec/aacdec_fixed: Fix multiple runtime error: shift exponent 127 is too large for 32-bit type 'int' [04:13:19 CEST] <rcombs> jamrial: does 7631f14bb35e8467d4ffaaa2b34e60614eb37c71 work reliably if output isn't seekable? [04:15:22 CEST] <jamrial> rcombs: that code isn't triggered with non seekable output, no [04:15:57 CEST] <rcombs> so it doesn't solve the problem that header-delaying does [04:16:22 CEST] <jamrial> what do you mean? [04:16:57 CEST] <rcombs> header-delaying allows updated extradata to be written when the output is non-seekable [04:17:13 CEST] <rcombs> or, well, bsf-generated extradata [04:17:20 CEST] <jamrial> no [04:17:45 CEST] Action: rcombs headtilts [04:17:49 CEST] <jamrial> not now that the bsf that used to do this in question doesn't violate the api anymore [04:18:17 CEST] <rcombs> well it _did_ solve that problem [04:18:42 CEST] <rcombs> but removing the code to set output codecpar and delay headers will regress that [04:19:06 CEST] <jamrial> the delayed header "solved" the problem of bsf generated extradata being available during write_header by abusing the fact this one bsf was violating the bsf api [04:20:13 CEST] <rcombs> if that solution isn't acceptable then we'll need a new one [04:20:27 CEST] <jamrial> it should be done within the muxer [04:20:48 CEST] <jamrial> sort of like how i buffer master elements to write crc32 elements [04:20:50 CEST] <rcombs> that's fine, as long as the muxer delays writing its header internally until the data is available, so it works when output isn't seekable [04:21:07 CEST] <jamrial> yeah [04:21:08 CEST] <rcombs> I figured doing it in lavf/mux was a bit easier, since it doesn't require N muxers to do work [04:21:50 CEST] <jamrial> it was a good idea, but it relied on aac_adtstoasc violating the bsf API [04:22:03 CEST] <jamrial> right now, only matroska needs some extra internal work [04:23:11 CEST] <rcombs> still could be done internally by having mux.c catch the new-extradata side-data and updating the stream's extradata, when it happens before the header is actually written [04:23:27 CEST] <rcombs> which would keep N muxers from having to deal with this [04:23:54 CEST] <rcombs> fate-segment-adts-to-mkv-header-* is meant to test this case [04:24:05 CEST] <jamrial> can't we differentiate between bsf created packet side data and for example encoder created side data to achieve this? [04:24:10 CEST] <jamrial> *can [04:24:30 CEST] <rcombs> does it matter? [04:24:49 CEST] <jamrial> flacenc creates packet side data in the last packet [04:24:59 CEST] <jamrial> and muxers expect it [04:25:29 CEST] <jamrial> if mux.c catches it first, muxers will never see it [04:26:31 CEST] <rcombs> that's why I said "when it happens before the header is actually written" [04:26:43 CEST] <jamrial> yeah, missed that part, sorry [04:27:11 CEST] <rcombs> looking at flacenc and I'm sorta confused about what it puts in there [04:28:06 CEST] <jamrial> the final md5 digest for the decoded data [04:28:07 CEST] <rcombs> seems like it's all either useless, known at startup, or doesn't make sense to be written at the codec level anyway [04:28:27 CEST] <rcombs> that seems like a muxer thing [04:29:03 CEST] <rcombs> reminds me a bit about how flac puts timestamps in the codec-level frame header for some reason [04:29:11 CEST] <jamrial> no, i said decoded data [04:29:17 CEST] <rcombs> oh, derp [04:29:53 CEST] <rcombs> though, seems easier to just checksum the coded data and have the muxer handle it :/ [04:30:02 CEST] <rcombs> but flac is flac, so w/e [04:31:18 CEST] <rcombs> like, min_framesize is in there because ??????? [04:33:19 CEST] <rcombs> but yeah, this would work for that [04:35:46 CEST] <jamrial> well, the point of codecs like flac is to guarantee the decoded bitstream is bitexact to the original raw stream. a checksum of the encoded data is useless for that :p [04:37:24 CEST] <jamrial> regarding your suggestion, there's also the case where you manually call the bsf with ffmpeg.c [04:37:56 CEST] <jamrial> the autobsf in mux.c gets the already filtered stream in that case [04:39:47 CEST] <jamrial> it could still catch the packet side data, i guess, but seems kinda fragile [13:39:25 CEST] <thardin> does fate need more machines? [13:55:24 CEST] <thardin> I may be taking custody of some retired cluster nodes [13:56:37 CEST] <atomnuker> x86's? [14:18:32 CEST] <thardin> I think so [14:30:41 CEST] <cone-532> ffmpeg 03Michael Niedermayer 07master:c51357d206f2: avcodec/wavpack: Fix runtime error: signed integer overflow: -1386217472 * 4 cannot be represented in type 'int' [14:30:41 CEST] <cone-532> ffmpeg 03Michael Niedermayer 07master:d8030c14bd7a: avcodec/sheervideo: Check input buffer size before allocating and decoding [14:30:41 CEST] <cone-532> ffmpeg 03Michael Niedermayer 07master:9c1812491f7b: avcodec/jpeg2000dec: Check tile offsets more completely [14:30:41 CEST] <cone-532> ffmpeg 03Michael Niedermayer 07master:781f88bb2653: avcodec/jpeg2000: Fix runtime error: signed integer overflow: 4185 + 2147483394 cannot be represented in type 'int' [15:29:24 CEST] <thardin> xeon 56, 16G RAM [15:38:43 CEST] <Compn> thats some nice hardware [15:38:52 CEST] Action: Compn still likes x86 kinda [15:39:17 CEST] Action: Compn makes note to remind friend about getting 64bit office [17:30:46 CEST] <michaelni> BBB, about "avcodec/webp: Fixes null pointer dereference", ive not received a reply from skal, can the patch be applied or do you prefer a different solution ? [17:31:54 CEST] <michaelni> i just into a 3rd case thats fixed by the patch [17:32:15 CEST] <michaelni> just RUN into [17:40:36 CEST] <michaelni> thardin, we always can use more testing [17:41:00 CEST] <michaelni> check fate.ffmpeg.org and see whats missing and what could be added [17:42:00 CEST] <michaelni> any other compilers, memory debuggers, emulated architectures, ... [17:45:27 CEST] <thardin> I guess one could run a whole bunch of VMs [18:30:04 CEST] <cone-909> ffmpeg 03Michael Niedermayer 07master:b9c032ebc0ad: avcodec/snow: Fix runtime error: signed integer overflow: 1086573993 + 1086573994 cannot be represented in type 'int' [18:30:04 CEST] <cone-909> ffmpeg 03Michael Niedermayer 07master:67b30decf779: avcodec/ylc: Check count in build_vlc() [18:30:04 CEST] <cone-909> ffmpeg 03Michael Niedermayer 07master:6b9cb5d26a2d: avcodec/aacdec_fixed: Fix runtime error: left shift of 1 by 31 places cannot be represented in type 'int' [18:57:40 CEST] <durandal_1707> michaelni: please revert d8030c14bd [18:58:58 CEST] <michaelni> durandal_1707, ok, should i list some reason ? [19:00:20 CEST] <durandal_1707> michaelni: formula is not clear to me [19:00:46 CEST] <durandal_1707> how you know it will always work? [19:02:45 CEST] <michaelni> durandal_1707, its approximately 25% of the minimal frame size, so to do W*H alloc and decode (W*H) time there needs to be W*H/4 bytes, this limts the time spend per byte [19:03:55 CEST] <michaelni> before the patch there was just a limit of fixed 20bytes [19:04:19 CEST] <michaelni> so a 20byte packet could lead to max resolution allocation and decode [19:09:15 CEST] <michaelni> s#W*H/4 bytes#W*H/16 bytes# [19:12:41 CEST] <durandal_1707> michaelni: it can stay, max compressed ratio it can archieve is less than 2x [19:13:46 CEST] <michaelni> durandal_1707, ok, anything i should do the clarify the check (like adding a comment?) or some other change you want me to do to it ? [19:14:26 CEST] <iive> adding comment is always good idea :D [19:15:26 CEST] <durandal_1707> michaelni: no [19:15:56 CEST] <michaelni> ok [19:40:10 CEST] <BBB> michaelni: the issue was that the alpha plane decodes but the pic buf is missing because its an invisible frame, right? [19:43:24 CEST] <BBB> michaelni: I guess apply it then, webp is intraonly and I dont really see the point of invisible keyframes in that context, but the bitstream allows it (probably to be vp8-compatible for hw purposes) so I really dont know if returning an error is ok, but I Guess its fine because I admit its pointless [19:43:44 CEST] <BBB> reason I wanted skal to respond is so we can do the same as libwebp [19:43:53 CEST] <BBB> but if he doesnt respond then whatever :) [19:44:59 CEST] <michaelni> BBB, ok, will push it on my next push, thanks [20:40:05 CEST] <Shiz> >unresolvable R_386_PC32 relocation against symbol `free' [20:40:09 CEST] <Shiz> whoops, wrong chan [20:56:01 CEST] <durandal_1707> michaelni: looks like libnut cant handle nut native files [20:57:27 CEST] <michaelni> is libnut maintained / used by anyone ? [20:58:35 CEST] <durandal_1707> its used by clueless mpv users [20:58:59 CEST] <jamrial> maybe we should remove the lavf wrapper [21:21:27 CEST] <cone-909> ffmpeg 03Michael Niedermayer 07master:67020711b7d4: avcodec/webp: Fixes null pointer dereference [21:21:28 CEST] <cone-909> ffmpeg 03Michael Niedermayer 07master:872bac81590c: avcodec/aac_defines: Add missing () to AAC_HALF_SUM() macro [21:21:56 CEST] <alevinsn> When I use a video encoder (H.264) and an audio encoder (opus), and start encoding such that the first raw inputted audio and video share the same time stamp [21:22:14 CEST] <alevinsn> why is it that the pts for the resulting encoded audio and video frames are different (for same time_base)? [21:22:49 CEST] <nevcairiel> audio encoders have delay, video can have re-ordering (although maybe not for the very first frame) [21:23:30 CEST] <alevinsn> so, for example, lets say audio is 48 kHz, and video has a frame rate of 29.97 (30000/1001) [21:23:58 CEST] <alevinsn> The first encoded audio sample gets a pts of 2778, while the first video frame gets a pts of 3003 [21:24:09 CEST] <alevinsn> for a timebase of 1:90000 [21:24:10 CEST] <alevinsn> for both [21:24:25 CEST] <alevinsn> what do you mean that audio encoders have delay? [21:25:03 CEST] <nevcairiel> a more accurate term is probably pre-roll or decoder priming data, which can in some cases be output before the actual audio [21:25:53 CEST] <alevinsn> so, that doesn't actually correspond to actual audio? [21:26:38 CEST] <nevcairiel> the difference between 2778 and 3003 happens to be 120 audio samples exactly, maybe that is a priming frame for opus [21:26:48 CEST] <alevinsn> I find that odd, because each of the decoded opus frames has the same number of samples, 960 [21:27:11 CEST] <alevinsn> nb_samples is the same for each subsequent decoded Opus frame [21:27:35 CEST] <nevcairiel> of course the priming data would not get decoded if the entire chain works properly [21:27:49 CEST] <nevcairiel> well, it would get decoded [21:27:51 CEST] <nevcairiel> but not ouput [21:28:15 CEST] <alevinsn> ok, next question, when I encoded, a specified time stamps of 0 for each of the input raw video and audio frames [21:28:33 CEST] <alevinsn> why does it gets a pts of 3003 for the first video frame then (which would correspond to the fourth video frame) [21:28:40 CEST] <alevinsn> first encoded video frame, I mean [21:28:55 CEST] <alevinsn> 0, 1001, 2002, 3003 [21:29:55 CEST] <alevinsn> hmm [21:30:13 CEST] <alevinsn> that would be if the time scale were actually 30000:1001 [21:30:18 CEST] <alevinsn> but, the time_base is 1:90000 [21:30:47 CEST] <alevinsn> oops, 3003 apparently corresponds to the first frame [21:31:01 CEST] <atomnuker> michaelni: in the aacsbr patch shouldn't you use FLT_EPSILON? [21:31:07 CEST] <alevinsn> 0, 3003, 6006 [21:31:36 CEST] <nevcairiel> it proably increased it by one to make room for the opus pre-roll [21:31:39 CEST] <alevinsn> maybe the idea is that it "starts" on the second video frame because it needs room for the decoder priming data? [21:31:44 CEST] <alevinsn> which starts a bit earlier? [21:31:45 CEST] <nevcairiel> since there cant be negative timestamps [21:31:54 CEST] <nevcairiel> (not in mpegts anyway) [21:31:56 CEST] <michaelni> atomnuker, FLT_EPSILON is much larger than FLT_MIN [21:32:40 CEST] <alevinsn> that makes sense--so, for playback purposes, would it be correct to always use the pts, even if the values don't seem to make sense? [21:32:53 CEST] <nevcairiel> what else would you do [21:32:57 CEST] <alevinsn> for audio/video synchronization [21:32:59 CEST] <nevcairiel> of course you u se the timestamps given [21:34:17 CEST] <alevinsn> ok, thanks [21:35:08 CEST] <alevinsn> one unrelated question--I've noticed that when, say using Blackmagic over a long period of time (at least 8 hours, let's say) [21:35:20 CEST] <alevinsn> because of the inaccuracy of the clocks in most modern PCs [21:35:28 CEST] <alevinsn> it tends to lose frames over time [21:35:42 CEST] <atomnuker> michaelni: I guess I've been doing it wrong then using EPSILON in the opus encoder [21:35:44 CEST] <alevinsn> that is, it doesn't quite output frames at the actual frame rate [21:36:15 CEST] <alevinsn> I know how to deal with this in my own code, but I'm wondering if ffmpeg does anything to keep things in sync with actual wall clock time? [21:36:24 CEST] <alevinsn> I imagine it can't do anything in practice [21:37:36 CEST] <alevinsn> since how would ffmpeg know that the computer's clock is slightly off [21:59:42 CEST] <rcombs> ffmpeg doesn't use wall clock time for much, but when it does, it assumes the computer's clock is accurate [22:34:11 CEST] <BBB> libnut :-o :-D [22:34:30 CEST] <jamrial> spring cleaning [22:34:35 CEST] <BBB> this validates my suspicion that theres a libxyz for every feature out there [22:34:48 CEST] <BBB> (and that most of these libraries are crap) [23:32:22 CEST] <nevcairiel> most of the libraries are old and exist back from a time when they still mattered, ie. they were the only one [23:38:55 CEST] <RiCON> and then they stay a few years so you can compare them with the native implementation [00:00:00 CEST] --- Mon May 29 2017