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

[burek]

[00:00:00 CEST] <philipl> unexposed, but the hardware is there.
[00:02:10 CEST] <BtbN> same for skylake.
[00:06:46 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:334b11246c3e: avfilter/fade: use AV_OPT_TYPE_BOOL for alpha option
[00:06:55 CEST] <ubitux> (sorry for the noise btw)
[00:06:58 CEST] <jamrial> philipl: 960?
[00:09:43 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:96651e41b0ec: avfilter/fieldmatch: use AV_OPT_TYPE_BOOL for ppsrc, mchroma and chroma options
[00:10:04 CEST] <philipl> jamrial: yeah.
[00:10:20 CEST] <philipl> It's got the same video processing core as the X1, which does hevc and vp9
[00:13:58 CEST] <BtbN> i wonder what intel is planing for libva...
[00:14:17 CEST] <BtbN> The stuff they added to the libva-intel-driver makes me think they will support VP9 via some binary blob
[00:14:38 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:f5436ebe22e9: avfilter/fspp: use AV_OPT_TYPE_BOOL for use_bframe_qp option
[00:14:39 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:a62bf26c28f6: avfilter/il: use AV_OPT_TYPE_BOOL for {luma,chroma,alpha}_swap options
[00:14:58 CEST] <philipl> BtbN: Yeah, their mysterious binary-only commercial vaapi implementation.
[00:15:22 CEST] <BtbN> Did you look at the latest libva-intel-driver commits?
[00:16:19 CEST] <BtbN> The open source driver is now able to chainload another libva driver, and forward certain codecs to it.
[00:17:07 CEST] <BtbN> Also, libva now checks malloc/calloc for null.
[00:17:15 CEST] <BtbN> By aborting if it is...
[00:19:37 CEST] <cone-380> ffmpeg 03Michael Niedermayer 07master:91ca8105dde9: avcodec/h264_sei: Remove "Subtitles with data type 0x%02x" sample request
[00:19:38 CEST] <cone-380> ffmpeg 03Michael Niedermayer 07master:6bda0f6638eb: doc/protocols: Fix usefull typo
[00:20:43 CEST] <philipl> BtbN: fun times. When they say "Shader accelerated" in their slides it means whatever this mysterious binary-only implementation is.
[00:21:04 CEST] <philipl> They had an hevc version for older hardware, IIRC.
[00:21:09 CEST] <BtbN> Well... it's not like the current driver is much better than a binary one.
[00:21:26 CEST] <philipl> Heh. It's naturally obfuscated.
[00:21:38 CEST] <BtbN> well
[00:21:39 CEST] <BtbN> http://cgit.freedesktop.org/vaapi/intel-driver/tree/src/shaders/vme/inter_frame_haswell.g75b
[00:21:55 CEST] <philipl> haha.
[00:22:15 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:dc2802c81ee8: avfilter/kerndeint: use AV_OPT_TYPE_BOOL for the previously missed options
[00:22:24 CEST] <BtbN> That's compiled from http://cgit.freedesktop.org/vaapi/intel-driver/tree/src/shaders/vme/inter_frame_haswell.asm
[00:22:29 CEST] <BtbN> but it's not like that helps a lot
[00:22:46 CEST] <philipl> Isn't the entire instruction set documented, though?
[00:22:53 CEST] <philipl> So technically you can understand it
[00:23:05 CEST] <BtbN> No idea, but i doubt anyone will ever try to get into that code.
[00:23:17 CEST] <philipl> That I believe.
[00:31:49 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:9f846ed4c794: avfilter/haldclut: use AV_OPT_TYPE_BOOL for shortest and repeatlast options
[00:33:48 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:9c52eafd5b93: avfilter/overlay: use AV_OPT_TYPE_BOOL for rgb, shortest and repeatlast options
[00:37:25 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:81e52c6df90d: avfilter/palettegen: use AV_OPT_TYPE_BOOL for reserve_transparent option
[00:41:00 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:d1c4e8c7db75: avfilter/paletteuse: use AV_OPT_TYPE_BOOL for mean_err and debug_accuracy option
[00:43:35 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:9b8e514c14bf: avfilter/spp: use AV_OPT_TYPE_BOOL for use_bframe_qp option
[00:47:29 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:b0431383cb7b: avfilter/unsharp: use AV_OPT_TYPE_BOOL for opencl option
[00:48:23 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:b761033e7f64: avfilter/uspp: use AV_OPT_TYPE_BOOL for use_bframe_qp option
[01:02:17 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:14d6c68824d1: avfilter/vidstabtransform: use AV_OPT_TYPE_BOOL for tripod and debug options
[01:02:18 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:9f4e09649613: avfilter/vignette: use AV_OPT_TYPE_BOOL for dither option
[01:05:02 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:c826f9b28487: avfilter/waveform: use AV_OPT_TYPE_BOOL for mirror option
[01:15:47 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:7b6007204d9e: avfilter/cellauto: use AV_OPT_TYPE_BOOL for a few options
[01:16:57 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:7114282a0d93: avfilter/life: use AV_OPT_TYPE_BOOL for a stitch option
[01:21:11 CEST] <Mista_D> can't create the rav video out of 4K big bunny file, need pix_fmt "NV16". http://pastebin.ca/3156288
[01:21:23 CEST] <Mista_D> sorry, wrong window
[01:32:49 CEST] <cone-380> ffmpeg 03Clément BSsch 07master:143558737302: avfilter/acrossfade: use AV_OPT_TYPE_BOOL for overlap option
[01:33:13 CEST] <ubitux> ok done with this boring stuff
[01:33:24 CEST] <ubitux> i'm too lazy to go through codecs & stuff
[01:33:30 CEST] <ubitux> so hf
[01:59:09 CEST] <cone-380> ffmpeg 03Andrew Stone 07master:a450ec267225: avcodec/libvorbisdec: Fix memory leak
[02:02:37 CEST] <RT|AO> "<@Timothy_Gu> RT|AO: patch pushed, although I'm still curious to hear if it works or not" # yeah it works now :D
[02:20:49 CEST] <Mista_D> Is there a specific build command to enable NV16 (pix_fmt), it is currently disable by default (in v2.7.2).
[02:25:48 CEST] <jamrial> Mista_D: apparently there's no support on swscale for it
[02:30:50 CEST] <Mista_D> jamrial: thanks, digging through older builds.
[02:36:18 CEST] <cone-380> ffmpeg 03Michael Niedermayer 07master:7277a4ace9f5: avformat/http: add reconnect_delay_max option
[02:40:59 CEST] <jamrial> Mista_D: i kinda doubt older builds will have a feature newer ones don't...
[02:41:16 CEST] <jamrial> Mista_D: you could open a feature request ticket. http://trac.ffmpeg.org/
[02:44:11 CEST] <Mista_D> It seems so, no NV16 detected -  "ffmpeg version CVS, build 4759, Copyright (c) 2000-2004 Fabrice Bellard"
[03:03:04 CEST] <cone-380> ffmpeg 03Michael Niedermayer 07master:a7c0373ea396: avformat/mxfenc: Move sponsorship notice to its own comment block
[03:03:05 CEST] <cone-380> ffmpeg 03Michael Niedermayer 07master:2c1ec575960a: avformat/mpegvideo_enc: Move sponsorship notice to its own comment block
[04:12:51 CEST] <cone-380> ffmpeg 03Michael Niedermayer 07n2.8:HEAD: avformat/mpegvideo_enc: Move sponsorship notice to its own comment block
[04:51:47 CEST] <cone-380> ffmpeg 03Michael Niedermayer 07master:e407d70f8359: MAINTAINERS: add 2.8, drop 2.2
[10:05:27 CEST] <BtbN> philipl, https://github.com/01org/intel-hybrid-driver
[10:06:54 CEST] <cone-341> ffmpeg 03Vittorio Giovara 07master:3b8e89523759: codec_desc: Add missing DXV entry
[10:06:55 CEST] <cone-341> ffmpeg 03Hendrik Leppkes 07master:b421455ee099: Merge commit '3b8e895237592fdaffe87cdcd204104200b9ccf9'
[10:06:57 CEST] <BtbN> No idea why they put that into an external driver.
[10:07:15 CEST] <BtbN> It's not even a license issue, it's MIT licensed.
[10:07:33 CEST] <nevcairiel> maybe they wanted to split the complexity
[10:07:45 CEST] <nevcairiel> but its interesting to see they are bringing the hybrid decoding to linux as well
[10:08:03 CEST] <BtbN> They already did bring it to linux, even to older platforms
[10:08:12 CEST] <BtbN> The driver for that comes with the 3000$ Intel Media SDK.
[10:08:29 CEST] <nevcairiel> way to get into the linux spirit :)
[10:44:36 CEST] <durandal_170> how does scale filter changes frame size? I want to do same with crop
[11:03:50 CEST] <nevcairiel> mm I wonder if Microsoft adopting VP9 means they will actually produce a DXVA2 spec for it, or if they'll cheap out
[11:03:57 CEST] <BtbN> Doesn't it use swscale for that?
[11:05:02 CEST] <BtbN> Does ffmpeg VP9 even have the neccesary "hooks" for hwaccel?
[11:05:06 CEST] <BtbN> Doesn't look like it.
[11:05:13 CEST] <BtbN> Same for mjpeg and vp8 i guess
[11:05:13 CEST] <nevcairiel> not yet, but neither did HEVC before i added them
[11:05:14 CEST] <nevcairiel> so shrug
[11:06:15 CEST] <nevcairiel> those usually dont appear until someone is working on the first hwaccel
[11:07:01 CEST] <BtbN> I'll propably start with VAAPI (m)jpeg.
[11:08:15 CEST] <nevcairiel> jpeg has so many variations and color spaces, seems like an annoying task to figure out which actually work
[11:11:29 CEST] <atomnuker> speaking of jpeg, what made everyone scared to use arithmetic coding?
[11:11:48 CEST] <atomnuker> someone started throwing the book at companies who dare to use math?
[11:50:49 CEST] <cone-341> ffmpeg 03Rostislav Pehlivanov 07master:da64bd6a992c: aaccoder: tweak PNS implementation further
[12:01:43 CEST] <cone-341> ffmpeg 03Paul B Mahol 07master:af2476340069: avfilter/vf_lut: use AV_OPT_TYPE_BOOL for negate_alpha option
[12:01:44 CEST] <cone-341> ffmpeg 03Paul B Mahol 07master:33a68759c135: avcodec/libmp3lame: use AV_OPT_TYPE_BOOL for all options
[12:01:46 CEST] <cone-341> ffmpeg 03Paul B Mahol 07master:6603368ab41d: avcodec/huffyuvenc: use AV_OPT_TYPE_BOOL for non_deterministic option
[12:01:49 CEST] <cone-341> ffmpeg 03Paul B Mahol 07master:8bf2d3e46882: avcodec/wavpackenc: use AV_OPT_TYPE_BOOL for all options
[12:55:37 CEST] <durandal_170> michaelni: can lavfi change frame width/height on the fly?
[13:05:56 CEST] <ubitux> i remember seeing a recent commit with a list of filter exception where it's allowed to have outlink parameters mismatching frame ones
[13:06:46 CEST] <ubitux> 5d859e59809f38334592fc43f8ae70a23b5a9597
[13:14:16 CEST] <durandal_170> well i set frame width/height 
[13:14:58 CEST] <durandal_170> but the output still use old values
[13:25:35 CEST] <ubitux> durandal_170: it seems idet filter changes the link settings as well
[13:29:10 CEST] <BtbN> I'm not sure what to make of that nvenc mail on ffmpeg-devel. That's great i guess, but does it need some response to actualy get the patch?
[13:36:00 CEST] <durandal_170> ubitux: i think all of them expect that size changes outside, not by filter itself
[13:36:18 CEST] <nevcairiel> BtbN: yeah the mail was weird, i figured just to wait
[14:00:21 CEST] <michaelni> durandal_170, some filters contain code to handle w/h changes, some should "just work", some do not support it currently
[14:02:24 CEST] <michaelni> a flag should probably be added to flag filters which cant handle it
[14:02:41 CEST] <michaelni> and then reinit these filters on size changes or insert scale before them if w/h changes
[14:03:51 CEST] <durandal_170> michaelni: i just want crop to change frame size
[14:14:39 CEST] <cone-341> ffmpeg 03Ricardo Constantino 07master:2641eeeefe93: configure: add libsoxr to swresample's pkgconfig
[14:50:34 CEST] <cone-341> ffmpeg 03Hendrik Schreiber 07master:9d742d23d28c: lavc: Fix compilation with --disable-everything --enable-parser=mpeg4video.
[15:58:37 CEST] <atomnuker> turns out libfdk_aac uses the same TNS quantization method for the LPC coefficients as the one I wrote
[15:58:54 CEST] <atomnuker> even they knew not to trust the specifications too much
[15:59:41 CEST] <atomnuker> (libfaac uses the method described by the specifications and it's no wonder it isn't good at all)
[16:01:01 CEST] <atomnuker> although the fdk_aac folks weren't clever enough to know they could skip the entire schur recursion by storing the processed coefficients directly
[16:02:40 CEST] <JEEB> :)
[16:02:46 CEST] <iive> :)
[16:03:58 CEST] Action: Daemon404 cant wait for the day he can drop fdk
[16:05:47 CEST] <durandal_170> unused gamma_convert in libswscale
[16:10:18 CEST] <JEEB> Daemon404: indeed
[16:10:24 CEST] <JEEB> one less dependency biting the dust
[16:14:39 CEST] <RiCON> a listening test in HA with the new changes would be nice
[16:15:41 CEST] <atomnuker> no, not yet
[16:16:01 CEST] <atomnuker> those guys will tear the encoder to shreads with placebo
[16:23:51 CEST] <cone-341> ffmpeg 03Hendrik Schreiber 07release/2.8:c3021738fc90: lavc: Fix compilation with --disable-everything --enable-parser=mpeg4video. (cherry picked from commit 9d742d23d28c11749f90128aee0522270fd93a81)
[16:41:59 CEST] <cone-341> ffmpeg 03Ricardo Constantino 07release/2.8:aa46ae8848ef: configure: add libsoxr to swresample's pkgconfig
[16:45:56 CEST] <philipl> BtbN: neat.
[16:46:19 CEST] <BtbN> Currently trying to get this working.
[16:46:32 CEST] <philipl> nevcairiel: I have a change here with what I think are the vp9 hwaccel hooks. Obviously can't test them.
[16:46:53 CEST] <nevcairiel> thats why they usually only show up once someone has a hwaccel to work them with
[16:47:13 CEST] <nevcairiel> sometimes they need to go in a rather particular place due to oddness in the decoder or something
[16:48:01 CEST] <philipl> no doubt
[16:51:35 CEST] <philipl> BtbN: so the hybrid driver works on hardware back to haswell?
[16:51:45 CEST] <philipl> That appears to be what the readme says
[16:53:56 CEST] <BtbN> According to some mails, it doesn't.
[16:54:01 CEST] <philipl> hmm.
[16:54:09 CEST] <BtbN> But i will test that right now.
[17:26:46 CEST] <BtbN> philipl, it looks like the Haswell in my Laptop does indeed support both profiles the libva-hybrid-driver advertises
[17:28:44 CEST] <philipl> BtbN: How exciting.
[17:28:53 CEST] <philipl> I've got a haswell machine
[17:28:54 CEST] <BtbN> Had to fix their build system first
[17:28:58 CEST] <philipl> heh.
[17:29:08 CEST] <philipl> So this requires the latest libva I guess?
[17:29:18 CEST] <BtbN> >=1.6.0
[17:29:41 CEST] <BtbN> everything but git master doesn't know about VP9 though, so it just says "unknown profile"
[17:30:27 CEST] <philipl> Is the chain loading configuration documented somewhere?
[17:30:35 CEST] <BtbN> I'm not using that.
[17:30:43 CEST] <BtbN> I just set LIBVA_DRIVER_NAME=hybrid and called vainfo
[17:30:58 CEST] <philipl> So you only see the two profiles
[17:31:03 CEST] <BtbN> yes
[17:31:08 CEST] <philipl> Makes sense.
[17:31:12 CEST] <BtbN> this is strange
[17:31:24 CEST] <BtbN> On my Baytrail Nuc, it doesn't support VP8 encoding, only VP9 decoding.
[17:31:33 CEST] <BtbN> My Haswell laptop supports VP8 encoding.
[17:31:35 CEST] <philipl> maybe not enough shader power?
[17:31:47 CEST] <philipl> the baytrail gpu is pretty weak
[17:32:07 CEST] <philipl> I'm surprised it even supports decoding.
[17:32:16 CEST] <philipl> Do you really mean baytrail and not braswell?
[17:32:30 CEST] <philipl> the baytrail gpu is ivy bridge generation
[17:32:54 CEST] <BtbN> http://cgit.freedesktop.org/vaapi/intel-driver/commit/?id=2d42512bd6b7382c5effe21a5f9999742d98db88
[17:32:58 CEST] <BtbN> It's still changing how to enable it...
[17:33:18 CEST] <philipl> truly the bleeding edge.
[17:33:26 CEST] <BtbN> I'll try it now.
[17:38:00 CEST] <BtbN> 1.6.1 has been released though, with that flag in
[17:38:07 CEST] <BtbN> so i'd say it's kind of stable now
[17:38:31 CEST] <BtbN> yes, it just works.
[17:38:51 CEST] <BtbN> libva-intel-driver built with that option enabled just shows the VP9 support.
[17:41:01 CEST] <BtbN> https://gist.github.com/BtbN/0f55022fec3153ce63b8
[17:43:48 CEST] <BtbN> So aparently anyone with a Haswell CPU has a VP9 "hardware" decoder now.
[17:45:37 CEST] <rcombs> what kind of "hardware" are we talking
[17:45:49 CEST] <philipl> BtbN: how exciting.
[17:45:57 CEST] <BtbN> I have nothing to test this yet.
[17:46:04 CEST] <BtbN> They called it "highly experimental"
[17:46:59 CEST] <BtbN> And as the code that does the actual work looks like this: https://raw.githubusercontent.com/01org/intel-hybrid-driver/master/src/vp9hdec/intel_hybrid_vp9_kernel_g9.cpp
[17:47:11 CEST] <BtbN> I have absolutely no idea how "hardware" it is.
[17:47:14 CEST] <philipl> btbn: https://github.com/philipl/FFmpeg/commit/46fa7945d55b8edf03f3d6a3cd9959e4fcc52de6
[17:47:17 CEST] <philipl> for whatever that's worth.
[17:48:07 CEST] <BtbN> Does any hwaccel, except my hevc vaapi one, even use the per-frame priv buf?
[17:49:09 CEST] <philipl> BtbN: no idea. Strictly cargo-culting.
[17:49:25 CEST] <philipl> It seems like an hwaccel API requirement even if the backend doesn't use it
[17:49:49 CEST] <BtbN> it makes sense to have it, it was definitely usefull for hevc
[17:49:54 CEST] <philipl> I think vdpau stores some context info in it.
[19:00:53 CEST] <philipl> BtbN: I wonder what exciting nvenc optimizations nvidia have for us.
[19:01:36 CEST] <BtbN> some changed defaults aparently
[19:02:28 CEST] <philipl> I'm pleasantly surprised to see them re-engaging at all.
[20:03:19 CEST] <BtbN> "Picture original resolution. The value may not be multiple of 8." Is my english failing me, the authors english, or does this tell me the frame_width cannot be a multiple of 8?
[20:04:26 CEST] <philipl> That's what it sounds like
[20:04:34 CEST] <philipl> but surely it must be the exact opposite.
[20:05:39 CEST] <Daemon404> no
[20:05:44 CEST] <Daemon404> it could be interpreted differently
[20:05:56 CEST] <Daemon404> let me reword for you:
[20:06:07 CEST] <Daemon404> The value might not be a multiple of 8.
[20:06:12 CEST] <Daemon404> as in it is not guaranteed to be 8.
[20:06:18 CEST] <Daemon404> since it is the original picture res.
[20:06:22 CEST] <Daemon404> (and not coded)
[20:06:23 CEST] <BtbN> It's an input parameter for VP9 decoding with libva
[20:06:42 CEST] <Daemon404> well this is how i read it
[20:06:49 CEST] <Daemon404> it makes the most sense in context
[20:06:51 CEST] <BtbN> So i guess it means that it wants the actual frame size, and not rounded up to 8?
[20:07:00 CEST] <Daemon404> i guess so
[20:07:03 CEST] <Daemon404> whoever wrote that should be shot
[20:08:01 CEST] <BtbN> 59c2d708 (Wang, Ce 2014-04-02 05:40:01 +0000  63)      *  Picture original resolution. The value may not be multiple of 8.
[20:08:57 CEST] <Daemon404> engrish?
[20:13:58 CEST] <philipl> Ok. So just advice.
[20:15:00 CEST] <Daemon404> you guys seem to have recurring issues with nvidia's docs
[20:15:22 CEST] <BtbN> nvidia?
[20:15:25 CEST] <nevcairiel> but this is intel
[20:15:37 CEST] <nevcairiel> vdpau docs are much better than this =p
[20:15:50 CEST] <Daemon404> [19:15] <@Daemon404> you guys seem to have recurring issues with all docs related to any sort of hw accel.
[20:15:53 CEST] <Daemon404> fixed?
[20:16:03 CEST] <nevcairiel> nah, dxva docs are fine
[20:16:24 CEST] <BtbN> That VP9 stuff actualy looks quite ok.
[20:21:14 CEST] <philipl> nevcairiel: my nvidia beef is having the high444p decoder implemented but no 444 surface support.
[20:21:23 CEST] <philipl> It's the decoder that cannot output usable frames. yay!
[20:22:17 CEST] <Daemon404> nevcairiel, arent dxva docs written by ms?
[20:22:21 CEST] <Daemon404> and not the hw vendor
[20:23:08 CEST] <BtbN> Which is why they are good.
[20:23:12 CEST] <Daemon404> yes
[20:23:14 CEST] <Daemon404> thats my point
[20:26:07 CEST] <nevcairiel> yes they are
[20:26:12 CEST] <nevcairiel> but in cooperation with the vendors
[20:26:26 CEST] <nevcairiel> but for hevc they even had one guy that was deeply involved in the hevc spec itself
[20:27:35 CEST] <Daemon404> of course
[20:27:36 CEST] <Daemon404> they needed to
[20:27:43 CEST] <Daemon404> no humans can decipher the hevc spec
[20:27:49 CEST] <Daemon404> it's built for robots, and its creators
[20:27:53 CEST] <nevcairiel> apparently he works for MS anyway, so that helped
[20:30:42 CEST] <atomnuker> the hevc specs are 600+ pages
[20:30:53 CEST] <Daemon404> atomnuker, theyre written for robots
[20:31:03 CEST] <Daemon404> i used the f264 companion document
[20:31:08 CEST] <Daemon404> er f265
[20:31:17 CEST] <atomnuker> is there even a decoder which implements correctly 95% of the specs?
[20:31:28 CEST] <Daemon404> http://f265.org/f265/static/txt/h265_companion.html
[20:31:39 CEST] <Daemon404> see "A short rant about the specification "
[20:35:17 CEST] <atomnuker> it's probably just lack of communication between the parties who wrote them
[20:44:31 CEST] <atomnuker> hm f265 looks nice, too bad it doesn't appear active anymore
[20:45:07 CEST] <atomnuker> what motivation did the libx265 guys have to go C++ and just provide a C interface
[20:46:14 CEST] <Daemon404> outsourcing and visual studio
[20:46:20 CEST] <Daemon404> it's company-written code
[20:47:10 CEST] <atomnuker> enterprise quality software?
[20:59:08 CEST] <jamrial> at least they moved from intrisics to actual assembly
[21:00:11 CEST] <Daemon404> jamrial, poorly written assembly i hear (from you)
[21:00:30 CEST] <Daemon404> didnt you say the avx code was slower than a well written sse2 ste?
[21:00:31 CEST] <Daemon404> set*
[21:00:51 CEST] <jamrial> no, i don't remember saying that
[21:01:00 CEST] <Daemon404> someone in here did.
[21:01:24 CEST] <jamrial> i know they disabled some avx2 code a few weeks ago because it wasn't exactly faster than the sse2/4 version
[21:01:41 CEST] <jamrial> but i don't remember commenting about the quality of any of it
[21:01:57 CEST] <Daemon404> 20:46 <@kurosu> re avx2, hevc mc benefited around 5%, and I'd expect the same for correctly written transforms (hint: x265's is worse than an average sse2 version)
[21:02:00 CEST] <Daemon404> it was kurosu
[21:02:28 CEST] <smarter> BBB: hi! so re: vp9 ratecontrol issues, I haven't looked at it in a year and I only ever looked at 2-pass vbr, but back then I concluded that there were just too many damn parameters tuned with magic constants that all interact with each other in ways which are impossible to reason about
[21:02:44 CEST] <BBB> hahaha
[21:02:47 CEST] <smarter> quoting from the last pull request I did on the subject: "This makes me question the whole concept of active_worst_quality/active_best_quality, I guess the goal is to avoid wild variations in quality in the same clip, but other encoders do not seem to need this (Theora seems to limit the Q range between [0.8*prevQ, 1.2*prevQ], x264 determines Q values by measuring the complexity of the frames(frames with high motion get high Qs) and then uses
[21:02:47 CEST] <smarter>  a gaussian blur)." https://chromium-review.googlesource.com/#/c/69507/
[21:02:48 CEST] <BBB> ok thats what I thought
[21:02:56 CEST] <Daemon404> they probably inherited it from on2
[21:02:58 CEST] <Daemon404> i am guessing?
[21:03:14 CEST] <BBB> of course they did
[21:03:17 CEST] <smarter> it's partially inherited from vp8, which probably inherited it from older codebases
[21:03:25 CEST] <BBB> but I dont udnerstand the issue
[21:03:38 CEST] <BBB> you match a crf (quality) to rate graph using a standard regression
[21:03:50 CEST] <Daemon404> smarter, the x264 rc you described is slightly outdated btw
[21:03:51 CEST] <BBB> quants in hedge funds do nothing else but regressions
[21:03:59 CEST] <smarter> Daemon404: yeah I described the simplest one
[21:04:00 CEST] <BBB> python can do regressions for me
[21:04:14 CEST] <BBB> google has tons of smart people working in its ads department that nderstand this
[21:04:18 CEST] <BBB> how can they not solve this already?
[21:04:28 CEST] <smarter> the particular issue that frustrated me is that there is a magic formula used at the end of the first pass to choose the minimum Q, and during the second pass you can never go below this Q
[21:04:39 CEST] <Daemon404> wut
[21:04:43 CEST] <smarter> so if that minimum Q is wrong, you end up having all your frames at the same Q
[21:04:50 CEST] <BBB> hahaha
[21:04:55 CEST] <BBB> ok thats not funny
[21:04:55 CEST] <Daemon404> the entire concept seems flawed
[21:04:56 CEST] Action: BBB cries
[21:05:12 CEST] <smarter> I tried removing it, but then everything explodes, and it seemed easier to just redo the whole thing from scratch
[21:05:28 CEST] <Daemon404> btw fun note: the x264 RC smarter described was adapted from michaelni's ffmpeg RC
[21:05:38 CEST] <Daemon404> (mbtree was x264's new one)
[21:05:38 CEST] <smarter> yeah, I ended up doing some archeology on that one :)
[21:06:06 CEST] <smarter> well, ffmpeg had some crazy thing where you could give your own formula for the ratecontrol
[21:06:19 CEST] <smarter> with a parser of expressions and everything
[21:06:36 CEST] <Daemon404> qcomp was michaels thing though
[21:06:38 CEST] <Daemon404> i remember that much
[21:07:07 CEST] <Daemon404> anf x264 had this eval thing too.
[21:07:21 CEST] <Daemon404> look at the user SEI of older x264 encoders and teh formula use is coded into it
[21:07:25 CEST] <Daemon404> used*
[21:08:56 CEST] <JEEB> hmm, JCT-VC did some weird stuff with their yadif usage
[21:09:00 CEST] <JEEB> "To better facilitate deinterlacing, and to avoid possible chroma phase difference issues, an interlace-aware chroma format conversion from 4:2:0 to 4:2:2 was applied prior to invoking the ffmpeg deinterlacing process."
[21:09:27 CEST] <JEEB> from http://phenix.int-evry.fr/jct/doc_end_user/current_document.php?id=10212
[21:11:50 CEST] <BBB> huh
[21:12:52 CEST] <peloverde> smarter: It's great when activebestq is off and the codec misses target rate by like 8x and no number of passes in the recode loop help
[21:15:32 CEST] <Daemon404> peloverde, how high up is "redo RC" on the vpx todo?
[21:15:37 CEST] <Daemon404> i hope pretty high.
[21:16:06 CEST] <peloverde> lulz, afaik it isn't even on the list
[21:16:34 CEST] <Daemon404> -_-
[21:16:47 CEST] <BBB> Daemon404: you need more constructive feedback then fix it to work on it
[21:16:51 CEST] <BBB> like, imagine I work on it
[21:16:54 CEST] <BBB> what do you want me to fix?
[21:16:57 CEST] <BBB> dont say it"
[21:17:10 CEST] <Daemon404> BBB, you should still have it somewhere on goals, to have usable ratecontrol
[21:17:16 CEST] <Daemon404> it's a goal, even if it is vague
[21:17:19 CEST] <BBB> what is usable"
[21:17:21 CEST] <peloverde> on screen content I get concave rd curves
[21:17:35 CEST] <peloverde> that seems not good
[21:17:39 CEST] <Daemon404> BBB, "doesnt understood or overshoot by massive amounts"
[21:17:49 CEST] <Daemon404> peloverde, lol
[21:18:40 CEST] <Daemon404> peloverde, thierry mentioned they sort of do their 'own' RC for encodes
[21:18:50 CEST] <Daemon404> since they do gop distributed encoding
[21:18:54 CEST] <Daemon404> per-gop RC or something?
[21:19:46 CEST] <Daemon404> this is why i dont think google understands adoption.
[21:19:54 CEST] <Daemon404> theyre pushing for adoption, but... only for youtube videos?
[21:20:01 CEST] <Daemon404> fuck content creators, cater to youtube?
[21:20:02 CEST] <JEEB> yes,  you only need to have the decoder
[21:20:16 CEST] <JEEB> no need for the encoder, gaff off you plebs
[21:20:58 CEST] <JEEB> meanwhile @ JCT-VC people have noticed that BT.2020 chroma positioning differs from the MPEG-2/AVC one http://up-cat.net/p/e7cbf673
[21:21:15 CEST] <nevcairiel> it does? how annoying
[21:21:38 CEST] <Daemon404> anyway, i still contend when vp9 appears in more hw and browser (ie, haswell etc), anyone but youtube will struggle
[21:21:46 CEST] <Daemon404> with ratecontrol and good quality/speed tradeoffs
[21:21:54 CEST] <Daemon404> avg joe content host isnt going to implement GOP distriution.
[21:22:23 CEST] <Daemon404> end rant.
[21:22:34 CEST] Action: Daemon404 sips some tea.
[21:25:03 CEST] <smarter> BBB: "fix it" for me would mean "write the simplest rc possible, maybe based on what Theora does"
[21:25:13 CEST] <BBB> uhm
[21:25:16 CEST] <BBB> wait
[21:25:16 CEST] <Daemon404> smarter, theroa's rc was not good
[21:25:19 CEST] <BBB> did you say theora?
[21:25:25 CEST] <BBB> theora is the most braindead thing in the world
[21:25:35 CEST] <peloverde> I don't think anyone here is interested in Joe Random putting a single bitrate of a single video on a static html page in the <video> tag without MSE. I know I'm not. 
[21:25:37 CEST] <smarter> I don't actually know how good or bad or their rc is, I just assumed it's OK
[21:25:48 CEST] <BBB> its not
[21:25:56 CEST] <Daemon404> peloverde, you cant even provide reasonable MSE streaming without a set of reasonable biytrates to use
[21:26:01 CEST] <BtbN> philipl, the VP9 hwaccel patch is at least missing the pix_fmt stuff, which signals an application support for hwaccel. I'll look into it tomorrow.
[21:26:05 CEST] <Daemon404> that doesnt work if you cant actually get such a set because it always under/overshoots
[21:26:19 CEST] <smarter> I think derf said that daala rc would probably be based on theora's, so I assumed it worked okay
[21:26:19 CEST] <Daemon404> unless you encode gops separately, and keep an eye on them
[21:26:25 CEST] <smarter> maybe it got improved in the never-released theora 1.2
[21:26:38 CEST] <BBB> smarter: I know you hang out in the xiphy irc channels, but the way you often hear googles vpx codecs are kind of pred up into the sky, xiph is very good at that also
[21:26:55 CEST] <Daemon404> smarter, i never once got theora to hit near a bitrate i wanted
[21:27:01 CEST] <Daemon404> but this was like 10 years ago.
[21:27:01 CEST] <Daemon404> so.
[21:27:07 CEST] <BBB> theora is not that good. nothing about theora is good, except that its free
[21:27:16 CEST] <Daemon404> BBB, so its like vp8
[21:27:17 CEST] Action: Daemon404 runs
[21:27:20 CEST] <BBB> ...
[21:27:36 CEST] <BBB> :D
[21:27:41 CEST] <Daemon404> vp8 had no advantage when ti was release
[21:27:43 CEST] <Daemon404> unlike vp9
[21:27:48 CEST] <BBB> I know
[21:27:58 CEST] <BBB> I still remember the i/o talk
[21:28:08 CEST] <BBB> every time I look back at that, Im like woa, how did they approve that talk"
[21:28:14 CEST] <BBB> I think the graphs are real
[21:28:15 CEST] <BBB> but ...
[21:28:18 CEST] <BBB> theyre insane
[21:28:25 CEST] <BBB> (did you guys ever watch that?)
[21:28:30 CEST] <smarter> I did, thought it was good
[21:28:30 CEST] <Daemon404> i can see vp9 catching on outside of youtube, with IE adoption, and stuff
[21:28:36 CEST] <Daemon404> but it will be hard given the encoder.
[21:28:38 CEST] <Daemon404> that is my prediction.
[21:28:47 CEST] <BBB> iirc, they do 1-2 comparisons against h264 _baseline_ (not main) profile
[21:28:58 CEST] <BBB> and the bitrate they show ends up leading to psnr values in the range of (wait for it)
[21:29:00 CEST] <Daemon404> BBB, oh *that* talk.
[21:29:02 CEST] <BBB> 25-26
[21:29:04 CEST] <BBB> and Im like
[21:29:18 CEST] <BBB> WHO ON EARTH APPROVED THAT TALK
[21:29:25 CEST] <BBB> Im only guessing that its real
[21:29:25 CEST] <Daemon404> BBB, this was hot of on2
[21:29:26 CEST] <BBB> but...
[21:29:28 CEST] <BBB> WHO CARES
[21:29:32 CEST] <Daemon404> theyre literally famous for info/talks like that
[21:29:35 CEST] <smarter> it inspired me to make a split view video comparison webpage: http://exp.martres.me/splitview/ (unfortunately it doesn't have any sample loaded by default because I lost them and was too lazy to rerun libvpx a bunch of times :))
[21:29:48 CEST] <BBB> WHO CARES THAT YOURE @2% BETTER THAN H264 BASELINE AT A PSNR VALUE RANGE OF 25-26 </rage>
[21:29:57 CEST] Action: Daemon404 gives BBB a sedative
[21:30:00 CEST] <BBB> thank you
[21:30:20 CEST] <BBB> splitview is aweosme yes
[21:30:26 CEST] <Daemon404> btw side note: x265 successfully adopetd x264's ratecontrol
[21:30:32 CEST] <Daemon404> and it works
[21:30:33 CEST] <BBB> oh thats nice
[21:30:45 CEST] <smarter> frankenstein265
[21:30:50 CEST] <Daemon404> :D
[21:31:13 CEST] <BBB> now add the vpx patent license in it
[21:31:31 CEST] <JEEB> yeah, I encoded VBV with x265 some time ago and it didn't completely piss its pants
[21:31:36 CEST] <JEEB> which was more than I expected
[21:31:49 CEST] <Daemon404> JEEB, curves match x264s
[21:31:58 CEST] <smarter> (there' some plans to add something like splitview to Mozilla's codec metrics comparison tools, which should be really useful: https://arewecompressedyet.com/ )
[21:33:09 CEST] <JEEB> also it seems like JCT-VC members are starting to see x265
[21:33:15 CEST] <Daemon404> smarter, you could attempt to use the tool x264 used to tune its psy
[21:33:21 CEST] <smarter> Daemon404: what's that?
[21:33:28 CEST] <Daemon404> posting builds on doom9, and letting hoards of monkies test and compare
[21:33:29 CEST] <Daemon404> <_<
[21:33:40 CEST] <JEEB> they added command lines for x265 for "High Dynamic Range with HEVC Main10"
[21:33:48 CEST] <JEEB> "HDR-10"
[21:34:00 CEST] <Daemon404> JEEB, for all those HDR monitors out there?
[21:34:03 CEST] <Daemon404> and tvs
[21:34:21 CEST] <JEEB> hey, they have a list of six whole TVs/monitors from six vendors that seemed to have worked
[21:34:27 CEST] <JEEB> "The following monitors have been identified as supporting HDR-10 through HMDI 2.0a and/or playback of HEVC Main10 files (usually in a .mp4 file container)"
[21:35:13 CEST] <Daemon404> interesting.
[21:36:12 CEST] <Daemon404> anyway, i look forward to bbb's vdd talk and resulting discussion
[21:36:16 CEST] <Daemon404> which i am sure will be entirely civil
[21:36:27 CEST] <Daemon404> since we are a community of responsible adults.
[21:36:59 CEST] <BBB> muhaha
[21:37:08 CEST] <BBB> followed by the libav vs ffmpeg friendship meetinh
[21:37:30 CEST] <BBB> BFF15 days
[21:37:36 CEST] <Daemon404> the only part of that last year that didnt make me want to remove my own face was when thierry yelled at everyone.
[21:37:42 CEST] <Daemon404> that meeting, i mean.
[21:38:07 CEST] <smarter> BBB: what's your talk going to be about?
[21:38:27 CEST] <Daemon404> vp9
[21:38:42 CEST] <BBB> thierry is awesome
[21:38:51 CEST] <smarter> +1
[21:39:00 CEST] <BBB> I already gave my proxy vote for the irc meeting to j-b, but if I hadnt, Id give it to thierry
[21:39:22 CEST] <peloverde> Oh you mean his whole smug--I'm above it all because I'm not involved at all and if you don't make nice I'll stop using all the free stuff you give me for free--speech
[21:40:02 CEST] <peloverde> People already knew it was broken, and he didn't offer any concrete suggestions
[21:40:16 CEST] <BBB> thierry is right about one thing: free or not, we need to get our act together, because if we dont, were friendster and myspace, waiting for facebook to come along
[21:40:21 CEST] <Daemon404> that is true enough, peloverde 
[21:40:31 CEST] <Daemon404> but it made the pain in my ears stop for a while.
[21:40:47 CEST] <BBB> were lucky that diego and mru are gone and michaelni is no longer insisting hes the boss
[21:41:17 CEST] <Daemon404> we definitely no longer have childish fights on mailing lists, ever.
[21:41:26 CEST] <BBB> ...
[21:42:03 CEST] <Daemon404> BBB, i did my time trying to fix the community in the past, was nothing but stress and being shat on
[21:42:07 CEST] <Daemon404> so now i sit in the peanut gallery
[21:42:08 CEST] <Daemon404> and laugh.
[21:42:11 CEST] <Daemon404> that is all.
[21:42:18 CEST] <Daemon404> it's better for my health.
[21:42:53 CEST] <peloverde> BBB: I guess I'd say "so?" Something that seems good enough to supplant this mess seems like a good thing. 
[21:43:03 CEST] <BBB> peloverde: I agree
[21:43:15 CEST] <BBB> peloverde: but some of us may see a project we love dearly go to shit as a result
[21:43:20 CEST] <BBB> and that wasnt necessary
[21:43:41 CEST] <BBB> Daemon404: if you want good health, move to new york and eat sushi once a week and spend nights in speakeasies
[21:43:50 CEST] <BBB> nakazawa ftw
[21:43:58 CEST] <Daemon404> BBB, i used to live 1/2 a block away from a real speakeasy in chelsea
[21:44:07 CEST] <Daemon404> it was a coffee shop that had a bar hidden in its basement
[21:44:10 CEST] <Daemon404> you had to know aobut it to enter
[21:44:16 CEST] <BBB> theres tons of those
[21:44:21 CEST] <BBB> I know a handful maybe
[21:44:38 CEST] <Daemon404> i will be in new york in october
[21:44:38 CEST] <BBB> love em, because theyre quiet and theres no tvs
[21:44:41 CEST] <Daemon404> ill get sushi then
[21:45:02 CEST] <BBB> nakazawa requires a 1-month-before reservation
[21:45:04 CEST] <BBB> just so you know
[21:45:20 CEST] <Daemon404> standard new york
[21:45:20 CEST] <BBB> its worth it
[21:45:42 CEST] <Daemon404> i bet the prices arent bad either.
[21:45:47 CEST] <Daemon404> you know it's bad when i think enw york prices are cheap
[21:45:51 CEST] <Daemon404> compared to the UK
[21:46:00 CEST] <BBB> nakazawa is not cheap
[21:46:09 CEST] <BBB> but most places are affordable
[21:46:14 CEST] <Daemon404> i doubt it's nice-London-restaurant expensive
[21:46:17 CEST] <BBB> what was the speakeasy near chelsea?
[21:46:24 CEST] <BBB> maybe I should try it
[21:46:34 CEST] <Daemon404> it's a few shops to teh left of the gotham pizza in chelsea
[21:46:40 CEST] <Daemon404> on 9/19th
[21:47:33 CEST] <Daemon404> peloverde, btw i forgot to mention: some guy from brightcove i met at a conference in London invited me to vidtechcon as well
[21:47:44 CEST] <Daemon404> he said he knows you
[21:48:15 CEST] <BBB> salinas, bathtub gin, omai, bocca di bacco, tipsy parson?
[21:48:19 CEST] <peloverde> Daemon404: Phil Cluff?
[21:48:20 CEST] <Daemon404> Phil Cluff
[21:48:21 CEST] <Daemon404> yes
[21:48:35 CEST] <Daemon404> BBB, i cant remember
[21:48:41 CEST] <peloverde> yeah, he's part of my best coast video meetup group
[21:48:42 CEST] <BBB> bathtub gin probably
[21:48:46 CEST] <BBB> its the only speakeasy between them
[21:48:50 CEST] <BBB> and it says its hidden
[21:48:55 CEST] <BBB> ok Ill put that on my list
[21:49:00 CEST] <Daemon404> peloverde, he was at a Golang conference in London
[21:49:02 CEST] <Daemon404> kinda random.
[21:49:22 CEST] <Daemon404> BBB, i think that was it
[21:49:36 CEST] <BBB> oh right vidtechcon
[21:49:40 CEST] <BBB> I tried emailing them
[21:49:44 CEST] <BBB> but their email didnt work
[21:49:47 CEST] <BBB> did that ever get fixed?
[21:50:05 CEST] <peloverde> yeah, it was all messed up, they fixed it eventually. It's their first year so there are some bumps
[21:50:15 CEST] <Daemon404> oh they have a real site now!
[21:50:19 CEST] <peloverde> It's called "Demuxed" now
[21:50:21 CEST] <Daemon404> it use to be a single page saying email us
[21:51:23 CEST] <BBB> yeah and then you email them and it doesnt work
[21:51:28 CEST] <peloverde> next year will hopefully go smoother
[21:51:34 CEST] <BBB> thats like, really professional, only engineers could set that up ;)
[21:51:44 CEST] <Daemon404> BBB, maybe well grab food again when im in NYC for october. though my spouse is comign for the 2nd half of the two weeks.
[21:51:57 CEST] <BBB> sgtm
[21:52:01 CEST] <Daemon404> o/
[21:52:39 CEST] <BBB> I always have second thoughts about that smiley
[21:52:57 CEST] <Daemon404> youre not even german
[21:53:06 CEST] <BBB> close enough
[21:53:18 CEST] <BBB> Im almsot american though
[21:53:36 CEST] <Daemon404> do you like velveeta yet?
[21:53:58 CEST] <BBB> Im not suburban
[21:54:07 CEST] <BBB> I dont even have a car
[21:55:47 CEST] <Daemon404> http://5secondfilms.com/watch/an_american_in_new_york <--
[21:56:01 CEST] <cone-341> ffmpeg 03Hendrik Schreiber 07n2.9-dev:HEAD: lavc: Fix compilation with --disable-everything --enable-parser=mpeg4video.
[22:02:57 CEST] <durandal_170> michaelni: so does filter can change frame dimensions?
[22:04:52 CEST] <BBB> Im still thinking one day Im going to remove all these overflow protections from the vp9 simd and just use bitexact flags everywhere
[22:05:02 CEST] <BBB> Im not convinced they can occur on real input
[22:05:08 CEST] <BBB> but I have to prove it :(
[22:08:39 CEST] <durandal_170> how much they hurt?
[22:09:25 CEST] <BBB> not too much
[22:09:39 CEST] <BBB> but every cycle counts
[22:11:31 CEST] <michaelni> durandal_170, it depends on what filter comes after it, not all filters can handle it
[22:12:25 CEST] <durandal_170> no filter comes after it
[22:12:40 CEST] <durandal_170> Just ffmpeg/ffplay
[22:12:58 CEST] <BBB> durandal_170: works for me with -reinit_filter 0
[22:13:24 CEST] <BBB> durandal_170: -reinit_filter 0 -i file -f image2 file%d.yuv gives me resized frames for SVC vp9 content
[22:13:28 CEST] <michaelni> if no filter afterwards then it should e ok
[22:13:33 CEST] <BBB> (resizes meaning no swscale was ever invoked)
[22:15:50 CEST] <durandal_170> michaelni: croping leaves uninitialized data because size of window remain unchanged
[22:50:52 CEST] <BBB> so, Im gonna assume nobody cares about the vp9 patches right? (so I can just push them)
[22:51:38 CEST] <iive> if nobody commented on the list for 2 days...
[22:51:57 CEST] <BBB> I hate waiting for 2 days for something nobody is likely to care about :-p
[22:52:05 CEST] <BBB> or understand
[22:52:24 CEST] <BBB> the patch is basically libvpx does something weird - chagne ffvp9 to match libvpx behaviour"
[22:52:27 CEST] <BBB> all of em
[22:54:19 CEST] <peloverde> There was some annoying stuff where I had to widen something to match an argon stream that I don't think a reasonable encoder could make
[22:54:50 CEST] <iive> BBB: did you work with somebody else on vp9? ubitux ?
[22:55:06 CEST] <iive> BBB: you can always ask michaelni for review.
[22:55:19 CEST] <kierank> the argon streams are interesting
[22:55:37 CEST] <BBB> peloverde: iwht
[22:55:58 CEST] <BBB> peloverde: I use AV_CODEC_FLAG_BITEXACT for that, the residual was nonsensical (-20k or so)
[22:56:22 CEST] <iive> BBB: of course you can always just push them, then listen to people blaming you for been benevolent dictator ;)
[22:56:36 CEST] <BBB> but I changed some idcts and Im considering reverting these and use bitexact flag there also, if I can prove to myself its not possible to get such coefs from a real ftx
[22:56:46 CEST] <BBB> iive: Im not benevolent, just a dictator
[22:57:30 CEST] <iive> not yet :D
[22:57:44 CEST] <Daemon404> maybe that is why BBB does not like o/
[23:03:26 CEST] <durandal_170>  /o\
[23:38:13 CEST] <ubitux> someone should poke luca with b89ce54e
[23:38:27 CEST] <ubitux> i feel like he's adding a hack just for one filter (scale)
[23:38:33 CEST] <ubitux> instead of doing it properly&
[23:44:08 CEST] <BBB> Im with daemon404, popcorn all the way
[23:44:18 CEST] <BBB> Im not poking anyone over there
[23:45:58 CEST] <ubitux> well, problem is for the one who is going to merge
[23:46:36 CEST] <ubitux> nevcairiel: since you're concerned about that, you probably want to skip merging "avfilter: Support both syntaxes for the scale filter" if it gets applied
[23:46:54 CEST] <Daemon404> yes its very ugly
[23:47:00 CEST] <ubitux> in its current state it's easy to ignore
[23:47:15 CEST] <ubitux> it's likely that if you raise b89ce54e, they are going to NIH it and make the merge more complex
[23:47:29 CEST] <ubitux> see what risks you are willing to take :p
[00:00:00 CEST] --- Thu Sep 10 2015