[00:08:30 CEST] <atomnuker> yeah ok, I'll try to pick that back up this weekend, [00:08:40 CEST] <BBB> ty <3 [00:15:50 CEST] <atomnuker> though I think the opus encoder's EC system was a bigger effort [01:05:29 CEST] <philipl> BtbN: https://github.com/philipl/FFmpeg/commits/master cuda yadif now in a presentable form :-) [01:07:53 CEST] <nevcairiel> how is the performance? a cpu algorithm may not always translate that well speed wise [01:18:05 CEST] <philipl> 1% of GPU utilisation on my 2080ti. No idea how it scales down, of course. [01:19:02 CEST] <philipl> It's not perfect as there are a couple of conditionals in the algorithm but I think in practice it's simple enough that it doesn't do anything pathological. [01:21:28 CEST] <nevcairiel> gpu usage is not a usable metric [01:22:27 CEST] <nevcairiel> pick a video, compare cuvid decode + internal deint, or cuvid decode + yadif, grab some FPSes =p [01:23:06 CEST] <philipl> fair enough. [01:24:05 CEST] <philipl> I think I may also have done something that gratuitously increased the CPU consumption vs my first implementation. *sigh* [01:24:46 CEST] <cone-973> ffmpeg 03Mark Thompson 07master:f370142ec08b: lavfi/ebur128: Fix mixed declarations and code [01:29:34 CEST] <philipl> nevcairiel: At first glance it looks like it almost halves the fps vs doing nothing. [01:29:50 CEST] <philipl> (after accounting for the fact that there are twice as many frames) [02:14:49 CEST] <cone-973> ffmpeg 03James Almer 07master:6a112349c206: configure: add missing optional SDL2 dependency to OpenGL outdev [10:29:19 CEST] <j-b> Good morning *! [10:30:13 CEST] <durandal_1707> ***moroning day! [11:30:34 CEST] <durandal_1707> j-b: you are very evil, you do not like mpv [11:32:09 CEST] <j-b> if that is all my evilness, I'm not very evil [12:32:52 CEST] <January> michaelni: does last timecode fate test work for you? [12:36:15 CEST] <michaelni> January, you mean the test from 3f2103ec73c96d530b0516869363ad9ea730c909 ? i think but ill recheck if it passes on all easy testable platforms [12:36:54 CEST] <January> michaelni: '[PATCH vFINAL] fate: add api-h264-slice test' on the ml [16:52:27 CEST] <graphitemaster> is there any support for decoding and playing back NSCF files? [17:21:12 CEST] <atomnuker> BBB: "Don't use tile-threaded code path if there's only one tile." [17:21:27 CEST] <BBB> yes? [17:21:30 CEST] <atomnuker> yeah, I was under the impression you could use the tile threaded code in non-tile-encoded images [17:21:37 CEST] <BBB> you could [17:21:42 CEST] <BBB> but someone complained that it wasnt faster [17:22:04 CEST] <BBB> its not a correctness issue, its a speed issue [17:22:09 CEST] <BBB> (or, rather, battery usage) [17:22:12 CEST] <atomnuker> I tested this the other day actually, it wasn't, for non-tiled images [17:22:34 CEST] <BBB> it wasnt = it wasnt faster or it wasnt not faster"? [17:22:35 CEST] <atomnuker> (which 100% of everything is, as usual, like with vp9) [17:22:56 CEST] <atomnuker> it wasn't faster, it was slower, just using all cores for frame threading was faster [17:23:04 CEST] <BBB> right [17:23:10 CEST] <BBB> so the patch makes that issue go away [17:23:22 CEST] <BBB> not much you can do& no tiles, no tile threading :) [17:23:39 CEST] <atomnuker> there was some minor advantage when I used 2 tile threads / 6 frame threads but it was low enough that I discounted that as noise [17:24:28 CEST] <atomnuker> runtime was around 2 seconds to decode 300 frames, so there was plenty of margin for noise [17:25:04 CEST] <BBB> yeah [17:25:09 CEST] <BBB> good speed btw, 150fps :) [17:27:53 CEST] <jamrial> depends on resolution :p [17:32:57 CEST] <atomnuker> mIAfxj7nd9k so 1920x1080, 8 bit [17:36:34 CEST] <atomnuker> BBB: no, checked again, there's a 13% gain (2.2 vs 1.9 sec) when using 8+4 vs 8+1 frame/tile threads [17:37:31 CEST] <atomnuker> if I let it run without limit the CPU use is almost a core higher than with frame threads alone [17:48:37 CEST] <durandal_1707> graphitemaster: is that avi file? [17:50:00 CEST] <graphitemaster> durandal_1707, no, PSF files, as used by game consoles [17:50:55 CEST] <graphitemaster> durandal_1707, basically all the nintendo consoles and playstation used more or less the same audio file format (PSF) with ton of their own extensions [17:52:13 CEST] <graphitemaster> here's one such impl https://github.com/kode54/SSEQPlayer [17:52:25 CEST] <durandal_1707> if it is not streamed, but tracked format - ffmpeg does not play it directly, but maybe there is some other lib [17:52:50 CEST] <durandal_1707> it is probably similar to midi [17:54:32 CEST] <JEEB> graphitemaster: there are some patches for PSMF and the PS3 version (basically ATRAC3+ in MPEG-PS), but unfortunately all the patches that added a parser somehow broke seeking [17:54:37 CEST] <JEEB> and I haven't had the time to fixup it [17:54:55 CEST] <JEEB> this was the latest attempt by misty, IIRC https://github.com/mistydemeo/FFmpeg/tree/mps_support_atrac3 [17:55:33 CEST] <JEEB> the current decoder expects a lot of data to come from extradata, while the format in MPEG-PS unexpectedly has its own header [17:55:48 CEST] <JEEB> (for each ATRAC3+ packet) [17:56:41 CEST] <JEEB> oh, and UMD Video also used another version of it [17:56:47 CEST] <graphitemaster> JEEB, the whole thing is a bit of a mess, on one hand it seems the emulator people have this down but they have it down in ugly af C++ code, most of which is riddled with UB or implementation defined behavior or security vulns, PSF is a bytecode interpreted format and I can hand craft some Nintendo DS audio that will crash the emulator [17:56:54 CEST] <graphitemaster> I'm not happy with this [17:57:29 CEST] <JEEB> ppsspp at least uses a fork of FFmpeg with an earlier version of the parser+patch [17:57:37 CEST] <JEEB> they don't need to seek so it's simpler for them [17:57:54 CEST] <JEEB> (also I don't think they used some other things) [18:22:14 CEST] <graphitemaster> JEEB, hum [18:54:49 CEST] <durandal_1707> ubitux: do you have comments for lut3d patch, if not i will apply it [19:16:18 CEST] <ubitux> durandal_1707: can you just share the header? [19:21:00 CEST] <durandal_1707> ubitux: https://pastebin.com/GhPh9sPd [19:24:55 CEST] <ubitux> yeah well i guess that's fine [19:33:51 CEST] <michaelni> January, sorry for the delay, the vFINAL (with the dependant h264 patch) works on all systems i tried [19:34:30 CEST] <January> No problem, will push tomorrow then [20:14:46 CEST] <durandal_1707> JEEB: SSEQPlayer is player for tracker file [20:14:53 CEST] <JEEB> right [20:14:59 CEST] <JEEB> he just mentioned PSMF [20:15:06 CEST] <JEEB> which I happened to know about :P [23:11:45 CEST] <jamrial> jkqxz: https://pastebin.com/279WcMDP reference frame tracking for cbs_vp9 [23:16:04 CEST] <cone-457> ffmpeg 03Paul B Mahol 07master:bd02a6d7ed90: avfilter/af_adelay: switch to activate [23:24:46 CEST] <cone-457> ffmpeg 03Paul B Mahol 07master:963c16ed38fb: avfilter/vf_lut3d: do not error out if TITLE is after other lines [00:00:00 CEST] --- Fri Oct 26 2018