[00:00:09 CEST] <jamrial> ok, thanks [00:03:03 CEST] <alevinsn> jamrial: btw, I don't think it matters for a 0/9 e-mail [00:03:38 CEST] <alevinsn> but you misspelled "dependencies" in this one and the earlier one :-) [00:04:30 CEST] <nevcairiel> those mails are just for the ML, not like anyone really cares [00:05:34 CEST] <jamrial> meh, that one is not going to be commited anyway :p [01:19:52 CEST] <alevinsn> btw, where is this channel publicly logged? [01:23:48 CEST] <wm4> http://ffmpeg.gusari.org/irclogs/ [01:48:14 CEST] <cone-155> ffmpeg 03James Almer 07master:b3570f03893c: avcodec/decode: also check for FF_CODEC_CAP_SETS_PKT_DTS in audio decoders [01:50:00 CEST] Last message repeated 1 time(s). [03:44:22 CEST] <jamrial> gcc 7.1 compiles ffmpeg just fine and passes fate on x86_64 linux [03:46:20 CEST] <cone-155> ffmpeg 03Carl Eugen Hoyos 07master:a75ef1506a62: lavc/jpeg2000dec: Fix jp2 inner atom size used for overread checks. [03:47:40 CEST] <wm4> jamrial: is 7.1 the first gcc 7 release? [03:50:00 CEST] <jamrial> wm4: yeah [03:50:25 CEST] <wm4> that's amazing then [03:51:00 CEST] <jamrial> starting with gcc 5 the first release is the .1, to help differentiate between development builds and releases [04:39:03 CEST] <rcombs> oh, TIL [04:40:09 CEST] <james9999> in linuxese isn't it odd numbered subversions are unstable and even numbers ones are stable? [04:40:22 CEST] <james9999> so it's the same thing there? [04:41:31 CEST] <jamrial> no [04:42:18 CEST] <wm4> I think nobody does that anymore [04:45:21 CEST] <james9999> according to wikipedia the linux kernel used to do that but doesn't anymore [04:45:26 CEST] <james9999> that's where I heard about it [04:45:50 CEST] <james9999> https://en.wikipedia.org/wiki/Software_versioning#Odd-numbered_versions_for_... [04:57:28 CEST] <rcombs> node does something like that [04:58:40 CEST] <rcombs> hmm, is there an easy way to generate a stream with no packets in lavf? (trying to come up with a fate test that doesn't require a new binary sample) [05:06:12 CEST] <rcombs> alternately, what dir would it make sense to put a binary sample for MPEGTS, or general lavf behavior, in? [05:06:38 CEST] <rcombs> most of the dirs are named after either codecs or& where the samples came from, I guess? [05:29:35 CEST] <wm4> jkqxz: that was quite a lot of boilerplate refucktoring in the videotoolbox code... [05:30:02 CEST] <wm4> (regarding [PATCH] videotoolbox: add hwcontext support) [09:50:20 CEST] <ubitux> in an incoming merge, there is the introduction of an "avbuild" directory [09:50:28 CEST] <ubitux> is it ok to use "ffbuild"? [10:00:36 CEST] <durandal_170> wouldnt that causes issues later? [10:07:31 CEST] <ubitux> similar to avconv.c vs ffmpeg.c [10:10:13 CEST] <rcombs> does it matter if it's not user-visible? [10:10:23 CEST] <rcombs> (does it matter if it is?) [10:10:33 CEST] <rcombs> it's not like "av*" isn't used as a namespace in ffmpeg [10:10:50 CEST] <rcombs> probably wouldn't be that much work to change, but it'd be even less work to leave [10:11:46 CEST] <rcombs> (hot take: "ffmpeg" is a better name for a project than "libav", but "avconv" is a better name for a command-line tool) [10:12:02 CEST] <durandal_170> i dont care, [10:19:42 CEST] <atomnuker> ubitux: what's it for? [10:20:32 CEST] <ubitux> isolate random build files [10:22:23 CEST] <atomnuker> makefiles? [10:25:59 CEST] <atomnuker> anyway, I'd prefer ffbuild [10:50:59 CEST] <wm4> also config.log etc [12:13:32 CEST] <jkqxz> config.log moving isn't very nice. Everything else is good; tidies up some files you ~never look at. [12:15:17 CEST] <cone-092> ffmpeg 03Michael Niedermayer 07master:382b4fc9b5f3: avcodec/svq3: Increase offsets to prevent integer overflows [12:15:18 CEST] <cone-092> ffmpeg 03Michael Niedermayer 07master:48b311784417: avcodec/svq3: Reject dx/dy beyond 16bit [12:15:44 CEST] <jkqxz> wm4: Should we move the transfer-by-mapping into common code, then? (If the transfer function doesn't exist but map does, use it.) [12:17:37 CEST] <jkqxz> wm4: Wrt the type-mapping functions, elenril suggested a hwcontext error mapping function. Having type mapping like that could avoid adding the extra public symbols. [12:20:49 CEST] <wm4> jkqxz: sounds good, not sure what you mean by error mapping [12:22:31 CEST] <jkqxz> Something like "int av_hwdevice_error_string(AVBufferRef *device, char *buffer, size_t len, int error_code)". [12:23:39 CEST] <wm4> any relation o my patch? [12:23:42 CEST] <wm4> *to [12:25:43 CEST] <cone-092> ffmpeg 03Anton Khirnov 07master:45286a625c6c: h264dec: make sure to only end a field if it has been started [12:25:44 CEST] <cone-092> ffmpeg 03Clément BSsch 07master:2584656106bf: Merge commit '45286a625c6ced1f5c4c842244cbb4509429abba' [12:25:56 CEST] <jkqxz> I was just thinking of it as inspiration for "enum AVPixelFormat av_hwdevice_image_type_to_pixfmt(not_sure_what_type_t something)" and reverse functions rather than adding the specific av_map_videotoolbox_format_to/from_pixfmt() public functions. [12:26:41 CEST] <jkqxz> Maybe it's a bit too clumsy to actually be useful. [12:27:04 CEST] <cone-092> ffmpeg 03Alexandra Hájková 07master:fa64aea12ee6: unary: Convert to the new bitstream reader [12:27:05 CEST] <cone-092> ffmpeg 03Alexandra Hájková 07master:00c72a1e01a9: mlp: Convert to the new bitstream reader [12:27:06 CEST] <cone-092> ffmpeg 03Alexandra Hájková 07master:fc322d6a7018: tta: Convert to the new bitstream reader [12:27:07 CEST] <cone-092> ffmpeg 03Clément BSsch 07master:9d45454cd09a: Merge commit 'fc322d6a70189da24dbd445c710bb214eb031ce7' [12:27:24 CEST] <cone-092> ffmpeg 03Martin Storsjö 07master:a0c443a3980d: aarch64: vp9itxfm: Use the offset parameter to movrel [12:27:25 CEST] <cone-092> ffmpeg 03Clément BSsch 07master:9f1bca4e6f90: Merge commit 'a0c443a3980dc22eb02b067ac4cb9ffa2f9b04d2' [12:27:59 CEST] <wm4> AVPixelFormat av_map_from_hw_format(AVBufferRef *device, AVPixelFormat format, uint64_t hw_format) maybe [12:28:11 CEST] <wm4> or void *hw_format [12:28:48 CEST] <cone-092> ffmpeg 03Ruta Gadkari 07master:5b26d3b789bd: nvenc: Update check for lookahead [12:28:49 CEST] <cone-092> ffmpeg 03Clément BSsch 07master:bf0fde84d503: Merge commit '5b26d3b789bd19a32dbe1e9c7ccab9498de7ee9b' [12:29:21 CEST] <cone-092> ffmpeg 03Diego Biurrun 07master:f9edc734e0ca: ratecontrol: Drop xvid-rc-related struct members unused after a6901b9c6 [12:29:22 CEST] <cone-092> ffmpeg 03Clément BSsch 07master:c3e08544100c: Merge commit 'f9edc734e0ca3f6ef06c1ad0bd2c19c0c66f1ffa' [15:25:27 CEST] <ubitux> 11096804340ac2cec37ef1bce828105bd0a7dfbe [15:25:28 CEST] <ubitux> why? [15:26:09 CEST] <JEEB> back to 2011 :D [15:29:40 CEST] <ubitux> it's full of random revert [15:30:26 CEST] <BtbN> "this breaks my workflow" [15:31:27 CEST] <nevcairiel> nice of him to elaborate =p [15:33:01 CEST] <ubitux> http://ffmpeg.org/pipermail/ffmpeg-cvslog/2011-June/038509.html [15:33:20 CEST] <ubitux> i suppose it's about supporting running make into the lib subdir [15:33:37 CEST] <ubitux> which isn't supported anymore in ffmpeg, right? [15:34:09 CEST] <BtbN> it never was, but happened to work [15:34:13 CEST] <nevcairiel> does it work now? [15:34:26 CEST] <ubitux> (please tell me no) [15:36:03 CEST] <RiCON> nevcairiel: it works now, there's still the include ../config.mak [15:36:18 CEST] <nevcairiel> well just one line might not be enough to make it work =p [16:55:06 CEST] <cone-092> ffmpeg 03Diego Biurrun 07master:11a9320de547: build: Move build-system-related helper files to a separate subdirectory [16:55:07 CEST] <cone-092> ffmpeg 03Clément BSsch 07master:3f17751eeb7e: Merge commit '11a9320de54759340531177c9f2b1e31e6112cc2' [17:02:50 CEST] <ubitux> huh, we still have --enable-raise-major? [17:03:02 CEST] <ubitux> the shit is this fuck again? [17:27:51 CEST] <cone-092> ffmpeg 03Michael Niedermayer 07master:dec2fa8cc708: tools/target_dec_fuzzer: Use decoder and not codec_id as argument [22:43:30 CEST] <alevinsn> nevcairiel: you there? [23:20:41 CEST] <alevinsn> any way to run just a specific fate test? [23:22:07 CEST] <jkqxz> make fate-name-of-test [23:22:30 CEST] <jkqxz> Some groupings also work, like fate-h264. [23:23:04 CEST] <alevinsn> don't use SAMPLES= in that case? [23:23:31 CEST] <jkqxz> Um, probably? I always put --samples on my configure line, so don't think about it afterwards. [23:24:08 CEST] <alevinsn> ok, that worked [23:24:18 CEST] <wm4> without SAMPLES (and if no sample dir is configured) it will run only tests that don't require samples, AFAIK [23:27:52 CEST] <alevinsn> anyone here have any experience building on Windows with MSVC? [23:28:02 CEST] <alevinsn> I could swear that I got past this point in the past [23:28:10 CEST] <alevinsn> but when I use make fate (with or without SAMPLES) [23:28:16 CEST] <alevinsn> it is failing to build checkasm [23:28:21 CEST] <alevinsn> because of some missing __imp symbols [23:31:52 CEST] <alevinsn> anyone know why make fate rebuilds libavcodec, etc? [23:32:00 CEST] <alevinsn> why doesn't it just use the .dlls that are already built? [23:32:16 CEST] <wm4> maybe you changed the code? [23:32:21 CEST] <alevinsn> nope [23:32:34 CEST] <alevinsn> it generates .a files when I do make fate [23:32:38 CEST] <alevinsn> order was [23:32:50 CEST] <alevinsn> make testclean; make clean; make distclean; (probably overkill) [23:33:04 CEST] <alevinsn> ./configure ...; make V=1; make fate [23:33:09 CEST] <alevinsn> no changes to the code [23:33:34 CEST] <wm4> it does build some test programs over default make [23:33:51 CEST] <alevinsn> it wants a libavdevice.a file for some reason (static build, although I doubt it is truly static) [23:34:09 CEST] <alevinsn> but, you don't think it should be rebuilding the various shared libraries, right? [23:34:10 CEST] <nevcairiel> fate runs with shared libraries just fine, although sometimes needs a bit trickery to actually make it find the .dlls for some test programs [23:34:15 CEST] <nevcairiel> and no it wouldnt do such a rebuild [23:34:46 CEST] <alevinsn> on Windows, I've only ever seen it build libavdevice.a, libavfilter.a, etc [23:34:54 CEST] <alevinsn> after it successfully builds the DLLs [23:35:30 CEST] <J_Darnley> That's the gcc equivalent for the MSVC .lib files [23:35:36 CEST] <alevinsn> right [23:35:42 CEST] <alevinsn> but I'm not using gcc :-) [23:35:57 CEST] <alevinsn> here's an example command-line [23:35:58 CEST] Action: J_Darnley thinks he should be ignored [23:36:14 CEST] <alevinsn> skipping strip -wN ..@* tests/checkasm/x86/checkasm.o [23:36:14 CEST] <alevinsn> rm -f libavdevice/libavdevice.a [23:36:14 CEST] <alevinsn> lib -nologo -out:libavdevice/libavdevice.a libavdevice/alldevices.o libavdevice/avdevice.o libavdevice/decklink_common.o libavdevice/decklink_dec.o libavdevice/decklink_dec_c.o libavdevice/decklink_enc.o libavdevice/decklink_enc_c.o libavdevice/file_open.o libavdevice/lavfi.o libavdevice/utils.o [23:36:14 CEST] <alevinsn> : libavdevice/libavdevice.a [23:37:27 CEST] <alevinsn> one odd bit is that it is using lib instead of mslink [23:37:52 CEST] <alevinsn> and the other odd bit is that it wants .a files [23:38:03 CEST] <nevcairiel> if you build shared for msvc, you should probably also pass disable static just to make sure, msvc cant build both at the same time like gcc can [23:38:27 CEST] <alevinsn> I'm doing that [23:38:37 CEST] <alevinsn> ./configure --toolchain=msvc --enable-yasm --enable-asm --enable-shared --disable-static --enable-decklink --enable-libmfx --disable-nvenc --disable-cuda --disable-cuvid --disable-indev=gdigrab --disable-indev=vfwcap --disable-indev=dshow --extra-cflags=-arch:AVX2 [23:41:07 CEST] <nevcairiel> in any case to use fate from a shared build you need to install the binaries and make sure they are in the path, otherwise it wont be able to load the dlls [23:42:38 CEST] <alevinsn> yeah, I've done that, and it can find ffmpeg [23:42:47 CEST] <alevinsn> etc etc [23:42:54 CEST] <alevinsn> and run it [23:43:08 CEST] <alevinsn> by just invoking ffmpeg--but, still not sure what to do for the build failures [23:43:19 CEST] <alevinsn> have to go through--I'll see what I can figure out later, thanks [23:43:36 CEST] <nevcairiel> well it works just like expected here [23:44:42 CEST] <nevcairiel> configure --toolchain=msvc --enable-shared --prefix=/d/somedir/in/path && make && make install && make fate [23:44:46 CEST] <nevcairiel> no rebuiilds in static [23:46:56 CEST] <nevcairiel> in any case no reason to run fate in a shared build, its more effort either way with the installing and whatnot [23:48:10 CEST] <nevcairiel> oh i see whats going on, checkasm is special since it needs to access avcodec internal stuff to work [23:48:40 CEST] <nevcairiel> but the msvc shared builds objects are probably not quite compatible with that [23:48:46 CEST] <nevcairiel> ie. just run fate in static =p [23:49:04 CEST] <nevcairiel> (or well, skip checkasm anyway) [00:00:00 CEST] --- Thu May 4 2017