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

[burek]

[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