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

[burek]

[01:40:49 CEST] <lrusak_> anyone know why this happens?:
[01:40:50 CEST] <lrusak_> Assertion *(const AVClass **)avctx->priv_data == codec->priv_class failed at libavcodec/utils.c:998
[01:41:58 CEST] <lrusak_> ah, similar fix here, http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=b942845beedc369cf0684eb332e3cd8cd00c13d0
[01:42:42 CEST] <nevcairiel> yeah if you use options, the struct needs to include AVClass
[03:55:38 CEST] <x420> where did trac go
[03:55:50 CEST] <x420> seems down for me
[03:59:47 CEST] <jamrial> works here
[04:00:44 CEST] <jamrial> although kinda slow
[04:04:07 CEST] <x420> can ping it but times out on 80 and 443 for me idk
[04:04:10 CEST] <x420> oh well
[16:26:25 CEST] <cone-476> ffmpeg 03Jeremy Dorfman via ffmpeg-devel 07master:bb5efd1727ee: avformat/av1: Initialize padding in ff_isom_write_av1c
[16:29:21 CEST] <durandal_1707> jamrial: now you, previously michaelni, same error
[16:31:16 CEST] <jamrial> ugh
[16:32:08 CEST] <jamrial> yeah, my fault, i don't run any script to catch these. i just didn't pay enough attention
[16:32:43 CEST] <jamrial> it's annoying how google emails get mangled like this
[19:02:12 CEST] <j-b> Can we not do that, again?
[19:04:02 CEST] <JEEB> gitlab when (´ûÉû@) (only half-jokingly)
[19:13:38 CEST] <thardin> gitmab is ok
[20:34:49 CEST] <durandal_1707> gitmob
[20:43:58 CEST] <durandal_1707> who gonna RE blackmagic and prores RAW?
[20:46:25 CEST] <gnafu> Is that like a flash mob?
[20:46:42 CEST] <gnafu> A bunch of people committing several tiny typo fixes all at once.
[20:46:50 CEST] <gnafu> Or code formatting changes.
[21:19:55 CEST] <philipl> BtbN: so this ticket #7674. The guy who reopened it pinged me on devtalk too. It seems on the surface that cleaning up after yourself and avoiding a resource leak leads to a big performance penalty.
[21:20:13 CEST] <philipl> I think we should throw it to an nvidia person to deal with.
[21:21:28 CEST] <BtbN> Yeah, removing the deregistering is incorrect and only works because the hwframes_ctx keeps reusing the same frames over and over again
[21:21:40 CEST] <BtbN> Which cannot be safely assumed in nvenc
[21:22:16 CEST] <BtbN> His usecase is such an edge case that I have a hard time caring. Only breaks when using at least 50 encode sessions...
[21:49:53 CEST] <nevcairiel> I imagine there is a  certain overhead of resource management, and the special case of re-using the same stuff all the time avoids that
[21:50:03 CEST] <nevcairiel> why it suddenly kills performance is a bit odd, but who knows
[21:59:05 CEST] <BtbN> re-registering the same frame over and over again certainly does not feel right
[21:59:23 CEST] <BtbN> So that deregister got to be there. If it causes a serious performance impact, that's on the driver.
[22:00:20 CEST] <philipl> Could we, in theory, have some sort of hook that get registered with the hwframes_ctx so that we unregister when the frame gets deallocated?
[22:01:06 CEST] <philipl> Of course, better if nvidia fixes driver, but register/unregister is slow for many of their resource types.
[22:01:09 CEST] <philipl> Seems a tradition.
[22:02:19 CEST] <BtbN> In theory, yes. In practice, that would require some hackery to keep nvenc alive until the frame is freed
[22:02:29 CEST] <BtbN> which sounds dangerous and deadlocky to me
[22:03:11 CEST] <BtbN> Would need to work in a very similar fashion as it does in nvdec, except that nvenc does not produce the frames and thus can't set a custom deallocator
[22:40:48 CEST] <durandal_1707> oh no! black belt training in RE sold out: https://nullcon.net/website/goa-2019/training/black-belt-in-reverse-engineering.php
[22:42:00 CEST] <nevcairiel> it also happened a month ago a lready
[22:43:06 CEST] <BtbN> Talking about RE, i'm currently trying to reverse engineer some "encryption" algorithm arcade cabs use. I have the decompiled code Ghidra generated for the decrypt function, but holly hell they put some effort into making this obtuse.
[22:44:32 CEST] <nevcairiel> in my experience decompiled code hardly looks straight forward from the get go  =p
[22:44:45 CEST] <BtbN> It does a surprisingly good job
[22:45:02 CEST] <BtbN> Since it uses no external functions and just shuffles around on a block of memory
[22:45:19 CEST] <durandal_1707> just reproduce decompiled function, you can even compile it with minor changes if it is not referencing extra stuff
[22:45:52 CEST] <BtbN> It's 6 layers deep of memory shuffling functions though
[22:46:23 CEST] <BtbN> I guess I could just straight up copy the decompiled C code, and it'd work.
[22:46:46 CEST] <durandal_1707> well, it may not work always,...
[22:47:54 CEST] <JEEB> BtbN: they just open sourced the decompiler C++ module I think
[22:47:56 CEST] <JEEB> @ ghidra
[22:48:18 CEST] <BtbN> nice, but I doubt that'd help me. At least immediately.
[22:48:26 CEST] <BtbN> In the long run it'll probably greatly improve its quality.
[22:48:43 CEST] <durandal_1707> you can also use retdec
[22:48:45 CEST] <BtbN> I'm still a bit confused about their intention with releasing Ghidra, but I take it
[22:49:11 CEST] <JEEB> BtbN: it's a PR thing mostly
[22:49:16 CEST] <JEEB> but yes
[22:49:38 CEST] <JEEB> it doesn't seem to be a generally OK thing
[22:49:48 CEST] <JEEB> so yes, taking it :)
[22:50:30 CEST] <BtbN> Maybe someone higher up at the NSA got seriously upset about Hexrays
[22:50:46 CEST] <BtbN> Cause they are right now actively harming their business quite a bit
[22:51:12 CEST] <JEEB> yup
[22:51:50 CEST] <JEEB> granted, this seems to fit their defensive role. by releasing this they bring good reverse engineering tools into the hands of many whom the NSA is supposed to defend
[22:52:24 CEST] <JEEB> (and yes, IDA Pro / Hex-rays loses some market share or at least doesn't get utilized in the manner it has been so far as much)
[22:52:43 CEST] <BtbN> They probably primarily will get pirated a lot less
[22:52:48 CEST] <JEEB> yea
[22:52:53 CEST] <durandal_1707> lol, it loses nothing
[00:00:00 CEST] --- Tue Apr  9 2019