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

[burek]

[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_development_releases
[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