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

[burek]

[00:00:02 CEST] Action: Compn considers reinstalling win2k
[00:00:15 CEST] <wm4> a liability for those companies
[00:00:16 CEST] <JEEBsv> ugh, that doesn't even have aligned malloc, IIRC
[00:00:29 CEST] <JEEBsv> I think the nice stuff in msvcrt came in... xp sp2?
[00:01:58 CEST] <kierank> not really
[00:02:11 CEST] <kierank> if they have programs that for whatever reason only run on xp
[00:02:19 CEST] Action: kierank sadly has customers with that
[00:02:27 CEST] <wm4> so what, many companies have that with DOS
[00:02:31 CEST] <wm4> (or worse)
[00:02:45 CEST] <kierank> yes but xp is much larger
[00:02:49 CEST] <kierank> orders of magnitude
[00:03:07 CEST] <wm4> so you have customers who need to run bleeding edge ffmpeg on XP machines, or something
[00:03:07 CEST] <Compn> millions of machines
[00:03:36 CEST] <nevcairiel> kierank: any corporate environment that still uses xp is dumb
[00:03:40 CEST] <nevcairiel> its a security nightmare now
[00:03:41 CEST] <Compn> your idea to drop xp also affects ffmpeg libs, which affects vlc and j-b and all other tools that use lavc
[00:03:46 CEST] <kierank> wm4: well it's more vlc
[00:03:48 CEST] <kierank> yes exactly
[00:04:13 CEST] <Compn> kierank : i dont think he cares, so why are we arguing with him ?
[00:04:13 CEST] <wm4> j-b: do you care about XP support?
[00:04:14 CEST] <Compn> heh
[00:04:23 CEST] <nevcairiel> I think many downstreams will be happy if we give them an excuse to drop xp support =p
[00:04:43 CEST] <wm4> Compn: I don'T care about you, but I care a lot about getting rid of XP
[00:05:57 CEST] <Compn> your precious w7 is obsolete as well. every time i point this out to w7 users they shrug it off 
[00:06:09 CEST] <wm4> does anything you say ever make sense
[00:06:11 CEST] <Compn> you are going to have to make  a choice about new windows, very soon...
[00:06:12 CEST] <Compn> bah
[00:09:57 CEST] <j-b> wm4: yes, I do.
[00:10:24 CEST] <kierank> BURN
[00:10:28 CEST] <j-b> wm4: but I wouldn't care if I had no hw threading on XP
[00:11:35 CEST] <wm4> whatever that means
[00:11:50 CEST] <wm4> compiling vlc against pth?
[00:12:00 CEST] <Compn> j-b : some devs dont care about vlc, but i care about vlc, i want a list of things vlc wants from us. like on a wiki. :)
[00:13:26 CEST] <j-b> wm4: all winpthread implems are shit, so far
[00:14:22 CEST] <nevcairiel> w32thread in ffmpeg/libav isnt too bad, if you discount the xp compat layer, but oif course its just minimal enough for the things ffmpeg needs
[00:14:53 CEST] <wm4> j-b: because of win xp
[00:14:58 CEST] <j-b> wm4: no
[00:15:06 CEST] <Compn> i thought there were native threads .... hmm
[00:15:10 CEST] <j-b> wm4: because most of them can't read the fucking documentation
[00:15:14 CEST] <j-b> because many require init
[00:15:20 CEST] <j-b> like ptheadGC2
[00:15:42 CEST] <j-b> because some expose other POSIX functions as __inline at the same time (see mingw64)
[00:15:49 CEST] <j-b> and fuck up the configures + builds
[00:16:28 CEST] <nevcairiel> pthread-w32 (ie. pthreadGC2) is one of the least terrible at least, imho, the one mingw-w64 build is worse
[00:17:42 CEST] <nevcairiel> but ffmpeg is the only pthread thing i frequently build/use, and it doesn't require either, which is better for me
[00:22:35 CEST] <jamrial> pthreads on win32 seems pointless to me when the native critical section stuff maps almost perfectly
[00:24:22 CEST] <nevcairiel> a small subset maps perfectly, but some of the more advanced pthreads stuff gets complicated, but luckily ffmpeg doesnt use that
[00:41:40 CEST] <cone-394> ffmpeg 03Janne Grunau 07master:a31c4b2cbef9: fate-g2m3: disable the audio stream
[00:41:40 CEST] <cone-394> ffmpeg 03Michael Niedermayer 07master:03b2b40fd7f0: Merge commit 'a31c4b2cbef9aee15910fc3df52519aef46760de'
[04:58:15 CEST] <cone-575> ffmpeg 03rogerdpack 07master:a1c03b9d5882: ffmpeg_filter: log more information on failure to init simple filter graph
[05:15:59 CEST] <cone-575> ffmpeg 03John Adlum 07master:c8eca438a953: avformat/asfdec_f: factor error checking out of main header parsing loop
[05:16:00 CEST] <cone-575> ffmpeg 03John Adlum 07master:59fffefdb4dd: avformat/asfdec_f: Use dynamic allocation in asf_read_metadata() instead of a fixed size buffer
[05:16:01 CEST] <cone-575> ffmpeg 03John Adlum 07master:72cad800164c: avformat/asfdec_f: Add ASFDataType, use named types for metadata
[05:18:47 CEST] <jamrial> where are these patches coming from, and why is the old asfdec suddenly getting a lot of development only after a replacent showed up?
[05:23:11 CEST] <jamrial> that last one especially. this all just reeks of NIH
[05:31:02 CEST] <philipl> BtbN: The 'docs' imply that only lossless 444p works.
[05:31:04 CEST] <philipl> That's what I tested.
[05:34:08 CEST] <philipl> BtbN: No luck on identical frames though. Looks like some colourspace difference. odd.
[05:55:11 CEST] <philipl> ah, got it. Needed to make sure my source was really yuv444p
[05:55:26 CEST] <philipl> So yeah, it works.
[06:04:55 CEST] <philipl> Hmm, and while the nvenc packed 444 was a false alarm, in vdpau, the 444 output mode is definitely packed yuva. Fun times.
[08:24:41 CEST] <durandal_170> michaelni: from where those asf_f patches are coming?
[08:46:58 CEST] <jamrial> michaelni: for that matter, 59fffefd added an av_malloc inside a loop without an av_free
[08:47:04 CEST] <jamrial> asan and valgrind are of course complaining
[09:50:42 CEST] <cone-448> ffmpeg 03Michael Niedermayer 07master:1f69b7baa10c: avformat/asfdec_f: Fix memleak
[10:18:59 CEST] <durandal_170> are reviewers alive?
[10:35:50 CEST] <BtbN> philipl, did you check if yuv444p works for the non-lossless modes? I remember it beeing useable excluviely for the lossless mode. So it'd might need a static init function, that sets the supported pixel formats based on the mode.
[11:07:21 CEST] <cone-448> ffmpeg 03Stefano Sabatini 07master:8cbce1001db3: doc/muxers/segment: fix formatting of segment_list_type option
[11:11:34 CEST] <Newbie> hi
[11:12:37 CEST] <Guest92195> Helloo
[11:12:50 CEST] <Guest92195> HIiiiiiiiiiiiiiiiiiiiiiiii
[11:13:02 CEST] <Guest92195> help me please!!!!!!!!!!!!!!!!
[11:13:14 CEST] <phh> no
[11:13:35 CEST] <Guest92195> hi phh
[11:13:36 CEST] <phh> well, anyway, noone can
[11:13:48 CEST] <phh> since noone knows your problem
[11:14:03 CEST] <Guest92195> i have problem when i capture Screen
[11:14:11 CEST] <wm4> Guest92195: go to #ffmpeg
[11:14:17 CEST] <wm4> your question is offtopic here
[11:15:02 CEST] <Guest92195> no no
[11:15:07 CEST] <[-T-]> hey
[11:15:08 CEST] <[-T-]> https://github.com/TheTroll/FFmpeg/commit/16787892da578c29cf2578a7af4a1eac89891321
[11:15:12 CEST] <Guest92195> I develop software using FFMPEG library
[11:15:22 CEST] <ubitux> then it's offtopic
[11:15:25 CEST] <[-T-]> it works nicely in tvh
[11:16:09 CEST] <nevcairiel> Guest92195: this channel is for developing ffmpeg itself, not using ffmpeg, not developing software with ffmpeg
[11:16:14 CEST] <wm4> [-T-]: that looks pretty clean
[11:16:29 CEST] <Guest92195> Sorry ALL
[11:16:44 CEST] <j-b> Why doing changes in qsvdec_h264.c
[11:16:52 CEST] <j-b> in a commit for qsv_mpeg2?
[11:17:08 CEST] <j-b> but, yes, that's what I remembered from Luca, and that was a sane patch
[11:18:32 CEST] <wm4> j-b: yeah, and the changes in that file are wrong
[11:19:50 CEST] <nevcairiel> thats what happens when some random guy picks old patches from someplace without really knowing wtf is going on
[11:20:01 CEST] <nevcairiel> also, i dont understand why everyone obsesses a bout qsv decoders that much
[11:20:10 CEST] <nevcairiel> its just a wrapper around vaapi or dxva2, depending on platform
[11:20:51 CEST] <j-b> +10
[11:20:55 CEST] <nevcairiel> (and in my experience, not a bug free wrapper)
[11:20:59 CEST] <[-T-]> f'wm4: well this one is pretty clean, but it's using a less clean patch
[11:21:45 CEST] <[-T-]> nevcairiel: wtf are you saying ?
[11:21:55 CEST] <[-T-]> first of all, calm down with your words
[11:22:11 CEST] <[-T-]> i am not doing P/R
[11:22:26 CEST] <[-T-]> I know you guys don't give a shit about QSV
[11:22:44 CEST] <j-b> libyami
[11:22:45 CEST] <j-b> lol
[11:22:47 CEST] <nevcairiel> and neither should you, it just adds another layer in between ffmpeg and the hardware, and more layers mean more bugs
[11:23:02 CEST] <wm4> <nevcairiel> its just a wrapper around vaapi or dxva2, depending on platform <- oh, so that's its dirty secret?
[11:23:18 CEST] <j-b> well, in cases, it fallbacks to software
[11:23:25 CEST] <nevcairiel> yeah it can also do that
[11:23:26 CEST] <j-b> but I did not say it.
[11:23:40 CEST] <nevcairiel> at least on windows it also has software decoders for all the codecs
[11:23:44 CEST] <[-T-]> (and yes, you are right, there should not be changes in h264_qsv in this commit, it's just that I fixed a problem that impacted both qsv decoders...)
[11:23:45 CEST] <nevcairiel> but you obviously dont want to use them
[11:24:08 CEST] <[-T-]> 11:18 < f'wm4> j-b: yeah, and the changes in that file are wrong
[11:24:13 CEST] <[-T-]> can you elaborate ?
[11:24:34 CEST] <nevcairiel> "ret < 0" is the correct check, just if (ret) is wrong
[11:24:36 CEST] <wm4> ret = AVERROR(ENOMEM);
[11:24:39 CEST] <wm4> return AVERROR(ret);
[11:24:42 CEST] <wm4> makes no sense
[11:24:43 CEST] <[-T-]> yes sorry wm4
[11:24:45 CEST] <[-T-]> you are right
[11:24:48 CEST] <j-b> it does make sense
[11:24:51 CEST] <[-T-]> it's correct in the mpeg2 file though
[11:24:59 CEST] <[-T-]> nevcairiel: no
[11:25:00 CEST] <j-b> AVERROR(AVERROR(AVERROR(AVERROR(ENOMEM))));
[11:25:21 CEST] <[-T-]> because AVERROR(EGAIN) = 11 
[11:25:23 CEST] <[-T-]> and 11 > 0
[11:25:30 CEST] <wm4> [-T-]: wrong
[11:25:33 CEST] <[-T-]> it leads to a crash
[11:25:40 CEST] <wm4> it's negative
[11:25:46 CEST] <[-T-]> well .. not in my tests
[11:25:50 CEST] <nevcairiel> all error codes are negative
[11:25:51 CEST] <wm4> then your tests are broken
[11:26:06 CEST] <[-T-]> let me double check that ...
[11:28:00 CEST] <wm4> do you really think that at least 50% of all code in ffmpeg is wrong?
[11:28:32 CEST] <nevcairiel> you get such problems if you do thinks like AVERROR(ret)
[11:28:37 CEST] <nevcairiel> because it may turn it back positive
[11:29:03 CEST] <[-T-]> what do you mean ?
[11:29:12 CEST] <[-T-]> oh ok...
[11:29:18 CEST] <[-T-]> you are sooooo funny
[11:33:58 CEST] <[-T-]> ok it's always negative ... not sure what went wrong in my log last time...
[11:34:02 CEST] <[-T-]> i ll fix this
[11:43:04 CEST] <j-b> https://blogs.gnome.org/uraeus/2015/06/30/introducing-pulse-video/
[11:45:30 CEST] <[-T-]> a "better" one
[11:45:30 CEST] <[-T-]>     Add QSV MPEG2 decoding support
[11:45:30 CEST] <[-T-]>     Correct qsv_h264.c DecodeHeader when more Data is needed
[11:45:30 CEST] <[-T-]>     QSV Decoding is based on drocon11 ffmpeg fork (thanks!)
[11:45:33 CEST] <[-T-]> oups
[11:45:38 CEST] <[-T-]> https://github.com/TheTroll/FFmpeg/commit/18b3b8fdfd13c72469629840e3d29df670524bfb
[11:45:42 CEST] <[-T-]> this one :)
[11:45:51 CEST] <[-T-]> again, it's not meant for PR
[11:46:02 CEST] <[-T-]> but it may be usefull for some people
[11:48:08 CEST] <__gb__> A way to import native { DXVA2, D3D11, VA-API } surface into an mfxSurfaceFrame or whatever it's called should be more appropriate to avoid MFX decoders
[11:49:00 CEST] <__gb__> using the native functions would be much faster, as you'd probably also avoiding checking for e.g. NAL boundaries (start code) multiple times
[11:49:45 CEST] <__gb__> in some situations, looking for the next start code is actually the most CPU intensive residual task when HW decode is involved...
[11:52:21 CEST] <[-T-]> __gb__: why part of the layers is looking for the start codes ?
[11:52:26 CEST] <[-T-]> is it done in SW ?
[11:52:43 CEST] <nevcairiel> j-b: at least its only Video cameras, not output or some shit
[11:55:56 CEST] <j-b> nevcairiel: for now...
[11:56:08 CEST] <[-T-]> why only video cameras ?
[12:00:11 CEST] <[-T-]> here is a "perf report" of a tvheadend transcoding from mpeg2_qsv 576i to h264_qsv 720p
[12:00:14 CEST] <[-T-]> http://pastebin.com/FF3bjwLZ
[12:16:15 CEST] <wm4> j-b: it would be awesome if video decoding APIs would be made privleged, and everything had to go through PulseVideo to use it!
[12:16:44 CEST] <j-b> wm4: don't laugh
[12:25:14 CEST] <durandal_170> move it into kernel
[13:16:04 CEST] <Compn> [-T-] : you'll have to put up with nevcairiel , hes being a real pain as of late.
[13:17:52 CEST] <nevcairiel> because I'm saying the truth? Go deal with it =p
[13:18:06 CEST] <Compn> John Adlum (April 29, 1759 – March 14, 1836) was a pioneering American  viticulturalist who was the first to cultivate the Catawba grape. 
[13:18:30 CEST] <Compn> sour grapes.
[13:21:58 CEST] <durandal_170> michaelni?
[13:23:01 CEST] <michaelni> durandal_170, ?
[13:23:08 CEST] <durandal_170> after Elvis is gone...
[13:26:15 CEST] <durandal_170> michaelni: should we care for backward compatibility when converting find_rect and cover_rect to dualinput?
[13:26:25 CEST] <[-T-]> nevcairiel: the truth is that instead of give me advices on how to improve what I did, you indirectly provocted/insulted me
[13:26:38 CEST] <[-T-]> you must be a very nice guy irl..
[13:27:05 CEST] <nevcairiel> when i told you wahts wrong, you said "no, I'm right", so shrug
[13:27:33 CEST] <[-T-]> is it a joke ?:)
[13:27:35 CEST] <[-T-]> 11:19 <+f'nevcairiel> thats what happens when some random guy picks old patches from someplace without really knowing wtf is going on                                                                   @f'sireta~
[13:27:41 CEST] <[-T-]> this is your first message
[13:28:27 CEST] <nevcairiel> if you find that insulting, you should really not visit the internet
[13:28:36 CEST] <[-T-]> ...
[13:29:09 CEST] <[-T-]> I have nothing more to say :)
[13:32:17 CEST] <__gb__> [-T-], looking for start codes is needed to extract NAL units and their related headers where you extract additional info to pass to the HW
[13:32:32 CEST] <[-T-]> yep ok
[13:32:50 CEST] <[-T-]> where is it currently done ?
[13:32:57 CEST] <__gb__> unless there is a way to tell MSDK that you feed it with e.g. NAL units instead of whole access units, it would scan for start codes again there, imho
[13:34:33 CEST] <__gb__> the point is, it's totally useless to supply QSV-based decoders, the better option is to work on interop from native hwaccel & qsv for e.g. encoding or other video processing
[13:35:01 CEST] <__gb__> especially since, in Linux, you have to supply a VADisplay anyway, so, you could just be fine with ffmpeg vaapi decoders for instance
[13:35:17 CEST] <nevcairiel> not only useless but also a new source for bugs. If you have the alternatives of: ffmpeg -> qsv -> vaapi -> hardware, or ffmpeg -> vaapi -> hardware ... the second is going to be a better choice
[13:35:42 CEST] <__gb__> some additional helpers akin to newer vdpau's from courmisch  would be useful
[13:36:04 CEST] <michaelni> durandal_170, how hard/messy is backward compat?
[13:36:18 CEST] <michaelni> if its easy, i think compatibility is always a good ide
[13:36:19 CEST] <michaelni> a
[13:38:53 CEST] <__gb__> nevcairiel, yes, and I have also mentioned the performance aspect wrt. scanning for start codes again at the MSDK level
[13:38:54 CEST] <[-T-]> totally useless is maybe a bit exagerated, it's a 15%CPU gain on my machine
[13:39:25 CEST] <nevcairiel> compared to software decoding? certainly. compared to vaapi decoding? likely not
[13:39:25 CEST] <[-T-]> but I get your point
[13:39:26 CEST] <Compn> [-T-] : i think he means useless vs using vaapi or vdpau
[13:39:34 CEST] <[-T-]> oh ok
[13:39:36 CEST] <[-T-]> sorry
[13:39:41 CEST] <Compn> or dxva2
[13:39:46 CEST] <[-T-]> yep ok
[13:39:47 CEST] <nevcairiel> the point is that qsv just uses vaapi internally
[13:39:53 CEST] <nevcairiel> so you can cut out an extra layer in between
[13:39:57 CEST] <nevcairiel> it only adds overhead
[13:40:00 CEST] <[-T-]> yes ok
[13:40:17 CEST] <Compn> nevcairiel : does it add stability or ease of use ?
[13:40:59 CEST] <[-T-]> btw, I get the exact same kind of gain using VPDAU
[13:41:21 CEST] <__gb__> in my older measurements, scanning for startcodes is number 1 function hotspot for the whole decoding processing with vaapi
[13:41:26 CEST] <[-T-]> I mean, VDPAU and QSV decoding bring about the same gain over sw
[13:41:55 CEST] <__gb__> and optimizing it, or removing a couple of occurrences of it, could reduce the overall amount of instructions by ~15+%
[13:42:34 CEST] <[-T-]> the code that looks for SC is in libavcodec/utils ?
[13:42:54 CEST] <__gb__> yes, and ffmpeg
[13:43:04 CEST] <__gb__> 's version is quite optimized already
[13:43:10 CEST] <[-T-]> ok
[13:55:04 CEST] <durandal_170> find_rect is so slow
[13:56:27 CEST] <nevcairiel> Compn: in my experience on windows, it adds bugs, so using dxva2 directly is favorable to me .. although I suppose its easier to use. But if you have avcodec already anyway, t hen the ease of use argument melts away since s omeone else has already done the heavy lifting
[14:44:26 CEST] <Daemon404> philipl, the target_smver stuff sure is lulzy
[14:44:34 CEST] <Daemon404> there are no enums or defines for the magic numbers?
[14:46:27 CEST] <BtbN> nope
[14:46:55 CEST] <Daemon404> that's pretty awful
[14:46:57 CEST] <Daemon404> but hey. nvidia.
[14:47:30 CEST] <BtbN> It's not part of the nvenc api though
[14:47:38 CEST] <BtbN> that part is CUDA
[14:47:42 CEST] <Daemon404> still nvidia.
[14:47:55 CEST] <BtbN> You don't have to use CUDA for nvenc
[14:47:59 CEST] <BtbN> unless you are on linux
[15:07:22 CEST] <cone-448> ffmpeg 03Ivan Uskov 07master:db89f45535aa: avcodec/qsv: Extending QSV/MFX session initialization for the linux platform where a display handle is required.
[15:21:05 CEST] <[-T-]> Thanks Ivan!
[15:21:12 CEST] <[-T-]> are you on the chan ?
[16:10:47 CEST] <philipl> BtbN: It seems to work in lossy mode.
[16:31:58 CEST] <durandal_170> Looks like everybody hates me and my patches
[16:32:19 CEST] <wm4> nevcairiel: is it possible that when using opengl on windows in exclusive mode (fullscreen, the driver forces it), you can't use d3d?
[16:32:25 CEST] <ubitux> durandal_170: what do you need review on?
[16:32:35 CEST] <nevcairiel> wm4: no idea, never dealt with ogl fullscreen exclusive
[16:32:40 CEST] <wm4> nevcairiel: actually I'm trying to use dxva2, but that of course requires d3d
[16:33:21 CEST] <wm4> and a similar problem doesn't exist with d3d exclusive mode?
[16:33:46 CEST] <nevcairiel> well it can
[16:34:01 CEST] <nevcairiel> you have to create the d3d device before the exclusive mode locks stuff up
[16:34:33 CEST] <nevcairiel> but if you render in d3d anyway, you can also just use the render device
[16:35:08 CEST] <durandal_170> ubitux: ya8 astats (a)drawgraph lut lavfi
[16:35:15 CEST] <wm4> a bit hard with ogl and if the application starts in fullscreen
[16:45:42 CEST] <BtbN> philipl, i'll test it later today or tomorrow on my Kepler hw
[16:49:10 CEST] <philipl> BtbN: cheers.
[16:49:25 CEST] <nevcairiel> Daemon404: the smver thing isnt all that magic really though, its just 4 bits of major and 4 bits of minor version
[16:49:30 CEST] <BtbN> Currently too busy melting to test anything
[16:49:33 CEST] <nevcairiel> 0x30 = 3.0, 0x52 = 5.2
[16:50:10 CEST] <nevcairiel> and yeah. f'ing summer
[16:50:12 CEST] <nevcairiel> who invented this
[16:50:24 CEST] <Daemon404> it's only bad because europe is a third world continent
[16:50:26 CEST] <nevcairiel> its supposed to get even hotter tomorrow
[16:50:31 CEST] <Daemon404> and doesnt have things like screens on windows
[16:50:32 CEST] <Daemon404> or AC.
[16:50:47 CEST] <nevcairiel> ACs are not really worth it for 6 days of hot weather a year
[16:50:57 CEST] <nevcairiel> but during those 6 days, we do want them =p
[16:51:11 CEST] <BtbN> I'll have a lot of work in our server rooms the next weeks
[16:51:13 CEST] <Daemon404> i am seriously thinking of getting screens *made* for my place.
[16:51:22 CEST] <Daemon404> i dont get why europeans dont have window screens
[16:51:25 CEST] <Daemon404> to keep bugs out
[16:51:30 CEST] <Daemon404> as soon as i open ym windows -> YAY BUGS
[16:51:38 CEST] <nevcairiel> plenty  people install bug screens
[16:51:39 CEST] <BtbN> I have those on every single window?
[16:52:00 CEST] <nevcairiel> i dont have them myself, but bugs arent that bad in this area
[16:52:04 CEST] <BtbN> Not only against bugs, but against pollen, because of allergies.
[16:52:11 CEST] <Daemon404> nevcairiel, none in any place ive been
[16:52:18 CEST] <RiCON> screens stop pollen?
[16:52:21 CEST] <Daemon404> yes
[16:52:22 CEST] <nevcairiel> some can
[16:52:23 CEST] <Daemon404> they do.
[16:52:25 CEST] <J_Darnley> uh, a bug screen is far too large to stop pollen
[16:52:26 CEST] <BtbN> there are special ones that do
[16:52:51 CEST] <Daemon404> BtbN, what country?
[16:52:54 CEST] <BtbN> germany
[16:52:58 CEST] <Daemon404> same as nevcairiel 
[16:53:15 CEST] <Daemon404> i have never seen one in the UK, ireland, netherlands, belgium, france...
[16:53:25 CEST] <Daemon404> italy i am told does not
[16:53:25 CEST] <nevcairiel> my parents have bug screens on all bedroom windows, so they can open those at night and stuff and still keep them out
[16:53:27 CEST] <BtbN> I installed them myself, but they are not that uncommon
[16:53:29 CEST] <nevcairiel> not on all windows though
[16:53:43 CEST] <Daemon404> maybe its more common in .de
[16:54:06 CEST] <Daemon404> meanwhile in the UK, insulated housing is a luxury
[16:54:50 CEST] <nevcairiel> we do have proper insulation most of the time, which means houses don't heat up that quickly during summer either
[16:55:05 CEST] <RiCON> Daemon404: you'd hate portugal then, don't come here on vacation
[16:55:15 CEST] <Daemon404> vacation is fine
[16:55:17 CEST] <Daemon404> hotels have AC
[16:55:36 CEST] <Daemon404> nevcairiel, i am moving into a newly built property this weekend (i bought a house)
[16:55:40 CEST] <Daemon404> it is actually insulted
[16:55:44 CEST] <Daemon404> my previous 3 places werent
[16:55:50 CEST] <Daemon404> 2 of which didnt even have double glazed windows.
[16:55:52 CEST] <nevcairiel> why do you insult your new house
[16:56:07 CEST] <Daemon404> i did?
[16:56:15 CEST] <nevcairiel> you said its insulted
[16:56:19 CEST] <nevcairiel> i assume you did the insulting!
[16:56:22 CEST] <Daemon404> oh
[16:56:23 CEST] <Daemon404> lol
[16:56:24 CEST] <Daemon404> typo.
[16:57:00 CEST] <Daemon404> nevcairiel, germany also has actual winters in some bits
[16:57:07 CEST] <Daemon404> so i assume you'd need it.
[16:57:10 CEST] <nevcairiel> but yeah, we usually tend to have double glazed windows at least, and any house or apartment building constructed in the last two decades or so will have proper insulation
[16:58:27 CEST] <nevcairiel> in fact, if you wanted to build something new, you would probably not get a license if its not properly insulated
[16:58:36 CEST] <nevcairiel> no idea how old those laws are
[16:59:05 CEST] <Daemon404> i know houses here probably wouldnt pass building codes in other countries
[16:59:16 CEST] <Daemon404> e.g. exterior walls have pipes in them
[16:59:20 CEST] <Daemon404> or out them
[16:59:27 CEST] <Daemon404> which is an awesome way to freeze/explode your pipes
[16:59:29 CEST] <Daemon404> in winter.
[16:59:34 CEST] <nevcairiel> sounds like fun
[16:59:53 CEST] <wm4> I thought UK doesn't have real winters
[17:00:01 CEST] <Daemon404> scotland does
[17:00:05 CEST] <Daemon404> here? no.
[17:00:22 CEST] <BtbN> in my last house, the insulation was litteraly made of straw...
[17:00:32 CEST] <Daemon404> straw is better than air
[17:00:34 CEST] <BtbN> I was living under the roof, and had 45°C on the hottest days
[17:01:22 CEST] <nevcairiel> directly under the roof is often quite painful, especially if the insulation is crap like that
[17:01:25 CEST] <nevcairiel> i couldnt stand that
[17:01:37 CEST] <BtbN> I'm still living under the roof now, but it's propperly insulated.
[17:01:41 CEST] <Daemon404> BtbN, also there houses here with roofs MADE of straw
[17:01:50 CEST] <Daemon404> and theyre listed as historical. you cant remove it.
[17:01:54 CEST] <Daemon404> (it's ugly as shit)
[17:02:04 CEST] <nevcairiel> we have that too
[17:02:37 CEST] <nevcairiel> same historical BS 
[19:07:06 CEST] <cone-448> ffmpeg 03Michael Niedermayer 07master:9dc0bac9719a: avcodec/motion_est_template: Fix undefined shifts in CHECK_MV()
[19:07:07 CEST] <cone-448> ffmpeg 03Michael Niedermayer 07master:c9220d5b0653: avcodec/mjpegdec: Reorder operations to avoid undefined behavior
[19:46:24 CEST] <cone-448> ffmpeg 03Ivan Uskov 07master:6e5864ab294c: avcodec/qsvenc_h264: Change the set of performance presets to match with the MFX library constants.
[19:47:11 CEST] <klaxa> how can i properly debug ffmpeg? i compiled it with --enable-debug --disable-optimizations --enable-openssl --enable-shared --enable-pic, when i run it in my debugger (nemiver) not all symbols can be resolved and i can't view the code from the libraries
[19:47:27 CEST] <klaxa> it looks like this: http://dedi.klaxa.eu/public/2015-07-02-194524_3200x1800_scrot.png
[19:47:52 CEST] <klaxa> when i debug my code from doc/examples/ i can view all source files
[19:49:43 CEST] <J_Darnley> Does ffmpeg link witht the correct shared libraries?  I see that the paths there start with /usr/loc
[19:49:47 CEST] <klaxa> ah, i have the feeling enabling shared libraries might be an issue
[19:50:05 CEST] <klaxa> i install my freshly compiled libraries in /usr/local/
[19:50:41 CEST] <klaxa> because i couldn't figure out how to tell the makefile/ld to use the libraries i just built when i built my code in doc/example
[19:51:34 CEST] <klaxa> i'm compiling it without shared libraries right now to see if that helps
[19:53:40 CEST] <c_14> klaxa: the `ffmpeg' binary? That's stripped by default, either use the ffmpeg_g binary or --disable-stripping
[19:53:47 CEST] <klaxa> i'm using ffmpeg_g
[19:54:12 CEST] <klaxa> i can see the ffmpeg.c code and everything but nothing from libavformat (which i want to debug :P)
[19:54:26 CEST] <klaxa> s/and everything//
[19:55:18 CEST] <c_14> Might be the shared libraries, because the installed libraries are stripped and then the unstripped ffmpeg_g uses the stripped libraries. Either try static or --disable-stripping
[19:56:07 CEST] <klaxa> okay thanks, i'll try that
[20:02:35 CEST] <klaxa> ah well after switching to the correct branch and recompiling the segfault i wanted to inspect doesn't occur anymore
[20:04:57 CEST] <klaxa> and i also can properly debug it now, thanks!
[21:32:58 CEST] <durandal_170> michaelni: what to do with lut highbit depth support fate test?
[21:33:47 CEST] <durandal_170> just kill pixfmt one and add new ones or something else ?
[21:43:31 CEST] <kierank> a wild netflix appears
[21:47:12 CEST] <michaelni> durandal_170, not sure i understand the question
[21:48:56 CEST] <durandal_170> michaelni: pixfmt tests can't work with >8 bits formats
[21:50:02 CEST] <michaelni> why?
[21:51:52 CEST] <durandal_170> on bigendian you get be fmts on litttle le fmts
[21:52:23 CEST] <durandal_170> filter operates in native format only
[21:53:27 CEST] <michaelni> converting to fixed endiannness might work
[21:53:30 CEST] <durandal_170> there is no switch to use only le fmts
[21:54:48 CEST] <J_Darnley> I thought that -pix_fmt *le gave you a little endian format.
[22:09:23 CEST] <cone-448> ffmpeg 03Paul B Mahol 07master:7ff5a345a46e: avfilter: use AVFILTER_DEFINE_CLASS()
[22:09:24 CEST] <cone-448> ffmpeg 03Paul B Mahol 07master:96953e2ef653: avfilter/vf_mpdecimate: remove packed formats
[23:33:32 CEST] <cone-448> ffmpeg 03Andreas Cadhalpun 07master:d0eff8857cef: wavpack: limit extra_bits to 32 and use get_bits_long
[23:47:40 CEST] <kierank> Daemon404: do my emails appear as spam
[23:52:13 CEST] <jamrial> kierank: i'm having a lot of emails being sent to the spam folder lately. is this something happening to other people as well?
[23:52:19 CEST] <kierank> yes
[23:52:23 CEST] <kierank> @googlemail.com
[23:52:31 CEST] <kierank> and a few others
[23:53:03 CEST] <Daemon404> kierank, no
[23:53:05 CEST] <J_Darnley> heh, someone probably couldn't figure how to unsubscribe to they started hitting the spam button
[23:53:22 CEST] <jamrial> kierank: yeah
[23:53:44 CEST] <nevcairiel> google seems to have screwed up their SPF records or something flagging googlemail.com as invalid
[23:54:31 CEST] <nevcairiel> or the dmarc header in this case, apparently
[23:55:13 CEST] <nevcairiel> people that use such an address should report to google
[23:56:26 CEST] <Daemon404> does google have a german office?
[23:56:42 CEST] <j-b> yes
[23:57:38 CEST] <nevcairiel> several, depending on which branch you want
[23:58:15 CEST] <nevcairiel> i th ink there is an accounting office in my city
[00:00:00 CEST] --- Fri Jul  3 2015