[03:04:20 CEST] <cone-291> ffmpeg 03Vignesh Venkatasubramanian 07master:7be0f48a3215: lavf/matroskaenc: Write Block Keyframe correctly [03:52:29 CEST] Action: llogan loves screenshots of text [03:53:08 CEST] <llogan> proper method should be console > image > OCR > libflite [04:17:43 CEST] <cone-291> ffmpeg 03Michael Niedermayer 07master:c93602ae5bd4: avcodec/rdft: Use more specific error codes [13:11:25 CEST] <cone-824> ffmpeg 03Michael Niedermayer 07master:c7ce16e716a8: avutil/softfloat: Fix thresholds in av_normalize_sf() [13:11:26 CEST] <cone-824> ffmpeg 03Michael Niedermayer 07master:904ea60afacd: avutil/softfloat: Add more tests for the normalization [13:51:49 CEST] <cone-824> ffmpeg 03Nedeljko Babic 07master:19ed3e35a5cd: libavutil/doc: Changes in documentation due to changes to fixed_dsp [13:51:50 CEST] <cone-824> ffmpeg 03Michael Niedermayer 07master:d3585c53debe: avutil/softfloat: Move av_sincos_sf() from header to c file [17:14:48 CEST] <cone-824> ffmpeg 03Andreas Cadhalpun 07master:5bf84a584e9c: arm: only enable setend on ARMv6 [17:56:41 CEST] <cone-824> ffmpeg 03Michael Niedermayer 07master:6690ca22b36e: avutil/softfloat: Fix alternative implementation of av_normalize_sf() [17:56:42 CEST] <cone-824> ffmpeg 03Michael Niedermayer 07master:af8d63e756e6: avutil/softfloat: Fix alternative implementation of av_normalize1_sf() [18:23:11 CEST] <pps> any info about building ffmpeg with msvc tollchain and --disable-optimizations option? [18:23:54 CEST] <pps> it seems that all the deadcode is till referenced by ms compiler when compiled in debug/non-optimizing mode [18:24:15 CEST] <pps> is there a way to make it work without optimizations? [18:24:30 CEST] <pps> (e.g. without manually passing -O1 or something like that) [18:26:49 CEST] <nevcairiel> pps: no, that is not possible, without optimizations doesnt work with msvc .. if you are developing code and using msvc for it, you can manually disable optimizations for individual files using #pragma commands, which is what I usually use when i work on code inside ffmpeg, or debug a particular problem [18:28:12 CEST] <wm4> (this ffmpeg "requirement" is so stupid) [18:28:24 CEST] <pps> i have this idea in mind. For all code that has for if(HAVE_SOMETHING) { call_something(); } configure might automatically generate a c file with this kind of stuff: [18:29:12 CEST] <pps> #ifndef HAVE_SOMETHING [18:29:14 CEST] <pps> char call_something; [18:29:15 CEST] <pps> #endif [18:29:17 CEST] <pps> ... [18:29:46 CEST] <wm4> I'd rather just have #idef in the code [18:29:50 CEST] <wm4> directly [18:30:01 CEST] <pps> that way, it won't result in link errors in debug builds [18:30:08 CEST] <pps> in some places you cannot. [18:31:26 CEST] <pps> like in the function that registers all the codecs. Macro expands there to if(HAVE_##CODEC) avregister(codec)l; It's obviously possible to modify that macro to avoid referencing dead code (e.g. to expand to nothing instead) [18:33:07 CEST] <pps> in short, making proper ifdefs will result in many changes all over the place. Generating automatic .c file with dummy variables doesn't have any harm: if they aren't referenced they won't be included, if they are actually referenced it will be a link error, e.g. it cannot result in code trying to call a char variable as if it was a function [18:33:42 CEST] <wm4> pps: allcodecs.c should just be generated by configure or so [18:33:59 CEST] <pps> no, not a good idea IMO [18:34:22 CEST] <pps> there you can see all supported codecs, and you don't need to go to some configure script etc [18:35:06 CEST] <nevcairiel> wm4: but configure gets its list of codecs from allcodecs.c :D [18:35:18 CEST] <wm4> nevcairiel: I know... which is just backwards [18:35:28 CEST] <pps> anyways, allcodecs is minor issue compared to others. There are like hundred other places where similar if(0) call_something(); code exists [18:35:48 CEST] <pps> nevcairiel: exactly, also true :0 [18:35:50 CEST] <wm4> pps: you could also try some preprocessor magic, which wouldn't even require changes to most of allcodecs.c [18:36:11 CEST] <nevcairiel> You are unlikely to find much support for actually changing this in the code base [18:36:40 CEST] <pps> allcodecs is minor, registration macro could be expanded to c preprocessor majic to completely remove code for macro taht are 0. It'seasy. [18:36:54 CEST] <pps> but there are MANY other places that are all different. [18:38:00 CEST] <pps> forget abotu allcodecs.c, it's a simple fix. All other places aren't likely to get support for that kind of change from if(HAS_SOMETHING) to #ifdef HAS_SOMETHING [18:38:46 CEST] <nevcairiel> its unfortunate the optimizer can't just optimize these things away and leave everything else in place, however with the recent improvements to release-build-debugging features, its not too bad [18:38:56 CEST] <nevcairiel> and in fact, if you try to debug a gcc build, you run into the same problems [18:39:03 CEST] <nevcairiel> a *lot* of local variables optimized out =p [18:39:04 CEST] <pps> because in many places it's like 5 lines and each like call functions for some platform. FOr example if(HAVE_ARM) register_dsp_arm(); next like is already for x86 etc [18:39:16 CEST] <pps> with #ifdefs it will look like mess [18:40:25 CEST] <pps> the reason I want to ahev debug build is that I'm trying to debug code and I cannot see values of some variables i deeply nested code because of optimizations. [18:40:31 CEST] <nevcairiel> i'm probably one of the few regular contributors who actually use msvc primarily, and I don't even mind that much, i'm just happy i dont have to mess with gdb, is all :D [18:40:50 CEST] <nevcairiel> pps: like i said, wrap that particular code in #pragmas that disable optimizations [18:41:32 CEST] <nevcairiel> #pragma optimize("", off) [18:42:06 CEST] <pps> i know, i can find a workaround, i was just courious if a generic solution could be added to ffmpeg build [18:42:21 CEST] <BtbN> MSVC does not have a better way to turn off optimizations [18:42:41 CEST] <BtbN> gcc has -O0, but MSVC simply doesn't [18:42:52 CEST] <nevcairiel> honestly the situation is no different in gcc, people just have been dealing with it for years for ffmpeg already so they dont complain =p [18:42:55 CEST] <pps> -Od [18:43:08 CEST] <nevcairiel> i dont think gcc builds with disabled optimizer [18:43:22 CEST] <pps> i think it builds [18:45:09 CEST] <cehoyos> nevcairiel: You cannot disable dead code optimization for gcc [18:45:14 CEST] <cehoyos> (afaik) [18:47:18 CEST] <pps> cehoyos: regarding automatically generating by configure refs to deadcode to enable linking in msvc/icl. Would something like this be acceptable in ffmpeg? [18:48:12 CEST] <cehoyos> I cannot answer this question but what's wrong with using -Od or what is necessary to activate dead code elimination in msvc? [18:48:53 CEST] <nevcairiel> you need O1 [18:49:05 CEST] <nevcairiel> or well, global optimization anyway [18:49:10 CEST] <nevcairiel> which is part of O1 [18:49:15 CEST] <nevcairiel> but also removes all the local variables [18:50:26 CEST] <cehoyos> Why is this not set as cflags_noopt in configure? [18:51:34 CEST] <nevcairiel> it makes no difference [18:52:26 CEST] <cehoyos> It makes no difference if the user has to pass an option instead of automatically setting it? [18:52:43 CEST] <cehoyos> And while there: Why is _cflags_size not set to Os? [18:53:45 CEST] <cehoyos> Ah, Og is deprecated in favour of =1 [18:53:48 CEST] <cehoyos> of O1 [18:54:34 CEST] <nevcairiel> O1 is maximize speed, which should be the default for the size thing i think? [18:54:45 CEST] <nevcairiel> eh minimize size [18:54:47 CEST] <nevcairiel> i got confused [18:55:19 CEST] <cehoyos> Same here, sorry. [18:56:07 CEST] <nevcairiel> noopt could be set to Og if you really wanted to, but O1 is probably similar in generated code, the other options make no huge difference [18:56:15 CEST] <nevcairiel> Od would be appropriate, but that doesn't build [19:09:33 CEST] <pps> yes, in msvc there are no options to disable dead code elimination without optimizations. [19:10:05 CEST] <pps> ffmpeg totally relied on gcc to do so even without optimizing code, which is wrong imo (for gcc to do so) [19:10:41 CEST] <pps> there is linker option in msvc /OPT:REF, but it doesn't help [19:13:02 CEST] <nevcairiel> if the compiler still thinks its to be used, then the linker cant fix that [19:14:24 CEST] <wm4> can't you make the linker to ignore unresolved symbols? [19:15:00 CEST] <wm4> I even remember how the old Borland Pascal compiler could output object files even if the source file had semantic errors [19:20:46 CEST] <cone-824> ffmpeg 03Michael Niedermayer 07master:06b49375a2cd: avutil/ppc/cpu: add include avassert.h [19:28:47 CEST] <BBB> michaelni__: why were the fixed_dsp functions added to APIChanges? that doesnt seem like it belongs there [19:30:16 CEST] <michaelni__> they will be used by the aac patches and they are in libavutil so they have to be public [19:30:27 CEST] <michaelni__> if they arent ATM then the APIChanges entry was premature [19:34:27 CEST] <michaelni__> ac3dec uses AVFixedDSPContext so i would assume its public already [19:38:09 CEST] <jamrial> softfloat.h is not an installed header, though [19:38:39 CEST] <jamrial> sorry, fixed_dsp.h [19:41:42 CEST] <wm4> these APIchanges entries are completely bogus [19:42:15 CEST] <wm4> oh, they're callbacks in the DSP context [19:43:07 CEST] <wm4> they're not public anyway, and fixed_dsp.h is indeed not an installed header, so they should be removed [20:09:25 CEST] <jamrial> does it need to be installed for that matter? it's essentially the same as float_dsp, and that one has always been internal [20:12:34 CEST] <michaelni__> jamrial, thats a philosophical question, ill just accept what the community prefers on that [20:23:02 CEST] <cone-824> ffmpeg 03Michael Niedermayer 07master:6fd15d6e90b1: Revert addition of a few fixed_dsp functions to APIChanges [20:24:18 CEST] <BBB> I meant what jamrial said, yes [20:25:00 CEST] <BBB> I think stuff that is in the avpriv_ symbol range (or should be there), should be treated as ff_* for documentation purposes, i.e. not public api and not for use in applications" [20:25:18 CEST] <BBB> (not that we can tell apps what to do and what not to do, but anyway) [20:26:20 CEST] <michaelni__> yes, i misunderstood what you meant [20:43:13 CEST] <pps> regarding linking in msvc/icl. What about: instead of: http://pastie.org/10225658 it could be: http://pastie.org/10225663#3 [20:44:19 CEST] <wm4> that's the preprocessor hack I mentioned [20:44:25 CEST] <Daemon404> i think it's not going to be popular to work around msvc like that when no other compiler needs it [20:44:51 CEST] <wm4> this is about doing standard C instead of relying on compiler specifics [20:45:08 CEST] <Daemon404> it's been raised a billion times about relyign on DCE [20:45:10 CEST] <pps> agree [20:45:13 CEST] <Daemon404> i doubt this time will end any different [20:45:16 CEST] <wm4> heh [20:45:30 CEST] <wm4> ffmpeg will be ffmpeg [20:45:32 CEST] <pps> agree with wm4 O ean [20:46:31 CEST] <pps> well, then it could be added a configure step that adds all these function into a dummy file for msvc/icl debug builds only [20:46:36 CEST] <pps> that way no code change is needed [21:04:23 CEST] <jamrial> the font-awesome characters are apparently not working on fate.ffmpeg.org anymore [21:30:56 CEST] <michaelni> jamrial, do you know why ? some error /warning somewhere ? [21:36:32 CEST] <baptiste> michaelni, CORS issue I believe [21:42:25 CEST] <michaelni> thx, jamrial, beastd, should be fixed [21:45:57 CEST] <michaelni> hi lglinskih_, how is the outreachy work going ? [21:46:00 CEST] <michaelni> any patches ? [21:56:55 CEST] <cone-824> ffmpeg 03Michael Niedermayer 07master:b2fecce3c16e: avformat/flvdec: increase buffer size for parsing metadata string key [21:56:56 CEST] <cone-824> ffmpeg 03Michael Niedermayer 07master:790a3cdf7687: avformat/flvdec: Add TYPE_ONCAPTIONINFO [21:56:57 CEST] <cone-824> ffmpeg 03Michael Niedermayer 07master:108b738db1fd: avformat/flvdec: Show unknown tags at debug level [21:56:58 CEST] <cone-824> ffmpeg 03Ganesh Ajjanagadde 07master:a86928d2abf8: flvdec: fix lack of duration for some files [22:03:05 CEST] <BBB> so Im looking at ff_hevc_cabac_init(), do we ever carry over cabac state from one frame to the next? [22:03:10 CEST] <BBB> I mean, does that ever happen? [22:04:25 CEST] <BBB> (it looks like we dont?) [22:48:16 CEST] <nevcairiel> re: earlier discussion, having avpriv in avutil seems like a wrong design. Everything avutil should be generically useful, or it seems to not be the right fit.. [22:53:45 CEST] <jamrial> well, float_dsp can't be moved to lavc and made fully internal there because it's also used by lavfi [22:54:58 CEST] <jamrial> float/fixed_dsp could be made public, in a similar fashion as avfft is [22:55:01 CEST] <jamrial> but if nobody ever cared about using them outside of libav* then i don't think it's worth it [22:56:24 CEST] <jamrial> heh, another ticket that is solved by using pkgconfig :p [22:56:57 CEST] <nevcairiel> another thing we arent using pkgconfig for? meh [22:58:10 CEST] <nevcairiel> its odd though, the ticket claims we use pkgconfig for libx264 :d [22:58:36 CEST] <nevcairiel> or did that get the hacky workaround-y thing [22:59:05 CEST] <nevcairiel> apparently it did get a workaround-y thing with fallback for non-pkgconfig [22:59:13 CEST] <jamrial> we do, but there's a fallback [22:59:14 CEST] <jamrial> yeah [22:59:44 CEST] <nevcairiel> but yeah, pkg-config is useful, even if some people are unwilling to accept that [22:59:54 CEST] <nevcairiel> even (and maybe especially?) if you have custom build setups [23:23:39 CEST] <baptiste> OS X does not have pig-config out of the box [23:24:04 CEST] <baptiste> that's one reason I don't like pig-config :) [23:25:14 CEST] <nevcairiel> its a tiny binary, just install it [23:25:25 CEST] <nevcairiel> also, i think mine had it, i dont r emember installing it [23:25:27 CEST] <nevcairiel> maybe i just forgot [23:25:36 CEST] <baptiste> well, yeah, and actually reading .pc file is simple, you could do it in configure :) [23:27:33 CEST] <wm4> or you could just install it [23:27:51 CEST] <wm4> I didn't even have to install it when I ran osx, it somehow came with homebrew [23:57:23 CEST] <Plorkyeran> I think homebrew just assumes anything built from source needs pkgconfig [00:00:00 CEST] --- Sat Jun 6 2015