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

[burek]

[00:01:28 CET] <atomnuker> klaxa: how does your mkvserver_mk2 work? I give it matroska via stdin and there's nothing when I try tcp or http protocols on the server
[00:05:03 CET] <BtbN> God damn those new CPU vulnerabilities are quite something
[00:05:35 CET] <wm4> hardware bugs are fun
[00:05:40 CET] <BtbN> You can in theory execute almost arbitrary code in Kernel-Space from JavaScript in some website.
[00:06:02 CET] <wm4> I thought it was only about reading kernel data
[00:06:09 CET] <BtbN> It's _way_ more
[00:06:28 CET] <BtbN> Just because the CPU speculatively executes your illegal function call. You first use a timing attack on cache loads to read arbitrary data, bit by bit
[00:06:52 CET] <BtbN> And then you find a specific function of the Linux Kernel, from the eBPF framework, which executes a pre-compiled and trusted bytecode
[00:07:09 CET] <BtbN> And then call it with arbitrary malicious bytecode
[00:07:19 CET] <wm4> wouldn't that be just a bug
[00:07:20 CET] <BtbN> You will get an error because you're not allowed to call that
[00:07:33 CET] <BtbN> But the CPU speculatively still executed your code, and wrote its results to cache
[00:07:40 CET] <BtbN> Which you can then extract with the same method, bit by bit
[00:08:09 CET] <nevcairiel> you cant really execute more then just one or two asm instructions
[00:08:14 CET] <nevcairiel> until the fault is processed
[00:08:39 CET] <BtbN> Well, they successfully made a Haswell CPU execute their byte code to the eBPF function
[00:08:42 CET] <BtbN> so it seems like you can
[00:10:16 CET] <BtbN> "This section describes the theory behind our PoC for variant 2 that, when running with root privileges inside a KVM guest created using virt-manager on the Intel Haswell Xeon CPU, with a specific version of Debian's distro kernel running on the host, can read host kernel memory at a rate of around 1500 bytes/second."
[00:10:43 CET] <wm4> that's still just read access
[00:10:44 CET] <BtbN> And later they also describe a theoretical attack where it works on any custom Kernel
[00:11:00 CET] <BtbN> Yes, of course it's only read access
[00:11:12 CET] <BtbN> Any writes you do will get eventually discarded
[00:11:31 CET] <BtbN> But reading arbitrary data from a VM host is quite a big deal
[00:12:18 CET] <wm4> because it sounded like you claimed something else, but maybe I misunderstood
[00:12:37 CET] <BtbN> You read by making the CPU speculatively execute arbitrary BPF bytecode
[00:12:56 CET] <BtbN> And then pulling the results of that bytecode from the cache
[00:13:36 CET] <BtbN> https://googleprojectzero.blogspot.de/2018/01/reading-privileged-memory-with-side.html has the full lenghty description
[00:14:54 CET] <wm4> yep
[01:07:58 CET] <klaxa> atomnuker: it should listen on http://0:8080
[01:20:20 CET] Action: kierank has stopped receiving ffmpeg-devel emails
[01:41:50 CET] <Chloe> kierank: unintentionally?
[01:42:05 CET] <kierank> yes
[01:42:54 CET] <kierank> I want to reply to michaelni's h264 patch
[01:45:39 CET] <atomnuker> klaxa: oh yeah it works, didn't notice it crashed when I tried to connect
[01:46:04 CET] <klaxa> it's not the most stable piece of software. i'm not even sure why it crashes sometimes
[01:46:25 CET] <atomnuker> I'm running it on the rpi so its probably that
[01:48:52 CET] <klaxa> in the future" i might check what causes hangs, something i found was weird requests with empty http methods, not sure what to do about that yet, but i haven't looked at that code in a long time
[01:50:03 CET] <atomnuker> also it fails to build if ffmpeg was build with static linking in mind
[01:54:20 CET] <klaxa> huh... 
[01:54:35 CET] <klaxa> something something, pthreads?
[01:54:59 CET] <atomnuker> no, all av_* functions
[01:55:15 CET] <atomnuker> segment.o: In function `av_make_error_string':
[01:55:18 CET] <atomnuker> /usr/local/include/libavutil/error.h:111: undefined reference to `av_strerror'
[01:57:11 CET] <c3-Win> So the AMD PRO CPU is one of their FX/Bulldozer-based CPUs. No surprise there.
[02:00:24 CET] <iive> meltdown and spectre ...
[02:25:09 CET] <atomnuker> klaxa: crashes after a second in ffio_ensure_seekback
[02:25:26 CET] <atomnuker> do I really really need to apply the first patch in patches?
[02:34:25 CET] <c_14> the first one should be in master already
[02:35:01 CET] <c_14> I think I found the compilation issue, but it seems like there's something deeper
[02:35:07 CET] <klaxa> the second one is a memory leak, that was never fixed :( maybe i should resubmit, it's been like 9 months?
[02:36:44 CET] <atomnuker> yeah, or ping the patches if they still apply, I'll take a look if I have to
[03:54:41 CET] <cone-503> ffmpeg 03Rostislav Pehlivanov 07master:c29038f3041a: lavr: deprecate the entire library
[03:54:41 CET] <cone-503> ffmpeg 03Rostislav Pehlivanov 07master:f141b353e60f: opusenc_psy: disable stereo searches for mono streams
[05:40:18 CET] <cone-503> ffmpeg 03Carl Eugen Hoyos 07master:695b1d81117d: lavu/mem: Allow allocations close to max_alloc_size with av_fast_realloc().
[07:24:19 CET] <JEEB> mistym: you're the one working on the ATRAC3+ MPEG-PS encapsulation?
[07:24:29 CET] <mistym> JEEB: Yep!
[07:24:53 CET] <JEEB> I posted a comment thing about it, and I'll then also link you a PS3 sample which uses PAMF00 instead of PSMF00
[07:25:13 CET] <JEEB> found it out during poking into this stuff
[07:25:15 CET] <mistym> Thank you! I'd love to take a look at that sample
[07:27:12 CET] <JEEB> mistym: http://kuroko.fushizen.eu/samples/UT2OP.movie
[07:27:57 CET] <mistym> If you've been looking at it, I'm also very curious if you've found a way to identify ATRAC-3 within private section 1 headers w/o relying on the PSMF00 header wrapping the MPEG file
[07:28:01 CET] <mistym> Thank you!
[07:33:02 CET] <JEEB> any work I did was heavily grounded on the header so unfortunately not
[07:33:34 CET] <JEEB> and yea, as I noted in the e-mail before people NG'd the parser because it touched the AVCodecContext, so I'll see if people reply regarding it
[07:33:49 CET] <JEEB> (it was not specifically to you, but in general for the folks reading the thread)
[07:37:15 CET] <JEEB> I was going to check if Sony used something similar for PSVita with ATRAC9
[07:37:36 CET] <JEEB> but the sample videos I've got myself are all MP4s :P
[07:43:27 CET] <mistym> Yeah, my hope was to avoid peeking at the header and storing stuff in AVCodecContext, and instead sniff the contents of the private section to figure out if there's going to be ATRAC3P
[07:44:15 CET] <JEEB> that's the AVFormatContext :)
[07:44:23 CET] <JEEB> which is more OK since you're setting that in the demuxer
[07:45:02 CET] <JEEB> the real problem is that currently the decoder's design is one for the WAV-like OMA, which has the packets without a header and the values in the header of the file
[07:45:34 CET] <JEEB> while with MPEG-PS encapsulation you've got the header in each packet IIRC
[07:46:26 CET] <mistym> Er yeah, AVFormatContext. The real reason I don't want to sniff the header is because I want to include support for .MPS movies from UMD video discs, which don't have the PSMF header
[07:46:35 CET] <JEEB> ah yes
[07:46:39 CET] <JEEB> I've got a couple of those too
[07:48:24 CET] <JEEB> UMD video was funny in the way that it was SD, but could easily have like 6+mbps with H.264
[07:48:53 CET] <JEEB> so some things that never got any HD thing and only a DVD and UMD, the UMD could quite possibly be much better :P
[07:50:24 CET] <mistym> I wouldn't call the UMD exclusive video *good* per se but it's at least interesting enough to have support for :b
[07:50:50 CET] <JEEB> well compare it with MPEG-2 Video at 8mbps with a 1.5megabit buffer size
[07:51:10 CET] <mistym> Oh rather I mean the movies that are exclusive to the format
[07:51:13 CET] <JEEB> and yes, it's not necessarily good but still possibly the least retarded version
[07:52:07 CET] <JEEB> yea not sure what *exclusives* it had
[07:52:36 CET] <mistym> I've been testing with a ridiculous, not-very-good AFL compilation that was like $0.50
[07:52:44 CET] <mistym> I don't even watch AFL
[07:53:20 CET] <JEEB> :D
[07:54:36 CET] <JEEB> I've got a copy of spider-man that sony used to give out to people who registered their PSPs
[07:55:00 CET] <JEEB> and then I have Comic Party Revolution, which has some rather fabulous analog conversion artifacts (dot crawl etc)
[07:55:20 CET] <JEEB> but I wouldn't be surprised if the latter is the best version released, lol
[07:56:26 CET] <mistym> Oh wow
[07:58:08 CET] <mistym> I've taken a break from the ATRAC3 branch for a day or two to come back with a clear head, have been looking at XA audio in AIFF and whatever the hell Grandia uses in the meanwhile
[08:09:38 CET] <JEEB> mistym: hmm, VGMToolbox seemed to have some support for PSM
[08:09:50 CET] <JEEB> unless it does something really simple :P
[08:09:52 CET] <mistym> JEEB: Hmm, I'll take a look
[08:10:04 CET] <mistym> I did look at PPSSPP, but it goes off of the PSMF header :/
[08:10:26 CET] <JEEB> yes, the MPEG-PS patch + parser thing is from there
[08:21:30 CET] <mistym> Oh interesting, VGMToolbox supports subtitles https://sourceforge.net/p/vgmtoolbox/code/HEAD/tree/format/VGMToolbox/format/SonyPmfStream.cs
[08:21:56 CET] <JEEB> I decided I am too lazy to look through it in SF so I started a git svn clone :P
[08:23:17 CET] <mistym> lol
[08:24:28 CET] <JEEB> https://github.com/jeeb/vgmtoolbox
[08:26:40 CET] <JEEB> so it has GetAudioFileExtension and IsThisAnAudioBlock ...
[08:27:30 CET] <mistym> But IsThisAnAudioBlock just checks for 0xBD, which is private stream 1 and can also mean implementation-defined stuff
[08:27:35 CET] <JEEB> yea
[08:27:45 CET] <mistym> GetAudioFileExtension seems to assume that any stream ID sub-20 is ATRAC
[08:27:48 CET] <JEEB> so it's highly possible he just hard-codes file extensions :P
[08:27:55 CET] <JEEB> as in, the input ones
[08:28:07 CET] <JEEB> PMF/MPS => sony MPEG-2
[08:28:21 CET] <mistym> I mean, this is somewhat generalized, but I'm not sure what other stuff this would choke on
[08:28:53 CET] <JEEB> funny how I see Atrac3Bytes
[08:28:56 CET] <mistym> It's true that the mapping here lines up with other private stream 1 usage I've seen, e.g. DVD subs starting at 0x20
[08:28:57 CET] <JEEB> but that's not used anywhere?
[08:31:10 CET] <mistym> Huh, weird
[08:31:21 CET] <mistym> That might be a useful hint though
[08:31:44 CET] <JEEB> last modified @ https://github.com/jeeb/vgmtoolbox/commit/b0362bb2819b8c1e955a74bc753a1e87e61cea96
[08:32:09 CET] <mistym> Useful to have a mirror :b
[08:36:55 CET] <mistym> I don't see 0x1E, 0x60, 0x14 in the sample files I have :/
[08:39:02 CET] <mistym> Oh, but I *do* see 1E 60 04 in the PMF file, and 1E 60 04 in the MPS
[08:39:15 CET] <mistym> I walked back thruogh blame a bit and found the 0x04 version here https://github.com/jeeb/vgmtoolbox/commit/6754b1c81d89bda8d2c109073bf9b420746e5200
[08:41:37 CET] <JEEB> yeh
[08:42:02 CET] <JEEB> of course it'd be nice to know what values those exactly are
[08:44:35 CET] <mistym> It comes after the PES header I think: http://dvd.sourceforge.net/dvdinfo/pes-hdr.html
[08:46:02 CET] <JEEB> ah
[09:11:50 CET] <KGB> [13FFV1] 15JeromeMartinez reopened pull request #77: White space for forcing carriage return in a paragraph (06master...06Markdown) 02https://git.io/vQ0Qm
[09:57:38 CET] <SortaCore> has YUVJXXX formats been cleansed yet
[11:39:31 CET] <wm4> SortaCore: no, durandal_1707 gave up
[11:40:13 CET] <mistym> JEEB: Updated version of this branch should work: https://github.com/mistydemeo/FFmpeg/tree/mps_support_atrac3
[11:41:49 CET] <mistym> I used the ATRAC bytes that vgmtoolbox notes to flag the presence of ATRAC and then assumed that any startcode under 0x20 is ATRAC in that case
[11:43:45 CET] <mistym> Works with your Utawarerumono sample, plus the 3rd Birthday .PMF file and AFL .MPS file I was testing with
[11:44:14 CET] <SortaCore> ah
[11:44:22 CET] <SortaCore> then can we drop the deprecated pixel format warnings >.>
[11:51:29 CET] <wm4> IMO we should motivate durandal_1707 to continue
[11:54:02 CET] <SortaCore> do it durandal_1707
[11:54:08 CET] <SortaCore> don't let your memes be dreams
[11:55:18 CET] <thardin> don't let your dreams be memes
[11:59:07 CET] <JEEB> mistym: najs
[12:01:45 CET] <SortaCore> just use that sweet regex, replace all YUVJ420P so next line has color range set to jpeg
[12:01:52 CET] <SortaCore> I see no problems
[12:02:39 CET] <SortaCore> top ffmpeg contributor award when
[12:03:02 CET] <mistym> JEEB: Going to try resubmitting the patchset like this, unless you can think of any issues with that approach :b
[12:05:50 CET] <JEEB> mistym: if it otherwise is the same thing then the question I noted earlier still stands, hopefully someone will answer :P
[12:06:15 CET] <mistym> Yeah that one still applies :b So we'll see if anyone thinks it's an issue
[12:06:27 CET] <JEEB> if not then I would kind of be laughing :P
[12:06:46 CET] <JEEB> because that's what blocked the patch set back then
[12:06:57 CET] <mistym> A lot can change in four years
[12:07:02 CET] <JEEB> true
[12:08:21 CET] <JEEB> anyways, as a separate discussion I wonder which should be the "canonical format" for ATRAC3+ in FFmpeg. the MPEG-PS one with the per-packet headers sounds better, and in either case you would have to make sure the canonical one gets converted to whatever the container requires
[12:25:01 CET] <mistym> wrt modifying AVCodecContext from the parser, I suppose I could parse that data out the packet in the demuxer?
[12:36:24 CET] <cone-666> ffmpeg 03Paul B Mahol 07master:89bbf5c7ec18: avfilter: add hilbert source FIR filter
[12:47:49 CET] <KGB> [13FFV1] 15JeromeMartinez opened pull request #87: Change remaining_bits_in_bitstream to remaining_bits_in_block (06master...06blocks) 02https://git.io/vNvVU
[12:48:29 CET] <KGB> [13FFV1] 15JeromeMartinez opened pull request #88: Make the topmost value of the border column explicit (06master...06topmost) 02https://git.io/vNvVI
[12:49:19 CET] <KGB> [13FFV1] 15JeromeMartinez opened pull request #89: Replace color space wording by more adapted transformation wording (06master...06transformations) 02https://git.io/vNvVm
[12:50:13 CET] <KGB> [13FFV1] 15JeromeMartinez opened pull request #90: Use Golomb Rice wording when applicable (06master...06VLC) 02https://git.io/vNvVZ
[12:50:40 CET] <Guest87975> [13FFV1] 15JeromeMartinez opened pull request #91: Add get_bits() definition (06master...06get_bits) 02https://git.io/vNvVc
[13:16:05 CET] <durandal_1707> which crossover to use for bandsplit filter?
[13:20:17 CET] <durandal_1707> some audiophiles claim LT4 is worse than LT2
[14:05:28 CET] <wm4> BBB: technically you maintain the http code, could you review my reconnect patch?
[14:37:20 CET] <BBB> technically :-p
[14:37:28 CET] <BBB> dont I technically maintain some rtp code also?
[14:39:51 CET] <BBB> is this enabled by default, or is it some AVOption you have to set on http?
[14:40:21 CET] <BBB> my question is: could this lead to situations where the current behaviour is that it exits and the new behaviour will be that the user thinks it hangs?
[14:40:36 CET] <BBB> (even if it didnt hang but the user just blindly updated)
[14:40:43 CET] <BBB> (and no interrupt handler was set)
[14:56:28 CET] <durandal_1707> atomnuker: you can already have all sorts of multiband compressors with ladspa and lv2 filters
[14:59:09 CET] <wm4> BBB: it's an avoption, off by default
[14:59:51 CET] <wm4> BBB: I wanted to use it, but the fact hat it returns an error if the first reconnect fails breaks streaming
[15:00:03 CET] <wm4> so I'd say this is just sort of a bug fix
[15:02:44 CET] <BBB> yes, ok, then its fine
[15:03:00 CET] <BBB> if it was on-by-default, I would have suggested adding a log message while its reconnecting
[15:03:18 CET] <BBB> as a warning or so, just so the user has some kind of faint idea whats going on
[15:03:47 CET] <BBB> (is info on by default?)
[15:04:27 CET] <wm4> there's a second patch which raises the log message level
[15:04:35 CET] <BBB> oh nice
[15:04:36 CET] <BBB> cool
[15:04:41 CET] <BBB> ok no further comments then
[15:04:51 CET] <BBB> all good
[15:04:56 CET] <wm4> well thanks, then I'll push
[15:07:47 CET] <wm4> once I can even access the git repo
[15:16:35 CET] <cone-666> ffmpeg 03wm4 07master:8a108bdea06f: http: block while waiting for reconnecting
[15:16:36 CET] <cone-666> ffmpeg 03wm4 07master:1b283c4a0dde: http: bump message level for reconnect message and log timeout
[15:39:21 CET] <wm4> tls_opentls.c uses pthreads if HAVE_THREADS is defined, isn't this wrong?
[15:39:54 CET] <wm4> doesn't HAVE_THREADS only imply the ff_ defines are available?
[15:42:07 CET] <RiCON> tls_openssl*?
[15:42:45 CET] <wm4> err yes
[15:43:24 CET] <wm4> tls_gnutls does apparently the same thing
[15:43:26 CET] <nevcairiel> all our emulation things map to pthreads functions
[15:43:28 CET] <wm4> GCRY_THREAD_OPTION_PTHREAD_IMPL
[15:43:32 CET] <nevcairiel> so what else should it be
[15:44:13 CET] <wm4> do I want to know what that macro does
[15:44:53 CET] <wm4> nevcairiel: right, I confused that
[15:44:57 CET] <wbs> the GCRY one is for gcrypt, which gnutls has stopped using since quite a few years; if you drop gnutls < 3.x, you should be able to just ditch that part
[15:45:06 CET] <wbs> and hopefully the same for openssl thread safety callbacks
[15:45:22 CET] <wm4> yeah I see a GNUTLS_VERSION_NUMBER check here
[15:45:40 CET] <RiCON> and same for openssl
[15:45:51 CET] <RiCON> wait, no.
[15:46:05 CET] <wm4> I have no idea how important those old versions are for users
[15:46:11 CET] <wm4> or if anyone would not like dropping them
[15:46:53 CET] <wbs> the gnutls ones probably are safe to drop, they were old (but still required) back when the libavformat tls code was written 6 years ago
[15:47:05 CET] <wm4> looking around in the gnutls header files I see a gnutls_global_set_mutex()
[15:47:53 CET] <wm4> oh nice, it documents that it defaults to OS API, and you should not use it
[15:55:48 CET] <wm4> nice, newer gnutls make gnutls_global_init thread safe, apparently
[15:55:53 CET] <wbs> yes
[15:56:00 CET] <wm4> GNUTLS_STATIC_MUTEX(global_init_mutex);
[15:56:21 CET] <wbs> I think this became really nice since 3.0 or so
[15:56:43 CET] <wm4> their win32 code for this is bogus
[15:57:02 CET] <wm4> or, lets say, questionable
[15:57:36 CET] <wm4> http://sprunge.us/PfIe 
[15:58:04 CET] <wm4> good enough as far as I'm concerned
[15:58:27 CET] <nevcairiel> its fine, but has the uglyness of leaking the mutex
[15:58:54 CET] <wm4> yep, and it's not our problem... and maybe they'll eventually drop XP support and fix it
[16:01:46 CET] <kierank> michaelni: ping
[16:01:46 CET] <wm4> I find it harder to tell what openssl does
[16:06:10 CET] <wm4> in any case newer openssl seems to be safe(r)
[16:06:41 CET] <wm4> so yeah, I don't see any reasons to care about this stuff anymore
[16:07:09 CET] <wm4> we could deprecate avformat_network_init
[16:10:33 CET] <wm4> SSL_library_init is kind of unsafe even in openssl-1.1.0g
[16:14:14 CET] <wm4> ok it's good enough if you ask me
[16:14:31 CET] <wm4> there's some silly stuff about the openssl lib registering an atexit handler for uninit...
[16:49:31 CET] <cone-666> ffmpeg 03Humberto Ribeiro 07master:59b126f92225: libavutil/hwcontext_dxva2: Add check for possible errors from GetAdapterDisplayModeEx
[16:49:31 CET] <cone-666> ffmpeg 03wm4 07master:18fbfd7bf86e: hwcontext_dxva2: initialize D3DDISPLAYMODEEX correctly
[17:03:14 CET] <wm4> so there were almost no code changes required to make those network init functions optional
[17:28:00 CET] <michaelni> kierank, pong
[17:35:26 CET] <atomnuker> jamrial: can I apply the ffserver removal patches now even though the bump period isn't over?
[17:35:49 CET] <atomnuker> I can wait until Chloe's patches are ready
[17:47:15 CET] <jamrial> atomnuker: yeah, once we can remove the lavu atomic stuff, we remove everything at once
[17:47:26 CET] <Chloe> atomnuker: do that first I think. I've got tons of school work I need to do before the 8th
[17:48:27 CET] <nevcairiel> just replace the atomic stuff with static mutexes now that we have those for windows, and dont rush the other things
[17:58:02 CET] <wm4> I think those Chloe patches actually don't require ABI bumps, or do they?
[17:58:22 CET] <Chloe> they shouldnt no
[17:58:28 CET] <Chloe> they just deprecate certain things
[17:58:29 CET] <Chloe> oh
[17:58:50 CET] <Chloe> They 'clarify' some functionality in registering internal components
[17:59:09 CET] <Chloe> you can no longer register them through the external API, so maybe
[17:59:10 CET] <atomnuker> they indirectly do since then we can remove the avpriv atomic stuff
[17:59:18 CET] <atomnuker> wm4: so is the AV_CODEC_CAP_SUBFRAMES deprecation patch okay? we have 2 ways to output multiple frames from decoders and that'll just be messy
[17:59:42 CET] <nevcairiel> like I keep saying repeatedly, there are far easier and simpler options to get rid of the avpriv atomics to finally finish the unstable period
[17:59:43 CET] <wm4> atomnuker: I'm just saying it's barely related to the new API
[17:59:56 CET] <Chloe> av_register_codec() no longer actually registers an external codec
[18:00:13 CET] <wm4> atomnuker: the old API could return multiple frames per packet, the new API can
[18:00:30 CET] <wm4> just that the new API makes this simpler (probably)
[18:00:45 CET] <atomnuker> nevcairiel: welp, a month ago you volunteered to replace one to show how its done
[18:00:48 CET] <wm4> Chloe: IMO that's fine because the only API users doing this would have violated the API anyway
[18:01:17 CET] <jamrial> i'm with nevcairiel, lets just remove the lavu atomic stuff in the _register() functions using static mutexes for now
[18:01:32 CET] <jamrial> we can then see about Chloe patches after a few review rounds
[18:01:37 CET] <Chloe> wm4: this is what I assumed. Then my patches can wait
[18:01:44 CET] <atomnuker> wm4: the subframes thing is a hack and the doxygen comment says only to use it as a last resort
[18:01:55 CET] <Chloe> jamrial: they still need a bit of work, I also need to do lavfi so i think it'd be better to not rush them
[18:01:59 CET] <atomnuker> so yeah, it'll simplify things
[18:02:59 CET] <KGB> [13FFV1] 15retokromer opened pull request #95: add v4_notes (06master...06patch-2) 02https://git.io/vNfY6
[18:06:55 CET] <atomnuker> wm4: could you check/okay the 2 patches on the ml then?
[18:07:23 CET] <atomnuker> I can make a new ifdef for the second patch if you think its better
[18:07:45 CET] <wm4> why bother, you've recently pushed a much larger change against my disagreement
[18:07:58 CET] <wm4> personally I don't care of the CAP disappears though
[18:08:28 CET] <nevcairiel> the cap does nothing but control a warning anyway
[18:08:50 CET] <wm4> yep
[18:08:55 CET] <wm4> and it's sometimes wrong
[18:10:29 CET] <durandal_1707> so? should i do crossover filter until atomnuker does atrac9?
[18:10:57 CET] <cone-666> ffmpeg 03wm4 07master:2477bfe22121: http: avoid logging reconnect warning if stream was aborted
[18:11:16 CET] <SortaCore> is there a code style checker for ffmpeg patching?
[18:11:38 CET] <SortaCore> I want to fix Intel QSV so I don't have to change the implementation from any to hardware-any every time
[18:11:39 CET] <jamrial> SortaCore: tools/patcheck
[18:12:05 CET] <jamrial> it can give some false positives, though
[18:12:11 CET] <SortaCore> how use?
[18:12:14 CET] <SortaCore> I'm on Windows
[18:12:29 CET] <SortaCore> ah, it's a bash thing?
[18:12:34 CET] <SortaCore> I'll run it under mingw then
[18:13:30 CET] <jamrial> yes
[18:16:46 CET] <atomnuker> wm4: because if you don't review it then who else will?
[18:18:03 CET] <atomnuker> durandal_1707: could you do some kind of an image fingerprinting filter?
[18:18:33 CET] <atomnuker> e.g. feed it an image, it spits out some kind of a fingerprint and you can then compare it to other fingerprints of images
[18:19:01 CET] <atomnuker> so you could check an entire directory for identical/low resolution copies of images
[18:19:40 CET] <durandal_1707> atomnuker: ask youtube to dump its code for checking copyright of uploads
[18:20:47 CET] <atomnuker> that's how you get doublecrossed, you get it, they say you've gotten it illegaly and you're off to court
[18:21:50 CET] <atomnuker> (it has so many false positives these days no one with over 10000 subscribers is okayd afaik)
[18:22:46 CET] <durandal_1707> isnt there already gpl version of filter that does same thing?
[18:29:45 CET] <jamrial> nevcairiel: something like this? https://pastebin.com/za3CcxwH
[18:30:57 CET] <nevcairiel> jamrial: the logic is really confusing for me, does it really put stuff at the top of the parser list?
[18:31:35 CET] <jamrial> nevcairiel: i basically reverted the functions to the point they were before the atomic rewrite was done, then added the mutexes
[18:31:48 CET] <nevcairiel> its probably fine then
[18:32:11 CET] <nevcairiel> its still practically impossible to test their thread safety
[18:32:41 CET] <wm4> atomnuker: what was the title?
[18:34:03 CET] <cone-666> ffmpeg 03James Almer 07master:b4eeffffc893: configure: update minimum required version of libvmaf
[18:36:22 CET] <atomnuker> wm4: "avcodec: move the old decoding/encoding API under and ifdef", second patch for the subframes cap is a reply to it
[18:37:53 CET] <wm4> atomnuker: jamrial apparently had comments
[18:47:22 CET] <durandal_1707> atomnuker: there are bunch of ways how to do fingerprinting,  haar wavelet seems nice for this
[18:53:35 CET] <atomnuker> makes sense that wavelets would be suitable, they essentially store progressively downsized images + diffs
[18:55:11 CET] <kierank> michaelni: what is the relevance of 03b82b3ab9883cef017e513c7d0b3b986b3b3e7b to "Do not attempt to	render into frames already output"
[18:56:22 CET] <wm4> fuzzing
[18:56:25 CET] <michaelni> kierank, the testcase doesnt work before that commit, it seems decoding goes a slighty different path
[18:56:52 CET] <kierank> apart from OOM I don't see how that can be the case
[18:56:58 CET] <kierank> well, threading
[18:57:05 CET] <kierank> as well
[18:58:22 CET] <michaelni> i dont know / didnt debug this to the point to know exactly but there where warnings aboutz overread, so maybe something after the initialized arrays threw it in a different branch
[19:22:53 CET] <cone-666> ffmpeg 03James Almer 07master:414a49d6710d: ffmpeg: use thread wrappers for the thread message functionality
[19:22:54 CET] <cone-666> ffmpeg 03James Almer 07master:8d9c9775b248: avutil/log: use thread wrappers for the locking functionality
[21:25:10 CET] <SortaCore> durandal_1707: why'd you drop the yuvj removal?
[21:28:06 CET] <durandal_1707> SortaCore: not enough motivation
[21:28:37 CET] <SortaCore> not enough of Shia LaBeouf?
[21:34:29 CET] <atomnuker> durandal_1707: plz deprecate yuvj or it won't be gone for 4 years
[21:35:19 CET] <atomnuker> jkqxz: sent a vaapi patch to the ml
[21:35:31 CET] <CoreX> so this guy last night was having a problem and i get the same thing
[21:35:32 CET] <CoreX> [00:42:35] <Guest39271> Hi, I'm trying to install ffmpeg with H.264 from source.  I installed H.264 libraries using VideoLan.  However, when compiling ffmpeg, its libavcodec/libx264.c is looking for a defined name "x264_bit_depth", which does not exist in either x264_config.h or x264.h generated by VideoLan H.264.  Does anyone know how I could fix this?
[21:35:37 CET] <CoreX> whats causing it ?
[21:36:15 CET] <philipl> Apple joins AOM. Seems huge.
[21:40:30 CET] <atomnuker> their plan to bet on hevc failed
[21:40:33 CET] <durandal_1707> SortaCore: who?
[21:40:51 CET] <jdarnley> CoreX: your ffmpeg is too old for the new changes to x264
[21:40:57 CET] <microchip_> CoreX: recent changes to x264. get ffmpeg git master
[21:41:00 CET] <philipl> the patent licensing monster ate its children.
[21:42:52 CET] <jkqxz> atomnuker:  Why?  IMO the X11 thing isn't really wanted there any more because it causes more confusion than it helps.  (Though I haven't actually tried to do that because compatibility something something.)
[21:43:53 CET] <wm4> philipl: holy shit
[21:44:18 CET] <wm4> maybe they joined only to sabotage it trollol
[21:45:27 CET] <rcombs> philipl: source?
[21:47:14 CET] <rcombs> oh http://aomedia.org/about-us/
[21:47:51 CET] <atomnuker> jkqxz: what do you mean?
[21:48:17 CET] <KGB> [13FFV1] 15michaelni closed pull request #88: Make the topmost value of the border column explicit (06master...06topmost) 02https://git.io/vNvVI
[21:48:48 CET] <atomnuker> the point is to be able to just do -hwaccel vaapi and not have to find your drm handle and do -vaapi_device /dev/dri/renderxxxx
[21:48:57 CET] <jkqxz> In Wayland, why would you ever use not-DRM?
[21:49:14 CET] <jkqxz> To do anything with Wayland you need to manage your own connection anyway.
[21:49:35 CET] <jkqxz> (The stupid window system integration stuff which shouldn't be in libva at all, I mean.)
[21:49:49 CET] <atomnuker> well fine, should I submit a patch to remove the x11 stuff?
[21:49:57 CET] <wm4> some drivers certainly needed it
[21:50:09 CET] <wm4> but with DRM everything interops nicely I guess
[21:50:29 CET] <wm4> is there any reasonable logic which DRM device should be selected?
[21:52:20 CET] <philipl> rcombs: yeah.
[21:52:41 CET] <philipl> It seems so weird that Apple sat on the fence for so long, and then jumped on hevc when it was already clear which way the wind was blowing. Then this.
[21:54:40 CET] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vNfiZ
[21:54:40 CET] <KGB> 13FFV1/06master 1411c75cb 15Jérôme Martinez: Clarify the difference between Pixel and Sample...
[21:56:24 CET] <cone-666> ffmpeg 03Misty De Meo 07master:fde057dfb25e: aiff: add support for XA ADPCM
[21:56:50 CET] <jkqxz> atomnuker:  I don't strongly mind it, I just thing it's kindof confusing to have the window system connections when you can't actually do anything with them (IMO having X11 originally was a mistake).
[21:57:24 CET] <jkqxz> The putting it before X11 is presumably because xwayland doesn't have DRI2 and that barfs somehow in libva IIRC?
[21:58:01 CET] <KGB> [13FFV1] 15JeromeMartinez opened pull request #96: Makes bits_per_raw_sample more generic (06master...06bits_per_raw_sample) 02https://git.io/vNfiV
[21:58:41 CET] <KGB> [13FFV1] 15ablwr opened pull request #97: change definitions from use of luminance to use of luma (06master...06ab/luma-in-definitions) 02https://git.io/vNfiM
[21:58:54 CET] <jkqxz> (I know the libva X11 init aborts when run over ssh forwarding, which does annoy me.  I should fix that at some point...)
[21:59:12 CET] <wm4> "aborts"?
[21:59:26 CET] <wm4> as in tries to use it and fails instead of using DRM?
[22:00:23 CET] <jkqxz> Yeah, I mean aborts.
[22:00:49 CET] <wm4> abort()?
[22:01:51 CET] <jkqxz> <https://0x0.st/sZKm.txt>
[22:02:30 CET] <wm4> oh that shit
[22:02:40 CET] <wm4> it should at least have been XCB
[22:02:51 CET] <wm4> because X11's "error handler" is ridiculous
[22:03:35 CET] <wm4> it aborts by default and it's process global
[22:03:57 CET] <jkqxz> Yeah.  Can't turn an X11 connection into an XCB connection though, so hysterical raisins fuck you over.
[22:04:18 CET] <jkqxz> DRI3 only works over XCB, too, which is a pain.
[22:05:10 CET] <wm4> would we need that? vaapi has a xcb API right?
[22:05:33 CET] <wm4> also there's some sort of x11/xcb interop, but forgot how it works
[22:05:50 CET] <wm4> modern xlib actually uses xcb
[22:05:57 CET] <atomnuker> I don't think so, there's no xcb mention anywhere in va/va_x11.h
[22:06:11 CET] <jkqxz> Yeah.  You can make an X11 connection from XCB, but not the other way around.
[22:06:16 CET] <jkqxz> No XCB in VAAPI, yeah.
[22:06:27 CET] <wm4> oh, weird
[22:06:33 CET] <wm4> pretty fucked up
[22:08:07 CET] <wm4> (ok, you can get a xcb_connection_t from a X11 Display, useless here)
[22:11:49 CET] <atomnuker> jkqxz: if you don't mind it can you give me an lgtm? its not big and can be removed alongside the x11 thing whenever you get around to it
[22:12:31 CET] <jkqxz> Sure.
[22:12:42 CET] <jkqxz> I assume there is no better way to identify a wayland display name?
[22:16:56 CET] <atomnuker> there is, through the WAYLAND_DISPLAY variable
[22:17:44 CET] <atomnuker> wl_display_connect reads it when the string its given is NULL
[22:18:28 CET] <wm4> shouldn't you pass the device string there
[22:18:30 CET] <jkqxz> You shouldn't always pass NULL if there is a device string.  You'll connect to WAYLAND_DISPLAY by default even with device = ":1" something.
[22:18:33 CET] <jkqxz> I replied.
[22:18:35 CET] <wm4> the av API one
[22:19:00 CET] <durandal_1707> nothing can motivate me to work on yuvj shit removal, except $$$, maybe as next gsoc
[22:20:18 CET] <atomnuker> I guess I can, I just copied what x11 did
[22:20:21 CET] <atomnuker> durandal_1707: :(
[22:21:28 CET] <jkqxz> X11 doesn't pass NULL.
[22:21:42 CET] <cone-666> ffmpeg 03Humberto Ribeiro 07release/3.4:7c3d519df90f: libavutil/hwcontext_dxva2: Add check for possible errors from GetAdapterDisplayModeEx
[22:21:43 CET] <cone-666> ffmpeg 03wm4 07release/3.4:4a53ecb12ead: hwcontext_dxva2: initialize D3DDISPLAYMODEEX correctly
[22:36:03 CET] <atomnuker> sent a v2
[22:37:23 CET] <jkqxz> Er, what?  Just pass the device string directly.  If it's null then the library reads the environment variable (or at least I assume it does, that's what X does).
[22:38:39 CET] <atomnuker> oh, I get it
[22:40:35 CET] <wm4> I also sent a comment
[22:42:54 CET] <cone-666> ffmpeg 03Marton Balint 07master:f528c49c7cd1: avfilter/vf_framerate: calculate interpolation as integer
[22:45:04 CET] <KGB> [13FFV1] 15michaelni pushed 2 new commits to 06master: 02https://git.io/vNfDd
[22:45:04 CET] <KGB> 13FFV1/06master 1449a47b1 15Jérôme Martinez: Add get_bits() definition
[22:45:04 CET] <KGB> 13FFV1/06master 14cfb65d4 15Jérôme Martinez: Change "current position" to "pointer"...
[22:45:26 CET] <atomnuker> wm4: so you want something like "if (!display && device && !strcmp(device, "wayland"))"?
[22:45:56 CET] <atomnuker> but what if device is NULL?
[22:46:14 CET] <atomnuker> wayland's just going to get skipped which would make the patch useless
[22:49:11 CET] <wm4> if device is NULL that can probably be considered using "autodetection"
[22:49:18 CET] <wm4> so using wayland in that case would be fine
[22:49:36 CET] <wm4> I don't know how X11 device names are formatted and whether the string "wayland" could be valid
[22:49:53 CET] <wm4> sounds far fetched though, so why not
[22:52:57 CET] <atomnuker> what's the issue with just leaving it as it is?
[22:53:24 CET] <jkqxz> I think it's fine just checking for not '/' (assuming '/' isn't valid).
[22:53:37 CET] <atomnuker> it isn't
[22:54:14 CET] <jkqxz> Though if all wayland display names contain "wayland" that would be a nice check.
[22:54:25 CET] <jkqxz> (I've no idea if they do.  Google isn't helping much.)
[22:54:58 CET] <jkqxz> And then if you have an X11 display called "wayland" and it goes wrong then you will have deserved it.
[22:56:43 CET] <atomnuker> jkqxz / wm4: does this look okay then https://0x0.st/sZKx.patch
[22:56:56 CET] <atomnuker> it'll handle the case where you have an x11 display called wayland
[22:58:34 CET] <jkqxz> Wrong version?  That still has the incorrect NULL case.
[23:02:23 CET] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vNfSr
[23:02:23 CET] <KGB> 13FFV1/06master 14fdc65b7 15Jérôme Martinez: Makes bits_per_raw_sample more generic...
[23:05:54 CET] <atomnuker> jkqxz / wm4: bloody hell git, https://0x0.st/sZZb.patch
[23:06:34 CET] <atomnuker> (couldn't commit just amend too if there's any cached changes)
[23:08:12 CET] <jkqxz> Fine with me.
[23:08:24 CET] <jkqxz> (Commit message needs a fixup too.)
[23:11:42 CET] <wm4> that completely ignores anything I said on the post on the ML
[23:15:53 CET] <atomnuker> what you said makes no sense
[23:16:04 CET] <atomnuker> the display name may be NULL
[23:16:26 CET] <atomnuker> in which case checking for whether its a valid prefix is pointless and it'll get skipped
[23:17:26 CET] <wm4> ...
[23:17:45 CET] <wm4> if you add wayland, any user who tried to pass an X11 display name will break
[23:23:47 CET] <durandal_1707> how?
[23:24:43 CET] <atomnuker> no it doesn't, just "Cannot connect to a Wayland display" gets printed (verbose) and it the code carries on trying x11
[23:24:45 CET] <jkqxz> It shouldn't, should it?  The wayland connect thing will just go "wtf is this shit, return error".
[23:25:01 CET] <jkqxz> Unless the names really do collide, in which case you lose anyway.
[00:00:00 CET] --- Fri Jan  5 2018