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

[burek]

[01:28:52 CEST] <atomnuker> its fine, if its license is alright we can ctrl+c/v
[01:56:00 CEST] <atomnuker> I'm surprised you didn't figure it out, if the decoder is 2 clause bsd then there can't be any lgpl in there
[04:09:13 CEST] <atomnuker> its deader than usual all across irc today
[04:15:14 CEST] <jamrial> can't say i agree. i'm not in a lot of channels myself, but i've seen days where not a word was said outside of build/bug bots
[04:23:29 CEST] <BBB> atomnuker: yes, license will be 2 clause bsd
[04:31:40 CEST] <jamrial> that's gpl compatible, isn't it? how could it not use lgpl code?
[04:44:47 CEST] <BBB> jamrial: he means the other way around
[04:44:51 CEST] <BBB> lgpl code can use bsd code
[04:44:55 CEST] <BBB> bsd code cannot use lgpl code
[04:45:00 CEST] <BBB> since that turns it into lgpl code
[04:47:27 CEST] <BBB> j-b: probably should get ltrudeau in here also, he wrote the LR code
[04:48:10 CEST] <atomnuker> linear regression?
[10:36:15 CEST] <cone-551> ffmpeg 03Paul B Mahol 07master:bb16a0624a2f: avutil: add float_dsp.vector_dmul
[10:36:15 CEST] <cone-551> ffmpeg 03Paul B Mahol 07master:ecf38be7c7f5: avfilter: add amultiply audio filter
[11:23:13 CEST] <cone-551> ffmpeg 03Paul B Mahol 07master:544fde1bf827: avfilter: add bm3d filter
[11:29:12 CEST] <cone-551> ffmpeg 03Paul B Mahol 07master:0ac937f80dd8: configure: bm3d filter depends on dct in avcodec
[11:42:19 CEST] <BradleyS> ^ nice
[12:19:34 CEST] <cone-551> ffmpeg 03Paul B Mahol 07master:776cdd1dc8e1: avfilter/vf_remap: refactor code
[13:58:58 CEST] <durandal_1707> libaom-av1 actually uses threads when?
[14:00:22 CEST] <BBB> tiling
[14:00:29 CEST] <BBB> -tile-columms
[14:00:32 CEST] <BBB> and maybe -tile-rows also
[14:21:10 CEST] <durandal_1707> it drops frames badly, cant keep it
[14:28:50 CEST] <durandal_1707> it is year 2018, and people still use SVN version of FFmpeg
[14:59:50 CEST] <BBB> drops frames badly?
[14:59:52 CEST] <BBB> what does that mean
[15:37:20 CEST] <durandal_1707> BBB: slower than realtime
[15:37:38 CEST] <BBB> . o O ( :-o )
[16:34:05 CEST] <atomnuker> if you're on arch keep in mind they compile their libaom without asm optimizations
[16:45:32 CEST] <JEEB> :D
[16:45:35 CEST] <JEEB> wonderful
[16:51:39 CEST] <nevcairiel> ...why?
[17:09:13 CEST] <jamrial> are you talking decoding or encoding?
[17:09:39 CEST] <jamrial> because to get multithreading encoding with our wrapper we need jkqxz's tile support patch first
[17:10:07 CEST] <durandal_1707> decoding is slow, and uses 1 cpu only
[17:10:52 CEST] <jamrial> yeah, don't think we can get multithreading decoding with our wrapper
[18:15:38 CEST] <nevcairiel> jamrial: it does thread, but not very well, i get maybe 3 cores worth of load on my 10c/20t cpu
[18:16:18 CEST] <jamrial> nevcairiel: ah, but not done by libavcodec in any case
[18:16:31 CEST] <nevcairiel> of course not, external things have to do their own threading
[18:23:13 CEST] <jamrial> oh, libaom has the same thing as libvpx where threads == 0 means 1 instead of max
[18:23:48 CEST] <JEEB> of course :D
[18:27:17 CEST] <jamrial> there, patch in the ml
[18:30:44 CEST] <JEEB> sinec libvpxdec doesn't do it, does the libvpx/aom documentation note the max thread count at 16?
[18:31:19 CEST] <jamrial> i don't know where the 16 comes from, tbh
[18:32:04 CEST] <jamrial> also, the 0 == 1 is in the encoder doxy. the decoder doxy doesn't say anything about it, but seems to behave the same
[18:32:32 CEST] <JEEB> also my eyes seem to be bad, I see the FFMIN in libvpx there too
[18:32:35 CEST] <JEEB> will post lgtm
[18:32:40 CEST] <nevcairiel> https://aomedia.googlesource.com/aom/+/master/aom_util/aom_thread.h#28
[18:32:42 CEST] <nevcairiel> all i know is that
[18:32:44 CEST] <nevcairiel> and its not 16
[18:32:45 CEST] <nevcairiel> :D
[18:33:10 CEST] <jamrial> hah
[18:33:17 CEST] <jamrial> want me to change it to 8 before pushing?
[18:33:19 CEST] <JEEB> roflcopter bbq
[18:33:42 CEST] <JEEB> you could switch it to 8 but that's an internal value anyways...
[18:33:47 CEST] <JEEB> they might change it at any point :P
[18:34:18 CEST] <JEEB> wonder if we could get that value from vpx/aom's API?
[18:34:18 CEST] <jamrial> yeah, would be nice to have that define in a public header
[18:39:54 CEST] <nevcairiel> only now i noticed they have a win32 thread wrapper, but stupid cmake doesnt give you an option to actually switch off pthread and prefer win32 instead
[18:41:34 CEST] <durandal_1707> is_avc option in h264 decoder is not enabled because it is missing flags
[18:45:26 CEST] <cone-499> ffmpeg 03James Almer 07master:309c3a0e81be: avcodec/libaom: fix setting amount of threads
[18:46:04 CEST] <jamrial> pity the guy handling the mpc-hc fork already tagged the first release with libaom earlier today
[19:11:16 CEST] <kurosu> I guess everyone (browsers included) will switch to dav1d once a release has usable API
[19:12:21 CEST] <kurosu> I wonder if it will have reimplemented frame threading, or use the tile one
[19:13:22 CEST] <jamrial> the former at first, afaik
[19:14:35 CEST] <jamrial> did google adopt ffvp9 in chromium, or are they still using libvpx?
[19:14:44 CEST] <atomnuker> nope, libvpx
[19:14:49 CEST] <jamrial> i know firefox switched to ffvp9 long ago
[19:14:52 CEST] <jamrial> figures
[19:14:53 CEST] <kurosu> ok, sad that energy+stuff had to be spent to reinvent that particular wheel
[19:14:58 CEST] <atomnuker> I doubt they'll change to using non-libaom decoder
[19:14:59 CEST] <jamrial> so guess the same will happen with dav1d
[19:15:16 CEST] <durandal_1707> dav1d is irrelevant
[19:15:26 CEST] <atomnuker> they were apparently... resistant to the idea of not improving libaom despite having more money than jesus to do it themselves
[19:15:28 CEST] <JEEB> basically chromium now has some limit on new deps and since they already have libvpx approved I don't think they'll try to get vp9 from FFmpeg
[19:16:23 CEST] <jamrial> they use ffmpeg for other stuff, so how hard is to also do --enable-decoder=vp9? :p
[19:16:43 CEST] <JEEB> (´4@)
[19:17:14 CEST] <kurosu> atomnuker, depending on the contract terms, I guess they are more confident in having something they have control over and follows various internal guidelines
[19:17:30 CEST] <kurosu> though, indeed, it looks like another waste
[19:18:05 CEST] <kurosu> anyway I hope jesus would spent his money on something else
[19:18:12 CEST] <kurosu> like swscale rewrite maybe ? :D
[19:19:49 CEST] <atomnuker> in hindsight I should have said bezos, I doubt someone with over a million could be an icon of any religion except scientology
[19:20:24 CEST] <JEEB> &25
[19:21:45 CEST] <kurosu> God^Xogle works in mysterious ways
[19:29:41 CEST] <nevcairiel> jamrial: pity because of that commit specifically? that wont matter for mpc-hc, it doesnt set it to zero
[19:30:19 CEST] <jamrial> oh neat, i figured it'd set threads to 0/auto
[19:30:58 CEST] <jamrial> in any case doesn't matter. just tried and none of my av1 samples worked :p
[19:31:31 CEST] <nevcairiel> i just downloaded one from youtube and it played fine for me,  but granted i didnt try with mpc-hcs built-in decoders
[19:31:32 CEST] <jamrial> i reported it to him, assuming it's an issue with the mpc-hc hooks with lavfilters, and not lavfilters itself
[19:32:45 CEST] <nevcairiel> someone else reported that a mkv created with youtube-dl when downloading both audio and video with av1 crashed for him, not sure why that would ever happen
[19:33:00 CEST] <nevcairiel> apparently youtube-dl uses ffmpeg to mux the video+audio
[19:33:04 CEST] <nevcairiel> do we even write mkvs yet
[19:33:04 CEST] <jamrial> yeah
[19:33:12 CEST] <jamrial> to both
[19:37:13 CEST] <jamrial> tried it and doesn't crash for me
[19:39:37 CEST] <jamrial> https://www.youtube.com/playlist?list=PLyqf6gJt7KuHBmeVzZteZUlNUQAVLwrZS neat
[19:42:12 CEST] <nevcairiel> yeah the playlist is nice
[19:56:18 CEST] <jamrial> all the streams report "av01.0.05M.08" for some reason, even if 5 is not the seq_level_idx value in the seq header obu
[20:43:17 CEST] <durandal_1707> it looks like IMM5 codec is some bastardization of old ffmpeg code and its h264 decoder, there are ffmpeg comments all over place in binary
[20:50:10 CEST] <cone-499> ffmpeg 03Paul B Mahol 07master:e320f9576a4d: avfilter/vf_bm3d: use av_clip_uintp2_c where clip is variable
[23:09:52 CEST] <durandal_1707> is there any binary hex editor for linux?
[23:11:26 CEST] <TheAMM> vim and those two commands
[23:13:52 CEST] <durandal_1707> TheAMM: i want to remove bytes, so this vim with xxd can not work