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

[burek]

[00:13:13 CEST] <cone-176> ffmpeg 03Marton Balint 07master:b72a7b96f84e: avformat: factorize iso 8601 timestamp writer to a dictionary avutil function
[00:18:11 CEST] <cone-176> ffmpeg 03James Almer 07master:bba6a03b2816: examples/demuxing_decoding: convert to codecpar
[09:46:37 CEST] <cone-252> ffmpeg 03Carl Eugen Hoyos 07master:f866f22c3f58: lavf/pcmdec: Try to fix msvc compilation after 4c42d306.
[10:45:15 CEST] <durandal_17> michaelni:  ./ffmpeg.exe -f lavfi -i aevalsrc="0.2*sin(440*PI*t):duration=5" -af aresample=44100:dither_method=shibata -c:a pcm_f64le dbl.wav
[10:45:23 CEST] <durandal_17> this gives silence
[11:33:18 CEST] <durandal_17> so each project have same time slot for talking about its future, how neat
[12:16:08 CEST] <cone-252> ffmpeg 03Michael Niedermayer 07master:946acacdcdff: swresample: move dither init up
[12:16:09 CEST] <cone-252> ffmpeg 03Michael Niedermayer 07master:30b2611ed310: swresample: Skip over dither steps if dithering scale is 0
[12:16:36 CEST] <michaelni> durandal_17, fixed the silence
[12:16:46 CEST] <durandal_17> thanks
[14:20:53 CEST] <ubitux> anyone working on ffmpeg/codecpar?
[14:21:21 CEST] <ubitux> i'd like to work on the merges but it's going to be tricky for the incoming merges without that part
[14:25:44 CEST] <ubitux> we're down ~250 commits now
[14:26:08 CEST] <ubitux> we passed the h264 waves, but the avconv are going to be tricky
[14:26:58 CEST] <JEEB> i think chloe was trying to poke at that but iirc there were parts where manual avctx was needed instead of codecpar etc?
[14:27:57 CEST] <ubitux> i can look at this for a few hours (about 3), but if work has already been done i don't want to walk on someone's feet
[14:28:10 CEST] <ubitux> (it very much likely won't be enough but well)
[15:22:46 CEST] <durandal_1707> ubitux: the codecpar thing is blocking because of hacks
[15:23:24 CEST] <ubitux> what hacks? how can i help?
[15:23:42 CEST] <durandal_1707> can I push swr change?
[16:31:16 CEST] <cone-393> ffmpeg 03Paul B Mahol 07master:9876d8fc6d2b: swresample: add int64 sample format
[16:31:16 CEST] <cone-393> ffmpeg 03Paul B Mahol 07master:fc600eff630f: avcodec: add 64-bit signed pcm codec
[16:31:16 CEST] <cone-393> ffmpeg 03Paul B Mahol 07master:81f7d07608e1: avfilter/af_astats: add support for s64(p) sample format
[16:31:16 CEST] <cone-393> ffmpeg 03Paul B Mahol 07master:703ae350c2de: avfilter/af_astats: fix flt(p) support
[18:41:37 CEST] <Chloe> ubitux: yeah, I gave it a shot, but I kept encountering issues because of things requiring avctx, I tried to switch them over, and more things broke. I'm not entirely sure where codecpar needed to replace avctx.
[19:55:58 CEST] <Dresk|Dev> So I realize this isn't the responsibility of you guys, but I figured you might be able to help, we have been building ffmpeg natively in MSVC2015 but without any ASM optimizations, which is torturous, so I want to get the latest 3.1.2, but the Zeranoe builds are oddly named and I can't find his 3.1.2 : https://ffmpeg.zeranoe.com/builds/win32/shared/
[19:57:23 CEST] <BtbN> He just builds latest git master every day, which is the recommended way of using ffmpeg.
[19:57:42 CEST] <BtbN> Releases basically only exist to make distributors happy.
[19:58:31 CEST] <Dresk|Dev> BtbN: Well we're building for multiple OSes and platforms, it helps us to have a definitive "release", especially for the investors
[20:00:01 CEST] <Dresk|Dev> I'm just trying to understand if his random, hashes, it seems, have any correlation to the Git releases
[20:01:14 CEST] <BtbN> It's exactly the git commit.
[20:01:56 CEST] <Dresk|Dev> So, if we have this https://ffmpeg.zeranoe.com/builds/win32/shared/ , how can I find 3.1.2 from this?  https://git.ffmpeg.org/gitweb/ffmpeg.git/shortlog/n3.1.2
[20:02:31 CEST] <BtbN> There is no 3.1.2. It builds git master.
[20:03:02 CEST] <Dresk|Dev> Grrr!
[20:03:19 CEST] <BtbN> 3.1 was branched off, so it has no relation to master anymore, just getting security and bugfixes.
[20:03:24 CEST] <Dresk|Dev> But look, zeranoe does make "distributor" builds : https://ffmpeg.zeranoe.com/builds/win32/shared/ffmpeg-3.0.1-win32-shared.7z
[20:04:08 CEST] <BtbN> Probably only when someone requests one. Or he just stopped. No 3.1 there.
[20:04:16 CEST] <Dresk|Dev> Yeah, I noticed that
[20:04:44 CEST] <BtbN> What's the issue with just using latest git master?
[20:04:52 CEST] <Dresk|Dev> But, and I would be deeply appreciative, if you could help me find, if it's possible, which one of these builds on Zeranoe's site IS the 3.1.2 Git from ffmpeg
[20:05:03 CEST] <BtbN> None of them is.
[20:05:05 CEST] <BtbN> He builds git master
[20:05:06 CEST] <Dresk|Dev> It's more of an investor thing, just, politics
[20:05:08 CEST] <BtbN> 3.1.2 is not on master.
[20:05:25 CEST] <Dresk|Dev> Oh, ah
[20:05:53 CEST] <Dresk|Dev> Well I shall then embrace the latest, which means I have no idea what to call the folder, heh
[20:06:36 CEST] <BtbN> The git commit is right in the version name.
[20:07:12 CEST] <Dresk|Dev> I am dumb sometimes
[20:10:24 CEST] <Dresk|Dev> BtbN: Thanks, gonna see if I can actually build this with YASM via MSVC, that would be ultimate for us since we don't want to rely on MSVCRT.dll from Cygwin due to it being OS-dependent and just, bad
[20:10:50 CEST] <BtbN> You'll depend on some runtime anyway.
[20:10:58 CEST] <BtbN> gcc also has its runtime library.
[20:11:22 CEST] <BtbN> The easiest way to build ffmpeg for windows is by using Linux with a cross compiler.
[20:11:23 CEST] <Dresk|Dev> Well if we built it with MSVC2015 we can depend on vc-runtime-140.dll
[20:11:38 CEST] <Dresk|Dev> BtbN: But that causes it to use MSVCRT.dll, which is NOT a good DLL to rely upon
[20:12:01 CEST] <BtbN> Why would it do that?
[20:12:22 CEST] <Dresk|Dev> https://sourceforge.net/p/mingw-w64/wiki2/The%20case%20against%20msvcrt.dll/
[20:12:58 CEST] <BtbN> That only lists reasons why it would not do that.
[20:13:36 CEST] <Dresk|Dev> That DLL was what Microsoft used to use with new versions of Windows, updating the runtime and putting it in the same file, so you never know what version you're really gonna have
[20:14:04 CEST] <Dresk|Dev> Now with WinSxS we can have the individual runtime DLLs and make sure we're executing on the correct one
[20:14:17 CEST] <Dresk|Dev> Myth #3 is particularly damning
[20:14:25 CEST] <BtbN> From how I understand this library, it comes with windows by default, and export a minimum standard set of features. So using it should be perfectly safe.
[20:14:59 CEST] <BtbN> I don't think MinGW uses any higher level features from it.
[20:15:04 CEST] <BtbN> It has its own runtime for that after all.
[20:15:39 CEST] <Dresk|Dev> Newer C99 features and the like are not guaranteed to work in MSVCRT.dll
[20:16:09 CEST] <BtbN> That's what gcc has its own runtime for.
[20:17:04 CEST] <Dresk|Dev> In general you can't mix VC runtimes, though exceptions do exist, such as MSVCRT mixing with explicit runtimes, but it's not clean, professional code
[20:17:23 CEST] <cone-393> ffmpeg 03Paul B Mahol 07master:b3c6e89d4871: avfilter/avf_showspectrum: do not use uninitialized memory
[20:17:24 CEST] <cone-393> ffmpeg 03Paul B Mahol 07master:e2a39b103e59: avfilter/avf_showvolume: use current peak value for picking colors
[20:17:34 CEST] <BtbN> Tons of applications are using mingw64, they all work fine. And use their own runtime anyway...
[20:18:29 CEST] <Dresk|Dev> But if you build an app in MSVC and include libs built wiht mingw64, you're really playing with fire, and it will only get worse
[20:18:53 CEST] <BtbN> No you're not. Using multiple shared versions of MSVC runtimes is perfectly supported.
[20:19:05 CEST] <BtbN> You just can't link more than one statically, for obvious reasons.
[20:19:52 CEST] <Dresk|Dev> Before you yell at me some more, due to only needing basically 2 containers and 5 codecs, we're trying to build ffmpeg statically since the binary size increase isn't that bad
[20:20:15 CEST] <BtbN> Keep in mind that you might run into licensing issues with that.
[20:20:23 CEST] <BtbN> Ending up with a binary that cannot be redistributed.
[20:20:27 CEST] <Dresk|Dev> We're aware
[20:22:40 CEST] <BtbN> I'm quite sure an ffmpeg.exe with a microsoft VC runtime statically linked into would fall into that category.
[20:28:30 CEST] <Dresk|Dev> So, think I can get YASM going in MSVC2015 for a proper build?
[23:14:20 CEST] <Dresk|Dev> Did ffmpeg 3.x introduce significant performance advantages over 2.x / 2.8.x+?  Almost seems like my CPU is a little more taxed
[23:18:31 CEST] <Compn> Dresk|Dev : what cpu ?
[23:19:16 CEST] <Compn> Dresk|Dev : bonus question, if you can make a testcase and test ff 3.x v ff 2.x  we can find the speed bug if it exists
[23:19:43 CEST] <Compn> e.g. run the same ffmpeg command , same file, on same computer with both versions and see if there is speed diff
[23:19:53 CEST] <Dresk|Dev> Compn: RIght now testing on 4960x under 32bit binary Windows OCed to 4.8Ghz
[23:20:10 CEST] <durandal_1707> what command?
[23:20:36 CEST] <Dresk|Dev> We've integrated ffmpeg into our OGL program and are rendering to textures
[23:20:56 CEST] <Dresk|Dev> I'd just profile the various ffmpeg calls I guess and see if they take more
[23:22:29 CEST] <Compn> i dont think we do time based checks 
[23:22:36 CEST] <Compn> i requested this feature in FATE testing a long time ago
[23:22:44 CEST] <Compn> but .... no one seems to care
[23:25:41 CEST] <durandal_1707> what decoder/encoder so on, provide useful info 
[23:40:27 CEST] <cone-599> ffmpeg 03Michael Niedermayer 07master:cc13bc8c4f0f: avcodec/h2645: Fix NAL unit padding
[23:40:27 CEST] <cone-599> ffmpeg 03Michael Niedermayer 07master:382a68b0088b: vcodec/h2645_parse: Clear buffer padding
[23:41:25 CEST] <Dresk|Dev> Actually, to be most honest I just moved from 2.8.2 to 3.1.2 and I'm trying to fix these 2 deprecated things with not much documentation
[23:52:04 CEST] <durandal_1707> ignore them
[23:52:14 CEST] <durandal_1707> for now
[23:57:04 CEST] <Dresk|Dev> It was just passing in a context for avcodec_alloc_context3(codec) such that I could pass in the context for avcodec_open2 (instead of codec)
[00:00:00 CEST] --- Fri Aug 19 2016