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

[burek]

[01:10:01 CEST] <friendofafriend> Actually communicating with the MPEG LA sounds terrifying.
[01:27:35 CEST] <freemint> Hello i try to findout whether my Intel i5 8250 running fedora 29 performs harware accelartion for video.
[01:28:25 CEST] <freemint> I tried figure that out by ffmpeg -i file -map 0:v:0 -c:v libx264  -f null - vs ffmpeg -i file -map 0:v:0 -c:v mpeg2_vaapi  -f null -
[01:29:38 CEST] <freemint> When i call anything goal codec ending in _vaapi i always get the error:
[01:29:39 CEST] <freemint> Impossible to convert between the formats supported by the filter 'Parsed_null_0' and the filter 'auto_scaler_0'
[01:29:39 CEST] <freemint> Error reinitializing filters!
[01:29:41 CEST] <freemint> Failed to inject frame into filter network: Function not implemented
[01:38:55 CEST] <friendofafriend> freemint: You're talking about QuickSync?
[01:39:49 CEST] <freemint> i think the technology i want to use is called libva or vaapi or vdpau
[01:40:12 CEST] <friendofafriend> And you're trying to hardware accelerate encoding on your Intel CPU, yes?
[01:40:27 CEST] <freemint> Encoding and decoding, yes
[01:41:17 CEST] <friendofafriend> You'll find some excellent information about it, here.  https://trac.ffmpeg.org/wiki/Hardware/QuickSync
[01:42:55 CEST] <freemint> Is it the same as quicksync?
[01:43:30 CEST] <friendofafriend> That's the term for hardware accelerated video encoding/decoding with Intel CPUs.
[01:43:38 CEST] <freemint> my intel is gen8
[01:45:06 CEST] <friendofafriend> Right, so the wiki recommends you use intel-vaapi-driver from the linked repo.
[01:46:28 CEST] <friendofafriend> There's a lot of example commands in the wiki, also.  You'll want to make sure the ffmpeg you have supports "qsv", in the first place.
[04:46:38 CEST] <Tu13es> hi folks, i have a mp4 whose audio/video goes out of sync part way through. is there a way I can adjust the video stream partway through?
[04:48:09 CEST] <Tu13es> i used -itoffset to fix some initial sync issues but it goes out of sync again later in the video
[15:07:02 CEST] <Atlenohen> Is it possible to disable audio of the mpegts muxer ? LATM and ADTS are added as muxers
[15:07:41 CEST] <Atlenohen> Not a big deal tho
[15:08:10 CEST] <cehoyos> They are a requirement
[15:08:18 CEST] <cehoyos> Actually a dependency
[15:08:38 CEST] <Atlenohen> Oh allright
[15:09:47 CEST] <JEEB> probably in order to minimize the amount of ifdefs in code
[15:11:36 CEST] <cehoyos> No, in this case the dependency was added because users protested that the mpegts muxer didn't work
[15:12:18 CEST] <JEEB> :)
[15:12:23 CEST] <Atlenohen> hmm, ffmpeg's configure treats .LIB files as "shared libs" and .a as static for MSVC and WIN64, while lib.exe according to everyone I talked never worked with .a files, whether shared or static
[15:13:14 CEST] <JEEB> Atlenohen: yea I think in msvc nomenclature .lib is generally utilized for both the stubs as well as static libs I think
[15:14:37 CEST] <Atlenohen> So my MSYS2 MINGW MSVC build attempt with x264 is stuck with these invalid .a files, they look like they're COFF (!<arch>) format but their size is too small IMO, I have more muxers/encoders and it's 3 times the size of the older library which has only 1 muxer and 1 encoder
[15:15:20 CEST] <Atlenohen> So I get errors in VS2017,LNK2019 unresolved external symbol BCryptOpenAlgorithmProvider referenced in function av_get_random_seed avutil.lib(random_seed.o)
[15:16:44 CEST] <BtbN> .lib and .a are virtually the same
[15:16:56 CEST] <cehoyos> The error you quote is definitely not related to x264
[15:16:57 CEST] <Atlenohen> 3 times less size, the old lib is 10 MB and I have 3 MB
[15:17:02 CEST] <BtbN> it's impossible to tell, other than by guessing based on file size.
[15:17:29 CEST] <BtbN> Cause an import-.lib is technically also just a static lib, but only containing trampolines
[15:17:44 CEST] <cehoyos> It sounds more as if you forgot to tell which native Windows libraries libavutil needs
[15:17:55 CEST] <BtbN> 3MB is still way too large for it to be just an import-lib
[15:18:32 CEST] <cehoyos> 3MB sounds correct for x264
[15:19:08 CEST] <Atlenohen> cehoyos: I had same kind of errors pointing to avcodec.lib(libx264.o) previously, someone else told me that static libs dependencies may not be packing themselfs like russian dolls and that the 3rd C++ project needs all the includes so I added them, the x264 errors turned into warnings and new errors pointing to ffmpeg stuff shown up
[15:19:35 CEST] <cehoyos> I saw some of the nonsense you were told yesterday;-)
[15:19:48 CEST] <cehoyos> Atm, I only see an error message that you quoted and that is not related to x264
[15:20:02 CEST] <Atlenohen> cehoyos: these are the x264 warnings now LNK4217 locally defined symbol x264_levels imported in function X264_init avcodec.lib(libx264.o)
[15:20:46 CEST] <JEEB> I don't think static libs have dependencies noted in them so you need to link all of the stuff (usually noted by pkg-config implementations), and preferably in the right order for your linekr
[15:20:50 CEST] <JEEB> *linker
[15:20:53 CEST] <Atlenohen> cehoyos: cause I was around 5 other channels all day long, so it's a bit spread around, I was on #msys on OFTC alot, on ##linux, on ##c++-general, etc
[15:21:20 CEST] <Atlenohen> BtbN cause I want full static libs, not DLL import libs
[15:21:39 CEST] <BtbN> You'll need to make sure all your dependencies are static libs then
[15:21:42 CEST] <cehoyos> I don't think the Windows C library is available as a static library, is it?
[15:21:49 CEST] <BtbN> It is
[15:22:05 CEST] <cehoyos> And also all other Windows system libraries?
[15:22:06 CEST] <BtbN> You don't want that though, cause it comes with Windows anyway, and is huge
[15:22:08 CEST] <cehoyos> I didn't know that.
[15:22:21 CEST] <BtbN> Like, 30MB or so
[15:22:37 CEST] <BtbN> And it's part of Windows in every still supported release
[15:22:38 CEST] <cehoyos> I mean I didn't know that all Windows system libraries exist as static libraries.
[15:22:53 CEST] <JEEB> I didn't know if all of them did?
[15:22:59 CEST] <Atlenohen> X264 building is a lot different, look a lot different output, and lib.exe command is clearly shown at the end and a .lib is made, but I have independently confirmed that AR (archive tool) is indeed lib.exe so the problem may be somewhere else
[15:23:28 CEST] <JEEB> msvcrtXXX was a thing that definitely had static versions though
[15:23:30 CEST] <cehoyos> As long as you don't tell us your problem, it is unlikely that we will be able to help you;-)
[15:23:41 CEST] <Atlenohen> BtbN: Yes I built x264 as static, there's no other dependencies that I'm aware of.
[15:24:07 CEST] <cehoyos> x264 can have several dependencies but this was not the issue of the error message you quoted above.
[15:25:37 CEST] <Atlenohen> cehoyos: I wish I knew what the problem was. Simply put the .a files (which I renamed to .lib) that got generated all day yesterday in those conditions weren't valid for the C++ project which always used and is using static ffmpeg libs
[15:26:15 CEST] <Atlenohen> I did further config adjustments, added more params, will try again now, and I'll paste all the config's
[15:26:23 CEST] <cehoyos> They weren't valid? You mean you created libraries incompatible with the toolchain you want to use?
[15:26:45 CEST] <cehoyos> Instead of pasting the config's you should maybe tell us the error you get.
[15:27:07 CEST] <Atlenohen> x264 build and ffmpeg build were all successful, it was a struggle to just get to some result.
[15:27:27 CEST] <Atlenohen> There's no error in x264 or ffmpeg builds in MSYS2 MINGW shell
[15:27:32 CEST] <cehoyos> (Given that static compilation is the default, this is a little surprising)
[15:27:34 CEST] <BtbN> You cannot use gcc built .a files in msvc builds. They will be targetting a different libc
[15:29:10 CEST] <Atlenohen> BtbN: this is what I was trying to figure out yesterday evening with someone on a C++ channel, but we confirmed MSYS2 MINGW64 shell is indeed using lib.exe from MSVC because I got an error if it didn't find it, i also forced option --ar=lib too
[15:29:40 CEST] <Atlenohen> So it's not using ar.exe in MSYS2/MINGW64, even tho ffmpeg's output prints "AR    libavcodec.a"
[15:30:05 CEST] <JEEB> AR is just "whatever is set to be your 'ar' equivalent"
[15:30:11 CEST] <JEEB> I think the more specific output is with make V=1
[15:30:19 CEST] <JEEB> which outputs the actual commands if you wish to see those
[15:30:34 CEST] <cehoyos> To answer the question that you have not yet asked: You need the additional import library Bcrypt.lib for libavutil in your project.
[15:31:14 CEST] <Atlenohen> x264 build log printed lib.exe and the full command referencing all .o files, I'm sure probably that's what it's done under the hood in ffmpeg case, the messaging may just be different, although for a novice user that's sometimes very confusing but I managed to figure things out
[15:32:50 CEST] <Atlenohen> cehoyos: Oh well, if it's that easy ... I never knew about it's existence so I couldn't have been able to ask it, I might have figured it out by searching the error, but hours later probably.
[15:33:22 CEST] <cehoyos> I didn't know about its existence either but it took me a minute to find out.
[15:33:25 CEST] <Atlenohen> cehoyos: this is something the ffmpeg's build log should have warned about, (or maybe i should have enabled warn failure)
[15:34:22 CEST] <cehoyos> Please provide the output of: make libavutil/libavutil.pc && cat libavutil/libavutil.pc
[15:34:40 CEST] <Atlenohen> JEEB: V=1, oh the messaging configuration, thanks
[15:35:07 CEST] <Atlenohen> cehoyos: after the build? I cleaned it so I'll have to rebuild, moment
[15:35:20 CEST] <cehoyos> No, you don't have to rebuild
[15:35:22 CEST] <Atlenohen> or wait, maybe it's still in the output folder
[15:35:33 CEST] <JEEB> his command specifically re-builds the pc file
[15:35:35 CEST] <JEEB> :)
[15:35:38 CEST] <JEEB> (only)
[15:35:50 CEST] <JEEB> (or makes sure it exists if you have some build outputs still there)
[15:36:06 CEST] <Atlenohen> Ofocurse, I'm totally new to this.
[15:36:39 CEST] <BtbN> lib and ar are just archiv creating tools for virtually the same format
[15:37:05 CEST] <BtbN> It's the object files inside that matter
[15:37:21 CEST] <cehoyos> I am curious about something else: What is your original issue? After all, the default builds are static.
[15:38:21 CEST] <Atlenohen> cehoyos: https://pastebin.com/5pAE8xcL
[15:39:31 CEST] <cehoyos> So, if I count correctly there are three ways to immediately tell you that bcrypt.lib is a needed library (I was just interested in this one because I was curious if pkg-config really works, I doubted it). Where id you look?
[15:39:56 CEST] <Atlenohen> BtbN: I worked with delayloaded DLLs and their .libs, while there is similarities they look a lot different in text editor and they're much smaller, only a few 100 KBs at most, I am thinking maybe FFMPEG has improved in years so much there's less code needed for the stuff I'm using
[15:40:01 CEST] <cehoyos> The easiest would be "rm ffmpeg_g && make V=1 ffmpeg_g"
[15:40:08 CEST] <Atlenohen> unrelated project*
[15:40:15 CEST] <cehoyos> after building FFmpeg
[15:40:59 CEST] <cehoyos> This is extremely unlikely: The FFmpeg libraries grow each year.
[15:41:25 CEST] <Atlenohen> cehoyos: after ffmpeg built, there was no any indication of anything wrong, so I just spent 3 hours figuring out why .a, and all that was a long story, I then just put .a renamed to .lib manually and see what happens, and here we are
[15:41:53 CEST] <cehoyos> Why do you believe that anything went wrong?
[15:41:55 CEST] <Atlenohen> The log was long, I didn't check all warnings, but if it's a needed lib it probably should have been an error, no big deal, it may be a bug
[15:42:28 CEST] <cehoyos> Why would there be a bug?
[15:42:39 CEST] <Atlenohen> cehoyos: Such thing should show an error by default, not my me having to explicitly use some verbose output mode. Error happened when it didn't find x264.lib so why not bcrypt.lib
[15:42:49 CEST] <cehoyos> What should show an error by default?
[15:43:24 CEST] <cehoyos> You showed us an error when compiling your project and - as said - it was immediately clear what was missing. Then you asked if FFmpeg didn't know about the dependency, and yes, it knew.
[15:43:37 CEST] <cehoyos> (I forgot that configure also told you about the dependency, that makes four times)
[15:44:10 CEST] <Atlenohen> If ffmpeg needs it for building then ffmpeg. So you're trying to say it's some dependency which is needed but not at build time, so VS2017 project would need it?
[15:44:17 CEST] <cehoyos> * what was missing although I don't compile on Windows and I had never heard about this library before.
[15:44:58 CEST] <cehoyos> It is needed at build time which is why FFmpeg's build system first told you about it, wrote it down for you and used it when linking ffmpeg (the application).
[15:46:24 CEST] <Atlenohen> Look I just woke up in the morning after doing that for 14 hours straight yesterday, Bcrypt error happened late yesterday and I called it quits, so I haven't had the chance to search, I did assume and didn't check if it's something else so I didn't rush to search what it means
[15:47:22 CEST] <Atlenohen> I'm going to repeat build now, and I'll pay attention at the log
[15:50:11 CEST] <cehoyos> (I didn't suggest to pay more attention to the log, just that it is not difficult to find out about additional dependencies and that afaics, there is no bug.) You still haven't answered my question what your original issue is: What is wrong with the Zeranoe builds?
[15:50:55 CEST] <Atlenohen> I haven't saw that question before - zeranoe does not provide static libs, those are shared libs
[15:51:40 CEST] <Atlenohen> the .lib files are just refs to the .DLLs, they're not the same, but they kinda look the same since the extension is the same .lib
[15:52:14 CEST] <Atlenohen> MS uses same extension for both, it's nothing new, it's just one more stupid thing MS does.
[15:53:10 CEST] <Atlenohen> Plus, I need a custom build with only a few components, not the full blown ffmpeg.
[15:54:09 CEST] <Atlenohen> And I generally am interested in learning how to build my self, ffmpeg happened to be the first one for me.
[15:54:54 CEST] <cehoyos> I see.
[15:55:54 CEST] <Atlenohen> And, you know it kinda looked as if I couldn't search this one little error, as I explained, circumstances, .. I'm exhausted!
[15:56:19 CEST] <Atlenohen> As if I didn't turn over the whole internet yesterday ;)
[15:56:57 CEST] <BtbN> Atlenohen, yes, DLLs work because they can link in their own libc. When static linking the whole application and all libs and their libs have to aggree on the same libc.
[15:57:39 CEST] <BtbN> The .lib for loading DLLs and true static .lib files don't only look the same, they are the same.
[15:58:01 CEST] <BtbN> The .lib to load a dll just has a GetProcAddress based shim function for every function in the dll
[16:00:53 CEST] <Atlenohen> BtbN: We had a big discussion on the .a and .lib differences yesterday, I went in ##linux at one point and called for real linux people to tell me the first 8 bytes of a .a file they had, and the result was some had ELF and some had !<arch> format (COFF) which is the format used by LIB.EXE while linux utils can do both but they usually don't name .lib they name it .a so you have another confusion on linux cause not .a files may be
[16:00:53 CEST] <Atlenohen> the same format, that's one thing
[16:01:23 CEST] <BtbN> both .a and .lib files are just ar archives with object files in them
[16:01:44 CEST] <BtbN> That's not the issue at all
[16:02:05 CEST] <BtbN> It's what built that code inside and what libraries and runtime it expects to have access to
[16:02:49 CEST] <Atlenohen> Second thing is, the !<arch> files thhe ones are static are several times larger than the ones that are only references, all it takes is taking a look at zeranoe's build, avcodec.lib is 128 kilobytes large, tell me how can that be a static library ?
[16:02:50 CEST] <BtbN> If you build libx264 with msvc and ffmpeg with mingw64, or vice versa, that will explode because one expects Microsoft CRT, and the other the gcc libc
[16:03:08 CEST] <BtbN> Zeranoe does not offer static libraries
[16:03:13 CEST] <BtbN> For license reasons
[16:03:29 CEST] <BtbN> There are static fftools and shared libraries
[16:03:35 CEST] <BtbN> no static libraries
[16:04:21 CEST] <Atlenohen> But he offers .libs which look like static libs but they aren't so the argument is when you said all .libs are the same which just doesn't make sense.
[16:04:43 CEST] <BtbN> All libs are, in their essence, static libraries.
[16:04:56 CEST] <BtbN> But some of them are just empty shim ones that load a .dll and forward to it.
[16:05:28 CEST] <BtbN> That's a Windows specific btw., on Linux you can link directly against .so files, so there is no need for import .libs
[16:06:06 CEST] <BtbN> Only real way to tell on Windows is to either decompile the .lib and look what it does. Or it's plain obvious by its size.
[16:06:19 CEST] <Atlenohen> Sure if you want to treat such a significant practical difference as a small technical details than that's your opinion, to me that's a major difference, and while you may be right about the technical aspect of the files themsefls, in practice, it's a night and day difference.
[16:06:28 CEST] <BtbN> gcc/mingw on Windows has adopted the .dll.a vs. .a scheme to differentiate the two
[16:08:26 CEST] <Atlenohen> At least that. But I do agree with the .lib exention, althought only for "independent static libs" for "reference libraries" i'd use something like ".rlib" or ".dlib"
[16:08:47 CEST] <BtbN> That will confuse the hell out of the linker and build system though
[16:09:00 CEST] <BtbN> Cause for them, there is zero difference between a shim .lib and actual static lib .lib
[16:09:06 CEST] <BtbN> They work and behave the same
[16:09:27 CEST] <BtbN> And Windows likes its file extensions
[16:09:37 CEST] <Atlenohen> I do however find .a extension kinda like linux usually does, put some random name on it, weird, you know the trend of naming software after some random anime/manga name, which makes zero relevance/sense.
[16:09:48 CEST] <BtbN> ?
[16:10:06 CEST] <BtbN> It's called .a because it's an ar archive.
[16:13:00 CEST] <Atlenohen> Well, yeah I did eventually heard that. Oh and I didn't mean that with linux, at least I feel it's a recent trend, I think I saw an utility called "Candy" or something.
[16:13:52 CEST] <Atlenohen> Nevermind, I don't remember it was several months ago, but it doesn't help with making things less confusing.
[16:24:39 CEST] <Atlenohen> cehoyos: There is no mention of bcrypt.lib in the default output log (without V=1)
[16:26:52 CEST] <Atlenohen> https://pastebin.com/HHTDU8wd
[16:34:18 CEST] <cehoyos> Atlenohen: Missing configure output
[16:34:47 CEST] <Atlenohen> Yeah I was about ot
[16:36:47 CEST] <Atlenohen> cehoyos: Configuration https://pastebin.com/7WktAgFC
[16:38:13 CEST] <cehoyos> Indeed, bcrypt is not mentioned, feel free to send a patch.
[16:38:21 CEST] <cehoyos> Note that your configure line has multiple issues...
[16:39:04 CEST] <Atlenohen> pkg config probably since I pasted it later on from a forum, but it didn't made a diff apparently
[16:47:05 CEST] <cehoyos> Try: $ ./configure --toolchain=msvc --disable-all --enable-avformat --enable-avcodec  --enable-gpl --enable-protocol=file --enable-muxer=webm,matroska,mpegts,rawvideo,mxf,frame* --enable-libx264 --enable-encoder=mpeg4,libx264*,bmp,ffv*,rawvideo
[16:47:45 CEST] <Atlenohen> Will do
[16:48:53 CEST] <Atlenohen> Althought I was thinking, maybe bcrypt is needed by framecrc/hash/md5 that looks related, those aren't that that super necessary (but it comes useful for debug), so I could do another test later without those
[16:49:29 CEST] <cehoyos> You cannot disable it
[16:49:50 CEST] <cehoyos> Sorry, you can, but you have to remove a header from your toolchain
[16:50:14 CEST] <cehoyos> (Or patch the FFmpeg source code)
[16:50:56 CEST] <furq> it's required for the matroska muxer
[16:51:06 CEST] <cehoyos> ./configure --disable-autodetect --toolchain=msvc --disable-all --enable-avformat --enable-avcodec  --enable-gpl --enable-protocol=file --enable-muxer=webm,matroska,mpegts,rawvideo,mxf,frame* --enable-libx264 --enable-encoder=mpeg4,libx264*,bmp,ffv*,rawvideo
[16:51:21 CEST] <cehoyos> Is more similar to what you did (disable-autodetect)
[16:51:30 CEST] <cehoyos> I don't know if it has an effect on bcrypt
[16:52:07 CEST] <furq> bcrypt is used for av_get_random_seed on windows
[16:52:10 CEST] <cehoyos> furq: I don't see a requirement for bcrypt or do I misundersatnd?
[16:52:32 CEST] <furq> which is called a couple of times in matroskaenc
[16:52:51 CEST] <furq> apparently the mxf muxer needs it as well
[16:53:00 CEST] <cehoyos> Yes, but the function doesn't need it.
[16:54:48 CEST] <Atlenohen> Building the first command - maybe the old libs were larger because they were build with debug (as I have the original configure command, or it looks like it, good thing it gets copied over to the .lib)
[16:55:17 CEST] <Atlenohen> Debug is enabled here now, so it looks like it's the default.
[16:56:45 CEST] <Atlenohen> Debug Symbols* - didn't made a difference to the size of he .a libs
[16:56:48 CEST] <furq> i guess it's not required then but that's what's pulling it in
[16:59:40 CEST] <furq> you can probably just use --disable-bcrypt if it's causing issues
[17:01:26 CEST] <Atlenohen> No wait
[17:01:52 CEST] <Atlenohen> cehoyos: I was looking at the old --prefix, it picked /usr/local in MSYS2
[17:02:59 CEST] <Atlenohen> the libraries appear to be of the expected size, slightly larger, 11 MB for libavcodec ... but is this due to debug symbols, idk, it's still at least positive indication.
[17:03:16 CEST] <Atlenohen> the old was 9.x MB
[17:05:32 CEST] <Atlenohen> What about cflags, loks like defining -I and -L wasn't necessary, but I hope the autodetect used -GS- for disabling Buffer Security
[17:15:52 CEST] <furq> 15:59:40 ( furq) you can probably just use --disable-bcrypt if it's causing issues
[17:15:55 CEST] <furq> ok apparently you can't do this
[17:15:59 CEST] <furq> that's slightly annoying
[17:18:21 CEST] <Atlenohen> I'm building C++ Solution right now with the first build
[17:21:19 CEST] <Atlenohen> Looks like Swscale is required by the C++ solution, I'll have to rebuild ffmpeg
[17:35:33 CEST] <Atlenohen> Yeah bcrypt again
[17:36:49 CEST] <Atlenohen> yeah, debug symbols make a big diff in lib size
[17:39:10 CEST] <cehoyos> ./configure --disable-autodetect --toolchain=msvc --disable-all --enable-avformat --enable-avcodec --enable-swscale --enable-gpl --enable-protocol=file --enable-muxer=webm,matroska,mpegts,rawvideo,mxf,frame* --enable-libx264 --enable-encoder=mpeg4,libx264*,bmp,ffv*,rawvideo
[17:42:25 CEST] <Atlenohen> I would need to do multiple into the PKG config then
[17:45:55 CEST] <Atlenohen> Sure, I found that environmental vars are set up, but they don't point directly to /um/x64 where bcrypt.lib is apparently, still checking
[17:47:39 CEST] <Atlenohen> ah spoke too soon, it does
[17:51:51 CEST] <Atlenohen> but can't check it if accessible in shell
[17:52:03 CEST] <Atlenohen> tried cat bcrypt.lib but won't work.
[18:05:13 CEST] <Atlenohen> I probably have to make universal pkgconfig and add another pkgconfig entry, not directly to just x264
[19:03:29 CEST] <Atlenohen> cehoyos: If I turn autodetect off wouldn't then some options which are enabled by default be turned on? Like pthreads?
[19:12:51 CEST] <cehoyos> Atlenohen: (What you write - "wouldn't turning autodetect off turn autodetection on?" - makes little sense imo), either pthreads or win32threads is the default, I forgot which: Use either --disable-pthreads or --enable-w32threads if you don't like the default, no need to use both
[19:14:07 CEST] <Atlenohen> Well since there's much less, i'd leave autodetect on, probably it's good to do it simple first, then define it more specifically later on
[19:16:28 CEST] <cehoyos> No, I can see from your configure line that you do not want autodetection
[19:16:56 CEST] <cehoyos> (I always recommend to leave it on and I regularly fight for more auto-detection but judging from your configure line it is not what you want)
[19:17:21 CEST] <Atlenohen> But I'm not using mine anymore, i'm using your now
[19:17:28 CEST] <cehoyos> Note that my recommendation - contrary to what you have used so far - is to do it simple first
[19:18:22 CEST] <cehoyos> My suggestion from 16:51 was to turn auto-detect off
[19:18:22 CEST] <Atlenohen> Well, it still works the same, right now I'm trying to combine PKGCONFIG for both x264 and Bcrypt
[19:18:49 CEST] <cehoyos> But I am not sure what the default threads type for msvc is
[19:19:16 CEST] <cehoyos> I don't think there is PKGCONFIG for Bcrypt...
[19:19:31 CEST] <cehoyos> And you don't need it for x264 as it also works without
[19:19:38 CEST] <cehoyos> (Some libraries absolutely need it)
[19:19:55 CEST] <Atlenohen> I moved the pkgconfig for x264 and made it for Bcrypt in a central location inside msys64/usr/local/.../pkgconfig but it has trouble locating x264
[19:20:07 CEST] <Atlenohen> so I kinda have to fiddle with it
[19:20:39 CEST] <Atlenohen> Because I can't link to just x264, I need included more than one dependency then
[19:21:30 CEST] <cehoyos> Instead of fiddling supply --extra-cflags=-i/path/to/x264/include --extra-ldflags=-L/path/to/x264/library
[19:21:48 CEST] <Atlenohen> Sure ... but what about bcrypt
[19:21:58 CEST] <cehoyos> I have x264 on the same "level" as FFmpeg, so here it is: --extra-cflags=-I../x264 --extra-ldflags=-L../x264
[19:21:59 CEST] <Atlenohen> I never got cflags working anyway
[19:22:08 CEST] <cehoyos> capital I...
[19:23:08 CEST] <cehoyos> It's not difficult: clone x264, cd into x264, build it, cd .., clone FFmpeg, cd into FFmpeg, configure with --enable-gpl --enable-libx264 --extra-cflags=-I../x264 --extra-ldflags=-L../x264
[19:23:08 CEST] <Atlenohen> well I did i just left it as --extra-cflags=-I until you removed it which means it wasn't necessary at all as PKGCONFIG worked
[19:23:33 CEST] <cehoyos> It should have returned an error imo because -I needs a parameter...
[19:23:36 CEST] <cehoyos> awk
[19:23:55 CEST] <Atlenohen> But it did work make, and I did put it in C++ and it was the same result, BCRYPT issue
[19:24:53 CEST] <Atlenohen> I have x264 as separate gitrepo, I guess move the whole thing into ffmpeg then, along with bcrypt
[19:25:24 CEST] <Atlenohen> Bcrypt is accessible, no idea why it doesn't take it, as if a config is missing, because it is part of INCLUDE environment that MS Dev Cmd makes
[19:25:46 CEST] <Atlenohen> So I wanted to try to force bcrypt inclusion by making a pkconfig for it
[19:29:39 CEST] <Atlenohen> The .a thing's pretty much done, i found LIBSUF whihc defines it, i'll force change it to .lib in the configure it self, done! :D
[19:29:56 CEST] <Atlenohen> in the configure file it self*
[19:43:10 CEST] <Atlenohen> cehoyos: well can you confirm the extact values, no dots, one dot, two dot  -Ipath ?
[19:43:28 CEST] <Atlenohen> actual folder like include, libs, or root one like x264 ?
[20:05:09 CEST] <Atlenohen> cehoyos: nothing works with flags
[20:05:42 CEST] <Atlenohen> that's why I came to pkconfig, I put all combinations, .. dots, one dot, no dots, no slash, while I had the x264 in ffmpeg and in usr/local
[20:06:06 CEST] <Atlenohen> msys64/usr/local that is, now I typed out the full path, still nothing, it's broken or what
[20:06:34 CEST] <Atlenohen> # ./configure --toolchain=msvc --extra-cflags=-I/c/msys64/usr/local/dependency/x264/include --extra-ldflags=-L/c/msys64/usr/local/dependency/x264/lib
[20:10:45 CEST] <Atlenohen> if it given me the path where is it searching
[20:11:14 CEST] <Soni> can ffmpeg hwdecode with my GPU and hwencode with my CPU?
[20:14:38 CEST] <ncouloute> yes it can
[20:18:25 CEST] <garyserj> What commands would help convert an mp4 with this profile https://pastebin.com/raw/XD5YnaLg  into an mp4 with this profile https://pastebin.com/raw/b5xqFLxy ?
[20:28:51 CEST] <ncouloute> Soni you can specify the decoder before the input (-i) for example for nvidia. (-hwaccel cuvid -c:v h264_cuvid -i "Path\to\ConvertMe.mp4")
[20:29:54 CEST] <ncouloute> garyserj - unlikely someone will give you the exact flags. It isn't that hard to figure it out. Documentation for that kind of stuff is pretty good.
[20:31:15 CEST] <Soni> what about intel and amd (mesa)?
[20:34:37 CEST] <ncouloute> -hwaccel qsv -c:v h264_qsv -i "Path\to\ConvertMe.mp4" for intel. I'm not sure there is a AMD specifi decoder yet. I know there is an encoder. At least not in the zeranoe i use. There are a few generic hw decoders that arent brand specific
[20:37:07 CEST] <Atlenohen> cehoyos: That does it had to put an end to this, deep monitoring: I can see that CL.exe is accessing bcrypt.h in the configuration process, which surely means it's also possible in the making process, and link.exe is accessing crypt.lib in the default directory, it first tries to find it in the ffmpeg repo root directory, tries a few other MS directories and then finds it in the existing default location
[20:38:23 CEST] <Atlenohen> I think I have the latest or at least almost latest Win10 SDK ... what if the bcrypt is TOO HIGH version ????
[20:38:39 CEST] <Atlenohen> C:\Program Files (x86)\Windows Kits\10\Lib\10.0.17134.0\um\x64\bcrypt.lib
[20:48:22 CEST] <garyserj> ncouloute: both are x264 and both are AAC so i've no idea
[20:49:33 CEST] <garyserj> the main difference is one of them have "writing library" and "encoding settings" and the other doesn't
[20:49:59 CEST] <garyserj> but i've no idea how to convert one that does into one that doesn't
[20:53:24 CEST] <Atlenohen> Cehoyos: okay we got the full picture now, cflags actually works, it forwards the -I/path parameter to CL.exe, CL.exe finds x264.h successfully
[20:54:48 CEST] <Atlenohen> Cehoyos: link.exe receives nothing from --extra-ldflags and this is probably what I was hinting at previously, there is no "-L" option I found on the MS documentation sites I checked 2 days ago (i'll do again as soon as I finish writing this)
[20:55:06 CEST] <Atlenohen> It must be a legacy option that was deprecated and removed, replaced
[20:56:01 CEST] <Atlenohen> so link.exe (not the MSYS2 link.exe, i disabled that, this is actual MSVC link.exe) first looks into the ROOT FFMPEG directory where were configuring, it doesn't find it.
[20:56:49 CEST] <Atlenohen> Link.exe then tries C/msys64/mingw64/lib/ directory, doesn't find it, then it tries the FFMPEG root again
[20:58:02 CEST] <Atlenohen> It then tries 3 other Windows Kits "lib" directories (which are part of $INCLUDE and other env variables), doesn't find it there obviously, then tried FFMPEG root again, and that's it, nothing found so we get an error in MSYS2 MINGW64 Shell
[20:59:41 CEST] <Atlenohen> The workaround is obviously to try to move it there where it's looking at, or using the PKCONFIG which worked previously, but PKCONFIG's also hit and miss, I'll debug it as well to get an idea
[20:59:55 CEST] <Atlenohen> PKGCONFIG*
[21:01:11 CEST] <Atlenohen> https://docs.microsoft.com/en-us/cpp/build/reference/libpath-additional-libpath?view=vs-2019   let's try this
[21:03:44 CEST] <Atlenohen> didn't work, maybe the whole --extra-ldflags is broken the way it's scripted, i'll see... I'm pretty much developing ffmpeg at this point lol
[21:03:57 CEST] <Atlenohen> debugging it at least
[21:04:38 CEST] <Atlenohen> I have no choice but to go to the bottom of it, and well, probably would be great if I can contribute back too.
[21:40:02 CEST] <ncouloute> garyserj - In the case of encoding settings and writing library. That is telling you that the original file was made with x264 using those specific flags. You care more about the resulting file info as you are trying to emulate that
[21:56:36 CEST] <_bt> hello, i have some 1080p60 h264 video which i want to timelapse. i'm using 'ffmpeg -i 2019_0412_202119_001.MP4 -vf framestep=30,setpts=N/60/TB,fps=60 -an out.mp4' to create the timelapse. it works well, but the output file is the same length as the input file, only with the last frame displayed for the remainder of the video. where am i going wrong?
[22:11:57 CEST] <_bt> cracked it: ./ffmpeg -discard nokey -i 2019_0412_202119_001.MP4 -vf "setpts=0.0120*PTS" -an out3.mp4
[22:12:00 CEST] <_bt> see ya
[22:12:26 CEST] <poutine> I feel like that guy has been asking the same question for months now
[22:15:07 CEST] <HickHoward> uhhh
[22:15:16 CEST] <HickHoward> how as ATRAC3 reverse-engineerred in the first place?
[22:17:35 CEST] <JEEB> by finding a decoder and looking what it did inside
[22:17:51 CEST] <JEEB> nowadays you can get rather fancy decompilers etc in open source
[22:17:56 CEST] <JEEB> like NSA's ghidra being the latest
[22:19:07 CEST] <JEEB> sometimes of course you might also find something documenting the format
[22:19:10 CEST] <JEEB> often this is not the case
[22:19:42 CEST] <JEEB> and then you have people documenting their findings
[22:19:46 CEST] <JEEB> f.ex. https://wiki.multimedia.cx/index.php/ATRAC3plus
[22:21:45 CEST] <faLUCE> JEEB: yesterday I got an answer from MPEG LA
[22:22:41 CEST] <HickHoward> he
[22:22:45 CEST] <HickHoward> *heh
[22:25:05 CEST] <durandal_1707> faLUCE: and?
[22:25:35 CEST] <faLUCE> durandal_1707: they told me that "Based on your explanation below, I understand that you will not be offering end products with AVC functionality for Sale. Rather, you will simply publish source code.  Therefore, your understanding is correct that you would not benefit from coverage under our AVC License in that case."
[22:27:23 CEST] <faLUCE> what could  it mean? does it mean that the license is not required?
[22:28:34 CEST] <faLUCE> it seems to confirm what the old threads pasted by JEEB said
[22:29:14 CEST] <faLUCE> (given that source code is not an end product)
[22:32:05 CEST] <faLUCE> yes, it confirms that
[22:33:46 CEST] <faLUCE> then MPEG-LA seems to be perfectly compatible with FOSS non commercial stuff
[22:50:17 CEST] <iive> faLUCE, the last statement doesn't seem correct
[22:50:32 CEST] <faLUCE> iive: why?
[22:51:33 CEST] <iive> they told you that simply publishing the source code is OK. that has always been the case.
[22:51:49 CEST] <iive> distributing working program for free is separate issue
[22:51:56 CEST] <faLUCE> iive: yes, you are right
[22:52:03 CEST] <iive> so is distributing working program for money.
[22:53:06 CEST] <iive> that's why cisco basic avc codec exists...
[22:53:26 CEST] <faLUCE> iive: anyway, the important thing is that MPEG LA is absolutely not against non commercial open source
[22:53:33 CEST] <faLUCE> this is very good
[22:54:31 CEST] <faLUCE> I think it's ethical
[22:59:09 CEST] <cehoyos> Atlenohen: It's unlikely that we would accept a change to how --extra-ldflags work, it is working for many people for a very long time.
[22:59:14 CEST] <cehoyos> Please explain what is not working for you
[23:00:39 CEST] <cehoyos> " then MPEG-LA seems to be perfectly compatible with FOSS non commercial stuff"
[23:00:43 CEST] <cehoyos> No, this is not correct
[23:00:51 CEST] <cehoyos> And please do not repeat this again and again
[23:01:18 CEST] <cehoyos> "anyway, the important thing is that MPEG LA is absolutely not against non commercial open source"
[23:01:27 CEST] <cehoyos> This is of course also not true, on the contrary
[23:01:42 CEST] <faLUCE> cehoyos: why?
[23:08:22 CEST] <cehoyos> The MPEG-LA tries (actively) to oppress the freedoms that open source implies: They do not allow re-distribution.
[23:09:01 CEST] <cehoyos> The re-distribution that free software implies of course includes binary distribution, it is not limited to source distribution.
[23:09:32 CEST] <cehoyos> Note that I clearly remember a C interpreter, I wonder what happens if MPEG-LA remembers it;-)
[23:10:44 CEST] <faLUCE> cehoyos: I did not even know that a C interpreter does exist!
[23:11:03 CEST] <faLUCE> cehoyos: but would it have performance issues...?
[23:13:42 CEST] <cehoyos> Yes =-)
[23:13:59 CEST] <JEEB> cehoyos: I would guess the intent of the distributor is what will end up meaning something in the courts :) f.ex. "just distributing code" in python or JS and expect that to be OK in their eyes (in case you get on one of these patent licensing things' radar)
[23:14:23 CEST] <JEEB> but yes, all this patent licensing is a mess :P
[23:14:35 CEST] <JEEB> full of "let's make things not clear to not make promises"
[23:14:53 CEST] <faLUCE> JEEB: but a native python x265 encoder would never exist...
[23:15:32 CEST] <JEEB> why not? just like fabrice made a JS decoder (not sure if he used emscripten with HM or the lavc thing)
[23:16:07 CEST] <faLUCE> JEEB: I mean _encoders_  .... because it would not take full advantage of the current technology
[23:16:33 CEST] <cehoyos> My point is just that this isn't patent-law-exchange, and it would be great if we could agree that we cannot know what exactly the MPEG-LA thinks. I still don't know faLUCE's use case...
[23:16:42 CEST] <JEEB> very true
[23:16:47 CEST] <JEEB> we are all very much not lawyers
[23:16:58 CEST] <JEEB> (and even if we are, we don't want to give out law advice)
[23:16:59 CEST] <cehoyos> I usually read irc-log and this goes on for far too long;-)
[23:17:09 CEST] <cehoyos> Correct!
[23:17:43 CEST] <faLUCE> I was interested in understanding all the sides of open source digital-audio video
[23:18:02 CEST] <faLUCE> because I see that it's a mess!
[23:18:43 CEST] <faLUCE> anyway, I'm thinking seriously to switch to theora
[23:19:11 CEST] <faLUCE> from what I read, its current quality is comparable to h264
[23:19:21 CEST] <JEEB> o_O
[23:19:32 CEST] <faLUCE> not true?
[23:20:40 CEST] <JEEB> I would be very surprised :D libvpx and friends came out (plus then daala/libaom/rav1e etc). so the theora encoder's issues such as rate control I think never got resolved.
[23:20:59 CEST] <JEEB> I remember derf talking about the rate control fixes a few years ago at VDD
[23:21:32 CEST] <HickHoward> is it just me or am i the only one who thinks that Ogg Opus is not a good audio codec?
[23:21:34 CEST] <JEEB> basically, while theora encoding could be improved, the effort went into more modern formats
[23:21:38 CEST] <faLUCE> JEEB: which kind of issue? it's not possible to change bitrate on fily?
[23:22:10 CEST] <faLUCE> or is it a more general problem?
[23:22:21 CEST] <JEEB> I wish I remembered the details
[23:23:11 CEST] <cehoyos> Why do you believe that it is a mess? And is there a specific reason why you want to "understand" all sides?
[23:23:35 CEST] <JEEB> ooh, https://git.xiph.org/?p=theora.git;a=commit;h=eac29ae2f9c748cb4a0a3fc381002f4dae3e1141
[23:23:42 CEST] <JEEB> so the mentioned issue might have gotten fixed :)
[23:23:52 CEST] <cehoyos> But the technology is not up-to-date
[23:24:10 CEST] <JEEB> yea
[23:24:14 CEST] <cehoyos> The idea that libtheora's is equal to x264 makes not much sense to me.
[23:24:18 CEST] <JEEB> theora was vp3++
[23:24:19 CEST] <faLUCE> cehoyos: because before three months ago I did not knew anything detailed about patent question
[23:24:22 CEST] <faLUCE> s
[23:24:33 CEST] <JEEB> patents don't really relate to open source as such
[23:24:42 CEST] <JEEB> it's in a way relevant to all software, and yes - it's a mess
[23:25:08 CEST] <cehoyos> I am not 100% convinced that you know many details now and I wonder why you want to know them.
[23:25:43 CEST] <faLUCE> cehoyos: because I would like to work more and more with open source video stuff
[23:26:33 CEST] <damdai> cehoyos why are you keep closing my bug report for no reason
[23:26:38 CEST] <faLUCE> [23:25] <cehoyos> I am not 100% convinced that you know many details  <-- in fact it's a mess
[23:27:23 CEST] <JEEB> dongs: no problemos. not sure if it was much more than maybe a ping regarding a possibility of getting a sample of the 22.2ch AAC to see how it's bolted together
[23:27:26 CEST] <Atlenohen> cehoyos: none of the combinations of -cflags and ldflags have worked that I tried, would you be able to provide an exact working example ?
[23:30:24 CEST] <cehoyos> I provided one (the one I use) at 19:23 but if pkg-config works for you, please use it!
[23:31:02 CEST] <cehoyos> faLUCE: We all work (more and more) with open source video stuff and we try not to think about patents - what is the reason that you want to think of them?
[23:31:17 CEST] <cehoyos> damdai: Would you like to tell me which ticket you talk about?
[23:31:51 CEST] <Atlenohen> cehoyos: whether or not PKGCONFIG works, if flags don't work it's a bug of some kind
[23:31:57 CEST] <damdai> cehoyos http://trac.ffmpeg.org/ticket/7824
[23:32:19 CEST] <Atlenohen> PKGCONFIG needs to support more than one library, not only x264
[23:32:25 CEST] <Atlenohen> If it can't do that it's useless
[23:32:32 CEST] <cehoyos> Again: They work fine, if they don't work for you, I am happy to help you find out why but if pkg-config works for you (it doesn't work for me on many operating systems), that may save us both time.
[23:33:25 CEST] <JEEB> I think it's worthwhile checking the differnce between the make V=1 output between the two ways
[23:33:40 CEST] <Atlenohen> cehoyos: Yes PKGCONFIG hasn't been working when I tried to combine it with other than x264
[23:33:40 CEST] <cehoyos> damdai: Ticket 7824 has not similarities to a valid ticket, I really don't know why you are surprised that I closed it.
[23:33:49 CEST] <faLUCE> cehoyos: because I wanted to be sure that publishing source code is OK. it would be much better to publish also binaries, but from what I see, it's a mess (and it depends also on the laws country where you are). Then, in my next projects I wonder which codec could I use without all this mess
[23:33:51 CEST] <damdai> cehoyos  bug still exist
[23:34:20 CEST] <Atlenohen> JEEB: This is only the ./configure process, it can't get past that yet (I know it works one way, but that was is not really practical)
[23:34:21 CEST] <faLUCE> so I thought about theora, based on what I read on wikipedia, but now you are telling me that is not comparable to h264
[23:34:48 CEST] <cehoyos> damdai: No, there is no bug. FFmpeg's implementation of dst uses 352800Hz, if you are unhappy about it, don't use it.
[23:35:07 CEST] <cehoyos> If you don't believe me: It is trivial to replace this value but this will break compilation;-(
[23:35:20 CEST] <JEEB> Atlenohen: ok, the configure script outputs its stuff in ffbuild/config.log
[23:35:33 CEST] <JEEB> so you should be able to compare whatever is your failing and succeeding configuration
[23:35:42 CEST] <damdai> cehoyos  but it shouldn't show as   352800Hz
[23:35:51 CEST] <damdai> how is that not a bug
[23:35:52 CEST] <cehoyos> faLUCE: What do you mean with sure? There are more than one thousand contributors in FFmpeg, what problem could you have that they do not have?
[23:36:01 CEST] <Atlenohen> JEEB: That has not been helpful most of the time I checked it, but I'll do it again, it only says "x264.h" not found and that's it
[23:36:10 CEST] <cehoyos> damdai: Again, this is how it is implemented, this is not a bug as long as the output sounds correct.
[23:36:30 CEST] <damdai> cehoyos well i am just doing ffprobe
[23:36:33 CEST] <JEEB> Atlenohen: it should have the check (code) and the actual commands utilized for checking in there
[23:36:59 CEST] <cehoyos> Atlenohen: In case your issue is that bcrypt has nothing to do with pkg-config than you can neither fix this in pkg-config nor with --extra-flags: Both are not related to bcrypt.
[23:37:17 CEST] <faLUCE> cehoyos: "There are more than one thousand contributors in FFmpeg, what problem could you have that they do not have?" <--- this is true... but what could happen if tomorrow MPEG LA changes their rules?
[23:37:18 CEST] <damdai> cehoyos  so if  a  22khz mp3 file show as  44khz mp3 file on ffprobe,  you are saying that is not a bug then?
[23:37:37 CEST] <cehoyos> damdai: As said: If you are not happy about our dst implementation, just use another one;-)
[23:37:42 CEST] <Atlenohen> LDFLAGS=' -L/c/msys64/usr/local/dependency/x264/lib'
[23:37:46 CEST] <damdai> cehoyos answer my question
[23:37:47 CEST] <damdai> cehoyos  so if  a  22khz mp3 file show as  44khz mp3 file on ffprobe,  you are saying that is not a bug then?
[23:37:57 CEST] <JEEB> damdai: if the decoded output is correct, then it is "only" an issue with the output of the information provided at the probe
[23:38:09 CEST] <JEEB> if the actual *decode* is incorrect, that's a separate case
[23:38:20 CEST] <cehoyos> That would likely be a bug because our mp3 implementation requires that the output has the frequency that you want to hear.
[23:38:40 CEST] <cehoyos> I suspect it would be possible to change the mp3 decoder so that it shows another frequency and still works.
[23:38:50 CEST] <cehoyos> (Note that this is exactly what happens for some aac files)
[23:39:19 CEST] <Atlenohen> JEEB: does that mean it's trying to pass linux-paths to a windows utility? cl -nologo -I/c/msys64/usr/local/dependency/x264/include -c -Fo./ffconf.xwinK8u6/test.o ./ffconf.xwinK8u6/test.c
[23:39:20 CEST] <damdai> i expect  22khz mp3 file show  to show as  22khz mp3 file in ffprobe
[23:39:26 CEST] <cehoyos> faLUCE: Then - sad as it is for us and maybe for you - you should not contribute to FFmpeg.
[23:40:00 CEST] <faLUCE> cehoyos: in addition, I was about fsf complaining MPEG-LA... so my thought was.. should I continue to use MPEG stuff or do I have to switch to theora and opus. I tried opus in the last two months and I was very satisfied
[23:40:14 CEST] <cehoyos> damdai: That is correct for the current mp3 decoder implementation, it could (theoretically) change in the future, as said for some aac files this is exactly what happens.
[23:40:26 CEST] <JEEB> Atlenohen: yes. although do remember that msys(2) has funky utilities to convert stuff in flight
[23:40:28 CEST] <cehoyos> you were about or it was about?
[23:41:16 CEST] <cehoyos> Now you are saying "use": Do you want to use FFmpeg or do you want to contribute to FFmpeg? I believe these are two differect things (I very, very rarely use FFmpeg)
[23:41:36 CEST] <faLUCE> cehoyos: I would like to contribute too.
[23:41:55 CEST] <cehoyos> Then please do, man power (time) is the only limiting factor;-)
[23:42:18 CEST] <faLUCE> cehoyos: I did in the past! And in this channel I try to help newbies
[00:00:00 CEST] --- Sun Apr 14 2019