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

[burek]

[01:18] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:bd8d28e2d271: avcodec/hnm4video: check dimensions for validity
[01:18] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:5c4aa72b75c1: avformat/hnm: check chunk_size == 0
[01:18] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:ffe31c654d0e: avcodec/hnm4video: check writeoffset in decode_interframe_v4a()
[01:28] <llogan> how can i get access to files in upload.ffmpeg.org?
[01:33] <BBB> hah it compiles
[01:33] <BBB> that's about time
[01:33] <BBB> ofc it crashes, but that's fixable
[01:39] <beastd> BBB: congrats!  keep on going :)
[03:01] <Compn> hmmm llogan
[03:01] <Compn> i thought i sent him infos
[09:58] <cone-821> ffmpeg.git 03Reimar Döffinger 07master:97a0bad87c8d: Add --enable-rpath option to add -Wl,-rpath to pkg-config files.
[12:18] <cone-821> ffmpeg.git 03Diego Biurrun 07master:c16bfb147df8: swscale: x86: Consistently use lowercase function name suffixes
[12:18] <cone-821> ffmpeg.git 03Michael Niedermayer 07master:8733b363ac3b: Merge commit 'c16bfb147df8a9d350e8a0dbc01937b78faf5949'
[13:29] <ubitux> i don't understand this vdpau thing&
[13:30] <ubitux> why isn't it an output device like sdl & xv?
[13:30] <ubitux> also, what's the use case?
[13:31] <nevcairiel> what vdpau thing
[13:31] <ubitux> what has just been comitted to avconv
[13:31] <nevcairiel> oh that
[13:31] <ubitux> vdpau "decoding"
[13:31] <ubitux> but with x11 stuff
[13:31] <nevcairiel> isnt that just an implementation of the hwaccel
[13:32] <ubitux> there are 2 things about vdpau; decoding, and presentation, right?
[13:32] <nevcairiel> primary motiviation was being able to test hwaccels
[13:32] <nevcairiel> no idea
[13:32] <ubitux> this one seems to be about presentation
[13:33] <ubitux> well i don't even get how it works, so i'll wait for the merge
[13:34] <nevcairiel> i dont know stuff about vdpau, but it looks like it does about the same things you would do when you implemented dxva hwaccel decoding
[13:35] <ubitux> it looks like something that belongs in ffplay to me but well
[13:36] <nevcairiel> such APIs usually require an X session to function, which is where the X11 stuff comes in i guess
[13:36] <ubitux> we already have some accelerated *decoding* through the <codec>_<accel>
[13:36] <ubitux> ok
[13:36] <nevcairiel> those codecs are ugly hacks and shouldnt exist
[13:36] <ubitux> ah, they're meant to be replaced by this new thing?
[13:37] <nevcairiel> i dunno, since libav doesnt really have th em
[13:37] <ubitux> they do
[13:37] <ubitux> at least they show up with ./configure --list-hwaccels
[13:37] <nevcairiel> and what was added here just makes use of those hwaccels
[13:38] <nevcairiel> since you cant just enable it without user-app code to handle it
[13:38] <nevcairiel> or well, of one hwaccel
[13:39] <nevcairiel> which is why the hwaccels are generally never tested properly
[13:39] <nevcairiel> since no native ffmpeg/libav tool supported them
[13:41] <ubitux> mmh
[13:42] <cone-821> ffmpeg.git 03Tim Walker 07master:b53285462263: ac3: implement request_channel_layout.
[13:42] <iive> one of hwaccel work like parsers. the applications links to x11, allocates buffers, the avcodec just parses packets and extrancts the relevant bitstreams.
[13:42] <cone-821> ffmpeg.git 03Michael Niedermayer 07master:2e5780a53f43: Merge commit 'b53285462263ef8a795f0e289abd5799b4c57652'
[13:42] <cone-821> ffmpeg.git 03Michael Niedermayer 07master:2cbf27b08a49: libavcodec/ac3dec: fix channel_layout
[13:42] <ubitux> indeed, it seems i can't naively do ffmpeg -c:v h264_vdpau -i foobar.mp4 -f null -
[13:43] <iive> other hwaccel (vaapi i think) do the allocation on their own, this however means that avcodec should link to X and call X functions.
[13:43] <nevcairiel> i thought that might still work, since michael didnt merge the removal of the old vdpau decoders
[13:43] <ubitux> i have some decoding errors here
[13:43] <ubitux> "no frame!"
[13:43] <ubitux> "decode_slice_header error"
[13:43] <nevcairiel> hm, i dunno, no idea if it needs user app code as well
[13:43] <ubitux> and various other errors following
[13:44] <nevcairiel> there are others that can work out of the box
[13:44] <iive> now, some of the hwaccels can do the decoding on card, then read it back to the system memory. 
[13:44] <nevcairiel> vda i think has one
[13:44] <iive> some don't.
[13:44] <nevcairiel> but they really shouldnt exist
[13:44] <ubitux> all that hwaccel stuff looks quite messy :)
[13:44] <nevcairiel> either the user app should make use of the AVHWAccel, or someone should propose a HWAccel v2 that takes care of all plumbing as well
[13:44] <ubitux> btw, somehow unrelated, how hard is the move from sdl to sdl2?
[13:45] <ubitux> (wondering about our ffplay)
[13:46] <iive> i though the plan is putting the X functions into libavdevice, It already handles X functions and it could be provided as default allocation/decoding for the applications.
[13:46] <ubitux> http://wiki.libsdl.org/MigrationGuide mmh
[13:46] <wm4> ubitux: yeah that stuff was supposed to test hwaccel
[13:47] <wm4> ubitux: and for testing it's probably also better to actually read the decoded data back to memory
[13:47] <wm4> so you can verify the results
[13:47] <wm4> hacking vdpau display into ffplay would probably be half a nightmare
[13:48] <wm4> and the old pseudo decoders like vdpau_h264 were indeed removed from Libav, but not from ffmpeg
[13:48] <wm4> no idea why
[13:48] <wm4> they're redundant
[13:48] <ubitux> i see them in libav
[13:48] <wm4> they just have a slightly different API
[13:48] <wm4> where
[13:48] <ubitux> maybe it was an old checkout, just a sec
[13:48] <wm4> hm or was it h264_vdpau
[13:48] <iive> well, in case you want to have vdpau decoding that outputs yuv420 raw image, how are you going to do it?
[13:49] <ubitux> wm4: 13:37:38 <@ubitux> at least they show up with ./configure --list-hwaccels
[13:49] <wm4> iive: do the same thing as avconv just did
[13:49] <wm4> iive: and in general, this is completely useless and slow
[13:49] <wm4> for video conversion uses I mean
[13:49] <iive> ??
[13:49] <wm4> ubitux: ok, hwaccel != pseudo decoder
[13:49] <wm4> as in AVCodec
[13:49] <wm4> iive: ???
[13:49] <iive> please explain.
[13:50] <wm4> what's there to explain
[13:50] <wm4> it's just slow
[13:50] <wm4> slower than software decoding, usually
[13:51] <iive> well, it is not done by the cpu, so more cpu for the encoder :P
[13:51] <cone-821> ffmpeg.git 03Tim Walker 07master:d4df02131b55: ac3dec: Remove write-only channel_layout field from AC3DecodeContext
[13:51] <cone-821> ffmpeg.git 03Michael Niedermayer 07master:94194bdcd7bf: Merge commit 'd4df02131b5522a99a4e6035368484e809706ed5'
[13:51] <wm4> iive: it also lets the cpu wait
[13:52] <wm4> well, not sure, maybe ffmpeg has some multithreading weirdness so that this won't matter
[13:52] <wm4> but all in all supporting readback seems to be rather questionable
[13:52] <wm4> so it's fine if this is not natively supported by libavcodec
[13:53] <iive> well, there is no reason for the readback to be slow. Unless the raw image is in nv12 form in the card and the drivers do naive nv12->yv12 conversion.
[13:53] <iive> pcie bandwidth is big enough in both directions, afaik
[13:54] <wm4> there are various reasons why this would be slow
[13:54] <wm4> including hw decoders made for realtime use, not for being as fast as possible
[13:54] <wm4> +being
[13:54] <wm4> but yeah, this exposed pathetic libswscale speed for nv12->yv12
[13:55] <ubitux> this should be fixed
[13:55] <wm4> patches welcome
[13:55] <ubitux> no i mean, it's fixed
[13:55] <iive> as I said, you don't need it to be fast, in order to be useful. There are just too many presumptions based on the current perks, that could be easily improved.
[13:55] <wm4> didn't elenril complain it's still slow?
[13:55] <iive> i though michael fixed it.
[13:55] <ubitux> wm4: dunno
[13:55] <iive> the swscale conversion. I remember some commits for nv12/21
[13:56] <wm4> also I remember mentioning this idea (testing hwaccel through readback) with reimar on the mailing list, and he considered it not useful for multiple reasons
[13:56] <wm4> ubitux, iive: yes AFAIK elenril used these patches
[13:57] <wm4> iive: when we implemented proper vda support (native display instead of readback via the ffmpeg "decoder") we actually observed 2-2.5x reduction in CPU usage
[13:57] <wm4> I mean, implemented it in mpv
[13:57] <wm4> ffmpeg has a proper vda hwaccel
[13:59] <iive> once again. this is not theoretical limitation.
[14:01] <iive> pcie bandwidth should have same in both directions. This means that it should take the same cpu utilization to upload yv12 image, as it is to read a raw image to the card.
[14:01] <wm4> I don't think it's that simple
[14:01] <iive> if there is such huge slowdown, then it is probably driver issue, that tries a naive conversion.
[14:01] <wm4> GPU memory is a weird thing
[14:01] <wm4> for example, I'm pretty sure vdpau/nvidia stores video internally as separate fields, and probably even in a tiled way
[14:02] <iive> this could be improved by the driver.
[14:02] <iive> well... then swscale would support tiled formats too.
[14:02] <pigoz> wm4: iirc ffmpeg's vda decoder also does a memcpy
[14:02] <pigoz> so readback + memcpy
[14:04] <iive> look. it is ok to don't use a feature that is slow.
[14:05] <iive> it is not OK to design an API in a way that doesn't allow that feature at all. especially when there is no theoretical reason for it to be slow. (Some features are slow on theory too...).
[14:05] <wm4> what if it's slow in practice
[14:06] <iive> then, find out why it is slow in practice.
[14:08] <iive> sometimes it is slow, because nobody uses it. if you don't use it, it would never be optimized. 
[14:08] <wm4> sigh
[14:09] <wm4> nobody would introduce such complicated APIs like they did with hardware decoding if the easier way (i.e. readback) would have been just as fast
[14:09] <wm4> but it's designed this way because shuffling memory from the GPU to the CPU is inherently slow
[14:10] <iive> it is not just as fast. because in the best case it involves 2 memcpy. one from the card and one to the card.
[14:10] <iive> it doesn't mean it is not useful.
[14:11] <pigoz> iive: it is slow because whoever contributed to mplayer's is misguided and just wants their gui to work with shitty mmap. since they need readback anyway, they thought it was a good idea.
[14:11] <pigoz> in practice it's so wasteful that software decoding is almost as fast!
[14:40] <cone-821> ffmpeg.git 03Anton Khirnov 07master:07fd0a221928: avconv: add infrastructure for using hwaccels
[14:40] <cone-821> ffmpeg.git 03Michael Niedermayer 07master:62e10c375968: Merge commit '07fd0a22192805d56c635eb294dc26b0a54ae325'
[14:52] <cone-821> ffmpeg.git 03Anton Khirnov 07master:7671dd7cd7d5: avconv: add support for VDPAU decoding
[14:53] <cone-821> ffmpeg.git 03Michael Niedermayer 07master:3e641b4842b8: Merge commit '7671dd7cd7d51bbd637cc46d8f104a141bc355ea'
[15:00] <cone-821> ffmpeg.git 03Alexandra Khirnova 07master:6f270da61b8c: libschroedingerenc: do not assert on values from external libraries
[15:00] <cone-821> ffmpeg.git 03Michael Niedermayer 07master:f63ee2aa14ec: Merge remote-tracking branch 'qatar/master'
[17:05] <ubitux> meh #2835 is fun
[17:13] <ubitux> -hwaccel none ’ 530 fps
[17:13] <ubitux> -hwaccel vdpau ’ 50 fps
[17:13] <ubitux> fun
[17:21] <ubitux> it crashes if hwaccel can not be initialized
[17:24] <wm4> anton already has a patch for this
[17:30] <ubitux> it's not an assert
[17:31] <ubitux> it doesn't happen all the time (threading related)
[17:32] <ubitux> http://pastie.org/pastes/8503519/text
[17:33] <nevcairiel> its possible threading with hwaccel is broken in ffmpeg, i dont think it was ever tested
[17:34] <ubitux> mmh?
[17:35] <nevcairiel> the real question however is, why is exit_program being called from a frame worker thread? :p
[17:35] <nevcairiel> that seems like bad karma
[17:38] <ubitux> it's hard to reproduce with valgrind
[17:38] <ubitux> it happens with libav as well
[17:43] <wm4> nevcairiel: supposedly, vlc uses threading + hwaccel just fine
[17:44] <wm4> mplayer also tries to do, but its code is literally full of hacks, including comments that curse libavcodec's threading behavior
[17:45] <nevcairiel> comments which are probably completely out of date now
[17:45] <wm4> likely
[17:59] <cone-821> ffmpeg.git 03James Zern 07master:6819eaf31bf8: libvpxdec: set CODEC_CAP_DR1 for vp9
[17:59] <cone-821> ffmpeg.git 03James Zern 07master:34e32d646413: libvpxenc: update cpu-used default
[18:22] <rexbron> Does ffmpeg copy over all metadata from a Broadcase Wave file when trimming? Timecode and Frame Rate from a Sound Devices 664T got stripped out. It show up in ffprobe but -codec:a copy only seems to carry over some of it. Would uploading a sample of the input and output to the tracker be helpful?
[18:27] <JEEB> there was IIRC a way to force ffmpeg to copy over all metadata as well, codec:a copy should have copied all of the in-band actual audio data
[18:30] <rexbron> JEEB: I'll file a bug on the tracker
[18:31] <JEEB> try the full metadata copy at first
[18:31] <JEEB> since -c/codec:a doesn't really touch that
[18:32] <rexbron> JEEB: I'm not familiar with how to do that
[18:33] <JEEB> -map_metadata <number of the input>
[18:34] <JEEB> as far as I can see
[18:36] <rexbron> JEEB: Same results
[18:36] <JEEB> k
[18:36] <rexbron> I wonder if it is because the wav muxer doesn't support the writting of those fields yet
[18:37] <JEEB> anyways, search for similar issues on trac, and if there's none feel free to report it with a sample
[18:37] <JEEB> possibly
[18:38] <rexbron> hmm, well it shows up in the output metadata of the encoding ffmpeg command, but ffprobe doesn't see it and neither does Davinci Resolve
[18:42] <rexbron> ffprobe also sees the metadata in the original file
[18:46] <rexbron> what is the ffmpeg ftp server for samples? Trac limits attachments to 2.5mb
[18:50] <wm4> apropos wav, is ac3 in wav standard?
[18:50] <wm4> especially if it uses the same format tag as s16?
[19:05] <kierank> yes
[19:05] <kierank> it's designed to go over spdif or aes3
[19:05] <kierank> neither of those cables have any concept of data format
[19:05] <kierank> they just send out stereo bytes
[19:05] <kierank> s/bytes/pairs
[19:06] <JEEB> btw, how does lavf/lavc handle possible spdif content muxed into a PCM audio track?
[19:07] <wm4> kierank: interesting and disgusting
[19:07] <JEEB> can I just push it out of the demuxer as PCM, or do I have to do something special?
[19:07] <wm4> yes that would be interesting to know
[19:07] <kierank> should work as pcm
[19:07] <JEEB> ok
[19:07] <kierank> alignment is important though
[19:08] <JEEB> then I can pretty much rewrite the earthsoft dv demuxer stuff compared to the Japanese guy's patch
[19:08] <JEEB> because he had some really funky checks in the demuxer for various spdif'd stuff
[19:08] <JEEB> (IIRC unrelated to alignment)
[19:09] <kierank> alignment is effectively the pts
[19:09] <JEEB> alrighty
[19:11] <JEEB> oh right, the demuxer tries to extract it I think... :| not something I'd do in the demuxer to be honest if lavc in general can handle it
[19:11] <JEEB> /* search for IEC 61937 Burst-preamble */
[19:11] <JEEB> etc.
[19:12] <wm4> well, the demuxer has to signal the correct codec
[19:12] <wm4> because on the decoder side, it's too late for that
[19:13] <JEEB> ok, so "should work as pcm" doesn't mean that
[19:13] <wm4> AFAIK not, if you're talking about what AVStream->codec will identify
[19:59] <kierank> JEEB: yes the burst preamble is what signals the codec
[19:59] <kierank> lavc can't deal with it
[19:59] <JEEB> ok
[21:07] <cone-984> ffmpeg.git 03Michael Niedermayer 07master:321b33876262: avcodec/hnm4video: allocate frame only when theres a coded frame
[21:07] <ubitux> HOSTCC	doc/print_options.o
[21:07] <ubitux> HOSTCC? really? oO
[21:14] <ubitux> BBB: since the dc-only patch, most of the time is spent in 32x32 and the loop filters
[21:14] <ubitux> they really are slow
[21:14] <ubitux> i'm almost tempted to look at them :p
[21:23] <ubitux> BBB: i'm going to start on lf instead of idct 16
[21:43] <ubitux> BBB: http://b.pkh.me/0001-avcodec-vp9dsp-remove-unused-stride-parameter-in-loo.patch opinion?
[21:55] <wm4> why are people trying to coerce a muxer API into a video player output API
[21:55] <wm4> his deserves the "fucking retarded" label
[21:55] <wm4> +this
[21:57] <Plorkyeran> playing and muxing are conceptually vaguely similar things
[21:57] <Plorkyeran> and programmers love reusing abtractions
[22:02] <BBB> ubitux: sure
[22:03] <BBB> ubitux: and yes 32x32 I know
[22:03] <ubitux> BBB: so what's the trick with lf?
[22:03] <ubitux> i'm looking at loop_filter_h_4_8()
[22:03] <BBB> ubitux: to make things slightly easier for us to develop step-by-step, I was considering the following: have a (non-vp9dsp) set of function ptr tables that take a VP9DSPContext argument, and then have them select which specialization to take
[22:03] <ubitux> the c version looks like this: http://pastie.org/8503989
[22:04] <BBB> the default implementation for dc-only would be your specialcase code, and for all other cases the current c base full versions
[22:04] <BBB> but then we could easily specialize a 2x2 32x32 or 4x4 16x16 without needing to dig our eyes out to complete all assembly before it can be committed
[22:04] <BBB> that would help e.g. with writing a super-fast ssse3 dc-only for all
[22:04] <BBB> that would speed up 16x16 and 32x32 by a lot also
[22:05] <BBB> and a 2x2 and 4x4 does cover most practical 32x32 cases
[22:05] <BBB> we can leave the rest as C then
[22:05] <BBB> wdyt?
[22:05] <BBB> the trick with lf is: do the vertical filter (horizontal edge between a top/bottom block) first
[22:05] <ubitux> will the dc only really benefit from the asm versions?
[22:06] <BBB> no they all will
[22:06] <BBB> but the dc is easier to write
[22:06] <BBB> I'm trying to get stuff out faster rather than slower, and adjust code/development to that end
[22:06] <BBB> then the filter: you'll notice there's 8px 4/8/16wd versions
[22:06] <ubitux> main benefit of this would be to ease the writing of those functions
[22:07] <ubitux> so i'm not against
[22:07] <BBB> these are not called often but meant for mmx or so
[22:07] <BBB> then there's 16px functions, same idea
[22:07] <BBB> they are 16wd, or a mix2 of 4/4 or 8/8 or 4/8 or 8/4 wd
[22:07] <ubitux> right
[22:07] <BBB> that's because edges between these types of lfs only have a length of 8px
[22:08] <BBB> so we merge 2 so we can do sse2/ssse3 (16byte) registers
[22:08] <BBB> do everything in bytes, obviously
[22:08] <BBB> ignore 8px maybe, focus on 16px first (maybe 4wd)
[22:08] <BBB> and you'll see it's not hard to do it without stack on x86-64
[22:09] <BBB> 8wd is basically 'do some threshold trick to see whether we do 8wd or 4wd loopfilter' (i.e. 4wd is a strict subset of 8wd)
[22:09] <BBB> runtime selected
[22:10] <ubitux> ETOOMUCHINFO
[22:10] <ubitux> just a sec
[22:10] <BBB> oh
[22:10] <BBB> well, start with 4/4wd 16px
[22:10] <BBB> it's easy
[22:10] <BBB> or, well, about as easy as a loopfilter will ever get
[22:11] <ubitux> i was ignoring the 16 and mix2 so far
[22:11] <ubitux> since 16 was calling 8
[22:11] <BBB> that's just a c'ism
[22:11] <BBB> ignore c, it's stupid
[22:11] <ubitux> mmh
[22:12] <BBB> I prepared it that way for asm purposes
[22:12] <BBB> sse2/ssse3 is 16bytes right
[22:12] <BBB> so we want to do 16 bytes (if 1 byte is 1 pixel) per call to the simd function
[22:12] <BBB> that's why we mix 2
[22:12] <ubitux> but, the 8 versions are supposed to be called as well, right?
[22:12] <BBB> yes, but not as often
[22:12] <BBB> look at the backtrace of the callers
[22:13] <ubitux> oh indeed
[22:13] <BBB> most of the time, the backtrace of 8 is 16
[22:13] <BBB> once in a while, it's mix2
[22:13] <BBB> very rarely is it called in and by itself
[22:13] <BBB> that's expected, it makes sense for non-random noise content
[22:14] <BBB> (non-'random noise')
[22:14] <ubitux> ok
[22:14] <ubitux> al'right, so i need to focus on 16 directly
[22:16] <ubitux> 22:08:19 <@BBB> do everything in bytes, obviously // what do you mean? no simd?
[22:16] <ubitux> oO
[22:16] <BBB> byte-wise simd
[22:16] <BBB> i.e. use all byte instructions
[22:16] <BBB> paddb, paddusb, etc.
[22:16] <ubitux> ah, ok
[22:17] <ubitux> that's cool if i can do that :)
[22:17] <BBB> that way you can do it loopless
[22:21] <cone-984> ffmpeg.git 03Clément BSsch 07master:bea93944653f: avcodec/vp9dsp: remove unused stride parameter in loop_filter().
[22:21] <ubitux> ok
[22:22] <ubitux> let's try this then
[22:22] <BBB> \o/
[22:22] <BBB> I have an almost-working patch for mt
[22:22] <BBB> that is, it works in single-threaded mode
[22:22] <ubitux> haha
[22:22] <BBB> (I know, that sounds entirely useless)
[22:22] <BBB> (but really, it's quite something IMO)
[22:23] <ubitux> :)
[22:30] <ubitux> BBB: v version will be calling h version with a transpose?
[22:30] <ubitux> or they will be more
[22:30] <ubitux> ?
[22:31] <BBB> exactly right
[22:31] <BBB> I don't know how we'll do a 16x16 transpose btw
[22:31] <BBB> but we'll figure that out
[22:31] <BBB> probably 2x16x8 or so
[22:32] <BBB> or maybe imaginatively speaking it's not that hard, never thought much about it
[22:52] <durandal_1707> gmake: *** No rule to make target ibavcodec/dct32_fixed.o'.  Stop.
[22:53] <durandal_1707> gmake: *** No rule to make target `libavcodec/dct32.c', needed by `libavcodec/dct32_fixed.o'.  Stop.
[22:55] <ubitux> durandal_1707: the dependency thing again
[22:55] <ubitux> you need to make distclean / git clean -fdx
[22:56] <ubitux> or just edit/drop the .d
[22:59] <nevcairiel> I dont get why people  dont just clean when they get such an error instead of complain
[23:00] <durandal_1707> i dont get why people change stuff
[23:02] <nevcairiel> we should totally stop developing, change is bad!
[23:03] <durandal_1707> developing is not K&R
[23:05] <ubitux> nevcairiel: re-running configure should be enough, but it doesn't work
[23:05] <ubitux> those rename are a pita
[23:06] <nevcairiel> configure doesnt generate d files, make does, but it fails at tracking changes to its own make files
[23:08] <lukaszmluki> Hi, is Stefano online?
[23:09] <ubitux> he left a few hours ago (nickname: saste)
[23:09] <nevcairiel> he doesnt appear to be here right now
[23:09] <lukaszmluki> maybe some else know... he mentioned "custom widget filter", do you know what it is?
[23:10] <ubitux> which thread?
[23:10] <lukaszmluki>  Move ffplay engine to separate library, 7th post
[23:12] <durandal_1707> ffprobe.c:348:15: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides]
[23:17] <ubitux> lukaszmluki: i guess he just invented a name for this potential special purpose filter
[23:18] <lukaszmluki> so it doesn't exist yet? :D
[23:18] <ubitux> yes, it seems to be your job :)
[23:19] <lukaszmluki> ok, i'll try to catch him tommorow to confirm that, but I greped and nothing similar to it found :]
[23:19] <lukaszmluki> ok, thx
[23:25] <cone-984> ffmpeg.git 03Paul B Mahol 07master:638d79a9d080: ffprobe: use designated initializer for AVClass
[23:36] Action: BBB agrees with durandal_1707 
[23:37] <BBB> I don't care about whether people do k&r or not, but please let's not call it development
[23:37] <Daemon404> let's not call it k&r
[23:37] <ubitux> let's not
[23:37] <BBB> diego&r?
[23:37] <ubitux> diego&luca&koda
[23:44] <lukaszmluki> what is k&r?
[23:57] <{V}> lukaszmluki, Kernighan and Ritchie probably.
[00:00] --- Sun Nov 24 2013