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

[burek]

[00:00:43 CEST] <atomnuker> so lets have some random companies who did no work whatsoever "protect" them and collect their share
[01:08:23 CEST] <iive> actually, patents are a way worse. There have been awarder about million patents doing existing things but this time "on internet" or "on mobile"
[01:08:35 CEST] <iive> awarded
[03:20:39 CEST] <cone-184> ffmpeg 03Michael Niedermayer 07master:7592d97f1013: avcodec/h264_slice: Fix signed integer overflow
[03:20:39 CEST] <cone-184> ffmpeg 03Michael Niedermayer 07master:c07af720984a: avcodec/wavpack: Fix invalid shift
[04:03:52 CEST] <cone-184> ffmpeg 03James Almer 07master:440285474bb8: x86/utvideodsp: make restore_rgb_planes functions work on x86_32
[04:03:53 CEST] <cone-184> ffmpeg 03James Almer 07master:bcbe9e444790: x86/sbrdsp: zero extend m_max in apply_noise_main
[04:03:54 CEST] <cone-184> ffmpeg 03James Almer 07master:3d3243577cfd: checkasm: use declare_func_float() in sbrdsp sum_square test
[04:37:44 CEST] <cone-184> ffmpeg 03James Almer 07master:24bb7db40378: x86/sbrdsp: remove unnecessary sign extend instruction in apply_noise_main
[04:38:21 CEST] <cone-184> ffmpeg 03Michael Niedermayer 07master:c8cfbc6629c1: avcodec/hevcdec: do not let updated extradata corrupt state
[05:17:22 CEST] <cone-184> ffmpeg 03Steven Liu 07master:d01b8f8683df: avformat/hlsenc: optimize help message default value.
[05:21:15 CEST] <cone-184> ffmpeg 03Steven Liu 07master:1fe40e73a67c: avformat/hlsenc: copy codec_tag when stream copy
[11:51:11 CEST] <durandal_1707> atomnuker: see my aac branch on github, now i get segfaults
[12:33:48 CEST] <iive> durandal_1707: link?
[12:37:05 CEST] <durandal_1707> iive: https://github.com/richardpl/FFmpeg/tree/aac
[12:48:19 CEST] <funman> doing hbrmt2bmd + obe on same source
[12:48:33 CEST] <kierank> funman: wrong channel
[12:48:49 CEST] Action: funman blames his huge hands
[12:49:03 CEST] <iive> durandal_1707: does it segfault on 64 bit or 32?
[12:50:11 CEST] <durandal_1707> 64bit in sbrdsp asm
[12:53:09 CEST] <nevcairiel> i'm sure james will fix it when he wakes up
[13:03:13 CEST] <iive> durandal_1707:  well, there are 2-3 changes, one removes a sign extend, another uses declare float
[13:05:00 CEST] <iive> asm check specially feeds garbade, and the sign extend could be there to remove it.
[13:05:12 CEST] <iive> garbage
[13:13:30 CEST] <iive> durandal_1707: where and when does it segfault?
[14:22:57 CEST] <J_Darnley> dammit.  Why do I always pick the moments when BBB is offline to ask him a question?
[14:41:21 CEST] <wm4> well he goes offline all the time
[14:41:35 CEST] <kierank> J_Darnley: it is holidays in usa
[14:42:19 CEST] <J_Darnley> I guess they need another day to recover from their collective booze and fireworks hangovers
[14:45:01 CEST] <J_Darnley> heh.  speak of the devil
[14:45:59 CEST] <J_Darnley> BBB: Do you have a website that we should link to in another blog post?
[14:46:34 CEST] <BBB> did you know my nickname (BBB) was originally Beelzebubu, which is a wordplay on Beelzebub, the devil? :-p
[14:46:59 CEST] <BBB> (BeelzeBuBu -> BBB, because Im now old and boring)
[14:47:14 CEST] <BBB> as for website, Id link to this: https://blogs.gnome.org/rbultje/
[14:47:15 CEST] <J_Darnley> You mean you're not a fan of the Blender video project?  I am gutted(!)
[14:47:25 CEST] <BBB> sorry
[14:47:42 CEST] <BBB> its not a very good test video, CGI after all
[14:49:47 CEST] <kierank> J_Darnley: I already linked to that
[14:50:14 CEST] <J_Darnley> I missed that
[15:32:57 CEST] <kierank> wm4: wtf is up with that api patch
[15:33:16 CEST] <wm4> you mean the compat one?
[15:33:21 CEST] <kierank> yeah
[15:33:32 CEST] <kierank> zero byte packets
[15:33:48 CEST] <kierank> wtf
[15:33:48 CEST] <cone-820> ffmpeg 03James Almer 07master:9d5e81d3b160: Revert "x86/sbrdsp: remove unnecessary sign extend instruction in apply_noise_main"
[15:33:48 CEST] <wm4> basically the old API ate any shit you gave it
[15:33:51 CEST] <wm4> the new API is a bit stricter
[15:34:01 CEST] <JEEB> :D
[15:36:08 CEST] <wm4> that reminds me (unfortunately) that I volunteered to push libturing
[15:36:54 CEST] <TMM> is the actual implementation of libturing any good?
[15:37:21 CEST] <TMM> I read the patchset and the libturing website and I'm not entirely sure what it's FOR in the context of ffmpeg
[15:37:43 CEST] <BBB> its a hevc encoder, right?
[15:38:11 CEST] <wm4> + #if defined(_MSC_VER)
[15:38:11 CEST] <wm4> +#define TURING_API_IMPORTS 1
[15:38:11 CEST] <wm4> +#endif
[15:38:13 CEST] <wm4> ....wat
[15:38:27 CEST] <BBB> welcome to microsft symbol exports
[15:38:31 CEST] <BBB> I love that stuff
[15:38:55 CEST] <TMM> BBB, it is a hevc encoder indeed, but, wouldn't that be the 3rd one in ffmpeg?
[15:38:56 CEST] <JEEB> TMM: "we made a research encoder like kvazaar at the BBC"
[15:38:57 CEST] <jamrial> then why is its entry in allcodecs.c before x265?
[15:38:59 CEST] <wm4> every lib that actually uses that (you don't have to) has the decency to do it transparently/internally
[15:39:25 CEST] <jamrial> it should be below, in the "external libraries, that shouldn't be used by default" list
[15:39:28 CEST] <JEEB> libkvazaar is being developed by a Finnish university, while libturing is BBC R&D :D
[15:39:30 CEST] <BBB> jamrial: alphabetical?
[15:39:57 CEST] <jamrial> BBB: there's a section for libraries that should not be used if another better one is also available
[15:40:04 CEST] <TMM> I'm not trying to say it shouldn't be merged or anything
[15:40:05 CEST] <jamrial> that's where libopen264 is, for example
[15:40:15 CEST] <JEEB> what jamrial notes is valid tho
[15:40:17 CEST] <TMM> I really have no stake in this, I just wondered why it was there I suppose
[15:40:21 CEST] <BBB> jamrial: review ;)
[15:40:24 CEST] <BBB> I dont care about hevc :-p
[15:40:34 CEST] <JEEB> TMM: because people want their R&D stuff to be "It's usable from FFmpeg!"
[15:40:48 CEST] <jamrial> thign is, i think i did mention it long ago in one of the first iterations of this patch...
[15:40:51 CEST] <TMM> JEEB, I guess that does help with getting testers
[15:41:06 CEST] <wm4> turingcodec/boost/libs/program_options/src/../../../boost/function/function_base.hpp:308:13: warning: placement new constructing an object of type boost::detail::function::functor_manager_common<boost::_bi::bind_t<std::vector<boost::program_options::basic_option<char> >, boost::_mfi::mf1<std::vector<boost::program_options::basic_option<char> >, boost::program_options::detail::cmdline, std::vector<std::__cxx11::basic_string<char> >&>
[15:41:06 CEST] <wm4> , boost::_bi::list2<boost::_bi::value<boost::program_options::detail::cmdline*>, boost::arg<1> > > >::functor_type {aka boost::_bi::bind_t<std::vector<boost::program_options::basic_option<char> >, boost::_mfi::mf1<std::vector<boost::program_options::basic_option<char> >, boost::program_options::detail::cmdline, std::vector<std::__cxx11::basic_string<char> >&>, boost::_bi::list2<boost::_bi::value<boost::program_options::detail::cmdline*>, 
[15:41:07 CEST] <wm4> boost::arg<1> > >} and size 24 in a region of type char and size 1 [-Wplacement-new=]
[15:41:10 CEST] <wm4> nice start
[15:41:20 CEST] <jamrial> >boost
[15:41:23 CEST] <BBB> boost \o/
[15:41:27 CEST] <nevcairiel> its a warning, just ignore it =p
[15:41:46 CEST] <RiCON> they'd get the same amount of testers if they made a simple turingenc.exe that used lavf/lavc like x264
[15:41:48 CEST] <BBB> jamrial: ignoring reviews means unfortunately we have to re-review it
[15:41:50 CEST] <nevcairiel> template related warnings can look rather frightening
[15:41:50 CEST] <TMM> that's a pretty dire warning though
[15:42:30 CEST] <TMM> if you're trying to placement new into a region where it won't fit and you place another thing next to it you may end up with interesting results 
[15:42:42 CEST] <JEEB> TMM: it's for advertisement :P
[15:43:04 CEST] <JEEB> maybe extra testers but not many will build libturing to begin with
[15:43:13 CEST] <TMM> ah, this warning is actually a boost bug
[15:43:31 CEST] <TMM> and it's largely cosmetic, apparently the target for the placement is the middle of a char[] 
[15:44:06 CEST] <TMM> still... use the goddamn language so you can get the compiler to help you avoid bad fuckups
[15:44:34 CEST] <BBB> lol
[15:44:42 CEST] <iive> why boost?! WHY?!
[15:44:57 CEST] <nevcairiel> compilers arent actually as smart as you seem to give them credit for =p
[15:45:21 CEST] <TMM> nevcairiel, they *can* help in the c++ case if you provide correct typing infos etc
[15:45:36 CEST] <TMM> And rustc can really help you a lot if you give it correct metadata :)
[15:45:44 CEST] <TMM> otoh, rustc will tell you to go fuck yourself if you don't
[15:45:49 CEST] <TMM> which is nice
[15:45:59 CEST] <wm4> make install will install stuff like lib/boost/libboost_filesystem.a
[15:46:20 CEST] <TMM> wm4, can't libturing build against OS supplied boost? 
[15:46:22 CEST] <wm4> ubitux: ok to push that br tag patch?
[15:46:30 CEST] <wm4> TMM: who knows
[15:46:55 CEST] <TMM> I mean, shipping boost with your app is fine and all, but if you detect system headers you should really use them imho
[15:47:41 CEST] <BBB> imagine if diego got his hands on libturing
[15:47:57 CEST] <BBB> they should really have sent this patch to libav-devel also
[15:48:07 CEST] <nevcairiel> maybe he would die of disgust?
[15:48:08 CEST] <TMM> I thought libav was done now?
[15:48:14 CEST] <BBB> I think it wouldve significantly enhanced the code quality of turing
[15:48:20 CEST] <BBB> (by some metrics)
[15:48:33 CEST] <BBB> which is probably what they were hoping for by integrating in ffmpeg in the first place
[15:48:36 CEST] <TMM> oh, libav still lives? 
[15:48:48 CEST] <BBB> TMM: I believe it still exists, I dont know, some poeple here contribute to it I believe
[15:48:49 CEST] <nevcairiel> its not our job to judge the quality of the code of that library, or even include that in a decision if we want to support it or not, its not like we work on their code
[15:49:04 CEST] <BBB> nevcairiel: I agree, I think
[15:49:18 CEST] <wm4> BBB: almost all recent hw transcode stuff you see in ffmpeg was developed in Libav
[15:49:21 CEST] <TMM> BBB, urgh, does that mean I should send my patches to the libav devel list too?
[15:49:54 CEST] <BBB> TMM: & thats a politically loaded question that Im going to stay out of :-p
[15:49:56 CEST] <JEEB> depends on if you care about libav
[15:50:06 CEST] <TMM> BBB, sorry, I really didn't mean to
[15:50:07 CEST] <nevcairiel> wm4: thats all they do lately though, hw stuff and api stuff, everything else seems to basically not improve
[15:50:22 CEST] <BBB> TMM: dont worry, its fine, dont take it negatively, I didnt mean it that way
[15:50:24 CEST] <TMM> JEEB, I don't know if I should or not I suppose, is it actually used? I thought all the linux distros switched back to ffmpeg
[15:50:42 CEST] <TMM> Linux distros is all I care about :)
[15:50:44 CEST] <JEEB> I see a lot of people not caring about Libav, and then there's a few people who use Libav in $dayjob or so which is why they throw the patch to both sides, or just libav.
[15:50:51 CEST] <nevcairiel> its probably just handbrake that still uses libav for some reason, not sure anyone else does
[15:50:52 CEST] <jamrial> nevcairiel: the api that expects a command line as parameter deserves to be judged :p
[15:51:03 CEST] <BBB> TMM: its a personal decision and there are some valid reasons to do it, and some valid reasons not to do it. nobody tells you what to do, and both decisions would be fine
[15:51:13 CEST] <JEEB> BBB: yup
[15:51:24 CEST] <nevcairiel> jamrial: like i said on the ML, thats basically how x264 and x265 work as well for anything beyond the absolute most basic options =p
[15:51:44 CEST] <nevcairiel> we hand-off strings to their option parsing
[15:52:23 CEST] <jamrial> fair enough
[15:52:26 CEST] <JEEB> yup
[15:52:31 CEST] <wm4> ffmpeg libs also work this way
[15:52:33 CEST] <BBB> TMM: I believe most distros use ffmpeg nowadays, yes
[15:52:36 CEST] <wm4> which I dislike btw.
[15:52:56 CEST] <nevcairiel> lavfi graph building with the string thingys does feel awkward
[15:53:07 CEST] <TMM> ghe, libav has a cinepak *encoder*?
[15:53:08 CEST] <TMM> crazy
[15:53:14 CEST] <nevcairiel> someone made a CLI api and then forgot to actually make a C api
[15:53:29 CEST] <wm4> TMM: isn't it ported from ffmpeg's?
[15:53:32 CEST] <nevcairiel> it is
[15:54:02 CEST] <TMM> Ah, I didn't notice it before in ffmpeg I guess, I should check there first next time :)
[15:54:28 CEST] <nevcairiel> they rarely have original things these days, outside of api changes
[15:54:39 CEST] <jamrial> curious how they get rid of toy en/decoder snow then add toy encoder cinepak :p
[15:55:02 CEST] <nevcairiel> i didnt feel like starting a troll thread by asking whats the motivation of importing it
[15:55:07 CEST] <TMM> cinepak is super relevant! If you want to convert a DVD to watch on your 1992 mac it's ESSENTIAL
[15:57:10 CEST] <thardin> I'm surprised someone bothered to complete it
[15:57:32 CEST] <thardin> I wrote it as a bit of a joke, then someone took it seriously
[15:57:42 CEST] <TMM> I kind of want to write an MVE encoder .... :-)
[15:57:53 CEST] <thardin> I think there's one floating around already
[15:58:04 CEST] <thardin> for encoding videos for fallout, baldur's gate etc
[15:58:19 CEST] <TMM> probably not for the old-ass mve frame formats I reverse engineered 
[15:58:39 CEST] <TMM> since nobody knew how they worked :)
[15:58:50 CEST] <thardin> cinepak is useful for that early-90's  a e s t h e t i c
[15:59:19 CEST] <TMM> may be useful for people who do fan translations of old games for scummvm too
[15:59:24 CEST] <jamrial> glorious 15 fps 320x240 cutscenes?
[15:59:33 CEST] <atomnuker> BBB: nonsense, taking no sides and saying there are reasons for and agains is how you worsen the issue
[15:59:39 CEST] <wm4> Version: 72b085e
[15:59:40 CEST] <TMM> although, I suppose you may as well use a modern codec then
[15:59:50 CEST] <wm4> libturing's .pc version field contains garbage
[15:59:54 CEST] <wm4> a git hash is unusable
[16:00:26 CEST] <TMM> Why do people even think that's acceptable? People do it internally here all the time too it's maddening because figuring out what's actually the LATEST version is fucking impossible
[16:00:45 CEST] <BBB> atomnuker: I dont think the situation can be improved
[16:00:51 CEST] Action: TMM shares your frustration :)
[16:01:01 CEST] <BBB> its like most western countries political climate, its totally screwed up and I dont know how to fix it
[16:01:17 CEST] <BBB> so I ignore it and move on to actually doing other stuff, like coding
[16:05:01 CEST] <wm4> also why is the start of config.log full of configure boilerplate spam
[16:05:08 CEST] <atomnuker> BBB: it'll fix itself in due time, just don't make people doubt themselves
[16:05:11 CEST] <wm4> make sit so hard to figure out the simplest things
[16:08:07 CEST] <BBB> atomnuker: okiedokie
[16:08:15 CEST] <BBB> TMM: I personally dont contribute to libav, if that helps
[16:36:45 CEST] <iive> TMM: how essential is boost for libturing? how much effort would it be to remove that dependency?
[16:45:49 CEST] <iive> my distro does come with libboost, however every minor update breaks all programs that I've compiled and that depend on it.
[16:46:08 CEST] <iive> libstdc++ at least provides some backward compatibility.
[16:52:26 CEST] <Shiz> W
[16:57:57 CEST] <TMM> iive, I don't know I'm not a libturing developer. But in general a program that depends on boost:: will not be super easy to move off of it. If it was written in an ancient c++ it's usually a bit easier as a lot of boost features made it into newer c++ versions.
[16:59:53 CEST] <iive> oh, since you were talking about sending libturing integration patch to libav, i assumed you are one of the developers.
[17:00:07 CEST] <TMM> iive, I was just talking about the patch in general, sorry.
[17:11:10 CEST] <wm4> jkqxz: so, any idea how the DRM hwctx should be done? or is your latest patch still how you want to do it?
[17:21:23 CEST] <jkqxz> wm4:  What changes are you wanting?  I was assuming LongChair would finish the RockChip decoder using it (possibly with some minor fixups to the DRM bit), and then they would commit together.
[17:22:37 CEST] <wm4> well he made a suggestion
[17:22:54 CEST] <wm4> which looked ok to me
[17:22:59 CEST] <wm4> he claimed that it'd be simpler
[17:23:40 CEST] <jkqxz> Going back to the nested arrays?  I'm fine with that.
[17:24:37 CEST] <jkqxz> Do you want me to send a new version using that?
[17:27:08 CEST] <wm4> sure
[17:27:38 CEST] <wm4> well my complaint about the nested arrays is that they can bloat quickly, not because I dislike them
[17:27:57 CEST] <wm4> so if we hardcode them to size 4, I'm fine with it
[17:45:03 CEST] <ubitux> wm4: if it works with the trailing / form
[17:45:20 CEST] <ubitux> please.
[17:45:28 CEST] <ubitux> (re: br tag)
[17:47:44 CEST] <wm4> what does the trailing form do?
[17:48:11 CEST] <wm4> does it exist in your subtitle corpus?
[18:15:39 CEST] <ubitux> wm4: it will take a while to check but i will in a moment
[18:18:08 CEST] <ubitux> wm4: the trailing form is just the html standard for standalone tags btw
[18:19:02 CEST] <ubitux> or maybe that was the xhtml thing
[18:19:36 CEST] <ubitux> that has nothing to do with subtitles but i know that typically graphviz will error out if you use <br> instead of <br/> (they also use some kind of html markup system) 
[18:19:45 CEST] <kierank> is it intentional for multi field closed captions to be broken
[18:20:12 CEST] <ubitux> (https://stackoverflow.com/questions/1946426/html-5-is-it-br-br-or-br)
[18:22:22 CEST] <RiCON> <br/> and <br /> shouldn't show up in srt
[18:22:31 CEST] <RiCON> (neither should <br>, though)
[18:22:42 CEST] <wm4> and </br>?
[18:22:57 CEST] <RiCON> that never shows up
[18:23:00 CEST] <RiCON> it's like <img>
[18:23:12 CEST] <ubitux> yeah, br, hr, img, ...
[18:23:20 CEST] <ubitux> all standalone tags could have a trailing /
[18:23:59 CEST] <RiCON> <br/> isn't even valid xhtml or html, iirc
[18:24:08 CEST] <ubitux> you mean without space?
[18:24:11 CEST] <RiCON> yeah
[18:24:54 CEST] <RiCON> "Since some earlier browsers that would parse XHTML as earlier HTML would choke on <br/> but not on <br /> such extra whitespace is the norm, for backwards compatibility (more backwards kludging it, but still...)."
[18:25:00 CEST] <RiCON> "compatibility"
[18:25:57 CEST] <thardin> <br/> should be valid xhtml. it is how you do it in normal xml at least
[18:26:11 CEST] <RiCON> anyway, it could be parsed for compatibility-sake, unless it unnecessarily adds complexity
[18:26:17 CEST] <thardin> xmllint certainly thinks so at least
[19:05:26 CEST] <kierank> how do I return side data from a frame that isn't decoded
[19:05:29 CEST] <kierank> field 1?
[19:48:21 CEST] <durandal_1707> is alex converse on irc?
[19:49:03 CEST] <nevcairiel> durandal_1707: its peloverde
[19:50:44 CEST] <peloverde> durandal_1707: pong
[19:51:43 CEST] <durandal_1707> peloverde: how good do you know aac 960/120 mdct?
[19:52:14 CEST] <peloverde> pretty well
[19:59:33 CEST] <peloverde> if this is about the scale though, taking some educated guesses will be way faster than reasoning from proper principles
[20:01:44 CEST] <durandal_1707> peloverde: there are artifacts, even with 0 to 0 sequence
[20:02:46 CEST] <durandal_1707> see on: https://github.com/richardpl/FFmpeg/tree/aac
[20:05:40 CEST] <peloverde> what do you mean by 0 to 0?
[20:10:55 CEST] <durandal_1707> peloverde: long to long
[20:11:06 CEST] <durandal_1707> define is 0
[20:12:44 CEST] <peloverde> if you plug in the reference transfom does it work? I can take a better look when I'm back at my desk. 
[20:16:10 CEST] <durandal_1707> i tried one from faad2 and got gibberish,  completly white spectrum
[20:16:38 CEST] <durandal_1707> perhaps i did something wrong
[20:20:29 CEST] <peloverde> I think it's way more likely that something else is a little off than that the transform is busted. The transfom is one of the few things that we do test in isolation. 
[20:33:04 CEST] <ubitux> wm4: i'm uncompressing the data again, it takes some time, then i'll run the research
[21:45:13 CEST] <jpabq> Is there anything I need to be doing to get https://patchwork.ffmpeg.org/patch/3860/ committed?
[21:54:55 CEST] <cone-746> ffmpeg 03James Almer 07master:9878935927c5: fate: add fate-checkasm-sbrdsp target
[21:54:55 CEST] <cone-746> ffmpeg 03John Stebbins 07master:a188942efe7b: movenc: simplify codec_tag lookup
[21:54:55 CEST] <cone-746> ffmpeg 03John Stebbins 07master:f55c42c14655: movenc: move tags definitions to where they are used
[21:54:55 CEST] <cone-746> ffmpeg 03John Stebbins 07master:da002b99b335: movenc: write correct format hvcc when tag is hvc1
[21:54:55 CEST] <cone-746> ffmpeg 03John Stebbins 07master:62861660fa4a: movenc: allow alternative hvc1 h.265 codec tag
[21:56:11 CEST] <cone-746> ffmpeg 03John Stebbins 07master:e199d90da647: movenc: simplify codec_tag lookup
[21:56:12 CEST] <cone-746> ffmpeg 03John Stebbins 07master:38d808d72e39: movenc: move tags definitions to where they are used
[21:56:13 CEST] <cone-746> ffmpeg 03John Stebbins 07master:974d508e5710: movenc: write correct format hvcc when tag is hvc1
[21:56:14 CEST] <cone-746> ffmpeg 03John Stebbins 07master:369a3e111cb8: movenc: allow alternative hvc1 h.265 codec tag
[21:56:44 CEST] <jamrial> wonder if that's what happens when two people try to push at the exact same time...
[21:57:24 CEST] <BtbN> what?
[21:57:29 CEST] <nevcairiel> only one of those sets of changes arrived
[21:57:30 CEST] <nevcairiel> so weird
[21:57:54 CEST] <jamrial> yeah, i pushed my commit there, but cone reported the five from derek as well
[21:58:30 CEST] <BtbN> the push hook probably runs earlier than actually pushing the commits?
[21:58:31 CEST] <jamrial> i assume we pushed at the same time, and while only one succeded the other push somehow "got through" in some way
[21:58:44 CEST] <jamrial> derek then rebased and pushed again, and cone reported it as well
[22:00:08 CEST] <jamrial> i almost panicked thinking i somehow made a push with a dirty tree full of unrelated commits :p
[22:05:45 CEST] <durandal_1707> jpabq: ping it on ml
[22:06:00 CEST] <jpabq> durandal_1707: Okay, will do.
[22:24:57 CEST] <durandal_1707> atomnuker: have you installed new system?
[22:32:49 CEST] <iive> durandal_1707: i can recommend you `edb` if you need to debug asm code.
[22:33:26 CEST] <durandal_1707> what is tthat?
[23:01:45 CEST] <atomnuker> durandal_1707: no, also my router's messed up so internet is crappy, my thoat hurts, I can't hear well with my left ear which also hurts and I can't sleep well
[23:02:44 CEST] <atomnuker> I'm not a very happy person right now
[23:03:13 CEST] <durandal_1707> atomnuker: seriously? just take few blue pills
[23:05:11 CEST] <durandal_1707> sleep well and dontt code at home
[23:06:29 CEST] <atomnuker> oh yeah, and I really want to get off this rock and move to someplace in Europe
[23:09:58 CEST] <atomnuker> where ISPs give you either an ethernet cable or a fiber with a media converter rather than router tracking everything to room humidity
[23:10:42 CEST] <durandal_1707> where are you?
[23:11:08 CEST] <iive> sounds like usa
[23:11:08 CEST] <atomnuker> but can't blame them for giving people routers, because PHONE CABLES aren't really where packets are meant to go
[23:11:31 CEST] <atomnuker> iive: its not that bad thankfully, I'm in the UK
[23:12:09 CEST] <iive> :P
[23:15:22 CEST] <iive> british telecon was the big government monopoly, afair
[23:15:31 CEST] <iive> telecom...
[23:26:27 CEST] <cone-746> ffmpeg 03Azamat H. Hackimov 07master:121ab69c9d06: libavformat/gdv: Fix parsing for soundless video
[23:36:17 CEST] <kierank> atomnuker: no virgin media where you live?
[23:37:16 CEST] <atomnuker> bt was faster and cheaper
[23:37:53 CEST] <atomnuker> (seriously, a phone cable? and for TV they give you a box which requires an antenna)
[23:38:31 CEST] <atomnuker> and you also need an amplifier because the signal isn't good enough and even then its still not good enough
[23:39:08 CEST] <atomnuker> its like I've gone somewhere rural with phone cables and TV antenna amplifiers
[23:39:49 CEST] <BtbN> atomnuker, you wish. The standard in europe is to use ancient two-wire phone lines and squish as much bandwidth through them as possible, with crappy plaster-routers.
[23:40:03 CEST] <BtbN> Germany is especially bad
[23:40:15 CEST] <JEEB> le VDSL
[23:40:30 CEST] <kierank> atomnuker: virgin does 200mbps now
[23:40:51 CEST] <BtbN> Ethernet/Fiber is the absolute exception
[23:41:09 CEST] <atomnuker> oh yeah and bt by default disable using a non-dhcp given DNS
[23:41:26 CEST] <kierank> Huh, I don't use their crappy dns
[23:41:52 CEST] <atomnuker> I had to login to the account page on their website and wait a few hours until it was disabled
[23:45:19 CEST] <atomnuker> what has the world come down to, I remember getting 50mbps symmetric back in 2005 where the ISP would have an FTP server filled with movies and games and such
[23:45:51 CEST] <atomnuker> and ISPs would compete to see who can amass the largest collection and attract the most customers
[23:46:34 CEST] <BtbN> that sound mildly illegal
[23:47:10 CEST] <BtbN> Something amazing the German Telekom does: Block foreign SMTP servers.
[23:47:11 CEST] <atomnuker> (they usually hijacked chinese websites like gamez.com.tw or magnet.co.jp via their DNS to a look-alike page with listings and search of what they had)
[23:47:40 CEST] <BtbN> So if you want to use SMTP to something that's not their Mail-Server, you need to unlock the specific server first
[23:47:41 CEST] <JEEB> lol
[23:48:04 CEST] <BtbN> And it's a per-server unlock, not a general "Let me use SMTP"
[23:48:53 CEST] <atomnuker> sure its illegal, but back then there was no danger for ISPs which were never ever big enough to cover an entire city of 300 000 people
[23:49:35 CEST] <atomnuker> and who'd report them, everyone was happy to be getting all this stuff and took it for granted
[23:51:42 CEST] <atomnuker> oh and you could get even more stuff out of people because everyone was wired directly and could see each other and everyone was on the default windows WORKGROUP workgroup
[23:53:05 CEST] <atomnuker> windows didn't even have a firewall or malware detector or antivirus by default so sasser spread like wildfire
[00:00:00 CEST] --- Thu Jul  6 2017