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

Fri Jul 17 02:05:02 CEST 2015

[02:53:10 CEST] <cone-038> ffmpeg 03Carl Eugen Hoyos 07master:9901e5318730: lavf/rtpenc_jpeg: Fix sending multiple quantization tables.
[04:06:01 CEST] <J_Darnley> durandal_1707 jamrial: I have pushed naieve avx2 functions for removegrain to my Gitlab repo
[04:06:39 CEST] <J_Darnley> I will look for more improvements and benchmark them tomorrow 
[04:08:16 CEST] <J_Darnley> oh I also pushed a small addition to x86inc.asm
[04:08:23 CEST] <J_Darnley> I got bit in the ass by that again.
[04:35:59 CEST] <cone-038> ffmpeg 03Michael Niedermayer 07master:cdca400c5efa: avformat/utils: Print stream number in max_analyze_duration exit path
[04:36:00 CEST] <cone-038> ffmpeg 03Michael Niedermayer 07master:4afc3429be49: avformat/utils: Fix regression with H264 stream probing
[04:36:01 CEST] <cone-038> ffmpeg 03Michael Niedermayer 07master:a39512ba9e0c: tests/checkasm/checkasm: Give macro a body to avoid potential unexpected syntax issues
[11:13:44 CEST] <cone-649> ffmpeg 03Paul B Mahol 07master:30015584872f: avfilter: add erosion, dilation, deflate & inflate filter
[11:21:13 CEST] <cone-649> ffmpeg 03Paul B Mahol 07master:61641627b87c: avfilter/af_astats: calculate audio bit-depth
[11:25:19 CEST] <cone-649> ffmpeg 03Paul B Mahol 07master:7aafac976fe2: avfilter/vf_smartblur: use the name 's' for the pointer to the private context
[11:51:05 CEST] <ubitux> random and perms=random are doing a nice couple of jerk filters
[11:51:09 CEST] <ubitux> i hope the family will grow
[12:28:18 CEST] <cone-649> ffmpeg 03Carl Eugen Hoyos 07master:8dad213143e3: lavc: Add properties field to AVCodecContext.
[12:28:19 CEST] <cone-649> ffmpeg 03Michael Niedermayer 07master:f1a38264f203: avcodec/pthread_frame: clear priv_data, avoid stale pointer in error case
[14:48:50 CEST] <BBB> michaelni: the vp9mc for mips/msa looks ok to me (Im no expert in anything, but a cursory look suggests its at least sane)
[15:12:32 CEST] <D404|Ghetto> durandal_1707: trying to write vf_reverse based off your (entirely uncommented) vf_random
[15:12:38 CEST] <D404|Ghetto> ending in segfault atm 
[15:12:44 CEST] <D404|Ghetto> (and im still quite unclear on wtf is going on)
[15:12:52 CEST] <D404|Ghetto> (in the code)
[15:13:21 CEST] <durandal_1707> what's unclear?
[15:13:27 CEST] <D404|Ghetto> mostly everything
[15:14:00 CEST] <D404|Ghetto> the pts stuff w/ memove, the interaction between filter and reques
[15:14:01 CEST] <D404|Ghetto> t
[15:14:12 CEST] <durandal_1707> You just need use stack and do not need memmove
[15:14:39 CEST] <D404|Ghetto> im pretty unclear on how to actually stakc and return frames
[15:14:45 CEST] <D404|Ghetto> since everything is done with links
[15:15:01 CEST] <durandal_1707> If pts come in random/reverse ffmpeg will drop frames
[15:16:03 CEST] <D404|Ghetto> thats nice but doesnt explain anything to me.
[15:16:05 CEST] <durandal_1707> so pts must come out as they get in
[15:16:57 CEST] <D404|Ghetto> http://chromashift.org/reverse.c.txt
[15:17:42 CEST] <D404|Ghetto> im still pretty damn unclear on how filter and request interact, and who is responsible for what
[15:17:48 CEST] <D404|Ghetto> it seems fairly entangle.d
[15:22:59 CEST] <D404|Ghetto> backtraces arent so helpful... theyre a mess of callbacks
[15:23:51 CEST] <durandal_1707> when stack is empty you need to feel it again
[15:24:33 CEST] <durandal_1707> Does it returns at least several frames?
[15:24:46 CEST] <durandal_1707> Before crash?
[15:25:12 CEST] <D404|Ghetto> 1 sec recompiling with -O0
[15:25:23 CEST] <D404|Ghetto> and i will test with frames=clip_length
[15:25:37 CEST] <D404|Ghetto> which i ntheory shouldnt crash if that was the only problem.
[15:28:07 CEST] <D404|Ghetto> durandal_1707: yes works if frames = clip
[15:28:16 CEST] <D404|Ghetto> so i guess the stack needs reflling like you said
[15:28:27 CEST] <D404|Ghetto> also there was an off-by-one error
[15:30:13 CEST] <durandal_1707> where?
[15:30:44 CEST] <D404|Ghetto> idx = s->nb_frames - s->frames_used;
[15:30:46 CEST] <D404|Ghetto> needs a -1
[15:30:47 CEST] <D404|Ghetto> i thin
[15:30:51 CEST] <D404|Ghetto> k
[15:30:54 CEST] <cone-649> ffmpeg 03hSÇ 07master:dcd14db80670: avcodec: loongson add constant definition
[15:30:55 CEST] <cone-649> ffmpeg 03hSÇ 07master:0bfa176c64c2: avcodec: loongson optimized idctdsp with mmi
[15:30:56 CEST] <cone-649> ffmpeg 03Rong Yan 07master:2af180bf1bf1: swscale/ppc/yuv2rgb_altivec: POWER LE support in the macros vec_unh() and vec_unl()
[15:30:57 CEST] <cone-649> ffmpeg 03Shivraj Patil 07master:012ba786e6a7: avcodec/mips: MSA (MIPS-SIMD-Arch) optimizations for VP9 MC functions
[15:34:36 CEST] <D404|Ghetto> hmm.
[15:36:59 CEST] <D404|Ghetto> different crash now...
[15:38:55 CEST] <durandal_1707> you probably need to cache and release in bursts
[15:41:07 CEST] <D404|Ghetto> i think i got t
[15:41:07 CEST] <D404|Ghetto> it
[15:41:18 CEST] <D404|Ghetto> maybe
[15:42:01 CEST] <D404|Ghetto> ... nope
[15:54:43 CEST] <D404|Ghetto> think i got it working...
[16:02:05 CEST] <D404|Ghetto> now to figure out this horrendous compelx filter api...
[16:02:11 CEST] <D404|Ghetto>  ./ffmpeg_g -i foreman_cif.y4m -filter_complex 'trim=end=30 [v1] ; trim=end=60 [v2] ; [v1] [v2] concat [outv]' t.y4m
[16:02:15 CEST] <D404|Ghetto> s/api/syntax/
[16:02:18 CEST] <D404|Ghetto> ^ sure doens't work
[16:02:36 CEST] <D404|Ghetto> ubitux maybe
[16:03:08 CEST] <ubitux> what doesn't work?
[16:03:30 CEST] <D404|Ghetto> what i just pasted
[16:03:36 CEST] <ubitux> yeah but what's the result?
[16:03:37 CEST] <D404|Ghetto> doesnt even allow output
[16:03:42 CEST] <D404|Ghetto> Cannot find a matching stream for unlabeled input pad 0 on filter Parsed_trim_1
[16:03:48 CEST] <ubitux> wait i see only one input
[16:03:54 CEST] <ubitux> what are you trying to do?
[16:04:06 CEST] <D404|Ghetto> simple
[16:04:15 CEST] <D404|Ghetto> trim(0,30s)+trim(0,60s)
[16:04:28 CEST] <ubitux> what does it do?
[16:04:31 CEST] <D404|Ghetto> (it would repeat)
[16:04:34 CEST] <D404|Ghetto> what does WHAT do?
[16:04:39 CEST] <D404|Ghetto> i just said it refused to output.
[16:04:42 CEST] <ubitux> your trim thing
[16:04:53 CEST] <D404|Ghetto> takes 0-30s?
[16:04:54 CEST] <ubitux> i mean what does "trim(0,30s)+trim(0,60s)" mean
[16:04:56 CEST] <D404|Ghetto> and 0-60s?
[16:05:02 CEST] <ubitux> ok
[16:05:05 CEST] <D404|Ghetto> trim() is basically the same EVERYWHERE
[16:05:07 CEST] <D404|Ghetto> sure is bubble
[16:05:18 CEST] <ubitux> are you find with two open?
[16:05:20 CEST] <ubitux> fine*
[16:05:24 CEST] <D404|Ghetto> ?
[16:05:28 CEST] <ubitux> (there are multiple solutions)
[16:05:30 CEST] <ubitux> like
[16:05:34 CEST] <D404|Ghetto> i would rather only open one
[16:05:35 CEST] <ubitux> ffmpeg -i foreman_cif.y4m -i foreman_cif.y4m -lavfi ...
[16:05:37 CEST] <D404|Ghetto> irl i'd want like
[16:05:41 CEST] <D404|Ghetto> scale the inpit res
[16:05:45 CEST] <D404|Ghetto> then do ym trims
[16:05:46 CEST] <ubitux> ok
[16:05:55 CEST] <D404|Ghetto> split might be what i want?
[16:06:25 CEST] <ubitux> then -i foreman_cif.y4m -vf "split=2[a][b]; [a]trim=end=30[t30]; [b]trim=end=60[t60]; [t30][t60]concat" ...
[16:06:27 CEST] <ubitux> does this work?
[16:06:32 CEST] <D404|Ghetto> what does the 2 do
[16:06:41 CEST] <ubitux> it splits in two?
[16:06:44 CEST] <D404|Ghetto> why does it need it
[16:06:47 CEST] <D404|Ghetto> it cant tell there are two?
[16:06:57 CEST] <D404|Ghetto> (instead of split=[a][b])
[16:07:15 CEST] <ubitux> well you want to trim differently 2x the input
[16:07:24 CEST] <D404|Ghetto> so?
[16:07:34 CEST] <D404|Ghetto> i dont understand why splti would behave differently if you give it a 2 or not
[16:07:37 CEST] <ubitux> well then you have a duplicate
[16:07:38 CEST] <D404|Ghetto> youre still providing 2 outputs
[16:07:57 CEST] <ubitux> ?
[16:08:03 CEST] <ubitux> foreman_cif.y4m is one input
[16:08:06 CEST] <ubitux> it's split in 2 outputs
[16:08:08 CEST] <ubitux> for each trim
[16:08:14 CEST] <D404|Ghetto> so why cant it see [a][b]
[16:08:16 CEST] <D404|Ghetto> and know it's two
[16:08:23 CEST] <ubitux> ah that
[16:08:40 CEST] <ubitux> yeah it was proposed to adjust this automatically
[16:08:49 CEST] <ubitux> i don't remember why we didn't
[16:09:02 CEST] <ubitux> nicolas was saying it should be doable without much effort
[16:09:18 CEST] <D404|Ghetto> i see
[16:09:24 CEST] <D404|Ghetto> anyway that indeed works
[16:09:28 CEST] <D404|Ghetto> i do have a questiob
[16:09:34 CEST] <D404|Ghetto> can trim work with frame #s?
[16:09:38 CEST] <D404|Ghetto> i only see pts and seconds.
[16:09:38 CEST] <ubitux> (i think there are some tricks because the syntax allows you implicit labels)
[16:09:42 CEST] <ubitux> mmh
[16:09:44 CEST] <ubitux> i think so
[16:09:46 CEST] <D404|Ghetto> which is not ideal
[16:09:47 CEST] <D404|Ghetto> i see.
[16:09:52 CEST] <ubitux> start_frame/end_frame, no?
[16:09:53 CEST] <D404|Ghetto> converting frame to time and back is less tahn idea
[16:09:55 CEST] <D404|Ghetto> l
[16:10:11 CEST] <ubitux> D404|Ghetto: ffmpeg -h filter=trim
[16:10:15 CEST] <D404|Ghetto> ah
[16:10:18 CEST] <D404|Ghetto> im blind
[16:11:23 CEST] <D404|Ghetto> -filter_complex 'scale=640:480[c]; [c]split=2[a][b]; [a]trim=end_frame=30[t30]; [b]trim=end_frame=90[t60]; [t30][t60]concat'
[16:11:26 CEST] <D404|Ghetto> seems to work right
[16:11:26 CEST] <D404|Ghetto> thanks
[16:11:32 CEST] <ubitux> you can save a label
[16:11:40 CEST] <D404|Ghetto> i tried without teh [c]
[16:11:40 CEST] <ubitux> 'scale=640:480,split=2 ...
[16:11:41 CEST] <D404|Ghetto> didnt work
[16:11:44 CEST] <D404|Ghetto> ah
[16:11:45 CEST] <D404|Ghetto> comma.
[16:12:04 CEST] <ubitux> ',' is for stacking
[16:12:16 CEST] <ubitux> ';' is for separating graph (you expect a source afterward)
[16:12:50 CEST] <ubitux> (or a connection)
[16:13:00 CEST] <D404|Ghetto> right
[16:13:37 CEST] <D404|Ghetto> ok... well vf_reverse worsk
[16:13:42 CEST] <ubitux> :o
[16:13:57 CEST] <D404|Ghetto> guess ill submit it and be flamed
[16:14:17 CEST] <ubitux> no, flaming happens after it gets pushed
[16:17:10 CEST] <D404|Ghetto> lol
[16:17:26 CEST] <D404|Ghetto> ubitux: lastly: is there a way to know clip length at init time
[16:17:38 CEST] <D404|Ghetto> or do i need to av_fast_realloc during queueing
[16:18:15 CEST] <ubitux> libavfilter is fully stream oriented, no duration
[16:18:21 CEST] <D404|Ghetto> thought no
[16:18:23 CEST] <D404|Ghetto> realloc it is
[16:18:24 CEST] <ubitux> (especially since filters can completely alter this)
[16:18:29 CEST] Action: D404|Ghetto uses ALL the memory
[16:20:39 CEST] <ubitux> D404|Ghetto: eval $(ffprobe -v error -select_streams v:0 -show_entries stream=duration -of flat=s=_ foreman_cif.y4m); echo $streams_stream_0_duration
[16:20:41 CEST] <ubitux> :p
[16:23:54 CEST] <D404|Ghetto> ubitux: i can do it in a script no problem
[16:23:59 CEST] <D404|Ghetto> i meant inside the filt
[16:24:00 CEST] <D404|Ghetto> ;)
[16:24:08 CEST] <D404|Ghetto> clearly tou want me to use system()
[16:24:10 CEST] <ubitux> yeah lavfi is too abstract for that
[16:24:12 CEST] <ubitux> haha
[16:45:59 CEST] <ubitux> D404|Ghetto: so, are you starting to fall in love with lavfi?
[16:51:49 CEST] <D404|Ghetto> no
[16:51:58 CEST] <D404|Ghetto> its the worst thing ive use to write a filter
[16:52:12 CEST] <D404|Ghetto> and b6 far the hardest 
[16:52:15 CEST] <D404|Ghetto> by*
[16:54:06 CEST] <cone-649> ffmpeg 03Tom Butterworth 07master:6074956fa1d2: avcodec/hap: move some per-stream setup into decoder init rather than per-frame
[16:57:42 CEST] <michaelni> BBB are the other 3 "avcodec/mips: MSA (MIPS-SIMD-Arch) optimizations for VP9 *" patches ok too ?
[16:57:51 CEST] <BBB> I dindt check them yet
[16:59:25 CEST] <cone-649> ffmpeg 03Paul B Mahol 07master:59a9998908d8: avfilter/af_astats: also measure maximal difference between two consecutive samples
[17:07:20 CEST] <BBB> michaelni: responding& not yet, I think
[17:11:22 CEST] <ubitux> D404|Ghetto: give it some time ;)
[17:16:11 CEST] <cone-649> ffmpeg 03Paul B Mahol 07master:51925daafda9: avfilter/af_astats: make sure p->last is actually always set when measuring max difference
[17:20:10 CEST] <BBB> all reviewed
[18:19:19 CEST] <jamrial> J_Darnley: the avx2 stuff you posted last night doesn't work
[18:19:27 CEST] <J_Darnley> yes I know
[18:19:33 CEST] <jamrial> you're not taking into consideration the split lane stuff from avx
[18:20:10 CEST] <J_Darnley> yes, I realised that when I saw which modes failed
[18:21:09 CEST] <J_Darnley> thanks for testing anyway
[18:29:27 CEST] <michaelni> BBB, thanks
[18:59:33 CEST] <D404|Ghetto> new filters require a minor bump right?
[19:03:38 CEST] <cone-649> ffmpeg 03Michael Niedermayer 07master:c4dfb76fa7e4: avfilter/vf_eq: Support contrast from -1000 to 1000
[19:04:48 CEST] <jamrial> D404|Ghetto: yeah
[19:05:10 CEST] <D404|Ghetto> ok
[19:07:35 CEST] <nevcairiel> well, "require"
[19:08:01 CEST] <D404|Ghetto> huh...
[19:08:09 CEST] <D404|Ghetto> [Parsed_concat_1 @ 0x1e5fc20] Buffer queue overflow, dropping.
[19:08:21 CEST] <D404|Ghetto> 'split=2[a][b];[a][b]concat,scale=640:480' 
[19:08:23 CEST] <D404|Ghetto> not valid?
[19:08:58 CEST] <durandal_1707> how much frames it cache?
[19:09:09 CEST] <D404|Ghetto> ?
[19:09:13 CEST] <D404|Ghetto> my filter isnt in there
[19:09:20 CEST] <D404|Ghetto> that i pasted is the entire filter chain
[19:09:33 CEST] <D404|Ghetto> [output stream 0:0 @ 0x1d029a0] 100 buffers queued in output stream 0:0, something may be wrong. <-- stuff like that
[19:11:11 CEST] <durandal_1707> You want to put same clip one after another?
[19:14:07 CEST] <D404|Ghetto> durandal_1707: it was a simple test
[19:14:09 CEST] <D404|Ghetto> and yes
[19:14:11 CEST] <D404|Ghetto> why would that fai;?
[19:14:13 CEST] <D404|Ghetto> fail*
[19:16:02 CEST] <durandal_1707> I'm not concat creator
[19:16:24 CEST] <D404|Ghetto> lol k
[19:16:56 CEST] <D404|Ghetto> i thought it might be a bigger lavfi issue
[19:21:15 CEST] <durandal_1707> better to use concat demuxer for this?
[19:21:42 CEST] <durandal_1707> Or perhaps you need to change pts
[19:26:15 CEST] <D404|Ghetto> wouldnt that be the conat filter's job
[19:26:18 CEST] <D404|Ghetto> concat*
[19:29:50 CEST] <durandal_1707> ask Nicolas I will prepare popcorn
[19:31:20 CEST] <D404|Ghetto> id rather not
[19:31:31 CEST] <D404|Ghetto> he's one of the people who it is pointless to argue with
[19:31:38 CEST] <D404|Ghetto> better off arging against a walll
[19:32:55 CEST] <wm4> the thought of arguing against a wall sounds relatively pleasing
[19:36:40 CEST] <nevcairiel> so i tried to migrate my fate boxes to msys2, and for some reason its base system doesnt have tar .. and now sf.net is down, which they are still hosted on, and i cannot install it, gah! :P
[19:37:05 CEST] <nevcairiel> how does a system with a package manager not have tar in its base system anyway
[19:37:35 CEST] <D404|Ghetto> lol.
[19:37:40 CEST] <D404|Ghetto> it shoukd have tar
[19:37:44 CEST] <D404|Ghetto> its package manager uses tar
[19:37:51 CEST] <D404|Ghetto> try gtar
[19:38:01 CEST] <jamrial> it doesn't? lol
[19:38:03 CEST] <nevcairiel> no tar, no gtar
[19:38:10 CEST] <jamrial> nevcairiel: add https://www2.futureware.at/~nickoe/msys2-mirror/msys2-$arch to mirrorlist.msys
[19:38:30 CEST] <jamrial> it's a backup mirror they added after sourceforge went rogue
[19:38:35 CEST] <jamrial> with taking over projects and such
[19:38:50 CEST] <nevcairiel> maybe they should add that to the base system
[19:39:01 CEST] <jamrial> it is. an update long ago added it
[19:39:24 CEST] <nevcairiel> actually its in there
[19:39:28 CEST] <nevcairiel> bu not worky
[19:39:38 CEST] <jamrial> oh well
[19:39:43 CEST] <nevcairiel> i tried to run a mirror update, and it destroyed everything, because it thinks the 404 page from sf is its mirror now
[19:39:52 CEST] <nevcairiel> dumb script :p
[19:40:48 CEST] <jamrial> haha, yeah, tried it now and same thing happened
[19:41:34 CEST] <nevcairiel> i hope it fixes itself once sf is back
[19:42:07 CEST] <jamrial> i can access https://www2.futureware.at/~nickoe/msys2-mirror/msys2-x86_64/ with a browser, but it gives a certificate warning
[19:42:29 CEST] <nevcairiel> its CACert
[19:42:39 CEST] <nevcairiel> not valid unless you install their root
[19:43:33 CEST] <nevcairiel> they should totally move off of sf.net, but apparently binary hosting without giving in to some kind of evil is hard
[19:46:51 CEST] <jamrial> you could just download the tar package manually, then force a reinstall with pacman at a later time once everything is working again
[19:47:13 CEST] <nevcairiel> its just fate submissions thats broken, i can just leave it like that for a couple hours
[19:47:14 CEST] <nevcairiel> :D
[19:48:16 CEST] <durandal_1707> D404|Ghetto: it doest work with split but does if you use two inputs
[19:48:27 CEST] <D404|Ghetto> durandal_1707: interesting
[19:48:34 CEST] <durandal_1707> twice -i -i
[19:48:58 CEST] <D404|Ghetto> right
[20:09:24 CEST] <BBB> D404|Ghetto: omg
[20:09:54 CEST] <BBB> I hope you have a script to do this per keyframegroup or so
[20:19:50 CEST] <D404|Ghetto> BBB: i do it only for the first N frames
[20:19:53 CEST] <D404|Ghetto> in a script
[20:20:05 CEST] <BBB> thats no fun at all
[20:20:06 CEST] <BBB> boo
[20:20:16 CEST] <D404|Ghetto> 'split[a][b];[a]trim=end_frame=N,reverse[c];[c][b]concat'
[20:20:20 CEST] <D404|Ghetto> kinda liek that
[20:26:29 CEST] <Compn> in the future i predict people will pay just for someone to write ffmpeg filter command lines, because they are complicated :P
[20:26:50 CEST] <D404|Ghetto> Compn: i am being paid to do this
[20:27:01 CEST] <D404|Ghetto> so... there's taht.
[20:27:01 CEST] <Compn> i can see the footure
[20:39:13 CEST] <durandal_1707> I guess its time for areverse then
[20:58:50 CEST] <durandal_1707> but really why nobody does seeking in lavfi it shouldn't be hard
[21:03:16 CEST] <ubitux> durandal_1707: how do you raise the seek request up to the user?
[21:03:32 CEST] <ubitux> and how do you make sure the seek is properly satisfied?
[21:07:47 CEST] <durandal_1707> you don't if its not seekable just abort
[21:08:41 CEST] <BBB> welcome to gstreamer
[21:08:45 CEST] Action: BBB runs
[21:20:40 CEST] <Compn> mplayer has had seeking and filters working since 10 years , no one cares :P
[21:24:58 CEST] <cone-649> ffmpeg 03Tom Butterworth 07master:17ee24af7e5f: avcodec/snappy: refactor so ff_snappy_uncompress uses an existing buffer
[21:25:08 CEST] <durandal_1707> mplayer is dead
[21:39:14 CEST] <ubitux> Compn: the question is how you seek within filters; obviously seeking is supported above
[21:39:36 CEST] <ubitux> i mean even ffplay does it; you just need to reconfigure/flush the filtergraph before pushing shit in the pipeline again
[21:43:28 CEST] <cone-649> ffmpeg 03Ivan Uskov 07master:6e127990fa9e: Refactoring to move common QSV-related code part into libavcodec/qsvdec.c
[21:58:07 CEST] <D404|Ghetto> damn i hate gmail's web interface
[21:58:16 CEST] <D404|Ghetto> it hit backspace after hilighting -> back button 
[21:59:05 CEST] <thardin> use a real mail client
[21:59:26 CEST] <D404|Ghetto> i do
[21:59:29 CEST] <D404|Ghetto> i have no internet
[21:59:37 CEST] <D404|Ghetto> thus no server with my mua
[22:00:37 CEST] <BBB> what is this mplayer thing people keep talking about, is it like the iphone?
[22:01:19 CEST] <D404|Ghetto> no its more like symbian
[22:02:39 CEST] <D404|Ghetto> apologies if gmail fucks up the threading
[22:03:18 CEST] <BBB> apologies if my gun kills a kitten
[22:03:28 CEST] <BBB> dont blame the tool, blame the user :-p
[22:06:27 CEST] <D404|Ghetto> it's web ui is incredibly clunky at best
[22:06:29 CEST] <D404|Ghetto> its*
[22:06:47 CEST] <D404|Ghetto> if i coat your gun in cooking grease, and you drop it, and it kills a kitten
[22:06:50 CEST] <D404|Ghetto> maybe it's more similar ;)
[22:07:34 CEST] <BBB> :-p
[22:10:11 CEST] <D404|Ghetto> why am i looking at a 4k gif from ubitux 
[22:10:15 CEST] <D404|Ghetto> what am i even doing with my life
[22:11:24 CEST] <wm4> 4K gifs are the future
[22:11:24 CEST] <beastd> D404|Ghetto: Haha, though some thing really similar couple of minutes ago :)
[22:13:49 CEST] <D404|Ghetto> ;p
[22:46:09 CEST] <philipl> 4k? better hope we get hard-accelerated gif decoding.
[22:46:17 CEST] <philipl> hardware accelerated. bah
[22:46:20 CEST] <BBB> D404|Ghetto: you can do better things with your life, but thats a personal choice
[22:47:42 CEST] <BBB> when are you next in NY?
[22:49:23 CEST] <D404|Ghetto> np idea. maybe sep or oct
[22:49:33 CEST] <D404|Ghetto> im traveling all sep
[22:49:38 CEST] <D404|Ghetto> and part of aug
[22:49:50 CEST] <BBB> vdd then I guess?
[22:55:21 CEST] <JEEB> when was VDD again?
[22:55:56 CEST] <j-b> Sept 18-20
[22:56:59 CEST] <D404|Ghetto> yes
[22:57:17 CEST] <JEEB> gotcha
[22:58:34 CEST] <BBB> does j-b have a notification set for the keyword vdd?
[22:58:49 CEST] <nevcairiel> probably
[22:59:18 CEST] <j-b> yes
[22:59:33 CEST] <j-b> doing elsewise would be stupid.
[23:00:23 CEST] <BBB> j-b: do you know specific location? (I couldnt find it in any previous email) - would be useful for hotel booking
[23:00:37 CEST] <j-b> nope, that's the issue
[23:00:52 CEST] <BBB> ?
[23:02:22 CEST] <BBB> this doesnt sound good
[23:02:36 CEST] <BBB> what do you need? money? or just an empty space for day 19-20?
[23:03:38 CEST] <j-b> everythign :)
[23:04:43 CEST] <BBB> I know I want everything also
[23:04:48 CEST] <BBB> but what specifically do you need?
[23:06:19 CEST] <j-b> I need people to answer emails :)
[23:06:24 CEST] <j-b> and money would be nice
[23:37:18 CEST] <rcombs> ubitux: so, lavc/srtdec's unknown-tag behavior is kinda weird right now
[23:40:01 CEST] <rcombs> ubitux: unknown open tags end up dropped, but unknown unmatched close tags are passed through
[23:40:29 CEST] <rcombs> or, wait, no, both get passed through unchanged
[23:41:10 CEST] <rcombs> is this expected behavior? do actual SRT files require it? do other parsers handle this the same way?
[23:43:34 CEST] <rcombs> and then, when encoding WebVTT, we should probably escape <>s in the input
[23:45:12 CEST] <rcombs> which would mean moving `xml_escape_str` from ffprobe.c to lavu
[00:00:00 CEST] --- Fri Jul 17 2015