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

[burek]

[00:14:07 CEST] <michaelni> BBB, libavcodec/libavcodec.a(vp9dsp_init_16bpp.o): In function `ff_vp9dsp_init_16bpp_x86': mingw32/src/libavcodec/x86/vp9dsp_init_16bpp.c:144: undefined reference to `ff_vp9_ipred_dr_32x32_16_avx2'
[00:14:25 CEST] <BBB> maybe forgot to mark it as 64bit only?
[00:14:36 CEST] <BBB> like, put an #if ARCH_X86_64 around it in the init file
[00:14:56 CEST] <michaelni> just this one or more ?
[00:15:04 CEST] <michaelni> it seems this was the only not linking
[00:15:50 CEST] <BBB> I think just this one
[00:15:59 CEST] <michaelni> ok, will test and then push
[00:16:01 CEST] <BBB> sorry, shouldve picked that up during review
[00:16:02 CEST] <BBB> ty
[00:22:07 CEST] <cone-161> ffmpeg 03Hendrik Leppkes 07master:15b00aea418b: hwcontext_d3d11va: use correct license header
[00:25:17 CEST] <wm4> eh
[00:25:58 CEST] <atomnuker> ubitux: there's some aarch64 asm I removed in 4fdacf4c which seems like it can be reused (the fft15 asm), can you give it a go
[00:26:43 CEST] <atomnuker> tried but I don't understand what it tries to do
[00:27:08 CEST] <atomnuker> and I saw some conditional stuff so I'm not sure how good it is
[00:32:05 CEST] <cone-161> ffmpeg 03Michael Niedermayer 07master:516c213f089d: avcodec/x86/vp9dsp_init_16bpp: Fix linking to missing ff_vp9_ipred_dr_32x32_16_avx2() on 32bit
[01:46:34 CEST] <cone-161> ffmpeg 03James Almer 07master:d2ef9e6e7f9e: x86/vf_blend: use ABS2 macro
[08:24:52 CEST] <ubitux> atomnuker: i guess i should
[08:24:55 CEST] <ubitux> atomnuker: speaking of this
[08:24:57 CEST] <ubitux> https://trac.ffmpeg.org/ticket/3921
[08:25:02 CEST] <ubitux> did you see that ticket?
[08:25:37 CEST] <ubitux> it's not that much used anymore though since most code was switched to fft
[08:25:50 CEST] <ubitux> (but it was because of speed reason afaik)
[11:13:56 CEST] <wm4> jkqxz: I think LongChair is confused about how to proceed now
[11:14:07 CEST] <LongChair> i am :)
[11:15:37 CEST] <LongChair> I understand that we need to make sure that the API would fit other API as well, problem is that i don't have a good overview of "other" APIs, so was somehow wishing jkqxz and wm4 could come up with the proper structs & API agreement, so that i can arrange that to my specific hwdec :)
[11:16:28 CEST] <jkqxz> There were no replies to emails, unfortunately.
[11:18:00 CEST] <wm4> I mean yes, you did post a patch for a DRM hwcontext proposal
[11:19:27 CEST] <jkqxz> So, go ahead with that proposal?
[11:36:24 CEST] <wm4> jkqxz: posted a small comment on the Libav one, but it's just my old boring obsession with the representation of the plane descriptions
[11:49:48 CEST] <jkqxz> Does that actually work for all cases?  The planes must be in the order they are in the sw_format.
[11:50:21 CEST] <wm4> I mean then the contents would change, not the indexes
[11:53:10 CEST] <jkqxz> I'm not quite sure what you mean by "the contents"?
[11:53:41 CEST] <wm4> NV12 will always have the luma plane as first, and the chroma as second, right?
[11:54:07 CEST] <JEEB> wm4: yes that's how it should be
[11:54:11 CEST] <jkqxz> In libav*, yes, because that's how we define the pixfmt.
[11:54:27 CEST] <nevcairiel> its not "we" that defined that format =p
[11:54:28 CEST] <wm4> and the index fields would allow to shuffle this around, as far as the description goes
[11:54:28 CEST] <jkqxz> But when the two planes are separate objects they aren't ordered in any sense.
[11:55:32 CEST] <jkqxz> And there is no XYZ format (in that order) with three planes, where someone could have two objects XZ and Y?
[11:55:54 CEST] <jkqxz> That would be insanity, but that doesn't mean it doesn't exist.
[11:56:12 CEST] <nevcairiel> just because it exists doesnt mean we have to support it =p
[11:56:19 CEST] <wm4> I guess I see what you mean
[11:57:28 CEST] <wm4> (if someone invents a YUVA format that has interleaved YA and UV planes I might have to punch this someone)
[11:57:30 CEST] <jkqxz> In fact, the pixfmt here doesn't enforce that data[0] < data[1] for NV12 anyway.  (And line-interleaved YUV420P works too...)
[11:58:35 CEST] <wm4> LongChair: do you think the current proposed representation is easy to work with? (you have to set it up from rockchip and then push it into both EGL and DRM APIs)
[11:59:37 CEST] <LongChair> which one is the current one ? (sorry there has been several discussions, and i'm not sure whcih oen we are talking about)
[12:00:01 CEST] <wm4> jkqxz's DRM patch on the ML
[12:05:22 CEST] <LongChair> @wm4 : lemme check
[12:05:59 CEST] <jkqxz> Enforce this constraint?  planes[i].object_index < planes[i+1].object_index || (planes[i].object_index == planes[i+1].object_index && planes[i].offset < planes[i+1].offset)
[12:06:13 CEST] <jkqxz> (Therefore, you must put the object descriptors in the right order.)
[12:07:39 CEST] <wm4> not sure if I can fully parse it... but yes maybe
[12:12:10 CEST] <LongChair> @wm4: i just checked ML don't see any answer from mark on my patch other than old ones. are we talking about another patch he submitted , :)
[12:13:17 CEST] <jkqxz> <http://ffmpeg.org/pipermail/ffmpeg-devel/2017-June/212546.html>
[12:13:19 CEST] <wm4> yes he submitted it as separate patch
[12:15:20 CEST] <LongChair> ok reading
[12:19:48 CEST] <LongChair> ok i think rk stuff would fit in there 
[12:21:05 CEST] <LongChair> I will grab this patch and start working with it 
[12:21:47 CEST] <LongChair> jkqxz: for some reason i didn't see it in my mail. Sorry for not replying to this before :)
[12:23:16 CEST] <LongChair> wm4: i'll try to also make a generic drmprime-egl & drmprime-drm opengl-hwdec-interops for mpv . will need to review it when i'm done to make sure i'm not overlooking some "other" things :)
[12:27:02 CEST] <jkqxz> The one in ffmpeg should be usable standalone with something like "ffmpeg -c:v h264_rkmpp -i in.264 -vf 'format=drm_prime,hwdownload,format=nv12' -c:v libx264 out.264" (though probably rather slow).
[12:29:19 CEST] <cone-946> ffmpeg 03Clément BSsch 07master:e4a27e2f2dea: lavc/arm: fix lack of precision in ff_ps_stereo_interpolate_neon
[12:29:20 CEST] <cone-946> ffmpeg 03Clément BSsch 07master:edd041e64c0b: checkasm: add AAC PS tests
[12:29:21 CEST] <cone-946> ffmpeg 03Clément BSsch 07master:9bbb0fbd314c: lavc/aacpsdsp: fix a few spaces (cosmetics)
[12:29:22 CEST] <cone-946> ffmpeg 03Clément BSsch 07master:ff0ecef624e9: lavc/aarch64: add a few SIMD functions for AAC PS
[12:29:23 CEST] <cone-946> ffmpeg 03Clément BSsch 07master:b12a36170b13: lavc/aacpsdsp: use ptrdiff_t for stride in hybrid_analysis
[13:05:42 CEST] <atomnuker> ubitux: actually might be a better idea to port the x86 asm over to aarch64, I'm pretty sure it'll be faster, but oh well, if you got the time
[13:05:54 CEST] <atomnuker> that bug ticket doesn't seem valid to me though
[13:06:30 CEST] <ubitux> why?
[13:09:06 CEST] <atomnuker> it works around uncomfortable twiddles in the asm rather than to modify the twiddles themselves
[13:09:39 CEST] <ubitux> no i mean, why the ticket seems invalid?
[13:13:20 CEST] <atomnuker> I don't get what its complaining about, that we're only slightly slower than fftw3?
[13:15:40 CEST] <ubitux> atomnuker: http://kojevnikov.com/static/images/fft-bench-results.png
[13:15:46 CEST] <ubitux> there is no asm for our code
[13:16:30 CEST] <LongChair1> jkqxz: i tried to gran the patch from mailing list and apply that locally on master, but doesn't seem to apply. could you gist me the patch please ? 
[13:16:35 CEST] <LongChair1> grab*
[13:17:05 CEST] <atomnuker> ubitux: there isn't? holy shit
[13:26:04 CEST] <durandal_1707> is there anything simdable in fft?
[13:28:10 CEST] <durandal_1707> michaelni: fine to  apply your utvideo patchset?
[14:05:51 CEST] <jkqxz> LongChair1:  Hmm, it collides with wm4's d3d11 changes.
[14:08:29 CEST] <jkqxz> Rebased (but not tested): <http://ixia.jkqxz.net/~mrt/ffmpeg/drm/0001-lavu-Add-DRM-hwcontext.patch>.
[14:10:20 CEST] <cone-946> ffmpeg 03Michael Niedermayer 07master:1835c5e7a4fd: avcodec/utvideodec: Move bitstream end check out of inner loop
[14:10:21 CEST] <cone-946> ffmpeg 03Michael Niedermayer 07master:9c604b34d435: avcodec/utvideodec: hardcode vlc bits
[14:10:22 CEST] <cone-946> ffmpeg 03Michael Niedermayer 07master:676a589c936b: avcodec/utvideodec: enable unchecked bitreader
[14:10:23 CEST] <cone-946> ffmpeg 03Michael Niedermayer 07master:5eb4701b7d64: avcodec/utvideodec: bswap directly without memcpy
[14:10:24 CEST] <cone-946> ffmpeg 03Michael Niedermayer 07master:850c6db97d1f: avcodec/utvideodec: Factor multiply out of inner loop
[14:19:47 CEST] <kierank> http://obe.tv/about-us/obe-blog/item/45-optimising-and-modernising-ffmpeg-s-idct-part-1
[14:20:50 CEST] <kierank> can someone add that to HN
[14:20:55 CEST] <kierank> my account is on noslack
[14:22:15 CEST] <ubitux> kierank: https://news.ycombinator.com/item?id=14653459
[14:22:26 CEST] <kierank> thanks!
[14:23:18 CEST] <LongChair> jkqxz: thanks, will try it tonite :)
[14:41:21 CEST] <cbsrobot> kierank: in your post, the last character in the link to http://www.inf.puc-rio.br/~roberto/lpeg/) should be removed
[14:41:32 CEST] <kierank> thanks
[14:56:45 CEST] <durandal_170> kierank: why do you not make more full timed ffmpeg devs?
[14:57:22 CEST] <kierank> durandal_170: because we have non-ffmpeg stuff to do
[14:57:28 CEST] <kierank> J_Darnley: https://www.reddit.com/r/programming/comments/6k07as/optimising_and_modernising_ffmpegs_idct_part_1/
[14:57:32 CEST] <kierank> maybe you want to answer that
[15:01:27 CEST] <wm4> lol is that really the first post
[15:01:32 CEST] <J_Darnley> Oh many reasons but mostly because I thinkt they are shit.
[15:01:32 CEST] <iive> Is that article written by J_Darnley ? I don't see name attached to it.
[15:02:27 CEST] <kierank> wm4: it's very fashionable to use intrinsics
[15:02:55 CEST] <J_Darnley> Top of my list of why I hate them: about 6 different functions for movd
[15:03:45 CEST] <nevcairiel> the magic of intrinsics: you dont even need functions for that, you can just assign a variable to make it generate that! :D
[15:05:13 CEST] <nevcairiel> the main reason against intrinsics is that you're still at the mercy of the compiler, and for many algorithms it really isnt even significantly easier to write either, since the worst you need are some loops
[15:05:40 CEST] <durandal_170> divisions
[15:06:02 CEST] <iive> well, intrinsics are not so bad, for as long as you have 1:1 transition of code to assembly.
[15:07:04 CEST] <durandal_170> they are bad. period.
[15:07:34 CEST] <wbs> I was surprised once to notice that clang/llvm actually is pretty good at intrinsics; there's an odd mpegvideo function that somebody from linaro ported to aarch64 by making an intrinsics version (pretty much based on the arm assembler); I tried making a 1:1 port of the arm assembly to aarch64 and compare that to the intrinsics; for gcc, the handwritten assembly was faster, but clang/llvm managed to 
[15:07:40 CEST] <wbs> make the intrinsics even faster than that
[15:08:55 CEST] <nevcairiel> as long as you write only intrinsics and only use C as little as required for contorl flow etc, msvc also generates the expected assembly instructions directly, but if you start mixing more C in there, it gets weird fast
[15:09:13 CEST] Action: durandal_170 gonna push prores patches
[15:10:23 CEST] <J_Darnley> As far as I can tell, you suggest I just write "mm1 = pmaddwd(mm1, mm2)" and that is somehow better than assembly?
[15:10:38 CEST] <ubitux> so i opened libavutil/cpu.c
[15:10:40 CEST] <ubitux> and now i'm sad
[15:11:19 CEST] <iive> well, every time somebody talks about intrinsics, in my memory i see the disassembly of intrinsic code compiled with non SIMD ops. just regular assembly....
[15:11:20 CEST] <kierank> why
[15:12:05 CEST] <ubitux> almost duplicated options
[15:13:12 CEST] <TMM> In my uses of intrinsics it usually works pretty well. You just have to be very careful about what you do with the special datatypes
[15:13:34 CEST] <TMM> as soon as you do anything with the variables that's outside of the scope of the intrinsic you're using you're going to get a disaster 
[15:13:47 CEST] <TMM> ridiculous amount of copying,packing,unpacking etc
[15:13:54 CEST] <J_Darnley> Perhaps one of you people can demonstate how I can use constants from memory?
[15:31:21 CEST] <kierank> J_Darnley: are you going to reply
[15:37:17 CEST] <J_Darnley> No.  I don't have a reddit account for it is horrible censorious place
[15:40:09 CEST] <iive> J_Darnley: you dare to oppose the hivemind?! ;)
[15:41:40 CEST] <kierank> ok i will answer
[15:54:17 CEST] <kierank> BBB: http://obe.tv/about-us/obe-blog/item/45-optimising-and-modernising-ffmpeg-s-idct-part-1
[15:54:19 CEST] <kierank> james wrote that
[15:54:24 CEST] <BBB> woohoo
[15:54:27 CEST] <BBB> is it committed?
[15:54:33 CEST] <BBB> please talk about this @ vdd
[15:54:37 CEST] <BBB> its important that we talk about shit
[15:54:46 CEST] <kierank> part 1 is just the conversion, part 2 and 3 will be the sse
[16:06:09 CEST] <BBB> when will part 2 be written?
[16:06:16 CEST] <BBB> or better: when will it be pushed? :-p
[16:07:18 CEST] <kierank> dunno
[16:07:20 CEST] <kierank> ask J_Darnley 
[16:14:14 CEST] <J_Darnley> Ha.  I should probably get on that.  I'm bored of this vc2 transform stuff.  I wish to become bored of mpeg2 transform stuff again.
[16:14:39 CEST] <BBB> hm...?
[16:14:44 CEST] <BBB> whats so bad about the vc2 transform?
[16:14:51 CEST] <BBB> isnt vc2 dirac-intra?
[16:15:05 CEST] <kierank> J_Darnley: i thought all the mpeg2 stuff was fixed now?
[16:15:08 CEST] <kierank> by you and ronald?
[16:15:17 CEST] <BBB> yes but he needs to actually push it
[16:15:18 CEST] <J_Darnley> It is. I just need to rebase and push, I think
[16:15:22 CEST] <BBB> and thats scary
[16:15:23 CEST] <kierank> J_Darnley: then do it!
[16:15:27 CEST] <kierank> ah
[16:15:37 CEST] <BBB> because when you push it, ffmpeg will suddenly be free of evil mmx code in your runtime
[16:15:39 CEST] <BBB> just imagine that
[16:15:48 CEST] <J_Darnley> pfft
[16:15:52 CEST] <BBB> :-p
[16:15:55 CEST] <J_Darnley> I bet it is still there somewhere
[16:16:12 CEST] <BBB> I believe dequant/quant is still mmx, yes
[16:21:29 CEST] <wm4> I wonder if we could remove the self-modifying mmx code from libswscale, that is somehow hacked into the common part with OS specific further hacks
[16:21:43 CEST] <wm4> and which is only used for a non-default scaler that is known as broken
[16:21:48 CEST] <wm4> (can't make that shit up)
[16:22:16 CEST] <iive> i thought it is used for the default scaler and is the fastest one.
[16:23:01 CEST] <BBB> the fast_bilinear one?
[16:23:15 CEST] <BBB> I tried to remove or rewrite it once, and couldnt do it
[16:23:17 CEST] <wm4> yes
[16:23:18 CEST] <BBB> I wouldnt spend time on it
[16:23:26 CEST] <BBB> not worth it
[16:23:43 CEST] <iive> what do you mean by that you couldn't do it?
[16:23:56 CEST] <iive> you couldn't write static version of similar speed?
[16:52:43 CEST] <cone-946> ffmpeg 03Vittorio Giovara 07master:3426832ac307: hevc: Add support for alternative transfer characterics SEI
[17:02:23 CEST] <cone-946> ffmpeg 03Paul B Mahol 07master:42f516b5d356: avcodec/interplayvideo: check that video_size is >0
[17:16:16 CEST] <cone-946> ffmpeg 03Paul B Mahol 07master:613ccdaaacaa: avcodec/interplayvideo: use int16_t instead of short
[17:16:17 CEST] <cone-946> ffmpeg 03Paul B Mahol 07master:ed782bebf508: avcodec/interplayvideo: fix dead-lock
[17:19:32 CEST] <cone-946> ffmpeg 03Paul B Mahol 07master:c1d1274bfc56: avcodec/interplayvideo: return void
[17:20:08 CEST] <kierank> can anyone upvote this https://www.reddit.com/r/programming/comments/6k07as/optimising_and_modernising_ffmpegs_idct_part_1/
[17:29:08 CEST] <wm4> didn't BBB have good explanations on why intrinsics are not the way to go for ffmpeg
[17:33:25 CEST] <BBB> our documentation has some text about it
[17:33:43 CEST] <BBB> I have played with intrinsics a few times and never found it quite ideal
[17:33:57 CEST] <BBB> the performance is never quite what you can get manually
[17:34:03 CEST] <BBB> its easier
[17:34:15 CEST] <BBB> so the question is one between effort or performance
[17:36:00 CEST] <atomnuker> not just effort or performance, one's likelier to give you alzheimer's later in life than the other
[17:36:14 CEST] <Gramner> nasm preprocessor is much, much better than the c preprocessor is a pretty big deal. also if you want to use modern instruction sets it's usually a lot easier to upgrade the assembler than to upgrade the compiler
[17:36:50 CEST] <BBB> preprocessor is a good reason for bigger, more complex functions, yes
[17:37:07 CEST] <BBB> writing a 32x32 idct in intrinsics sounds hideous
[17:37:43 CEST] <Gramner> also the compiler might not even support new instruction sets at all. msvc still doesn't support avx-512 iirc
[17:37:58 CEST] <J_Darnley> That's not saying much
[17:41:00 CEST] <atomnuker> J_Darnley: hey, you still use windows, don't insult the only compiler for your os
[17:41:04 CEST] <cone-946> ffmpeg 03James Darnley 07master:8b19467d07d5: avcodec/x86: allow future 8-bit simple idct to have "DC only hack"
[17:41:05 CEST] <cone-946> ffmpeg 03James Darnley 07master:d7246ea9f229: avcodec/x86: add an 8-bit simple IDCT function based on the x86-64 high depth functions
[17:41:06 CEST] <cone-946> ffmpeg 03James Darnley 07master:0c2acccd4be4: avcodec/x86: use new x86-64 functions for -idct simple
[17:41:17 CEST] <kierank> OMG
[17:41:22 CEST] <J_Darnley> At long last
[17:41:25 CEST] <Gramner> I also never understood why they insist on renaming every instruction in instrinsics. makes it harder to parse for no good reason
[17:54:01 CEST] <gh0st__> Hm, libvpx seems to prefer intrinsics over manually writing assembly.
[17:56:22 CEST] <nevcairiel> the only real reason for intrinsics is that its "easier", you dont need fancy build-system support, you can use C for control flow, etc
[17:56:56 CEST] <BBB> so
[17:57:18 CEST] <BBB> example number: libvpx sse2 idct32x32 is 3619.8 cycles (intrinsics), ours is 2563.6 cycles (assembly)
[17:57:40 CEST] <BBB> they do exactly identical operations, except that libvpx doesnt zero the coefficients and the input is not pre-transposed
[17:57:46 CEST] <nevcairiel> that doesnt really say that much, you would probably need to use the exact same code in both variants
[17:58:00 CEST] <BBB> I plugged them both in our checkasm
[17:58:43 CEST] <BBB> I cant find their avx2 version :-/
[17:59:14 CEST] <BBB> it looks like they dont have one
[19:39:50 CEST] <cone-946> ffmpeg 03Paul B Mahol 07master:f0edab6e63ec: avcodec/interplayvideo: use correct context when checking for enough bytes
[21:37:02 CEST] <durandal_170> atomnuker: report?
[21:38:15 CEST] <atomnuker> buggered, easiest way would be to have 2 readers with the same api
[21:41:55 CEST] <ubitux> you're looking at the bitstream reader?
[21:42:58 CEST] <atomnuker> I looked at it last night
[21:43:24 CEST] <atomnuker> got some work done on coverting the api
[21:44:23 CEST] <durandal_170> just add flag cache 64 bit something
[21:44:46 CEST] <durandal_170> like there is for unchecked bitreader
[21:47:16 CEST] <atomnuker> I think replacing it is better
[21:48:19 CEST] <iive> just write one that is faster on 32 bit and much faster on 64
[21:50:19 CEST] <atomnuker> iive: are you on a 32 bit system?
[21:50:43 CEST] <iive> i have a cpu that can run 32 bit :D
[21:51:53 CEST] <atomnuker> makes me wonder if there's a system which can't run in 32 bit mode
[21:52:34 CEST] <BBB> most arm machines are 32bit
[21:52:36 CEST] <J_Darnley> arm?  powerpc?  itanium?
[21:53:42 CEST] <atomnuker> OH CRAP, I FORGOT
[21:54:09 CEST] <BBB> J_Darnley: btw, WOOHOO!
[21:54:11 CEST] <BBB> beer
[21:54:24 CEST] <J_Darnley> Indeed
[21:54:57 CEST] <J_Darnley> Though I wonder whether there is an x86 chip that somehow avoids needing <64 bit for booting
[21:56:16 CEST] <BBB> I did not expect to ever get rid of some of that inline asm code
[21:56:20 CEST] <BBB> very happy it went down
[21:57:23 CEST] <J_Darnley> It certainly uncovered a lot of bugs elsewhere in the code.
[22:18:17 CEST] <kwizart> what is the current situation if one enable fdk-aac with gpl and publicly redistribute such binary ?
[22:18:30 CEST] <JEEB> the fdk-aac license isn't compatible with GPL
[22:18:33 CEST] <JEEB> still nonfree
[22:18:41 CEST] <JEEB> thus if you don't need HE-AAC then just use the internal encoder
[22:18:52 CEST] <kwizart> is this something bad, but tolerated ? or will you ask the person to stop redistributing the binaries ?
[22:18:53 CEST] <JEEB> it has been updated in late 2015-early 2016
[22:19:21 CEST] <JEEB> please don't distribute them, and people have scolded companies that have done it
[22:20:40 CEST] <kwizart> okay, I don't plan, myslef, but there is a person doing so
[22:21:01 CEST] <kwizart> and it's breaking ours users
[22:21:40 CEST] <BtbN> doesn't --enable-gpl also allow fdk, without nonfree?
[22:21:47 CEST] <JEEB> no
[22:22:15 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=configure;h=282114d2688c3134d61c50b5a8384da37a29234a;hb=HEAD#l1507
[22:22:15 CEST] <BtbN> JEEB, https://github.com/FFmpeg/FFmpeg/blob/master/configure#L3605 yes
[22:22:55 CEST] <kwizart> well, one can build a lgpl binary that has fdk-aac enabled  ? or I am wrong ?
[22:23:03 CEST] <BtbN> yes, looks like it
[22:24:05 CEST] <RiCON> same thing with openssl
[22:24:21 CEST] <BtbN> It's questionable, pretty sure the fdk thing is lgpl incompatible as well
[22:25:57 CEST] <JEEB> I think with LGPL the primary point moves to "are you compliant with fdk-aac's license?"
[22:26:30 CEST] <BtbN> It's not a very restrictive license
[22:26:46 CEST] <BtbN> just a bit weird, and thus making it incompatible
[22:27:02 CEST] <kwizart> BtbN, my lawer say fdk-aac is lgpl period, but he's a little extremist. I would rather listen what you think "as ffmpeg projet"
[22:28:13 CEST] <JEEB> it's similar in the vein that you have to give the sources to the library to binary recepient
[22:28:29 CEST] <JEEB> but it has all sorts of funky things in there
[22:30:20 CEST] <kwizart> about usage ? probably, but as soon as code copyrights apply this is lgpl. The others points 'license' as soon as you don't consider them as copyrights don't stand up
[22:30:56 CEST] <kwizart> well, he made a rather quick analysis, so I wouldn't trust him either
[22:31:20 CEST] <JEEB> anyways, I'm just happy the internal AAC encoder got improved
[22:42:14 CEST] <kierank> kwizart: it's not
[22:42:19 CEST] <kierank> it forces you to get a patent licence
[22:42:26 CEST] <kierank> which is an additional requirement
[22:55:12 CEST] <tmm1_> mateo`: have you looked into using getOutputImage() instead of getOutputBuffer() for mediacodec_wrap_sw_buffer()
[22:58:20 CEST] <kwizart> kierank, yes this is my understanding also , and that we are in the good side not linking our ffmpeg built with fdk-aac
[22:58:37 CEST] <tmm1_> n/m i misread the docs, reading from Image would be the same thing
[22:58:45 CEST] <kwizart> thx for the answear, and sorry for bringing this topic here
[22:59:02 CEST] <kwizart> FYI, the issue behind is way more complex:
[23:00:14 CEST] <kwizart> The Fedora Councils want to allows others 3rd part repositories is the release media (not enabled by default)
[23:01:23 CEST] <kwizart> one if it's repositories is hold by a person who produce incompatible package with our RPM Fusion project (rpmfusion.org) such as a ffmpeg built with fdk-aac
[23:04:15 CEST] <wm4> I still wonder why we haven't removed fdk-aac
[23:04:47 CEST] <BtbN> Because it's the best he-aac encoder.
[23:05:20 CEST] <wm4> but why should it be in ffmpeg
[23:05:34 CEST] <BtbN> why shouldn't it?
[23:05:40 CEST] <wm4> if they don't want to make it (L)GPL compatible we should tell them to fuck off
[23:06:02 CEST] <BtbN> I don't see the problem, there are plenty non-free libraries that can be used by ffmpeg
[23:06:04 CEST] <nevcairiel> they dont care,  they made the encoder for android, its the community that extracted the sources from the android sources and packaged it
[23:06:12 CEST] <nevcairiel> because its high quality
[23:06:29 CEST] <wm4> BtbN: only openssl and (weirdly) decklink
[23:06:40 CEST] <BtbN> and various nvidia stuff
[23:06:53 CEST] <wm4> that's not non-free
[23:07:04 CEST] <BtbN> npp and scale_cuda is
[23:07:14 CEST] <wm4> well they're not in the nonfree list anyway
[23:07:20 CEST] <RiCON> they used to be
[23:07:23 CEST] <nevcairiel> there is a separate list for hwaccel things
[23:07:24 CEST] <BtbN> They are in the hwaccel_nonfree list
[23:07:39 CEST] <RiCON> until BtbN (im)ported the headers
[23:07:47 CEST] <BtbN> Not all of them
[23:08:01 CEST] <BtbN> So there's parts left that still need the actual non-free parts
[23:08:05 CEST] <wm4> so cuda has both free and nonfree support?
[23:08:21 CEST] <BtbN> indeed
[23:08:25 CEST] <RiCON> cuvid and nvenc are free, libnpp and cuda-based filters aren«t
[23:08:31 CEST] <wm4> libnpp is also another thing where we should actually not enable nvidia's bullshit
[23:08:49 CEST] <wm4> just tell people to buy intel if they really want to do hw transcoding
[23:08:50 CEST] <BtbN> I actually think libnpp should be removed, now that there's scale_cuda
[23:09:12 CEST] <BtbN> it's a mess anyway, most of the algorithms it advertises do nothing
[23:09:18 CEST] <RiCON> npp is actually obsoleted by scale_cuda, but isn't scale_cuda also non-free?
[23:09:24 CEST] <BtbN> it is
[23:09:34 CEST] <BtbN> But at least it's not as messy
[23:10:19 CEST] <RiCON> i remember libnpp needing cuda sdk installed to both compile and run
[23:10:22 CEST] <RiCON> scale_cuda too?
[23:10:33 CEST] <wm4> meanwhile I feel sorry for the libturing guy
[23:10:45 CEST] <wm4> went through all of our bullshit to cosmetically perfectionalize his patch
[23:11:06 CEST] <wm4> maybe I should just apply the patch
[23:11:34 CEST] <atomnuker> yet they did not go through any bullshit to make an API
[23:11:43 CEST] <atomnuker> they haven't got one still...
[23:12:15 CEST] <iive> what is libturing?
[23:12:29 CEST] <atomnuker> and its worse than x265 without any hope it'll be better
[23:12:30 CEST] <nevcairiel> it has a similar api to how we use libx264 or libx265, it parses string commands, i dont see why everyoen makes such a fuzz about that
[23:19:41 CEST] <iive> wm4: go ahead and commit it.
[23:20:51 CEST] <BtbN> I still don't get the whole point of libturing in itself
[23:21:10 CEST] <RiCON> another competitor to x265
[23:21:13 CEST] <RiCON> like kvazaar
[23:23:50 CEST] <iive> x265 does need more competition.
[23:25:14 CEST] <atomnuker> it won't improve
[23:25:50 CEST] <iive> turing or x265 ?
[23:26:01 CEST] <atomnuker> either, its not developed by neckbeards living in their parents basements
[23:26:11 CEST] <j-b> +1
[23:26:32 CEST] <iive> how about kvazaar?
[23:28:15 CEST] <atomnuker> it looked better on paper, though they used hm, the reference encoder as a reference
[23:28:41 CEST] <jkqxz> The libturing people threw more stuff over the wall a month ago: <https://github.com/bbc/turingcodec/commit/09a838c9feeb43ac410391e300b8b53ff660c721>.  Open development ftw!
[23:31:07 CEST] <wm4> that looks like a code drop
[23:32:00 CEST] <wm4> git merge --squash or something
[23:32:18 CEST] <BtbN> Or some dev having no clue about git
[23:32:24 CEST] <BtbN> and commiting once every half year
[23:41:53 CEST] <cone-658> ffmpeg 03Michael Niedermayer 07master:bc6ab72bc7af: avcodec/vb: Check vertical GMC component before multiply
[23:41:54 CEST] <cone-658> ffmpeg 03Michael Niedermayer 07master:c709f009dad2: avcodec/cfhd: Fix invalid left shift of negative value
[23:49:01 CEST] <jkqxz> LongChair:  Do I need a funny version of the Rockchip stuff?  MPP_DEC_GET_FREE_PACKET_SLOT_COUNT doesn't exist in the one I have, nor does it appear to be present in the current git version.
[23:50:46 CEST] <jkqxz> (And Google finds it only in your patch on the ffmpeg list...)
[00:00:00 CEST] --- Thu Jun 29 2017