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

[burek]

[00:41:38 CEST] <cone-184> ffmpeg 03Mark Thompson 07master:92a0a6bea9dc: hwcontext_vaapi: Fix compilation with libva versions < 1.4.0
[00:45:25 CEST] <cone-184> ffmpeg 03Mark Thompson 07release/4.0:44cb6474770e: hwcontext_vaapi: Fix compilation with libva versions < 1.4.0
[01:30:21 CEST] <atomnuker> nevcairiel: do the mysterious hls errors still get reported?
[01:30:50 CEST] <atomnuker> a bunch of streaming websites have had issues for more than a week, so it might be just a coincidence
[01:32:56 CEST] <atomnuker> smashcast for instance is hilarious, almost all requests 504, 404 or just time out
[01:34:42 CEST] <klaxa> aren't they going bust soon anyway?
[01:35:02 CEST] <wm4> what's this about
[01:35:30 CEST] <klaxa> hitbox rebrand smashcast
[01:35:45 CEST] <klaxa> twitch clone afaict
[01:37:20 CEST] <klaxa> but with shitty websocket chat instead of irc like twitch
[01:37:31 CEST] <klaxa> fucking webshits ruining everything
[01:38:04 CEST] <atomnuker> no, just going through "corporate restructuring" and firing a bunch of people, though that's not a good sign
[01:38:16 CEST] <klaxa> ah
[01:38:41 CEST] <wm4> always cute when they don't actually have a way to make money
[01:39:42 CEST] <atomnuker> 5-6 years ago there was own3dtv which for a time was almost an equal to twitch in size
[01:40:12 CEST] <atomnuker> shame they didn't improve their awful pos player and failed purely because of it
[01:41:57 CEST] <atomnuker> literaly all a streaming website had to do back then was to use html5 video to become a dominant platform
[01:42:25 CEST] <atomnuker> but that didn't happen until somewhat recently for twitch
[02:38:40 CEST] <kierank> michaelni: why not clip the rgb values
[02:57:07 CEST] <cone-184> ffmpeg 03Mark Thompson 07n4.1-dev:HEAD: hwcontext_vaapi: Fix compilation with libva versions < 1.4.0
[04:00:01 CEST] <Chloe> BtbN: I think youre missing an obvious reason for cracks, games cost a lot
[10:55:33 CEST] <durandal_1707> can i get review for my overlay slice threading patch?
[10:56:19 CEST] <kierank> durandal_1707: we should remove non bitexact hpel crap, no?
[10:57:15 CEST] <durandal_1707> what's gain of having non-bitexact at first place?
[10:57:55 CEST] <kierank> durandal_1707: early 2000s thinking of people like michaelni of course
[10:57:56 CEST] <kierank> as always
[10:58:07 CEST] <kierank> cf thread on postproc
[10:58:30 CEST] <durandal_1707> ?
[10:58:54 CEST] <kierank> It's "faster" if you don't care about exact quality
[10:59:07 CEST] <durandal_1707> how much faster?
[10:59:16 CEST] <kierank> dunno
[11:28:41 CEST] <cone-135> ffmpeg 03Paul B Mahol 07master:4f484edaa7ca: avfilter/vf_convolution: make rdiv set to 0 more useful
[11:37:15 CEST] <durandal_1707> kierank: you no longer use overlay filter?
[11:37:36 CEST] <kierank> I do but I have hardcoded ffmpeg version because everything breaks
[11:37:50 CEST] <durandal_1707> what breaks?
[11:38:09 CEST] <kierank> api
[11:40:30 CEST] <durandal_1707> so you will not benefit from faster overlay filter in lavfi?
[11:42:13 CEST] <kierank> https://github.com/FFmpeg/FFmpeg/commit/6442e4ab3cab573e6f86bfa6db096afd8edef453#diff-3365d6ae06f22ba69bb0eb2a2d647e24
[11:42:17 CEST] <kierank> this is what broke api for me
[11:42:25 CEST] <kierank> and why i am never touching lavfi in my code ever again
[11:43:54 CEST] <nevcairiel> that commit seems pretty innocent, if you passed integer font sizes before it should still handle them like that after i would think
[11:44:11 CEST] <kierank> iirc it doesn't work
[11:44:26 CEST] <kierank> I had all the wrong font sizes 
[11:52:20 CEST] <durandal_1707> kierank: you are bad, bad, bad
[13:11:53 CEST] <atomnuker> kierank: still not using systemd?
[14:01:02 CEST] <loki_> good morning everyone
[14:02:00 CEST] <loki_> so i have just gotten audio for this really obscure game codec working, however now when i add the audio stream and render an avi, the video is spep up by about 2x. any idea what might be the reason? it is clearly the audio, when i disable it again then video is normal speed
[14:05:39 CEST] <wm4> wrong sample rate?
[14:06:27 CEST] <loki_> thought of that. however audio is sounding normal and has the correct length. so the whole avi is set to 55 seconds, but the audio plays the full 100 seconds
[14:07:08 CEST] <loki_> normally video should be 100 seconds too, but now plays faster and finishes at 55
[14:07:38 CEST] <loki_> mpc-hc says it is 24 fps, but plays visibly faster than 24
[14:07:43 CEST] <durandal_1707> wrong format?
[14:10:04 CEST] <loki_> raw output to 22050 hz s16le 2ch sounds correct. the same i did in the code, not sure about avpriv_set_pts_info tho. currently i use this: avpriv_set_pts_info(ast, 33, 1, 22050);
[14:10:12 CEST] <wm4> messed up timebases?
[14:10:18 CEST] <atomnuker> or timestamps
[14:10:39 CEST] <wm4> because avpriv_set_pts_info(ast, ...) is a complicated way to set st->time_base
[14:13:18 CEST] <loki_> would it be better to set time_base directly?
[14:13:32 CEST] <wm4> no
[14:13:48 CEST] <wm4> I just mean you should check whether it's consistent with your pts values
[14:18:28 CEST] <cone-135> ffmpeg 03Paul B Mahol 07master:5c6a3604f059: avcodec: remove duplicate prores decoder
[14:18:29 CEST] <cone-135> ffmpeg 03Paul B Mahol 07master:99d24499c231: avcodec/proresdec2: make long name more descriptive
[14:18:30 CEST] <cone-135> ffmpeg 03Paul B Mahol 07master:81d78fe13bc1: avcodec/proresdec2: add missing frame color metadata
[14:18:31 CEST] <cone-135> ffmpeg 03Paul B Mahol 07master:c116ba375ea4: doc/libav-merge: remove resolved item
[14:23:16 CEST] <durandal_1707> pp7 filter confirmed very blurry and too strong on d9
[14:48:17 CEST] <loki_> thanks for the info, it is definitely related to avpriv_set_pts_info, i just checked again
[15:32:57 CEST] <durandal_1707> will apply overlay slice patch soon, as looks nobody gonna review it anytime soon
[15:34:14 CEST] <wm4> so does anyone know if libavcodec/rawdec.c can accept arbitrary pixfmts?
[15:34:42 CEST] <wm4> I mean it almost looks like it does
[15:35:01 CEST] <wm4> (but only with minimal alignment)
[15:35:31 CEST] <Chloe> durandal_1707: I would have loved to review it, but I'm honestly not experienced enough to review much on the ML
[15:36:07 CEST] <durandal_1707> wm4: does raw supports colorspace, color_trc, color_primaries, color_range ?
[15:37:14 CEST] <wm4> durandal_1707: I think it'll just pass them through from codecpar
[15:37:25 CEST] <wm4> on that note I'm really glad we did this codecpar merge
[15:37:36 CEST] <wm4> it's so much more defined what gets passed through and what not
[15:38:46 CEST] <JEEB> yup
[16:05:26 CEST] <durandal_1707> why slice threading init in lavfi cost so much?
[16:19:45 CEST] <JEEB> hmm, did adding a new thing add a #define for it in config.h?
[16:20:38 CEST] <JEEB> seems like yes
[16:20:51 CEST] <JEEB> CONFIG_XXXX 1
[16:21:12 CEST] <wm4> durandal_1707: ?
[16:25:07 CEST] <durandal_1707> wm4: i benchmarked filter with threads=1 and threads=4 and it gave only 10% gain
[16:33:36 CEST] <wm4> how is that related to "init"
[16:40:32 CEST] <JEEB> how did I in configure add a dependinng dependency to a demuxer? just yer usual string append with an if?
[16:41:13 CEST] <JEEB> oh, the listing definition is before any of the functions
[16:41:43 CEST] <JEEB> or is the _suggest
[16:41:49 CEST] <JEEB> thing for possible deps?
[16:43:19 CEST] <atomnuker> <name>_demuxer_deps="<component>"
[16:43:36 CEST] <JEEB> yeah, but if it is dependant on libXXXX being enabled?
[16:43:45 CEST] <JEEB> and I've ifdef'd it in the demuxer
[16:44:07 CEST] <atomnuker> you don't need to ifdef it if its depending on it
[16:44:33 CEST] <JEEB> yes, but the demuxer doesn't *require* it, it's just niced to get X,Y,Z if you do have it
[16:44:39 CEST] <JEEB> ok, _suggest seems to be it
[16:44:48 CEST] <atomnuker> no, that's not it
[16:44:57 CEST] <atomnuker> say its optional if it is
[16:45:12 CEST] <atomnuker> to make it optional add the ifdef flag to HAVE_ flags
[16:45:36 CEST] <JEEB> ok, so there's an xxxx_demuxer_optional?
[16:45:50 CEST] <atomnuker> and check it using enabled <component> && require <stuff to check> <component>
[16:46:10 CEST] <JEEB> I already have the demuxer building without the library enabled, so the ifdefs are there correct
[16:46:18 CEST] <atomnuker> no, itis called EXTERNAL_LIBRARY_LIST
[16:46:22 CEST] <atomnuker> and HAVE_LIST
[16:46:27 CEST] <atomnuker> you need to add it to both
[16:46:54 CEST] <JEEB> EXTERNAL_LIBRARY_LIST I already of course have
[16:47:12 CEST] <JEEB> and `enabled libaribb24        && require_pkg_config libaribb24 aribb24 "aribb24/aribb24.h" arib_instance_new`
[16:47:15 CEST] <JEEB> is already there
[16:47:20 CEST] <JEEB> so it gets the correct flags from pkg-config
[16:47:38 CEST] <JEEB> and I have CONFIG_LIBARIBB24 in mpegts.c
[16:47:42 CEST] <JEEB> ifs
[16:48:08 CEST] <JEEB> so now all I need to libavformat get the aribb24 flags if libaribb24 is enabled + mpegts demuxer is enabled
[16:48:18 CEST] <JEEB> and _suggests seems to do that?
[16:48:50 CEST] <JEEB> I will be moving some of this functionality to a separate file, but currently it's all in mpegts.c so no separate file
[16:49:56 CEST] Action: JEEB re-tests without aribb24 enabled
[16:50:59 CEST] <JEEB> and yes, as soon as you add a single file into the library that has a specific dependency on a thing
[16:51:05 CEST] <JEEB> the whole library gets those link flags
[16:51:12 CEST] <JEEB> and it's suddenly much simpler :)
[16:55:49 CEST] <JEEB> ok, _suggest seems to not make it require it if library isn't enabled it seems
[16:55:52 CEST] <JEEB> which is gut
[16:56:07 CEST] <JEEB> and it adds it as a dep to an existing thing if it is enabled
[16:57:20 CEST] <JEEB> atomnuker: just for the context, this is how it came to look like now :) https://github.com/jeeb/ffmpeg/commit/5c225ac6917d483ce7a33f1c32366a33a3304f11
[16:57:35 CEST] <JEEB> also I need to add requirement for v3
[16:59:05 CEST] <atomnuker> is it that hard to decode sjis to utf8?
[16:59:13 CEST] <JEEB> it's not SJIS
[16:59:14 CEST] <JEEB> that's the joke
[16:59:31 CEST] <JEEB> it's a special JIS coding defined at hte end of STD-B.24 or B.32
[16:59:40 CEST] <jamrial> JEEB: whatever_demuxer_deps="libaribb24"
[16:59:47 CEST] <JEEB> jamrial: that's a requirement, right?
[16:59:52 CEST] <JEEB> but I've ifdef'd it
[16:59:52 CEST] <jamrial> yes
[17:00:00 CEST] <JEEB> or well if'd
[17:00:07 CEST] <JEEB> for the if'ing _suggest seemed to work
[17:00:08 CEST] <jamrial> this is in configure, doesnt' matter what you did in the tree
[17:00:13 CEST] <JEEB> yea
[17:00:16 CEST] <jamrial> c files, i mean
[17:00:23 CEST] <JEEB> see the commit I just linked, that seems to work
[17:00:33 CEST] <JEEB> with both enabled and disabled for the lib
[17:00:37 CEST] <jamrial> a demuxer that needs a external library must depend on said library being present to be enabled at all
[17:00:48 CEST] <JEEB> it's an optional feature
[17:00:51 CEST] <jamrial> oh, this is for mpegts
[17:00:53 CEST] <JEEB> yes
[17:01:05 CEST] <JEEB> it's my first part of integrating ARIB B.24
[17:01:05 CEST] <jamrial> yeah, _deps would make it required
[17:01:10 CEST] <jamrial> i thought this was for a new demuxer
[17:01:16 CEST] <atomnuker> JEEB: still, how hard would that be?
[17:01:26 CEST] <JEEB> atomnuker: it's a fuckbig map
[17:01:33 CEST] <JEEB> let's not duplicate it in avutil, shall we?
[17:01:35 CEST] <jamrial> so yeah, _suggest is ok
[17:02:46 CEST] <JEEB> but yea, this simple character conversion is just the first thing, after that I'll try adding demuxing and decoding of the captions
[17:02:52 CEST] <JEEB> with the aribb24 library
[17:03:38 CEST] <JEEB> and added libaribb24 to EXTERNAL_LIBRARY_VERSION3_LIST
[17:03:45 CEST] <JEEB> since its license is LGPLv3
[17:04:13 CEST] <JEEB> although I guess since he already once relicensed from GPL to LGPL I'm not sure if he wouldn't be OK with LGPLv2+
[17:04:26 CEST] <JEEB> might poke him about that later
[17:04:53 CEST] <j-b> you cannot.
[17:05:01 CEST] <j-b> the relicensing is already very dodgy
[17:05:13 CEST] <j-b> JEEB: you should consider this lib to be GPLv3, for the moment.
[17:05:17 CEST] <JEEB> oh?
[17:05:27 CEST] <JEEB> so there are old contributors
[17:05:33 CEST] <JEEB> which he didn't consult with
[17:05:45 CEST] <j-b> JEEB: it's a bit more complex than that.
[17:07:10 CEST] <JEEB> ok, it seems like he just copied some things from VLC ad verbatim in 2014, possibly including the license file?
[17:07:17 CEST] <j-b> indeed.
[17:08:11 CEST] <JEEB> huh, the character code decoder at least was LGPLv2+ from the beginning it seems o_O
[17:08:18 CEST] <JEEB> what on earth happened there
[17:09:41 CEST] <j-b> JEEB: told you.
[17:09:47 CEST] <j-b> JEEB: it's being discussed, btw
[17:11:35 CEST] <JEEB> and the files copied from VLC seemed to be LGPLv2+ too by their headers
[17:11:53 CEST] <JEEB> at least the amount of contributors can be counted on the fingers of one hand it seems
[17:29:10 CEST] <Compn> oh no we lost the cone
[17:34:51 CEST] <rcombs> JEEB: couldn't you just take any existing EUC decoder and swap out the char tables
[17:36:39 CEST] <rcombs> e.g. https://github.com/bminor/glibc/blob/09533208febe923479261a27b7691abef297d604/iconvdata/euc-jp.c
[17:50:07 CEST] <Chloe> Compn: ?
[17:50:09 CEST] <wm4> av_iconv
[17:50:37 CEST] <Chloe> wm4: also add zip to lavf then you dont have to use libarchive with its encoding issues in mpv
[17:51:43 CEST] <wm4> and instead have that in lavf
[17:51:54 CEST] <wm4> I don't really agree that something like libarchive should be in lavf though
[17:52:06 CEST] <wm4> it wouldn't integrate well and would cause all kinds of problems
[17:52:28 CEST] <wm4> otherwise I'd be glad to leave yet another stinky feature to ffmpeg
[17:54:59 CEST] <j-b> So, the HTTP server supports gzip compression? :D
[18:01:11 CEST] <wm4> don't know
[18:11:05 CEST] <cone-889> ffmpeg 03Mark Wachsler 07master:9d7535496356: fftools/ffmpeg: Add system time and real time to benchmarking.
[18:11:05 CEST] <cone-889> ffmpeg 03Rahul Chaudhry 07master:e84212b78e00: swresample/arm: rename labels to fix xcode build error
[18:11:05 CEST] <cone-889> ffmpeg 03André Camargo 07master:1322b00060d3: fftools/ffmpeg: change fps progress log message to show two decimal digits
[18:25:36 CEST] <JEEB> rcombs: I dunno, this was just the first step in integrating that thing that will also do ARIB STD-B.24 captions
[18:25:48 CEST] <JEEB> so just charset conversion seemed like the simplest thing to do
[18:25:52 CEST] <JEEB> as the first step
[18:35:06 CEST] <kierank> atomnuker: ubuntu 18.04 will force us
[18:48:02 CEST] <atomnuker> oh, you skipped 16.04
[18:56:27 CEST] <kierank> atomnuker: yeah, systemd :)
[18:56:43 CEST] <cone-889> ffmpeg 03Paul B Mahol 07master:d54014d1573e: avfilter/vf_overlay: add slice threading
[19:00:52 CEST] <JEEB> kierank: as someone making services I felt like sysv < upstart < systemd. of course the problem was that debian-based distros for some reason kept around init files for all of the darn init systems so in the worst case you got a random one utilized
[19:01:05 CEST] <JEEB> but I guess if you don't need to change, don't :)
[19:02:47 CEST] <kierank> Got no choice, have to change for 18
[19:03:42 CEST] <JEEB> well yea
[19:17:14 CEST] <durandal_1707> wm4: vapoursynth wrapper does not support alpha?
[19:17:41 CEST] <wm4> durandal_1707: VS handles alpha as separate node, so it's kind of awkard... but we could
[19:18:33 CEST] <durandal_1707> bad joke
[19:24:27 CEST] <cone-889> ffmpeg 03Gyan Doshi 07master:96d7cbedbefd: doc/ffmpeg - update benchmark option readout details
[19:55:39 CEST] <durandal_1707> ubitux: why fieldmatch doesn't use same defaults as vapoursynth VFM ?
[19:56:25 CEST] <ubitux> maybe the defaults changed in vs
[19:56:35 CEST] <ubitux> i don't remember changing them
[19:56:59 CEST] <ubitux> but it was a long time ago
[20:57:06 CEST] <durandal_1707> ubitux: you have hardcoded stuff for subsamplings, so it only works with yuv420p case
[21:00:52 CEST] <durandal_1707> for y0/y1 using
[21:05:21 CEST] <atomnuker> michaelni: you should probably remove https://github.com/FFmpeg/gas-preprocessor
[21:05:49 CEST] <atomnuker> it hasn't been needed to build with simd support on arm for ages now
[21:08:18 CEST] <JEEB> it was made for clang IIRC
[21:08:32 CEST] <JEEB> and clang compatibility was only fixed to be good enough very recently
[21:08:48 CEST] <JEEB> and wbs's fixes that make clang work without it went in just a few weeks ago
[21:09:07 CEST] <atomnuker> it was needed for gcc too, wasn't it?
[21:09:42 CEST] <JEEB> I never heard of that
[21:09:51 CEST] <JEEB> I only heard of it in conjunction with clang
[21:10:06 CEST] <atomnuker> no, I'm pretty sure it was needed for gcc 2 years ago as well
[21:10:28 CEST] <atomnuker> well, its in 4.0 anyway so its technically no longer needed to build the latest release
[21:12:14 CEST] <wbs> it's needed with clang < 5.0, super-old xcode toolchains that use standalone apple binutils 'as', and also for windows/arm with msvc tools
[21:12:28 CEST] <JEEB> yup
[21:12:53 CEST] <JEEB> and wasn't that <= 5.0?
[21:13:07 CEST] <JEEB> since IIRC the check for clang only broke with the latest NDK clang
[21:13:14 CEST] <JEEB> which I think should have been 6.0 development?
[21:13:26 CEST] Action: JEEB goes check
[21:13:41 CEST] <wbs> NDK r17 beta uses clang from october 2017 (despite the version number saying it's 6.0.1)
[21:13:46 CEST] <wbs> october 2017 + patches
[21:14:05 CEST] <wm4> so their version numbers lie or what?
[21:14:28 CEST] <wbs> NDK r16 used clang from maybe march/april 2017; the altmacro stuff was merged in may 2017, and 5.0 branched in july 2017
[21:14:42 CEST] <JEEB> ok
[21:14:44 CEST] <wbs> wm4: well 6.0.0 would have been accurate at least, dunno what things they've backported
[21:15:06 CEST] <wbs> since clang trunk claimed to be 6.0.0 from after when 5.0.0 was branched
[21:16:59 CEST] <wbs> but with modern tools (latest ndk, latest xcode), the only place where gas-preprocessor is necessary is for arm/arm64 with msvc tools (where it reformats the asm completely for use with armasm.exe)
[21:17:34 CEST] <JEEB> so it's no longer needed for R16?
[21:17:53 CEST] <wm4> does windows on arm still exist
[21:18:01 CEST] <JEEB> yes
[21:18:06 CEST] <wbs> JEEB: no, I meant latest == R17
[21:18:07 CEST] <JEEB> they're actually pushing out new devices
[21:18:11 CEST] <JEEB> wbs: but that's still beta?
[21:18:16 CEST] <wbs> JEEB: well yes
[21:18:27 CEST] <JEEB> I'd rather call it the next version at this point of time
[21:18:30 CEST] <JEEB> but details, details
[21:18:31 CEST] <JEEB> ;)
[21:18:37 CEST] <wbs> yes, my point was, "modern tools"
[21:19:03 CEST] <wbs> wm4: windows phone is dead, but they're pushing it for windows desktop and server
[21:19:16 CEST] <wbs> wm4: (arm64 then also, not only arm)
[21:19:37 CEST] <JEEB> the work wbs did was exactly related to the desktop Windows on aarch64
[21:19:47 CEST] <JEEB> if I recall correctly :)
[21:19:51 CEST] <wbs> yes
[21:20:35 CEST] <wbs> (and using clang and llvm tools with mingw, which is like 90% of the effort; the aarch64 parts is pretty much good enough at the moment)
[21:22:48 CEST] <wm4> why is MS pushing this? the only advantage I can see is that they can lock "secureboot" on those devices
[21:23:41 CEST] <wbs> wm4: keeping all doors open? or maybe it's mostly qualcomm (and arm64 server chips manufacturers) pushing, and microsoft not denying it?
[21:24:58 CEST] <JEEB> esp. if they already had the kernel etc done
[21:25:04 CEST] <JEEB> and a lot of stuff cross-compilable
[21:27:39 CEST] <Compn> Chloe : the cone bot timed out :P
[21:29:01 CEST] <wm4> why is CE being cranky with me again
[21:29:02 CEST] <wm4> what the fuck
[21:29:10 CEST] <durandal_1707> what you expect?
[21:29:27 CEST] <wm4> probably better if I just filter his email address and ignore anything that comes from him
[21:29:51 CEST] <wm4> would that be against the dev policies or anything
[21:30:11 CEST] <Compn> no
[21:30:13 CEST] <Compn> do that
[21:30:19 CEST] <Compn> thats fine
[21:30:27 CEST] <atomnuker> no, don't
[21:30:28 CEST] <wm4> ok
[21:30:32 CEST] <wm4> now what
[21:30:42 CEST] <atomnuker> don't do anything you wouldn't want done on yourself
[21:30:51 CEST] <atomnuker> just ignore him unless you get replied to
[21:31:02 CEST] <wm4> well he replied to my patch
[21:32:47 CEST] <atomnuker> well don't do anything, its not like he asked you, he just told you an issue he saw once had a proposed fix which was the same as in your patch and didn't help, its irrelevant
[22:35:51 CEST] <durandal_1707> ubitux: do i must sent every patch for fieldmatch to ML for review?
[22:51:35 CEST] <ubitux> no it's ok if you're confident with your patches
[22:56:48 CEST] <durandal_1707> well, i only have one that changes yuv444p fate test, because of hardcoded subsamplings for yuv420p
[23:15:43 CEST] <cone-673> ffmpeg 03Paul B Mahol 07master:29fd44adf128: avfilter/vf_fieldmatch: use correct subsamplings for y0a, y1a and startx
[00:00:00 CEST] --- Sun Apr 29 2018