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

[burek]

[03:20:17 CET] <cone-902> ffmpeg 03James Almer 07master:18507b48825d: avformat/avc: fix sps buffer offset when calling ff_avc_decode_sps()
[11:04:59 CET] <Lynne> I'm suprised, 2 people used to sign their commits via gpg but they stopped some time ago
[13:31:43 CET] <thardin> https://www.youtube.com/watch?v=ym1brc2OcYQ  Kdenlive is a Garbage Fire (but there's a better tool)
[13:31:48 CET] <thardin> does libmelt not use multithreading?
[13:32:04 CET] <thardin> last time I poked with it it seemed p good
[13:33:01 CET] <ubitux> i confirm kdenlive is garbage
[13:33:36 CET] <Lynne> I heard blender is pretty good
[13:34:20 CET] <ubitux> last thing i tried was olive, it was ok, even though it was pretty basic with basically nothing
[13:35:00 CET] <ubitux> last shitty kdenlive bug i had was not being able freeze a frame and crop at the same time
[13:35:21 CET] <ubitux> seems it was a bug present in libmelt for years
[13:35:25 CET] <thardin> yeah kdenlive is terrible, but I had at least thought libmelt was decent enough
[13:35:48 CET] <thardin> I've successfully used it for the command-line editing
[13:35:54 CET] <thardin> s/the/some/
[13:46:17 CET] <durandal_1707> how do you create vtable inside ghidra?
[13:47:23 CET] <Lynne> what made you change from ida? the disasm looks worse than that
[13:48:17 CET] <durandal_1707> ida is piece of shit
[13:49:07 CET] <durandal_1707> the only ida i have does not play well with class inspector/informer, unless you buy me latest version i will continue to use ghidra
[13:51:12 CET] <durandal_1707> i tried various scripts that do this for ghidra, but they all basically fail
[13:51:15 CET] <ubitux> durandal_1707: there is a help for advanced stuff like this available in the doc
[13:51:30 CET] <ubitux> ah, you meant automatic
[13:51:56 CET] <ubitux> always done it manually so i dunno
[13:52:06 CET] <durandal_1707> ubitux: even manual if good to know
[13:52:36 CET] <JEEB> has ghidra been improved during the time post-initial release?
[13:52:42 CET] <durandal_1707> i see in assembly view just list of functions
[13:52:43 CET] <ubitux> durandal_1707: check GhidraDocs/GhidraClass/Advanced/improvingDisassemblyAndDecompilation.pdf
[13:52:54 CET] <ubitux> there are a few slides about this
[13:52:56 CET] <durandal_1707> i read that..
[13:53:22 CET] <ubitux> JEEB: yeah it improved quite significantly between releases
[13:53:27 CET] <ubitux> at least wrt bugs
[13:53:38 CET] <JEEB> nice
[13:54:11 CET] <ubitux> they still haven't adressed my simd issue though
[13:54:40 CET] <ubitux> https://github.com/NationalSecurityAgency/ghidra/issues/249
[13:55:21 CET] <ubitux> i should probably open an issue without the question label, since i'm unable to drop it
[13:55:59 CET] <durandal_1707> that is not garbage
[13:56:10 CET] <durandal_1707> its valid decompiler code
[13:56:12 CET] <ubitux> it's doing better with arm assembly though
[13:56:19 CET] <ubitux> durandal_1707: that's not the point
[13:57:09 CET] <durandal_1707> do you want original code with intrinsic stuff? or just better output
[13:57:32 CET] <ubitux> something close to the original intrinsic
[13:57:46 CET] <ubitux> but whatever the syntax they want as long as it is readable
[13:57:52 CET] <ubitux> they actually do that for neon
[14:00:51 CET] <cone-349> ffmpeg 03Andreas Rheinhardt 07master:76e0ecec0bfa: avcodec/extract_extradata_bsf: Don't unref uninitialized buffers
[14:02:28 CET] <durandal_1707> for creating vtable structure, i need to know singature of each function in vtable, this is not possible to guess i think?
[14:05:21 CET] <ubitux> i haven't played with a c++ codebase for a while, but i remembed having to create individual types for each method prototype
[14:05:40 CET] <ubitux> and then use them in the struct
[14:05:57 CET] <ubitux> there is probably a more efficient way of doing that nowadays
[14:06:02 CET] <ubitux> and likely a plugin to help with that
[14:10:10 CET] <durandal_1707> i tried plugin and it help only little
[15:06:48 CET] <Lynne> one thing which I find kinda sketchy about gpu filters is that they're sometimes not bitexact
[15:07:10 CET] <Lynne> like our nlmeans_opencl filter doesns't output the same results compared to the cpu one
[15:07:36 CET] <Lynne> and I think it even differs between vendors, since I can vaguely remember it behaving differently under nvidia and intel
[15:23:12 CET] <ubitux> Lynne: because float
[15:23:40 CET] <ubitux> also yeah, you can get random results depending on the chip, version of the drivers, etc
[15:23:47 CET] <ubitux> just like with compilers, systems, cpus
[15:24:30 CET] <ubitux> float and bitexact are a pita to deal with, you need to rely on thresholds for all the tests
[15:24:39 CET] <Lynne> its not like gpus don't have integer vectors too, you know
[15:25:22 CET] <Lynne> but you can't sample images then, so that's bad
[15:27:03 CET] <Lynne> and not sampling images means your code also runs slower because caching just isn't a big thing with reading storage images (from memory either nvidia or intel is slower, but not both)
[15:29:00 CET] <ubitux> let's be honest, they're not designed for dealing with ints at all
[15:57:06 CET] <kierank> you can get different results depending on some value of float
[15:57:31 CET] <kierank> I have seen some crazy optimisations that really matter between 98 and 99 or something 
[15:57:34 CET] <kierank> but all other values were fine
[16:03:48 CET] <cone-349> ffmpeg 03Andriy Gelman 07master:99d78e4f4249: lavc/extract_extradata: Use bytestream api
[16:03:49 CET] <cone-349> ffmpeg 03James Almer 07master:e5db2e96c02d: avformat/avc: add missing return error value
[23:26:44 CET] <durandal_1707> fun, braw uses internally 420 subsampling
[00:00:00 CET] --- Sun Dec  1 2019