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

[burek]

[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