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

[burek]

[12:00:36 CET] <BtbN> Hm, I wonder if ffmpeg_cuvid.c can just be removed by now. It looks as generic as it gets.
[15:41:51 CET] <kwizart> Hello, FYI fsf raised a statement on the fdk-aac license (on Fedora/RH request after a patent disabled fdk-aac package was introduced)
[15:41:54 CET] <kwizart> https://www.gnu.org/licenses/license-list.en.html#fdk
[15:42:09 CET] <kwizart> in case you have missed it
[15:43:03 CET] <kwizart> half related, I've recently found this project https://github.com/yugr/Implib.so
[15:43:53 CET] <kwizart> which might allow to dlpen any libraries at runtime (probably once the headers and entries point are added in ffmpeg)
[15:44:09 CET] <kwizart> would it be something appropriate for use in ffmpeg ?
[15:44:25 CET] <kwizart> (for such cases as fdk-aac decklink or else ?)
[15:44:56 CET] <nevcairiel> its questionable this influences the license situation. Some technical mean should not influence how law is interpreted. this is not something ffmpeg s hould consider. if you want to build like that
[15:45:18 CET] <nevcairiel> .. you can do that w ithout ffmpeg knowing about it, its supposed to be transparent
[15:59:14 CET] <kwizart> yep I think it's just a matter to error as appropriate if end-users request the library but it's not available at runtime
[15:59:54 CET] <atomnuker> I wish people would stop trying to find ways to make fdk appear as legal and open source as possible and just use opus
[16:00:18 CET] <kwizart> the question is would ffmpeg source tree would be able to have the generated wrapper code or this have to be a downstream use case ?
[16:02:00 CET] <gnafu> atomnuker: Hear, hear!
[16:03:51 CET] <kwizart> atomnuker, I agree with that too, but the averrage end-user is dumb when it comes to audio codec
[16:04:10 CET] <JEEB> also there's the plastic boxen, although the internal AAC encoder is generally speaking OK
[16:05:01 CET] <j-b> yes
[16:05:09 CET] <j-b> fdk-aac is non-free
[16:05:10 CET] <kwizart> atomnuker, and my problem as a distro maintainer is that some scammer repo still advertise ffmpeg built with fdk-aac without fear breaking "good repos" that tries to avoid such licensing issue
[16:05:13 CET] <j-b> ffaac is good enough
[16:05:19 CET] <j-b> and opus is amazing
[16:05:38 CET] <kwizart> j-b, note quite, it's GPL incompatible as stated by fsf, but it might be floss
[16:05:47 CET] <j-b> it is not.
[16:05:54 CET] <kwizart> (they don't say it's not)
[16:06:09 CET] <kwizart> they say it should be avoided when possible, which is good
[16:06:32 CET] <j-b> "You may not charge copyright license fees for anyone to use, copy or distribute the FDK AAC Codec software or your modifications thereto."
[16:07:13 CET] <JEEB> "This is a free software license as far as it goes. It is incompatible with any version of the GNU GPL." <- whatever this means @ the FSF page
[16:07:21 CET] <JEEB> "as far as it goes"
[16:07:33 CET] <JEEB> that just raises more questions as a wording than anything else
[16:07:50 CET] <kwizart> j-b, I don't see that in the current fdk-aac license at all
[16:10:06 CET] <kwizart> j-b sorry my bad, it's there, but it's not an issue
[16:12:13 CET] <j-b> https://opensource.org/osd
[16:15:25 CET] <jamrial> jkqxz: ticket 7538, libva-x11 pkg-config apparently doesn't pull x11 ldflags and cflags
[16:16:16 CET] <jamrial> while libva needs to fix it upstream, configure should also make vaapi_x11 depend on xlib, so it may include its ldflags
[16:17:41 CET] <kwizart> j-b, maybe ffmpeg/vlc should publish their reading of the fdk-aac license , it would be interesting to compare with the fsf statement wording
[16:18:15 CET] <kwizart> but anyway, thx for all advices and sorry for raising that issue again
[19:02:40 CET] <cone-228> ffmpeg 03Paul B Mahol 07master:975510758cc7: avfilter/avf_showspectrum: improve magma colors
[19:02:41 CET] <cone-228> ffmpeg 03Paul B Mahol 07master:ed58db4237c8: avfilter/avf_showspectrum: add viridis color map
[19:02:42 CET] <cone-228> ffmpeg 03Paul B Mahol 07master:0c6d4e7ba4d7: avfilter/avf_showspectrum: add plasma color map
[20:57:18 CET] <jkqxz> jamrial:  True, but that doesn't appear to be the problem there because it's complaining about libavutil?
[20:57:25 CET] <jkqxz> To get libva_x11 you need to have xlib, and xlib gives you those libraries (<http://git.videolan.org/?p=ffmpeg.git;a=blob;f=configure;h=00b5d9795e0daf5cd1f60aaea1520305f497431c;hb=HEAD#l5899>).
[20:57:29 CET] <jamrial> jkqxz: hwcontext
[20:57:52 CET] <jkqxz> Seems to work fine for me.  --disable-xlib indeed loses the X flags and libva_x11 too.
[20:58:06 CET] <jamrial> nothing is making libavutil depend on (aka, include ldflags from) xlib
[20:58:20 CET] <jamrial> or at least nothing obvious
[21:05:40 CET] <atomnuker> I think we wanted to get rid of specific vaapi backends eventually and just always used a dri device path
[21:06:32 CET] <jkqxz> Getting rid of the X11 backend would be sensible, it's not useful to anyone.
[21:07:24 CET] <jkqxz> Ah, I see.  VDPAU works because it includes -lX11 explicitly in its own flags, and autodetect pulls that in.
[21:07:49 CET] <jkqxz> Whereas VAAPI doesn't have anything making that dependency, and libva-x11 also lacks it.
[21:11:30 CET] <jkqxz> Is <https://0x0.st/sIFj.diff> right?  It seems to work, but I'm not sure how those configure parts interact exactly.
[21:13:00 CET] <jamrial> yeah, that should do it
[22:33:45 CET] <atomnuker> BBB: btw gave up on doing adaptation as a separate function, I'll make the whole decoding function in asm
[22:34:27 CET] <atomnuker> call overhead was almost 2x the overhead for doing the basic full avx2 adaptation
[22:35:43 CET] <atomnuker> with the latest blend avx2 simd decode_symbol_adapt had the most overhead for chimera at 13% the whole decoder
[22:38:24 CET] <BBB> yes I saw that too
[22:38:25 CET] <BBB> ok
[22:39:16 CET] <BBB> this is a good sign btw, now that ec is becoming most runtime
[22:39:19 CET] <BBB> it means we did well :)
[00:00:00 CET] --- Thu Nov  8 2018