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

[burek]

[01:09:43 CET] <jamrial> Gramner: ping
[01:22:46 CET] <Gramner> jamrial: pong
[01:23:16 CET] <jamrial> Gramner: https://pastebin.com/9KPQW85g is this ok?
[01:24:14 CET] <jamrial> audio_mix.asm does some calculations with num_mmregs expecting it to be 8 or 16, and ever since the avx512 that value is 32 on x86_64 even if not using avx512
[01:26:46 CET] <Gramner> I don't think that variable was ever intended to be used outside of x86inc itself, but nasm doesn't really have any practical way of flagging such things so it doesn't surprise me that implementation details ends up being used as API
[01:29:16 CET] <jamrial> i can change the asm file in question instead, but it's kinda ugly to do something like "num_mmregs - 16*notcpuflag(avx512)"
[01:30:06 CET] <Gramner> I can see it being useful so I'm not against having it signal the proper thing
[01:30:09 CET] <jamrial> or i could try replacing that num_mmregs usage with something like 8+8*ARCH_X86_64
[01:30:17 CET] <jamrial> alright
[01:31:09 CET] <Gramner> that patch doesn't look correct though
[01:31:37 CET] <jamrial> no, it's not. this should be https://pastebin.com/0aiHsTsw
[01:32:08 CET] <Gramner> it's only 32 in x86-64. avx-512 doesn't give more regs in 32-bit
[01:32:58 CET] <jamrial> ah right
[01:37:35 CET] <iive> jamrial: shouldn't you fix audio_mix.asm instead ?
[01:38:29 CET] <jamrial> i suggested that, but ideally num_mmregs would report the actual amount of regs available instead
[01:39:14 CET] <jamrial> Gramner: https://pastebin.com/M19VZguZ
[01:41:01 CET] <Gramner> jamrial: seems reasonable
[01:43:23 CET] <iive> oh, i didn't look carefully, i saw changing 32 to 16 and thought you limit it to 16 in all cases. my bad. need sleep.
[02:12:09 CET] <jdarnley> wtf?  How come I never saw that failure?
[02:12:56 CET] <jdarnley> oh
[02:12:58 CET] <jdarnley> do you have to explicitly enable avresample?
[02:14:24 CET] <kierank> yes
[02:18:10 CET] <jdarnley> jamrial, Gramner: if you lower num_mmregs to 16 will it correctly reset permutations and whatnot whengoing from 16->32 and 32->16?
[02:19:49 CET] <jdarnley> I guess it probably worked correctly doing 8->16 and 16->8 but mmx may have always been disabled in files which alsohave sse.
[02:20:22 CET] <wm4> I've argued to enable avr for ages :(
[02:24:00 CET] <atomnuker> well its getting deprecated as soon as I resubmit my patch
[02:40:36 CET] <kierank> jdarnley: how much do you understand about the c idct code?
[02:40:49 CET] <kierank> maybe a question for atomnuker as well
[02:42:04 CET] <atomnuker> not a lot, if you were asking about the daala dct on the other hand
[02:42:13 CET] <atomnuker> is it changed compared to 8bit mpeg4?
[02:43:16 CET] <jdarnley> Hm, very little, most of my knowledge is about the h264 idct
[02:43:59 CET] <jdarnley> (even that is fairly limited)
[02:45:13 CET] <kierank> atomnuker: yes quite significantly since the coefficients are 17-bit
[02:45:44 CET] <kierank> basically my question is how many more bits the transform uses
[02:47:02 CET] <kierank> not sure if i can do it with 32-bit intermediates or i need 64
[02:47:22 CET] <atomnuker> I bet its designed such that normally less than or equal to 32 bits are used unless you feed it junk, in which case it might overflow
[02:47:37 CET] <atomnuker> they'd have to be crazy to require 64 bit intermediaries
[02:47:59 CET] <atomnuker> (especially considering its not a state of the art codec)
[02:49:23 CET] <kierank> i have it working with float dct
[02:54:48 CET] <kierank> atomnuker: aren't the intermediates implementation dependent?
[02:57:15 CET] <atomnuker> yes, but there's a minimum you can get by with
[02:57:55 CET] <kierank> "If each pixel is represented by n bits per pixel, the input to the forward transform and output from the inverse
[02:57:55 CET] <kierank> transform is represented with (n+1) bits. The bit precision of the DCT coefficients changes in accordance with the
[02:57:55 CET] <kierank> value of mpeg2_stream defined in StudioVideoObjectLayer(). In case of mpeg2_stream = 0, The coefficients are
[02:57:55 CET] <kierank> represented in (n+7) bits including three fractional bits. "
[03:06:42 CET] <kierank> atomnuker: any idea what this (of course undocumented) ricing does? https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/simple_idct_template.c#L117
[03:09:26 CET] <atomnuker> looks like SIMD done with GPRs
[03:09:39 CET] <jdarnley> Yeah, that's that DC only bypass
[03:10:27 CET] <kierank> jdarnley: but how does that code work independently of coefficient bitdepth
[03:10:45 CET] <jdarnley> Its in the template so it gets mutated somehwo.
[03:11:12 CET] <kierank> but it should use dctcoef
[03:11:43 CET] <jdarnley> ah that's what youmean.
[03:12:18 CET] <kierank> my guess is all codepaths assume int16_t?
[03:12:51 CET] <jdarnley> I guess so
[03:13:15 CET] <jdarnley> do all the supported bitdepths just have 16-bitcoefs.
[03:13:17 CET] <jdarnley> ?
[03:13:24 CET] <kierank> ah possibly because BBB fudges prores coefficients into 16-bit
[03:15:36 CET] <jdarnley> I am wrong when I call it DC-only.  It really splats the lowest frequency coefficient to the entire row.
[03:33:04 CET] <cone-336> ffmpeg 03James Almer 07master:90d216cb9039: x86inc: set the correct amount of simd regs in x86_64 when avx512 is enabled but not used
[05:08:56 CET] <cone-336> ffmpeg 03Karthick Jeyapal 07master:6848201f704b: avformat/http: Avoid calling http_shutdown() if end of chunk is signalled already
[05:08:57 CET] <cone-336> ffmpeg 03Karthick Jeyapal 07master:be2da4c52221: avformat/hlsenc: Signal http end of chunk(http_shutdown) during hlsenc_io_close()
[05:19:21 CET] <jdarnley> jamrial: thanks for fixing that
[05:19:28 CET] Action: jdarnley goes to bed
[12:01:05 CET] <cone-679> ffmpeg 03Paul B Mahol 07master:ec6608f51b2d: avfilter/vf_convolve: clear coefficients only when needed
[12:01:06 CET] <cone-679> ffmpeg 03Paul B Mahol 07master:86e3eebfb763: avfilter/vf_convolve: use shorter variants for pointers
[12:01:06 CET] <cone-679> ffmpeg 03Paul B Mahol 07master:f9f1b2a9274f: avfilter/vf_convolve: split input/output operations from fft
[12:01:07 CET] <cone-679> ffmpeg 03Paul B Mahol 07master:c59e49f9b2f3: avfilter/vf_convolve: implement slice threading
[12:04:45 CET] <wm4> atomnuker: also libavresample's codebase is cleaner and thus a better lib to work on
[12:06:36 CET] <atomnuker> its cleaner because it has less things in it
[12:06:53 CET] <atomnuker> pizza without pepperoni is a nice starting base too but you wouldn't want to eat it as-is
[12:07:31 CET] <wm4> your first statement isn't true
[12:08:18 CET] <wm4> also you wasted your pepperoni on a shit sandwhich
[12:09:26 CET] <atomnuker> lswr is more flexible - you can write a new resampling/mixing core without breaking the old one
[12:10:17 CET] <wm4> that infrastructure only exists to badly hack in sox
[12:13:34 CET] <durandal_1707> hack?
[12:13:51 CET] <durandal_1707> give proof to your statements
[12:14:13 CET] <atomnuker> its not a hack, its rather clean, barely 100 lines of code
[12:14:53 CET] <wm4> with various fun issues when I tried to use it
[12:19:48 CET] <durandal_1707> like?
[12:26:53 CET] <thardin> which ones do downstream projects use?
[12:57:53 CET] <durandal_1707> wm4: its other way around
[15:49:28 CET] <cone-241> ffmpeg 03Paul B Mahol 07master:e712d3017361: avfilter/vf_convolve: add threading for complex multiplication
[15:57:22 CET] <atomnuker> ubitux: I think the doc/APIchanges line is fine, do you mean the commit message (which I didn't actually write)?
[16:55:53 CET] <cone-241> ffmpeg 03Steven Liu 07master:2aee5a872332: avformat/hlsenc: fix resource leak
[17:25:58 CET] <ubitux> atomnuker: it's important to specify that it's unmaintained *in FFmpeg*
[17:26:36 CET] <ubitux> "better" x2 is not neutral, it's an opinion, i don't think it belongs in apichanges
[17:28:26 CET] <atomnuker> fine, "more accurate and faster" then
[17:33:51 CET] <jamrial> configure could emit a warning when --enable-avresample is used as well
[17:34:12 CET] <atomnuker> I'll look into that as well
[18:31:47 CET] <atomnuker> ubitux / jamrial: does this look better https://0x0.st/s8VT.patch ?
[18:32:22 CET] <atomnuker> the warning in configure is a bit hacky since it won't work if a user uses --enable=avresample,libx264,etc but only on --enable-avresample
[18:33:10 CET] <ubitux> "unmaintained by the FFmpeg project" // i think "in" is more correct english but i'm not a native speaker
[18:33:51 CET] <ubitux> should be fine otherwise
[18:36:27 CET] <jamrial> atomnuker: make it "enabled avresample && warn" near the end of configure instead
[18:36:33 CET] <jamrial> after the check_deps() call for example
[18:46:57 CET] <durandal_1707> i got deconvolve filter almost working, but i do not understand why i get artifacts
[19:39:30 CET] <tmm1> michaelni: can you "curl -v" a segment from simplehttpd and see if the response is http/1.0 or http/1.1
[19:42:07 CET] <michaelni> tmm1, HTTP/1.0 200 OK
[19:42:19 CET] <michaelni> Server: SimpleHTTP/0.6 Python/2.7.6
[19:42:23 CET] <tmm1> thanks, that explains it
[19:42:56 CET] <tmm1> setting willclose=1 when the response version is 1.0 should fix the bug
[19:47:44 CET] <tmm1> michaelni: does this work https://paste.ubuntu.com/26252718/
[19:56:16 CET] <michaelni> tmm1, doesnt work, the code is never reached, the whole if (s->is_connected_server) { body never is reached
[20:04:57 CET] <tmm1> doh thats the http server path i guess
[20:09:26 CET] <tmm1> how about this https://paste.ubuntu.com/26252862/
[20:17:05 CET] <tmm1> michaelni: ^^
[21:23:43 CET] <durandal_1707> i think deconvolution cant work with nonpower of 2 images anyway
[21:30:32 CET] <michaelni> tmm1, doesnt work, also not with if (!av_strncasecmp ... The code triggers though
[21:31:54 CET] <tmm1> hmm ok, ill try to install simplehttpd
[21:31:59 CET] <tmm1> pip install wasnt working
[21:32:20 CET] <tmm1> is p pointing to "http/" at all?
[21:33:37 CET] <michaelni> "HTTP/1.0 200 OK" yes, the if() triggers
[22:00:42 CET] <tmm1> oh huh, ok
[22:25:45 CET] <durandal_1707> Compn: why you are not in #ffmpeg?
[22:27:18 CET] <Compn> dont tell carl :)
[22:27:27 CET] <Compn> i not subscribe to ffmpeg-user either
[22:39:54 CET] <durandal_1707> there is bug with vfr files, and how are they decoded
[22:49:01 CET] <durandal_1707> is there some kind of magic one can use to do non power 2 deconvolution of images?
[22:58:05 CET] <atomnuker> what's preventing it from working?
[23:03:56 CET] <durandal_1707> atomnuker: you can not create missing data for padded pixels
[23:05:24 CET] <durandal_1707> or im missing obvious
[23:06:26 CET] <atomnuker> good point
[23:06:53 CET] <atomnuker> it would work on non-ptwo images then though
[23:07:31 CET] <atomnuker> its just that the images need to be modulo the padding size (e.g. width == stride)
[23:08:19 CET] <durandal_1707> it sort of work if you add small constant to impulse and than you get output buut with artifacts
[23:10:14 CET] <durandal_1707> you could try convolve filter first and than deconvolve convolved frame
[23:11:03 CET] <durandal_1707> for power of 2 dimensions you get perfect output
[00:00:00 CET] --- Tue Dec 26 2017