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

Fri Jan 9 02:05:02 CET 2015

[00:24] <cone-947> ffmpeg.git 03Alexandre Colucci 07master:5a1addd7c1d8: xsub: Support DXSA subtitles
[00:24] <cone-947> ffmpeg.git 03Michael Niedermayer 07master:3ed80bd95e1d: Merge commit '5a1addd7c1d8ff218ed4b84f4f02fdb83980094c'
[02:07] <Timothy_Gu> wbs: to recap the ac_slater's issue: 1. Android API Level <= 17 contains a broken math.h header that does not declare log2(). 2. The issue is fixed in API Level 18, but only in NDK version 9b+. 3. He could not compile the thing he was building with API Level 19, only 17. 4. He tried building with both, and only 19 works. 5. I don't know the *exact* NDK he is using although theoretically as long as it is >=9b it doesn't matter. 6. log2 seem
[02:08] <Timothy_Gu> wbs: see https://developer.android.com/tools/sdk/ndk/index.html: `Updated include/android/*h and math.h for all Android API levels up to 18`
[02:08] <Timothy_Gu> (9b changelog)
[02:09] <Timothy_Gu> 9 apparently supported API level 18 as well, but still with the broken math.h
[02:10] <cone-947> ffmpeg.git 03wm4 07master:bcaa9099b364: avcodec/dvdsubdec: error on bitmaps with size 0
[02:10] <Timothy_Gu> wbs: see the broken header: https://github.com/android/platform_bionic/blob/android-4.2.2_r1.2/libm/include/math.h
[02:11] <Timothy_Gu> wbs: commit that fixed it: https://github.com/android/platform_bionic/commit/a0ee07829a9ba7e99ef68e8c12551301cc797f0f
[02:13] <Timothy_Gu> and the ndk headers are synced to bionic's in https://android-review.googlesource.com/#/c/68014/
[03:18] <cone-947> ffmpeg.git 03Lou Logan 07master:919e038a95fd: doc: fix typos
[03:20] <aetasx> have you guys seen any issues with linking against an ffmpeg lib built with --enable-lto and using -ffat-lto-objects?
[05:29] <cone-947> ffmpeg.git 03Michael Niedermayer 07master:1d2410639d9d: doc/examples/muxing: Use avio_closep() in examples as it avoids leaving stale pointers
[05:29] <cone-947> ffmpeg.git 03Michael Niedermayer 07master:c61b84ccfda1: doc/examples/transcode_aac: Use avio_closep() in examples as it avoids leaving stale pointers
[05:29] <cone-947> ffmpeg.git 03Michael Niedermayer 07master:a63c17cec723: idoc/examples/remuxing: Use avio_closep() in examples as it avoids leaving stale pointers
[05:30] <cone-947> ffmpeg.git 03Michael Niedermayer 07master:a85f033149a6: doc/examples/transcoding: Use avio_closep() in examples as it avoids leaving stale pointers
[05:37] <Timothy_Gu> aetasx: not really, but that's probably because nobody here uses it
[07:11] <ac_slater> hey guys. I'm working through some ./configure issues. I would spend a bunch of time narrowing this down, but maybe you guys know. When building with --enable-programs, ffmpeg.o is looking for the symbol `ff_isom_write_hvcc` but it's undefined in my libavformat. I tried enable hecv parsers, etc. Any clue?
[07:12] <ac_slater> ie - trying to find what provides that symbol
[07:14] <ac_slater> oh... matroska
[07:16] <Timothy_Gu> ac_slater: i think that's a known bug
[07:16] <ac_slater> Timothy_Gu: Im trying to just enable matroska mux/demux and parser to see
[07:17] <ac_slater> Timothy_Gu: thanks!
[07:17] <Timothy_Gu> ac_slater: wait no
[07:18] <Timothy_Gu> ac_slater: can you confirm libavformat/hevc.o is built?
[07:18] <Timothy_Gu> ac_slater: and also, what release are you using?
[07:19] <Timothy_Gu> ac_slater: libavformat/hevc.c supplies that symbol
[07:21] <ac_slater> Timothy_Gu: release 2.5
[07:22] <ac_slater> Timothy_Gu: and no, I'm not building HEVC ... hmm. 
[07:22] <Timothy_Gu> ac_slater: no, the hevc.o object file doesn't mean hevc decoder
[07:22] <ac_slater> Timothy_Gu: I guess I need it ;). Parser? Mux/Demux?
[07:22] <Timothy_Gu> ac_slater: the muxer need it
[07:23] <Timothy_Gu> ac_slater: libavformat/hevc.c file contains some muxer routines that are not related to the decoder
[07:23] <Timothy_Gu> ac_slater: so try to see if hevc.o is built
[07:23] <ac_slater> Timothy_Gu: yea it doesnt get built
[07:42] <ac_slater> Timothy_Gu: well. I dont really know enough ffmpeg'
[07:42] <ac_slater> Timothy_Gu: to solve this. I tried enable just the hevc muxer and the symbol still isnt there. What do you think I should enable?
[07:45] <jamrial> check libavformat/Makefile, search for hevc.o
[07:46] <jamrial> matroska, webm, mov or rtp muxers
[07:48] <ac_slater> jamrial: interesting. I do need the RTP muxer
[07:48] <Timothy_Gu> jamrial: hevc.o is in matroska muxer
[07:49] <Timothy_Gu> s/(in)/included \1/
[07:49] <jamrial> i know, that's why i mentioned it
[07:55] <Timothy_Gu> looking at http://sprunge.us/cRbQ he did enable matroska
[07:55] <Timothy_Gu> ac_slater: that's odd
[07:56] <Timothy_Gu> ac_slater: check libavformat/Makefile and find the line with OBJS-$(CONFIG_MATROSKA_MUXER)
[07:56] <Timothy_Gu> ac_slater: can you see "hevc.o" there?
[07:58] <ac_slater> Timothy_Gu: that paste didnt have the matroska enabled since, well, I dont need it ;)
[07:59] <ac_slater> Timothy_Gu: oh wait, that paste doesnt disable anything, it just added the android flags, etc.
[08:00] <ac_slater> So the question remains, if I want to build the ffmpeg binary, should I just enable matroska ?
[08:07] <jamrial> you shouldn't need to, really. not sure why it told you ffmpeg.o needed ff_isom_write_hvcc. ffmpeg.c doens't call it
[08:08] <Timothy_Gu> ac_slater: jamrial is right. Can you show the **exact** error?
[08:38] <ac_slater> Timothy_Gu: uploading paste now
[08:39] <ac_slater> Timothy_Gu: http://paste.debian.net/plain/139668
[08:39] <ac_slater> I guess this isnt for ffmpeg.o
[08:39] <ac_slater> it's obviously not since the error is for libavformat.so
[08:40] <Timothy_Gu> ac_slater: can you try make distclean and reconfigure with static libs instead of shared libs?
[08:41] <Timothy_Gu> two things might be happening: 1. just a configure remnant from a previous build causing the issue; 2. there's a problem with the build system and using static helps debugging this kind of issue
[08:44] <ac_slater> Timothy_Gu: gotcha. I create the complete new tree every build. And even if static worked I could use it since I'd violate GPL :(
[08:46] <Timothy_Gu> ac_slater: I think you meant LGPL
[08:46] <ac_slater> Timothy_Gu: yes.
[08:46] <Timothy_Gu> ac_slater: but anyways this is just for debugging
[08:46] <ac_slater> Timothy_Gu: true. And it did work with a static build
[08:47] <Timothy_Gu> interesting. can you try shared again from a clean tree?
[08:53] <Timothy_Gu> gotta sleep now
[08:54] <Timothy_Gu> bye
[14:21] <Daemon404> i wonder how many bugs can be summed up as "i dont understand how vsync works"
[14:31] <aetasx> on that note, I tried finding a tool that would let me resync things the way ffplay and vlc seems to play them but wasnt able
[14:42] <kierank> Daemon404: more like people don't understand vfr
[14:42] <nevcairiel> vfr is evil
[14:43] <nevcairiel> our screens are not vfr, why would you make video that way :D
[14:43] <cone-173> ffmpeg.git 03Michael Niedermayer 07master:558cef886054: ffmpeg_opt: Use avio_closep() to avoid leaving stale pointers in memory
[14:43] <cone-173> ffmpeg.git 03Michael Niedermayer 07master:78cb3c069d15: ffmpeg: Use avio_closep() to avoid leaving stale pointers in memory
[14:43] <cone-173> ffmpeg.git 03Michael Niedermayer 07master:eb3e661babfd: ffserver: Use avio_closep() to avoid leaving stale pointers in memor
[14:43] <cone-173> ffmpeg.git 03Michael Niedermayer 07master:e5993aeb606e: avdevice/lavfi: Use avio_closep() to avoid leaving stale pointers in memory
[14:43] <cone-173> ffmpeg.git 03Michael Niedermayer 07master:b565fd44642c: avformat/hdsenc: Simplify code by using avio_closep()
[14:44] <wm4> <nevcairiel> our screens are not vfr, why would you make video that way :D <- they're about to fix this
[14:44] <kierank> hopefully will do it properly too
[14:44] <nevcairiel> if you refer to GSYNC or Adaptive Sync, its a gaming feature, dont expect TVs to ever have that
[14:44] <kierank> timestamp + duration
[14:45] <Daemon404> kierank, not a fan of matroska?
[14:45] <Daemon404> ;)
[14:45] <kierank> of course not
[14:45] <kierank> timestamp alone is moronic
[14:45] <wm4> matroska also has a fps field (as float)
[14:46] <kierank> that's just metadata
[14:46] <nevcairiel> matroska has a BlockDuration element, so you can have timestamp + duration
[14:47] <kierank> it should be mandatory
[14:47] <wm4> matroska has no dts though
[14:47] <nevcairiel> its probably mostly used for subtitles
[14:48] <aetasx> can only see vfr as saving storage for crappy video
[14:49] <aetasx> which I have lots of :/
[14:49] <nevcairiel> well in theory it could make sense to reduce the number of frames when you dont need them as the video is not moving, but on the other hand with predicted frames encoding those takes practically no space so why bother with the complexity
[14:49] <kierank> ricing
[14:50] <aetasx> nevcairiel: mostly realtime streaming being the problem
[14:52] <aetasx> if you get trashed sync, is there a way to fix it the way ffplay manages to?
[15:07] <cone-173> ffmpeg.git 03Michael Niedermayer 07master:50bb9b87ab6f: avformat/img2enc: Use avio_closep() to avoid leaving stale pointers in memory
[15:07] <cone-173> ffmpeg.git 03Michael Niedermayer 07master:26c72d2941d9: avformat/img2dec: Use avio_closep() to avoid leaving stale pointers in memory
[15:07] <cone-173> ffmpeg.git 03Michael Niedermayer 07master:bf3126db6a60: avformat/hlsenc: Use avio_closep() to avoid leaving stale pointers in memory
[15:09] <wm4> I keep wondering what the fuck the point of these commits is, when the functions they're used in are called before deallocation anyway
[15:10] <Daemon404> Code Defensively (TM)
[15:20] <aetasx> you trademark that?
[15:21] <aetasx> Daemon, how familiar are you with --enable-lto for ffmpeg?
[15:22] <Daemon404> it's broken on mostly everything because of asm symbols iirc.
[15:22] <Daemon404> also, why me
[15:23] <TimNich> you Know Everything (") ;)
[15:23] <aetasx> because I had an impression you would know and it wasnt the first time I had asked
[15:25] <aetasx> it seems to work fine internally but including a lto-linked ffmpeg library in this case within x264 does break within the configure script due to the asm issues
[15:26] <aetasx> I chalked it up to mingw64 stupidity though
[15:27] <Daemon404> if you made a .a, it is not lto linked.
[15:27] <Daemon404> the emited bytecode is just added to teh ar archive.
[15:27] <Daemon404> no linking is done
[15:28] <aetasx> I know, but -flto is passed into those objects, the actual flto errors out during the x264 configuration conftest part
[15:28] <Daemon404> i would check if lto is even properly being used in the conftest checks.
[15:29] <aetasx> yeah they are, it comes out with that typical "asm" constraints error
[15:29] <aetasx> for some mmx function wihtin swscale
[15:29] <Daemon404> lto is not very useful anyway
[15:30] <aetasx> it strips quite a lot of code out of a static build
[15:31] <Daemon404> it is limited as to what it can do to ffmpeg, due to things like av_register_all() existing
[15:31] <Daemon404> (sometimes ive seen output be larger)
[15:32] <aetasx> the ffmpeg I built through linking in -flto extra libraries and running --enable-flto on the ffmpeg built is somewhat around 2-4mb less in size
[15:32] <aetasx> without the external libraries, thats probably the case
[15:33] <Daemon404> using lto-built external libs does nto require lto-build ffmpeg fwiw
[15:36] <aetasx> you'd have to pass in -fuse-linker-plugin and -flto to ldflags and I wanted to apply flto to the ffmpeg objects regardless
[15:36] <aetasx> it works fine in binary builds of ffmpeg, just screws with the libraries when getting included into other things
[15:38] <aetasx> right now though I think the only lto build problems are a result of mingw64's recent idiotic pthreads commits
[15:39] <nevcairiel> lto never worked for me, and i dont use pthreads
[15:39] <aetasx> nevcairiel: you know that commit I showed you before?
[15:40] <aetasx> Heres what it is now: http://sourceforge.net/p/mingw-w64/mingw-w64/ci/5eb74fa49b3b34e21c98f85c6db2241c36bc102c/
[15:40] <aetasx> all the flto built errors are: input/lavf.o (symbol from plugin):(.text+0x0): multiple definition of `asctime_r'
[15:41] <nevcairiel> did you like disable inline asm? mine fails much earlier on that
[15:41] <aetasx> nah, didnt need to
[15:42] <aetasx> when I build ffmpeg with lto, Im passing in -ffat-lto-objects though so non-lto builds still build properly
[15:44] <aetasx> within the configure script for x264 though, even if you don't pass in flto or fuse-linker-plugin, it is still invoked when it hits lto-built objects due to some configure script wrapper I think
[15:45] <aetasx> but these asctime_r errors are the exact same type of crap I was experiencing before so Im guessing its still more mingw64 screwyness
[15:53] <aetasx> Daemon404: you said you saw flto builds bigger in size when running them before.  are you sure this isn't due to not adding in -ffat-lto-objects in the ffmpeg's --enable-lto options?  the gcc docs say without it, the builds can end up larger
[15:53] <aetasx> or do you think there's something else going on?
[15:53] <Daemon404> i personally do not care about lto, and thus cannot be arsed to look.
[15:54] <aetasx> thats pretty close to my own feeling ;)
[16:12] <wm4> why would you use lto anyway
[16:13] <aetasx> [09:31] <aetasx> the ffmpeg I built through linking in -flto extra libraries and running --enable-flto on the ffmpeg built is somewhat around 2-4mb less in size
[16:14] <wm4> you're probably better off by disabling all the dumb unneeded shit
[16:14] <wm4> like game format decoders
[16:15] <aetasx> thats not really the purpose of this project, its for a build-script system that builds and links multimedia tools.  making assumptions about what they do or don't need isn't really my place
[16:17] <aetasx> its like zeranoe's build scripts
[16:20] <aetasx> plus I get more experience having gone through the nightmare itself ;)
[16:30] <Snaggle1> Is the AVFoundation indev on ffmpeg supposed to have an OS X min version for building?  When autodetected to build, it tries to link to the CoreGraphics framework, but that only exists as a standalone framework from 10.8 and up. However, the detection code only checks for the presence of the AVFoundation.h header. Compilation of libavutil.54.dylib on 10.7 fails with "ld: framework not found CoreGraphics"
[16:44] <wm4> michaelni_: for me, fate-sub2video fails even before my patches
[16:45] <wm4> oh, I guess it uses system ffmpeg, wtf
[16:46] <Daemon404> wtf?
[16:48] <wm4> hm, double-checking it, this is not the case
[16:51] <wm4> but the test still fails
[16:53] <wm4> the only difference is actually that my output is missing stream 0
[17:05] <cone-173> ffmpeg.git 03Carl Eugen Hoyos 07master:26ac6d543598: lavfi/boxblur: Readd 8bit colour spaces on big-endian.
[17:14] <wm4> updating magically fixed it
[17:15] <nevcairiel> magic is always a good solution
[17:20] <saste> nevcairiel, only when it works
[17:27] <cone-173> ffmpeg.git 03Martin Storsjö 07master:71ec3d36fa61: doc: Add initial documentation about the OpenH264 encoder wrapper
[17:27] <cone-173> ffmpeg.git 03Michael Niedermayer 07master:de8f70b8e02d: Merge commit '71ec3d36fa6122b3b6c5c68a21b9c70cb2e668e8'
[17:35] <cone-173> ffmpeg.git 03Martin Storsjö 07master:3852e2c926dd: libopenh264enc: Fix a typo and some nitpicks
[17:35] <cone-173> ffmpeg.git 03Michael Niedermayer 07master:93870f0a0b71: Merge commit '3852e2c926ddb166c7aa69c4644a86100ea144d9'
[17:43] <aetasx> *sigh* http://sourceforge.net/p/mingw-w64/mailman/message/33212333/
[17:43] <aetasx> wm4: you're right, these people are idiots
[17:44] <cone-173> ffmpeg.git 03Martin Storsjö 07master:2dbd35b00c64: libfdk-aacdec: Make sure decoding doesn't add any extra delay in the latest version of fdk-aac
[17:44] <cone-173> ffmpeg.git 03Michael Niedermayer 07master:3fd3647fdc5b: Merge commit '2dbd35b00c6433e587d5f44d5dbc8972ebbaa88e'
[17:48] <wm4> aetasx: did I say that? I think it was someone else
[17:49] <wm4> in any case, mingw itself is a somewhat idiotic project, because it hogs on an ancient unsupported msvcrt dll
[17:52] <aetasx> actually you did say it was run by idiots ;)
[17:53] <funman> tmatth: no idea how hard it would be to decode bpg
[17:55] <aetasx> mingw-w64 specifically
[17:55] <wm4> meh
[17:55] <aetasx> oh no you said it was a bad commit, it was nevcairiel that said it was run by morons ;)
[18:01] <Daemon404> i wouldnt consider them morons
[18:01] <Daemon404> they provide a massive effort wrt CRT and the only working and update FOSS compiler for windows
[18:02] <Daemon404> protip: shitting on the hand that feeds is a terrible idea
[18:02] <Daemon404> and you come off as an as.
[18:02] <Daemon404> ass*
[18:02] <aetasx> nah, we were just having a discussion of their breaking things a number of times a few in the crt and headers
[18:03] <Daemon404> protip 2: thats why they have releases
[18:03] <Daemon404> its youre own fault if you use HEAD
[18:03] <aetasx> where did I mention using HEAD?
[18:03] <Daemon404> most of the breakage in headers that have been linked here were never in any release.
[18:04] <Daemon404> and compaining about them is thsu pretty silly.
[18:04] <cone-173> ffmpeg.git 03wm4 07master:816577716bc6: avcodec/dvdsubdec: fix accessing dangling pointers
[18:05] <aetasx> msys2 only does releases based on that, Alexey being the dev of that project
[18:05] <Daemon404> msys2 is unrelated to toolchains.
[18:05] <Daemon404> msys2 is an environment
[18:05] <aetasx> an environment that provides build releases
[18:06] <Daemon404> they HAPPEN to have a toolchain package, and its their fault for using HEAD
[18:06] <Daemon404> its the packagers fault i your toolchain is broken then
[18:06] <Daemon404> if*
[18:06] <aetasx> and the project maintainer is on the mingw-w64 group
[18:06] Action: wm4 still hopes for midipix
[18:06] <Daemon404> he is not a mingw-w64 core devel
[18:06] <Daemon404> or even a contributer
[18:06] <Daemon404> he is a thrid party mostly.
[18:08] <aetasx> why is this even relevant?  I didn't say they were morons
[18:08] <Daemon404> [16:43] < aetasx> wm4: you're right, these people are idiots
[18:08] <Daemon404> orly
[18:09] <aetasx> nev was referring to the management of their pthreads built-in library
[18:09] <Daemon404> in context, you were not referring to that
[18:09] <Daemon404> see your link. it is not about their pthreads lib.
[18:09] <aetasx> no, what I was doing was referrencing someone elses comment
[18:10] <Daemon404> right. so you link to some unrelated thing, and then comment implicitly about pthreads.
[18:10] <Daemon404> yea seems legit.
[18:10] <Daemon404> anyway /care
[18:10] Action: Daemon404 gets coffee
[18:11] <aetasx> except its the pthreads lib that gets broken due to POSIX defines
[20:09] <sectroyer> Hello. I have raw video with nv16 pixel format but when I try to play it with ffplay I get this error:
[20:10] <sectroyer> Impossible to convert between the formats supported by the filter 'ffplay_buffer' and the filter 'auto-inserted scaler 0'
[20:31] <cone-173> ffmpeg.git 03Michael Niedermayer 07master:e360d030b362: avformat/rtsp: Use avio_closep() to avoid leaving stale pointers in memory
[20:31] <cone-173> ffmpeg.git 03Michael Niedermayer 07master:f9ddaa35c7d9: avformat/rtpenc_chain: Use avio_closep() to avoid leaving stale pointers in memory
[20:32] <cone-173> ffmpeg.git 03Michael Niedermayer 07master:07e4ed5637f5: avformat/mov: Use avio_closep() to avoid leaving stale pointers in memory
[20:32] <cone-173> ffmpeg.git 03Michael Niedermayer 07master:edeaf6f3a4d7: avformat/mlvdec: Simplify code by using avio_closep()
[20:32] <cone-173> ffmpeg.git 03Michael Niedermayer 07master:d1d8f866b540: avformat/mlvdec: Use avio_closep() to avoid leaving stale pointers in memory
[20:51] <wm4> sectroyer: libswscale apparently can't handle this format
[20:52] <sectroyer> wm4: hmmm than what should I do? I have rawvideo data that I would like to play/rencode...
[20:52] <wm4> nothing you can do, other than hacking libswscale, or hoping that someone else does, or converting the format yourself
[21:02] <kierank> iirc swscale does support nv16
[21:02] <kierank> apparently not
[21:02] <wm4> at least it doesn't report it
[23:10] <cone-173> ffmpeg.git 03Michael Niedermayer 07master:6d1a2efb8ac3: ffmpeg: Clear error message array at init.
[23:14] <nevcairiel> Daemon404: at least their pthreads lib is quite moronic :P it doesn't work for shit
[23:15] <nevcairiel> And just because it's the only thing we have doesn't make many of their actions any better
[23:15] <wm4> I made my own pthread wrapper now
[23:15] <nevcairiel> But I stick to my own builds using releases and generally don't run into big problems
[23:16] <wm4> it was pretty simple, though no XP compat
[23:16] <nevcairiel> For FFmpeg I use w32threads, don't really build anything elaey
[23:16] <nevcairiel> Else*
[23:16] <jamrial> i missed the msys2 chat. was it about how their mingw64 packages got an update that broke ffmpeg yesterday or so?
[23:17] <jamrial> because i had that issue. fortunately they fixed it already
[23:17] <nevcairiel> I didn't try msys2 yet, but everything I hear about it makes me not want to
[23:17] <jamrial> i wonder why they use mingw64 HEAD, though
[23:17] <jamrial> things break too often
[23:18] <nevcairiel> Even if I would use msys2, I would probably just use their msys parts and stick to my own toolchain
[23:18] <nevcairiel> I like control :)
[23:19] <jamrial> same. i'm thinking about doing that since their mingw64 toolchain is not 100% static, and i don't like having to rely on dlls
[23:20] <jamrial> especially the winpthreads one that i don't use. i use w32threads
[23:20] <nevcairiel> I have pthreads-w32 in my toolchain if I need one implementation for something else, but yeah
[23:22] <nevcairiel> Using pthreads-w32 together with my MSVC code leaks thread handles though, there is some weirs incompatibility there
[23:22] <nevcairiel> But w32threads works just fine so I don't care
[23:25] <wm4> I think pthreads-w32 requires you to "register" new threads not created by it?
[23:25] <wm4> with pthread_win32_thread_attach_np() and pthread_win32_thread_detach_np()
[23:26] <wm4> needed when doing static linking
[23:27] <aetasx> ah, yeah I dont use MSVC for any of this stuff
[23:28] <aetasx> jamrial: you're right about that.  the project that I use and help with for building multimedia libs just goes through and renames all .dll.a files to something else if it can find a static lib
[23:29] <wm4> what project is that?
[23:29] <aetasx> https://github.com/jb-alvarado/media-autobuild_suite
[23:29] <wm4> ah
[23:29] <aetasx> it builds maybe like 30 different libs/binaries for multimedia stuff
[23:30] <jamrial> if you mean renaming the .dll.a so the linker uses the .a files instead, you could just use -static when linking
[23:30] <aetasx> ffmpeg, mp4box, mplayer, mpv, mkvtoolnix, f265, x264, x265 etc
[23:30] <wm4> I guess it's easier for single projects with specific own solutions
[23:30] <aetasx> that doesn't work so well actually, some projects screw it up when building
[23:32] <aetasx> theres a lot of libraries that are only built as shared which I'm not wild about
[23:33] <wm4> windows is strangely the only OS left where static linking is preferred over dynamic for dependencies
[23:34] <aetasx> bitter memories over the old dll hell days
[00:00] --- Fri Jan  9 2015