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

[burek]

[03:10:56 CEST] <liyou> hi,all
[03:27:39 CEST] <cone-632> ffmpeg 03Sasi Inguva 07master:e7e1fbc49bf6: lavf/movenc.c: Set sgpd and sbgp atoms to represent decoder delay for AAC.
[04:21:29 CEST] <cone-632> ffmpeg 03James Almer 07master:c100330a8ff4: avformat/movenc: reindent after the previous commit
[10:50:38 CEST] <ubitux> durandal_1707: http://www.ipol.im/pub/art/2017/192/
[10:50:41 CEST] <ubitux> -vf addgrain?
[10:52:25 CEST] <durandal_1707> we have noise which is pretty fast
[10:53:00 CEST] <durandal_1707> im afraid their algo is sloow
[10:53:40 CEST] <ubitux> afaict it's depending on the input contrary to noise
[10:53:59 CEST] <ubitux> also, does noise have transparency so it's "overlayable" onto an input?
[10:54:46 CEST] <ubitux> not all filters are designed for real time anyway
[11:13:05 CEST] <atomnuker> proposal: how about making decoder pre-skip being handled by utils.c
[11:13:09 CEST] <atomnuker> cc wm4
[11:13:35 CEST] <atomnuker> so the data pointers in avframe would be offset by however many samples the pre-skip is
[11:14:15 CEST] <atomnuker> and nb_samples would be reduced by the preskip as well
[11:15:34 CEST] <atomnuker> thata way users wouldn't need to do anything special for audio formats
[11:17:33 CEST] <wm4> it already does that by default if the side data is used
[11:21:26 CEST] <atomnuker> wm4: ah, nevermind, its because opus is special
[11:21:52 CEST] <atomnuker> where your initial preskip can be arbitrary
[11:30:13 CEST] <wm4> we still should reduce it to 1 mechanism
[11:30:19 CEST] <wm4> instead of having 2 or 3
[11:34:43 CEST] <ZeroWalker> btw is I420 actually planar?
[11:35:00 CEST] <wm4> ffmpeg has no concept of I420
[11:35:39 CEST] <ZeroWalker> will see what ffmpeg translates it to
[11:36:52 CEST] <ZeroWalker> ah yeah it's AV_PIX_FMT_YUV420P, forgot i actually learned that before lol
[11:37:22 CEST] <ZeroWalker> so confusing when the format is called i420 from the source and then it's actually planar -_-
[11:38:39 CEST] <wm4> that's not confusing at all
[11:39:06 CEST] <ZeroWalker> lucky you;p
[11:39:16 CEST] <wm4> I420 usually refers to what ffmpeg calls YUV420P (just that I420 is often used on contexts where the planes are sequential in memory or so)
[11:39:38 CEST] <nevcairiel> not sure what the I is actually supposed to mean, if it means anything at all
[11:41:07 CEST] <ZeroWalker> but wait, isn't planar basically, you have the entire picture in Y, then U then V, it's not sequential, or well i guess it depends what you mean with that
[11:41:36 CEST] <ZeroWalker> yeah the 'i', we will never know what it means
[11:42:00 CEST] <nevcairiel> planar means that each plane is separate, but they might as well be in continous memory
[11:42:22 CEST] <jkqxz> It's perfectly valid with YUV420P for the chroma planes to be line-interleaved, say.  Some definitions of I420 might ban that.
[11:44:39 CEST] <ZeroWalker> so wait, how would one determine if it's line interleaved or not?
[11:45:37 CEST] <jkqxz> Look at the pointers and linesizes.  It doesn't matter to any software implementation, but hardware might care.
[11:46:06 CEST] <ZeroWalker> yeah well as i am working on shader conversion, that's probably kinda important xd
[11:49:10 CEST] <ZeroWalker> looking at the linesize it seems to be, 640,320,320 in this case. so i guess it's line interleaved, or:s?
[11:49:21 CEST] <nevcairiel> its not.
[11:49:34 CEST] <nevcairiel> that wouldnt really happen on software frames that avcodec outputs
[11:49:40 CEST] <nevcairiel> but it is in theory possible
[11:49:58 CEST] <ZeroWalker> this is an input, sorry about that
[11:50:13 CEST] <ZeroWalker> so it's produced by a webcam in this case
[11:50:41 CEST] <ZeroWalker> and i got the linesize by filling it out with the format
[11:50:43 CEST] <J_Darnley> Stop confusing the poor bastard.  Treat planes as planes in separate areas of memory.
[11:51:04 CEST] <ZeroWalker> :(
[11:52:37 CEST] <ZeroWalker> but that doesn't tell me that much, i mean, isn't it completely different if it's per line compared to the entire picture being split into 3 parts
[11:52:58 CEST] <J_Darnley> No.
[11:53:12 CEST] <J_Darnley> The data pointer points to the first byte of each plane
[11:53:28 CEST] <J_Darnley> the linesize tells youhow many bytes to the next row.
[11:54:02 CEST] <bencoh> you just end up with a different stride, that's all
[11:54:17 CEST] <J_Darnley> You don't care where exactly the data is relative to each other.
[11:54:39 CEST] <ZeroWalker> yeah well i am going to convert it in a shader, so i would need to be able to determine how it's structure myself. So the data being at different places makes all the difference
[12:11:30 CEST] <cone-103> ffmpeg 03Martin Storsjö 07master:9042402ec78a: d3d11va: Check WINAPI_FAMILY instead of HAVE_LOADLIBRARY
[12:40:11 CEST] <BtbN> I don't get that guys problem. The spec clearly says it has to be greater or equal. So being 1 second greater is perfectly fine and might safeguard for some broken players
[12:40:42 CEST] <BtbN> Never seen him state anything that breaks, except for maybe his sense for aesthetics
[12:44:16 CEST] <JEEB> lol
[12:44:23 CEST] <JEEB> usual case of derp
[12:44:39 CEST] <wm4> has anyone ever seen this assert trigger when building ffmpeg with mingw? https://github.com/bminor/binutils-gdb/blob/master/bfd/cofflink.c#L2341
[12:55:46 CEST] <BtbN> Trac detected an internal error: OperationalError: database is locked
[12:55:47 CEST] <BtbN> hm
[12:59:12 CEST] <Compn> that cant be good
[13:07:13 CEST] <JEEB> that probably means that there was a transaction that required a certain area that another request was trying to poke to be locked
[14:34:29 CEST] <J_Darnley> Do any of you know a good binary diff program?  I want to investigate the differences between two files I'm making.
[14:47:01 CEST] <RiCON> J_Darnley: https://github.com/dwbuiten/bxd ?
[14:47:58 CEST] <atomnuker> J_Darnley: vimdiff
[14:48:40 CEST] <atomnuker> best of all, you already have it
[15:17:55 CEST] <J_Darnley> bxd isn't too bad.  does exactly what I need from it.  It would benefit from knowing page up/down, home, and end keys.  Oh and maybe Ctrl-Z to suspend it.
[16:06:37 CEST] <cone-103> ffmpeg 03Vittorio Giovara 07master:8c34a2024da7: h264: Add support for alternative transfer characterics SEI
[16:06:38 CEST] <cone-103> ffmpeg 03Vittorio Giovara 07master:f3571048669b: pixfmt: Support chroma-derived and ictcp color matrices
[16:29:00 CEST] <durandal_1707> http://i.imgur.com/SyoFhJb.png
[17:15:49 CEST] <durandal_1707> nobody likes my demo?
[17:21:15 CEST] <durandal_1707> ok, no reason to continue its developement
[17:22:01 CEST] <ubitux> it's a screenshot of a textarea&
[17:24:05 CEST] <cbsrobot> ffedit - an editor for filtergraph escaping
[17:26:55 CEST] <durandal_1707> lol , coding gui app from sctrach for first time is demanding
[17:28:36 CEST] <ubitux> alias ffedit='ffplay -f lavfi "$(zenity --entry --text=filtergraph:)"'
[17:35:17 CEST] <durandal_1707> ubitux: ffplay does not allow frame accurate seeking
[17:35:46 CEST] <ubitux> lavfi doesn't allow seeking
[17:36:17 CEST] <durandal_1707> but one can seek to certain point
[17:36:41 CEST] <ubitux> you can replace ffplay with mpv if you prefer :p
[17:36:56 CEST] <ubitux> mpv has a lavfi input, no?
[17:37:28 CEST] <durandal_1707> mpv is mplayer offspring
[17:38:36 CEST] <durandal_1707> besides idea is not playback, but real gui
[18:41:59 CEST] <thebombzen> the patch I just sent (replacing --full-help with --fullhelp) fixes a typo in the documentation
[18:42:48 CEST] <thebombzen> I assume this is not controversial but if I missed some conventions I can resend
[19:08:54 CEST] <atomnuker> durandal_1707: is it going to be like a non-linear editor?
[19:09:42 CEST] <atomnuker> or is it just going to do basic trimming/picking a segment and applying effects on it (which change over time)?
[19:09:43 CEST] <kierank> avfilter can't seek so no
[19:10:34 CEST] <atomnuker> k, there are dozens of nles anyway
[19:12:34 CEST] <atomnuker> (lavfi doesn't really need to handle seeking imo, its up to the user to skip and feed it frames from another time)
[19:18:23 CEST] <durandal_1707> yes thats main idea, also what ubitux said providing nice 2D filtergraph view
[19:20:44 CEST] <thebombzen> you mean we're going to stop saying "get an NLE" whenever someone wants to do some really complicated non-sequential splice-and-edit
[20:24:38 CEST] <atomnuker> huh, an rpi 1 boots up fine with a 64 gig sd card
[20:25:12 CEST] <atomnuker> an overkill considering how slow it is, might as well make it run fate twice a day
[20:25:35 CEST] <atomnuker> fact: an rpi 1 consumes as much current under load as it does idling
[20:33:35 CEST] <kierank> atomnuker: lol rpi1
[21:00:46 CEST] <rcombs> can I use a Pi3 as an aarch64 dev board yet
[21:01:07 CEST] <rcombs> if not, what should I buy
[21:01:19 CEST] <rcombs> I need to get off my ass and learn ARM
[21:01:54 CEST] <BtbN> An actual arm64 android phone I guess?
[21:02:20 CEST] <rcombs> something with a real OS
[21:02:42 CEST] <rcombs> I mean, I once did get gcc running on android
[21:02:46 CEST] <rcombs> but it was hellish
[21:03:10 CEST] <rcombs> and I lost it all in an OS update (turns out those wipe the root partition)
[21:03:57 CEST] <BtbN> you can setup a debian chroot on android
[21:04:10 CEST] <BtbN> the root partition is usually wiped on reboot
[21:04:15 CEST] <BtbN> as it's only a tmpfs
[21:05:11 CEST] <BtbN> I might have to RMA my Ryzen...
[21:05:34 CEST] <BtbN> It's affected by the "crash while compiling gcc or mesa"
[21:08:04 CEST] <ubitux> rcombs: no you can't, unless you don't want PMU counters, wifi, or anything gpu related
[21:08:10 CEST] <ubitux> odroid is still okish
[21:08:22 CEST] <atomnuker> rcombs: I have an rpi3 running archlinux arm in 64 bit mode
[21:08:32 CEST] <BtbN> where did you get the firmware?
[21:08:35 CEST] <ubitux> atomnuker: with perf counters? :)
[21:08:55 CEST] <rcombs> that reminds me that I really need to learn to use linux's perf system
[21:08:56 CEST] <ubitux> rcombs: i'm currently waiting for the nanopi neo 2, for which i have some relatively high expectation
[21:09:00 CEST] <rcombs> I'm spoiled by Instruments on macOS
[21:09:05 CEST] <atomnuker> with absolutely nothing needing firmware, so only a CPU and an ethernet port, that's it
[21:09:07 CEST] <ubitux> (it might be available already depending on your country)
[21:09:12 CEST] <atomnuker> no wifi, bluetooth or even temperature sensor
[21:09:28 CEST] <rcombs> is there anything like that for perf
[21:09:31 CEST] <atomnuker> usb was unstable too I think when I tried it
[21:09:40 CEST] <rcombs> (Instruments is a GUI for dtruss, basically)
[21:10:32 CEST] <atomnuker> I can't imagine writing simd without the conveniences of x86_64 has
[21:10:48 CEST] <atomnuker> s/has//
[21:11:17 CEST] <J_Darnley> An operating system that works is now a convenience?
[21:11:44 CEST] <atomnuker> sure you have more registers than you know what to do with but the very last thing you do when writing simd is using more regs than you can skimp with
[21:12:32 CEST] <rcombs> ubitux: it is!
[21:12:42 CEST] <ubitux> you sure?
[21:12:50 CEST] <rcombs> yeah, it's on Amazon
[21:12:57 CEST] <ubitux> url?
[21:13:06 CEST] <ubitux> you checked it's the h5 cpu?
[21:13:09 CEST] <rcombs> https://www.amazon.com/Allwinner-High-performance-Quad-Core-Running-UbuntuCore/dp/B0728LPB2R
[21:13:16 CEST] <ubitux> sounds like it
[21:13:26 CEST] <ubitux> i have to wait for end of september for my country, but well
[21:13:36 CEST] <atomnuker> allwinner is junk
[21:13:48 CEST] <ubitux> anyway, i can't give any guarantee, though there are a lot of mainline effort for these boards
[21:13:55 CEST] <ubitux> atomnuker: mainline support is good :)
[21:13:56 CEST] <J_Darnley> BtbN: Is there any Ryzen that isn't affected by that bug?  I have heard that EPYC and ThreadRipper might not be
[21:14:17 CEST] <BtbN> From the looks of it, only the very first few production runs are affected
[21:14:18 CEST] <ubitux> atomnuker: basically, only sunxi boards give me mainline support 
[21:14:28 CEST] <BtbN> so just getting a replacement that was manufactured later fixes it
[21:14:29 CEST] <ubitux> which is a shame given the shady company, but the community does a good work
[21:14:50 CEST] <J_Darnley> Ah that's good no know.  The longer I delay in buying one myself the better my chances.
[21:14:54 CEST] <ubitux> damnit, that nanopi form factor is cute
[21:14:55 CEST] <atomnuker> I've had nothing but bad experiences with allwinner, though that was 4 years ago now
[21:15:02 CEST] <rcombs> so, what, ODROID-C2 if I want something that performs well for testing?
[21:15:05 CEST] <atomnuker> they were also very hardcore android-centric
[21:15:15 CEST] <BtbN> buying one right now is pretty much safe
[21:15:25 CEST] <BtbN> week 25 of 2017 is confirmed fine
[21:15:38 CEST] <BtbN> I have no idea what week mine is, as I'd have to disassemble the PC to check
[21:15:40 CEST] <ubitux> any news on mainline for the odroid?
[21:15:58 CEST] <atomnuker> ubitux: yeah, armbian works
[21:16:10 CEST] <ubitux> patched kernel?
[21:16:17 CEST] <atomnuker> nope, though its ubuntu based junk and not debian
[21:16:25 CEST] <ubitux> 4.12?
[21:16:27 CEST] <J_Darnley> Even better.  I'm still delaying because I am cheap
[21:16:28 CEST] <atomnuker> (why did these idiots call it armbian then)
[21:16:30 CEST] <atomnuker> yes
[21:16:30 CEST] <BtbN> The problem is, to RMA it, I'd have to send it back to AMD
[21:16:42 CEST] <BtbN> And they don't give me an intermediate replacement
[21:16:44 CEST] <ubitux> 4.12 doesn't have mmc support iirc
[21:16:46 CEST] <BtbN> and it takes 4-6 weeks
[21:16:52 CEST] <ubitux> sdcard* support
[21:17:17 CEST] <atomnuker> ubitux: I guess, I only ran it from the 1 emmc I had
[21:17:40 CEST] <ubitux> how are you booting the first time?
[21:17:46 CEST] <rcombs> is there any particular advantage of the NanoPi over the Odroid
[21:17:50 CEST] <rcombs> other than it being cheap and tiny
[21:18:23 CEST] <ubitux> i'd say the nanopi is faster, but you need to check
[21:18:31 CEST] <ubitux> again, haven't bought it yet
[21:18:41 CEST] <atomnuker> ubitux: normally? I tried that 2 months ago and it worked fine until the polyfuse blew, I thought it broke and ordered another c2
[21:18:49 CEST] <ubitux> :D
[21:20:16 CEST] <rcombs> they're both A53s
[21:20:30 CEST] <BtbN> I might just buy a 100¬ R3 quad core for the mean time and try to sell it off later :(
[21:21:14 CEST] <ubitux> rcombs: ah, yeah well, go for odroid
[21:21:19 CEST] <rcombs> Odroid at 2GHz, NanoPi at& apparently 1.2GHz?
[21:21:47 CEST] <rcombs> presumably for thermal reasons
[21:21:58 CEST] <rcombs> I had trouble finding a clock figure for the NanoPi
[21:22:31 CEST] <ubitux> nanopi is recent
[21:22:43 CEST] <rcombs> well Odroid had it in their product description
[21:22:45 CEST] <ubitux> you'll have to dig your way to get it work
[21:23:09 CEST] <rcombs> alright, going with the Odroid; wish me luck
[21:23:19 CEST] <jamrial> BtbN: that crash can't be fixed with microcode update?
[21:45:49 CEST] <iive> BtbN: are you in europe?
[21:46:02 CEST] <BtbN> yes
[21:46:32 CEST] <iive> i think that the the one you bought the part takes all the troubles
[21:46:41 CEST] <iive> i mean, the shop
[21:47:19 CEST] <BtbN> I already asked the shop. They hadn't heard from the issue at all so far. And most news articles about it tell you to contact AMD directly
[21:47:38 CEST] <iive> by law. they MUST do one of the following: 1. repair in 1 month; 2. replace 3. return your money.
[21:48:01 CEST] <BtbN> Yeah, but even then, I'd be one month without CPU :D
[21:48:26 CEST] <BtbN> I'm gonna call them tomorrow
[21:48:29 CEST] <BtbN> and ask
[21:48:36 CEST] <iive> ask them fore replacement.
[21:48:39 CEST] <iive> for
[21:48:54 CEST] <BtbN> I want a replacement that is known good though. And AMD can provide that. the shop can't
[21:49:03 CEST] <BtbN> Even though pretty much all their R7 stock they have now should be good
[21:49:31 CEST] <iive> BtbN: they should be OK with replacement, because the part you return would be replaced by AMD
[21:50:06 CEST] <BtbN> Yeah, but it'd still take a while
[21:51:30 CEST] <iive> BtbN: it might be good idea to read the law of your country. a lot of shops like to bulshit their customers ;)
[21:51:43 CEST] <BtbN> I can return it with them just fine
[21:51:53 CEST] <BtbN> it's just that I don't want to. Because I have only that one CPU
[21:52:21 CEST] <iive> just ask for replacement. The shop is not taking a financial hit
[21:52:37 CEST] <iive> they will sell the replacement they get from AMD as a new CPU to somebody else.
[21:52:47 CEST] <BtbN> Yeah, but the way it works is I send them the old one, they check it, maybe send it to AMD for a check, and when it's confirmed, I get the replacement
[21:53:13 CEST] <iive> no, you ask the shop for replacement.
[21:53:17 CEST] <iive> you don't care about AMD
[21:53:28 CEST] <iive> that's problem of the shop, not yours
[21:55:38 CEST] <BtbN> I also can't find the small plastic holder thing the CPU belong into anymore
[21:55:50 CEST] <BtbN> so without a replacement, I absolutely can't safely package it
[21:56:18 CEST] <iive> you'll find it. when you don't need it anymore ;)
[21:56:35 CEST] <BtbN> I might have actually thrown it away
[21:57:06 CEST] <iive> that's bad
[21:57:09 CEST] <wm4> <BtbN> It's affected by the "crash while compiling gcc or mesa" <- what's this about anyway?
[21:57:35 CEST] <iive> yeh, i was about to ask if the problem has been ... explained
[21:57:36 CEST] <BtbN> compiling gcc and mesa randomly crashes gcc on early Ryzen CPUs
[21:57:47 CEST] <iive> it should have been diagnosed and fixed.
[21:58:05 CEST] <BtbN> They only said they could reproduce it and are investigating it
[21:58:14 CEST] <BtbN> and they said it only affects the very first few batches of ryzen CPUs
[21:58:20 CEST] <iive> so, no microcode update that fixes it?
[21:58:27 CEST] <BtbN> not yet at least
[21:58:32 CEST] <J_Darnley> I haven't seen talk about a fix yet (but I haven't been looking)
[21:58:44 CEST] <BtbN> and if it's actually bad silicon, I don't want a CPU that has that
[21:59:22 CEST] <iive> can you reproduce it yourself?
[21:59:26 CEST] <BtbN> yes, easily
[21:59:34 CEST] <BtbN> just building gcc crashes after a few minutes
[21:59:48 CEST] <BtbN> gcc just randomly segfaults
[22:00:54 CEST] <BtbN> to make things more weird, it's only when compiling specific things
[22:01:00 CEST] <BtbN> like, I can build webkit or libreoffice just fine.
[22:01:07 CEST] <BtbN> It's specifically gcc that always crashes
[22:01:09 CEST] <BtbN> and sometimes mesa
[22:01:24 CEST] <BtbN> The system is also not unstable otherwise
[22:01:29 CEST] <BtbN> I can run Prime95 for hours on end
[22:13:40 CEST] <iive> it's probably something wierd, like the i7 mov ah/al collision
[22:14:12 CEST] <BtbN> On Windows, the DX12 CPU Benchmark of Ashes of Singularity also crashes every time
[22:14:18 CEST] <BtbN> So it's not something linux exclusive
[22:14:29 CEST] <BtbN> and building stuff in bash-for-windows also shows the same crashes
[22:15:27 CEST] <iive> it might be cache related, e.g. if there is some access pattern that loads and replaces cache entries.
[22:16:42 CEST] <BtbN> Disabling OpCache does mostly mitigate it
[22:16:45 CEST] <BtbN> as does disabling SMT
[22:16:49 CEST] <BtbN> As does not using Core 0
[22:17:00 CEST] <BtbN> But all just "almost mitigate" it
[22:17:07 CEST] <BtbN> it still happens, just not as frequently
[22:17:10 CEST] <iive> opcache, is that instruction cache?
[22:17:13 CEST] <J_Darnley> :)
[22:17:25 CEST] <BtbN> No idea, the bios calls the option just "OpCache Enable/Disable"
[22:17:29 CEST] <BtbN> with no further explanation
[22:18:14 CEST] <iive> micro-op cache.
[22:19:20 CEST] <BtbN> Disabling all but one core makes it happen even faster
[22:19:32 CEST] <BtbN> Read some people speculating about interrupt handlers being involved
[22:20:27 CEST] <JEEB> at least it seems like the ryzen segfaults do not happen with threadripper/epyc
[22:20:45 CEST] <JEEB> so while it sucks, it seems to have been taken care of
[22:21:27 CEST] <iive> BtbN: does it happen if you never use core0 ?
[22:21:57 CEST] <BtbN> yes
[22:22:06 CEST] <BtbN> but less frequently
[22:22:28 CEST] <BtbN> JEEB, they supposedly also don't happen with later production batches
[22:22:37 CEST] <BtbN> basically only the people who got it on day 1 are affected
[22:22:53 CEST] <BtbN> So just getting any replacement will most likely be good
[22:23:01 CEST] <JEEB> ouch
[22:23:32 CEST] <BtbN> It's most likely just a bad batch
[22:25:21 CEST] <cone-618> ffmpeg 03Marton Balint 07master:493f637d1e93: ffplay: add support for rendering yuv images with negative line size
[22:25:22 CEST] <cone-618> ffmpeg 03Marton Balint 07master:7004ac5eeb8e: ffplay: add support for displaying rgb images with alpha
[22:25:23 CEST] <cone-618> ffmpeg 03Marton Balint 07master:3bd2228d05a0: ffplay: add support for more SDL pixel formats when rendering video
[22:30:45 CEST] <rcombs> atomnuker: btw, which x86_64 conveniences are you referring to?
[22:30:57 CEST] <rcombs> the nasm macro engine and x86inc?
[22:32:01 CEST] <rcombs> or other features of the nasm assembly syntax over GNU (labels, etc)?
[22:37:28 CEST] <atomnuker> rcombs: being able to add a multiple of a register plus a constant as an offset to memory for free
[22:37:42 CEST] <rcombs> 0.o ARM doesn't have that?
[22:37:53 CEST] <rcombs> I guess it'd take up too much space in the instruction encoding
[22:38:25 CEST] <rcombs> as much as people hate x86's variable-length encoding& I suppose it's there for a reason
[22:39:57 CEST] <iive> yeh
[22:40:01 CEST] <JEEB> ugh, https://github.com/mozilla/rr/issues/2034#issuecomment-304445368
[22:40:16 CEST] <JEEB> seems like Ryzen has some other issues?`unless these are also limited to first gen
[22:43:40 CEST] <cone-618> ffmpeg 03Marton Balint 07master:498c90c70844: avfilter/vf_overlay: fix alpha blending for planar formats with a transparent background
[22:45:13 CEST] <BtbN> I don't even understand what that stuff is about
[22:46:56 CEST] <atomnuker> hard to replicate, one in a thousand runs bugs
[22:47:24 CEST] <JEEB> I think they did deduce the bug to an easily replicate'able case
[22:47:38 CEST] <BtbN> Wonder if it's related
[22:47:46 CEST] <BtbN> should try on a known-good CPU
[23:55:38 CEST] Action: kepstin has one of the affected ryzen chips, and something in the code generation from gcc 6 makes the segfaults happen a lot less often than with older gcc versions, it seems
[23:55:52 CEST] <kepstin> kinda weird, really.
[23:56:46 CEST] <Compn> or someone fixed gcc6...
[23:56:49 CEST] <Compn> more likely
[23:57:02 CEST] <Compn> a workaround for a buggy proc
[00:00:00 CEST] --- Fri Aug 11 2017