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

[burek]

[00:41:58 CEST] <jamrial> nevcairiel: did you have time to check the hevc patches?
[01:14:48 CEST] <cone-273> ffmpeg 03James Almer 07master:14e092448f2e: avformat/concatdec: port to the new bitstream filter API
[01:42:46 CEST] <alevinsn> nevcairiel:  you there?
[02:01:26 CEST] <alevinsn> anyone know why tests/checkasm is built such that it links to FF_STATIC_DEP_LIBS?
[02:01:31 CEST] <alevinsn> instead of FF_DEP_LIBS?
[02:01:44 CEST] <alevinsn> it appears to be the only thing that uses FF_STATIC_DEP_LIBS
[02:03:43 CEST] <J_Darnley> Didn't someone guess the right answer before?
[02:03:51 CEST] <alevinsn> ?
[02:03:55 CEST] <J_Darnley> It needs to call internal functions
[02:04:06 CEST] <alevinsn> ok, that makes sense
[02:04:17 CEST] <alevinsn> still, that doesn't quite explain why it wants .a files
[02:04:18 CEST] <J_Darnley> Perhaps you were offline
[02:04:21 CEST] <alevinsn> instead of .lib files
[02:04:24 CEST] <alevinsn> yeah, i had to leave
[02:04:45 CEST] <alevinsn> I'll check IRC logs
[02:06:56 CEST] <alevinsn> yeah, looks like I missed the final stuff from nevcairiel
[02:45:45 CEST] <alevinsn> currently fate, when an error occurs, appears to just stop running
[02:45:47 CEST] <alevinsn> at least on Linux
[02:45:54 CEST] <alevinsn> is there any way to get it to continue to the next test?
[02:53:41 CEST] <J_Darnley> It's make so the -k option will do it
[02:54:31 CEST] <alevinsn> ah, that makes sense, thanks
[05:27:21 CEST] <cone-761> ffmpeg 03James Almer 07master:c53bf8c9b8ad: configure: fix libopus detection
[07:12:52 CEST] <wm4> philipl_, jkqxz: anything to say about that cuvid patch?
[09:25:54 CEST] <ubitux> what is required to take the reordering out of the h264 decoder?
[09:45:12 CEST] <wm4> lots of tears?
[09:55:36 CEST] <rcombs> ubitux: funny that you ask, I was just talking to jkqxz about that
[09:55:50 CEST] <ubitux> heh :)
[09:55:56 CEST] <rcombs> thinking about A53?
[09:56:01 CEST] <ubitux> no, vda/vt
[09:56:04 CEST] <rcombs> ah
[09:56:17 CEST] <ubitux> i really want to have that async vt decoder in ffmpeg
[09:56:25 CEST] <rcombs> (I had both of those use-cases in mind)
[09:58:47 CEST] <wm4> maybe trying this with hevc first would be easier, but then again I have not the slightest clue
[10:46:12 CEST] <nevcairiel> i doubt thats a realistic thing to be doing
[11:56:59 CEST] <ubitux> nevcairiel: why?
[11:57:31 CEST] <ubitux> it will really help cleaning up that garbage
[11:57:33 CEST] <nevcairiel> because you would basically re-build a h264 decoder without slice decoding
[13:52:24 CEST] <cone-249> ffmpeg 03Michael Niedermayer 07master:390c6ee42c49: tools/target_dec_fuzzer: Fix memleak on open failure
[14:31:52 CEST] <cone-249> ffmpeg 03Michael Niedermayer 07master:92f4a4bf29d7: configure: Do not add omit-frame-pointer for ossfuzz
[16:24:10 CEST] <ubitux> michaelni: you may want to use -Og when available btw
[16:47:08 CEST] <jamrial> ubitux: i looked at the next merge. wtf do we do with raise_major?
[16:48:05 CEST] <jamrial> how do we make the new .version files consider it? it's a configure time only variable
[16:48:53 CEST] <ubitux> yeah i wanted to drop it
[16:49:21 CEST] <ubitux> we can still keep it and pass it as argument
[16:49:26 CEST] <ubitux> to check if it should be enabled or not
[16:50:06 CEST] <ubitux> like, to the script, you pass the $raise_major_enabled var or whatever actual holder
[16:52:39 CEST] <jamrial> libversion.sh is called by make, so configure would need to store raise_major in some way in config.mak or wherever
[16:53:07 CEST] <jamrial> kinda hacky
[16:57:41 CEST] <BBB> for the stupid (me): what is raise_major?
[17:00:31 CEST] <jamrial> a configure option that bumps the libraries' major version by 100
[17:00:51 CEST] <JEEB> ah
[17:01:11 CEST] <BBB> I bet its totally not a hack or anything, right?
[17:01:30 CEST] <jamrial> 99% chances is a hack :p
[17:03:32 CEST] <jamrial> the commit message says it's to allow users to install the just compiled libraries alongside other already installed libraries with the same soname
[17:07:08 CEST] <BBB> but why
[17:07:20 CEST] <BBB> actually, I retract that question
[17:07:25 CEST] <BBB> I dont want to know
[17:07:38 CEST] <BBB> Im just going to continue to statically link so I dont have to re-live dll hell ever in my life
[17:08:18 CEST] <BBB> WhatCouldPossiblyGoWrong[TM]
[17:13:39 CEST] <ubitux> jamrial: don't you have access to that variable in the config.mak?
[17:13:55 CEST] <ubitux> i mean, i'm all for dropping the feature though
[17:13:55 CEST] <ubitux> michaelni: do we still need that raise major hack?
[17:15:49 CEST] <philipl_> wm4: I missed it, but I've found it now. Will look today
[17:18:55 CEST] <cone-249> ffmpeg 03Michael Niedermayer 07master:cabfed6895fc: avcodec/msvideo1: Check buffer size before re-getting the frame
[17:20:27 CEST] <philipl> wm4: so the main point here is that the cuvid decoder can directly access the hw_device_ctx if the client (mpv) sets it first. and so we don't need the half-initialized hw_frames_ctx. Makes sense when I look at it. Do you have the mpv side cleanup somewhere? Does it just remove video/decode/cuda.c?
[17:22:55 CEST] <michaelni> ubitux, i dont remember exactly what it was used for
[17:23:28 CEST] <ubitux> 102b794e09482fec881e7ec903e57914895f9b74
[17:23:39 CEST] <ubitux> > this allows seperate installation of shared libs that should not conflict with whatever is already installed.
[17:24:01 CEST] <ubitux> the SYMVER thing doesn't seem present anymore
[17:24:17 CEST] <ubitux> so it's only a +100 on major
[17:24:54 CEST] <ubitux> note: FF_SYMVER is defined but not used
[17:32:27 CEST] <jamrial> ubitux: oh, you're right, it's there
[17:37:23 CEST] <alevinsn> nevcairiel:  you there?
[17:39:16 CEST] <ubitux> damnit why is ffmpeg, even with --disable-pthreads, no predictible wrt the avio requests over http
[17:39:33 CEST] <nevcairiel> alevinsn: not for long
[17:39:51 CEST] <ubitux> i have a httpd that doesn't seem to like at all ffmpeg requests
[17:40:01 CEST] <ubitux> it leads to fd exhaustion on its 
[17:40:03 CEST] <ubitux> side
[17:40:04 CEST] <alevinsn> k, I saw your messages from yesterday regarding checkasm, disabling checkasm isn't enough to get shared builds FATE runs to work
[17:40:22 CEST] <alevinsn> it later builds options.c (from libavcodec, for example), but in a way that enables some test code
[17:40:24 CEST] <ubitux> are we somehow opening and not closing N connections with ffmpeg for each ranges?
[17:40:26 CEST] <nevcairiel> checkmas is the only thing that doesnt work reliably
[17:40:29 CEST] <alevinsn> and that fails as well
[17:40:39 CEST] <alevinsn> to build
[17:40:44 CEST] <alevinsn> complaining about the same missing symbols
[17:40:54 CEST] <alevinsn> no problem when I do a static build
[17:41:09 CEST] <alevinsn> which is the way the MSVC fate builds are configured to run at fate.ffmpeg.org
[17:41:15 CEST] <alevinsn> so, I gave up and went with that
[17:41:23 CEST] <alevinsn> is this an issue for shared builds on Linux?
[17:41:24 CEST] <nevcairiel> fate has both, shared and static
[17:41:41 CEST] <ubitux> i had to hack something for the shared one iirc
[17:42:06 CEST] <alevinsn> well, it doesn't appear to work on Windows--as I indicated, disabling checkasm in tests/Makefile isn't sufficient
[17:42:12 CEST] <alevinsn> more needs to be done
[17:42:27 CEST] <ubitux> fate/configs/enable-shared.cfg:extra_ldflags="-Wl,-rpath=libpostproc:libswresample:libswscale:libavfilter:libavdevice:libavformat:libavcodec:libavutil:libavresample"
[17:42:30 CEST] <alevinsn> since it tries to do a static-like build for options.c, and possibly other stuff
[17:42:47 CEST] <ubitux> i don't remember why i need this
[17:43:25 CEST] <alevinsn> ubitux:  I guess that's for Linux, right?
[17:43:26 CEST] <alevinsn> gcc
[17:43:26 CEST] <nevcairiel> the alternative to that is to install the libraries into a path where the linker finds them
[17:43:30 CEST] <ubitux> alevinsn: yes
[17:43:35 CEST] <alevinsn> oh
[17:43:42 CEST] <alevinsn> so, alter LIB environment variable
[17:44:08 CEST] <alevinsn> it wants .a versions of libraries though
[17:44:36 CEST] <alevinsn> when a dynamic build is done
[17:44:36 CEST] <nevcairiel> i dont see anything special for the options tool, it only uses public stuff as far as I can see and has no special link instructions
[17:45:27 CEST] <alevinsn> unfortunately, I don't have the output log anymore
[17:45:32 CEST] <alevinsn> but, it should be easily reproduced
[17:49:08 CEST] <nevcairiel> its not really all that important either way, as long as the main fate tests all work, those special test tools are mostly just  nonsense to increase coverage
[17:49:32 CEST] <alevinsn> so, if I use make -k, I can get past those failures?
[17:49:49 CEST] <nevcairiel> presumably
[17:49:58 CEST] <nevcairiel> the fate stations on fate.ffmpeg.org manage to do it  =p
[17:50:39 CEST] <alevinsn> it might be nice if those used make V=1 or V=2 fate
[17:51:06 CEST] <nevcairiel> way too much spam for no use
[17:51:37 CEST] <alevinsn> I had hoped to see that output so that I could compare my compilation lines to the ones done by the "official FATE system"
[17:51:41 CEST] <nevcairiel> the configure commands are shown there, nothing else is otherwise hidden anywhere
[17:52:00 CEST] <alevinsn> if there were some way to log V=1,V=2 separate;y
[17:52:05 CEST] <alevinsn> or at the same time as V=0
[17:52:11 CEST] <alevinsn> that would be awesome
[17:52:52 CEST] <nevcairiel> i still dont see why
[17:52:59 CEST] <nevcairiel> those dont o ffer any useful info
[17:53:25 CEST] <alevinsn> well, for example, I wanted to see if it was trying to find .a files
[17:53:34 CEST] <alevinsn> when linking
[17:53:41 CEST] <alevinsn> and compare it to my link line, when it was failing
[17:54:15 CEST] <nevcairiel> clearly you can see from the log that it also fails making the checkasm test for similar reasons
[17:54:22 CEST] <nevcairiel> in the shared config
[17:54:48 CEST] <alevinsn> hmm, I didn't notice that there were shared runs on fate.ffmpeg.org
[17:54:52 CEST] <alevinsn> but I guess I missed that
[17:56:01 CEST] <alevinsn> yeah, I see that
[17:56:10 CEST] <alevinsn> but, there are also differences
[17:56:24 CEST] <alevinsn> it complained about -lm not working much earlier for my log for some reason
[17:56:48 CEST] <nevcairiel> the order is not deterministic since it uses parallel make
[17:58:14 CEST] <mdavis> For my own amusement/education, I was thinking of writing Codec2 support into FFmpeg. Should I do it "right" in case anyone's interested?
[17:58:14 CEST] <alevinsn> options.exe failed for the same reason I see now
[17:58:20 CEST] <alevinsn> in the shared build at
[17:58:24 CEST] <alevinsn> http://fate.ffmpeg.org/log.cgi?time=20170503202843&log=test&slot=x86_32-msvc14-dll-md-windows-native
[17:58:32 CEST] <alevinsn> just search for __imp
[17:58:35 CEST] <nevcairiel> (ie. make -j3 for  most of my fate boxes, since its a resource limited VM)
[17:59:35 CEST] <alevinsn> ok, this is all making sense--I should add some information to fate.texi for shared builds
[18:00:08 CEST] <nevcairiel> shared setups are way different everywhere, it should just be discouraged for fate testing
[18:00:24 CEST] <jamrial> michaelni: regarding repeated calls to av_realloc for cases where the final size of the array is known beforehand, do you think i should revert b438a7868c and 9f102653fd?
[18:00:50 CEST] <jamrial> michaelni: have either of those changes affected any of these fuzz cases you're trying to fix?
[18:01:27 CEST] <nevcairiel> anyhow time to leave
[18:01:38 CEST] <alevinsn> thanks
[18:02:18 CEST] <alevinsn> jamrial:  for multi-patch patch sets, what's the best way for someone to review
[18:02:29 CEST] <alevinsn> such that the previous patch, once reviewed
[18:02:33 CEST] <alevinsn> doesn't appear in the diff anymore?
[18:02:43 CEST] <alevinsn> besides committing it personally
[18:02:51 CEST] <alevinsn> so, I review patch 1
[18:02:58 CEST] <alevinsn> then apply patch 2 (or something like that)
[18:03:08 CEST] <alevinsn> and the patch 1 changes don't show up anymore
[18:03:16 CEST] <alevinsn> in my review tool, diff tool, etc
[18:04:01 CEST] <alevinsn> question for anyone, really
[18:16:03 CEST] <nevcairiel> Use a proper git client to read the diffs or just review on the ML if possible
[18:32:21 CEST] <michaelni> jamrial, the ossfuzz fuzzer doesnt use ffmpeg.c so nothing in it can affect it
[18:32:49 CEST] <jamrial> michaelni: ok
[18:32:54 CEST] <michaelni> a testcase that uses ffmpeg.c could be added of course
[18:37:56 CEST] <nevcairiel> Wasn't the reason for the slowdown the memory analyzer and not just an inherent slowness
[19:48:52 CEST] <cone-249> ffmpeg 03Michael Niedermayer 07master:a0296fc056f0: avcodec/pngdec: Use ff_set_dimensions()
[20:06:42 CEST] <cone-249> ffmpeg 03Michael Niedermayer 07master:c1c3a14073b3: libavcodec/mpeg4videodec: Convert sprite_offset to 64bit
[20:06:44 CEST] <cone-249> ffmpeg 03Michael Niedermayer 07master:d2657d225c14: avcodec/flicvideo: Check for chunk overread
[20:21:29 CEST] <Dresk|Dev> Apologies for asking a usage question in the dev channel, figured hopefully it would not agitate the natives too much, but my question is : with 3.3 regarding Android - does this version provider hardware decoding with the result being a texture, as opposed to an overlay?
[20:28:37 CEST] <Compn> with which android hwaccel interface, Dresk|Dev ?
[20:28:52 CEST] <Compn> omx? stagefright? something else
[20:31:28 CEST] <JEEB> mediacodec is now a thing in lavc
[20:32:01 CEST] <JEEB> it either outputs a normal avframe and I think there might be a texture output as well (a "hwaccel"), but I haven't utilized it
[20:32:14 CEST] <JEEB> since the mediacodec decoder is "fast enough" for me in general
[20:32:54 CEST] <Dresk|Dev> Compn: I'm not certain which interface - I was seeing if ffmpeg "handled" going through MediaCodec API on its own or something
[20:33:15 CEST] <Dresk|Dev> Compn: We purely use ffmpeg and don't use any Android code at all in our engine currently
[20:34:25 CEST] <Dresk|Dev> JEEB: We're software decoding 4K videos and no SoC right now can do it (we've tried Snappy 821, 830, Exynos 8890, Tegra K1 and Tegra X1)
[20:35:03 CEST] <JEEB> well, d'uh
[20:35:04 CEST] <JEEB> ARM
[20:36:04 CEST] <JEEB> also UHD sounds about where you probably would want direct rendering instead of possible memcpy. not sure how that works with opengl on android
[20:38:15 CEST] <Dresk|Dev> Hm, one moment, discussing with my fellow developers about understanding these changes (I'm the dumbest one of the bunch, hehe)
[20:40:26 CEST] <Dresk|Dev> JEEB / Compn : I deeply appreciate your help by the way, I could conceive how ffmpeg is not always the most joyous of projects to work on
[20:43:36 CEST] <Dresk|Dev> JEEB: Is there anything that needs to be done to get that accelerated codec by default? Right now we just call avcodec_find_decoder with the result of the codec_id in the stream, then copy the codec context and build a decoder context from that - is that behavior going to "get us" the mediacodec so calls to avcodec_decode_video2 (in our case) go through it?
[20:44:42 CEST] <Compn> oh wow 4k on android ?
[20:46:22 CEST] <JEEB> you would have to make sure you are using the mediacodec -prefixed decoder
[20:46:27 CEST] <Dresk|Dev> Compn: Yes sir, that is our goal
[20:46:50 CEST] <JEEB> if you log things you should see if the decoder is h264 or mediacodec_h264 for example
[20:56:08 CEST] <durandal_1707> atomnuker: trying to get uniform partitioned convolution to work, i get frequency spikes each time  of  one full IR samples block size
[20:57:40 CEST] <durandal_1707> with this filter ffmpeg could do reverb, ambiophonics and much more
[21:00:05 CEST] <cone-249> ffmpeg 03Michael Niedermayer 07master:fc4f88375b8a: avcodec/wavpack: Fix invalid shift and integer overflow
[21:00:06 CEST] <cone-249> ffmpeg 03Michael Niedermayer 07master:a78ae465fda9: avcodec/mjpegdec: Fix runtime error: signed integer overflow: -24543 * 2031616 cannot be represented in type 'int'
[21:39:20 CEST] <philipl> wm4: You have your ship-it
[22:05:59 CEST] <durandal_1707> atomnuker: shit, using 1,0,0,0.....as IR i get perfect output
[23:02:09 CEST] <wm4> philipl: yes, the mpv side of the change pretty much drops cuda.c and does not set hw_frames_ctx in the get_format callback
[23:06:24 CEST] <philipl> wm4: jolly good.
[23:18:52 CEST] <cone-249> ffmpeg 03Carl Eugen Hoyos 07master:3624d45ddbe9: compat/strtod: Add missing const qualifiers.
[23:22:27 CEST] <jamrial> ubitux: check https://github.com/jamrial/FFmpeg/commits/mergework whenever you can
[23:23:48 CEST] <jamrial> merged two commits at once, plus cherry picked changes from another two that fix regressions introduced by the merged ones
[23:24:56 CEST] <jamrial> tried it and both raise major build suffix seem to work (shared build or not), but i'd prefer if you can look at it and test it some
[23:27:01 CEST] <ubitux> +DESC = Libav container format library
[23:27:04 CEST] <ubitux> this one is wrong ^
[23:27:06 CEST] <ubitux> (lavf)
[23:27:54 CEST] <jamrial> oops
[23:28:14 CEST] <jamrial> fixed locally :p
[23:28:56 CEST] <ubitux> did you check if an out of tree build still work?
[23:28:57 CEST] <jamrial> ubitux: had to remove the include config.mak from every library Makefile
[23:29:15 CEST] <ubitux> i think one of the main thing we have different is that "src" dir from the build dir
[23:29:29 CEST] <ubitux> which may need special care (not sure if it makes a difference here)
[23:31:27 CEST] <jamrial> ah, symlink right? didn't, try on linux
[23:34:56 CEST] <ubitux> /bin/sh: /home/ux/src/ffmpeg/ffbuild/libversion.sh: Permission denied
[23:35:10 CEST] <ubitux> /bin/sh: /home/ux/src/ffmpeg/ffbuild/pkgconfig_generate.sh: Permission denied
[23:35:30 CEST] <jamrial> do you know what line?
[23:35:59 CEST] <ubitux> it's missing a chmod +x
[23:36:09 CEST] <ubitux> on both scripts
[23:36:41 CEST] <jamrial> right
[23:37:30 CEST] <ubitux> Requires: libavcodec >= , libswresample >= , libavutil >=
[23:37:39 CEST] <ubitux> these look broken in the installed .pc
[23:38:52 CEST] <jamrial> odd, it creates them fine here
[23:39:16 CEST] <ubitux> .version files are empty, is this normal/unrelated?
[23:41:21 CEST] <jamrial> they should be filled
[23:41:35 CEST] <jamrial> did you add +x to the scripts and tried from a clean state?
[23:41:55 CEST] <ubitux> let me retry from a clean state
[23:42:01 CEST] <ubitux> that might be the issue
[23:42:30 CEST] <jamrial> force pushed a version with the scripts fixed, hopefully
[23:43:43 CEST] <ubitux> seems to work yeah
[23:46:22 CEST] <ubitux> just trying one last thing and i guess it's good
[23:49:04 CEST] <ubitux> jamrial: are you sure the Libs.private is correctly set in shared build?
[23:49:12 CEST] <ubitux> (in the .pc file)
[23:51:30 CEST] <ubitux> btw, not sure if that's on purpose but libdir and includedir don't seem to rely on ${prefix} anymore
[23:51:38 CEST] <ubitux> it's expanded
[23:52:19 CEST] <jamrial> probably because it's printed from configure to config.sh, then to pkgconfig_generate.sh
[23:52:31 CEST] <jamrial> it shows up with ${prefix} in config-sh
[23:52:43 CEST] <jamrial> and afaik libs.private is the same as pre merge
[23:53:05 CEST] <ubitux> mmh, strange
[23:53:14 CEST] <jamrial> let me check again
[23:53:55 CEST] <ubitux> compare with --enable-shared
[23:54:28 CEST] <alevinsn> when running FATE on Windows, the diff is failing for me in some cases because of whitespace
[23:54:45 CEST] <alevinsn> newline characters apparently in the generated output
[23:55:05 CEST] <alevinsn> anyone know if there is a way I should be setting things up to prevent that?
[23:55:31 CEST] <BtbN> probably git putting windows line endings into things
[23:55:59 CEST] <alevinsn> no, I have that turned off
[23:57:03 CEST] <alevinsn> crap, I guess it didn't fix that for some of the files
[23:57:22 CEST] <alevinsn> I thought I had addressed that
[23:57:55 CEST] <nevcairiel> easiest is just to delete everything but the .git dir and let git restore everything
[23:59:45 CEST] <alevinsn> I had read that I could use git checkout-index --force --all
[23:59:53 CEST] <alevinsn> to fix that
[00:00:00 CEST] <alevinsn> but it doesn't seem to have worked in all cases
[00:00:00 CEST] --- Fri May  5 2017