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

[burek]

[00:37:25 CET] <kierank> is there any way to turn off inlining in ffmpeg
[00:42:19 CET] <rcombs> ubitux: there are multiple problems with 3e86ead3
[00:42:41 CET] <rcombs> ubitux: one being that your `while (i < FF_ARRAY_ELEMS(section->fields))` never increments i, so it loops forever
[00:44:03 CET] <rcombs> ubitux: fortunately it never actually gets called, because its use is in an `else if()` after `if (section->format_header && !order)`, so in the no-format-header case, ass_split_section takes the previous branch and never makes it to the call
[00:44:15 CET] <rcombs> I fixed both of those problems
[01:14:56 CET] <jamrial> kierank: add __attribute__((noinline)) to the function in question
[01:17:40 CET] <J_Darnley> I think there's an av_noinline alias for that
[01:19:20 CET] <jamrial> yeah, you're right
[01:51:28 CET] <cone-718> ffmpeg 03Andreas Cadhalpun 07master:7a4652dd5da0: aaccoder: prevent crash of anmr coder
[02:18:21 CET] <J_Darnley> Daemon404, wm4, BBB, ubitux: I think you lot said earlier that you were using the API and AVOption.  Can I ask where?  I want to see what the use looks like from the outside.
[02:26:13 CET] <wm4> J_Darnley: well, there are 44 av_opt calls in mpv, most are in the libsw/avresample wrapper, and a libswscale wrapper, interestingly
[02:27:14 CET] <J_Darnley> Thanks, I'll have a look.
[02:27:56 CET] <J_Darnley> mpv.io right?
[02:44:53 CET] <Plorkyeran> iirc avresample/swscale/swresample are the only thing that ffms2 uses av_opt for too
[02:57:23 CET] <cone-718> ffmpeg 03Claudio Freire 07master:293c170f5941: AAC encoder: ANMR, avoid empty search ranges
[03:01:24 CET] <rcombs> do we actually need an XML parser
[03:01:47 CET] <rcombs> that seems like a lot of work and a lot of complexity when there are at least 2 good libs for that
[03:01:48 CET] <J_Darnley> Someone must do subs in that format!
[03:02:02 CET] <J_Darnley> Or for some streaming format.
[03:04:36 CET] <atomnuker> don't joke about that stuff, there are ways to organize data and then there's xml and json
[03:10:33 CET] <J_Darnley> Is it just javascript devs that think json is good (or decent)?
[03:27:47 CET] <wm4> json is actually easy to parse
[03:27:54 CET] <wm4> while xml is very hard
[03:38:04 CET] <rcombs> hardest thing about parsing JSON is string escape handling, which is not very hard
[04:48:53 CET] <cone-718> ffmpeg 03Simon Thelen 07master:5b6c0fdb4316: ffmpeg: When streamcopying, only add the input seek position when copying timestamps.
[04:48:54 CET] <cone-718> ffmpeg 03Neil Birkbeck 07master:a16243a4aa5f: libavformat/mov.c: allow QuickTime metadata to come after traks
[12:22:27 CET] <cone-055> ffmpeg 03Luca Barbato 07master:9f57f134c197: configure: ObjC support
[12:22:28 CET] <cone-055> ffmpeg 03Hendrik Leppkes 07master:3b0f63e110d4: Merge commit '9f57f134c19773d54269b6cb9ee455ff87c2e9e1'
[12:33:04 CET] <atomnuker> "configure: ObjC support" << why?
[12:33:45 CET] <nevcairiel> mac things, apparently
[12:34:05 CET] <nevcairiel> (fwiw, we already have parts of that support before)
[12:34:11 CET] <nevcairiel> s/have/had/
[12:36:20 CET] <ubitux> atomnuker: avfoundation
[12:36:31 CET] <ubitux> we already have objc support since a while here
[12:36:43 CET] <ubitux> ./libavdevice/qtkit.m
[12:36:45 CET] <ubitux> ./libavdevice/avfoundation.m
[12:36:54 CET] <nevcairiel> (that patch was totally broken, i had to fix quite a few things in it)
[12:37:15 CET] <nevcairiel> that macbook actually came in handy for once
[12:38:27 CET] <cone-055> ffmpeg 03Clément BSsch 07master:560d1e7b4992: avfilter/codecview: add QP support
[12:38:28 CET] <cone-055> ffmpeg 03Clément BSsch 07master:3f46e7bad57c: avfilter/codecview: reindent after previous commit
[13:40:29 CET] <cone-055> ffmpeg 03Michael Niedermayer 07master:7ed47e97297f: avformat/smacker: fix integer overflow with pts_inc
[13:40:30 CET] <cone-055> ffmpeg 03Michael Niedermayer 07master:0c56f8303e67: avcodec/wmaprodec: Fix overflow of cutoff
[13:40:31 CET] <cone-055> ffmpeg 03Michael Niedermayer 07master:2de8bfd2ef06: avcodec/pcm: Fix overflow in bitrate computation
[13:40:32 CET] <cone-055> ffmpeg 03Michael Niedermayer 07master:15d14ce47cb3: avcodec/utils: Fix overflow in get_bit_rates computations
[15:09:57 CET] <thresh> hello!
[15:10:08 CET] <thresh> who's currently in charge with ffmpeg.org website?
[15:13:28 CET] <kierank> ubitux I believe
[15:15:42 CET] <BtbN> i think you can sent patches against ffmpeg-web to the ML if you want to change something
[15:17:55 CET] <ubitux> wat no! :(
[15:18:24 CET] <ubitux> (no about maintainership)
[15:21:19 CET] <rcombs> nevcairiel: sent that TrueHD-in-MPEGTS patch; apparently the sample plays in WMP with LAV Filters installed
[15:21:41 CET] <rcombs> not sure if I should blame WMP or you
[15:22:55 CET] <rcombs> ubitux: saw my reply re: ass_split?
[15:23:27 CET] <ubitux> rcombs: no
[15:23:34 CET] <ubitux> doesn't appear in the ml unless i missed sth
[15:24:10 CET] <ubitux> on on irc my bad
[15:24:17 CET] <ubitux> let me backlog, i missed a few messages
[15:24:21 CET] <rcombs> yeah
[15:25:12 CET] <thresh> well I want to minimize the number of git:// users on git.videolan.org, so can someone please change the clone URI on http://ffmpeg.org/download.html#get-sources to http://source.ffmpeg.org/git/ffmpeg.git ?
[15:25:43 CET] <kierank> thresh: what's the difference?
[15:25:46 CET] Action: kierank uses git.videolan
[15:25:47 CET] <ubitux> rcombs: o damn, didn't realized that infinite loop; curious no static analyzer spotted it
[15:25:59 CET] <thresh> kierank: http:// is awesomer than git://
[15:26:08 CET] <rcombs> ubitux: maybe because it's never hit
[15:26:08 CET] <thresh> all the cool kids use it, just look at github
[15:26:20 CET] <kierank> pfft
[15:26:31 CET] <rcombs> thresh: why http instead of https?
[15:27:00 CET] <thresh> rcombs: to hammer the server less, for no real reason?
[15:27:22 CET] <ubitux> rcombs: it's curious bc i'm pretty sure i tested it against the problematic sample... but well alright, sorry
[15:28:13 CET] <rcombs> ubitux: np as long as it gets fixed
[15:28:24 CET] <ubitux> fate test welcome btw :(
[15:28:49 CET] <thresh> kierank: git:// is a binary proto, which is hard to mangle (which I need to migrate stuff from git.v.o to gitlab)
[15:29:09 CET] <kierank> I see
[15:29:24 CET] <rcombs> ubitux: yeah, I'll put one together
[15:29:35 CET] <ubitux> J_Darnley: i used the AVOption in a project recently; it was really handy to provide a way of doing mylib_set_option(ctx, "foo", <bar>), with the mylib_set_option() last parem being vaarg doing introspection on type of the option to actually read the arg
[15:29:48 CET] <ubitux> J_Darnley: rest was common usage
[15:30:33 CET] <ubitux> it was actually really handy to set defaults value, range checks, and provide a stable option API 
[15:30:56 CET] <ubitux> like, not exposing the fields of the context and keeping it opaque, while shuffling everything in the background
[15:41:42 CET] <cone-055> ffmpeg 03Michael Niedermayer 07master:66e05f6ff5e5: avcodec/wmaprodec: Check bits per sample to be within the range not causing integer overflows
[15:48:29 CET] <nevcairiel> rcombs: wmp certainly doesnt support truehd i dont think, and not sure how I would modify truehd probing .. but maybe i forgot
[15:48:43 CET] <rcombs> nevcairiel: it was a passthrough thing
[15:48:54 CET] <rcombs> according to the user who provided the file
[15:49:42 CET] <nevcairiel> the patch is trivial, so its probably fine
[16:14:41 CET] <BtbN> Did they guy on ffmpeg-devel just post a pastebin link wrapped in a facebook tracking thing?!
[16:15:00 CET] <BtbN> Also, on the wrong ml.
[16:15:45 CET] <cone-055> ffmpeg 03Paul B Mahol 07master:a525b844d9e4: avfilter/af_stereotools: check s->length size
[16:15:46 CET] <fritsch> BtbN: did you see the vaapi hevc-10bit/ vp9 code landing?
[16:15:52 CET] <BtbN> yes
[16:16:08 CET] <fritsch> did you understand their handling of p1010?
[16:16:09 CET] <BtbN> waiting for the vp9 hwaccel hooks to be merged, then going to implement both
[16:16:17 CET] <nevcairiel> people post things like "my problem" and they really expect people to help?
[16:16:17 CET] <BtbN> Haven't looked too much at it yet
[16:16:21 CET] <wm4> hm, vaapi 10 bit, I wonder how surfaces are handled here
[16:16:31 CET] <fritsch> wm4: ^^ that was my question
[16:16:40 CET] <fritsch> they are converted internally to rgba32
[16:16:42 CET] <wm4> last time I checked, surfaces magically changed their format depending on random conditions
[16:16:47 CET] <wm4> wat
[16:16:47 CET] <fritsch> but I don't understand the code :-)
[16:16:50 CET] <wm4> that's fucked up
[16:16:55 CET] <fritsch> http://lists.freedesktop.org/archives/libva/2015-December/003759.html
[16:16:56 CET] <fritsch> here
[16:17:14 CET] <fritsch> see - they need support for vaPutsurface
[16:17:55 CET] <wm4> the patch linked just adds 10 bit support to vaPutSurface?
[16:17:59 CET] <fritsch> yes
[16:18:23 CET] <fritsch> "Currently it converts P010 to RBGA32"
[16:18:25 CET] <fritsch> he writes
[16:18:39 CET] <fritsch> with a bit of phantasie I even see the 4 8bit planes
[16:18:43 CET] <nevcairiel> asians, so verbose comments
[16:19:06 CET] <wm4> oh I see what you mean
[16:19:09 CET] <wm4> it looks very fucked
[16:19:19 CET] <fritsch> http://lists.freedesktop.org/archives/libva/2015-December/003775.html <- emil has the same question
[16:19:36 CET] <fritsch> we need that cause of vaPutSurface
[16:19:46 CET] <fritsch> but i'd like to understand how it's done
[16:21:18 CET] <fritsch> http://lists.freedesktop.org/archives/libva/2015-December/003766.html
[16:21:20 CET] <fritsch> here the decoder
[16:21:54 CET] <BtbN> #define I_P010  2, 2, 2, {I965_16BITS, I965_8BITS}, 3, { {PLANE_0, OFFSET_0}, {PLANE_1, OFFSET_0}, {PLANE_1, OFFSET_16} }
[16:24:13 CET] Action: wm4 wonders what hw supports this
[16:24:18 CET] <fritsch> Brexton
[16:24:20 CET] <fritsch> the new atom
[16:24:34 CET] <nevcairiel> Broxton*
[16:24:36 CET] <fritsch> broxton
[16:24:37 CET] <fritsch> yes
[16:24:39 CET] <BtbN> no backwards compat?
[16:24:50 CET] <fritsch> http://lists.freedesktop.org/archives/libva/2015-December/003756.html
[16:24:51 CET] <fritsch> no
[16:24:55 CET] <fritsch> gen9 only
[16:24:57 CET] <fritsch> it seems
[16:25:07 CET] <nevcairiel> gen9 is skylake as well, fwiw
[16:25:12 CET] <nevcairiel> but decoder features may not be the same
[16:25:16 CET] <fritsch> jep
[16:25:27 CET] <wm4> seems like I bought skylake really for nothing
[16:25:28 CET] <fritsch> they do it like they did with braswell: broadwel gpu + skl hevc decoder
[16:25:38 CET] <fritsch> broxton: skl gpu + kabi lake hevc decoder?
[16:25:49 CET] <fritsch> wm4: haha
[16:26:02 CET] <fritsch> yeah - windows + gpu assisted decoding
[16:26:11 CET] <fritsch> but yes - codec wise totally not interesting
[16:26:13 CET] <nevcairiel> broxton doesnt have a release date yet
[16:26:14 CET] <fritsch> could have got a braswell
[16:26:15 CET] <nevcairiel> so there is that
[16:27:46 CET] <fritsch> i think the libyami guys will implement those bits the next days
[16:27:55 CET] <nevcairiel> skylake always looked like a rather underwhelming chip, both on the cpu and gpu front, so..
[16:28:07 CET] <fritsch> i liked it concerning the 8 bit hevc
[16:28:12 CET] <fritsch> think of broadwell ...
[16:28:18 CET] <fritsch> it delivered absolutely nothing
[16:28:29 CET] <nevcairiel> 8-bit hevc is not very interesting
[16:28:47 CET] <fritsch> yes ..
[16:28:54 CET] <nevcairiel> systems that adopt hevc for UHD appear to go 10-bit right away
[16:29:01 CET] <fritsch> but never the less bsw / skl was used to implemented hevc vaapii nffmpeg
[16:29:20 CET] <fritsch> and from the 10 bit hevc patch, it seems that extending "should work" quite well
[16:29:23 CET] <fritsch> in vaapi side
[16:29:42 CET] <nevcairiel> i got a braswell for vp9 hybrid decoding, but at least a braswell nuc is cheap, skylake cpus are expensive =p
[16:29:52 CET] <fritsch> yeah
[16:30:03 CET] <fritsch> how good is the performance of bsw vp9 decoding?
[16:30:13 CET] <fritsch> 4k 24p possible?
[16:30:18 CET] <fritsch> I don't think so
[16:30:20 CET] <nevcairiel> didnt test
[16:30:33 CET] <fritsch> you just implemented it and then did not test? :-)
[16:30:45 CET] <nevcairiel> not the performance, cant really influence that anyway
[16:30:55 CET] <nevcairiel> and ffmpegs cli dxva2 support is very inefficient
[16:31:00 CET] <nevcairiel> so no good for benchmarking
[16:32:35 CET] <nevcairiel> once its merged i might test it in my own code
[16:33:22 CET] <fritsch> the bsw/skl hevc 8 bit decoder is really good
[16:33:38 CET] <fritsch> and the bsw in case of decoding + rendering is also really nice
[16:33:50 CET] <fritsch> 4k at 60 hevc 8 bit was doable
[16:34:17 CET] <fritsch> therefore I am looking forward for these 10 bit chips - as they will decode uhd bluray and also new live tv standard
[16:35:33 CET] <nevcairiel> just get a nvidia 950 or 960, they do it today =p
[16:36:39 CET] <fritsch> yeah
[16:36:41 CET] <fritsch> :-)
[16:36:44 CET] <fritsch> not interested
[16:36:53 CET] <fritsch> as the card needs 5 times what my bsw rig needs
[16:36:54 CET] <fritsch> in idle
[16:37:04 CET] <nevcairiel> its hard to be amazed by intel when they are 1-1.5 years behind the flow
[16:37:12 CET] <fritsch> not sure they are
[16:37:21 CET] <fritsch> at least on linux there is no 10 bit solution for now at all
[16:37:33 CET] <wm4> as multimedia devs you got to deal with broken consumer hardware and braindead consumers anyway
[16:37:55 CET] <fritsch> hehe
[16:41:23 CET] <nevcairiel> skylake should've had hevc 10-bit and hdmi 2.0, then it might've been worth-while of a platform
[16:46:00 CET] <fritsch> jep
[16:51:07 CET] <wm4> skylake seems to be a disappointment in every way
[16:51:14 CET] <BBB> wait why?
[16:51:14 CET] <wm4> I guess haswell was too good?
[16:51:27 CET] <BBB> what does skylake have that is exciting?
[16:51:32 CET] <nevcairiel> nothing
[16:51:38 CET] <nevcairiel> unless you get wet from avx512
[16:51:40 CET] <BBB> Ive been waiting for months now to get a new mbp until skylake gets in macs
[16:51:51 CET] <BBB> I think avx512 is nice
[16:51:55 CET] <nevcairiel> and even then you need a xeon skylake
[16:52:02 CET] <wm4> never wait for new technology when buying something
[16:52:22 CET] <BBB> the current mac pros are & pre-sandybridge, I believe
[16:52:47 CET] <wm4> I have a broadwell mbp
[16:53:03 CET] <BBB> oh its ivy
[16:53:06 CET] <BBB> anyway
[16:53:11 CET] <BBB> ivy is not really exciting
[16:53:17 CET] <BBB> not even avx2
[16:53:54 CET] <nevcairiel> current mbps being sold are broadwell
[16:54:11 CET] <BBB> haswell no?
[16:54:19 CET] <nevcairiel> or haswell, depending on which model
[16:54:30 CET] <nevcairiel> 13" is broadwell, 15" is haswell
[16:55:00 CET] <BBB> but the haswell is slower
[16:55:20 CET] <nevcairiel> the haswell is a quadcore, the broadwell only duals
[16:55:24 CET] <nevcairiel> haswell clocks lower though
[16:55:27 CET] <nevcairiel> so ... maybe?
[16:55:43 CET] <BBB> 2.2/2.5GHz quadcore haswell, vs. 2.7/2.9GHz dualcore broadwell
[16:55:49 CET] <BBB> which makes me frown
[16:55:57 CET] <nevcairiel> there is a 2.8ghz haswell model
[16:56:02 CET] <nevcairiel> but those upgrades costs a fortune
[16:56:03 CET] <BBB> ohright, yes
[16:56:09 CET] <BBB> 2.2/2.5/2.8
[16:56:12 CET] <BBB> or 2.7/2.9/3.1
[16:56:18 CET] <fritsch> why not going with a broadwell thinkpad?
[16:56:21 CET] <BBB> I missed the highest
[16:56:25 CET] <nevcairiel> he wants a mac =p
[16:56:28 CET] <fritsch> core i7 broadwell?
[16:56:29 CET] <fritsch> okay
[16:56:40 CET] <BBB> sorry mac only here, I dont have time to mess with my computer
[16:56:52 CET] <fritsch> you do all the ffmpeg development on the mac?
[16:56:55 CET] <BBB> yes
[16:57:55 CET] <BBB> so why didnt they make a broadwell quadcore? so silly
[16:58:19 CET] <fritsch> the broadwell only has a better gpu to my knowledge ...
[16:58:24 CET] <fritsch> in comparison to hsw
[16:58:53 CET] <nevcairiel> the interesting thing is that the haswell models were actually released after the broadwell 13"
[16:59:02 CET] <nevcairiel> probably got a cheap deal on old haswell cpus =p
[16:59:20 CET] <fritsch> or broadwell sucked heat / power wise?
[16:59:31 CET] <BBB> so maybe Ill just buy yhe mbp right now then
[16:59:46 CET] <BBB> I also want a mac pro, but paying $10k for a ivy seems kind of outrageous
[17:00:47 CET] <fritsch> http://www.macrumors.com/roundup/macbook-pro/ <- some benchmarks
[17:02:04 CET] <nevcairiel> no benchmarks 13 vs 15 though
[17:02:39 CET] <fritsch> https://browser.primatelabs.com/mac-benchmarks
[17:02:41 CET] <fritsch> perhaps there are some
[17:03:18 CET] <Compn> develops open source software ... uses proprietary kernel :P
[17:03:19 CET] Action: Compn runs
[17:03:50 CET] <nevcairiel> no system is entirely open source
[17:04:15 CET] <Compn> oh it it? nice
[17:04:50 CET] <fritsch> since skl intel needs firmware
[17:04:56 CET] <fritsch> too for the cpu
[17:05:06 CET] <fritsch> or was that gpu part?
[17:05:10 CET] <fritsch> gpu I think
[17:07:23 CET] <BBB> Compn: sorry Im over that period, I dont think opensource is the magic key to world domination. look at gnome or kde& really not that great
[17:07:33 CET] <Compn> im just kidding
[17:07:41 CET] <Compn> use what works.
[17:08:44 CET] <BBB> Compn: ;)
[17:10:14 CET] <atomnuker> Today is a slow day, and you people are so bored you only speak of hardware
[17:10:17 CET] <atomnuker> How about a nice big portion of IT'S HAPPENING
[17:10:24 CET] <cone-055> ffmpeg 03Rostislav Pehlivanov 07master:3a6e0208615e: aacenc: mark the "faac"-like coder for removal
[17:10:25 CET] <cone-055> ffmpeg 03Rostislav Pehlivanov 07master:b270ec9a1069: aacenc: mark coders other than twoloop as experimental
[17:10:26 CET] <cone-055> ffmpeg 03Rostislav Pehlivanov 07master:e34e3619a2b5: doc/encoders.texi: update documentation for the native AAC encoder
[17:10:27 CET] <cone-055> ffmpeg 03Rostislav Pehlivanov 07master:d9791a8656b5: aacenc: remove the experimental flag
[17:10:30 CET] <Compn> what happening ? aac 
[17:10:31 CET] <Compn> oooo
[17:10:35 CET] <Compn> so pretty
[17:10:53 CET] <Compn> ffmpeg.org news entry?
[17:10:58 CET] <atomnuker> worthy.
[17:11:38 CET] <nevcairiel> can we close the mega ticket now
[17:11:59 CET] <Compn> careful, the ticket is sentient now.
[17:12:06 CET] <nevcairiel> and direct people to create new ones for new complaints =p
[17:14:44 CET] <atomnuker> not a bad idea
[17:14:58 CET] <thresh> who manages ffmpeg.org the website?
[17:15:03 CET] <thresh> :)
[17:15:34 CET] <atomnuker> Timothy_Gu ?
[17:15:39 CET] <kierank> thresh: I might be able to commit to it
[17:15:55 CET] <ubitux> jsut send a patch
[17:16:01 CET] <ubitux> many ppl cna write to it
[17:16:06 CET] <thresh> where to?
[17:16:07 CET] <ubitux> (all devs?)
[17:16:27 CET] <thresh> nevermind
[17:17:04 CET] <ubitux> meanwhile, the end is near http://pastie.org/pastes/10611337/text :(
[17:17:43 CET] <kierank> who has twitter access?
[17:18:03 CET] <kierank> Compn: ping any idea where I can get more cfhd samples
[17:22:19 CET] <thresh> kierank: https://gist.github.com/thresheek/257f8f97660c97e8c60b
[17:24:17 CET] <ubitux> atomnuker: in the doc, you can use "auto", "true", "false"
[17:24:25 CET] <ubitux> instead of "-1" "1" "0"
[17:26:19 CET] <kierank> thresh: can you send it in format-patch style
[17:27:20 CET] <BBB> ubitux: at least you know what hardware to upgrade to now :D
[17:27:26 CET] <thresh> kierank: hope this works: https://gist.github.com/thresheek/66f4dc38da19aa3bea4c
[17:36:34 CET] <atomnuker> someone will need to start a hydrogenaudio thread to rip the encoder apart with criticism
[17:36:52 CET] <wm4> ubitux: be glad it's not a ssd
[17:37:21 CET] <kierank> thresh: pushed
[17:37:37 CET] <thresh> kierank: thank you!
[17:37:56 CET] <thresh> oh shit, it's not the only place
[17:41:21 CET] <cone-055> ffmpeg 03Rostislav Pehlivanov 07master:49b82bc9562e: doc/encoders.texi: remove forgotten mention of "experimental" from libvo-aacenc
[17:42:20 CET] <thresh> kierank: https://gist.github.com/thresheek/4f6285e59e1f731bfbbf
[17:42:22 CET] <thresh> need more coffee
[17:44:06 CET] <cone-055> ffmpeg 03Michael Niedermayer 07master:79798f7c57b0: avcodec/dirac_parser: Fix potential overflows in pointer checks
[17:44:07 CET] <cone-055> ffmpeg 03Michael Niedermayer 07master:c7d6ec947c05: avcodec/dirac_parser: Add basic validity checks for next_pu_offset and prev_pu_offset
[17:44:08 CET] <cone-055> ffmpeg 03Michael Niedermayer 07master:a08681f1e614: avcodec/dirac_parser: Check that there is a previous PU before accessing it
[17:44:26 CET] <cbsrobot_> thresh: here to: https://trac.ffmpeg.org/wiki/CompilationGuide/Centos
[17:45:08 CET] <cbsrobot_> and several other wiki places
[17:45:59 CET] <kierank> thresh: pushed
[17:46:16 CET] <thresh> I don't have an account on trac.ffmpeg.org
[18:08:03 CET] <michaelni> thresh, how long will git:// still be available/work for ffmpeg ?
[18:15:39 CET] <thresh> michaelni: forever
[18:16:20 CET] <thresh> we do not plan to remove it, ffmpeg and x264 will be there
[18:17:50 CET] <ubitux> what was the point of switching to http then?
[18:17:51 CET] <michaelni> ahh, ok, i was already a bit scared, but why do you change the default ? or rather how does it help to change the default if git:// support is left ?
[18:18:14 CET] <thresh> I want to minimize the future usage of git://
[18:18:20 CET] <ubitux> why?
[18:18:25 CET] <ubitux> passing through more broken networks?
[18:19:15 CET] <thresh> bad experiences with git-daemon, mostly
[18:21:22 CET] <thresh> I would want to move git.videolan.org to some other server while preserving the URIs, and while fixing git:// protocol on the fly is possible (manipulating tcp stream), I would rather keep it to a minimum
[18:25:41 CET] <michaelni> thresh, if it would help, we could probably move git to our box too, we already have ffmpeg-web git on it, but it would require a volunteer to setup & test it and also setup hooks and all, that is assuming these git:// issues  dont affect us
[18:26:04 CET] <thresh> I see no point in doing that, we're happy to host you guys!
[18:26:18 CET] <michaelni> ok
[19:07:29 CET] <atomnuker> I've written a news story: http://paste.debian.net/hidden/f01697f2/
[19:08:01 CET] <atomnuker> any feedback before sending it over to the ML?
[19:17:10 CET] <wm4> I feel like it could use some rewording
[19:17:18 CET] <wm4> but I'm not a native speaker myself
[19:22:34 CET] <durandal_1707> Update changelog
[19:23:49 CET] <atomnuker> append at the end of version <next>?
[19:24:15 CET] <atomnuker> wait, there's already "extensive native AAC encoder improvements"
[19:24:55 CET] <atomnuker> maybe I should replace that instead?
[19:26:17 CET] <ubitux> yes
[19:37:13 CET] <cone-055> ffmpeg 03Rostislav Pehlivanov 07master:713e67e5d873: Changelog: append experimental flag removal to the AAC encoder entry
[19:37:14 CET] <cone-055> ffmpeg 03Rostislav Pehlivanov 07master:cc68ca0cab67: doc/encoders.texi: use words intead of numbers to describe option states
[19:44:17 CET] <cone-055> ffmpeg 03Rostislav Pehlivanov 07master:3112501daf71: aacenc: fix aac_pred option triggering an error
[20:10:26 CET] <J_Darnley> ubitux: thanks, I just saw your message (Re: avopt)
[20:18:21 CET] <cone-055> ffmpeg 03Rostislav Pehlivanov 07master:dcbe8d8abc9b: aacenc_ltp: use an AR filter for LTP encoding as well
[20:50:33 CET] <durandal_1707> ubitux: there is someone spamming #ffmpeg with rejoins of channel
[20:50:50 CET] <ubitux> fixed
[20:58:43 CET] <durandal_1707> thx
[21:53:29 CET] <durandal_1707> ubitux: still wanting to do nlmeans?
[21:54:16 CET] <ubitux> i'm currently working on it
[21:54:41 CET] <durandal_1707> assom
[23:07:59 CET] <cone-055> ffmpeg 03Michael Niedermayer 07master:214085852491: avcodec/hevc: Fix integer overflow of entry_point_offset
[00:00:00 CET] --- Sun Dec  6 2015