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

[burek]

[01:06:38 CEST] <cone-580> ffmpeg 03Shiyou Yin 07master:90dc584d21eb: MAINTAINERS: add myself to MIPS section
[12:50:16 CEST] <gagandeepsingh> kierank: my new nick is this one
[12:50:38 CEST] <gagandeepsingh> do i send the file link here
[12:52:18 CEST] <kierank> sure
[12:53:56 CEST] <gagandeepsingh> cfhd.c : https://www.dropbox.com/s/ke4n7ru69iv13wi/cfhd.c?dl=0
[12:54:42 CEST] <gagandeepsingh> please just see what is wrong for intra part, i think that will help me iron out the bug
[12:55:15 CEST] <gagandeepsingh> i have the code for intra and ip (both progressive and interlaced samples) in this file
[13:02:18 CEST] <gagandeepsingh> kierank: here is the link to the patch containing the commits since interlaced feature has been added
[13:02:19 CEST] <gagandeepsingh> https://www.dropbox.com/s/nyup7ppeyllxbf7/patch.patch?dl=0
[13:04:32 CEST] <gagandeepsingh> just that the commits are not perfect right now, they are a mess, when i will send the patch to ffmpeg, the commits will be done in consistent manner
[16:18:57 CEST] <klaxa> atomnuker: i just pushed my latest version + more documentation (as recommended by the submission guideline) to https://github.com/klaxa/ffserver
[16:20:29 CEST] <klaxa> if you can think of something to add or so, would be good to know
[16:23:51 CEST] <klaxa> or maybe if i should put it somewhere else or whatever
[19:00:46 CEST] <durandal_1707> why I get completly white block with add idct for some blocks and not all of them, video decodes otherwise mostly fine
[19:01:10 CEST] <kierank> overflow
[19:12:39 CEST] <January> durandal_1707: can give you that code when I get home, sorry didnt get round to it yesterday
[19:14:38 CEST] <durandal_1707> January: for scpr?, sure. no rush
[19:17:18 CEST] <January> durandal_1707: Actually would have liked to finish it but have absolutely no time, just working and sleeping.
[19:18:25 CEST] <durandal_1707> January: there are no free days?
[19:19:34 CEST] <January> durandal_1707: guess its easy to forget about weekends
[20:27:39 CEST] <durandal_1707> avast antivirus is poc, it killed my msys32 while it was updating
[20:30:25 CEST] <BtbN> avast also bought CCCleaner and stuffed it full with malware
[20:32:03 CEST] <nevcairiel> the majority of antivirus tools cause more pain then they prevent
[20:32:44 CEST] <nevcairiel> and as a side note, windows defender actually has one of the best detection rates among all of them now
[20:36:15 CEST] <nevcairiel> (not to say that it doesn't also sometimes cause such pain)
[20:51:59 CEST] <atomnuker> I used to use avira back in the day
[20:52:19 CEST] <atomnuker> keep in mind last time was more than 10 years ago
[21:01:29 CEST] <durandal_1707> how to install ubsan enabled gcc on msys32?
[21:02:32 CEST] <gnafu> A friend recently got a new laptop, texted me wondering whether they should pay to keep McAfee registered.  I winced, then told them to uninstall it and just use Windows Defender.
[21:13:37 CEST] <jamrial> durandal_1707: not sure if you can use gcc ubsan/asan on windows at all
[21:15:35 CEST] <January> durandal_1707: https://github.com/januaryjp/FFmpeg/commit/09a92df20dbd0340da5deac89c975c00e2763086 it may or may not be useful, I was probably doing it a very roundabout way
[21:22:56 CEST] <durandal_1707> jamrial: then what they use?
[23:25:26 CEST] <atomnuker> Gramner: what did REP_RET do again? I see a bunch of nops after return
[23:25:44 CEST] <atomnuker> what kind of a screwup did amd make to need that ages ago?
[23:26:25 CEST] <Gramner> workaround for ancient amd cpus when ret was the target of a branch or directly followed a branch. it emits rep; ret; instead of just ret as a workaround for that bug
[23:26:44 CEST] <Gramner> tbh it's kind of pointless nowadays, I wouldn't use it for new code
[23:27:12 CEST] <Gramner> the bug was that it had a performance hit
[23:27:28 CEST] <atomnuker> yeah, I know, I tried to remove it last year because x86inc should handle that for you but it didn't and some binaries changed
[23:27:54 CEST] <Gramner> x86inc handles it automatically when following a branch, but not when it's a branch target
[23:28:05 CEST] <Gramner> (because it has no way of knowing that it's a branch target)
[23:28:27 CEST] <atomnuker> yeah, I guess I can try to remove it again but this time only on where its not needed and x86inc would handle that for you
[23:28:36 CEST] <Gramner> just use RET and forget about it basically
[23:28:56 CEST] <Gramner> the number of users of such amd cpus at this age must be like <0.001%
[23:28:57 CEST] <atomnuker> I want to but jamrial objected and wanted there to be no change in the binaries
[23:29:19 CEST] <nevcairiel> just leave existing code as-is, its not like it costs you anything at all to have it there right now
[23:29:44 CEST] <atomnuker> well it is an extra instruction to decode, it does affect performance somewhat
[23:30:00 CEST] <atomnuker> unmeasurably
[23:30:13 CEST] <atomnuker> what CPUs are affected? athlons?
[23:31:05 CEST] <Gramner> don't remember exactly. K8 probably?
[23:31:54 CEST] <atomnuker> yeah, they don't even have pshufb, not sure how you'd do high performance simd on those machines
[23:33:16 CEST] <Gramner> it's easy - you don't
[23:33:19 CEST] <Gramner> solved
[23:33:47 CEST] <atomnuker> I would be less annoyed if I didn't have REP_RET in my code, but unfortunately I do
[23:34:12 CEST] <atomnuker> now I either have to remove it all or do nothing
[23:34:18 CEST] <nevcairiel> should really find real problems to get worked up about
[23:34:35 CEST] <atomnuker> yeah, like that lavu fft I've been working on
[23:34:43 CEST] <atomnuker> or ffv2
[23:46:25 CEST] <jamrial> atomnuker: ask BBB. he wrote sse2 simd for vp9 and made 1080p 30fps videos work on dual core athlons (k10, though)
[23:48:20 CEST] <jamrial> and if you want to remove REP_RET from your simd then do it
[23:53:35 CEST] <atomnuker> k10 still didn't have pshufb but at least it had fast packs and unpacks
[23:59:08 CEST] <cone-873> ffmpeg 03Colin NG 07master:af4c2acddd15: libavformat/dashdec: Fix for un-free memory
[00:00:00 CEST] --- Thu Aug  9 2018