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

[burek]

[00:23:39 CEST] <BBB> atomnuker: not that Im against removing libschroedinger, I think libxyz madness is insane (these libs should have their own patches to itnegrate into ffmpeg, not the other way around), but isnt vc-2 intra-only and thus not the same functionality as libschroedinger encoder?
[00:36:04 CEST] <atomnuker> yes, but 1.) no one uses dirac, 2.) the vc-2 encoder should still generate decodable files by old dirac decoders
[01:32:27 CEST] <cone-470> ffmpeg 03Michael Niedermayer 07master:4c472c52525f: avcodec/ra144: Fix runtime error: signed integer overflow: 11184810 * 404 cannot be represented in type 'int'
[01:32:27 CEST] <cone-470> ffmpeg 03Michael Niedermayer 07master:7c845450d2da: avcodec/ra144: Fix runtime error: signed integer overflow: -2449 * 1398101 cannot be represented in type 'int'
[01:32:27 CEST] <cone-470> ffmpeg 03Michael Niedermayer 07master:c9e884f3d98d: avcodec/truemotion2: Fix runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
[01:32:27 CEST] <cone-470> ffmpeg 03Michael Niedermayer 07master:c901627918ff: avcodec/truemotion2: Fix passing null pointer to memset()
[02:46:02 CEST] <cone-470> ffmpeg 03Micah Galizia 07master:c4c73020f4bb: libavformat/hls: Observe Set-Cookie headers
[02:46:03 CEST] <cone-470> ffmpeg 03Michael Niedermayer 07master:f6ba58d193d9: avcodec/aacsbr: Fix libavcodec/aacsbr.c:257:59: runtime error: division by zero
[04:42:55 CEST] <cone-470> ffmpeg 03Michael Niedermayer 07master:718f8a01dfa3: tools/target_dec_fuzzer: Move the hwaccel check outside the initialization if
[10:29:20 CEST] <wm4> jkqxz: is there anything we can do against the gross incompetence intel driver devs have shown again with this buffer destruction API fiasco?
[10:29:42 CEST] <wm4> this is seriously shit-for-brains retarded
[10:31:15 CEST] <JEEB> wm4: is that on -devel or otherwise?
[10:37:27 CEST] <wm4> http://ffmpeg.org/pipermail/ffmpeg-user/2017-May/036232.html
[10:37:53 CEST] <wm4> "Unfortunately, Intel got tired of people complaining that their driver was broken.  Rather than fixing it, they decided to change the specification"
[10:38:12 CEST] <JEEB> trololol
[10:40:31 CEST] <wm4> incompetent shitheads
[10:40:54 CEST] <ubitux> looks like the same design as android/mediacodec
[10:41:00 CEST] <ubitux> render = destroy
[10:41:18 CEST] <JEEB> yup
[10:41:21 CEST] <ubitux> and yeah, it's complete garbage
[10:41:35 CEST] <mateo`> tell me more about it :D
[10:41:39 CEST] <wm4> that's not really the same
[10:41:53 CEST] <wm4> this here is just something where you get the choice between memory leak and crash
[11:16:04 CEST] <rcombs> heh
[11:16:11 CEST] <rcombs> so, the new behavior actually makes more sense
[11:16:20 CEST] <rcombs> but they didn't go about fixing it the right way
[11:23:19 CEST] <ubitux> wbs: oh, we can use optional args in gas macro? :o
[11:23:53 CEST] <wbs> ubitux: yes, that's been supported forever, and works in the clang built-in assembler as well
[11:24:03 CEST] <ubitux> nice, TIL
[11:24:19 CEST] <wbs> and in gas-preprocessor etc. widely used in libavutil/{arm,aarch64}/asm.S
[11:24:34 CEST] <ubitux> didn't ever realized..
[11:25:07 CEST] <ubitux> oh.. with export=1, yeah i guess i used already :')
[11:40:08 CEST] <wm4> mateo`: btw. any results in investigating better ways to use mediacodec without copying memory back to CPU?
[11:40:20 CEST] <wm4> wasn't there an idea to render to a GL texture?
[11:40:54 CEST] <rcombs> my current route is "yell at the vendor until they give me access at the OMX level"
[11:41:17 CEST] <rcombs> because OMX seems less painful than that shit (this is something that has never been said of anything else)
[11:42:12 CEST] <mateo`> wm4: the surface output is already implemented through the hwaccel
[11:42:59 CEST] <wm4> yeah, but as we know it's pretty inconvenient, due to the underlying mediacodec API
[11:43:21 CEST] <wm4> also looking forward to the horror google will come up to "solve" this (it will be a horror, I have no doubt)
[11:43:29 CEST] <BtbN> I'd kind of like to add a CUDA to GL frame converter. So for example kodi could use the cuvid decoders without having to use CUDA themselves.
[11:43:33 CEST] <mateo`> because you want to render the same frame multiple time ?
[11:43:49 CEST] <rcombs> apparently there's some amount of movement towards v4l2
[11:43:54 CEST] <nevcairiel> GL is tricky because its so stateful
[11:43:59 CEST] <nevcairiel> why dont you let kodi figure that out
[11:44:15 CEST] <BtbN> because they won't touch CUDA
[11:44:43 CEST] <wm4> BtbN: why not? how is GL better than CUDA?
[11:44:45 CEST] <nevcairiel> and we probably shouldnt try to offer a GL interface, because its going to end in a nightmare with context sharing and shit
[11:44:53 CEST] <BtbN> wm4, it's not nonfree
[11:45:07 CEST] <wm4> double negation?
[11:45:59 CEST] <mateo`> wm4: once you have a jni wrapper around the surfacetexture api, it's okay-ish (at least it works)
[11:47:01 CEST] <wm4> personally I'd love if cuda could just replace vdpau
[11:47:11 CEST] <wm4> well, anything to get rid of vdpau
[11:47:25 CEST] <mateo`> i use the following workflow in the app i work for, mediacodec -> surfacetexture -> GL_TEXTURE_EXTERNAL_OES (-> GL_TEXTURE_2D if need mipmapping)
[11:47:42 CEST] <mateo`> if I need to render the same frame twice, i just re-render the GL texture without updating it
[11:47:44 CEST] <nevcairiel> i've been very reluctant adding hw decoding for linux for $work because all the s olutions are apparently crappy
[11:48:07 CEST] <BtbN> The idea would be to have no context code in ffmpeg. Just a filter that copies from CUDA to a GL texture within a user provided context
[11:49:23 CEST] <rcombs> BtbN: bad news, ffmpeg.c
[11:49:37 CEST] <BtbN> ffmpeg.c has no need for that
[11:49:39 CEST] <wm4> you could do something with shared contexts lol
[11:50:29 CEST] <wm4> I'm also working on libplacebo (mpv's GL renderer as a library), which could probably take in GL or CUDA surfaces, and has to solve a similar "problem"
[11:51:45 CEST] <rcombs> BtbN: I have a use-case for mediacodec -> filters -> mediacodec
[11:51:57 CEST] <wm4> I'll probably end up sanity-checking GL context use by forcing the user to provide appropriate callbacks for getting the current host context
[11:51:58 CEST] <rcombs> optimally without a copy to CPU
[11:52:13 CEST] <BtbN> But how is mediacodec involved with CUDA?
[11:52:34 CEST] <rcombs> oh I missed that disconnect
[11:52:53 CEST] <rcombs> well I generally have a use case for [hardware decoder] -> [GPU filters] -> [hardware encoder], though
[11:52:53 CEST] <wm4> BtbN: well, opaque GPU surfaces in general
[11:52:56 CEST] <wm4> plus GL
[11:53:11 CEST] <BtbN> rcombs, CUDA can do that now
[11:53:20 CEST] <BtbN> someone just has to write the filters as CUDA kernels
[11:53:28 CEST] <BtbN> one scale filter already exists
[11:54:03 CEST] <wm4> isn't there a generic cuda program filter in libav
[11:54:05 CEST] <wm4> or queued
[11:55:52 CEST] <atomnuker> I'd prefer to scrap that and instead use vulkan compute shaders
[11:57:48 CEST] <wm4> hwdec/Vulkan interop is going to be another nightmare
[11:58:28 CEST] <atomnuker> would it be? I imagine it would work like swapchin images where the images are owned by the driver
[11:59:11 CEST] <atomnuker> *swapchain
[12:05:20 CEST] <mateo`> rcombs: so you need GL filters that would take GL textures (2D or OES) as input, for the mediacodec case ?
[12:05:58 CEST] <rcombs> I dunno how any of that works with mediacodec
[12:06:08 CEST] <rcombs> my experience with that surface API has been traumatic
[12:07:51 CEST] <mateo`> that would work, (this is what I do outside of avfilter), the tricky part IMHO, is managing the GL context that your filters will use
[13:34:49 CEST] <BtbN> wow, x264 master now needs a nasm version that not even Gentoo has
[13:35:14 CEST] <JEEB> well gentoo "stable" versions are what they are
[13:35:22 CEST] <BtbN> they is not in portage at all
[13:35:25 CEST] <BtbN> *it
[13:35:38 CEST] <BtbN> Debian also does not have it, not even in sid
[13:35:57 CEST] <JEEB> well yeah, gentoo st least has 9999
[13:36:07 CEST] <BtbN> there is no 9999 nasm
[13:36:17 CEST] <JEEB> :D
[13:40:50 CEST] <Gramner> debian sid doesn't really update anything until stretch is released. after that there will be a billion or so new packages withing a day or two
[13:42:44 CEST] <Gramner> the stable revision of x264 doesn't require nasm though, only git master
[13:43:08 CEST] <BtbN> pinned it to the last commit before the nasm thing was introduced
[13:47:43 CEST] <atomnuker> Gramner: it does
[13:48:13 CEST] <atomnuker> unstable and experimental still gets stuff vert quickly
[13:48:20 CEST] <atomnuker> *very
[13:49:22 CEST] <JEEB> one of those is atm frozen
[13:49:32 CEST] <JEEB> for 9
[13:51:18 CEST] <atomnuker> nope, neither is
[13:51:20 CEST] <atomnuker> that's testing
[13:51:33 CEST] <JEEB> ok
[13:56:08 CEST] <Gramner> isn't unstable sort-of-frozen while tsting is frozen?
[13:58:27 CEST] <Gramner> i searched for a few random packages and the versions of those are identical in testing and unstable
[14:00:59 CEST] <atomnuker> things slow down but nothing gets frozen above testing
[14:02:23 CEST] <iive> Gramner: do you mean that newst x264 needs newest nasm and not yasm?
[14:03:56 CEST] <BtbN> iive, https://github.com/mirror/x264/commit/d2b5f4873e2147452a723b61b14f030b2ee760a5
[14:33:55 CEST] <DHE> yeah x264 added avx512 support in their commit master, which is likely why that happened.
[14:34:28 CEST] <DHE> even though the only existing chips with avx512 today are Xeon Phi. gotta wait for the next generation from intel
[14:41:55 CEST] <cone-025> ffmpeg 03Michael Niedermayer 07master:f3da6fbff864: avcodec/jpeg2000dec: Use ff_set_dimensions()
[14:41:56 CEST] <cone-025> ffmpeg 03Michael Niedermayer 07master:c49fa2a51452: avcodec/dds: Fix runtime error: left shift of 145 by 24 places cannot be represented in type 'int'
[14:41:57 CEST] <cone-025> ffmpeg 03Michael Niedermayer 07master:e091b9b3c785: avcodec/ansi: Fix frame memleak
[14:44:10 CEST] <Gramner> DHE: the xeon phi subset of avx-512 isn't supported in x264. SKL-X is required
[14:46:44 CEST] <Gramner> not that I see why anyone would want to use a xeon phi for video encoding in the first place really. seems like a bad choice from a price/performance viewpoint compared to regular xeons for that use case
[14:49:12 CEST] <kierank> Gramner: because marketing
[14:52:17 CEST] <DHE> i never understood what the phi was trying to target. a 60-core xeon in a PCI slot is interesting until you learn all its limitations...
[14:52:28 CEST] <DHE> but that's a story for another channel
[14:54:49 CEST] <Gramner> it's fine if your workload is trivially SIMD:able and able to fully use 512- bit vectors for everything. essentially the same kind of computations that's suitable for GPGPU but easier to develop for
[14:55:14 CEST] <BtbN> how do you even access it? Does it act like a normal CPU?
[14:55:40 CEST] <Gramner> there are available as both normal CPU:s and as add-in cards
[14:55:44 CEST] <DHE> as I understand it, it behaves like a normal system you communicate with over some virtual networking.
[14:58:12 CEST] <BtbN> so it's an entire PC on that card, and you send it jobs? oO
[15:04:52 CEST] <DHE> sort of? like I said this is all just based on googling. it's got a CPU (obviously), some RAM, and a communication channel with the host over PCI
[15:05:06 CEST] <DHE> or it's also available as the CPU of an otherwise ordinary server...
[15:14:07 CEST] <wm4> what's the standard that specifies h264 mp4 muxing? (actually I'd prefer one for mkv, but surely that does not exist)
[15:15:04 CEST] <nevcairiel> ISO IEC 14496-15
[15:15:13 CEST] <nevcairiel> Carriage of NAL unit structured video in
[15:15:13 CEST] <nevcairiel> the ISO Base Media File Format
[15:18:20 CEST] <wm4> thanks
[15:34:43 CEST] <BBB> atomnuker: Im not arguing against it being dead, I just think the commit should mention that this removes dirac inter coding since it effectively does that. its fine to do that. but we need to mention that thats what were doing
[15:34:58 CEST] <BBB> (coding=encoding)
[15:52:54 CEST] <Gramner> atomnuker: apparently they improved gather operations a lot in skylake, I only tested it on haswell previously so maybe it's useful now as long as you only target skylake or newer
[15:56:45 CEST] <iive> what are the gather operations? 
[15:57:10 CEST] <Gramner> https://en.wikipedia.org/wiki/Gather-scatter_(vector_addressing)
[15:57:28 CEST] <Gramner> basically loading multiple values into a vector register
[15:59:28 CEST] <iive> how is that different than basic mov? e.g. movaps ?
[15:59:51 CEST] <iive> or do you mean, stuff like shufps, broadcast etc..
[16:00:25 CEST] <Gramner> movaps is one load of n bytes contiguous memory. gather loads x elements of 4 or 8 bytes each that may be located anywhere in addressable memory
[16:00:53 CEST] <iive> and what instruction does this?
[16:01:33 CEST] <atomnuker> Gramner: I heard someone say that vgather can help speed up cabac decoding
[16:01:33 CEST] <Gramner> v(p)gather*
[16:03:48 CEST] <iive> looks like it have higher latency and lower throughput on skylake
[16:04:34 CEST] <iive> 20;4 vs 14;7
[16:07:17 CEST] <Gramner> vpgatherdd ymm 34 µops with an inverse throughput of 12 on haswell lol. compared to 4 µops and an inverse throughput of 4 on skylake
[16:07:28 CEST] <Gramner> yeah. it's improved a little bit
[16:08:48 CEST] <BBB> atomnuker: when do we start on ffav1?
[16:10:06 CEST] <Gramner> BBB: didn't you get the memo? video encoders must start with the letter x
[16:10:16 CEST] <Gramner> it automatically makes them faster
[16:10:29 CEST] <BBB> ffav1=decoder
[16:10:32 CEST] <Gramner> ah
[16:10:34 CEST] <BBB> I know x-encoders are better
[16:10:38 CEST] <BBB> but ff-decoders are also better
[16:10:39 CEST] <Gramner> did they finalize the spec?
[16:10:43 CEST] <Gramner> indeed
[16:11:11 CEST] <BBB> I considered renaming by encoder to xeve, but figured that would put it too far ahead of the competition so it would be unfair
[16:11:18 CEST] <BBB> removing the x made it more of a challenge
[16:11:28 CEST] <atomnuker> BBB: not yet, DCTs haven't been decided yet (I hope all the daala ones make it in)
[16:14:13 CEST] <iive> i really do wonder, why are intel creating ops that are working slower than a series of instructions.
[16:14:30 CEST] <iive> of existing instructions.
[16:19:25 CEST] <Gramner> gathers are mainly designed around SIMD address calculations. for example loading a[b[c]]
[16:20:20 CEST] <Gramner> quite useful in compiler auto-vectorization and things like that
[16:20:42 CEST] <Gramner> avx-512 also adds corresponding scatter instructions
[16:20:48 CEST] <Gramner> for storing values
[16:20:53 CEST] <Compn> rcombs : 
[16:21:11 CEST] <Gramner> and conflict detection for detecting duplicate addresses
[16:21:20 CEST] <Compn> rcombs : https://trac.ffmpeg.org/ticket/4490     do you still need this done? do you have spec or something for it? theres a guy asking about doing this project...
[16:22:58 CEST] <iive> Gramner: my point is... they can add them and make them faster, or at least not-slower
[16:23:42 CEST] <Compn> rcombs : also can you upload some samples for that bug ?
[16:23:47 CEST] <Compn> or link to them...
[16:23:52 CEST] <Gramner> with an inverse throughput of 4 on skylake (if correct) it's the same speed as doing multiple ones. it's indeed a mystery why they added it to haswell with such poor performance though
[16:41:18 CEST] <jamrial> Compn: http://0x0.st/6zc.thd
[17:16:09 CEST] <BBB> J_Darnley: woohoo
[17:18:51 CEST] <BBB> J_Darnley: I think patches lgtm& did you confirm with e.g. dct-test that the performance did not change?
[17:19:17 CEST] <BBB> J_Darnley: maybe give michaelni a chance to confirm hes ok with it also, I dont think he minds but he wrote the original assembly so an explicit ok from him would probably be helpful
[17:19:35 CEST] <BBB> J_Darnley: and again, happy to help with the sse2 for the idct itself
[18:17:00 CEST] <philipl> BtbN: Tried out the 1030, and it works as advertised. Also got split decode/display on two devices working in mpv. That's cute.
[18:17:58 CEST] <BtbN> is it the second gen video chip?
[18:19:24 CEST] <philipl> Yeah. Same as the 1050
[18:20:06 CEST] <BtbN> phoronix benched the video engine to be slower... I'm pretty sure something went wrong there
[18:20:35 CEST] <philipl> I thought the video enginer performance was affected by the main GPU clock. So these low end parts do run slower.
[18:20:47 CEST] <BtbN> hm, yeah, possible
[18:45:03 CEST] <saste> hi guys
[18:45:30 CEST] <saste> I cannot push to the source ffmpeg git repository anymore, whom should I contact for assistance?
[18:48:06 CEST] <atomnuker> saste: what's the push url?
[18:48:14 CEST] <atomnuker> also the server got changed a few week ago
[18:49:18 CEST] <saste> atomnuker: that would explain, my url is "git at source.ffmpeg.org:ffmpeg"
[18:49:46 CEST] <BtbN> you're missing .git
[18:52:32 CEST] <saste> BtbN, he's still asking me for a password, after I changed it to "git at source.ffmpeg.org:ffmpeg.git"
[18:53:15 CEST] <BtbN> git at git.videolan.org:ffmpeg.git is what I use, but I think they are equivalent
[18:53:26 CEST] <atomnuker> huh, I use ssh://git@source.ffmpeg.org/ffmpeg
[18:53:38 CEST] <BtbN> that's the same
[19:12:33 CEST] <jamrial> saste: there was a server move not too long ago, maybe something happened with your ssh key
[19:13:21 CEST] <jamrial> poke michaelni, or thresh
[19:14:55 CEST] <saste> jamrial, allright, thank you
[21:08:17 CEST] <J_Darnley> I thought git gave me some error while checking out but no, it is just the lastest commit I have here with "runtime error: division by zero" in the message
[21:21:31 CEST] <nadermx> Hi all, I came across a functionality that I need patched in ffmpeg.  I asked in superuser https://superuser.com/q/1213776/535078 and also it was confirmed in the #ffmpeg chat that in order for this to work it has to be patched.   Where in the source would I find this to try and start to write a patch myself or is there some one I should contact or try and hire to patch this?
[21:27:45 CEST] <J_Darnley> What?  You want to change the entire OS just so you can seek in a pipe?
[21:31:51 CEST] <nadermx> didn't realize it would require that, thought it was maybe a quick patch
[21:32:31 CEST] <nadermx> thought it would be a patch ffmpeg to write the id3 headers before writing the mp3
[21:35:49 CEST] <wm4> at least that doesn't sound impossible
[21:36:02 CEST] <wm4> but it's probably a mess
[21:36:27 CEST] <wm4> you'll first have to figure out how picture attachment writing works, and then why it's delayed, or how it can be not delayed
[21:36:55 CEST] <nevcairiel> piped/non-seekable w riting has various limitations
[21:37:05 CEST] <nevcairiel> sometimes it just cant be fixed very easily
[21:37:43 CEST] <wm4> in this case there's no real fundamental reason though, or is there
[21:39:30 CEST] <nadermx> In order to avoid writing temporary files
[21:50:40 CEST] <BBB> J_Darnley: tnx for performance numbers
[22:05:37 CEST] <Compn> jamrial : can i put that thd  sample up on the samples repo ?
[22:06:13 CEST] <jamrial> it was posted on a trac ticket i think
[22:06:17 CEST] <jamrial> so, maybe?
[22:06:33 CEST] <Compn> if you dont have objection :)
[22:08:07 CEST] <jamrial> i don't
[22:08:25 CEST] <Compn> k
[22:22:32 CEST] <rcombs> Compn: it's not a high-priority thing for me (since it's not really breaking anything, just wasting bits in some cases), but still would be a "nice to have"
[22:24:12 CEST] <Compn> rcombs : np, got a spec ?
[22:24:25 CEST] <rcombs> not sure what you mean by that
[22:24:49 CEST] <Compn> like whats a regular packet supposed to look like vs encapsulated one
[22:27:21 CEST] <Compn> er
[22:27:22 CEST] <Compn> i mean
[22:27:28 CEST] <Compn> a substream
[22:28:59 CEST] <rcombs> oh, I'm pretty sure that's all private
[22:29:08 CEST] <Compn> anything to show what the substream looks like
[22:29:11 CEST] <Compn> headers, start codes
[22:29:16 CEST] <rcombs> but the truehd decoder has explicit code to ignore atmos substreams
[22:29:28 CEST] <rcombs> I think it's just "stream id is 4" or something
[22:29:31 CEST] <Compn> ok
[22:29:48 CEST] <Compn> so its just hooking up an option to discard it ?
[22:30:41 CEST] <rcombs> that issue is about remuxing
[22:30:44 CEST] <rcombs> so it'd be a bsf
[22:30:53 CEST] <Compn> right
[22:30:53 CEST] <Compn> ok
[22:30:58 CEST] <rcombs> the decoder already always discards; doesn't need an option
[22:31:52 CEST] <Compn> right
[22:44:14 CEST] <cone-025> ffmpeg 03Rostislav Pehlivanov 07master:a3deeaade32d: lavf: remove the libnut library wrapper
[22:44:15 CEST] <cone-025> ffmpeg 03Rostislav Pehlivanov 07master:220b24c7c97d: lavc: remove libschroedinger encoding and decoding wrappers
[22:44:19 CEST] <atomnuker> BBB: pushed with your suggestions
[22:47:31 CEST] <jamrial> atomnuker: i don't think the libschroedinger patch was fully accepted
[22:48:03 CEST] <jamrial> you didn't address Paul's comment
[22:49:32 CEST] <atomnuker> jamrial: I did, I tested extensively and everything still matched
[22:50:01 CEST] <jamrial> why didn't you reply to that email then?
[22:50:12 CEST] <atomnuker> I did, he even said okay
[22:51:15 CEST] <atomnuker> at 12:47 last night: "OK then."
[22:51:38 CEST] <atomnuker> the web archive is being slow so it only shows a few emails from the thread
[22:52:17 CEST] <jamrial> i didn't get that email at all...
[22:52:22 CEST] <durandal_1707> it is private
[22:52:45 CEST] <durandal_1707> its very confidential
[22:52:52 CEST] <jamrial> ah, that explains it
[22:56:26 CEST] <atomnuker> well, durandal_1707 mailed both me and the ml, it got into my main inbox and for some reason replying there didn't cc the ML
[22:59:16 CEST] <BBB> you reply-not-alled to me also
[22:59:23 CEST] <BBB> I think your mail client is stupid
[22:59:40 CEST] <nevcairiel> thats what happens on some clients when people CC the author instead of just mailing the ML
[23:00:03 CEST] <BBB> isnt that why we all use gmail?
[23:00:13 CEST] <nevcairiel> gmail also does that
[23:00:21 CEST] <BBB> not for me
[23:00:28 CEST] <nevcairiel> in short, dont CC individual people that are active on the ML anyway =p
[23:01:44 CEST] <iive> actually it is fine to cc individual people, as long as the to: field is the maillist
[23:02:04 CEST] <iive> however some email clients send with multiple to:'s and even worse, the first one is not maillist
[23:02:28 CEST] <iive> then a single reply (that is default in gmail too) would reply to the first sender only
[23:09:08 CEST] <atomnuker> replied back with the missing parts
[23:09:37 CEST] <atomnuker> I too use gmail but its hard work so I should switch back to evolution
[23:11:16 CEST] <RiCON> atomnuker: looks like you replaced "not" with "sadasd"? lol
[23:12:15 CEST] <RiCON> or at least durandal_1707's "not"s: "The lossless mode decoding is sadasd bitexact." "Nope, still sadasd lossless."
[23:12:49 CEST] <atomnuker> first time I used sed in a year and it didn't work
[23:12:53 CEST] <atomnuker> so I used printf
[23:13:05 CEST] <atomnuker> ...which didn't get into my clipboard
[23:15:34 CEST] <atomnuker> OH FUCK SED ACTUALLY SILENTLY CHANGED THE FILE
[23:15:49 CEST] <RiCON> sed -i?
[23:16:07 CEST] <atomnuker> and is so useless it can't replace newlines
[23:16:45 CEST] <atomnuker> the number one thing you ever need to replace and it can't do that
[23:18:09 CEST] <atomnuker> posted a corrected reply, fuck sed
[23:18:38 CEST] <atomnuker> there's a reason I haven't used it in a year
[23:26:08 CEST] <Gramner> sed is turing complete
[23:43:50 CEST] <wm4> atomnuker: but ffmpeg configure uses sed
[23:43:53 CEST] <wm4> so you have used it
[23:52:07 CEST] <thardin> um, you can replace netlines
[23:52:13 CEST] <thardin> you just need to use some special syntax
[23:54:36 CEST] <atomnuker> :a;N;$!ba;s/\n/replacement/g
[23:54:44 CEST] <atomnuker> how is this even remotely sane?
[00:00:00 CEST] --- Tue May 30 2017