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

[burek]

[02:39:59 CEST] <IIIkksksks> Hi. Guys, previous versions, not new 3.3 has broken, have inserts.... look..
[02:41:24 CEST] <IIIkksksks> just check windows binaries...others not seen, think too
[04:18:17 CEST] <chatter29> hey guys
[07:29:10 CEST] <Mista_D>  Is that supoposed to take longer: "-ss $t -i $file" VS. "-ss $t -f concat -i $file.concat" ? Wondering why is seeking much slower with concat. Please advise.
[07:32:27 CEST] <wm4> could be because the concat demuxer is a hack
[07:33:09 CEST] <Mista_D> well, it might benefit from becoming a real adult demuxer
[07:33:50 CEST] <Mista_D> should I "trac" it ?
[07:34:01 CEST] <kkanungo17> how do I output the aac ancoder block size through s->psy.model->window() ?
[07:34:18 CEST] <kkanungo17> I'm calling the function from vorbisenc.c
[07:45:18 CEST] <alevinsn> anyone know what the deal is with the FF_API_LAVF_AVCTX define?
[07:45:59 CEST] <alevinsn> As a result of that being defined, AVStream objects tend to leak some memory
[07:47:15 CEST] <wm4> these defines are for marking/excluding deprecated API
[07:47:37 CEST] <alevinsn> right, but it is being turned on as far as I can tell in the latest build
[07:47:54 CEST] <alevinsn> it is only turned off if the libavformat major version is bumped up to 58
[07:48:00 CEST] <alevinsn> and that apparently hasn't been done
[07:48:19 CEST] <alevinsn> so, that results in a bunch of deprecated functionality being enabled
[07:48:32 CEST] <alevinsn> the major version is currently set at 58
[07:48:42 CEST] <alevinsn> there is a comment in libavformat/version.h
[07:48:50 CEST] <alevinsn> that indicates that bumping the major version might break Chromium
[07:49:16 CEST] <alevinsn> so, basically, while it may be documented as deprecated, in effect it actually isn't
[07:51:45 CEST] <alevinsn> I guess I should just fix the memory leaks by adjusted stream_free()
[07:51:51 CEST] <alevinsn> by adjusting
[08:38:18 CEST] <alevinsn> For anyone in Europe, is interlaced video still used there, for, say, broadcast television?
[08:38:27 CEST] <alevinsn> Like 1080i50, for example
[09:00:14 CEST] <rcombs> I'm not European but I deal with European TV streams regularly
[09:00:16 CEST] <rcombs> yes, it is
[09:04:27 CEST] <alevinsn> ok, thanks
[09:05:01 CEST] <alevinsn> I had submitted a patch having to do with fixing a bug with interlaced video I guess a month ago now
[09:05:24 CEST] <alevinsn> and I was wondering if maybe people don't care because interlaced video isn't used much where they are based
[09:11:33 CEST] <wm4> most likely it just was overlooked or so
[09:12:12 CEST] <alevinsn> I pinged it last week or maybe the week prior
[09:12:51 CEST] <alevinsn> the change is actually more general than just one that addresses issues with interlaced video
[09:37:11 CEST] <kkanungo17>  using ff_psy_init() in vorbisenc.c causes segfault
[09:37:16 CEST] <kkanungo17> any advice?
[09:37:41 CEST] <kkanungo17> happens when ctx->model->init is accessed in psymodel.c
[11:25:15 CEST] <nevcairiel> alevinsn: deprecated in ffmpeg always means the code is still there, but scheduled for removal at a later date (ie. typically a major version bump), so people have time to migrate to the replacements without immediately breaking their apps if they don't, after that deprecation period we don't keep disabled code around, at that time its then entirely removed.
[12:56:28 CEST] <cone-600> ffmpeg 03Paul B Mahol 07master:9ef21a897c64: avcodec/utvideodec: fix decoding odd sizes with interlaced video with some formats
[18:20:09 CEST] <alevinsn> nevcairiel:  I wanted to run a DCE proposal by you to see if it passes at least initial muster
[18:22:06 CEST] <alevinsn> I know hearing about these proposals is probably one of the things you most look forward to in your day :-P
[18:24:20 CEST] <alevinsn> well, assuming you are around....
[18:27:46 CEST] <nevcairiel> any crazy and complex schemes are likely not going to make enough people happy =p
[18:28:17 CEST] <alevinsn> its not crazy, I think
[18:28:31 CEST] <alevinsn> you were right about the approach I talked about yesterday being really hacky
[18:28:41 CEST] <alevinsn> I had to make a bunch of changes to those files from Matt Oliver to get it to build
[18:29:00 CEST] <alevinsn> The only non-hacky approach I think is to remove it entirely, but that involves changing a bunch of files at once
[18:29:07 CEST] <nevcairiel> I wondered about one thing, if there is a function in there that does actually exist in your build, wouldnt it then scream about having it twice
[18:29:39 CEST] <alevinsn> there were also some clear mistakes in Matt's files
[18:30:11 CEST] <alevinsn> but, regarding the entire removal, its an either all in or all off sort of thing
[18:30:24 CEST] <alevinsn> and I think its going to be hard to get that into ffmpeg, the entire removal of DCE all at once
[18:30:32 CEST] <alevinsn> so, I thought of something that would allow gradual removal
[18:30:36 CEST] <alevinsn> on a component-by-component basis
[18:30:51 CEST] <alevinsn> but not require that it be eliminated all at once
[18:31:04 CEST] <alevinsn> if --disable-optimizations is enabled
[18:31:11 CEST] <alevinsn> it will use _cflags_noopt
[18:31:32 CEST] <nevcairiel> there never was any requirement to eliminate it all at once, one can do it all step by step, but it would only start working once all is done :D
[18:31:57 CEST] <alevinsn> right, no way to have a truly non-optimized build until all done
[18:32:12 CEST] <alevinsn> so, in the case that it does use _cflags_noopt
[18:32:17 CEST] <alevinsn> it will declare two additional variables
[18:32:24 CEST] <alevinsn> one with the value stored in _cflags_noopt
[18:32:36 CEST] <alevinsn> and one with the value stored in, probably, _cflags_size
[18:32:50 CEST] <alevinsn> at the end of configure, when it is outputting CFLAGS=
[18:32:53 CEST] <alevinsn> into config.mak
[18:33:03 CEST] <alevinsn> it will generate an alternate, CFLAGS_REQUIRES_DCE=""
[18:33:09 CEST] <alevinsn> and replace the _cflags_noopt value
[18:33:12 CEST] <alevinsn> with the _cflags_size value
[18:33:24 CEST] <alevinsn> or, if _cflags_noopt is empty
[18:33:28 CEST] <alevinsn> append
[18:33:41 CEST] <alevinsn> then, in each Makefile, for each component that depends on DCE
[18:33:51 CEST] <alevinsn> it will check if CFLAGS_REQUIRES_DCE is set
[18:33:55 CEST] <alevinsn> and use that instead
[18:34:17 CEST] <alevinsn> in theory, this could be done on a file-by-file basis, but that's somewhat hacky
[18:34:23 CEST] <nevcairiel> that would seriously ugly up all the simple makefiles though
[18:34:37 CEST] <alevinsn> it would only add a few lines I think
[18:34:43 CEST] <alevinsn> and some Makefiles won't need it at all
[18:34:51 CEST] <alevinsn> there are some components that don't depend on DCE currently
[18:37:04 CEST] <alevinsn> I think it would just add something like
[18:37:10 CEST] <alevinsn> assuming the component needs DCE
[18:37:15 CEST] <nevcairiel> I don't really see the advantage over just changing the code then, its more files to touch, but typically not many more individual instances, since the main use is for arch specific functions, so every single file often only has one block of code that uses it
[18:37:17 CEST] <wm4> uh why would that matter
[18:37:24 CEST] <wm4> indeed
[18:37:31 CEST] <wm4> why can't we just change the code
[18:37:56 CEST] <alevinsn> well, I guess the uses of DCE are more complex than just if (CONFIG...) in swresample
[18:38:14 CEST] <nevcairiel> the complex cases are in the vast minority
[18:38:27 CEST] <alevinsn> plus, this allows component "owners" (if there is such a thing) to make a decision
[18:38:28 CEST] <wm4> the most complex you'll get is "if(CONFIG_... && expression)"
[18:38:30 CEST] <nevcairiel> majority are all arch specific stuff
[18:38:43 CEST] <nevcairiel> and those are easy
[18:38:45 CEST] <alevinsn> rather than it being an all group decision
[18:39:20 CEST] <nevcairiel> such a thing should just be consistent throughout the code, it doesnt help us if thigns are done differently in various places
[18:39:29 CEST] <nevcairiel> and it also doesnt help us if half works without DCE
[18:39:50 CEST] <alevinsn> well, it would make debugging the files that are partially converted easier
[18:39:54 CEST] <alevinsn> I mean, fully converted
[18:40:06 CEST] <alevinsn> but, all good arguments in favor of the one approach to rule them all....
[18:41:18 CEST] <alevinsn> ok, jumping topics, nevcairiel:  are you able to get make fate to work on Windows
[18:41:25 CEST] <alevinsn> with MSVC I mean
[18:41:26 CEST] <nevcairiel> of course
[18:41:51 CEST] <alevinsn> just run make fate and it should work?
[18:41:55 CEST] <nevcairiel> TimothyGu: fatebeta is down, can you start it again?
[18:42:18 CEST] <alevinsn> It failed for me because it was looking for libavdevice/libavdevice.a
[18:42:19 CEST] <nevcairiel> need to grab the sample files and point make to them
[18:42:40 CEST] <alevinsn> which tends to indicate that it isn't doing something right
[18:42:43 CEST] <nevcairiel> but yes i can just run configure and make fate after
[18:43:11 CEST] <nevcairiel> typically smarter to run make before make fate so it doesnt get mixed up
[18:43:19 CEST] <alevinsn> I had done that
[18:43:26 CEST] <alevinsn> make V=1 make
[18:43:28 CEST] <alevinsn> make install
[18:43:30 CEST] <alevinsn> and then make fate
[18:43:42 CEST] <alevinsn> and now that I've run make fate and it failed
[18:43:43 CEST] <nevcairiel> i dont install, but that shouldnt make a difference i reckon
[18:43:52 CEST] <alevinsn> it seems to have messed up regular make V=1
[18:43:56 CEST] <alevinsn> which is odd
[18:44:09 CEST] <alevinsn> maybe I've messed something up
[18:44:18 CEST] <alevinsn> hmm
[18:44:25 CEST] <alevinsn> CONFIG_DEFLICKER_FILTER
[18:44:32 CEST] <alevinsn> is that a new thing?
[18:44:41 CEST] <nevcairiel> it was pushed last night i think?
[18:44:51 CEST] <nevcairiel> make should yell at you when you need to re-run configure
[18:45:52 CEST] <alevinsn> I've never seen that occur
[18:46:01 CEST] <alevinsn> on Windows at least
[20:10:16 CEST] <alevinsn> is it preferable to use av_frame_make_writable() or to allocate a new frame each time?
[20:10:32 CEST] <alevinsn> I see different behaviors in the samples and ffmpeg.c
[20:24:36 CEST] <nevcairiel> it depends on what you are doing, i guess
[20:30:50 CEST] <rcombs> is there a channel for ffmpeg-security
[20:34:12 CEST] <wm4> doubt it
[20:41:28 CEST] <alevinsn> nevcairiel:  well, I've tried running make fate on Windows a bunch of times
[20:41:36 CEST] <alevinsn> it never gets past source-check.sh
[20:42:27 CEST] <nevcairiel> that part is pretty slow, but works for me
[20:42:54 CEST] <alevinsn> reports some files without standard licenses
[20:43:14 CEST] <nevcairiel> maybe your code has changes that arent quite right :D
[20:43:17 CEST] <alevinsn> and two uses of av_clip()
[20:43:24 CEST] <alevinsn> I don't think that's it in this case
[20:43:39 CEST] <alevinsn> all of the source-check.sh warnings have nothing to do with my changes
[20:44:53 CEST] <alevinsn> if source-check reports issues
[20:45:02 CEST] <alevinsn> then does fate stop?
[20:47:09 CEST] <alevinsn> Linux build of ffmpeg is many times faster than MSVC build on Windows on the same system
[20:47:12 CEST] <alevinsn> its ridiculous
[20:47:21 CEST] <alevinsn> configure finishes in like a second
[20:47:29 CEST] <alevinsn> it takes like a minute to finish on Windows
[20:47:30 CEST] <BtbN> the build itself is similar
[20:47:33 CEST] <BtbN> msys bash is just slow
[20:48:28 CEST] <nevcairiel> yeah its just configure thats slow
[20:48:39 CEST] <alevinsn> gcc seems to be faster than cl as well
[20:48:44 CEST] <nevcairiel> anyway all I know is that make fate passess successfully here
[20:48:59 CEST] <nevcairiel> -s
[20:49:03 CEST] <alevinsn> you don't get any source-check warnings?
[20:49:18 CEST] <nevcairiel> no
[20:49:24 CEST] <BtbN> cl would be faster if ffmpeg would use its native multi-processing
[20:49:36 CEST] <alevinsn> "-s"?
[20:49:46 CEST] <BtbN> But due to the way configure and make works, it runs it once per object file
[20:50:29 CEST] <nevcairiel> there are also various automated msvc build systems running fate every couple hours and all pass
[20:50:45 CEST] <nevcairiel> http://fate.ffmpeg.org/history.cgi?slot=x86_64-msvc15-windows-native like this, just passed an hour ago
[20:52:56 CEST] <rcombs> I dunno who worked on clusterfuzz integration but whoever it was, google wants to give them money
[20:53:43 CEST] <rcombs> (or, did anyone from ffmpeg actually do anything on that, or did google just stick it in clusterfuzz themselves? If the latter, I guess they just want to give the project in general money? How does that even work)
[20:54:57 CEST] <alevinsn> oh, I bet it is me
[20:55:25 CEST] <alevinsn> and my use of those dce .c files
[20:55:31 CEST] <nevcairiel> <nevcairiel> maybe your code has changes that arent quite right :D
[20:55:32 CEST] <nevcairiel> :)
[20:55:58 CEST] <nevcairiel> it should tell you which files it finds things in
[20:56:11 CEST] <alevinsn> hmm, I didn't do that on this system
[20:56:45 CEST] <alevinsn> so, that the DCE stuff isn't relevant here
[20:56:46 CEST] <alevinsn> it does
[20:57:06 CEST] <alevinsn> libavcodec/h263data.h
[20:57:14 CEST] <alevinsn> bunch of files in every directory
[20:57:21 CEST] <alevinsn> none of which I've modified
[20:57:56 CEST] <alevinsn> cmdutils.h
[20:58:01 CEST] <alevinsn> which does have header guards
[20:58:11 CEST] <alevinsn> #ifndef CMDUTILS_H
[20:58:11 CEST] <alevinsn> #define CMDUTILS_H
[20:58:27 CEST] <alevinsn> so, I would guess that the way it is doing that check isn't working on my system for some reason
[20:59:09 CEST] <nevcairiel> it uses nothing but git, grep, sed and tr
[20:59:12 CEST] <nevcairiel> all pretty basic tools
[21:08:34 CEST] <alevinsn> I wonder if it is my version of git that is the problem
[21:08:49 CEST] <alevinsn> I'm using the version of git that is installed as part of VS2015 install
[21:08:56 CEST] <alevinsn> here's the command-line that is actually executed
[21:09:09 CEST] <alevinsn> git grep -L "^#define CMDUTILS_H$" cmdutils.h
[21:09:22 CEST] <nevcairiel> i always install proper git for windows
[21:16:29 CEST] <alevinsn> do you pick Use git and optional Unix tools from the Windows Command Prompt when you install git?
[21:16:39 CEST] <nevcairiel> no, only use git from command prompt
[21:18:21 CEST] <Fenrirthviti> git from the windows command prompt is awful. the minigw terminal it installs with is much better.
[21:20:57 CEST] <alevinsn> didn't fix anything
[21:21:04 CEST] <alevinsn> VS2015 instsalled git is 2.10.1
[21:21:14 CEST] <alevinsn> new version is 2.12.2
[21:21:28 CEST] <alevinsn> but I get the same results from the git invocation in source-check.sh
[21:21:55 CEST] <alevinsn> this is in an msys2 windows
[21:21:56 CEST] <alevinsn> window
[21:31:14 CEST] <alevinsn> ok, I think that check-source.sh might be working properly
[21:31:19 CEST] <alevinsn> but, it still gets some error
[21:31:27 CEST] <alevinsn> it says to look at source.err for more details
[21:31:30 CEST] <alevinsn> but that file is empty
[21:37:22 CEST] <alevinsn> even the output of make fate or make V=1 fate differs significantly from what I see at
[21:37:27 CEST] <alevinsn> http://fate.ffmpeg.org/log.cgi?time=20170421175211&log=test&slot=x86_64-msvc15-windows-native
[21:37:55 CEST] <alevinsn> here's what it looks like for me
[21:38:12 CEST] <alevinsn> $ make V=1 fate
[21:38:12 CEST] <alevinsn> warning: only a subset of the fate tests will be run because SAMPLES is not specified
[21:38:12 CEST] <alevinsn> TEST    checkasm-alacdsp
[21:38:12 CEST] <alevinsn> ./tests/fate-run.sh fate-checkasm-alacdsp "" "" "/c/alevinsn/ffmpeg" 'run tests/checkasm/checkasm --test=alacdsp' '' '/dev/null' '' '1' '' '' '' '' '' '' '' ''
[21:38:13 CEST] <alevinsn>  /c/alevinsn/ffmpeg/tests/checkasm/checkasm --test=alacdsp
[21:38:18 CEST] <alevinsn> and from fate.ffmpeg.org
[21:42:21 CEST] <jamrial> it says there you need to specify SAMPLES
[21:42:35 CEST] <nevcairiel> you should probably read over https://www.ffmpeg.org/fate.html
[21:42:51 CEST] <nevcairiel> its a much more complete test if you have samples available
[21:47:43 CEST] <cone-391> ffmpeg 03Paul B Mahol 07master:49255370044c: avcodec/utvideodec: fix gradient prediction when stride does not match width
[21:47:52 CEST] <alevinsn> OK, I did that, and I still get the source check failure
[21:48:03 CEST] <alevinsn> I checked the history of source-check.sh
[21:48:12 CEST] <alevinsn> it was changed 23 days ago to use git grep instead of grep
[21:48:19 CEST] <alevinsn> and if I switch it back to grep in my copy
[21:48:22 CEST] <alevinsn> the issue goes away
[21:48:38 CEST] <nevcairiel> well it works for everyone else, so your git is somehow faulty
[21:48:58 CEST] <alevinsn> I just installed the latest from git-scm.com
[21:49:05 CEST] <alevinsn> and I confirmed that it is using the version that I just installed
[21:52:23 CEST] <alevinsn> what does git --version report for you?
[21:52:48 CEST] <nevcairiel> git version 2.12.2.windows.2
[21:53:01 CEST] <alevinsn> AaronL at AARONL-DELL MSYS /c/alevinsn/ffmpeg
[21:53:01 CEST] <alevinsn> $ git --version
[21:53:01 CEST] <alevinsn> git version 2.12.2.windows.2
[21:53:01 CEST] <alevinsn> AaronL at AARONL-DELL MSYS /c/alevinsn/ffmpeg
[21:53:01 CEST] <alevinsn> $ git grep -L "^#define CMDUTILS_H$" cmdutils.h
[21:53:02 CEST] <alevinsn> cmdutils.h
[21:53:04 CEST] <alevinsn> AaronL at AARONL-DELL MSYS /c/alevinsn/ffmpeg
[21:53:06 CEST] <alevinsn> $ grep -L "^#define CMDUTILS_H$" cmdutils.h
[21:53:36 CEST] <alevinsn> I didn't paste the last line, but it comes up empty when only grep is used
[21:53:45 CEST] <nevcairiel> the git grep line is empty for me
[21:54:02 CEST] <alevinsn> maybe git grep uses some external tool to do that?
[21:54:09 CEST] <alevinsn> and that's what is different for you and me?
[21:54:16 CEST] <nevcairiel> did you checkout your sources with crlf line endings? some parts may be unhappy with that
[21:54:27 CEST] <alevinsn> not sure
[21:54:48 CEST] <alevinsn> git was installed a different way the first time around
[21:58:04 CEST] <alevinsn> has CRLF terminators
[21:59:34 CEST] <alevinsn> shit, that was it
[21:59:37 CEST] <alevinsn> CRLF terminators
[21:59:55 CEST] <alevinsn> The git installer recommends checking out with crlf
[22:00:00 CEST] <alevinsn> and checking in without
[22:00:26 CEST] <nevcairiel> personally I use "input" mode, so that it checks-out "as is" with LF, but if i accidentally use CRLF somewhere it converts to LF on checking
[22:00:27 CEST] <nevcairiel> -g
[22:00:40 CEST] <alevinsn> so, I guess you were right--there was a problem with with my source :-)
[22:01:12 CEST] <nevcairiel> crlf had odd problems in the past with some of the scripts, who knew some more parts got broken
[22:05:48 CEST] <alevinsn> so core.autocrlf is set to input for you?
[22:12:49 CEST] <JEEB> I just disable autocrlf because I hate it
[22:13:21 CEST] <JEEB> you will then have to do some git commands to completely re-instantiate all the files in the repo
[22:17:52 CEST] <alevinsn> I just did find -name '*.h' -type f | xargs dos2unix
[22:18:08 CEST] <alevinsn> although, of course, now it wants to do a fresh build
[22:40:24 CEST] <Chloe> Gramner: does nasm/yasm expand macro arguments under %undef
[22:41:40 CEST] <durandal_1707> do we have/need coloroffset filter?
[22:43:11 CEST] <Chloe> durandal_1707: would that stop you writing it? 
[22:43:35 CEST] <durandal_1707> it might
[22:49:14 CEST] <Chloe> I mean, someone out there might want it. 
[23:06:14 CEST] <durandal_1707> its doable with lut vf
[23:33:45 CEST] <BtbN> I feel like I'll get mails from this every now and then from now on: https://bitbucket.org/a4pdev/ffmpeg/commits/87007ebc168891df777c12b634d612cb80302eaf
[23:39:38 CEST] <llogan> what's a4pdev?
[23:41:30 CEST] <BtbN> Some random account name on bitbucket
[23:41:47 CEST] <BtbN> But since there is @BtbN in the commit message that account just pushed, I get an E-Mail for it.
[23:42:06 CEST] <nevcairiel> in some random commit message? seems like a mis-feature
[23:42:13 CEST] <BtbN> Github does the same
[23:42:29 CEST] <BtbN> Everytime soneone pushes that commit into some repo, I get en E-Mail
[23:42:38 CEST] <nevcairiel> doesnt make it any better
[23:42:52 CEST] <nevcairiel> especially in distributed shit that is  just not useful
[23:43:51 CEST] <llogan> that reminds me...i never setup that github "PR bot" to autoclose PRs.
[23:45:25 CEST] <BtbN> No PR happened since that was discussed
[23:46:52 CEST] <llogan> then again we already have a bot named BtbN.
[23:48:10 CEST] <llogan> what i mean is i think you have closed most of them
[23:49:00 CEST] <BtbN> Yeah, probably. Since I'm able to do so, I also get an E-Mail once someone opens one, so I just go ahead and close them right away.
[00:00:00 CEST] --- Sat Apr 22 2017