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

[burek]

[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