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

[burek]

[00:00:37 CEST] <nevcairiel> somehow i doubt c99wrap is actuially going to like cpp files though
[00:00:56 CEST] <nevcairiel> but it wouldnt build before, so even if it doesnt build after =p
[00:01:05 CEST] <alevinsn> possibly, but I didn't feel like trying to build with Visual Studio 2012 when I already have 2015 and knew it would be more of a pain
[00:01:19 CEST] <BtbN> Are there even any c++ files in ffmpeg?
[00:01:27 CEST] <nevcairiel> the decklink device
[00:01:28 CEST] <alevinsn> yes, the decklink ones
[00:01:37 CEST] <nevcairiel> mostly because its API is pure c++
[00:01:50 CEST] <alevinsn> technically, at least on Windows, you can use COM from C code, although it is much more of a pain
[00:02:09 CEST] <alevinsn> but on Linux (and possibly OS/X too?), perhaps C++ is a requirement to use the Blackmagic headers
[00:03:02 CEST] <wm4> depends if they offer COBJMACROS stuff
[00:04:02 CEST] <BtbN> I'm pretty sure ffmpeg does use COM from C
[00:04:08 CEST] <BtbN> for dshow or something
[00:05:31 CEST] <alevinsn> yeah it does
[00:05:35 CEST] <wm4> BtbN: also d3d
[00:05:39 CEST] <nevcairiel> yeah but you rely on the headers defining C COM apis
[00:05:41 CEST] <nevcairiel> not all do that
[00:05:49 CEST] <alevinsn> have to do stuff like IMediaControl_Stop(ctx->control);
[00:06:00 CEST] <alevinsn> rather than ctx->control->Stop();
[00:06:16 CEST] <wm4> I prefer the former anyway
[00:06:19 CEST] <nevcairiel> (I still wonder how that magic even works with the typical C++ vtbls)
[00:06:28 CEST] <alevinsn> I prefer the latter :-)
[00:06:28 CEST] <wm4> just that sometimes function names get absurdly long
[00:06:34 CEST] <wm4> nevcairiel: because it was designed this way
[00:07:02 CEST] <alevinsn> When processed with the IDL tool, at least on Windows
[00:07:16 CEST] <alevinsn> it usually generates a version of the header files that is suitable for C
[00:07:27 CEST] <alevinsn> Although I've always used from C++ code
[00:07:44 CEST] <nevcairiel> I really dont like working with the C COM stuff
[00:08:06 CEST] <nevcairiel> but I did the C++ verion for years before ever touching the C stuff, so its just what I am used to anyway
[00:09:15 CEST] <alevinsn> I prefer ATL in combination with COM over straight COM
[00:09:36 CEST] <cone-875> ffmpeg 03Andreas Cadhalpun 07master:8c3a643808fc: libschroedingerdec: don't produce empty frames
[00:09:37 CEST] <cone-875> ffmpeg 03Andreas Cadhalpun 07master:dc2ad094931d: libschroedingerdec: fix leaking of framewithpts
[00:09:38 CEST] <cone-875> ffmpeg 03Andreas Cadhalpun 07master:fc85646ad495: libopusdec: fix out-of-bounds read
[00:09:38 CEST] <alevinsn> CComPtr<IMediaControl> pMediaControl;
[00:09:39 CEST] <cone-875> ffmpeg 03James Almer 07master:c5fd47fa8a30: Merge commit 'fc85646ad495f3418042468da415af73a7a07334'
[00:09:44 CEST] <alevinsn> etc...
[00:10:09 CEST] <wm4> not sure how one can prefer deeply wrapped templated stuff (enjoy your error messages, compile times, and hair pulling)
[00:10:20 CEST] <alevinsn> its quicker to develop
[00:10:22 CEST] <alevinsn> with ATL
[00:10:31 CEST] <alevinsn> and self-destruction is useful
[00:10:45 CEST] <alevinsn> CComBSTR, CComQIPtr, all that good stuff
[00:11:08 CEST] <nevcairiel> the smart COM pointers are usually pretty useful and a shallow template without much annoyance
[00:11:14 CEST] <alevinsn> I've seen so many errors from people that don't understand the reference counting
[00:11:24 CEST] <nevcairiel> but misusing some of the C++ thigns can really create weird errors =p
[00:11:36 CEST] <alevinsn> leaking objects and causing them to be released prematurely
[00:12:02 CEST] <nevcairiel> I'm not a very good C++ devs, i barely use templates or any modern C++ features, its mostly C with classes
[00:12:07 CEST] <nevcairiel> :)
[00:12:15 CEST] <alevinsn> me too to a certain extent
[00:12:34 CEST] <alevinsn> well, you probably use STL, that involves templates :-)
[00:12:48 CEST] <nevcairiel> well i use some stl containers
[00:13:02 CEST] <nevcairiel> and i even have the odd lambda here and there
[00:13:37 CEST] <nevcairiel> but actual modern c++ codes becomes almost unreadable to me :D
[00:14:03 CEST] <alevinsn> yeah, it can be hard to understand at times
[00:14:24 CEST] <alevinsn> although, in practice, those constructs reduce the amount of work that is needed to write code
[00:14:37 CEST] <nevcairiel> sure,  if you're used to them, its just a much different language
[00:14:37 CEST] <alevinsn> but perhaps increase the amount of time needed to understand it :-)
[00:15:16 CEST] <alevinsn> how often does the github for ffmpeg update?
[00:15:27 CEST] <nevcairiel> every couple minutes i wo uld assume
[00:15:41 CEST] <BtbN> Isn't pushing there a hook?
[00:15:44 CEST] <nevcairiel> yeah it has the most recent changes
[00:15:59 CEST] <nevcairiel> dont think its a hook as such
[00:16:12 CEST] <nevcairiel> but who knows
[00:16:20 CEST] <alevinsn> ok, now I see the change you just committed
[00:16:47 CEST] <alevinsn> I guess I've now left my mark forever on ffmpeg :-)
[00:26:47 CEST] <alevinsn> ok, question, I have a bunch of commits in my local tree
[00:26:58 CEST] <alevinsn> including commits that are relevant to the patch that was just pushed
[00:27:04 CEST] <alevinsn> if I do an update, what is going to happen?
[00:27:13 CEST] <nevcairiel> that depends how you do the update
[00:27:25 CEST] <BtbN> do a pull --rebase
[00:28:13 CEST] <nevcairiel> thats usually the best choice
[00:45:01 CEST] <nevcairiel> pulling with rebasing will basically take your changes and apply them on top of the remote tree, so stuff doesnt get into  weird orders or you get odd merges
[00:45:18 CEST] <nevcairiel> it can also relatively smart just discard commits that have been applied upstream already
[00:52:01 CEST] <cone-875> ffmpeg 03Luca Barbato 07master:3f75e5116b90: avio: Keep track of the amount of data written
[00:52:02 CEST] <cone-875> ffmpeg 03James Almer 07master:34d7f337c160: Merge commit '3f75e5116b900f1428aa13041fc7d6301bf1988a'
[00:54:08 CEST] <cone-875> ffmpeg 03Vittorio Giovara 07master:4efea4ce75fb: APIChanges: Mention where release 12 was cut
[00:54:09 CEST] <cone-875> ffmpeg 03James Almer 07master:652ffbeaf10a: Merge commit '4efea4ce75fbea3e5f8be8040068bfaaffbb2718'
[00:57:14 CEST] <cone-875> ffmpeg 03Ruta Gadkari 07master:dbfe60caca2e: vf_hwupload_cuda: Add min/max limits for device option
[00:57:15 CEST] <cone-875> ffmpeg 03James Almer 07master:41b394bc612b: Merge commit 'dbfe60caca2e8323efa7aba6762dce7be2eba390'
[00:59:39 CEST] <cone-875> ffmpeg 03Diego Biurrun 07master:92e6b31c3b31: dxva2: Adjust multiple inclusion guard names to follow convention
[00:59:40 CEST] <cone-875> ffmpeg 03James Almer 07master:074e636c5ca1: Merge commit '92e6b31c3b31be5d6fcad6bf0030bea86a1c8360'
[01:32:43 CEST] <alevinsn> just discovered the joys of git stash save -p
[02:06:46 CEST] <cone-875> ffmpeg 03James Almer 07master:802d94c36edc: build: fix tools build dependencies
[02:37:56 CEST] <J_Darnley> alevinsn: the -p flag is useful for many git tools
[02:38:12 CEST] <J_Darnley> add, commit, checkout
[02:38:19 CEST] <J_Darnley> reset
[08:27:53 CEST] <alevinsn> If I go to https://github.com/FFmpeg/FFmpeg/commits/master/libavcodec/qsvenc.c to get the history for this file
[08:28:07 CEST] <alevinsn> I see, for example, Commits on Oct 31, 2016
[08:28:17 CEST] <alevinsn> but, the actual dates for those commits aren't Oct 31, 2016
[08:28:32 CEST] <alevinsn> for example, for qsv: Merge libav implementation
[08:28:40 CEST] <alevinsn> I see fhvwy committed on Oct 21, 2016
[08:28:44 CEST] <alevinsn> why don't the dates match?
[08:37:00 CEST] <rcombs> alevinsn: merges can be weird
[08:38:15 CEST] <alevinsn> then, what about avcodec/qsv: remove MFX_EXTBUFF_CODING_OPTION3
[08:38:18 CEST] <alevinsn> also for Oct 31
[08:38:26 CEST] <alevinsn> but committed on Jun 17, 2016
[08:38:33 CEST] <alevinsn> is that also a merge?
[09:05:37 CEST] <ubitux> alevinsn: commits have 2 dates, check with --format=fuller
[09:06:05 CEST] <ubitux> there is the time of commit (local creation, which is the default shown on git log) and the time of remote push
[09:07:03 CEST] <alevinsn> so, authordate and commitdate?
[09:07:49 CEST] <ubitux> yes
[09:08:18 CEST] <ubitux> github may display a different default than git itself
[09:08:43 CEST] <ubitux> they tend to even reorder the commit timeline so that wouldn't be surprising
[10:00:18 CEST] <ubitux> lol, we still have that audio_resample*()
[10:03:33 CEST] <durandal_1707> where?
[10:03:53 CEST] <ubitux> libavcodec/avcodec.h:int audio_resample(ReSampleContext *s, short *output, short *input, int nb_samples);
[10:04:02 CEST] <ubitux> libavcodec/resample.c:int audio_resample(ReSampleContext *s, short *output, short *input, int nb_samples)
[10:38:54 CEST] <nevcairiel> our last bump was quite some time ago, it should be scheduled for removal
[13:12:57 CEST] <cone-353> ffmpeg 03Rostislav Pehlivanov 07master:3f1c527bf555: opus_pvq: add resynth support and band encoding cost function
[16:13:59 CEST] <cone-353> ffmpeg 03Paul B Mahol 07master:34c2eea3d8ec: avcodec/dnxhdenc: make sure that mb_height > 255 can be stored
[16:14:00 CEST] <cone-353> ffmpeg 03Paul B Mahol 07master:5dedb2afd64e: avcodec/dnxhd*: add ff_dnxhd_get_hr_frame_size()
[16:33:23 CEST] <KGB> [13FFV1] 15JeromeMartinez opened pull request #56: Improvement of context and quantization tables paragraphs (06master...06context) 02https://git.io/vSQ3j
[17:03:18 CEST] <KGB> [13FFV1] 15JeromeMartinez opened pull request #57: JPEG2000-RCT formula update (06master...06RCT) 02https://git.io/vSQZX
[17:34:15 CEST] <cone-353> ffmpeg 03Steven Liu 07master:5caaa3a49e76: avformat/hlsenc: add hls encrypt options
[18:59:08 CEST] <alevinsn> nevcairiel:  you here by chance?
[18:59:38 CEST] <nevcairiel> yes
[18:59:49 CEST] <alevinsn> ok, regarding the require-pkg-config patch
[19:00:00 CEST] <alevinsn> there are already existing packages for which require-pkg-config is not used
[19:00:05 CEST] <alevinsn> sometimes require is used
[19:00:10 CEST] <alevinsn> sometimes check-headers is used, etc
[19:00:16 CEST] <alevinsn> if pkg-config isn't required for these packages
[19:00:23 CEST] <nevcairiel> not every package provides a pkg-config file
[19:00:23 CEST] <alevinsn> then why is it a problem to have a fallback?
[19:00:34 CEST] <alevinsn> well, if you build libmfx on Windows
[19:00:39 CEST] <alevinsn> using the Visual Studio project
[19:00:44 CEST] <alevinsn> then you don't have a pkg-config file
[19:00:54 CEST] <alevinsn> Intel provides a Visual Studio project
[19:01:04 CEST] <alevinsn> if you strictly use the files Intel provides
[19:01:08 CEST] <alevinsn> there is no pkg-config anything
[19:01:50 CEST] <alevinsn> I know I provided a "general" solution for this situation
[19:02:01 CEST] <alevinsn> but it felt better than doing something hacky just for libmfx
[19:02:07 CEST] <nevcairiel> then it should be suggested to not use pkg-config for libmfx, but just falling back to something else doesnt seem like a good solution
[19:03:27 CEST] <alevinsn> I actually tried switching to require instead of require-pkg-config
[19:03:39 CEST] <alevinsn> but there are a few problems with that
[19:03:55 CEST] <alevinsn> first, on Linux, someone has come up with an actual package
[19:04:01 CEST] <alevinsn> that provides pkg-config
[19:04:15 CEST] <alevinsn> and it builds a library mfx.a (or something like that)
[19:04:26 CEST] <alevinsn> whereas on windows, what is built with Visual Studio is libmfx.dll
[19:04:39 CEST] <alevinsn> this wouldn't really be a problem because -l* is replaced with -llib*
[19:04:48 CEST] <alevinsn> in the msvc_common_flags()
[19:04:55 CEST] <alevinsn> except msvc_common_flags() is not currently used
[19:05:16 CEST] <alevinsn> when doing test compiles and links as part of the require... steps
[19:05:24 CEST] <alevinsn> so, that doesn't work
[19:05:42 CEST] <alevinsn> in fact, it doesn't fill out any of the compilation flags, etc, for the test builds in configure
[19:07:31 CEST] <alevinsn> and, I think switching from require-pkg-config to require is going to be a non-starter for some people, because of the existence of whatever package people are using to build on Linux
[19:08:52 CEST] <nevcairiel> (that same package can also be build on windows with msvc, fwiw, which also makes you a pkg-config file)
[19:08:57 CEST] <alevinsn> but I'm fairly certain that this package is not maintained by Intel
[19:09:11 CEST] <alevinsn> true, but I don't think it is kept up to date with Intel's Media SDK releases
[19:09:22 CEST] <nevcairiel> intel is bad at maintaining their own things already, so =p
[19:09:43 CEST] <alevinsn> I don't know about that when it comes to the Intel Media SDK
[19:09:59 CEST] <nevcairiel> in any case its mostly a copy paste of intels stuff with a bit of build system on top
[19:10:04 CEST] <nevcairiel> and it seems up to date right now
[19:10:06 CEST] <nevcairiel> https://github.com/lu-zero/mfx_dispatch
[19:11:47 CEST] <nevcairiel> either way, changing a generic function for one case of platform diffrences is not the approach to take
[19:12:34 CEST] <alevinsn> would you accept if I did something specific in the enabled libmfx section?
[19:13:29 CEST] <nevcairiel> probably, it could do what libx264 etc do, use "use_pkg_config" and fallback to a direct require call if needed, not sure if anyone else would object though
[19:13:50 CEST] <alevinsn> oh, I didn't see that for libx264
[19:14:28 CEST] <nevcairiel> the official liibmfx not having a .pc file seems like a good enough reason tho
[19:15:07 CEST] <alevinsn> ok--I'll try that--what about the issue with test builds not using the compiler flags/linker flags that would be used when doing make?
[19:15:18 CEST] <nevcairiel> from what I can tell it does that
[19:16:03 CEST] <alevinsn> you mean, from what you see in configure, it ought to do that?
[19:16:11 CEST] <alevinsn> to do the right thing
[19:17:20 CEST] <alevinsn> here's what actually happened for libmfx
[19:17:28 CEST] <alevinsn> for the test build
[19:17:30 CEST] <alevinsn> require libmfx mfx/mfxvideo.h MFXInit -llibmfx
[19:17:31 CEST] <alevinsn> check_lib mfx/mfxvideo.h MFXInit -llibmfx
[19:17:31 CEST] <alevinsn> check_func_headers mfx/mfxvideo.h MFXInit -llibmfx
[19:17:31 CEST] <alevinsn> check_ld cc -llibmfx
[19:17:31 CEST] <alevinsn> check_cc
[19:17:31 CEST] <alevinsn> BEGIN ./ffconf.Z3iywqKK.c
[19:17:33 CEST] <alevinsn>     1	#include <mfx/mfxvideo.h>
[19:17:35 CEST] <alevinsn>     2	#include <stdint.h>
[19:17:40 CEST] <alevinsn>     3	long check_MFXInit(void) { return (long) MFXInit; }
[19:17:41 CEST] <alevinsn>     4	int main(void) { int ret = 0;
[19:17:43 CEST] <alevinsn>     5	 ret |= ((intptr_t)check_MFXInit) & 0xFFFF;
[19:17:46 CEST] <alevinsn>     6	return ret; }
[19:17:47 CEST] <alevinsn> END ./ffconf.Z3iywqKK.c
[19:17:49 CEST] <alevinsn> cl -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_USE_MATH_DEFINES -D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_WARNINGS -D_WIN32_WINNT=0x0502 -DPIC -nologo -arch:AVX2 -c -Fo./ffconf.KKqrGIJo.o ./ffconf.Z3iywqKK.c
[19:17:53 CEST] <alevinsn> ffconf.Z3iywqKK.c
[19:17:56 CEST] <alevinsn> ./ffconf.Z3iywqKK.c(3): warning C4311: 'type cast': pointer truncation from 'mfxStatus (__cdecl *)(mfxIMPL,mfxVersion *,mfxSession *)' to 'long'
[19:17:58 CEST] <alevinsn> ./compat/windows/mslink -nologo -out:./ffconf.K5nQJ2NB.exe ./ffconf.KKqrGIJo.o libmfx.lib psapi.lib advapi32.lib shell32.lib
[19:18:01 CEST] <alevinsn> -O2 doesn't show up
[19:18:03 CEST] <alevinsn> -Zo doesn't show up
[19:18:05 CEST] <alevinsn> all the -wd stuff doesn't show up
[19:18:09 CEST] <alevinsn> it doesn't have everything
[19:18:36 CEST] <alevinsn> -arch:AVX2 shows up because I added that to --extra-cflags
[19:18:48 CEST] <nevcairiel> it also uses -Fo
[19:18:51 CEST] <nevcairiel> so the key options work
[19:19:12 CEST] <nevcairiel> it doesnt really need all the fancy options
[19:19:27 CEST] <alevinsn> well, here's an example of why it might need the fancy options
[19:19:32 CEST] <alevinsn> I can build libmfx for debug or release
[19:19:52 CEST] <alevinsn> it uses -MT for release (by default) and -MTd for debug
[19:20:16 CEST] <alevinsn> but, if -MTd isn't passed in to cl when doing the build
[19:20:24 CEST] <alevinsn> and the debug version is in LIB
[19:20:30 CEST] <alevinsn> then it reports a warning
[19:20:35 CEST] <alevinsn> although the build succeeds
[19:20:46 CEST] <alevinsn> but, there are similar sorts of cases when such a build would not succeed
[19:21:31 CEST] <alevinsn> and, -Fo$@ doesn't come from option replacement
[19:21:40 CEST] <alevinsn> that comes from a different place in configure
[19:21:59 CEST] <nevcairiel> the filters do run, its not like it has incompatible flags in there
[19:22:13 CEST] <nevcairiel> it just doesnt pass all possible cflags into the probe functions, because they may not even be determined yet
[19:23:29 CEST] <alevinsn> ok, I see that it must be using msvc_common_flags(), since it went from -llibmfx to libmfx.lib
[19:23:34 CEST] <nevcairiel> for example, configure never switches between MT or MTd at all, so you would need to  pass that in as cflags anyway, unless i missed how that works
[19:24:23 CEST] <alevinsn> it does seem to me that it ought to use whatever _cflags_ by this point though
[19:24:36 CEST] <alevinsn> _cflags_speed, _cflags_size, or _cflags_noopt
[19:25:04 CEST] <nevcairiel> well you did say you put -arch:AVX2 into cflags and it passed that there, so if you want a specific MT(d)  or MD(d) you would have that in there anyway
[19:25:22 CEST] <alevinsn> well, in one of my patches I submitted
[19:25:58 CEST] <alevinsn> I declared -cflags_noopt="-Od -Og -MTd"
[19:26:05 CEST] <alevinsn> it wasn't declared previously from MSVC
[19:26:11 CEST] <alevinsn> _cflags_noopt I mean
[19:26:21 CEST] <alevinsn> although no one has commented on that
[19:26:31 CEST] <nevcairiel> I don't think specifically providing a MT or MD mode is a good idea at this point
[19:26:39 CEST] <alevinsn> well, we are getting it regardless
[19:26:44 CEST] <alevinsn> we are getting -MT right now by default
[19:26:54 CEST] <alevinsn> I checked by running link with -VERBOSE
[19:26:54 CEST] <nevcairiel> (also, Og is deprecated)
[19:26:59 CEST] <alevinsn> yes, I'm aware
[19:27:21 CEST] <alevinsn> but, it is the only way to get it to build currently as a result of the DCE requirement
[19:27:24 CEST] <alevinsn> if -Od is used
[19:27:31 CEST] <alevinsn> there is a comment in my patch that explains that
[19:27:41 CEST] <nevcairiel> the debug e xperience is pretty much the same between Og and O1 or O2 in my experience
[19:27:54 CEST] <alevinsn> well, I also added -Zo
[19:28:03 CEST] <alevinsn> which may help some
[19:28:28 CEST] <alevinsn> -d2Zi+ for older than 2013
[19:28:47 CEST] <alevinsn> although, with VS2015, you apparently get -Zo on by default if -Z7 or -Zi are used
[19:29:24 CEST] <alevinsn> According to Microsoft, both -O1 and -O2 use more than just -Og
[19:29:36 CEST] <nevcairiel> of course, but that impacts debugging very little, if at all
[19:29:37 CEST] <alevinsn> although maybe those other options don't impact debugging so much
[19:30:13 CEST] <alevinsn> I would think the frame pointer optimization would make a difference, but maybe that is more relevant for 32-bit builds
[19:30:50 CEST] <nevcairiel> either way I think the crt selection should be left to whoever builds it,  because if they rely on linking to it, it needs to match theirs, so they are probably best advised to select it directly
[19:31:16 CEST] <alevinsn> but, it isn't being left to whoever builds it right now--we are getting -MT by default
[19:31:28 CEST] <alevinsn> it isn't being passed in, but that doesn't mean that a choice isn't being made
[19:31:36 CEST] <nevcairiel> thats just the compiler default if you dont specify anything
[19:31:45 CEST] <nevcairiel> it has to use something if you dont tell it
[19:32:03 CEST] <alevinsn> true, but users may not realize this
[19:32:10 CEST] <alevinsn> I was thinking that the default should be in configure
[19:32:15 CEST] <alevinsn> specify -MT directly
[19:32:19 CEST] <alevinsn> so it is entirely clear
[19:32:24 CEST] <alevinsn> althouogh, then it is harder to overwrite
[19:32:35 CEST] <alevinsn> but, there is also a disadvantage to relying on the default
[19:32:41 CEST] <alevinsn> and then wondering why something doesn't link
[19:32:51 CEST] <alevinsn> Microsoft doesn't make it clear on MSDN what the default is
[19:33:06 CEST] <alevinsn> it used to (/ML, single-threaded run-time)
[19:33:07 CEST] <alevinsn> but not anymore
[19:33:25 CEST] <nevcairiel> those ST runtimes probabvly dont even exist anymore
[19:33:31 CEST] <nevcairiel> -v
[19:33:42 CEST] <alevinsn> right, I was just saying, Microsoft used to report the default on MSDN
[19:33:46 CEST] <alevinsn> for VS 6.0 or something
[19:33:49 CEST] <alevinsn> but not anymore
[19:34:54 CEST] <alevinsn> I guess what I think makes the most sense
[19:35:05 CEST] <alevinsn> is to allow users to choose with a configure option
[19:35:15 CEST] <nevcairiel> we have that, its called --extra-cflags =p
[19:35:16 CEST] <alevinsn> then it will be clear which option is being used at all times
[19:35:57 CEST] <alevinsn> or we could have --use-static-cruntime, etc
[19:36:04 CEST] <alevinsn> of course, that might only be relevant to Windows
[19:36:25 CEST] <nevcairiel> toolchain specific options are iffy, and we require using extra-cflags for that on all platforms where someone might want that
[19:36:39 CEST] <nevcairiel> although its not typical to static link on linux, but its possible
[19:37:29 CEST] <nevcairiel> someone that wants to build ffmpeg should really have some basic knowledge about their toolchain, so they should know what it means to build MT or MD, or debug variations
[19:38:29 CEST] <alevinsn> all right
[19:38:57 CEST] <alevinsn> ok, switching topics entirely
[19:39:10 CEST] <alevinsn> I wanted to add the ability to copy the .pdb files into BINDIR
[19:39:15 CEST] <alevinsn> doing that for libraries was easy
[19:39:19 CEST] <alevinsn> I did the following
[19:39:58 CEST] <alevinsn> I enhanced SLIB_INSTALL_EXTRA_SHLIB as follows:
[19:39:59 CEST] <alevinsn> SLIB_INSTALL_EXTRA_SHLIB='$(SLIBNAME:$(SLIBSUF)=.lib) $(SLIBNAME_WITH_MAJOR:$(SLIBSUF)=.pdb)'
[19:40:25 CEST] <alevinsn> although, maybe someone (you? :-) ) would have issue with me using SLIB_INSTALL_EXTRA_SHLIB for that
[19:40:44 CEST] <alevinsn> but, I don't have a good approach for the executables
[19:41:19 CEST] <nevcairiel> the entire SHLIB stuff is pretty much windows specific already, best would probably be to just clone that for debug symbols
[19:41:42 CEST] <nevcairiel> although the entire "install" target isnt really something that works well on windows :)
[19:41:54 CEST] <nevcairiel> this typical directory structure is very linux-y
[19:42:34 CEST] <alevinsn> well, all the dlls and exes are placed in the same directory
[19:42:47 CEST] <alevinsn> so, the executables do work "out of the box"
[19:43:32 CEST] <alevinsn> do you think it is reasonable to copy the .pdb files as part of make install?
[19:45:15 CEST] <alevinsn> I guess you already get .lib files alreadfy
[19:45:16 CEST] <alevinsn> already
[19:45:20 CEST] <alevinsn> in the bin directory
[19:45:37 CEST] <alevinsn> which someone might not want to package for a fully "binary" release
[19:45:47 CEST] <alevinsn> so, it probably isn't so much of a hassle to have .pdb files there too
[19:47:56 CEST] <alevinsn> ok, separate question about Makefile, the install-libs target depends on install-libs-yes
[19:48:01 CEST] <alevinsn> wtf is install-libs-yes?
[19:48:55 CEST] <alevinsn> I see "yes" once in library.mak
[19:49:15 CEST] <nevcairiel> the -yes stuff is for conditionally enabled things
[19:49:27 CEST] <nevcairiel> ie. install-libs-$(CONFIG_XXXX)
[19:49:51 CEST] <alevinsn> does $(CONFIG_STATIC) resolve to "yes"?
[19:49:59 CEST] <alevinsn> if turned on, I mean?
[19:50:03 CEST] <nevcairiel> yes
[19:50:06 CEST] <nevcairiel> or no when off
[19:50:22 CEST] <alevinsn> ok, that's a little tricky :-)
[19:51:05 CEST] <alevinsn> but maybe its a common sort of thing to do with Makefiles for this sort of thing
[19:58:32 CEST] <alevinsn> ok, one more thing--if 20 days go by and no one has reviewed a particular patch, what then?
[19:58:45 CEST] <nevcairiel> ping it
[20:01:07 CEST] <alevinsn> ok, thanks for taking the time to answer my questions on what I imagine is your Friday night
[20:06:39 CEST] <nevcairiel> even worse its good friday! :)
[20:10:06 CEST] <alevinsn> yes, apparently so
[20:10:19 CEST] <alevinsn> I thought maybe the reason why taxes in the US aren't due till Tuesday had to do with that
[20:10:32 CEST] <alevinsn> but instead it has to do with the fact that Massachusetts has a holiday on Monday
[20:10:39 CEST] <alevinsn> so, everyone in the US gets an extra day
[20:11:19 CEST] <nevcairiel> today and monday are national holidays here \o/
[20:12:12 CEST] <alevinsn> is "here" Hungary?
[20:12:55 CEST] <nevcairiel> germany
[20:14:45 CEST] <alevinsn> I used to work with someone based in Germany 18 years ago on a project named kmp3
[20:14:53 CEST] <alevinsn> Cajus Pollmeier
[20:15:01 CEST] <alevinsn> but, Germany is still a big country :-)
[20:15:23 CEST] <nevcairiel> i was about to say, between 80 million or so people, we dont know everyone =p
[20:15:34 CEST] <alevinsn> still, only a fraction are programmers :-)
[20:15:52 CEST] <alevinsn> maybe you frequent the same open source circles, who knows :-P
[20:25:00 CEST] <jamrial> nevcairiel: what's on monday? also related to easter?
[20:25:07 CEST] <nevcairiel> easter monday eah
[20:25:11 CEST] <nevcairiel> yeah
[20:25:35 CEST] <jamrial> ah
[20:25:45 CEST] <jamrial> lucky, we only get friday :p
[20:30:10 CEST] <alevinsn> Some people get Tuesday/Wednesday off and Monday/Tuesday off
[20:30:14 CEST] <alevinsn> for Passover :-)
[20:30:45 CEST] <durandal_1707> i get every day of year
[20:39:55 CEST] <BBB> We know that the avconv developers are violating the copyright of many people, <- is this what we stand for nowadays?
[20:40:03 CEST] <BBB> this is outrageous
[20:40:17 CEST] <nevcairiel> its carl,  how is that news
[20:40:27 CEST] <BBB> I think he should be banned for a week
[20:40:38 CEST] <BBB> he has been warned about this behaviour before
[20:40:53 CEST] <BBB> j-b: since you are the impartial enforcer of the CoC, can you take action?
[20:41:17 CEST] <JEEB> yea, I read that post and facepalmed
[20:41:29 CEST] <atomnuker> oh come on, there's no need for that
[20:42:15 CEST] <BBB> atomnuker: youre OK with this behaviour? o_O
[20:42:57 CEST] <atomnuker> well, he stated what he thinks
[20:43:20 CEST] <BtbN> Does the Author-Copyright-Header even mean anything? It's all (L)GPL
[20:43:23 CEST] <nevcairiel> i think many things about carl, but if i state them that would not be friendly
[20:43:37 CEST] <BBB> atomnuker: he didn't
[20:43:41 CEST] <BBB> atomnuker: he said we, not "I"
[20:44:03 CEST] <atomnuker> well he's wrong and he stated his opinion
[20:44:33 CEST] <BBB> he stated it as a project opinion, which is quotable and dangerous
[20:45:02 CEST] <BBB> I regularly hear complaints about this from companies Id rather be friendly with
[20:45:05 CEST] <jamrial> carl should have been banned long ago, but whenever someone tries to take action, everyone else disappears or looks away
[20:45:11 CEST] <RiCON> "We know" is different from "I think"
[20:45:24 CEST] <atomnuker> then by all means lets inform him he's wrong and he shouldn't really say stuff like that
[20:45:31 CEST] <fritsch> perhaps he thinks of a scientific paper when writing emails :-)
[20:45:53 CEST] <fritsch> we (mostly me and my prof that also wants his name on it ...)
[20:45:53 CEST] <BBB> fritsch: wouldnt pass peer review in well-regarded journals
[20:46:04 CEST] <BBB> ;)
[20:47:53 CEST] <atomnuker> outright banning him and asking someone external to take action is worse than saying a few nasty words and being wrong
[20:48:33 CEST] <jkqxz> alevinsn:  Would you mind submitting the QSV/interlacing patch to libav?  QSV development is active there, so it would get more useful review.
[20:48:45 CEST] <jkqxz> alevinsn:  It looks sensible to me, but I can't test it right now.
[20:49:52 CEST] <BBB> atomnuker: I didnt suggest banning him forever
[20:49:58 CEST] <jkqxz> alevinsn:  Also, it might be better to split it into three patches for the three separate things it does (pic_struct, alignment, query check).
[20:50:48 CEST] <durandal_1707> im for perma ban from trac
[21:06:08 CEST] <Compn> just have to encourage people to blog
[21:06:11 CEST] <Compn> like ubitux blog
[21:06:19 CEST] <Compn> carl needs a blog somewhere else
[21:06:31 CEST] <Compn> many ff devels have blogs
[21:06:43 CEST] <Compn> av devs too
[21:06:50 CEST] <ubitux> i'm pretty sure i could act like a (mostly) normal human being even without a blog
[21:07:17 CEST] <ubitux> so anyway, what is carl refering to?
[21:07:45 CEST] <Compn> hes posted about things before
[21:07:49 CEST] <Compn> with links
[21:07:52 CEST] <Compn> on the ml
[21:07:56 CEST] <Compn> i cant remember what mail though
[21:08:02 CEST] <durandal_1707> in my blog post: how to make Compn be more productive
[21:08:17 CEST] <Compn> with details and diffs 
[21:08:43 CEST] <Compn> but thats not what ffmpeg-devel (irc channel or mailing list) is for
[21:08:52 CEST] <Compn> so let him blog about it
[21:09:08 CEST] <Compn> durandal_1707 : i resubbed to the -devel list, happy ?
[21:10:21 CEST] <durandal_1707> right, posting blog posts is better than on ml, unless its same thing
[21:11:27 CEST] <Compn> should probably subscribe to -cvslog too
[21:12:24 CEST] <durandal_1707> Compn: find nano screen capture codec installer
[21:13:09 CEST] <Compn> k
[21:14:01 CEST] <Compn> durandal_1707 : this is it ? http://www.softsea.com/download/Nano-Screen-Capture-Codec.html
[21:14:32 CEST] <durandal_1707> can you get installer link working?
[21:14:36 CEST] <Compn> yes
[21:14:41 CEST] <Compn> http://www.softsea.com/download.php?id=834410741
[21:14:54 CEST] <Compn> i extract it already 01/26/2011  12:24 AM           553,984 nscc.dll
[21:15:05 CEST] <durandal_1707> ok
[21:15:28 CEST] <Compn> http://file1.softsea.com/Codec_Pack/NSCC-1.1.exe
[21:15:33 CEST] <Compn> is the actual url ... >.>
[21:15:58 CEST] <Compn> You don't have permission to access /Codec_Pack/ on this server. :(
[21:16:57 CEST] <Compn> durandal_1707 : should let the students and new contributors work on the easy screen codecs
[21:17:07 CEST] <Compn> durandal_1707 : your skills better suited to the harder ones :)
[21:21:16 CEST] <durandal_1707> Compn: i can not encode with this dll, only decode
[21:21:58 CEST] <BBB> Compn: ty
[21:22:16 CEST] <Compn> BBB : feel free to bring anything like this to my attention . i try
[21:22:39 CEST] <BBB> <insert thumbs-up smiley here>
[21:22:55 CEST] <Compn> durandal_1707 : ermhhhhhhhhh ..... what uses nscc encoder ?
[21:23:04 CEST] <Compn> durandal_1707 : if you know? i can find that installer maybe
[21:24:24 CEST] <Compn> oh the website is dead
[21:24:25 CEST] <Compn>  http://www.nanoback.com/files/NSCC-1.1.exe
[21:24:40 CEST] <Compn> durandal_1707 : are you sure its not a trial version ? e.g. you can unlock it ?
[21:24:46 CEST] <Compn> 2nd result in google is for a serial...
[21:26:16 CEST] <Compn> aha
[21:26:18 CEST] <Compn> durandal_1707 : http://mandsoft.com/download.html
[21:26:27 CEST] <Compn> they have a new codec "mscc" lol
[21:27:38 CEST] <Compn> durandal_1707 : theres a couple installers here in the archive. http://web.archive.org/web/*/http://mandsoft.com/*
[21:28:03 CEST] <Compn> probably one of them includes the encoder
[21:31:53 CEST] <Compn> durandal_1707 : do you know where vivo encoder is? i couldnt even find it :(
[21:39:41 CEST] <durandal_1707> Compn: i think i have vivo encoder
[21:42:42 CEST] <Compn> vivoprod.exe ?
[21:43:39 CEST] <j-b> BBB: haha. I wish I could enforce that.
[21:44:30 CEST] Action: Compn wonders if j-b enforces it in videolan...
[21:44:30 CEST] <Compn> :P
[21:44:41 CEST] <j-b> Yes
[21:44:59 CEST] <j-b> Compn: next time, ask them what happened at VDD10 in the videolan meeting
[21:45:34 CEST] <Compn> hmm i bet i could find vivo encoder on edonkey or other p2p network
[21:45:54 CEST] <alevinsn> jkqxz:  Just saw your earlier messages regarding my QSV/interlacing patch
[21:46:28 CEST] <Compn> durandal_1707 : i use uniextract on windows to extract setup .exe files. sometimes it works, sometimes not
[21:46:37 CEST] <Compn> can be faster than running setup .exe, when it works
[21:47:24 CEST] <alevinsn> jkqxz:  regarding submitting it to libav, what would that entail?  Submitting the patch as-is or building libav and creating a new patch that is appropriate for libav?
[21:48:40 CEST] <Compn> alevinsn : it would entail subscribing to libav-devel list at www.libav.org and sending patch to libav-devel mailing list.
[21:49:06 CEST] <Compn> alevinsn : ffmpeg and libav work on the same code, just forked apart
[21:49:16 CEST] <Compn> complicated history and current situation.
[21:49:31 CEST] <alevinsn> so, I need do nothing more than subscribe and submit the patch as is?
[21:49:38 CEST] <Compn> i guess
[21:52:17 CEST] <jkqxz> alevinsn:  The QSV code is pretty much identical.  Rebase it against libav and make sure it builds, but you shouldn't need to do more.
[21:54:15 CEST] <alevinsn> "rebase it against libav"--how do I do that?
[21:54:55 CEST] <alevinsn> manually?
[21:55:16 CEST] <alevinsn> there are only a few changes, so it wouldn't be a big deal to do that manually I guess
[21:55:28 CEST] <nevcairiel> with any luck the patch should just apply
[21:57:01 CEST] <atomnuker> Compn: I did point out multiple times the header is fine
[22:00:32 CEST] <jkqxz> Yeah.  I think it should just apply, but if it doesn't then manually fixing it up should be easy.
[22:00:43 CEST] <alevinsn> on a separate note, while working on the QSV bug fix last night, I was stepping through the code, and, I got to the line
[22:00:45 CEST] <alevinsn> if (avctx->hw_frames_ctx)
[22:00:56 CEST] <alevinsn> if qsvenc.c and noticed that hw_frames_ctx was null
[22:01:10 CEST] <alevinsn> hw_frames_ctx must be valid in order to use video memory for QuickSync encoding
[22:01:14 CEST] <Compn> atomnuker : i did not review.
[22:01:17 CEST] <Compn> :)
[22:01:26 CEST] <Compn> atomnuker : i believe you though
[22:01:32 CEST] <alevinsn> I can't figure out how to cause hw_frames_ctx to be set
[22:01:41 CEST] <alevinsn> when using ffmpeg.exe
[22:02:05 CEST] <nevcairiel> using -hwaccel qsv with a qsv decoder and qsv encoder should possibly set it
[22:02:06 CEST] <alevinsn> is that not supported for encoding when initiated via ffmpeg.exe currently?
[22:02:12 CEST] <alevinsn> I tried that
[22:02:15 CEST] <alevinsn> -hwaccel qsv
[22:02:20 CEST] <alevinsn> it wouldn't accept it for output
[22:02:22 CEST] <jkqxz> It's set if the output link of the filter graph has it set.
[22:02:33 CEST] <alevinsn> here's the command-line if it help
[22:02:34 CEST] <alevinsn> helps
[22:02:48 CEST] <alevinsn> C:\ffmpeg\new_build_3>ffmpeg.exe -hwaccel qsv -f decklink -re -probesize 32 -analyzeduration 0 -i "UltraStudio Mini Recorder at 12" -c:a opus -strict -2 -b:a 128k -c:v h264_qsv -preset:v veryslow -look_ahead 0 -async_depth 1 -b:v 3500k -minrate 3500k -maxrate 3500k -g 30000/1001 -r 30000/1001 -vf setfield=tff -flags +ildct -f mpegts udp://192.168.3.52:6000
[22:02:58 CEST] <alevinsn> it won't let me put -hwaccel qsv in the output side
[22:03:10 CEST] <nevcairiel> its only set if the input decoder is also qsv
[22:03:27 CEST] <jkqxz> Decklink is raw input, isn't it?
[22:03:37 CEST] <nevcairiel> you wouldnt have video memory if its from some other format anyway
[22:03:41 CEST] <jkqxz> So there isn't any gain to having things in video memory before the encoder.
[22:03:52 CEST] <alevinsn> well, that's not quite true
[22:04:01 CEST] <alevinsn> I have QuickSync code in my own project
[22:04:42 CEST] <nevcairiel> and if that is the case you can provide a hw_frames_ctx through code
[22:04:46 CEST] <alevinsn> and I go from DeckLink (UYVY) to NV12 and do the color conversion from UYVY to NV12 into already allocated video memory
[22:04:58 CEST] <alevinsn> QuickSync has better performance even in this case
[22:05:04 CEST] <alevinsn> when using video memory than when using system memory
[22:05:14 CEST] <alevinsn> plus, odd issues sometimes crop up with QuickSync when using system memory
[22:06:02 CEST] <alevinsn> so, ffmpeg isn't sophisticated enough to do that kind of thing implicitly?
[22:06:23 CEST] <alevinsn> or have a way to do it with the appropriate options?
[22:06:34 CEST] <nevcairiel> it could, but it doesnt see any benefit in uploading to video memory for nothing
[22:06:42 CEST] <alevinsn> I'm planning on using the ffmpeg libraries anyway
[22:07:01 CEST] <jkqxz> You are colour converting on the CPU, with the output straight into video memory?
[22:07:04 CEST] <nevcairiel> you can probably use the hwupload filter
[22:07:13 CEST] <nevcairiel> if you really want it uploaded
[22:07:32 CEST] <alevinsn> I'm color converting in my own code and using Intel Performance Primitives to do the color conversion very quickly
[22:07:33 CEST] <jkqxz> You should be able to do that with hwmap, but ffmpeg doesn't currently have the necessary device setup.
[22:07:34 CEST] <durandal_1707> 750$ for capture codec
[22:07:38 CEST] <jkqxz> avconv should be able to do it.
[22:07:49 CEST] <alevinsn> IPP
[22:08:10 CEST] <alevinsn> yes, it is happening on the CPU--it's faster than using QuickSync's VPP
[22:09:06 CEST] <alevinsn> nevcairiel:  it is going to upload to video memory regardless--the question is do you use system memory and let the QuickSync internals take care of it for you
[22:09:10 CEST] <alevinsn> or do you do it yourself
[22:09:11 CEST] <durandal_1707> this guys are using ffmpeg
[22:09:51 CEST] <jkqxz> If you want to do that in your application, you can allocate the hw_frames_ctx yourself, then map the individual frames with av_hwframe_map() and copy into them using the CPU.
[22:10:35 CEST] <alevinsn> ok, I'll give that a shot
[22:11:53 CEST] <alevinsn> thanks
[23:38:52 CEST] <alevinsn> anyone still here?  I subscribed to the libav-devel e-mail list but haven't gotten confirmation yet.
[23:38:59 CEST] <alevinsn> does that require someone to approve me?
[23:44:46 CEST] <alevinsn> just got approval, please disregard
[23:49:04 CEST] <jamrial> alevinsn: libav is a different project. you are unlikely to get help about things like their mailing list here
[23:50:01 CEST] <alevinsn> jamrial:  I'm aware it is a different project, but someone on this IRC channel (jkqxz) asked me to submit a patch to libav-devel that I had submitted to ffmpeg-devel, so I thought I would ask here
[23:50:05 CEST] <alevinsn> anyway, it is resolved
[23:50:43 CEST] <jamrial> yeah, but how their ml works is probably only known to them :p
[23:51:54 CEST] <alevinsn> true
[00:00:00 CEST] --- Sat Apr 15 2017