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

[burek]

[00:00] <dahat> Does anyone know where I can find a functional MinGW configuration that would allow me to even configure ffmpeg with libx264 and build with the VS2013 toolchain? I've been trying for days to create my own rather unsuccessfully.
[00:00] <BtbN> The one in cygwin works fine for me.
[00:00] <BtbN> But don't build it with MSVC, it generates horrible code.
[00:01] <BtbN> specialy for x264 it's like 20% slower for some reason
[00:01] <wm4> iive: lust I heard, lena bullshit blocked the packet? even though Libav has the same problem
[00:01] <wm4> *package
[00:02] <jamrial> dahat: if your problem is linking to libx264, then what you need is check what's wrong with x264
[00:02] <iive> well, libav is already inside, so it can't be blocked.
[00:03] <nevcairiel> wm4: nah the lena thing didnt block anything, the guy trying to get ffmpeg in just had nothing better to do, so he figured it might slightly improve his chances of getting favor with the debian gods
[00:03] <iive> i assume this have been fixed, so there are no more problems?
[00:04] <nevcairiel> it was his own motiviation to tackle this, not from debian
[00:05] <iive> hehe, he is amazing guy, indeed.
[00:05] <iive> and that is even better, because ffmpeg is not back at the start of the queue.
[00:11] <cone-490> ffmpeg.git 03Giorgio Vazzana 07master:d7e088849e33: lavd/v4l2: introduce enqueue_buffer()
[00:40] <J_Darnley> dahat has been bouncing between ffmpeg and x264 trying to get his question answered.
[00:41] <J_Darnley> It seems as though nobody on either side knows enough about the problem
[00:42] <J_Darnley> dahat: did you ever try the libx264-detection-via-pkg-config patch?
[00:43] <jamrial> he did, but the pkg-config file installed by libx264 was meant for mingw, not msvc
[01:28] <J_Darnley> Yasm, what is the point of an assert if you don't error when it fails?
[01:42] <cone-490> ffmpeg.git 03db0company 07master:c7011789005d: doc: Copyright in CSS, CSS split in 2 files
[02:01] <dahat> Ug... it seems I did something rather horrible... I stepped away from my PC for longer than planned after asking a Q...
[02:01] <dahat> BtbN: Unless GCC is able to compile ARM code that targets WinRT... MSVC is my only choice... granted perf isn't my concern at present, only functionality
[02:02] <dahat> jamrial: I can build libx264 without a problem... when I attempt to configure ffmpeg to use it however it goes looking for x264.lib... not libx264.lib which is actually built... and renaming the file also fails
[02:02] <BtbN> I don't see why not?
[02:04] <dahat> J_Darnley: Yes, same result. I even applied pkg-config to my MinGW install (plus a lot of GTK+ because of some puzzling dependancies) and now configure seems to think I'm using GCC in part. When doing build tests with cl.exe (MSVC's compiler) it's passing in arguments which are intended for GCC
[02:13] <dahat> BtbN: While I know there has been a great deal of work going into GCC in support of the creation of a port of VLC to WinRT... the fact that there is still only x86 & x64 builds of it... I am left very skeptical
[02:13] <j-b> dahat: because gcc for arm for winrt does not work. and MSVC does miscompile the open source libraries.
[02:16] <dahat> j-b: That's what I figured. Which open source libraries? Right now the issue I'm having isn't with the compiler screwing up but with it being given faulty information by the open source parts
[02:16] <j-b> all of them :)
[02:19] <dahat> bah! ;)
[06:55] <dahat> Has anyone had any new thoughts or  advice on building ffmpeg while linking to libx264 under MinGW and using the VS2013 toolchain? At the end of the day the compiler & library is all I care about and I continue to be shocked that this is so difficult
[07:06] <rcombs> are you absolutely sure you have to use VS2013 to compile? It would probably be much easier to use gcc
[07:07] <rcombs> and compiler aside, it'd probably be much easier to cross-compile for Windows
[07:07] <dahat> I'm afraid so... my ultimate target is WinRT on both Windows Phone & 'Windows Store' apps targeting ARM processors... and from what I've seen/heard GCC isn't fully there yet
[07:08] <rcombs> gcc compiles for ARM just fine
[07:08] <rcombs> (though I'm not sure about the Windows details)
[07:08] <wm4> dahat: then why do you want to link mingw x264?
[07:09] <dahat> that's the kicker... ARM building requirements isn't always the same thing depending on OS & HW platform
[07:10] <rcombs> you mean calling conventions and instruction sets?
[07:10] <dahat> wm4: Right now I'm only trying to build x86 or x64 for win32 under MinGW because I'm told it's the best way to do it. libx264 is required by my specific use case. I'm sticking with the VS2013 compiler because it is needed for targeting the ARM platform I need to end up on
[07:11] <rcombs> trying to mix compilers on Windows will result in pain
[07:13] <dahat> rcombs: Yes... as well as other unknowns. As an example: I know there has been a number of changes to GCC to support the VLC port to WinRT... but even today while it exists on x86 & x64 it  still does not exist on ARM... so clearly there are remaining issues... and if the code is truly portable then that points blame at the compiler toolchain
[07:14] <rcombs> :|
[07:14] <wm4> isn't winrt dead?
[07:15] <rcombs> "VLC hasn't been released for WinRT yet, therefore it must be impossible to use gcc to compile for WinRT"
[07:15] <rcombs> top-tier logic, that is
[07:15] <dahat> rcombs: I agree... I don't want to have to mix compilers... or are you saying that ffmpeg & libx264 are only capible of being built by GCC and not VS201x & the Intell C++ compiler and that the documentation here is wrong? http://www.ffmpeg.org/platform.html#Microsoft-Visual-C_002b_002b-or-Intel-C_002b_002b-Compiler-for-Windows
[07:16] <rcombs> it's possible, it'll just result in extra pain
[07:16] <rcombs> and building ffmpeg with cl and libx264 with gcc will result in even more pain
[07:16] <dahat> wm4: I've not heard the news of the death of WinRT... at last check all 'Windows Store' apps for Windows 8 & 8.1 are WinRT based... ditto for many apps targeting Windows Phone 8.1
[07:17] <dahat> rcombs: a version of VLC is avalible in the Windows Store today for x86 & 64: http://apps.microsoft.com/windows/en-us/app/vlc-for-windows-8/c527ff2d-b5d0-45b6-bfc3-92fb7357ef72  There was even a Kickstarter project to fund it: https://www.kickstarter.com/projects/1061646928/vlc-for-the-new-windows-8-user-experience-metro
[07:18] <rcombs> I'm not sure what that has to do with anything?
[07:19] <dahat> rcombs: if it results in extra pain... shouldn't that pain be documented... somewhere? All of the documentation I've seen said it's possible... however I am able to demonstrate repeatedly based on the official documentation that it is not. I'm half tempted to put up a video demonstrating this fact as in my experiance most folks don't seem to bother tesitng on platforms that are claimed to be supported.
[07:20] <dahat> My point with those links is to say yes in fact, VLC is avalible for WinRT while using libx264... but only on non ARM platforms
[07:21] <rcombs> fascinating! and I'm saying assuming that it's flatly impossible to compile software for Windows on ARM using gcc just because there's no VLC port is idiotic
[07:22] <wm4> lack of VLC port makes it somewhat less likely
[07:22] <wm4> especially for ffmpeg
[07:22] <dahat> I was using VLC as an example of the apparent impossibility or at least difficulty thus far
[07:22] <rcombs> if you want to tell me it's impossible to build software for a platform using gcc, find an article about it instead of pointing at people who haven't done it yet
[07:23] <dahat> I'd be happy to fire off an email to the VLC folks if you'd like... but that's just a waste of time
[07:23] <dahat> given my target environment, it makes sense to use the compiler which is most used for it (VS2013) regardless of whatever ill-will some may have towards it
[07:24] Action: rcombs looks around; finds gcc-arm-none-eabi-4_8-2014q2-20140609-win32.exe
[07:24] <dahat> documentation on the ffmpeg website claims that ffmpeg can be built with VS... yet I can show over and over again that that does not seem to be the case
[07:24] <rcombs> what actual issue are you having? Right now I've just got "it doesn't work"
[07:25] <wm4> dahat: it can't be built?
[07:25] <wm4> dahat: what fails?
[07:25] <dahat> the existance of this binary or that does not mean that it will work on the target system... and I don't have the time this evening to go grab the ARM based device my son is playing with to test on
[07:25] <dahat> libx264 detection doesn't work... period
[07:25] <rcombs> again with the "doesn't work"
[07:25] <rcombs> as it turns out, "doesn't work" doesn't mean anything
[07:25] <rcombs> what's printed in what phase, with what being logged?
[07:25] <dahat> it goes looking for 'x264.lib'... which according to the #264dev folks isn't the name of the library they spit out (and which I can build fine)... instead it should be looking for libx264.lib
[07:26] <rcombs> "it"
[07:26] <dahat> ffmpegs configure
[07:27] <dahat> it was suggested that ffmpeg doesn't properly do pkg-config under Windows (at all) and a patch was given to bypass that... that solved some issues (long story) but resulted in compiler options that were wrong... gimme a min while I scroll up to find the specific ones...
[07:27] <rcombs> double-check me on this, but I don't think ffmpeg's configure ever actually walks search directories to find lib files, and that task is left to the compiler or linker
[07:29] <dahat> For a sanity check, I went into x264.pc and renamed the lib it was telling the world to go look for... from x264.lib to libx264.lib... same result...
[07:29] <dahat> at this point I am at a point where the configure log ends with the following:
[07:29] <dahat> link -nologo -Ic:/MinGW2/msys/1.0/local/include -Lc:/MinGW2/msys/1.0/local/lib -out:./ffconf..BG81.500.5436.exe ./ffconf..BG81.500.5436.o x264.lib psapi.lib advapi32.lib shell32.lib
[07:29] <dahat> LINK : warning LNK4044: unrecognized option '/Ic:/MinGW2/msys/1.0/local/include'; ignored
[07:29] <dahat> LINK : warning LNK4044: unrecognized option '/Lc:/MinGW2/msys/1.0/local/lib'; ignored
[07:29] <dahat> LINK : fatal error LNK1181: cannot open input file 'x264.lib'
[07:29] <dahat> ERROR: x264 not found
[07:30] <dahat> while the version of link.exe running is correct, the arguments being specified to it ( ie /I & /L) are not for VS2013's version of link... but instead for GCC
[07:30] <rcombs> oh boy, some actual useful information!
[07:31] <dahat> if I went through every bit of useful information you'd be here for a week... which is how much time I've spent on this issue which defies the avalible documentation... be thankful I skipped a few steps
[07:32] <rcombs> now, how about let's see the whole log?
[07:34] <dahat> http://pastebin.com/6aX5wiFA
[07:40] <rcombs> can you post your x264.pc?
[07:41] <dahat> this is from a MinGW install with pkg-config from http://www.gtk.org/download/win32.php as well as the full GTK 3.6.4 package from there as well to make up for some dependancy issues... a modification to ffmpeg's configure file through what I'm told is known as the 'libx264-detection-via-pkg-config patch' which boils down to the following from ubitux the other night:
[07:41] <dahat> -enabled libx264           && require libx264 x264.h x264_encoder_encode -lx264 &&
[07:41] <dahat> -                             { check_cpp_condition x264.h "X264_BUILD >= 118" ||
[07:41] <dahat> -                               die "ERROR: libx264 must be installed and version must be >= 0.118."; }
[07:41] <dahat> +enabled libx264           && require_pkg_config "x264 >= 0.118" "stdint.h x264.h" x264_encoder_encode
[07:42] <rcombs> yup, no surprise
[07:42] <rcombs> spoilers: -Lc:/MinGW2/msys/1.0/local/lib almost certainly came from pkg-config
[07:44] <dahat> sorta... it comes from the PKG_CONFIG_PATH environmental variable which is noted as needing to be set before running configure... so the full configure line (alas not shown by the script is as follows):
[07:44] <dahat> PKG_CONFIG_PATH="/c/MinGW2/msys/1.0/local/lib/pkgconfig" ./configure --enable-shared --toolchain=msvc --disable-dxva2 --enable-libx264 --enable-gpl 
[07:44] <dahat> the path comes from there... if pkg-config is setting it... I cannot say
[07:45] <rcombs> that didn't make any sense :|
[07:45] <rcombs> post your x264.pc file
[07:45] <dahat> prefix=/usr/local
[07:45] <dahat> exec_prefix=${prefix}
[07:45] <dahat> libdir=${exec_prefix}/lib
[07:45] <dahat> includedir=${prefix}/include
[07:45] <dahat> Name: x264
[07:45] <dahat> Description: H.264 (MPEG4 AVC) encoder library
[07:45] <dahat> Version: 0.142.x
[07:45] <dahat> Libs: -L${exec_prefix}/lib -lx264 
[07:45] <dahat> Libs.private: 
[07:45] <dahat> Cflags: -I${prefix}/include
[07:46] <relaxed_> pastebin.com
[07:46] <rcombs> ^
[07:46] <dahat> http://pastebin.com/RmUJxm8H
[07:47] <rcombs> and that's from /c/MinGW2/msys/1.0/local/lib/pkgconfig/x264.pc, right?
[07:47] <dahat> correct
[07:48] <rcombs> what does `PKG_CONFIG_PATH=/c/MinGW2/msys/1.0/local/lib/pkgconfig pkg-config --libs x264` give?
[07:48] <dahat> -Lc:/MinGW2/msys/1.0/local/lib -lx264
[07:49] <dahat> which seems to suggest that pkg-config is pointing me in the wrong direction
[07:50] <rcombs> well, pkg-config is pointing you in the right direction for a GNU compiler
[07:50] <rcombs> but you're trying to use its output with cl, which has entirely different args
[07:51] <rcombs> and now we see why mixing compilers on Windows is painful
[07:52] <dahat> Sure would be nice if that was part of the documentation which says where to DL pkg-config from: https://trac.ffmpeg.org/wiki/CompilationGuide/MinGW
[07:52] <dahat> granted those instructions don't get you to a runnable copy of pkg-config
[07:53] <dahat> one could try to build pkg-config themselves without the missdirection... only that would require building glib... which would require building pkg-config... only that would require building glib... which would require building pkg-config... only that would require building glib... which would require building pkg-config... only that would require building glib... which would require building pkg-config... only that would require 
[07:54] <dahat> talk about painful! and that regardless of platform
[07:54] <rcombs> pkg-config's source ships with an internal copy of glib for that reason
[07:56] <rcombs> but it will most likely be easiest to stop trying to use pkg-config and just build libx264 with cl
[07:57] <dahat> in my setup... libx264 was built with CL... a week ago... spitting out the x264.pc file I mentioned above... which specified to look for x264.lib while ffmpegs configure as you saw is looking for libx264.lib
[07:59] <nevcairiel> ffmpeg doesnt use pkg-config for x264, because some developer thinks using pkg-config makes everything harder. Go figure!
[08:00] <dahat> nevcairiel: I've heard similar comments in #x264dev... have you heard a work around?
[08:02] Action: rcombs does the don't-use-pkg-config dance
[08:02] <wm4> isn't there a glib free pkg-config impl
[08:03] <rcombs> pkg-config is super-nice in a lot of cases, but will fall apart if you try to use it with cl when the pkgconfig file was designed for gcc
[08:03] <nevcairiel> the problem obviously is that pkg-config has gcc specific flags in it, like -L<path>, which msvc doesnt understand
[08:04] <nevcairiel> and thus doesnt find your lib
[08:05] <nevcairiel> try adding --extra-ldflags with -libpath:c:/wherever/ or something to poke it into the right direction
[08:08] <nevcairiel> we can only make ffmpeg itself build with msvc, we dont have any control about the pkg-config files of extra libraries being msvc compatible
[08:09] <nevcairiel> as such, claiming ffmpeg doesnt build with msvc is just plain wrong, it works just fine :p
[08:11] <dahat> nevcairiel: see http://pastebin.com/t7yAVGvC
[08:12] <dahat> if you have a MinGW environment is capible of running configure with my args... as well as building ffmpeg with MSVC... I'd love to see/or get a copy of it... as my results for the last week from avalible documentation say otherwise
[08:12] <nevcairiel> ... you can't just put a path in there, you have to give it a parameter as well
[08:13] <nevcairiel> --extra-ldflags="-libpath:/c/MinGW2/msys/1.0/local/lib"
[08:13] <nevcairiel> or maybe even windows style path, not sure anything will fix it around otherwise
[08:14] <nevcairiel> or you can just add the path to the LIB environment variable, which is read by the msvc linker
[08:15] <nevcairiel> thats what i usually do when working with msvc, setup LIB and INCLUDE env variables to point to my build environment
[08:15] <nevcairiel> (if anything external is needed)
[08:17] <dahat> hrm... my addition of of the full file name with more unix path naming seems to be taking while to return... I'll try your -libpath suggestion here in a few min after I finally kill this process if it doesn't bother to return
[08:17] <rcombs> nevcairiel: I'll leave this one to you, then
[08:17] <dahat> there we go... it returned with the previously mentioned issues of link.exe being fed arguments which were clearly intended for gcc
[08:18] <nevcairiel> i'll go make breakfast now :p
[08:18] <nevcairiel> my only point was that ffmpeg builds just fine with msvc, if an external library doesn't work with msvc, thats not necessarily ffmpegs fault
[08:21] <nevcairiel> .. although you can usually just fix it by setting appropriate include and lib dirs yourself
[08:39] <dahat> ug... after a good number of tries various forms of that also fail...
[08:40] <dahat> with ./configure --enable-shared --toolchain=msvc --disable-dxva2 --enable-libx264 --enable-gpl --extra-ldflags='-libpath /c/MinGW2/msys/1.0/local/lib/libx264.lib' it failed with:
[08:40] <dahat> link -libpath /c/MinGW2/msys/1.0/local/lib/libx264.lib -nologo -Ic:/MinGW2/msys/1.0/local/include -Lc:/MinGW2/msys/1.0/local/lib -out:./ffconf..BG81.500.19440.exe ./ffconf..BG81.500.19440.o x264.lib psapi.lib advapi32.lib shell32.lib
[08:40] <dahat> LINK : warning LNK4044: unrecognized option '/Ic:/MinGW2/msys/1.0/local/include'; ignored
[08:40] <dahat> LINK : warning LNK4044: unrecognized option '/Lc:/MinGW2/msys/1.0/local/lib'; ignored
[08:40] <dahat> LINK : fatal error LNK1181: cannot open input file 'x264.lib'
[08:40] <dahat> ERROR: x264 not found
[08:41] <nevcairiel> libpath takes a : not a space
[08:41] <dahat> for CL?
[08:41] <nevcairiel> and it takes a path, not the path to the library
[08:41] <nevcairiel> i mena, a folder, not a file
[08:43] <dahat> link seems to suggest otherwise... take the following command (based on that from the configure output):
[08:43] <dahat> $ link -libpath c:/MinGW2/msys/1.0/local/lib/ -nologo -out:./ffconf..BG81.500.19440.exe libx264.lib psapi.lib advapi32.lib shell32.lib
[08:43] <dahat> LINK : fatal error LNK1181: cannot open input file 'c:/MinGW2/msys/1.0/local/lib/.obj'
[08:43] <nevcairiel> i give up, you dont even read what i write
[08:44] <dahat> there does appear to be an easter egg in that line though (from configures output)... it too is looking for x264.lib... which is still wrong
[08:45] <nevcairiel> its libpath:<path>, not libpath <path>
[08:45] <dahat> Here is the output when sending it to the folder without the trailing whack: 
[08:45] <dahat> Brendan at BG81 /c/users/brendan/downloads/ffmpeg-2.3.3/ffmpeg-2.3.3
[08:45] <dahat> $ link -libpath c:/MinGW2/msys/1.0/local/lib -nologo -out:./ffconf..BG81.500.19440.exe libx264.lib psapi.lib advapi32.lib shell32.lib
[08:45] <dahat> LINK : fatal error LNK1181: cannot open input file 'c:/MinGW2/msys/1.0/local/lib.obj'
[08:45] <dahat> And again with the :...
[08:45] <dahat> Brendan at BG81 /c/users/brendan/downloads/ffmpeg-2.3.3/ffmpeg-2.3.3
[08:45] <dahat> $ link -libpath:c:/MinGW2/msys/1.0/local/lib -nologo -out:./ffconf..BG81.500.19440.exe libx264.lib psapi.lib advapi32.lib shell32.lib
[08:45] <dahat> LINK : warning LNK4001: no object files specified; libraries used
[08:45] <dahat> LINK : warning LNK4068: /MACHINE not specified; defaulting to X86
[08:45] <dahat> LINK : fatal error LNK1561: entry point must be defined
[08:46] <dahat> lemme try it again with the more unix paths...
[08:46] <nevcairiel> that looks fine
[08:46] <nevcairiel> you didnt tell it any object files to link
[08:46] <nevcairiel> cant make a .exe file from just libraries
[08:51] <dahat> please remember though... the link args I am specifying are based on those run by a running of ffmpegs configure script... which as previously shown is wrong (coupled with current documentation & bits)... and when trying to morph things a bit they continue to blow up in unexpected ways
[08:52] <nevcairiel> your latest error is entirely expected
[08:52] <nevcairiel> like i mentioned earlier however, it may be much simpler to just use the LIB environment variable though
[08:53] <dahat> you are ignoring the /libpath argument... something which VS2013 does support... while suggesting -libpath... something it doesn't support
[08:54] <nevcairiel> it supports any of its arguments with either / or -
[08:54] <nevcairiel> but whatever, have fun figuring it out
[08:54] <dahat> have you run it this evening? That's not what I'm seeing
[08:55] <rcombs> dahat: `LINK : fatal error LNK1561: entry point must be defined` just means there's no main() or winmain()
[08:55] <dahat> Compare the following... two chars are different:
[08:55] <dahat> Brendan at BG81 /c/users/brendan/downloads/ffmpeg-2.3.3/ffmpeg-2.3.3
[08:55] <dahat> $ link -libpath:c:/MinGW2/msys/1.0/local/lib -nologo -out:./ffconf..BG81.500.19440.exe libx264.lib psapi.lib advapi32.lib shell32.lib
[08:55] <dahat> LINK : warning LNK4001: no object files specified; libraries used
[08:55] <dahat> LINK : warning LNK4068: /MACHINE not specified; defaulting to X86
[08:55] <dahat> LINK : fatal error LNK1561: entry point must be defined
[08:55] <dahat> Brendan at BG81 /c/users/brendan/downloads/ffmpeg-2.3.3/ffmpeg-2.3.3
[08:55] <dahat> $ link /libpath c:/MinGW2/msys/1.0/local/lib -nologo -out:./ffconf..BG81.500.19440.exe libx264.lib psapi.lib advapi32.lib shell32.lib
[08:55] <dahat> LINK : fatal error LNK1181: cannot open input file 'C:/MinGW2/msys/1.0/libpath.obj'
[08:55] <nevcairiel> the first looks correct
[08:56] <rcombs> dahat: are you actually reading that output text before you paste it?
[08:56] <rcombs> because it's rather clear what your problem is
[08:57] <dahat> yes, I'm also reading the output of config... wich mentions the following (expanding the paste by a few lines and that lacks any entry point info):
[08:57] <dahat> BEGIN ./ffconf..BG81.500.19440.c
[08:57] <dahat>     1	#include <stdint.h>
[08:57] <dahat>     2	#include <x264.h>
[08:57] <dahat>     3	long check_x264_encoder_encode(void) { return (long) x264_encoder_encode; }
[08:57] <dahat>     4	int main(void) { return 0; }
[08:57] <dahat> END ./ffconf..BG81.500.19440.c
[08:57] <dahat> cl -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_WIN32_WINNT=0x0502 -Dstrtod=avpriv_strtod -Dsnprintf=avpriv_snprintf -D_snprintf=avpriv_snprintf -Dvsnprintf=avpriv_vsnprintf -nologo -D_USE_MATH_DEFINES -D_CRT_SECURE_NO_WARNINGS -Dinline=__inline -FIstdlib.h -Dstrtoll=_strtoi64 -Ic:/MinGW2/msys/1.0/local/include -Lc:/MinGW2/msys/1.0/local/lib -c -Fo./ffconf..BG81.500.19440.o ./ffconf..BG81.500.19440.c
[08:57] <dahat> cl : Command line warning D9002 : ignoring unknown option '-Lc:/MinGW2/msys/1.0/local/lib'
[08:57] <dahat> ffconf..BG81.500.19440.c
[08:57] <dahat> link -libpath /c/MinGW2/msys/1.0/local/lib/libx264.lib -nologo -Ic:/MinGW2/msys/1.0/local/include -Lc:/MinGW2/msys/1.0/local/lib -out:./ffconf..BG81.500.19440.exe ./ffconf..BG81.500.19440.o x264.lib psapi.lib advapi32.lib shell32.lib
[08:57] <dahat> LINK : warning LNK4044: unrecognized option '/Ic:/MinGW2/msys/1.0/local/include'; ignored
[08:57] <wm4> urgh
[08:58] <rcombs> dahat: stop pasting large amounts of text into the channel, or someone will end up kicking you
[08:58] <wm4> rcombs: you failed to suggest using a pastebin hours ago
[08:58] <rcombs> wm4: someone else did so
[08:58] <dahat> I've posted multiple pastebins
[08:58] <wm4> I recommend http://sprunge.us/
[08:58] <wm4> it makes it easy to "paste" output of commands etc.
[08:59] <rcombs> dahat: great, you've got the whole "using a pastebin" thing down
[08:59] <dahat> shall I instead link to a youtube video walking throuch each step of this process that demonstrates that the current documentation results in a failing build?
[08:59] <dahat> I'm more than happy to
[08:59] <rcombs> dahat: but you still need to work on the "not pasting text into the channel" part
[08:59] <rcombs> they kind of go together
[08:59] <wm4> rcombs: I don't think that kind of err smugness is appropriate here
[08:59] <dahat> I'm sorry that 15 lines of text to the channel is more than your IRC client or the channel can support
[09:00] <dahat> instead this seems to be more of a defense mechanism because of the error prone nature of the code involved
[09:00] <wm4> pastebins are still preferred for anything > 3 lines
[09:00] <nevcairiel> seriously, you cant even listen to the advice i'm trying to give you, and then you fallback to ranting on the code? :p
[09:00] <rcombs> your problem is that you're still passing in pkg-config's args
[09:01] <dahat> you'd think... after several days someone would have said "here is a compressed ZYX file contains an environment which supports what you are trying to do"... yet instead I have suggestions from folks looking at copy & pastes of outputs (and whining about them being pasted to an IRC channel) rather than trying to repro the specific issue at hand
[09:01] <rcombs> multiple correct methods of providing library search paths to cl and link have been mentioned
[09:02] <dahat> nevcairiel: re-read the above... I've responded to everying you've said above... you haven't actually tried to do what I'm trying to do with currently suggested environments and code files... no one has
[09:02] <dahat> and yet configure still fails to ignore them!
[09:02] <rcombs> what?
[09:02] <j-b> then compile for ANdroid :)
[09:02] <wm4> even the windows folks don't want to deal with msvc
[09:03] <dahat> j-b: alas for you my users use Windows Phone mostly
[09:03] <rcombs>  <dahat> and yet configure still fails to ignore them! <-- was that supposed to make any sense? Because it didn't.
[09:03] <dahat> wm4: depends on who you talk to
[09:04] <j-b> dahat: then use MFT
[09:04] <dahat> rcombs: have you followed this discussion? configure is ignoring such input
[09:04] <rcombs> (also, I'm not sure why I'm supposed to be defensive about ffmpeg's configure, which I had no part in writing)
[09:04] <rcombs> dahat: provide a full configure log in which such input is ignored
[09:04] <rcombs> (pastebinned, please)
[09:06] <dahat> lemme start from a more basic Q: Has anyone else here... in the last month... tried what I am attempting to do? Building ffmpeg with vs2013 under mingw while linking to libx264 (also built under mingw and vs2013)? if not... then you cannot difinetivly say that anyting I am doing is wrong... because each suggestion I get I try... it fails... and yet the blame is still put on me and never the code or poor documentation
[09:06] <rcombs> yes, because your logs and console output clearly state what the problem is
[09:07] <dahat> rcombs: have you forgotten that the output points the finger at pkg-config... which I DLed per the instructions I received from an official ffmpeg website?
[09:08] <dahat> now, if pkg-config is faulty... I can accept that... but I'd at least expect someone to try to repro what I am seeing and update the documentation at a minimum
[09:08] <nevcairiel> the way i see it, the only inconsistency is that x264 names its output file libx264.lib, which is not how msvc libraries are usually named. unix libs are lib<name>.so, msvc stuff is usually just <name>.lib
[09:08] <nevcairiel> if i rename libx264.lib to x264.lib, it works just perfectly
[09:09] <dahat> nevcairiel: Have you honestly tried that in an environment to which I have described very recently... or are you guessing? Because I've tried that several times over the last week and it has failed each time
[09:09] <nevcairiel> i just ran configure successfully
[09:09] <nevcairiel> and it took me 10 minutes
[09:10] <dahat> then please share a compressed copy of that environment because I'd like to try it
[09:10] <rcombs> and pkg-config isn't your problem
[09:10] <rcombs> pkg-config is doing exactly what it's supposed to, but your x264.pc is meant for gcc
[09:10] <dahat> oh? pkg-config is complained about on a normal run of ffmpeg's configure
[09:10] <nevcairiel> pkg-config isnt even used for x264, didnt we cover that earlier <.<
[09:10] <dahat> the #x264dev folks dissagree... though I don't see those I chatted with a week ago in here this evening
[09:10] <rcombs> nevcairiel: he's got a patched configure that uses it
[09:11] <nevcairiel> rcombs: no support for custom modifications, he can move on now!
[09:11] <rcombs> nevcairiel: he claims the patch came from ffmpeg.org
[09:11] <dahat> I've also tried this without a patched configure
[09:11] <rcombs> you'll need to either make a x264.pc that provides args for MSVC, or stop trying to use pkg-config and pass the MSVC args on the command line
[09:11] <nevcairiel> anyway, i cloned x264, and build it with msvc, renamed libx264.lib to x264.lib, and ran this command: ./configure --enable-shared --toolchain=msvc --disable-dxva2 --enable-libx264 --enable-gpl --extra-ldflags="-libpath:D:/Temp/x264" --extra-cflags="-I D:/Temp/x264"
[09:11] <nevcairiel> it worked perfectly
[09:12] <rcombs> yup, that looks kosher to me
[09:12] <dahat> do you want me to put a few public videos on youtube demonstrating the impossibility of building ffmpeg with x264 with mingw and vs2013? I'm happy to... I've got half a dozen repros based on existing documentation on my test VM already... what's another half dozen
[09:12] <nevcairiel> the only inconsistency is like i mentioned above, x264 does not name its library file consistent with msvc library naming
[09:12] <nevcairiel> hence the rename
[09:13] <rcombs> no, I'd like a log of the exact command nevcairiel just posted running on your system and failing
[09:13] <rcombs> (tweaked to point at the directories your x264 build is in, of course)
[09:13] <dahat> of course... one sec...
[09:14] <rcombs> with the stock configure from ffmpeg master, of course
[09:14] <nevcairiel> you're also free to grab http://xhmikosr.1f0.de/tools/msys/MSYS_MinGW-w64_GCC_491_x86-x64_Full.7z .. its the msys/mingw env i use
[09:14] <nevcairiel> but thats not really your problem
[09:24] <ubitux> dahat: with the pkg-config patch applied, if you want to ignore pkg-config flags, you do something like --pkg-config=true --extra-ldflags="-libpath:D:/Temp/x264 -lx264" --extra-cflags="-I D:/Temp/x264" 
[09:24] <ubitux> the pkg-config call will be a no-op and you specify the include & lib flags yourself
[09:25] <ubitux> not sure if "-lx264" is the correct link flag though
[09:26] <nevcairiel> wonder if it passes external ldflags through the ldflag filter function to translate it
[09:26] <nevcairiel> if yes, that would work, if not, you need to change it
[09:27] <dahat> With nevcairiel's configure line (modified for my environment (ie ./configure --enable-shared --toolchain=msvc --disable-dxva2 --enable-libx264 --enable-gpl --extra-ldflags="-libpath:C:/mingw2/msys/1.0/local/lib" --extra-cflags="-I C:/mingw2/msys/1.0/local/lib")) I get the following: http://pastebin.com/15TYwHUK
[09:27] <nevcairiel> ... you still have the pkg-config patch applied
[09:27] <rcombs> ^
[09:28] <dahat> tomorrow I'm just going to record a walk through, clean VM, downloading this app and that package and demonstrate the impossibility which seems not to be accounted for
[09:28] <rcombs> :|
[09:28] <nevcairiel> the impossibility seems to be listening
[09:28] <nevcairiel> or reading as it were
[09:28] <dahat> then cite the specific line I have not read and implemented
[09:28] <rcombs> you didn't remove the pkg-config patch
[09:28] <nevcairiel> <rcombs> with the stock configure from ffmpeg master, of course
[09:28] <wm4> is the "pkg-config patch" the thing CE hates?
[09:29] <nevcairiel> probably
[09:29] <dahat> I've not tried your build envionment yet as it's nearly 12:30 am and I've a 9am kick off of an american football game I need to be at a bar for by then
[09:29] <rcombs> nevcairiel's build environment will not help
[09:29] <ubitux> wm4: yes
[09:29] <nevcairiel> you can still do the same thing with the patch applied, you need to mess around with it a bit though
[09:30] <nevcairiel> ie. what ubitux said
[09:31] <dahat> here is a configure run against a git clone which does not have the pkg-config change applied: http://pastebin.com/PTkXD9dM
[09:34] <rcombs> (pastebin appears to be down, so I can't get to that until it's back up)
[09:34] <rcombs> ah, there we go
[09:35] <nevcairiel> i'm not even going to comment on this
[09:35] <rcombs> dahat: you have an -I pointed at your /lib dir instead of your /include dir
[09:35] <dahat> and again with a tweak to the include's: http://pastebin.com/7KbXyhsR
[09:36] <nevcairiel> i mentioned renaming the libx264.lib -> x264.lib several times above
[09:36] <dahat> while I wait for another configure (involving a copy & rename) ... I must against point out the incorrectness of the existing documentation which I will document in video form this weekend
[09:36] <rcombs> do you have a x264.lib in C:/mingw2/msys/1.0/local/lib ?
[09:36] <nevcairiel> go nuts
[09:36] <wm4> you think anyone would watch such a video
[09:36] <nevcairiel> the documentation is fine though
[09:37] <dahat> nevcairiel: bullshit, that is what I will demonstrate
[09:37] <rcombs> if you're compiling software, you're expected to be able to read and interpret error messages
[09:37] <nevcairiel> the docs document building ffmpeg, not any external libraries
[09:38] <dahat> rcombs: I'm fully capible of reading and interpreting error messages which come from the software I'm trying to build... such expectations don't work as well when the documentation tells you to download binaries which point to the wrong compiler
[09:38] <nevcairiel> heck the docs even mention using LIB and INCLUDE env variables, which i recommended like an hour ago
[09:38] <dahat> which I've tried in past
[09:38] <rcombs> "binaries which point to the wrong compiler", now
[09:39] <dahat> pkg-config from the gtk+ site
[09:39] <dahat> again, you'll see this in a video walking through every step in a day or three
[09:39] <nevcairiel> pkg-config just gives you the flags from the .pc file, the .pc file is not part of ffmpeg, but part of x264
[09:39] <nevcairiel> hence, not ffmpegs problem
[09:39] <rcombs> I suppose I don't actually have to come up with a response to that
[09:40] <dahat> but oh gee... now I have perl.exe taking 100% CPU usage (something I've seen before... which will run for hours at a time if not killed)
[09:40] <rcombs> I'm sure it'll be a fascinating video; perhaps someone will even watch it!
[09:41] <dahat> nevcairiel: You are free to wave the "not our problem" flag if you'd like... however the fact I can build one library but utterly fail to configure another says worlds
[09:41] <nevcairiel> i certainly wont
[09:41] <nevcairiel> it took me 10 minutes to build it
[09:41] <nevcairiel> from scratch
[09:41] <nevcairiel> including building x264!
[09:42] <dahat> so what I'm gathering... is if you don't care if people are unable to build ffmpeg with associated libraries without hand holding from IRC chat rooms... despite existing documentation which I will demonstrate points uers in the wrong direction? good to know
[09:42] <nevcairiel> good luck with your video
[09:42] <dahat> did you download the full environment... from scratch to a clean machine and without any previous insights, bits or steps?
[09:42] <nevcairiel> i cant make myself dumb again to try, can i now :P
[09:42] <rcombs> well, he has plenty of insight
[09:43] <dahat> you assume I care about massive viewership of such a video... my point of making such a thing is to demonstrate to you lot that the avalible documentation is wrong
[09:43] <rcombs> nevcairiel isn't clueless, you see
[09:43] <wm4> dahat: what's your point anyway? you sound angry, but people are actually trying to help you
[09:43] <nevcairiel> the documentation is not wrong, it just doesn't cover any external libraries. All it covers is building ffmpeg itself
[09:43] <nevcairiel> heck it doesnt even mention pkg-config, outside of needing it for ffplay/sdl
[09:44] <dahat> um... configure mentions pkg-config... mentioning that it's absense may cause external library detection to fail... so yes... it is mentioned
[09:45] <rcombs> today is bringing me new insights into the philosophy of _not_ coming up with responses to nonsense!
[09:46] <nevcairiel> dahat: it may cause this, but in this case its entirely unrelated
[09:46] <dahat> rcombs: So you are suggesting I should have stayed silent to all of those reading logs and not actually trying what I've described on the same fresh environment? Good to know!
[09:46] <nevcairiel> that would've made a far more relaxing morning for all of us
[09:47] <dahat> nevcairiel: You say that now, but when faced with warnings from configure without --enable-libx264 and errors with it... it's a pretty obvious direction to take up front
[09:47] <rcombs> I can't even lex those last 2 lines
[09:47] <nevcairiel> thats the first thing i said when i arrived
[09:48] <dahat> then configure should be changed
[09:48] <nevcairiel> the warning is fine
[09:49] <nevcairiel> its expected that people are capable of reading the config.log to figure out whats the problem, and it would quite clearly tell you immediately if the problem is a missing pkg-config, or something else entirely
[09:51] <dahat> There it is... "WARNING: pkg-config not found, library detection may fail." seems rather clear when ones attempts to include a lib (say libx264) fail... yet the config.log file doesn't quite point to the suggestions that have been proposed here based on OS, build environment or compiler. User error? Perhaps. Documetnation or code error? Absolutly. I'd post more info, but I'm afraid of being slapped for pasting too much info to the
[09:52] <ubitux> dahat: did you try what i suggest?
[09:52] <rcombs> it's rather clear if you have any idea what pkg-config is
[09:53] <nevcairiel> or how msvc works <.<
[09:53] <rcombs> or if you actually read your config.log!
[09:53] <dahat> Here is the config.log: http://pastebin.com/p7yEcq93 One mention of pkg-config before the error message... yes... so clear what is going on
[09:54] <dahat> and a whopping TWO whole references to it in the entire log file... OMG it's so clear! how did I never see the error before!
[09:54] <ubitux> that's not the cmd line i suggested
[09:54] <nevcairiel> the log doesnt even seem to end in an error
[09:55] <ubitux> why isn't this discussion on #ffmpeg btw?
[09:55] <rcombs> good question
[09:55] <dahat> *faceplam* I am refering to the message of "WARNING: pkg-config not found, library detection may fail."
[09:55] <rcombs> dahat: oh, the one that starts with "WARNING"?
[09:56] <nevcairiel> i shall stop partaking in this insane discussion now
[09:56] <dahat> why here vs #ffmpeg? Because I tried over there (like #x264dev) and the answers (or lack of) lead me here
[09:56] <ubitux> why aren't you answering my other questions?
[09:56] <rcombs> dahat: is your configure actually failing now?
[09:56] <dahat> which question haven't I answered?
[09:57] <ubitux> 09:52:09 <@ubitux> dahat: did you try what i suggest?
[09:58] <ubitux> and i'm also wondering if you still have the libx264 pkg-config patch applied in ffmpeg tree
[09:58] <rcombs> as far as I can tell, his problem is resolved and he's just complaining about documentation at this point
[09:58] <dahat> yes... it says warning... when not trying to configure with libx264 or extra arguments outside of the documentation on ffmpeg.org... and when you try to follow said documentation and include a library and things go to hell.. one natural reaction is to follow the warning from an earlier (and more isolated) configure and try to resolve that... which is part of what lead me here... and again... clearly the documetnation is lacking if
[09:58] <ubitux> rcombs: ah?
[09:58] <rcombs> ubitux: he reverted that patch a bit ago
[09:58] <dahat> yes... it's so horrible to complain about documentation which may have lead you astray for a week
[09:58] <ubitux> ok
[09:58] <ubitux> well then since this is #ffmpeg-devel he can send a patch now that he knows what's going on
[09:58] <nevcairiel> dahat: its open source, send a patch to improve it
[09:59] <rcombs> ubitux: because his x264.pc has args meant for gcc and he was trying to use them with cl
[09:59] <dahat> I did revert that patch... and configure succeeded... though I've not tried a build yet as I wanted to revert part of it to remind of the warning message which highlights poor documentation
[09:59] <dahat> nevcairiel: thanks for reminding me why I rather dislike open source... that's a common excuse vs recognizing issues the mentality is to blame the user and expect them to fix it
[09:59] <ubitux> with the patch applied, and my suggestion, you wouldn't see the warning
[10:00] <rcombs> dahat: you'll find that warning in pretty much any bit of software that uses pkg-config if you try to configure it without pkg-config
[10:00] <ubitux> dahat: you're not a user, you are on #ffmpeg-devel
[10:00] <nevcairiel> dahat: i do blame you, are are incapable of even following advice we've been giving you for 90 minutes now
[10:00] <dahat> ubitux: bull... again, I'll see if I can't find time for a few videos
[10:00] <ubitux> what prevents you from contributing?
[10:00] <dahat> nevcairiel: you should then perhaps re-read what you and others here have said and what I have replied with
[10:00] <ubitux> you're in the place where we discuss the contributions
[10:01] <ubitux> and how to contribute
[10:03] <dahat> given the traffic in #ffmpeg and the reponse to my Q's there... this was the obvious place to escalate to... and I am not opposed to contributions... my issue is with a mentality that the user (or developer) is at fault because the code hasn't been recently tested in an environment that matches the documentation
[10:04] <rcombs> we've been over this at least 4 times now
[10:04] <dahat> yes... and you've ignored what I've said about the documentation
[10:04] <ubitux> because we're not at your service, this isn't #ffmpeg :p
[10:05] <ubitux> we helped the best we can with what we know
[10:05] <rcombs> ubitux: as his issue is resolved and he's just complaining about how he doesn't know how to build software on his platform properly at this point, I propose he be removed
[10:05] <nevcairiel> dahat: and you have not had one kind word for us, despite us solving your problem that apparently blocked you for a week!
[10:05] <dahat> where on https://trac.ffmpeg.org/wiki/CompilationGuide/MinGW does it say that specifying include & lib dirs is a requirement under mingw?
[10:05] <ubitux> it's a wiki
[10:05] <ubitux> you create an account
[10:05] <ubitux> and update the page
[10:05] <nevcairiel> its also about MinGW, not about MSVC
[10:05] <rcombs> dahat: you're expected to know the basics of compiling software with the toolchain you're using
[10:06] <dahat> updating the page requires answers... I've been in the process of trying to find them for the last week
[10:06] <rcombs> and now you have them! Great! Bye!
[10:06] <dahat> MinGW has a hard dependancy on GCC? That'd be news to a lot of folks I bet
[10:06] <nevcairiel> MinGW *IS* GCC
[10:06] <rcombs> oh boy, more fantastic leaps of logic
[10:06] <nevcairiel> what you are talking about is MSYS
[10:06] <dahat> never mind the fact that MSVC *IS MENTIONED* on that page
[10:07] <ubitux> this wiki is filled by users and power users, mostly
[10:07] <nevcairiel> as a side note for one specific case
[10:07] <dahat> you folks seem to be used to the clouistered ivory tower sort of development... not used to fresh eyes looking upon your work... I'm sorry that I have been so disruptive & offensive
[10:07] <ubitux> 10:07:10 <@ubitux> this wiki is filled by users and power users, mostly
[10:08] <dahat> that one specific case is a foot in the door... http://www.ffmpeg.org/platform.html#Microsoft-Visual-C_002b_002b-or-Intel-C_002b_002b-Compiler-for-Windows is the other
[10:08] <ubitux> is there any error on that page?
[10:09] <rcombs> ffmpeg is a complex piece of software, so you need to know a bit about building software to& build it
[10:09] <dahat> granted that link refers to VS2012... the need to run a C99 to C89 compiler not being needed for the last couple of years
[10:09] <rcombs> or, at least, to build it on an unusual system like yours
[10:09] <nevcairiel> that link mentions the differences between 2012 and 2013
[10:09] <nevcairiel> with a lot of (if using MSVC 2012 or earlier)
[10:10] <dahat> Oh goodie... ffmpeg still fails to make with the suggestions above:
[10:10] <dahat> Brendan at BG81 /c/ffmpeg
[10:10] <dahat> $ make
[10:10] <dahat> common.mak:152: *** missing separator.  Stop.
[10:10] <rcombs> bad line endings
[10:10] <rcombs> disable autocrlf in git
[10:10] <dahat> in MinGW? typing 'make' and hitting enter is a bad line ending?
[10:10] <ubitux> bad git clone
[10:10] <nevcairiel> that part is kinda annoying, but its really makes problem. Make is broken and doesnt work with crlf in makefiles properly
[10:11] <ubitux> didn't we have a faq entry about that one?
[10:11] <ubitux> or something like that
[10:11] <rcombs> nevcairiel: you could argue that git on Win32 is broken and sticks \r's where they don't belong
[10:11] <nevcairiel> rcombs: doesnt it ask which mode to use during install, a nd thats not the default setting?
[10:11] <nevcairiel> or maybe it is
[10:11] <nevcairiel> i dunno
[10:12] <nevcairiel> i use autocrlf=input mostly
[10:12] <ubitux> ah it's in the git howto
[10:12] <rcombs> it's on by default iirc
[10:12] <rcombs> but I'm not 100% sure on that
[10:13] <ubitux> http://www.ffmpeg.org/git-howto.html#Cloning-the-source-tree
[10:13] <nevcairiel> its better than commiting crlf to the repo i guess
[10:13] <rcombs> either way, I'd say it's not ffmpeg or make's fault if git makes changes to the source
[10:13] <nevcairiel> but thats why i prefer the input mode, it converts to LF on commit, but keeps LFs on checkout
[10:13] <ubitux> Make sure that you do not have Windows line endings in your checkouts, otherwise you may experience spurious compilation failures. One way to achieve this is to run
[10:13] <ubitux> git config --global core.autocrlf false
[10:13] <ubitux> this should be in a more obvious place&
[10:14] <dahat> running 'git config --global core.autocrlf false' and then 'make' results in the same error
[10:14] <ubitux> you need to clone again
[10:15] <dahat> <cloning>
[10:18] <rcombs> what's autocrlf even for? In case you want to edit your code in notepad.exe?
[10:20] <dahat> git config --global core.autocrlf false still returns instantly... both from the root of the VM and the dir the clone was made to... configuring now...
[10:21] <rcombs> did anyone say it wasn't supposed to?
[10:24] <dahat> no, however the initial behavior was the same as to an existing clone which I'd not touched with notepad or other crlf-ing editors... again I'm sorry if you don't like gaps in documentation being pointed out... make seems to be going now... will have to check on it later as it's nearly 1:30 and I've college football kicking off in 7.5 hours and need to get some rest in before heading to the bar
[10:24] <dahat> thanks for the advice thus far... though I think there will be some suggested changes to a multitude of things once I have my wits about me again
[10:24] <nevcairiel> rcombs: i suppose its for some windows tools that dont do LF well,  but imho "input" should be the default mode, ie. mapping CRLF to LF on commit, but leaving it alone on checkout
[10:24] <ubitux> dahat: git config will affect your ~/.gitconfig
[10:24] <rcombs> nevcairiel: sounds sensible
[10:25] <ubitux> dahat: clone by defaut with git on windows seems to add random characters for line breaks, which make doesn't support
[10:25] <ubitux> and actually, i wonder if that wasn't "fixed" in recent gmake, i remember something like that
[10:25] <nevcairiel> didnt Daemon404 want to send a patch to make for that
[10:25] <nevcairiel> although it would be years until msys make gets it, if ever
[10:25] <ubitux> yeah right, that's what i had in mind
[10:28] <wm4> is msys that slow?
[10:28] <nevcairiel> apprently building for msys is some sort of dark magic
[10:29] <nevcairiel> anyway, right now its make 3.81, which apparently is from 2006
[10:29] <nevcairiel> admittedly, my linux box has make 3.82
[10:29] <nevcairiel> which is from 2010
[10:29] <rcombs> in my experience, msys is slow to update *and* slow to execute
[10:29] <nevcairiel> so ... make itself is slow?
[10:29] <nevcairiel> :D
[10:30] <rcombs> well, that too
[10:30] <rcombs> "let's all move to CMake and Ninja!"
[10:31] <nevcairiel> the problem apparently is that there is only ancient gcc 3.x compiler that can even build for msys
[10:31] <pross-au> rcombs: ... and limit ourselves to ~3 platforms!
[10:31] <rcombs> pross-au: yeah! :D
[10:32] <rcombs> sounds like an Excellent Plan"
[10:35] <rcombs> ^ in re: that bug, note that ffmpeg handles dash segments just fine if you use the concat demuxer to give it init.mp4 followed by one or more actual segments
[10:36] <nevcairiel> you can concat mp4s like that?
[10:36] <rcombs> nevcairiel: you can concat m4s's
[10:36] <rcombs> (DASH segments)
[10:36] <nevcairiel> oh, so its not actual mp4
[10:36] <rcombs> I think init.mp4 is technically a valid ISOBMFF file with no content (just headers)
[10:37] <rcombs> and then each individual segment is content with no headers
[10:38] <rcombs> so if you concat them together, you get a single proper MP4 file
[10:38] <nevcairiel> i see
[10:38] <rcombs> and I'd probably go write a demuxer if it weren't for the manifest format being XML and that sounding like a lot of work
[10:38] <nevcairiel> didnt i see some patch floating somewhere
[10:40] <rcombs> maybe?
[10:40] <wm4> rcombs: uh you mean literally concat them byte-wise?
[10:41] <rcombs> yup
[10:41] <rcombs> at least, that's been how it works for the DASH segments I've worked with, but the format apparently has 9001 different modes, so maybe that's not universal
[10:41] <nevcairiel> apparently dash can also be webm
[10:41] <rcombs> and you usually have separate sets of segments for audio and video, so that's fun
[10:42] <wm4> nevcairiel: that's probably just google
[10:42] <wm4> I heard google uses a single mp4 file for dash video
[10:42] <rcombs> wm4: YouTube's DASH stuff is a single MP4 or WebM for video and a single MP4 or WebM for audio
[10:43] <rcombs> (well, multiple different versions at different bitrates, but you get the idea)
[10:43] <wm4> sure is lame
[10:43] <rcombs> though they might do things a bit differently for embedded platforms; I've only really looked at their desktop web stuff
[10:44] <rcombs> and as it turns out, processing streaming video segments through JS on an embedded platform with very limited RAM is actually a bad idea!
[10:44] <rcombs> because as soon as you get up to mid-to-high-bitrate 1080p H.264, you find that your GoPs (and segment files) are larger than your buffer sizes
[10:46] <rcombs> which is one reason why a lot of Chromecast apps don't do 1080p
[10:47] <rcombs> a pity, too; Chromecast links lavf and uses its Matroska decoder, which has no problems with larger GoPs and doesn't need to futz around with segments
[10:51] <wm4> so who will implement dash on lavf?
[10:51] Action: wm4 takes a step back
[10:53] <rcombs> do we already link an XML parser?
[10:54] <rcombs> if you want a DASH *encoder*, you might want to check out Plex's ffmpeg tarballs, which unfortunately I can't help merge changes from, but I can tell you about and give you URLs for
[10:55] <wm4> no, encoder is uninteresting
[10:55] <wm4> I don't think there's a xml parser yet
[12:01] <Daemon404> nevcairiel, i *did* send a patch and recent make.exe is indeed fixed for linebreaks
[12:01] <nevcairiel> then its just another 10 years until msys make is updated
[12:01] <nevcairiel> the official distributions anyway
[12:01] <Daemon404> lol
[12:02] <nevcairiel> is it in any make release version yet anyway?
[12:02] <nevcairiel> ie. 4.0?
[12:02] <Daemon404> maybe 4.0 if its out
[12:03] <nevcairiel> seems to be out
[12:55] <michaelni> ubitux, there are 2 coverity issues in libavfilter/f_ebur128.c (1194399 Bad bit shift operation and 1197046 Out-of-bounds access)
[12:55] <ubitux> arg i really need to look at this&
[13:08] <J_Darnley> Can I ask what the feature is called in make that we use in makefile:20, the %=% bit?
[13:08] <J_Darnley> AVPROGS    := $(AVPROGS-yes:%=%$(PROGSSUF)$(EXESUF))
[13:16] <nevcairiel> its a shorthand for pattern substitution, ie. the patsubst function
[13:16] <nevcairiel> replace % with %$SUFFIX
[13:20] <ubitux> michaelni: ok i found a way to fix one properly
[13:21] <J_Darnley> nevcairiel: thanks
[13:42] <dudelig> hi
[13:44] <dudelig> Can anyone tell me which code does the metadata for matroska formats provide?
[13:49] <cone-784> ffmpeg.git 03Clément BSsch 07master:b2c0b80f6291: avfilter/ebur128: rework channel weighting definition code
[13:49] <wm4> dudelig: what exactly? reading metadata from matroska files?
[13:49] <wm4> it's in libavformat/matroskadec.c
[13:51] <dudelig> it is, if I encode a stream to matroska format, ffmpeg saves metadata for mediainfo. where do these data come from?
[13:51] <wm4> ffmpeg.c
[13:51] <wm4> probably gets it from input files
[13:51] <wm4> actually I think the muxer also adds at least one field
[13:53] <dudelig> wm4	probably gets it from input files
[13:53] <dudelig> ^which code do I have to search for those data?
[13:55] <ubitux> michaelni: 1st fixed; about the second one, i'm basically doing double *out = alloc(...); and then sending &out as swr_convert; since it's not planar i don't see how it can cause a problem
[13:55] <ubitux> michaelni: should i mark it as a false positive?
[13:56] <wm4> dudelig: it's a field named "metadata", probably the one of the format context
[13:56] <wm4> also libavformat/matroskaenc.c
[13:57] <dudelig> thank you wm4. I ll search the ffmpeg.c and matroska*
[13:57] <dudelig> good bye
[14:04] <michaelni> ubitux, is its false positive, yes 
[14:04] <ubitux> ok thank you
[14:06] <ubitux> michaelni: i don't remember how to drop them from the list though :p
[14:07] <michaelni> i guess they "disapear" on the next coverity run
[14:07] <ubitux> ok
[17:31] <kierank> 9:54 AM <rcombs> if you want a DASH *encoder*, you might want to check out Plex's ffmpeg tarballs, which unfortunately I can't help merge changes from, but I can tell you about and give you URLs for
[17:31] <kierank> lol
[17:33] <wm4> now that I read this again it sounds pretty "funny"
[17:33] <wm4> like as if he's legally not allowed to upstream them
[17:33] <wm4> even though the license would allow it
[17:33] <wm4> (???)
[17:34] <nevcairiel> might not be a legal thing, just not getting fired thing :p
[17:34] <J_Darnley> Perhaps he has some "inside knowledge" that might leak if he merged it himself.
[17:49] <ePirat> I am trying to extract audio with ffmpeg to pcm_s24le, for some reason the resulting output file only is 15 minutes long
[17:49] <ePirat> but it should be about an hour
[17:54] <ePirat> is there some file size or legnth limitation or something?
[17:58] <nevcairiel> if its WAV, it would end at 2gb or so
[18:00] <ePirat> it'd about 4,72 GB big but exactly 15 minutes long
[18:00] <ePirat> *it's
[18:01] <nevcairiel> what sample rate is it that its this huge?
[18:01] <nevcairiel> and channels?
[18:01] <ePirat> ffmpeg -i "file.mkv" -vn -acodec pcm_s24le -r 24 -ar 48000 audio/all.wav
[18:01] <ePirat> it's 5.1 audio
[18:02] <ePirat> so 6 channel
[18:02] <ePirat> *channels
[18:03] <nevcairiel> well thats definitely going to be too big for wav
[18:03] <nevcairiel> the size field probably overflows and results in weird values
[18:04] <ePirat> which container would you recommend? or is there some way to make multiple files?
[18:04] <nevcairiel> that depends what you want to do with it after
[18:05] <ePirat> at the end I want to have each channel in a separate file, which I did with sox  
[18:06] <nevcairiel> if youre on windows, you could do it all in one step with eac3to, just sayin' :D
[18:07] <nevcairiel> it supports output to 1 wav per channel
[18:07] <nevcairiel> dont think ffmpeg has that
[18:07] <J_Darnley> w64 maybe?
[18:10] <ePirat> will try it, thanks
[18:12] <mark4o> the pan filter can extract one channel
[18:15] <ePirat> oh forgot about that, thank you mark4o!
[18:21] <kierank> 4:34 PM <"nevcairiel> might not be a legal thing, just not getting fired thing :p
[18:21] <kierank> 4:34 PM <"J_Darnley> Perhaps he has some "inside knowledge" that might leak if he merged it himself.
[18:21] <kierank> it's this thing that companies do
[18:21] <kierank> where they take ffmpeg or other OSS
[18:22] <kierank> but consider their changes secret
[18:22] <nevcairiel> well at least they provide a tarball
[18:23] <kierank> they have to
[18:24] <kierank> some could play the game where only their customers can request the code
[18:24] <kierank> but it's a dick move
[18:24] <nevcairiel> sure, but not everyone does it
[18:24] <kierank> not everyone - ie all of china
[18:24] <nevcairiel> china doesnt care about copyright or patents either way
[18:30] <iive> nevcairiel: they care only then they hold them :)
[20:02] <cone-784> ffmpeg.git 03Andreas Cadhalpun 07master:b76d6eb3bd70: avformat/mpegts: fix spelling error
[20:34] <cone-784> ffmpeg.git 03Diego Biurrun 07master:041caf1a63f0: avplay: Exit by default at the end of playback
[20:34] <cone-784> ffmpeg.git 03Michael Niedermayer 07master:f9bc65e399d1: Merge commit '041caf1a63f091745b95a6d51c23fbdcb604d4ce'
[20:34] <cone-784> ffmpeg.git 03Michael Niedermayer 07master:5732b2188425: ffplay: make autoexit the default
[20:49] <cone-784> ffmpeg.git 03Mickaël Raulet 07master:684d0a0b23dc: avcodec/hevc: fix dead code
[21:04] <cone-784> ffmpeg.git 03Reimar Döffinger 07master:87c7fb2b215f: aacsbr: support hardcoding tables.
[21:04] <cone-784> ffmpeg.git 03Reimar Döffinger 07master:0f1281b2b8ac: cabac: initialize all of ff_h264_cabac_tables programmatically.
[21:04] <cone-784> ffmpeg.git 03Reimar Döffinger 07master:092d1977cc71: cabac: Allow hardcoding CABAC table.
[21:04] <cone-784> ffmpeg.git 03Reimar Döffinger 07master:3dbf569032e7: huffyuvdec: avoid large stack use.
[21:25] <ubitux> michaelni: the ffplay behaviour changes belongs at the end of the RELEASE_NOTES
[21:26] <michaelni> ubitux, do you have time to add them ?
[21:27] <ubitux> that's just an entry line, sure i can do it :p
[21:27] <michaelni> thx
[21:43] <cone-784> ffmpeg.git 03Michael Niedermayer 07master:cbb277988afc: avcodec/hevc_ps: Always initialize backup in decode_vui()
[21:43] <cone-784> ffmpeg.git 03Michael Niedermayer 07master:1b2390e2bcdd: avfilter/af_silenceremove: remove dead code
[22:29] <michaelni> Timothy_Gu, do you have time to update our RELEASE_NOTES for 2.4 ?
[22:30] <Timothy_Gu> michaelni: I'll try
[22:30] <michaelni> thanks
[00:00] --- Sun Sep  7 2014