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

Sat Feb 8 03:05:04 EET 2020

[10:33:47 CET] <durandal_1707> Lynne: looks like i need that configure patch after all
[11:09:50 CET] <cone-559> ffmpeg 03Thilo Borgmann 07master:2ca14d84eefd: lavd/avfoundation.m: Add an option to drop late frames.
[11:19:22 CET] <ffmpeguser> Ffmpeg ideas page seems empty for gsoc2020?
[11:19:46 CET] <durandal_1707> press reload
[11:21:15 CET] <ffmpeguser> I can see only 1 idea in the list
[11:21:31 CET] <durandal_1707> yes, do you have own idea?
[11:22:18 CET] <ffmpeguser> Not sure, what are the criteria for selection of ideas? 
[11:22:53 CET] <durandal_1707> that idea is not out of scope of project
[11:23:14 CET] <durandal_1707> like writing GUI for text editor
[11:24:10 CET] <ffmpeguser> Is there gui version of ffmpeg? 
[11:24:29 CET] <durandal_1707> only bad attempts
[11:31:31 CET] <thardin> handbrake maybe
[11:40:27 CET] <durandal_1707> perfect multiband dynamic normalizer: "acrossover=150[b][t];[b]dynaudnorm=m=100:b=1[b];[b][t]amix"
[12:13:59 CET] <cone-648> ffmpeg 03Paul B Mahol 07master:cd671ea08351: avfilter/af_acrossover: add slice threading support
[12:13:59 CET] <cone-648> ffmpeg 03Paul B Mahol 07master:7e8721e98e91: avfilter/af_acrossover: free all output frames on error
[12:26:00 CET] <durandal_1707> why it takes so long to post results of ffmpeg-meeting?
[12:36:08 CET] <cone-648> ffmpeg 03Andreas Rheinhardt 07master:0f0f2ab0c3b3: avcodec/cavsdsp: Fix undefined left shifts of negative numbers
[16:08:06 CET] <Lynne> does anyone have a 960 sample aac file thats not latm and not hevc?
[16:08:19 CET] <Lynne> err, he-aac
[16:26:09 CET] <kierank> afaik dab+ is he-aac
[16:26:14 CET] <kierank> so maybe they have reference samples
[16:28:10 CET] <jamrial> Lynne: maybe https://0x0.st/iieW.m4a
[16:44:25 CET] <Lynne> jamrial: no, its he-aac but signalled as aac-lc in the container
[17:02:26 CET] <durandal_1707> why it takes so long to post results of ffmpeg-meeting?
[17:06:36 CET] <Lynne> nothing was decided, only to start new votes to elect memebers is all
[17:10:20 CET] <cone-426> ffmpeg 03Paul B Mahol 07master:ae5a43530036: avfilter: add afirsrc filter
[17:13:49 CET] <durandal_1707> so nobody have ideas for GSOC this year?
[17:14:24 CET] <durandal_1707> Lynne: are you against my configure patch that fixes linking order?
[17:18:10 CET] <thilo> durandal_1707: porting more filters to vulcan as a project
[17:19:02 CET] <durandal_1707> ok, who will be mentor for that one?
[17:21:33 CET] <Lynne> durandal_1707: no, just haven't seen it on the ml
[17:21:45 CET] <thilo> none yet, proposed to Lynne - but many could mentor that
[17:23:34 CET] <Lynne> durandal_1707: saw it, lgtm, just push it
[17:23:57 CET] <durandal_1707> ok, thanks!
[17:24:25 CET] <Lynne> (I don't think glslang devs know what linking order is, or even what linking is, since you must link to pthreads even though its not in ldflags)
[17:25:44 CET] <cone-426> ffmpeg 03Paul B Mahol 07master:2b61c908b1a1: configure: fix order of linking for libglslang
[17:37:34 CET] <cone-426> ffmpeg 03Anton Khirnov 07master:af1f1e866541: ac3enc: drop a global variable
[17:51:51 CET] <mindfreeze> Hi,
[17:51:51 CET] <mindfreeze> Is having AVIF into FFmpeg solid enough for a summer of code work ? (https://trac.ffmpeg.org/ticket/7621)
[17:52:45 CET] <durandal_1707> isnt that thing for dav1d?
[17:55:27 CET] <Lynne> as long as carl doesn't mentor it again and somehow external API users use the new API
[17:56:37 CET] <mindfreeze> durandal_1707: AFAIK, AVIF is a image format from AV1 with better quality trade-off, 
[17:56:37 CET] <mindfreeze> https://aomediacodec.github.io/av1-avif/
[17:56:37 CET] <mindfreeze> So I was wondering, like to have support to have avif into ffmepg, so there would be some better use-cases like this 
[17:57:05 CET] <durandal_1707> mind you there is no native decoder for av1 in ffmpeg
[17:57:56 CET] <kierank> Oh no what a shame
[17:59:02 CET] <j-b> Seeing that soon dav1d will have more asm than the whole libavcodec...
[17:59:09 CET] <durandal_1707> haha
[17:59:34 CET] <j-b> Not a joke.
[17:59:48 CET] <durandal_1707> it is funny little project
[18:00:18 CET] <j-b> 54633   x86             asm=41795,ansic=12838
[18:00:25 CET] <j-b> 27819   arm             asm=24752,ansic=3067
[18:00:32 CET] <j-b> 14107   aarch64         asm=12719,ansic=1388
[18:01:16 CET] <j-b> that's 80k of asm
[18:01:50 CET] <rcombs> is there more duplication or something
[18:02:01 CET] <durandal_1707> new quant computers will make all that obsolete
[18:07:27 CET] <rcombs> just as soon as we figure out how to decompress video by factoring large integers
[18:08:14 CET] <j-b> rcombs: I don't think so.
[18:09:21 CET] <Gramner> rcombs: not a lot of duplication, no. in fact a lot of effort is spent trying to minimize binary size
[18:09:25 CET] <j-b> dav1d is currently at 66k of asm
[18:10:02 CET] <rcombs> does AV1 have more routines that are well-suited to asm than most codecs, or something? or is the project just really willing to write asm for more complex branching or non-leaf routines where lavc tends to stick to C?
[18:10:35 CET] <Gramner> each new generation of codecs will have more features than the previous one, which means more DSP code to write
[18:11:12 CET] <Gramner> it's also more optimized than most libavcodec stuff
[18:11:41 CET] <rcombs> mm, impressive
[18:16:25 CET] <durandal_1707> how much time it takes to build dav1d with nasm 2.15-rc0 ?
[18:16:36 CET] <durandal_1707> it takes eternity here
[18:18:01 CET] <Gramner> 11 seconds for me
[18:18:12 CET] <durandal_1707> with same nasm version?
[18:18:26 CET] <durandal_1707> it passed more than minute here
[18:18:41 CET] <Gramner> that was with 2.14
[18:19:29 CET] <durandal_1707> it unbuildable with rc15
[18:21:07 CET] <JEEB> reminds me of yasm having a small hash map with x264
[18:21:12 CET] <JEEB> so
[18:21:30 CET] <JEEB> i would recommend posting your results to nasm project
[18:21:41 CET] <JEEB> since it seems like a perf regression?
[18:22:03 CET] <Gramner> just tried git master of nasm, works fine
[18:22:37 CET] <jamrial> latest snapshot seems to take a long time to compile dav1d, yeah
[18:22:40 CET] <jamrial> https://www.nasm.us/pub/nasm/snapshots/latest/
[18:23:00 CET] <Gramner> no difference in compilation time of git master vs 2.14 for me
[18:23:02 CET] <jamrial> from October 2019, though
[18:23:23 CET] <Gramner> last nasm commit was in october 2019 so
[18:23:32 CET] <jamrial> also a crapload of warnings from -w+macro-params-multi
[18:24:45 CET] <Gramner> huh. no warnings here (on linux)
[18:24:49 CET] <jamrial> Gramner: tried their precompiled win64 binary. dunno what durandal_1707 used
[18:26:57 CET] <jamrial> Gramner: https://pastebin.com/raw/pPDRj5f2
[18:27:05 CET] <jamrial> fails on msac.asm, then freezes with cdef.asm
[18:27:27 CET] <jamrial> probably not imporant until an actual rc is released, though
[18:27:35 CET] <Gramner> I guess they broke windows
[18:27:48 CET] <Gramner> note that historically nasm rc versions have had a lot of bugs
[18:28:34 CET] <Gramner> I'm guessing the devs doesn't use windows so breaking that probably goes unnoticed for a while
[18:29:44 CET] <nevcairiel> i wonder if nasm+msvc can build ffmpeg yet properly, it produced some object file that the msvc linker doesnt like in some situations
[18:30:58 CET] <durandal_1707> NASM version 2.14.03rc2 compiled on Feb  7 2020
[18:31:02 CET] <durandal_1707> that one works
[18:31:17 CET] <durandal_1707> lates 2.15 rc does not, ubuntu
[18:32:10 CET] <durandal_1707> huh, but this 2.14 nasm version segv when building ffmpeg asm code
[18:35:49 CET] <durandal_1707> this NASM is piece of shit
[18:36:06 CET] <Gramner> just use a release version instead of rc:s
[18:38:11 CET] <durandal_1707> ok
[18:38:45 CET] <Gramner> 2.14.02 is the latest, and I think that should be good on linux/windows/macos
[18:41:52 CET] <durandal_1707> yes
[18:49:14 CET] <wbs> jamrial: is 1/3 of the fdk-aac settings tweak (and the updated 2/3) ok?
[18:53:42 CET] <wbs> rcombs: re dav1d asm, there's just sooo many dsp functions, and so many variants of them. and for itx, there's 4x4 up to 64x64, with rectangular forms for all shapes with aspects 2:1, 4:1, 1:2, 1:4, and all transforms up to 16x16 come in combinations of {dct, adst, flipadst, idenity} as both horizontal and vertical transforms for all transform sizes up to 16x16
[18:54:07 CET] <rcombs> wow
[18:54:17 CET] <jamrial> wbs: isn't 1/3 what the avctx->delay field is for?
[18:54:21 CET] <rcombs> guess the variants aren't that macroize-able?
[18:54:44 CET] <durandal_1707> assembly <<<<< rust
[18:55:18 CET] <Gramner> partially macroizable
[18:56:19 CET] <wbs> rcombs: they can share a reasonable amount of code (like just having one idct4, iadst4, flipadst4, identity4, idct8, ... and so on, and separate skeletons for each shape - but it's still a metric shitton of code
[18:56:28 CET] <rcombs> mmm
[18:56:43 CET] <wbs> rcombs: checkasm lists 433 different tested functions
[18:57:02 CET] <wbs> and then there'll be 433 new cases for 10 bit
[18:57:03 CET] <Gramner> also the avx2 ones macroizes less due to doing multiple lines per register for narrow sizes
[18:57:07 CET] <wbs> :-(
[18:58:07 CET] <wbs> jamrial: hmm, I'll have to check what it does - does some framework level code apply it on the timestamps?
[19:02:12 CET] <jamrial> wbs: apparently it's to discard samples before the first valid one, so i'm not sure
[19:17:39 CET] <Lynne> yeah, one thing which I don't like about av1 is how you can have different transforms for w/h of a block
[19:18:50 CET] <Lynne> its so incredibly niche, most don't keep coefficients in a purely frequency domain and the signalling costs aren't cheap
[19:19:21 CET] <Lynne> then you feed the not-entirely-frequency-domain coeffs into a zigzag which doesn't really adapt at all and you get a mess
[19:21:06 CET] <Lynne> oh, and the qcoeff encoding process relies on knowing and minimizing the last non-zero coeff, which is only valid for when your coeffs are in a normal pure dct domain
[19:24:14 CET] <Lynne> the quantization is still a scalar div so it feels like every single coding tool keeps the div quantization on life support
[19:26:07 CET] <Lynne> it gets better though, the coefficient coder is kinda nerfed partly because of political reasons so it uses miniature CDFs
[19:27:27 CET] <Lynne> I'm betting it will be replaced by something different in av2 which will use bigger cdfs, then you'll see why an avx2 adapt16 was needed
[19:27:43 CET] <Gramner> that part is weird, yes
[19:27:55 CET] <Lynne> speaking of that, I still disagree with having 3 separate decoding functions for differently sized CDFs
[19:28:08 CET] <Lynne> just have 1 and have branches
[19:28:09 CET] <Gramner> e.g. the hi_tok decoding. "let's do a bunch of width-4 entropy decode steps in a loop"
[19:28:20 CET] <Gramner> instead of just doing them all at once in parallel
[19:28:53 CET] <Lynne> before google conceded lvmap coded entirely boolean symbols
[19:29:15 CET] <Lynne> and even when they did concede cisco did the work to use the multisymbol coder
[19:29:45 CET] <Lynne> I think a reason why they conceded was because coding a tree of booleans is kinda sorta what cabac does
[19:30:46 CET] <Gramner> uh, why would you want to have a bunch of extra branches at run time for things that are known at compile time?
[19:31:36 CET] <Gramner> in a function that's called billions of times
[19:34:33 CET] <Lynne> you actually don't, you can have just 1 version of the function
[19:34:50 CET] <Lynne> saves binary space too and removes around 200 lines of asm
[19:36:11 CET] <Lynne> and being called billions of times means that you'll keep the instructions of the function in the instruction cache for longer
[19:36:53 CET] <cone-426> ffmpeg 03Paul B Mahol 07master:bfdd6304fbd4: avfilter/af_crystalizer: add slice threading support
[19:37:56 CET] <Lynne> I mean look at the benchmark, the difference between adapt4, adapt8 and adapt16 (avx2) is minimal
[19:38:19 CET] <Lynne> 0.2 decicycles for adapt8 <- adapt16_avx2
[19:38:32 CET] <Lynne> for 1<<22 runs
[19:45:54 CET] <Gramner> the main reason for having multiple sizes it that the load/store sizes are different. you can't just replace a call to the size-4 function with one to size-16. also the binary size of those functions are absolutely tiny (<100 bytes for size-8)
[19:48:04 CET] <Lynne> you can just make all CDFs 32 bytes
[19:49:24 CET] <Gramner> which wastes an order of magniture more cache then what you save from eliminating a small bit of code
[19:52:24 CET] <Gramner> actually more like >2 orders of magnitude
[19:52:41 CET] <Gramner> if not even 3
[19:52:43 CET] <Lynne> yeah, but you don't really keep CDFs around for long in memory
[19:54:44 CET] <Lynne> and its not like you waste that much space, the CDF sizes are already somewhat aligned to the nearest 64 bits for adapt4 and 128bits for adapt8
[20:08:28 CET] <wbs> jamrial: yeah, doesn't look like avctx->delay's documentation matches this case
[20:11:56 CET] <kurosu> hey, hardcore entropy coding discussions in my #ffmpeg-devel? too many channels to keep up with
[20:20:43 CET] <Lynne> speaking of that stuff the uncompressed header should have been entropy coded with fixed probabilities
[20:22:08 CET] <Lynne> and no trailing bits, mandatory zero bits or anything of that
[20:22:28 CET] <kurosu> a bit harder to parse, maybe? though I don't have the details in mind, so I may be mistaken
[20:22:36 CET] <kurosu> as long as the important stuff comes first
[20:26:18 CET] <Lynne> they just didn't want people to have to implement 10 lines of EC decoding code to parse the header
[21:22:33 CET] <darkapex> would a flif encoder/decoder make a good gsoc project? also using libflif v/s native lavc implementation?
[21:23:01 CET] <darkapex> i would like to mentor it as well if it seems useful
[21:23:41 CET] <durandal_1707> i do not think flif is stable?
[21:24:32 CET] <darkapex> hmm yeah just saw. v0.3 hmm
[21:47:17 CET] <thilo> could be added as experimental until stable is reached
[21:48:44 CET] <Lynne> we generally don't have experimental decoders
[21:54:39 CET] <thilo> AFAICT they called their v0.2 from 2016 "stable" already... "The latest stable version is FLIF16 and is documented here."
[21:57:50 CET] <darkapex> yeah i was going through their spec and it looks ok https://flif.info/spec.html . but the reference decoder/encoder don't seem that great.
[21:58:51 CET] <thilo> then it might be even more worth doing and maybe push the format
[22:01:08 CET] <darkapex> good point. ill add it on the trac with a short warning that this might have moving (or undefined) parts but still a good learning experience.
[22:02:30 CET] <durandal_1707> darkapex: best ask flif devs themselves
[22:03:56 CET] <darkapex> durandal_1707: will do thx
[22:37:36 CET] <cone-215> ffmpeg 03Paul B Mahol 07master:e3e559829040: avfilter/vf_xfade: add dissolve transition
[22:37:36 CET] <cone-215> ffmpeg 03Paul B Mahol 07master:3720153ffca6: aviflter/vf_xfade: add pixelize transition
[00:00:00 CET] --- Sat Feb  8 2020