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

[burek]

[00:00:16 CEST] <BtbN> I'm not a fan of meson
[00:00:23 CEST] <atomnuker> Mathieu_Du: if you want any chance of getting it merged in please keep quiet about any sort of a transition period
[00:00:45 CEST] <nevcairiel> because hiding your real intentions is such a good way to do things
[00:01:07 CEST] <atomnuker> not hiding anything, just letting things get to where you'd like them to be is called foresight
[00:01:09 CEST] <BtbN> There obviously will be one if/when anything like that will get merged
[00:01:27 CEST] <atomnuker> not necessarily, one can be added later
[00:01:43 CEST] <Mathieu_Du> atomnuker, I'm only giving my opinion on keeping both canonical build systems for ever (with as many rhetorical precautions as I could find :)
[00:02:24 CEST] <atomnuker> mpv still has kept both its build systems for 5 or so years now I think
[00:03:02 CEST] <Mathieu_Du> Anyway, I'm an outsider here, decisions should be made by the FFmpeg community
[00:03:08 CEST] Action: Mathieu_Du goes back into hiding
[00:09:41 CEST] <j-b> the beautiful configure that does not output anything for 2 minutes and then explodes? :)
[00:10:28 CEST] <nevcairiel> 2 minutes? you wish
[00:10:31 CEST] <nevcairiel> more like 10
[00:10:54 CEST] <Mathieu_Du> 1 m 30 on my system fwiw, but I didn't try it on Windows 
[00:11:31 CEST] <Mathieu_Du> meson's configuration takes ~ 15 seconds (and it actually says things while doing them :)
[00:12:07 CEST] <BtbN> I wonder if someone were to come up with a feature complete Python script for configure... what people would say about it
[00:12:38 CEST] <Mathieu_Du> It should be noted that build times are comparable, I've usually observed radical speedups when ported projects used some form of recursive make, but that's not the case for ffmpeg
[00:13:14 CEST] <nevcairiel> yeah during actual compilation i get close to 100% cpu use all the time
[00:13:24 CEST] <nevcairiel> its just configure thats bum slow, especially on windows
[00:13:39 CEST] <BtbN> in before someone comes up with a way to parallelize configure
[00:13:59 CEST] <Mathieu_Du> good luck :)
[00:18:13 CEST] <atomnuker> Mathieu_Du: how is yours so fast?
[00:18:38 CEST] <atomnuker> mine checks all math functions which takes quite some time (exp, sin, cos, log, pow, etc)
[00:19:15 CEST] <Mathieu_Du> Well you make me doubt now, let me time again
[00:19:45 CEST] <Mathieu_Du> I have a decent machine, but not crazy fast either
[00:20:19 CEST] <Mathieu_Du> real	1m17.453s
[00:20:22 CEST] <Mathieu_Du> I lied :)
[00:21:14 CEST] <Mathieu_Du> time meson build -> real	0m16.002s
[00:21:37 CEST] <Mathieu_Du> Intel(R) Core(TM) i7-6800K CPU @ 3.40GHz is my CPU
[00:24:07 CEST] <BtbN> ./configure --disable-doc  78,99s user 134,87s system 84% cpu 4:12,94 total
[00:27:11 CEST] <__tim> meson's checks are currently not optimised for speed at all yet fwiw, there are some experiments/branches/plans to parallelise checks
[00:28:11 CEST] <Mathieu_Du> that would be https://github.com/mesonbuild/meson/issues/3635 if I'm not mistaken :)
[00:29:30 CEST] <atomnuker> Mathieu_Du: do you require git master of meson? ['alsa', ['alsa/asoundlib.h'], ['snd_pcm_htimestamp'], {}],
[00:29:34 CEST] <atomnuker> errors out
[00:29:38 CEST] <January> atomnuker: yes
[00:29:40 CEST] <Mathieu_Du> Yes
[00:29:43 CEST] <atomnuker> why?
[00:29:48 CEST] <January> I stated that in the email iirc
[00:29:49 CEST] <Mathieu_Du> precisely because of that
[00:30:04 CEST] <Mathieu_Du> I've added dictionaries in meson recently
[00:30:22 CEST] <Mathieu_Du> https://github.com/mesonbuild/meson/pull/3490
[00:30:41 CEST] <Mathieu_Du> for the FFmpeg use case, but it's generally useful
[00:32:23 CEST] <January> atomnuker: also I thought mpv wanted to move to meson
[00:33:00 CEST] <atomnuker> if someone does the work
[00:34:11 CEST] <January> atomnuker: of course, same as always, no different here either
[00:37:38 CEST] <durandal_1707> January: how it outputs selected decoders/demuxer/parsers ? in one go?
[00:51:29 CEST] <Gramner> what kind of machine do you need for configure to take 10 minutes? it runs in under 30 seconds for me on a clean copy of git master which isn't that bad considering it's generally not something you do a hundred times per day
[00:52:13 CEST] <nevcairiel> I have a 7900X at 4.5GHz and a PCIe SSD .. I just have Windows as well =p
[00:52:32 CEST] <cehoyos> That surprises me: It takes 90 minutes on a hardware where compilation takes <5 minutes...
[00:52:36 CEST] <nevcairiel> the process creationg cost of the billions of forks makes it super slow
[00:54:04 CEST] <iive> Gramner, remember this: https://randomascii.wordpress.com/2017/07/09/24-core-cpu-and-i-cant-move-my-mouse/ ?
[00:54:32 CEST] <Gramner> e.g. "lol, windows"?
[00:54:41 CEST] <nevcairiel> that was just a bug and was fixed
[00:55:02 CEST] <Gramner> at least windows 10 ships with built-in ubuntu
[00:55:08 CEST] <Gramner> what about using that?
[00:55:24 CEST] <iive> it's still using windows kernel, isn't it?
[00:55:27 CEST] <nevcairiel> making native windows builds through that is annoyingly hard to setup
[00:58:39 CEST] <nevcairiel> but it is actually much faster in that
[00:58:57 CEST] <nevcairiel> their implementation of fork may actually work properly, unlike the one msys uses =p
[00:59:47 CEST] <jamrial> Windows 10 starting with the fall's creator update takes a shitload of time to run configure apparently because of some process spawn issue
[01:00:06 CEST] <jamrial> haven't tested the latest version that came out a month or so ago
[01:00:10 CEST] <jamrial> so no idea if it was fixe
[01:01:00 CEST] <j-b> The last 2 updates of Win10 are really shitty.
[01:01:06 CEST] <jamrial> since configure apparently calls bash every time it tries to do some module dependency check, well...
[01:01:11 CEST] <nevcairiel> its hard to compare since shit is slow anyway since the depedency changes
[01:01:52 CEST] <j-b> bash that calls pkg-config :)
[01:02:53 CEST] <nevcairiel> my fate VM runs on windows 8.1 still since its pretty old, and it also takes forever to configure
[01:03:19 CEST] <jamrial> j-b: pkg-config is called at most 20 times if you enable every single external library
[01:03:25 CEST] <jamrial> the problem is in i think flatten_extralibs()
[01:05:32 CEST] <jamrial> nevcairiel: curious, win10 pre falls creator would take a minute or so for me at worst
[01:05:44 CEST] <nevcairiel> after the dep changes?
[01:05:50 CEST] <jamrial> yeah
[01:06:08 CEST] <jamrial> at least that's how i remember it
[01:06:13 CEST] <nevcairiel> it takes about a minute in WSL
[01:23:41 CEST] <cone-892> ffmpeg 03Carl Eugen Hoyos 07master:78298bce70ed: lavc/dpx: Reset n_datum for every new line when decoding 12bit.
[01:23:41 CEST] <cone-892> ffmpeg 03Carl Eugen Hoyos 07release/4.0:a6d85a97d0be: configure: The eac3_core bitstream filter needs the ac3 parser.
[03:19:47 CEST] <cone-892> ffmpeg 03Pavel Koshevoy 07master:29cddc99cd83: lavfi/atempo: raise max tempo limit (v2)
[03:59:20 CEST] <BBB> Im trying to imagine if a video encoder was written like our configure script and ran on windows
[03:59:31 CEST] <BBB> how long would it take to encode 1 1080p video frame?
[04:01:27 CEST] <jamrial> for that comparison to work, the video encoder in question should launch a new process for every pixel encoded :p
[04:02:09 CEST] <jamrial> this is not a configure issue but a bash/environment one
[04:02:18 CEST] <jamrial> bash because we may be asking a bit too much from it
[04:02:31 CEST] <jamrial> environment because windows sucks at it
[04:06:46 CEST] <jamrial> how feasible is to just switch from bash to some other scripting language, like python (pure, not wrapped with meson), to do the exact same thing we're doing with bash?
[04:06:56 CEST] <jamrial> i think boost uses python for their configure script
[04:33:26 CEST] <Compn> i like my idea the best
[04:33:32 CEST] <Compn> we use tcc to compile an .exe to compile ffmpeg
[05:05:27 CEST] <January> I mean switching to a custom build system in an actual language would be better than we have now but... idk
[08:13:34 CEST] <j-b> Compn: <3
[08:13:50 CEST] <j-b> January: no. Custom is bad.
[08:13:55 CEST] <j-b> it's always bad.
[08:15:44 CEST] <j-b> We see that with VLC, that we compile on a very wide number of architecture and platforms, including shitty one.
[08:16:04 CEST] <j-b> And every single custom configure is wrong in a way or another.
[08:16:11 CEST] <j-b> like, no exceptions.
[08:16:33 CEST] <j-b> Only ffmpeg one is not shitty, but it's not perfect either
[08:23:37 CEST] <January> j-b: its also not practical in this case
[11:21:14 CEST] <BtbN> Building ffmpeg with libmfx on Windows seems to be a pain, wow
[11:22:06 CEST] <nevcairiel> i never thought it was that bad
[11:22:15 CEST] <nevcairiel> just use the copy from luca with the pkg-config file
[11:22:16 CEST] <BtbN> It is if you're not using msvc
[11:22:27 CEST] <BtbN> Building the one from luca needs the Intel SDK
[11:22:39 CEST] <nevcairiel> building the one from the intel sdk also needs the intel sdk
[11:22:40 CEST] <nevcairiel> :D
[11:23:00 CEST] <BtbN> And then throw Cygwin in the mix, and you have a massive mess
[11:23:14 CEST] <nevcairiel> i stay away from cygwin because mess is its middle name
[11:23:31 CEST] <BtbN> It's the only practically useable environment for Windows
[11:23:39 CEST] <nevcairiel> i do fine with msys2
[11:23:50 CEST] <BtbN> For just building, maybe. But not as a work environment.
[11:24:00 CEST] <BtbN> way too many packages are missing
[11:24:07 CEST] <nevcairiel> i dont need a work environment :)
[11:24:16 CEST] <BtbN> I'm not gonna learn PowerShell or CMD
[11:24:36 CEST] <nevcairiel> but i would use WSL if i needed something to regularly run linux-y things
[11:24:39 CEST] <RiCON> nevcairiel: can you check with mingw/msys2 that --disable-autodetect --enable-iconv isn't working?
[11:25:11 CEST] <nevcairiel> maybe later, need to go buy lunch and running configure takes forever
[11:25:20 CEST] <RiCON> for some reason it's enabling libc_iconv, which only checks iconv with -liconv
[11:25:31 CEST] <RiCON> without -liconv*
[11:26:56 CEST] <nevcairiel> i dont use the msys2-provided toolchain though, so i probably dont even have a compatible iconv
[11:35:15 CEST] <BtbN> seems like libmfx in Cygwin is impossible. It just refuses to configure.
[11:35:32 CEST] <BtbN> That's as annoying as it gets. Non-Cygwin ffmpeg is unuseable in a cygwin shell
[11:49:34 CEST] <BtbN> well, thanks to C++ it is even more impossible.
[12:29:03 CEST] <nevcairiel> thats why i really dont like cygwin, it doesnt really do well with interoperability
[12:29:08 CEST] <nevcairiel> its eitehr go full cygwin or go home
[12:44:59 CEST] <jdarnley> You're not wrong.
[12:45:28 CEST] <jdarnley> Though I think it is becuase ffmpeg tries to be interactive.
[15:13:10 CEST] <Compn> j-b : which do you like better autotools config or ffmpeg config ?
[15:13:18 CEST] <Compn> configure *
[15:43:49 CEST] <cone-257> ffmpeg 03Pavel Koshevoy 07master:f7d117b48464: avcodec/nvenc: enable nvenc encoder instance reuse
[15:43:50 CEST] <cone-257> ffmpeg 03Timo Rothenpieler 07master:6129b13dadeb: configure: simplify ffnvcodec version logic
[15:44:33 CEST] <nevcairiel> i stil think that nvenc change basically violates avcodec api
[16:22:54 CEST] <BtbN> Weird, configure --disable-doc needs 1~2 Minutes. If I --enable-libmfx, it suddenly needs 18 minutes.
[16:27:49 CEST] <BtbN> jkqxz, what's up with those load_plugins for QSV? Do I only get full hwaccel if I -load_plugin hevc_hw/h264_hw? And why is it not default on Windows, but on Linux?
[16:34:04 CEST] <BtbN> In fact, without manually doing -load_plugin hevc_hw, it doesn't even work, because the sw plugin doesn't exist
[16:47:44 CEST] <Zeranoe> Enjoy: https://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7&p=13808
[16:53:31 CEST] <Mathieu_Du> ./configure --enable-js of course
[17:01:08 CEST] <Zeranoe> "Why is my browser crushing my computer?"
[18:42:30 CEST] <tmm1> Zeranoe: https://github.com/Kagami/ffmpeg.js
[18:44:28 CEST] <nevcairiel> there are tools to just compile C to JS, so thats no surprise to exist
[18:44:36 CEST] <Zeranoe> Well I'll be damned
[18:45:32 CEST] <January> Zeranoe: also WebAssembly
[18:46:46 CEST] <January> Zeranoe: there are demos of qemu running in the browser
[18:48:36 CEST] <j-b> linux running inside the webbrowser.
[18:49:21 CEST] <Zeranoe> Didn't FFmpeg's founder do something with that?
[18:49:43 CEST] <January> Yes Bellard wrote it
[18:50:21 CEST] <January> Also Win95 in the browser, its pretty impressive really
[18:51:03 CEST] <j-b> Compn: autotools, probably.
[18:55:02 CEST] <Zeranoe> What is the practical use of running FFmpeg in a browser?
[18:55:12 CEST] <j-b> so far, none
[18:55:24 CEST] <j-b> like win95 in a browser
[18:55:40 CEST] <j-b> it is just cool
[18:57:10 CEST] <jamrial> client side encoding of uploaded videos to whatever site that can't afford the server costs for such workload?
[18:57:33 CEST] <jamrial> the fact the available builds are mp4 and webm encoding/muxing hint at that
[18:57:38 CEST] <Zeranoe> except you still need to download the FFmpeg js file which is like 20 megs at the least
[18:58:04 CEST] <nevcairiel> well the browser just does that in the background =p
[18:59:38 CEST] <Zeranoe> right, but requiring people to download that is a little intrusive imo
[19:00:06 CEST] <nevcairiel> its not like browsers dont download .js on any other site
[19:00:09 CEST] <nevcairiel> its just a bit bigger
[19:00:18 CEST] <Zeranoe> "a bit"
[19:00:29 CEST] <nevcairiel> its not like 20mb is that much in the age of broadband
[19:01:48 CEST] <Zeranoe> I feel like we've come full circle. Start off loeading everything to a central server, and now the cool thing to do is offload everything to the client
[19:04:13 CEST] <jamrial> nowadays opening a random modern website full of bells and whistles is like 5mb of scripts, images and assorted crap
[19:05:53 CEST] <jamrial> tried reddit front page (the new design that looks like a social network wannabe) and it was 3mb
[19:05:56 CEST] <jamrial> old design 1.4mb
[19:07:04 CEST] <kierank> adblock+ghostery
[19:07:24 CEST] <Zeranoe> I hate the new design
[19:07:30 CEST] <jamrial> this was with ublock :p
[19:08:21 CEST] <jamrial> disabled umatrix to test and got the above
[19:17:01 CEST] <j-b> I'm not a huge fan of the new design either
[19:18:48 CEST] <nevcairiel> I was never a huge fan of Reddit, I just don't "get it"
[19:20:27 CEST] <TheAMM> User-driven content aggregator
[19:20:32 CEST] <TheAMM> works for me
[21:47:36 CEST] <BtbN> Shouldn't DXVA2 -> QSV full hw transcode be possible?
[21:47:42 CEST] <BtbN> It always seems to download the framesw
[21:51:02 CEST] <cone-243> ffmpeg 03erankor 07master:3dc5aa36fbbd: qt-faststart - print errors to stderr
[22:27:46 CEST] <cone-243> ffmpeg 03Michael Niedermayer 07master:2e205bfc14d8: avcodec/decode: Consider STRIDE_ALIGN in get_buffer_internal() when checking width
[22:27:47 CEST] <cone-243> ffmpeg 03Michael Niedermayer 07master:aa41d322be71: avutil/common: Fix undefined behavior in av_clip_uintp2_c()
[22:27:48 CEST] <cone-243> ffmpeg 03Michael Niedermayer 07master:575d8ca0260f: avcodec/dirac_dwt_template: Fix undefined behavior in interleave()
[22:27:49 CEST] <cone-243> ffmpeg 03Michael Niedermayer 07master:8bd514d93437: avcodec/aacdec_fixed: Fix undefined integer overflow in apply_independent_coupling_fixed()
[22:43:51 CEST] <ramiro> michaelni: regarding adding a fate test for the '-intra_penalty max' patch. should we find a way to detect if there was any intra mb in the output (I don't see how to do this cleanly) or is it enough to just add a test that uses this flag and hope for the best?
[22:45:18 CEST] <michaelni> there was some -debug flag that could show mb types IIRC. Not sure if that would be easy to use
[22:46:01 CEST] <michaelni> if its not easy then simply adding some test and hoping for the best would be the obvious option
[00:00:00 CEST] --- Sat Jun 16 2018