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

[burek]

[10:24:41 CEST] <thardin> hmmm
[10:24:53 CEST] <thardin> is there a particular reason why av_clip_uint8_c() assumes 32-bit int?
[10:34:55 CEST] <durandal_1707> speed
[10:36:29 CEST] <thardin> it just seems it's supposed to do sign extension into the lowest 8 bits. but that won't work right for say 0x80000000 on 64-bit systems
[10:36:47 CEST] <thardin> would return 1 instead of 255
[10:39:35 CEST] <thardin> and presumably shifting by 31 takes the same time as shifting by 63
[10:53:19 CEST] <thardin> derp, it's only long that is 64-bit on 64-bit
[10:53:38 CEST] <thardin> in gcc at least
[10:59:09 CEST] <cone-189> ffmpeg 03Paul B Mahol 07master:d5b2458f4695: avfilter/vf_lut3d: fix range domain processing for .cube format
[10:59:09 CEST] <cone-189> ffmpeg 03Paul B Mahol 07master:5840a7f8a6d7: avfilter/vf_lut3d: increase MAX_LEVEL
[11:06:59 CEST] <nevcairiel> this is true, int is 32-bit everywhere, long is best avoided since it changes on different archs
[11:07:57 CEST] <nevcairiel> (and also doesnt change consistently, on windows long is always 32-bit, even on 64-bit systems, on linux it is 64-bit on 64-bit systems, etc - in short, avoid long :D)
[11:10:54 CEST] <cone-189> ffmpeg 03Paul B Mahol 07master:ea80af659c60: avcodec/scpr: avoid using uninitialized value
[14:20:22 CEST] <cehoyos> nevcairiel: Iiuc, toolchain=msvc defaults to "hardened" because GS is default for cc.exe, shouldn't we change this to "GS-" as default and "GS" for hardened?
[14:23:24 CEST] <nevcairiel> we should prefer default flags as much as possible imho
[14:23:33 CEST] <nevcairiel> if the compiler thinks this should be on by default, we shouldnt turn it off
[14:23:54 CEST] <cehoyos> The option exists...
[14:24:07 CEST] <cehoyos> And imo, this breaks performance comparisons
[14:24:34 CEST] <cehoyos> We default to "not hardened", no=
[14:24:36 CEST] <cehoyos> ?
[14:25:13 CEST] <JEEB> do we? I thought gcc/clang also harden by default (if we're talking about stuff like spectre etc mitigation) and we don't override that? unless we're talking about some other hardening.
[14:25:17 CEST] <nevcairiel> on gcc you have to explicitly enable it, and it potentially does much more then simple buffer security cookies
[14:25:26 CEST] <JEEB> ah, ok. so gcc doesn't :)
[14:25:36 CEST] <nevcairiel> it probably does some thing by default as well
[14:25:45 CEST] <nevcairiel> but it certainly has some additional hardening o ptions
[14:25:56 CEST] <JEEB> yea, you have various additional generic hardening options
[14:26:04 CEST] <cehoyos> Are there other hardening / non-hardening options for msvc except GS?
[14:26:04 CEST] <JEEB> which are unrelated to the CPU issues
[14:26:37 CEST] <cehoyos> gcc defaults to no security features, no?
[14:29:01 CEST] <nevcairiel> which gcc features are enabled by default can also vary depending on how it was build
[14:29:10 CEST] <nevcairiel> ie. it can change in different distributions
[14:29:53 CEST] <nevcairiel> In any case I'm of the opinion that we shouldn't disable default security features unless specifically asked to
[14:31:02 CEST] <nevcairiel> msvc performance comparisons are  "unfair" anyway because the inline asm syntax we use is incompatible
[14:32:23 CEST] <nevcairiel> and there is definitely more hardening options for msvc, spectre stuff for example, but also some additional options that I don't exactly know how to fully use
[14:33:14 CEST] <JEEB> yea, I'm generally of the opinion that not overriding defaults is probably a good idea. you then need to keep tabs on when things change in different ways. just like in theory we should be keeping an eye on that autovectorization thing we disable in some compilers
[14:47:18 CEST] <cehoyos> I am not sure there are spectre options: Aren't there spectre-compilers?
[14:47:38 CEST] <BtbN> There is a whole different msvc runtime you can target for spectre hardening.
[14:47:43 CEST] <nevcairiel> its /Qspectre for cl.exe
[14:47:54 CEST] <cehoyos> And how does the user ask FFmpeg to compile without hardening with msvc? I thought that is exactly what "./configure --toolchain=msvc" would do.
[14:48:06 CEST] <nevcairiel> the hardened library is basically the default library compiled with t hat option
[14:48:16 CEST] <cehoyos> So we should add "Qspectre" for hardening
[14:49:01 CEST] <cehoyos> JEEB: I am not sure you understand: FFmpeg defaults to non-hardening, but the user cannot disable hardening for msvc.
[14:49:24 CEST] <nevcairiel> this isnt really "hardening" as it is in gcc
[14:49:32 CEST] <nevcairiel> its a very cheap protection against buffer overflows
[14:49:39 CEST] <nevcairiel> hardening in gcc is typically far more expensive options
[14:50:09 CEST] <JEEB> I remember giving cl.exe parameters with env vars (because I remember having issues with extra-cflags/ldflags back in the day)
[14:50:10 CEST] <cehoyos> The description sounds similar to gcc stack protection
[14:50:41 CEST] <JEEB> so if you need to add "GS-" somewhere, wouldn't that make it possible?
[14:50:48 CEST] <JEEB> although I don't remember the exact env vars
[14:51:16 CEST] <nevcairiel> you can always build with extra-cflags if you so desire
[14:51:28 CEST] <nevcairiel> re spectre: we dont  add the gcc options for spectre either
[14:52:15 CEST] <nevcairiel> these things are very specialized and should probably be entirely controlled by the user - thats what extra cflags is for
[14:52:15 CEST] <JEEB> yea, not sure why I had problems with extra-*flags back in the day. been a while since I last touched cl.exe building
[14:52:36 CEST] <JEEB> I think it was mostly LIBS or so for me
[14:52:43 CEST] <cehoyos> JEEB: We tell our users not to mess with compiler options (they break compilation with Gentoo)
[14:53:09 CEST] <cehoyos> As user you cannot control them because of how configure works.
[14:55:24 CEST] <JEEB> I don't think this is as black/white as that to be honest. there are legitimate cases where you might have to override some compiler/linker flags. as a generic user thing, yes. "don't mess with the options unless you know you have to"
[14:55:47 CEST] <nevcairiel> if you use gentoo and dont understand compiler flags, you are doing it wrong anyway
[22:08:47 CEST] <cone-166> ffmpeg 03Marton Balint 07master:a5136426a732: avformat/mxfdec: rework mxf_essence_container_end
[22:08:47 CEST] <cone-166> ffmpeg 03Marton Balint 07master:5b6960f955a8: avformat/mxfdec: guess wrapping of tracks by other tracks with the same body sid
[22:08:47 CEST] <cone-166> ffmpeg 03Marton Balint 07master:fc15e8306f84: avformat/mxfdec: take into account run-in in find_partition_by_offset
[22:08:47 CEST] <cone-166> ffmpeg 03Marton Balint 07master:3dee6c09970d: avformat/mxfdec: fix and enhance RIP KLV length checks
[22:34:23 CEST] <durandal_1707> we should vote first should we vote at all
[23:13:43 CEST] <kierank> durandal_1707: so many people who have not done anything for years
[23:17:28 CEST] <durandal_1707> kierank: i doubt they will cast a vote
[23:42:50 CEST] <ubitux> still no decision taken on forward declaration and merging all the libs?
[23:43:02 CEST] <ubitux> damn, why did i go away for? :(
[23:45:21 CEST] <durandal_1707> ubitux: what happened?
[23:47:08 CEST] <jamrial> ubitux: there was a vote for that? :S
[23:48:25 CEST] <ubitux> durandal_1707: nothing it seems :(
[23:48:37 CEST] <ubitux> jamrial: i dunno, maybe it could have happened
[23:48:46 CEST] <j-b> merging all the libs? why?
[23:49:04 CEST] <ubitux> j-b: ease code sharing and inter-lib dependencies
[23:49:22 CEST] <ubitux> the question was raised quite a few times
[23:49:51 CEST] <j-b> I find this idea a bit weird, every time this is raised, tbh.
[23:50:42 CEST] <j-b> I would prefer more splitting, tbh :)
[23:53:28 CEST] <ubitux> as a user, sure, but as a developer, it makes progress much more complex
[23:54:08 CEST] <ubitux> that said, i'd rather push on the forward declaration thing currently
[23:54:34 CEST] <ubitux> 'been working on a codebase where this is allowed for a while now, and i must admit it often makes the code so much better...
[23:54:56 CEST] <j-b> I agree on the fwd declarations
[23:55:28 CEST] <j-b> as for the splitting, not really, because I'm afraid it will allow more "dirty hacks"
[23:55:40 CEST] <j-b> especially with libavfilter and libavdevice.
[23:56:02 CEST] <j-b> Why does Marton focus on GPLv3 while most of FFmpeg is LGPLv2.1 or later?
[23:57:18 CEST] <BtbN> I feel like we need a vote on how the Project wants to interpret the license first of all...
[23:57:20 CEST] <jkqxz> Can we please not use any sort of GPL definition anyway?  People don't generally agree what it means, so there will just be more argument later.
[23:57:55 CEST] <j-b> jkqxz: I agree on that.
[23:58:05 CEST] <j-b> The GPL is too verbose and not preceise enough
[23:58:55 CEST] <jkqxz> It's not relevant to this question.  The GPL definition can affect people distributing binaries, but it's orthogonal to the current question of what should be included in the source code.
[00:00:00 CEST] --- Mon Apr 29 2019