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

[burek]

[00:03:57 CET] <J_Darnley> Gramner and others: after forcing yasm to assume an unaligned stack I see the difference now
[00:08:56 CET] <wm4> Gramner: what does the old protocol do?
[00:09:14 CET] <wm4> surely it was bitmap based, and it was comprssed in some way, like using a screen codec?
[00:10:13 CET] <Gramner> not really sure about the details, but it was quite complex and tried to use different compression schemes for different content
[00:10:39 CET] <Gramner> and utterly horribly to use over anything other than a local >=100Mbit network
[00:14:45 CET] <jkqxz> Lync?  It ran a whole RDP session, sending bitmap fragments losslessly.
[00:16:20 CET] <Gramner> it handles (or at least tries to handle) text separately from graphics
[00:18:12 CET] <Gramner> and input is somehow tied to the rendering, so if you happen to get some flash animation or whatever on the remote screen it can take like half a minute to close that window
[00:21:29 CET] <jkqxz> I don't think text was text, but it certainly had all of the windowing hooks.  So standard movement of things worked well (scrolling text or moving windows - both very hard in a video codec if you don't have the exact vectors in advance).
[00:21:57 CET] <JEEB> hmm
[00:22:07 CET] <JEEB> did avutil have any time-related stuff?
[00:22:50 CET] <Gramner> even scrolling a simple text window is incredibly laggy in rdp if you're doing it over a DSL line
[00:23:17 CET] <Gramner> rdp is kind-of okay:ish if you're on a LAN, but it toally breaks down if bandwidth is limited
[00:25:33 CET] <Gramner> and encoding the screen shouldn't cause that much latency compared to the RTT anyway, as long as you render the cursor locally
[00:28:17 CET] <TD-Linux> well there's multiple versions of the protocol that do very different things
[00:28:24 CET] <TD-Linux> like earlier ones are basically GDI over network
[00:29:29 CET] <Gramner> I mean, with gaikai you could even play first person shooters remotely over the internet, and that's a lot more sensetive to lag than a windows desktop is
[00:35:01 CET] <JEEB> ok, av_gettime is what I want, most probably
[01:15:09 CET] <cone-122> ffmpeg 03Michael Bradshaw 07master:1c40bccc0949: lavc/dirac_dwt: fix building without asm
[01:56:53 CET] <J_Darnley> atomnuker, kierank: where can I find a repo for the dirac encoder?
[01:57:13 CET] <J_Darnley> if there's not a public one I can just use the patch on the ML.
[01:57:29 CET] <kierank> Good q
[02:15:06 CET] <Timothy_Gu> Daemon404: any comments on "configure: Enable GCC vectorization on e4.9"
[02:15:16 CET] <Timothy_Gu> i changed it to x86-only BTW
[02:16:20 CET] <Timothy_Gu> jamrial: ok to push "[PATCH] diracdsp: Make x86 files/functions names consistent"?
[02:42:11 CET] <jamrial> Timothy_Gu: yeah, seems ok. you'll have to rebase the dwt patch, though
[02:42:25 CET] <Timothy_Gu> jamrial: yeah. will push in a moment
[04:32:15 CET] <cone-492> ffmpeg 03Timothy Gu 07master:17ab8f7e6852: diracdsp: Make x86 files/functions names consistent
[04:32:15 CET] <cone-492> ffmpeg 03Timothy Gu 07master:9fd6ea933fa1: dirac_dwt: Make x86 files/functions names consistent
[05:40:44 CET] <cone-492> ffmpeg 03James Almer 07master:3e9b8ffc9bfe: avcodec/dcadsp: rename lfe_fir_float functions
[05:40:45 CET] <cone-492> ffmpeg 03James Almer 07master:8ae744794101: x86/dcadec: add ff_lfe_fir0_float_{sse,sse2,avx,fma3}
[09:14:31 CET] <rcombs> nevcairiel: apparently mingw is missing a few schannel macros; maybe steal the #ifdefs from http://boinc.berkeley.edu/android-boinc/curl-7.22.0/lib/curl_sspi.h?
[09:18:03 CET] <nevcairiel> i have no interest nor a way to test old mingw32, feel free to send a patch, but I would rather ignore it entirely
[09:18:08 CET] <nevcairiel> you should migrate to mingw-w64 already
[09:18:36 CET] <rcombs> this is 64
[09:18:44 CET] <rcombs> well, 32-bit mingw-w64
[09:18:46 CET] <nevcairiel> builds perfectly fine for me =p
[09:18:48 CET] <rcombs> (fuck these names)
[09:19:02 CET] <nevcairiel> on 4.0, not even trunk
[09:27:01 CET] <rcombs> ah, never mind, CI oddity
[09:28:14 CET] <nevcairiel> i think we even have mingw32 fate systems still, so the configure check either disables it, or it builds, so shrug :)
[11:31:17 CET] <atomnuker> okay, the encoder's been on the ML for like 5 days now
[11:31:39 CET] <atomnuker> if there are no objections I'll probably merge it in like 6 or so hours
[11:32:27 CET] <atomnuker> so yeah, go an review the code (this is the Dirac/SMPTE VC-2/Dirac Pro encoder I'm talkinb about)
[12:49:18 CET] <cone-981> ffmpeg 03Paul B Mahol 07master:956fed377b4c: cmdutils: realign for some additional filters with very long name
[14:48:22 CET] <durandal_1707> if I use maskedmerge and h264 decoder I get strange decoding errors
[14:49:47 CET] <nevcairiel> maybe maskedmarge forgot to request writable buffers
[14:50:04 CET] <nevcairiel> merge*
[15:32:30 CET] <wm4> kierank: what's the exact vale range for gbrpa10?
[15:32:49 CET] <wm4> for g/b/r and a components
[15:33:01 CET] <kierank> Full range I guess
[15:33:16 CET] <wm4> so [0,2^10-1]?
[16:06:30 CET] <kierank> wm4: yes, that's what I clip to at least
[16:06:33 CET] <kierank> the alpha I have no idea
[16:06:37 CET] <kierank> I've never used alpha in my life
[16:14:17 CET] <wm4> it would be sane if alpha had the same range as the color components
[16:14:32 CET] <wm4> it's also like that with yuv, I think (so the alpha isn't full range there)
[16:15:44 CET] <BBB> really? thats retarded
[16:15:56 CET] <BBB> I mean, I understand the color meaning of blacker than black"
[16:16:03 CET] <BBB> but more transparent than transparent makes no sense whatsoever
[16:17:31 CET] <JEEB> durandal_1707: the lua thing you posted seems perversely interesting
[16:20:18 CET] <durandal_1707> its just that, I cant do more, but its certainly better way of writing filtergraphs
[16:20:52 CET] <JEEB> how much stuff do you have access there?
[16:20:58 CET] <JEEB> stream lists?
[16:21:56 CET] <wm4> BBB: out of range values are not supposed to happen in yuv
[16:22:01 CET] <JEEB> so you could in theory do stuff like "if input contains a vobsub/dvbsub track, add the subtitle rendering filter chain
[16:22:04 CET] <wm4> so they don't need to make sense
[16:22:57 CET] <BBB> they absolutely do happen
[16:23:00 CET] <BBB> they even have meaning
[16:23:03 CET] <BBB> its very clearly defined
[16:23:13 CET] <BBB> you can clip them out if you dont want, but thats implementation defined
[16:23:37 CET] <BBB> search for blacker than black
[16:23:47 CET] <BBB> itll bring you back to antiquated mpeg documents explaining it all
[16:23:49 CET] <nevcairiel> Out of range values happen often enough, as wtw and btb, even if I find them nonsensical personally, any good display shouldn't be able to display them
[16:24:22 CET] <BBB> theyre nonsense with more modern color spaces such as bt2020
[16:24:25 CET] <BBB> or smpte240
[16:25:02 CET] <BBB> not nonsense as in having no meaning, but nonsense as in rpobably not adding very much
[16:25:11 CET] <wm4> this isn't about out of range values for limited range yuv, but our of range of the defined full range value range
[16:25:12 CET] <kierank> out of range values happen a lot in the real world
[16:25:25 CET] <kierank> filter overshoots etc
[16:25:32 CET] <kierank> not to mention out of gamut issues
[16:26:03 CET] <BBB> oh I see
[16:26:06 CET] <cone-492> ffmpeg 03Andreas Cadhalpun 07master:e740c3fb90c0: configure: fall back to using full path if src is a directory
[16:26:06 CET] <cone-492> ffmpeg 03Andreas Cadhalpun 07master:bb7522ce67e5: build: fix lcov with src link
[16:26:06 CET] <cone-492> ffmpeg 03Andreas Cadhalpun 07master:14bf59c1d5b5: build: use intermediate lcov coverage file
[16:26:10 CET] <BBB> you mean out of [0,2^10-1] range
[16:26:26 CET] <BBB> I Guess wed call that bit width
[16:26:32 CET] <BBB> sorry about that
[16:26:53 CET] <BBB> doesnt h264 allow separate bit widths for luma and chroma?
[16:26:57 CET] <BBB> its hilarious in a way
[16:27:03 CET] <nevcairiel> It does
[16:27:09 CET] <nevcairiel> But we don't support it :D
[16:27:23 CET] <BBB> thank goodness
[16:27:37 CET] <kierank> we should, j-b would go nuts
[16:27:46 CET] <BBB> if we ever see such a file, we should display a warning to the user to use a special commandline option for fuzzing, and else well format c:
[16:28:16 CET] <BBB> I think we already made jb go nuts
[16:28:19 CET] <BBB> poor guy
[16:59:07 CET] <atomnuker> so yeah, if someone can look at my VC-2/Dirac encoder that'd be nice
[16:59:28 CET] <atomnuker> it's been like a month now and other than a few style issues no one has said a word
[17:09:02 CET] <J_Darnley> atomnuker: is the code available in a public git somewhere?
[17:11:13 CET] <atomnuker> J_Darnley: give me 5 mins
[17:12:26 CET] <J_Darnley> That sounds like "no" to me so thank you if you're pushing it somewhere.
[17:16:37 CET] <atomnuker> J_Darnley: git am this patch: https://0x0.st/X9z.patch
[17:16:54 CET] <atomnuker> (to git master)
[17:17:25 CET] <atomnuker> the transforms are in libavcodec/vc2_dwt.c
[17:17:47 CET] <atomnuker> they're the main source of overhead
[17:19:29 CET] <atomnuker> but if you can take a look to see I'm not doing something insane so I could merge it that'd be nice too
[17:20:05 CET] <atomnuker> or say if you want a real repository on like github
[17:20:33 CET] <J_Darnley> Nah.  an up-to-date patch is fine
[17:29:28 CET] <j-b> BBB: I am not nuts, I'm very well, tbh.
[17:55:54 CET] <J_Darnley> atomnuker: I think you need to check for overflows when you allocate memory in the init_transforms function.
[17:56:48 CET] <J_Darnley> brb
[17:56:54 CET] <BBB> j-b: thats what all crazies say Im not crazy, Im an airplane!
[18:00:58 CET] <J_Darnley> Another suggestion would be to have int strides start as ptrdiff_t types in the transformssothey don't get changed later.
[18:02:13 CET] <atomnuker> J_Darnley: fair enough, I'll call avcodec_check_dimensions() in the main encoder init function
[18:02:14 CET] <J_Darnley> s/transformssothey/transforms so they/
[18:46:32 CET] <durandal_1707> this mats is getting on my nerves
[18:52:46 CET] <Loriker> ...mail flood
[18:53:14 CET] <ac_slater> hey guys. Anyone have a clue as to why MPEGTS + AVC (baseline) would cause a pause every second for about 30ms?
[18:53:30 CET] <ac_slater> I've been having this issue since 2.1 :(
[18:53:55 CET] <Compn> playback? encoding? command line ?
[18:54:04 CET] <ac_slater> Compn: yup getting a paste setup
[18:54:04 CET] <Compn> whats your source? filters? 
[18:54:06 CET] <Compn> heh
[18:54:15 CET] <Compn> also ask in #ffmpeg , this channel is for developers 
[18:56:18 CET] <ac_slater> true, figured it was a bug since it happens with both mpeg2 and x264 encoders. My test sources are lavfi testsrc, v4l2, or even a rawvideo in yuv420p to avoid the auto scaling. Heh indeed. I'll file a bug report
[18:56:57 CET] <ac_slater> and, since 2.1. Haven't tried earlier versions
[18:58:40 CET] <ac_slater> bug in the mpegts muxer * 
[19:27:40 CET] <wm4> nevcairiel: well I'm leaving the debian guy to you
[19:31:36 CET] <Daemon404> the worst part about these sorts of people is that they have infintie energy to argue their side
[19:31:44 CET] <Daemon404> eventually everyone else gets tired / gives up
[19:31:48 CET] <Daemon404> -> shit is pushed
[19:32:06 CET] <JEEB> :/
[19:32:43 CET] <Gramner> so the Ubuntu 16.04 LTS feature freeze is set at february 17, I think it would be beneficial to aim for a 2.9 or 3.0 release before that
[19:33:34 CET] Action: Daemon404 should finish merging then
[19:40:45 CET] <wm4> now it's apparently either apply that patch and add exceptions (vp9) as they come, or wait for BBB to do magic
[19:41:11 CET] <wm4> and all because courmisch trolled the debian guy into reverting the patch in ffmpeg
[19:41:12 CET] <wm4> bleh
[19:42:06 CET] <durandal_1707> How evil
[20:28:00 CET] <Gramner> http://www.econotimes.com/TECHNICOLOR-TECHNICOLOR-WITHDRAWS-FROM-THE-HEVC-ADVANCE-POOL-TO-ENABLE-DIRECT-LICENSING-OF-ITS-HEVC-IP-PORTFOLIO-155090 oh great, now you need to license patents from 3 parties (MPEG-LA + HEVC Advance + Technicolor) if you want to use HEVC. as if the terms didn't suck enough as it was
[20:29:13 CET] <nevcairiel> I doubt all relevant patents were included in the two pools before
[20:31:07 CET] <JEEB> Gramner: kind of makes me feel sorry for the format in some weird way
[20:31:27 CET] <Gramner> that statement holds true for pretty much every modern compression technology though. you never know when/if some patent trolls turns up from nowhere
[20:31:53 CET] <JEEB> yeah
[20:39:07 CET] <jkqxz> They have decided to license separately "to accelerate adoption of the standard".  Yes, that totally makes sense.
[20:39:39 CET] <Gramner> yeah, it's totally not to make some short term cash grab
[20:40:00 CET] <Gramner> would probably have sounded more sincere to not write any reason at all
[20:48:03 CET] <BBB> the ML is so much fun these days
[20:48:11 CET] <jkqxz> I suppose it could kindof make sense if they had some internal argument about how the media licence part of it is killing the standard.  They do say they only want to license devices.
[20:48:39 CET] <Daemon404> whici is a ridiuculous stance to take
[20:50:20 CET] <BBB> huh?
[20:50:28 CET] <BBB> I was talking about the hwaccel/threading trollfest
[20:50:37 CET] <BBB> no idea what you guys are talking about
[20:51:55 CET] <Daemon404> [19:28] < Gramner> http://www.econotimes.com/TECHNICOLOR-TECHNICOLOR-WITHDRAWS-FROM-THE-HEVC-ADVANCE-POOL-TO-ENABLE-DIRECT-LICENSING-OF-ITS-HEVC-IP-PORTFOLIO-155090 oh great, now you need to license patents from 3 parties (MPEG-LA + HEVC Advance + Technicolor) if you want to use HEVC. as if the terms didn't suck enough as it was
[20:52:00 CET] <Daemon404> this
[20:52:07 CET] <Daemon404> feel free to die laughing
[20:52:21 CET] <BBB> omg Im so pleased
[20:52:32 CET] <BBB> this shit gets better every day
[20:52:49 CET] <Daemon404> i just dont get how these entities make such decisions
[20:52:53 CET] <BBB> plus dont forget that some parties werent part of either mpegla or hevc advance already
[20:53:09 CET] <Gramner> if they only cared about devices they should've joined MPEG-LA instead. MPEG-LA has pretty reaosnable terms
[20:53:12 CET] <BBB> well, theres a troll with a big boat
[20:53:24 CET] <BBB> and his wife complains one day, why do our friends from across the lake have two boats and we only one
[20:53:32 CET] <BBB> plus, they have a private 747, we only have a private 767
[20:53:32 CET] <Daemon404> it sounds like everyone thought they could have made more money on the great success of h264
[20:53:36 CET] <BBB> and hes like
[20:53:38 CET] <BBB> ok
[20:53:38 CET] <Daemon404> so they want $$$ from hevc
[20:53:44 CET] <Daemon404> but are murdering it before its taken off
[20:53:46 CET] <BBB> let me whip my lawyers and get more money out of our technology
[20:54:09 CET] <Daemon404> [19:53] <@BBB> plus, they have a private 747, we only have a private 767
[20:54:13 CET] <Daemon404> bullcrap
[20:54:15 CET] <BBB> I Think companies are happy to pay for technologies if the value is obvious
[20:54:17 CET] <Daemon404> they' want a private A380!
[20:54:23 CET] <BBB> true, true, sorry
[20:54:23 CET] <Gramner> while forgetting that a large part of the reason that H.264 was so successful is that the licensing terms was very reasonable
[20:54:26 CET] <BBB> one A380?
[20:54:30 CET] <BBB> one for each member of the family
[20:54:38 CET] <BBB> I Dont want to sit in the same A380 as my little baby sister
[20:54:38 CET] <Daemon404> Gramner, exactly
[20:54:39 CET] <BBB> come on
[20:54:52 CET] <BBB> whats my relationship to hevc again?
[20:55:08 CET] <BBB> oooooo right I got one troll patent in about a bit that codes some obscure thing nobody gives a shit about
[20:55:15 CET] <BBB> actually, I didn't
[20:55:18 CET] <BBB> my lawyer did
[20:55:24 CET] <BBB> BUT I WANT MY A380!!!1223one
[20:55:41 CET] <BBB> s/A380/A380s/
[20:55:58 CET] <Gramner> "a bit that codes some obscure thing nobody gives a shit about" <- doesn't that description cover the vast majority of software patents
[20:55:59 CET] <BBB> and they wonder why companies are dying to move over to hevc very quickly
[20:56:08 CET] <BBB> Gramner: yup, exactly my point
[20:56:17 CET] <wm4> it sure is funny when those who want to make money out of patents get into trouble with patent trolls
[20:56:23 CET] <BBB> this might be a good reason to create a hevc basic"
[20:56:25 CET] <Daemon404> Gramner, you forgot the other type
[20:56:28 CET] <BBB> which covers most improvements over h264
[20:56:31 CET] <BBB> but has no troll patents
[20:56:42 CET] <Daemon404> "loops over a value and increments"
[20:56:42 CET] <Daemon404> BA<
[20:56:44 CET] <Daemon404> vage patent
[20:56:48 CET] <Daemon404> vague* BAM*
[20:57:14 CET] <Daemon404> BBB, hevc basis *kind of* exists with Thor... but it's too basic
[20:57:27 CET] <BBB> nah, that doesnt aven have cabac
[20:57:34 CET] <BBB> I didnt mean broken hevc basic"
[20:57:41 CET] <BBB> I meant correctly functional hevc basic"
[20:57:48 CET] <Daemon404> i was petty sure cabac had some troll patent
[20:57:58 CET] <BBB> so use the h264 cabac
[20:58:01 CET] <BBB> its not that bad
[20:58:04 CET] <BBB> the basic thing is the same
[20:58:09 CET] <BBB> the contexts are different
[20:58:14 CET] <BBB> so code elements differently and youre ok
[20:58:21 CET] <BBB> and then license h264 through mpegla
[20:58:22 CET] <BBB> done
[20:58:30 CET] <JEEB> uhh, aren't HEVC and AVC CABACs the same?
[20:58:38 CET] <JEEB> HEVC just removed CAVLC
[20:58:48 CET] <BBB> the contexts are different
[20:58:52 CET] <JEEB> oh
[20:58:52 CET] <BBB> the basic algo is the same, yes
[20:58:56 CET] <JEEB> ok
[20:59:01 CET] <BBB> you could probably patent the contexts right?
[20:59:12 CET] <BBB> I mean, you could patent the shape of the edges of an iphone
[20:59:20 CET] <BBB> you can probably patent contexts
[20:59:41 CET] <BBB> anyway, I couldnt be happier
[21:01:17 CET] <JEEB> HEVC has gone so bad licensing-wise I'm almost thinking that someone at googleplex is constantly holding a glass of red wine and having his face darkened off while laughing in an evil way
[21:04:22 CET] <Gramner> i wonder how many of the same companies are waiting for VP9 to gain traction so they can start the patent trolling there as well
[21:04:24 CET] <jkqxz> And you think that if H.265 dies and VP9 wins then all of the trolls won't try to apply the same things to VP9?  It's not that different, a lot of the patents will be sufficiently vague to apply to it too.
[21:05:02 CET] <JEEB> yeah, it will totally go that way
[21:05:08 CET] <BBB> this is awesome
[21:05:12 CET] <BBB> so they will all sue google
[21:05:22 CET] <JEEB> nah, they will sue the users
[21:05:29 CET] <BBB> thats google
[21:05:29 CET] <JEEB> I mean, the bigger ones
[21:05:32 CET] <BBB> google is shipping the video
[21:05:35 CET] <BBB> its called youtube
[21:05:46 CET] <JEEB> no, I mean the (inexistant) hw decoders
[21:05:53 CET] <JEEB> and binary distribution
[21:05:57 CET] <JEEB> etc
[21:06:05 CET] <JEEB> video they just can't do jack shit about really
[21:06:06 CET] <BBB> what was on2s hw division called again?
[21:06:10 CET] <BBB> and binary=chrome
[21:06:11 CET] <JEEB> the one in oulu?
[21:06:14 CET] <BBB> yes
[21:06:20 CET] <JEEB> don't remember
[21:06:26 CET] <Gramner> you don't start by sueing the largest company with the most lawyers. you start by going for an easier target so you can gain a precedent
[21:06:28 CET] <BBB> and yes its still part of google
[21:06:54 CET] <JEEB> Gramner: exactly
[21:07:01 CET] <BBB> google will step in to any lawsuit as an interested party, because it shapes a precedent
[21:07:11 CET] <JEEB> well, hopefully that happens :P
[21:07:15 CET] <BBB> and so it will indirectly always be google (unless the user stops using vp9 as a result of the lawsuit)
[21:07:18 CET] <BBB> it will always be google
[21:07:24 CET] <BBB> this is so awesome
[21:07:36 CET] <BBB> its like assured mutual destruction
[21:08:05 CET] <BBB> (its not that I want google to go down, its just that this is exactly the worst-case scenario described for years, and now its playing out right there; so much popcorn)
[21:08:20 CET] <JEEB> yeah
[21:08:31 CET] <JEEB> the stuff of "they can't be as dumb to do that"
[21:08:59 CET] <BBB> oh crap they did it anyway
[21:10:07 CET] <JEEB> the only thing I dislike about this is the fact that VP9 is getting light on it even though it's just born out of the same kind of closed-doors bullshit that makes JCT-VC development process look like open doors
[21:10:59 CET] <JEEB> (I was dumb enough to have hope that after G bought On2 they'd make the process better after VP8 was out of the door)
[21:11:37 CET] <JEEB> but yeah, generally pop corn hour
[21:12:44 CET] <Daemon404> i wish you had said popcorn time
[21:12:55 CET] <BBB> aomedia has an irc channel
[21:13:17 CET] <JEEB> Daemon404: didn't they get sued to hell?
[21:13:54 CET] <Daemon404> thejoke.jpg
[21:14:04 CET] <JEEB> lol
[21:14:21 CET] <BBB> we need a popcorn smiley
[21:14:30 CET] <BBB> life is not compelte without it
[21:14:57 CET] <JEEB> meh, my desktop IME doesn't know the emoji :<
[21:15:16 CET] <Daemon404> we do BBB 
[21:15:18 CET] <Daemon404> 🍿🍿🍿
[21:15:22 CET] <Daemon404> (if you client can show it)
[21:15:27 CET] <BBB> I see 3 squares :(
[21:15:41 CET] <Daemon404> it's unicode 8.0
[21:15:44 CET] <Daemon404> so... new
[21:17:18 CET] <BBB> http://www.unicode.org/emoji/charts/emoji-released.html
[21:17:25 CET] <BBB> sweet
[21:18:00 CET] <BBB> theres also a unicorn
[21:18:05 CET] <JEEB> yup
[21:18:30 CET] <Daemon404> unicode is covering only the important things
[21:18:37 CET] <Daemon404> aka emoji
[21:18:50 CET] <wm4> yet there's no official klingon
[21:19:01 CET] <BBB> maybe next release
[21:19:03 CET] <wm4> (which shows the unicode consortium is full of shit)
[21:19:23 CET] <BBB> lets do a contest, whos more full of shit, hevc or unicode
[21:19:44 CET] <wm4> patents win
[21:33:59 CET] <ubitux> 24+ hours without internet, sadness :(
[21:34:07 CET] <ubitux> BBB: the amphora looks like a bomb..
[21:36:03 CET] Action: Daemon404 calls interpol on ubitux 
[21:58:08 CET] <durandal_1707> ubitux: ping on streamselect and nlmeans
[21:59:19 CET] <ubitux> didn't have try again streamselect but feel free to push if the issue from last time are fixed, no progress on nlmeans
[22:24:24 CET] <Daemon404> i really enjoy the cargo culting with ffmpeg config options
[22:24:29 CET] <Daemon404> that guy has avisynth enabled on max.
[22:24:31 CET] <Daemon404> mac*
[22:27:12 CET] <durandal_1707> ubitux: still working on it?
[22:27:41 CET] <J_Darnley> Daemon404: That's partly why I would like configure to return more errors.
[22:27:43 CET] <ubitux> i still really want to, but got busy lately
[22:27:47 CET] <J_Darnley> atomnuker: sorry I disappeared to make dinner, eat it, and watch a film
[22:27:56 CET] <ubitux> durandal_1707: why are you so obsessed with it, you ask me like every weeek
[22:28:01 CET] <J_Darnley> I didn't have any more obvious comments about dirac/vc2
[22:29:15 CET] <durandal_1707> ubitux: because I'm filter freak
[22:29:40 CET] <jamrial> Daemon404: i've seen recent windows builds still using the memalign hack config option
[22:29:53 CET] <Daemon404> ... i think chrome's build does
[22:29:59 CET] <Daemon404> :/
[22:30:01 CET] <ubitux> durandal_1707: don't want to do the magnification one?
[22:30:07 CET] <ubitux> eulerian magnification
[22:30:44 CET] <jamrial> seriously? Chrome is using it on the one platform that has an aligned realloc function?
[22:35:23 CET] <Daemon404> jamrial, it was... dunno if it still is
[22:37:12 CET] <Daemon404> jamrial, nope im wrong
[22:37:15 CET] <Daemon404> it no longer does
[22:37:28 CET] <jamrial> good :p
[22:37:44 CET] <atomnuker> J_Darnley: thanks, I'll send you a patch in a bit with the fixed ptrdiff_t's
[22:37:48 CET] <JEEB> J_Darnley: it probably didn't error out because that person had installed the deadbeat piece of software called avxsynth
[22:38:01 CET] <JEEB> which is a fork of avisynth not really used by anyone that is buildable on *nix
[22:38:59 CET] <atomnuker> J_Darnley: also what did you mean by checking for overflows in the image dimensions in the transforms? FFmpeg limits the image dimensions to like 16384x16384 AFAIK
[22:39:38 CET] <atomnuker> and I doubt the encoder would ever get a negative size in cast something screws up in the chain
[22:39:39 CET] <wm4> something like this, but who knows for how long
[22:39:39 CET] <J_Darnley> Well, it it gets limited to that elsewhere then it should be fine
[22:39:46 CET] <wm4> (hopefully not forever)
[22:41:37 CET] <J_Darnley> I was concerned that maybe if width and height were great enough then they could overflow INT_MAX and result in too little memory being allocated.
[22:44:05 CET] <J_Darnley> what did I actually say earlier?
[22:44:45 CET] <J_Darnley> oh yes, I did say alloc and init.
[22:50:41 CET] <durandal_1707> ubitux: its patent pending, can I do it?
[22:51:07 CET] <ubitux> there are patents? didn't know that
[22:51:11 CET] <ubitux> matlab code is open though
[22:53:16 CET] <durandal_1707> but its atadenoise in reverse, kind of
[22:53:35 CET] <durandal_1707> Measuring pulse from video
[23:50:04 CET] <nevcairiel> jamrial: the sad part is that the option hasnt been required for years and years, even before the native align functions, configure just enabled the hack when needed, no clue how long it must have been before the option was even needed
[23:52:52 CET] <cone-678> ffmpeg 03Paul B Mahol 07master:d12d48d0a8e1: avfilter: add streamselect and astreamselect filter
[00:00:00 CET] --- Sun Feb  7 2016