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

[burek]

[00:57:37 CET] <rcombs> atomnuker: hey, any idea when PCEs will be in aacenc?
[01:11:58 CET] <atomnuker> well, I already have a patch to handle the bitstream side of things
[01:13:01 CET] <atomnuker> I'll try to see if I can make it work
[01:14:57 CET] <durandal_1707> atomnuker: looked at that my ascend bug report?
[01:15:27 CET] <durandal_1707> aacenc*
[01:15:39 CET] <atomnuker> no, can you give me a link?
[01:15:47 CET] <atomnuker> is it that weird 10 second sound?
[01:16:36 CET] <durandal_1707> Yes, look at spectrum, its ambient music
[01:18:38 CET] <atomnuker> durandal_1707: was the name of the file artifacts.flac?
[01:19:09 CET] <durandal_1707> yes, IIRC
[01:26:59 CET] <atomnuker> durandal_1707:  https://0x0.st/8YP.png https://0x0.st/8YZ.png
[01:27:13 CET] <atomnuker> the only artifacts I can hear are the footstep-like sounds at +2 seconds
[01:32:55 CET] <durandal_1707> there are vertical shapes not presented in source
[01:35:04 CET] <durandal_1707> dunno if same happens with fdk-aac
[01:36:41 CET] <rcombs> atomnuker: cool, thanks
[01:46:15 CET] <atomnuker> durandal_170: yes, those are the footstep-like sounds
[01:46:30 CET] <atomnuker> they seem to disappear with higher bitrates
[01:47:00 CET] <atomnuker> I did try to see if any of the coding tools (pns, tns, is or ms) causes it but nope, seems to be the coder
[01:48:48 CET] <durandal_170> ok
[02:10:03 CET] <cone-228> ffmpeg 03Carl Eugen Hoyos 07master:2355b7458e63: lavf/mov: Set display aspect ratio for avid dv.
[02:13:34 CET] <cone-228> ffmpeg 03Michael Niedermayer 07master:a870aa89bf38: avformat/seek-test: Support passing options to demuxers and protocols
[02:13:35 CET] <cone-228> ffmpeg 03Michael Niedermayer 07master:5324882529f3: fate: add pipe and cache test
[05:03:54 CET] <cone-228> ffmpeg 03Ganesh Ajjanagadde 07master:bd9c58756a50: lavc/aacenc_utils: replace sqrtf(Q*sqrtf(Q)) by precomputed value
[05:45:11 CET] <chubchubcharles> hey i need help with understanding an error message
[05:45:33 CET] <chubchubcharles> What does the error 'missing picture in access unit size XX' mean?
[05:46:02 CET] <chubchubcharles> I got this error when I used a code from GitHub that supposedly converts video files (.avi) into key frames (images)
[05:46:07 CET] <chubchubcharles> but I placed in .mkv files instead
[05:46:19 CET] <chubchubcharles> is that the reason why i have this error -- because the input video format is incorrect?
[05:48:15 CET] <chubchubcharles> anyone?
[05:48:42 CET] <durandal_170> wild guess: missing bsf filter
[05:50:10 CET] <chubchubcharles> hmm.. not very familiar with bsf filter..
[05:50:18 CET] <chubchubcharles> is there another way of explaining it?
[06:26:15 CET] <Timothy_Gu> chubchubcharles: use #ffmpeg channel
[06:26:20 CET] <jamrial> michaelni: valgrind complains about seek-cache-pipe test
[08:35:41 CET] <PrateechiS> Hey
[08:36:25 CET] <PrateechiS> Can anyone help me installing FATEserver on Mac?
[09:51:56 CET] <cone-700> ffmpeg 03Paul B Mahol 07master:85dd497baad0: avfilter/vf_vectorscope: avoid crash by explicitly checking for 8-bit depth
[09:51:57 CET] <cone-700> ffmpeg 03Paul B Mahol 07master:a7897bd3a6e1: avfilter/vf_vectorscope: add graticule
[09:51:58 CET] <cone-700> ffmpeg 03Paul B Mahol 07master:29c6fd41fcf1: avfilter/vf_vectorscope: make background opacity customizable
[09:59:14 CET] <mrec> hi, does anyone know which documentation I have to look at about the mpeg system stream header format 0x0000010 ?
[10:10:52 CET] <j-b> 'morning
[11:21:56 CET] <cone-700> ffmpeg 03Paul B Mahol 07master:bdf474bcff29: doc/utils: fix typo for min() description
[11:57:21 CET] <JamJams> Hi just wondering does anybody know which file contains the resync code for transport streams? Save me digging around is all.
[12:07:15 CET] <rcombs> mpegts.c
[12:08:25 CET] <mateo`> if there is a change of configuration in the h264 bitstream, who is in charge of updating the decoder avctx with the new width/height, coded_width/coded_height ?
[12:10:15 CET] <mateo`> the decoder itself ? or the layer above ?
[12:12:06 CET] <wm4> there's no layer above
[12:12:11 CET] <wm4> so the decoder
[12:12:26 CET] <wm4> some formats may have an external mechanism to update them
[12:12:43 CET] <wm4> but that's not the case with h264
[12:13:12 CET] <wm4> see apply_param_change()
[12:13:43 CET] <mateo`> in the case of mediacodec, i should watch for resolution/format changes in the bitstream filter right ?
[12:14:00 CET] <mateo`> and update the avctx accordingly
[12:14:18 CET] <wm4> I'm not sure how exactly that works, but I don't think the annex b bitstream filter does that
[12:14:28 CET] <wm4> the decoder itself would have to tell you
[12:15:11 CET] <mateo`> i don't trust the value returned by mediacodec as they seem to be the coded values and not the actual ones.
[12:15:35 CET] <wm4> usually a decoder will return the coded width/height, and a separate crop rectangle
[12:16:14 CET] <wm4> (ffmpeg ignores this concept; for software decoding, it will adjust the plane pointers to "crop" the top/left borders)
[12:20:46 CET] <mateo`> i'll double check again but from what i remember the crop values returned by mediacodec are missing most of the time
[12:20:59 CET] <wbs> mateo`: as far as I've seen, it always returns crop values
[12:21:13 CET] <JamJams> So mpegts.c has the code that will add extra video or audio frames to the stream to retain sync?
[12:21:33 CET] <wm4> JamJams: no, ffmpeg.c does that
[12:21:34 CET] <wbs> the width/height is whatever padded size the decoder chose (not necessarily the coded size), and then you have the crop-left/crop-right etc fields
[12:21:51 CET] <mateo`> wbs: are the values correct ?
[12:21:59 CET] <wbs> mateo`: I haven't seen a case where they wouldn't be
[12:22:33 CET] <wm4> you should probably verify that they are not larger than the coded size
[12:22:34 CET] <mateo`> i remember seeing cases when the crop-bottom is missing so you end up with 1920x1088 frames for example
[12:22:54 CET] <wbs> (the only case where things are weird is the handling of the TI version of NV12 on the OMAP4 decoder, where one either has to adjust for the top crop offset for the second plane, or ignore the offset parameter)
[12:22:59 CET] <wbs> hmm, haven't seen that
[12:23:55 CET] <mateo`> ok I will double check then, my memories might be at fault here
[12:24:44 CET] <JamJams> wm4 I thought so, do you know where exactly in that monster of a file :P Just looking to review how it handles sync got an odd stream here maybe a bug but probably just the stream being bad.
[12:25:24 CET] <wm4> JamJams: I'm not familiar with it either, but I think at least some if it is in do_video_out()
[12:25:53 CET] <JamJams> I thought it might be related to vf_framesync.c
[12:30:43 CET] <JamJams> Ahhh I see it
[12:30:45 CET] <JamJams> I see it
[12:35:32 CET] <cone-700> ffmpeg 03Paul B Mahol 07master:5afe91833608: avfilter/vf_vectorscope: add 9 & 10 bit depth input & output support with alpha
[12:57:37 CET] <JamJams> Line 946-947 of ffmpeg.c isn't it a little redundant to do that maths twice per frame :/
[13:43:05 CET] <ismail> nevcairiel: mkstemp patch is now upstream
[13:43:19 CET] <ismail> master branch at least.
[13:55:15 CET] <cone-700> ffmpeg 03Clément BSsch 07master:24a189e01647: fate/api: add missing FLV dependency to fate-api-seek
[13:55:28 CET] <ubitux> the test is weird btw
[13:55:38 CET] <ubitux> it's testing seeking on a 1sec video
[13:55:46 CET] <ubitux> doesn't sound very useful
[13:56:35 CET] <ubitux> it's also weird to have it depend on lavf-flv to get a synth flv
[13:56:40 CET] <ubitux> anyway..
[13:58:13 CET] <wm4> hm I guess 1 seconds could get a bit tight for keyframe intervals
[14:00:06 CET] <ubitux> heh, the recent thread fixes seem to allow about +80 additionnal tests to go green on helgrind fate instance
[14:00:26 CET] <ubitux> ~820 more to go
[14:03:39 CET] <wm4> lol
[14:03:43 CET] <wm4> some progress
[14:27:13 CET] <wm4> mateo`: in case you have looked at my decoder API changes, do you think that would simplify your mediacodec wrapper?
[14:27:36 CET] <BBB> ubitux: hm& you mean the die one?
[14:27:53 CET] <ubitux> apparently
[14:28:10 CET] <BBB> ubitux: if you want more to go green, make h264slicecontext only copy the members it cares about for the next thread
[14:28:18 CET] <cone-700> ffmpeg 03Michael Niedermayer 07master:554f6e930ce0: avformat/cache: Fix memleak of tree entries
[14:28:25 CET] <BBB> its quite a bit of work but itll make probably about half of them go green
[14:28:39 CET] <ubitux> there are still reported cases in the "core" of the threading, so that's why it get triggered in so many tests 
[14:29:01 CET] <BBB> and its a performance improvement if you do it correctly (i.e. only copy half of the struct and re-arrange members so they are consecutive on the top of the struct)
[14:29:03 CET] <ubitux> BBB: many tests are not h264 specific
[14:29:13 CET] <BBB> the same may apply to other codecs also
[14:29:20 CET] <BBB> is vp9/8 having any issues?
[14:29:24 CET] <BBB> their threading is much more contained
[14:29:44 CET] <ubitux> almost every tests involving threading are basically failing one way or another
[14:29:54 CET] <BBB> you said 80 succeed now
[14:30:03 CET] <ubitux> yes, apparently
[14:30:12 CET] <ubitux> http://fate.ffmpeg.org/history.cgi?slot=x86_64-archlinux-gcc-valgrind-threads
[14:30:14 CET] <ubitux> see scores
[14:30:48 CET] <BBB> theres an asan issue btw
[14:31:08 CET] <BBB> http://fate.ffmpeg.org/report.cgi?time=20160302095749&slot=x86_64-archlinux-gcc-asan
[14:31:09 CET] <BBB> a memleak
[14:31:14 CET] <ubitux> yes, valgrind reported it as well
[14:31:32 CET] <BBB> and helgrind vp8/9 is clean
[14:31:36 CET] <BBB> so Im not convinced
[14:31:44 CET] <mateo`> wm4: I haven't looked at the new api but it's on my todolist
[14:31:59 CET] <BBB> oh I see theres so many failues it doesnt fit the page
[14:32:03 CET] <BBB> and vp* comes at the end
[14:32:07 CET] <BBB> (its still loading)
[14:32:54 CET] <ubitux> yeah, every report represents gigabytes of report
[14:33:00 CET] <ubitux> of data*
[14:33:29 CET] <BBB> omg wtf
[14:33:32 CET] <BBB> I don't have tghat muc
[14:33:38 CET] <ubitux> :))
[14:33:44 CET] <ubitux> the drd report are smaller iirc
[14:33:47 CET] <BBB> much memory
[14:33:48 CET] <ubitux> http://fate.ffmpeg.org/report.cgi?time=20160302123319&slot=x86_64-archlinux-gcc-valgrind-drd
[14:33:55 CET] <BBB> my ysem is crashing thats ho ig it is
[14:34:14 CET] <BBB> well that didnt work
[14:35:12 CET] <ubitux> BBB: http://sprunge.us/PUCA
[14:35:17 CET] <ubitux> here is one vp9 test with drd
[14:36:04 CET] <ubitux> but most of the failure are probably not vp9 specific
[14:36:30 CET] <BBB> oh its the p->state access outside the lock context
[14:36:36 CET] <BBB> Im not sure I care about those
[14:36:47 CET] <ubitux> when the core will be clean of all these issues it will be much easier to track the other codec specific issues
[14:37:08 CET] <BBB> make state atomic
[14:37:18 CET] <BBB> I think the google dude is doing that now
[14:43:26 CET] <BBB> the drd page is also unresponsive as soon as I click any link
[14:43:28 CET] <BBB> :(
[15:06:50 CET] <ismail> what is the version of master atm 3.1?
[15:11:30 CET] <nevcairiel> 3.1-dev, but thats really not a version worth using anywhere
[15:13:03 CET] <ismail> nevcairiel: I am packaging git snapshots for unofficial purposes, thats why I asked
[15:13:06 CET] <ismail> thanks!
[15:13:17 CET] <nevcairiel> should just use git-describe for that =p
[15:13:27 CET] <nevcairiel> thats what the binary will call itself as well when build from git
[16:01:29 CET] <ubitux> Daemon404: do you have plans for the blacklist/whitelist mechanism in urlprotocol?
[16:01:43 CET] <ubitux> or we're going to keep our system?
[16:01:48 CET] <Daemon404> im unsure
[16:02:01 CET] <Daemon404> i would not like to break compat
[16:50:08 CET] <BBB> nevcairiel: how does a hwaccel signal that it does not support a particular stream?
[16:50:23 CET] <Daemon404> (inb4 blows up)
[16:52:05 CET] <nevcairiel> BBB: it doesnt
[16:52:11 CET] <nevcairiel> you are supposed to check
[16:52:35 CET] <nevcairiel> if its entirely incompatible, it will usually just not invoke the function to activate hwaccel
[16:52:42 CET] <nevcairiel> ie. different chroma format or bitdepth
[16:53:07 CET] <nevcairiel> but other than that, its the users responsibility to check the capabilities of the hardware
[16:53:17 CET] <BBB> hm
[16:53:29 CET] <ubitux> so apparently firefox is still unable to play mp4 properly
[16:53:37 CET] <ubitux> i got a 1sec lag every second
[16:53:40 CET] <nevcairiel> it really only applies to different types of 420 8-bit, like h264 lossless
[16:53:49 CET] <ubitux> (even when playing the file locally within firefox)
[16:54:20 CET] <mateo`> ubitux: maybe install flash player
[16:54:34 CET] <JEEB> mp4 playback for me has worked pretty well for quite a few months
[16:54:48 CET] <Daemon404> same
[16:54:50 CET] <JEEB> although I've always used the "developer edition" firefox
[16:54:50 CET] <ubitux> JEEB: http://b.pkh.me/tourbillons-de-neige.mp4  plays smoothly for you?
[16:54:58 CET] <JEEB> ubitux: wait until I get home
[16:55:02 CET] <Timothy_Gu> ff on windows work fine
[16:55:09 CET] <Daemon404> ubitux, broken here
[16:55:11 CET] <Daemon404> same lag
[16:55:13 CET] <ubitux> right
[16:55:14 CET] <Daemon404> on windows
[16:55:19 CET] <ubitux> okay.
[16:55:49 CET] <Daemon404> works in chrome
[16:55:56 CET] <ubitux> yes, it works everywhere
[16:56:01 CET] <ubitux> except firefox (even locally)
[17:00:15 CET] <ubitux> but it seems caused by the ffmpeg remux though
[17:01:52 CET] <ubitux> more specifically, by the time offsetting
[17:02:26 CET] <Daemon404> 'time offsetting'?
[17:02:28 CET] <ubitux> -ss 
[17:03:12 CET] <Daemon404> o
[17:03:14 CET] <Daemon404> elst?
[17:05:25 CET] <ubitux> yeah, probably related as usual
[18:14:57 CET] <cone-596> ffmpeg 03Mats Peterson 07master:2be0366a7f5d: lavf/utils: Add ff_get_packet_palette()
[18:16:19 CET] <kierank> pfft
[18:22:30 CET] <ubitux> ffmpeg -f lavfi -i "aevalsrc=floor(t)/10:d=10" -lavfi showwavespic out.png
[18:22:32 CET] <ubitux> what am i doing
[18:39:48 CET] <mrec> can anyone recommend some good documentation about MPEG2?
[18:40:20 CET] <mrec> even though I'm able to decode kind of everything using libavcodec I'm not satisfied with the video playback
[18:40:46 CET] <mrec> xine seems to have the best deinterlaced playback
[18:41:02 CET] <mrec> libavcodec using yadif=1 is second
[18:41:13 CET] <BtbN> try the new neural network magic
[18:41:16 CET] <mrec> but the cpu usage of libavformat is poor
[18:41:45 CET] <BtbN> And i don't see how deinterlacing is related to mpeg2 documentation.
[18:42:19 CET] <mrec> the presentation part is not clear to me and I seem to be stuck with that topic
[18:42:44 CET] <BtbN> presentation is not the job of ffmpeg though
[18:45:25 CET] <ubitux> ffmpeg has many deinterlacer, and maybe your source is just telecined and using yadif is wrong
[18:50:29 CET] <wm4> xine also could be using random filters?
[18:50:55 CET] <mrec> the cpu time xine vs ffplay 15:40
[18:51:06 CET] <mrec> ffplay using yadif=1
[18:51:22 CET] <mrec> there's some difference on the deinterlaced picture they're using another deinterlacer
[18:51:35 CET] <mrec> however my main problem is the juddered picture from time to time
[18:52:12 CET] <mrec> I only see that on scrolling video though
[19:36:31 CET] <smontgomerie> Hey guys I'm wondering if I can get some help compiling ffmpeg on Windows 10
[19:36:42 CET] <smontgomerie> configure passes without error
[19:36:50 CET] <smontgomerie> get this error:
[19:36:51 CET] <smontgomerie> awk: cmd. line:1: /including/ { sub(/^.*file: */, ""); gsub(/\/, "/"); if (!match($0, / /)) print "libavdevice/alldevices.o:", $0 }
[19:37:00 CET] Last message repeated 1 time(s).
[19:37:00 CET] <smontgomerie> awk: cmd. line:1:                                                                                                        ^ syntax error
[19:37:18 CET] <smontgomerie> awk: cmd. line:1:                                                                                                           ^ unterminated string
[19:37:36 CET] <smontgomerie> but the awk line looks fine 
[19:38:26 CET] <smontgomerie> there was a mention of this on this thread: https://ffmpeg.zeranoe.com/forum/viewtopic.php?t=2440
[19:38:33 CET] <kierank> probably some windows whitespace issue
[19:38:39 CET] <smontgomerie> the solution being to update make
[19:39:13 CET] <smontgomerie> huh, ok how would i debug that whitespace issue?
[19:39:21 CET] <smontgomerie> This is MSYS btw
[19:40:33 CET] <Daemon404> i mean, you kind of answered your own question
[19:40:39 CET] <Daemon404> your make is probably ancient
[19:40:49 CET] <Daemon404> which, if youre on the original msys, is certain
[19:40:53 CET] <smontgomerie> $ make -v
[19:40:53 CET] <smontgomerie> GNU Make 4.1
[19:40:53 CET] <smontgomerie> Built for i686-pc-cygwin
[19:41:05 CET] <Daemon404> hmm
[19:41:11 CET] <smontgomerie> I installed make from pacman
[19:41:24 CET] <smontgomerie> and which make uses the right one (now)
[19:41:34 CET] <Daemon404> did you per chance clone the git repo with 'native' endings instead of whats in the repo
[19:41:37 CET] <Daemon404> some versions of git have that
[19:41:40 CET] <Daemon404> byt defauly
[19:41:44 CET] <Daemon404> by default*
[19:42:29 CET] <smontgomerie> huh. well I'm seeing the same error in a fresh "git clone" as well as downloading the src zip from http://ffmpeg.zeranoe.com/builds/
[19:43:18 CET] <smontgomerie> on the git clone version, I do get this error prior: ./version.sh: line 2: $'\r': command not found
[19:43:30 CET] <smontgomerie> so line endings are a possibility
[19:44:40 CET] <smontgomerie> dos2unix version.sh got rid of the version error
[19:44:53 CET] <Daemon404> nothing in the repo should have dos endings.
[19:45:38 CET] <Daemon404> git config --global core.autcrlf false
[19:45:41 CET] <Daemon404> ^ do this, then clone
[19:45:55 CET] <Daemon404> also why does your make from cygwin
[19:45:59 CET] <Daemon404> you said you were using msys.
[19:46:12 CET] <smontgomerie> that is a good question...
[19:46:39 CET] <Daemon404> $ make -v
[19:46:39 CET] <Daemon404> GNU Make 4.1
[19:46:39 CET] <Daemon404> Built for x86_64-pc-msys
[19:47:36 CET] <JEEB> <@Daemon404> git config --global core.autcrlf false <= autocrlf is the most !?!? option I know of in git
[19:47:43 CET] <smontgomerie> ok... weird
[19:47:45 CET] <smontgomerie> $ which make
[19:47:52 CET] <smontgomerie> GNU Make 4.1
[19:47:52 CET] <smontgomerie> Built for x86_64-pc-msys
[19:48:15 CET] <smontgomerie> so yeah it was using the wrong make somehow.
[19:48:34 CET] <smontgomerie> sory
[19:48:35 CET] <smontgomerie> $ /usr/bin/make -v
[19:48:35 CET] <smontgomerie> GNU Make 4.1
[19:48:35 CET] <smontgomerie> Built for x86_64-pc-msys
[19:49:32 CET] <smontgomerie> now i have a whole different set of errors. I'll bash my head against the wall on these for a while, thx.
[19:49:49 CET] <Daemon404> your environment sounds broken
[19:50:05 CET] <smontgomerie> it's a fresh install of msys
[19:50:27 CET] <smontgomerie> maybe I'll reinstall everything
[19:51:43 CET] <smontgomerie> ok i'll do that, thx for your help!
[20:12:45 CET] <durandal_1707> people ask me to add features to lavfi for free
[20:12:58 CET] <kierank> like what
[20:16:14 CET] <durandal_1707> top secret, only shared with VIP like me 
[20:32:15 CET] <durandal_1707> its for sofalizer...
[20:34:13 CET] <durandal_1707> BBB: y4m demuxer doesn't seek to begining if its partially downloaded
[20:40:11 CET] <BBB> ?
[20:40:20 CET] <BBB> I didnt write the y4m demuxer
[20:46:29 CET] <durandal_1707> but seeking
[20:56:53 CET] <durandal_1707> BBB: fixed it
[20:57:21 CET] <BBB> ok
[20:57:59 CET] <kierank> durandal_1707: make mats use trac
[20:58:50 CET] <durandal_1707> kierank: he have book in pal8 format
[21:00:26 CET] <Daemon404> kierank, or... irc
[21:00:31 CET] <Daemon404> an actual instant messaging protocol
[21:00:34 CET] <kierank> yes
[21:00:35 CET] <Daemon404> which is how he uses email
[21:00:38 CET] <kierank> then I could put him on ignore
[21:03:45 CET] <durandal_1707> If I didn't looked in my spam folder I would never noticed him
[21:04:48 CET] <Daemon404> his latest email is amusing
[21:04:54 CET] <Daemon404> "I noticed that you, Paul, added a patch somewhere in 2012"
[21:04:59 CET] <Daemon404> it's not even CC'd to durandal_1707
[21:05:13 CET] <JEEB> lol
[21:13:26 CET] <jamrial> i added a filter to thunderbird to hide every single thread started by him until he stops spamming the list
[21:15:26 CET] <Daemon404> he needs to learn to thread his patchsets too.
[21:16:42 CET] <ilovewebm> Hi! Quick question, how did ffmpeg develop decoders/encoders of a proprietary codec whose specification was not available? Reverse engineering encoded files?
[21:17:05 CET] <JEEB> you usually have some sort of decoder and/or encoder
[21:17:09 CET] <JEEB> then you reverse engineer that
[21:17:11 CET] <fritsch> there was a nice blog entry about that lately
[21:17:29 CET] <Daemon404> i personally prefer to divine it from the gods of multimedia
[21:17:32 CET] <JEEB> you can't do too much with just the files :P
[21:17:36 CET] <JEEB> Daemon404: :D
[21:17:36 CET] <ilovewebm> That sounds challenging
[21:17:43 CET] <ilovewebm> :D
[21:20:37 CET] <cone-466> ffmpeg 03Rick Kern 07master:3af71ac3f9f6: lavc: add VideoToolbox H.264 Encoder
[21:21:40 CET] <ilovewebm> fritsch: Do you have the link around for the blog post? I'm trying to google but I suck :/
[21:21:57 CET] <fritsch> i don't find it - it was a dev from this channel
[21:22:12 CET] <fritsch> that described how he reverse engineered a partly known format
[21:22:18 CET] <fritsch> and gave a talk on a conference
[21:22:22 CET] <fritsch> but I cannot find it anymore
[21:22:38 CET] <ilovewebm> Cool np, I'll try and dig more, thanks!
[21:23:29 CET] <fritsch> https://fosdem.org/2016/schedule/event/video_reverse_eng/attachments/slides/1129/export/events/attachments/video_reverse_eng/slides/1129/17_vittorio.pdf
[21:23:32 CET] <fritsch> found it
[21:23:42 CET] <durandal_1707> ilovewebm: there is fosdem video, recent
[21:24:12 CET] <ilovewebm> Awesome, thanks a lot :)
[21:25:11 CET] <Daemon404> is it up yet
[21:25:40 CET] <Daemon404> indeed
[21:25:40 CET] <Daemon404> so it is
[21:27:36 CET] <Daemon404> the audio on this is so bad
[21:27:38 CET] <Daemon404> A+ fosdem...
[21:29:28 CET] <durandal_1707> and there are blogs
[21:53:42 CET] <durandal_1707> how many outreachy slots we have? 
[22:35:36 CET] <J_Darnley> durandal_1707: last I heard, one
[22:52:56 CET] <durandal_1707> kierank: have 4k pdf for pattern generation?
[22:55:56 CET] <jamrial> michaelni: check foo86's recent patchset to see if they fix the coverity stuff you informed him about a few weeks ago. if not poke him about it again
[23:30:40 CET] <Daemon404> urg i need to merge more tomorrow
[23:33:39 CET] <jamrial> Daemon404: tep2 commits?
[23:34:29 CET] <Daemon404> no theres some more stuff up to it
[23:34:35 CET] <Daemon404> like 6-7 commits
[23:34:37 CET] <Daemon404> wont take long
[00:00:00 CET] --- Thu Mar  3 2016