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

[burek]

[00:22:01 CEST] <cone-626> ffmpeg 03Alex Smith 07master:20b079963bf8: configure: Combine dynamicbase and nxcompat checks
[00:56:21 CEST] <cone-626> ffmpeg 03Ganesh Ajjanagadde 07master:265b106b9296: ffplay: introduce key repeats
[01:25:56 CEST] <cone-626> ffmpeg 03Christophe Gisquet 07master:08a7510fcad5: dnxhddec: implement slice multithreading
[01:41:24 CEST] <cone-626> ffmpeg 03Ganesh Ajjanagadde 07master:23acb982a3c7: ffplay: dynamically allocate filename buffer
[05:05:40 CEST] <Timothy_Gu> kurosu: what's the advantage of slice mt over frame mt?
[08:58:49 CEST] <kurosu> Timothy_Gu, delay in decoding and speed of preview, but it's minor
[09:07:02 CEST] <kurosu> the speed benefits of both are codec-dependent: for instance, with temporal prediction, frame threading may not scale
[09:07:50 CEST] <kurosu> slice threading may not scale if the jobs are unbalanced, and it has a different kind of overhead
[10:19:59 CEST] <Timothy_Gu> kurosu: I was specifically referring to dnxhd
[10:20:23 CEST] <Timothy_Gu> but that makes sense, thanks
[11:04:52 CEST] <durandal_1707> assumefps or setfps?
[12:20:17 CEST] <cone-433> ffmpeg 03Christophe Gisquet 07master:8e8ed57ea7d3: dnxhddec: remove unused qscale parameter
[12:20:17 CEST] <cone-433> ffmpeg 03Christophe Gisquet 07master:5c6e3a019c5c: dnxhddec: simplify block parsing calls
[12:58:32 CEST] <durandal_1707> no homework for me :(
[13:00:57 CEST] <wm4> or for me
[13:02:52 CEST] <Daemon404> both of you should probably do the homework
[13:03:05 CEST] <Daemon404> especially in case j-b invaldes germany
[13:06:49 CEST] <nevcairiel> j-b doesnt want to give it out before talking to us in person, preferably =p
[13:09:34 CEST] <wm4> I wonder why
[13:09:36 CEST] <Daemon404> nevcairiel, so there is a scheduled invasion time?
[13:11:26 CEST] <durandal_1707> zuffing ffv1 for 22:30 hours and still nothing
[13:11:57 CEST] <nevcairiel> Daemon404: apparently, although i didnt get a date yet
[13:12:36 CEST] <Daemon404> :D
[13:15:59 CEST] <kierank> durandal_1707: are you using a script
[13:17:13 CEST] <durandal_1707> kierank: nope
[13:17:30 CEST] <ubitux> durandal_1707: zzuf? why not afl?
[13:18:30 CEST] <durandal_1707> afl, it already found 2 bugs but that was long ago
[13:19:11 CEST] <kierank> I am running afl on opusdec
[13:19:21 CEST] <kierank> supposedly lots of hangs but I can never reproduce them
[13:19:22 CEST] <Compn> durandal_1707 : did you do flv1 codec already? :)
[13:19:55 CEST] <durandal_1707> Compn: just one hour, nothing
[13:20:20 CEST] <Compn> thansk :)
[13:20:40 CEST] <durandal_1707> kierank: i run hangs via valgrind
[13:22:26 CEST] <Compn> kierank : disable threading ? if there is on opus dec...
[13:22:28 CEST] <Compn> nevermind
[13:30:00 CEST] <kierank> durandal_1707: I have hundreds of supposed opus hangs but nothing happens
[13:39:18 CEST] <durandal_1707> well, i was just lucky then
[15:03:47 CEST] <cone-433> ffmpeg 03Michael Niedermayer 07master:485057f71572: avfilter/vf_mcdeint: add missing "This file is part of FFmpeg"
[15:03:48 CEST] <cone-433> ffmpeg 03Michael Niedermayer 07master:549d10924894: avfilter/vf_yadif: add missing "This file is part of FFmpeg"
[15:03:49 CEST] <cone-433> ffmpeg 03Michael Niedermayer 07master:c4d50314c087: avcodec/d3d11va: Fix project name
[15:03:50 CEST] <cone-433> ffmpeg 03Michael Niedermayer 07master:7d636d02b113: swresample/dither_template: Add missing license header
[16:55:21 CEST] <TheRyuu> so what's the story with my other two patches (adding HEASLR flag and the image base one)
[16:56:00 CEST] <nevcairiel> i assume the heaslr one only sets a PE flag and is ignored whenever not supported?
[16:56:38 CEST] <TheRyuu> it also sets the image base > 4GB
[16:57:03 CEST] <TheRyuu> https://github.com/TheRyuu/FFmpeg/commit/f2b805d02ee12af5593130ef06f0924422e8622e
[16:57:34 CEST] <nevcairiel> do the PE flags and image base match a msvc build after?
[16:57:43 CEST] <TheRyuu> yes
[17:00:12 CEST] <nevcairiel> did you complain to binutils about the entry point massacre?
[17:01:25 CEST] <TheRyuu> I have not
[17:02:09 CEST] <TheRyuu> if it was up to me I would completely revamp the linker defaults for mingw-w64
[17:02:30 CEST] <TheRyuu> the defaults are shit
[17:02:36 CEST] <Gramner> indeed, the defaults are quite bad
[17:02:42 CEST] <TheRyuu> (even on linux IIRC)
[17:03:34 CEST] <Gramner> they should use whatever msvc uses by default when linking windows binaries
[17:04:05 CEST] <TheRyuu> that's what I made ffmpeg do with these patches
[17:04:46 CEST] <Gramner> you should submit a patch to upstream and save everyone else the trouble
[17:05:41 CEST] <nevcairiel> windows usualy just enables new features by default, binutils for some reason doesnt enable anything by default =p
[17:06:55 CEST] <TheRyuu> I find the reloc shit particularly amusing since it basically means any open source project which gets compiled with it has a fixed base
[17:07:06 CEST] <TheRyuu> e.g. openvpn
[17:07:53 CEST] <TheRyuu> or you can look at it as punishment for not using msvc
[17:08:30 CEST] <TheRyuu> when did binutils finally stop using cvs
[17:08:53 CEST] <Gramner> at least it doesn't strip relocs from shared libs
[17:10:45 CEST] <nevcairiel> only from executables =p
[17:11:12 CEST] <Gramner> it msvc just fixes support for inline assembly on x64 I would probably stop using mingw altogether
[17:11:36 CEST] <nevcairiel> they have never supported that, its  unlikely they start anytime soon
[17:12:02 CEST] <Gramner> well, people used to say that about c99
[17:12:39 CEST] <nevcairiel> even ignoring inline asm, sadly gcc builds of ffmpeg are still non-trivially faster
[17:13:27 CEST] <nevcairiel> although i didnt compare 2015 yet
[17:13:29 CEST] <Gramner> are you using msvc with the most sane settings? I never checked
[17:13:39 CEST] <nevcairiel> define most sane
[17:14:27 CEST] <Gramner> -zomg-fast
[17:14:52 CEST] <Gramner> no, but optimized for performance instead of just defaults basically
[17:15:04 CEST] <nevcairiel> sure
[17:15:26 CEST] <Gramner> it uses stuff like stack cookies by default with has a significant overhead in some functions
[17:17:08 CEST] <nevcairiel> i should run a bench on ffmpeg itself again one of these days, I'm sure the options used in ffmpegs configure arent that precise
[17:18:39 CEST] <nevcairiel> disabling security features for performance is one of those arguable areas, but i should check how much stack cookies really cost
[17:20:31 CEST] <Gramner> honestly, there are so many attack vectors in libavcodec that I wouldn't trust it to decode untrusted data in anything other than a fat sandbox environment anyway
[17:20:34 CEST] <nevcairiel> but in the end that still leaves inline asm, and even if microsoft would fix that for x64, ffmpeg sitll uses the w rong syntax
[17:21:49 CEST] <Gramner> if you're relying on stack cookies for security you've basically already lost. but I'm sure others disagree
[17:22:17 CEST] <TheRyuu> stack cookies with the default settings should be almost free
[17:22:37 CEST] <TheRyuu> you should never have to disable /GS for performance
[17:23:52 CEST] <TheRyuu> 17:20 < Gramner> honestly, there are so many attack vectors in libavcodec <---IIRC most are actually in parsing (libavformat)
[17:24:30 CEST] <Gramner> libav* then
[17:33:29 CEST] <TheRyuu> does binutils have an irc channel
[17:34:27 CEST] <Daemon404> LOL
[17:35:40 CEST] <TheRyuu> should I take that as a no
[17:40:14 CEST] <TheRyuu> https://sourceware.org/bugzilla/show_bug.cgi?id=17321
[17:40:56 CEST] <TheRyuu> yes another option to fix a string of other broken options pls
[18:26:23 CEST] <durandal_1707> kierank: do you use asan?
[18:49:34 CEST] <TheRyuu> https://sourceware.org/bugzilla/show_bug.cgi?id=19011
[18:49:51 CEST] <TheRyuu> inb4no replies
[18:53:12 CEST] <Gramner> good post
[18:58:34 CEST] <Daemon404> enjoy your GNU
[18:58:46 CEST] <nevcairiel> gnus should be eaten, not reasoned with
[18:59:40 CEST] <TheRyuu> honestly I don't really care what happens now, now they know about it so it's up to them to do something about it
[19:00:39 CEST] <Gramner> I mean, it might break some legacy code from -92 that stores data in pointers, so it's going to get rejected. you should've suggested at least 3 new commandline flags instead
[19:01:27 CEST] <TheRyuu> I even went out of my way to reject the idea of adding a command line flag in my post
[19:01:37 CEST] <TheRyuu> I guess I'm doing it wrong
[19:01:56 CEST] <nevcairiel> Gramner: and usually MS is into those weird-ass backwards compat things
[19:02:29 CEST] <nevcairiel> (like largeaddressaware which actually makes it 32-bit for pointers, and not just 31)
[19:02:36 CEST] <nevcairiel> +use
[19:02:59 CEST] <Gramner> I guess "ms is doing it, so we're doing the opposite" is a possible explanation (which is also usually an ms tactic)
[19:03:50 CEST] <wm4> GNU usually prefers the most broken and awkward solution to anything
[19:04:07 CEST] <TheRyuu> granted the reloc section shit is actually broken compared to my other suggestions
[19:04:30 CEST] <TheRyuu> and should probably be fixed regardless of whatever else happens with it
[19:33:26 CEST] <cone-328> ffmpeg 03Alex Smith 07master:6e61231d641b: configure: Disable automatic image base calculation
[20:13:28 CEST] <kierank> durandal_1707: no
[20:25:14 CEST] <cone-328> ffmpeg 03Henrik Gramner 07master:7ca1de5b4f1a: checkasm/x86: Correctly handle variadic functions
[21:40:27 CEST] <fritsch> https://github.com/01org/libyami/blob/master/encoder/vaapiencoder_hevc.cpp#L152 <- I think the libva version that will actually define VAAPI_PROFILE_HEVC_MAIN10
[21:40:33 CEST] <fritsch> they will release some day?
[21:42:36 CEST] <wm4> oh wait is that the official libyami repo?
[21:43:03 CEST] <fritsch> jep
[21:43:09 CEST] <fritsch> but see: https://github.com/01org/libyami/commit/bb75c8d35ded275b7511d70913683f77b83278d2
[21:43:15 CEST] <fritsch> at least he knows something we don't :-)
[21:43:38 CEST] <fritsch> let me spam his github :-)
[21:43:39 CEST] <fritsch> and ask
[21:49:52 CEST] <JEEB> nice s tuff
[21:50:46 CEST] <wm4> call me if there's a driver/hw combination where this works
[21:51:34 CEST] <fritsch> i will
[21:52:43 CEST] <fritsch> BtbN: https://github.com/01org/libyami/blob/master/decoder/vaapidecoder_h265.cpp <- if something concerning scaling lists is still missing
[21:55:45 CEST] <BtbN> they are not missing, they just don't decode correctly.
[22:11:00 CEST] <fritsch> perhaps they do something differently
[22:11:05 CEST] <fritsch> to workaround some driver specialities
[22:11:12 CEST] <fritsch> btw. they also have VP9 decoder in there
[22:11:17 CEST] <fritsch> profile matching the hybrid-driver
[22:36:33 CEST] <cone-328> ffmpeg 03Christophe Gisquet 07master:b8b8e82ea140: dnxhddec: check and report bitstream errors
[22:55:07 CEST] <cone-328> ffmpeg 03Thomas Mundt 07master:2b6567722a48: h264: Fix ticket #3147 H264 - Wrong field order
[22:56:46 CEST] <wm4> we should have standards for commit messages
[22:59:04 CEST] <JEEB> wow
[22:59:15 CEST] <JEEB> that commit message looks straight out of some corporate commit machine
[22:59:27 CEST] <JEEB> not saying the fix isn't good but wow
[23:07:12 CEST] <cone-328> ffmpeg 03Ganesh Ajjanagadde 07master:f1a9583305d9: ffplay: add support for interactive volume control
[23:07:13 CEST] <cone-328> ffmpeg 03Ganesh Ajjanagadde 07master:fd44892073cc: doc/ffplay, ffplay: add information regarding volume control
[23:27:49 CEST] <kierank> JEEB: it's a bit weirdly worded
[23:28:07 CEST] <kierank> but "Default" is a verb iirc
[23:29:59 CEST] <JEEB> kierank: it was the avc intra field order thing, right?
[23:30:04 CEST] <kierank> yes
[00:00:00 CEST] --- Mon Sep 28 2015