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

[burek]

[00:39] <ubitux> oh, ronald is fwd'ing patches to ffmpeg :o
[00:39] <ubitux> it seems it's the patch creating so much flame on libav though
[00:40] <durandal_1707> what patches?
[00:40] <kierank> probably because google want it in ffmpeg
[00:40] <durandal_1707> just reply with NAK.
[00:40] <Daemon404> durandal_1707, thats a shitty attitude.
[00:40] <ubitux> well it will be in the next merge if libav accepts it
[00:41] <durandal_1707> Daemon404: i was not serious
[00:41] <ubitux> the patch is mangled anyway ;)
[00:41] <Daemon404> durandal_1707, oh ok
[00:41] <Daemon404> i cant tell anymore
[00:41] <Daemon404> :(
[00:42] <ubitux> :)
[00:44] <ubitux> beastd: hey i was wondering; what is the fate.txt output good for?
[00:44] <Daemon404> wanst fate.txt supposed to me rm'd
[00:44] <ubitux> it's actually outputed from the .texi
[00:44] <beastd> ubitux: it is for when you want to use less or an editor to view the fate documentation
[00:45] <Daemon404> OOo
[00:45] <ubitux> isn't the texi readable enough?
[00:46] <ubitux> well, doesn't matter much
[00:46] <beastd> ubitux: not sure. anyway it is cheap to generate the text file from the texi. i mean texi is meant to be used for multiple output formats
[00:46] <ubitux> sure, i was just confused to see only this one
[00:47] <beastd> ubitux: i came up with the idea because we had fate.txt for a long time. just moving it to texi and not providing a replacement seemed unnneeded and harsh to me
[00:48] Action: beastd doesn't remember exactly how things were happening back then
[00:48] <ubitux> i think no one really care, but ok
[00:49] <Daemon404> im sorta wondering why something liek fate needs local documentation
[00:49] <Daemon404> the adding to fate part i mena
[00:49] <Daemon404> mean*
[00:49] <beastd> Daemon404: not sure I understand you?
[00:49] <ubitux> it centralizes the info?
[00:49] <ubitux> wiki = lost
[00:49] <Daemon404> if youre looking to add a server to fate
[00:50] <Daemon404> you have internet
[00:50] <Daemon404> and can visit ffmpeg.org/fate.hmtl
[00:50] <Daemon404> html even
[00:50] <CIA-119> ffmpeg: 03Ronald S. Bultje 07master * r17fad33f81 10ffmpeg/ (7 files in 3 dirs): (log message trimmed)
[00:50] <CIA-119> ffmpeg: Change all uses of restrict to use av_restrict instead.
[00:50] <CIA-119> ffmpeg: Defining restrict results - for some compilers - in changing other
[00:50] <CIA-119> ffmpeg: uses of the restrict keyword also, e.g. __declspec(restrict) gets
[00:50] <CIA-119> ffmpeg: changed to __declspec(__restrict) on MSVC. This causes compilation
[00:50] <CIA-119> ffmpeg: failures. Therefore, using a private namespace macro instead is
[00:50] <CIA-119> ffmpeg: more reliable and robust.
[00:50] <ubitux> lol
[00:51] <ubitux> michaelni: did you read the opposition to that patch on the libav ml?
[00:51] <ubitux> they have some good points against this
[00:51] <beastd> Daemon404: This is mixing up a lot of things. I am not sure I want to explain. But if you want to listen I will write up 3 senteces or 4.
[00:51] <Daemon404> nah
[00:51] <Daemon404> im just musing out loud
[00:53] <michaelni> ubitux, please explain what issue you see with the patch ?
[00:53] <michaelni> i mean the one applied
[00:53] <beastd> ubitux, michaelni: which patch?
[00:53] <ubitux> michaelni: restrict is part of the standard, not a compiler specific thing
[00:53] <michaelni> <CIA-119> ffmpeg: Change all uses of restrict to use av_restrict instead.
[00:54] <beastd> ah, ronald's msvc patches?
[00:54] <michaelni> beastd, yes
[00:55] <michaelni> ubitux, yes but i dont understand where this is causing a problem or making a difference ?
[00:56] <ubitux> not sure, i was just reading quickly and saw some furious opposition
[00:56] <ubitux> it's not like i have an opinion on this yet
[00:56] <ubitux> i was just checking if you saw them
[00:57] Action: beastd just thought read those patches
[00:57] Action: durandal_1707 awaits fate results
[00:57] <michaelni> if it breaks ill revert or fix it but i didnt see any obvious issue in the patch ive applied
[00:58] <michaelni> and its a step toward MSCV support which is a good thing, some people want that and not that few
[00:58] <ubitux> yes sure
[00:58] <ubitux> ok :)
[01:00] <beastd> I did not yet read the discussion on libav. But at a first glance the restricted patch looked good to me. Not sure about the other one, seems contradicting to the spirit of the 1st.
[02:20] <iive> mans agreed on msvc support?! I want to see that.
[02:24] <Daemon404> its pretty hard to argue against it
[02:24] <Daemon404> without resorting to teh Freedom Enforcement Squad
[02:26] <ohsix> it's pretty hard to argue for it
[02:26] <ohsix> ffmpeg on sdcc! ffmpeg on lcc! we demand satisfaction
[02:27] <Daemon404> you do realize all teh biggest distributers of fmpeg use msvc, except vlc
[02:27] <ohsix> doesn't that indicate that they should be interested in it?
[02:28] <Daemon404> i was giving you a reason in favour of msvc support
[02:28] <Daemon404> since: [20:26] < ohsix> it's pretty hard to argue for it
[02:28] <ohsix> that's a reason "the distributors" might care, not a reason everyone else should
[02:28] <Daemon404> thats a pretty flawed atititude
[02:29] <ohsix> they need to support it :>
[02:29] <Daemon404> and google/chrome are the ones who are writing it
[02:29] <Daemon404> so uh
[02:29] <ohsix> nope, there are a finite amount of people to care
[02:29] <Daemon404> win-win?
[02:29] <ohsix> if google cares, that's great
[02:29] <ohsix> if it means splitting the people who care about other things, its' bad
[02:29] <Daemon404> except it isnt splitting anyone
[02:29] <ohsix> if is a predicate
[02:30] <iive> is that patch committed to libav? I don't see anybody there approving it?
[02:30] <Compn> chromwhuhhhh
[02:30] <Compn> heh
[02:30] <Daemon404> iive, no
[02:30] <Compn> i thought chrome stopped using ffmpeg ?
[02:30] <Daemon404> no it uses ffmpeg
[02:30] <Daemon404> so does youtube
[02:30] <Compn> k
[02:30] <ohsix> chromium uses it
[02:30] <ohsix> dunno about chrome
[02:30] <Daemon404> ohsix, it does
[02:30] <ohsix> awesome
[02:32] <ohsix> i still dont' know, but i'll take your word for it :]
[02:34] <beastd> I don't see a reason to not support MSVC except when it lowers the code quality in a significant number of places
[02:34] <Daemon404> beastd, it's doen as a preprocessor
[02:34] <Daemon404> so code impact is minimal
[02:35] <ohsix> that's what you said last time
[02:35] <durandal_1707> MythTV uses ffmpeg too
[02:35] <Daemon404> ohsix, ?
[02:35] <Compn> ohsix : do you happen to have a count of broken distributions that ffmpeg supports ?
[02:35] <Daemon404> there's a patch for it
[02:35] <Compn> wasnt there talk of a library for broken OS/distros ?
[02:35] <ohsix> Compn: no idea
[02:36] <Compn> libosderp or something
[02:36] Action: Compn forgets
[02:36] <ohsix> heh, sounds like something that duplicates what autotools can do for you :]
[02:36] Action: Compn recoils in horror
[02:37] Action: Daemon404 lieks autotools more than any otehr build system
[02:37] <Daemon404> even if it uses m4
[02:37] Action: beastd dislikes autotools with a passion
[02:37] <Daemon404> frankly, everythign else is even worse.
[02:37] <ohsix> <- dislikes covering ground someone else already covered, even if it is done poorly, it can be changed
[02:38] Action: Compn wishes google would sponsor wmv frame mt support :P
[02:38] <Compn> seems to be a popular feature request
[02:38] <Daemon404> Compn, id prefer if they covered making teh asf demuxer
[02:38] <Daemon404> you know
[02:38] <Daemon404> work
[02:38] <Daemon404> and not guess.
[02:38] <ohsix> isn't there something fundamental there, that's kept it broke for so long?
[02:38] <Compn> which part is broke ? 
[02:38] <Daemon404> ohsix, laziness and /care
[02:39] Action: Compn doesnt play much asf
[02:39] <ohsix> (asf demux)
[02:39] <Compn> ...
[02:39] <beastd> Daemon404: I agree most (if not all) solutions have problems, but going for autotools is IMHO always the wrong decision.
[02:39] <Daemon404> Compn, its seeking is probalistic
[02:39] <Compn> ah
[02:39] <Daemon404> beastd, autotools is teh sole build system that isnt terrible fro cross-compilign betwene archs
[02:39] <Daemon404> period.
[02:39] <Daemon404> also every otehr build system is very do-it-yourself, in that hardly any modules for htings exist
[02:40] <ohsix> and by arch he means platform triplets, it's not just arm/x86/whatever, it's libc/arch/kernel typically
[02:40] <Compn> oh man take your autotools flame somewhere else please :P
[02:40] <Compn> well i dont care too much
[02:40] Action: Daemon404 drops it
[02:40] Action: Compn goes to review bugs
[02:40] <ohsix> so you can meaningfully "support" uclibc-linux and glibc-linux in the same tree :>
[02:40] <Daemon404> ohsix, someone else who gets it@!
[02:40] Action: Daemon404 shocked
[02:41] <beastd> OMG; this whole discussion is flawed...
[02:41] <ohsix> oh i've created triplets just to solve pet problems, it's awesome :]
[02:41] <ohsix> ifdef or conditional linking isn't my friend
[02:44] <ohsix> most of the work is done for you for different triplets, for library names and whatnot; even without libtool, and a new "port" essentially just adds a few more exceptions for the target, and it helps hilight the problem areas with ports
[02:45] <ohsix> legacy code you don't really want to change can have its portability almost entirely in autotools
[02:46] <ohsix> or it can all be in the code where it really matters, and anywhere in between
[02:47] <ohsix> features typically have ifdef's so a few that are "platform features" aren't so bad, and they are basically the same
[02:48] <ohsix> it's hard to succinctly describe, but any given triplet will be 99% there no matter how alien the platform
[02:51] <durandal_1707> read_ffserver_streams does not check return value of avcodec_find_encoder which probably causes SEGV in #1456
[02:56] <CIA-119> ffmpeg: 03Paul B Mahol 07master * r137e80817d 10ffmpeg/libavcodec/ (13 files): 
[02:56] <CIA-119> ffmpeg: lavc: build some codecs only if they are actually enabled
[02:56] <CIA-119> ffmpeg: Saves few bytes if only some of them in same file are enabled.
[02:56] <CIA-119> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[03:02] <ohsix> if you go to a project needing it to support your platform (doesn't matter what it is) it's hell if it's not autotools, it's workable if it is, platform forks suck balls too
[03:03] <ohsix> porting to raw SoC's and stuff, companies will have their own library ports that diverge a bunch from upstream, and if you are used to upstream or need a feature that is a huge problem, but if you can port it yourself it's no problem
[03:04] <ohsix> multiply that by 5-50 for dependencies that matter, or bits of your platform; where you can't just run linux on it
[03:06] <ohsix> "effort" triage makes nonautotools projects very expensive, unless they are trivial; or are built like sqlite where you can, if you wish; just include one .c file, bonus if also like sqlite, it helps you put the amalgamation together
[03:08] <beastd> ohsix: well, can you really judge the quality of your result if you just fumble it in-place with autotools?
[03:09] <ohsix> i don't understand the question, you don't really fumble and have it actually build or run on your target
[03:11] <ohsix> do you mean where checks are insufficient and a library with the same symbol and interface has incompatible or unexpected semantics?
[03:13] <beastd> ohsix: for example. also most cases should make no difference with or without autotools if written according to standards and crossplatform libs.
[03:13] <ohsix> (that happens,  but you typically know about the differences in the libc implicitly)
[03:14] <ohsix> there is no standard for targeting a SoC directly, that's why i mentioned just running linux; that is "standard"
[03:15] <ohsix> those crossplatform libs also have to be targeted to the platform, if it's not linux, or windows, or something it already targets already; which can also affect how you choose your platform, but if that's out of your control then it's just compounded, and you write it all yourself or something
[03:16] <beastd> ohsix: I couldn't follow your last response.
[03:16] <beastd> ohsix: I do not argue that you don't have a point. But I argue that the solution is somewhat non-ideal.
[03:16] <ohsix> if you aren't targeting linux/glibc and those libraries you depend on aren't also targeting linux/glibc, it gets very intensive
[03:16] <ohsix> i started with saying autotools was nonideal :D
[03:17] <beastd> ohsix: That was a long time ago :)))
[03:17] <ohsix> it gets you almost all the way and is already set up to help you get the rest of the way, you do not have to duplicate that effort, and it is familiar to other people
[03:17] <ohsix> i would say autotools sucks, even; but when you consider how much work it can save, i will work with something that sucks
[03:18] <ohsix> and so will other people, we'll all use something that sucks together but we all sort of know how to employ, kind of like linux; it's malleable though, you can make it suck a little less in places where it really sucks
[03:24] <beastd> ohsix: I like to cite Git as a positive example. It started out as linux/posix-specific C code + bourne shell. Now it has grown into a stable multi-platform project. It is not exactly the things for a SoC though. It does not need autotools.
[03:24] <ohsix> if i have to redo all or most of what i'd have to do to get the project to build at all, by myself; as if i started with a pile of .c/.h files, i'm wasting my time
[03:25] <ohsix> right, something like git basically just does file io; which wouldn't be hard on a SoC either :]
[03:25] <ohsix> iirc the things that have dependencies are also packaged separately from -core
[03:25] <ohsix> things like git-svn
[03:27] <beastd> so you would agree that it is possible to grow projects meaningfully and achieve cross-platform support without the need for autotools?
[03:28] <beastd> ohsix: I would agree that it is a problem for existing/legacy projects where you do not have the manpower to meaningfully rework them and that there autotools might help you to get the job done with less expenses.
[03:28] <ohsix> as a case in point, sure; i don't know how git-svn is built; but as a person looking for stuff i can use and how i can use it, something without autotools is almost certainly very expensive in terms of effort to employ for my use
[03:29] <ohsix> even if that one project is very well done and already supports my platform in the raw or running-linux state, all of its dependencies don't; and the consideration isn't made in isolation
[03:29] <beastd> ohsix: deps are evil ;)
[03:30] <ohsix> if you can get by without them, sure; writing your own stuff is a way to do it, any other way is a build problem
[03:31] <beastd> i was just making fun there
[03:31] <beastd> of course the whole dependency graph has to be runable on your target platform
[03:32] <beastd> but it doesn't matter if all use autotools. they just have to fullfill your requirements with whatever buildsys they use
[03:32] <ohsix> if you have an os and a c library already you probably can do fine with just what comes with autotools, it's just easy to support any other scenario (new OS'ii or c libraries/raw hardware)
[03:33] <ohsix> not really, with autotools they don't have to already do what i want, because i know a port is cheap
[03:33] <ohsix> if your target is just an OS and a C library, it probably does, unless your os or c library is new
[03:34] <ohsix> but you can also get by with no c "library",  but with the stubs only the software uses, and the stubs use the hw directly, or your stub c library does
[03:34] <ohsix> or a c library that isn't compliant with any known standard, but suffices for the set of software running on it
[03:34] <ohsix> sort of like bionic on android
[03:37] <ohsix> you don't really need a "port" for bionic, you can target it with autotools and paper over the difference with wrappers if you don't or can't modify your project at all, too lazy to elaborate on the distinction, but a port is much more expensive than retargeting
[03:37] <ohsix> something like cmake implies a port, you need to redo everything
[03:39] <beastd> I do not think we really disagree much. I just think it is possible to grow projects (develop software) in a better way.
[03:41] <ohsix> right, i'm largely considering expense to employ and familiarity, i'd probably ignore the expense entirely in favor of familiarity if autotools didn't already do all this targeting stuff for me
[03:42] <ohsix> when evaluating a project on nothing but the build system, assuming the two do exactly the same thing; and something i need done, the one with autotools will be cheaper to port, even if i didn't look to see that the one that doesn't already has a port for my platform :]
[03:42] <Daemon404> holy walls of text
[03:42] Action: Daemon404 goes away more
[03:47] <CIA-119> ffmpeg: 03J. Bohl 07master * rfbed9317ff 10ffmpeg/libavutil/attributes.h: 
[03:47] <CIA-119> ffmpeg: enable C99-external_inline for icl
[03:47] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[04:18] <beastd> I am leaving. HF
[04:32] <Compn> d
[04:32] <Compn> did that av_restrict change mess up mplayer compilation ? 
[04:34] <michaelni> Compn, anything broken ?
[04:34] <Compn> [22:27] <DeHackEd> http://pastebin.com/3pL6uF5a
[04:34] <Compn> but i cant figure whats wrong
[04:35] <Compn> could be pebcak
[04:37] Action: Compn falling asleep
[04:38] <michaelni> Compn, ill try to fix it
[04:38] <michaelni> not the "falling asleep the restrict ;)"
[04:47] <Compn> haha
[05:02] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * rbc4da77b08 10ffmpeg/libavutil/internal.h: 
[05:02] <CIA-119> ffmpeg: lavu/internal: define av_restrict if it has not been defined by config.h
[05:02] <CIA-119> ffmpeg: This can happen if a application doesnt use ffmpegs configure
[05:02] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[05:03] <michaelni> Compn, might be fixed
[12:38] <ubitux> saste: hi
[12:38] <ubitux> saste: is it me or elenril last patchset has something similar to asetnbsamples filter?
[12:38] <ubitux> (the afifo filter)
[12:39] <saste> possible
[12:39] <ubitux> and the join audio filter looks like a limited pan filter again...
[12:39] <saste> i didn't think of merging the two paths but i didn't look at that patch yet
[12:40] <saste> limited but faster?
[12:40] <ubitux> i don't think so
[12:40] <saste> nih hits again
[12:40] <ubitux> pan filter is using the channel mapping from libswr when possible
[12:41] <ubitux> of course since libavr doesn't actually have that feature...
[12:41] <saste> btw could you commit the side-to-side video docu patch, seems to be a FAQ on -user
[12:41] <ubitux> ah yeah sure
[12:42] <ubitux> i'll do that in the hour, i have something important to do right now
[12:42] Action: ubitux &
[12:42] <saste> yes no hurry
[12:42] <ohsix> what's libavr/swr?
[12:55] <CIA-119> ffmpeg: 03Pavel Koshevoy 07master * ra1aac8d004 10ffmpeg/ (8 files in 3 dirs): 
[12:55] <CIA-119> ffmpeg: lavfi: add atempo filter
[12:55] <CIA-119> ffmpeg: Add atempo audio filter for adjusting audio tempo without affecting
[12:55] <CIA-119> ffmpeg: pitch. This filter implements WSOLA algorithm with fast cross
[12:55] <CIA-119> ffmpeg: correlation calculation in frequency domain.
[12:55] <CIA-119> ffmpeg: Signed-off-by: Pavel Koshevoy <pavel at homestead.aragog.com>
[12:55] <CIA-119> ffmpeg: Signed-off-by: Stefano Sabatini <stefasab at gmail.com>
[13:06] <ubitux> ohsix: add "aresample" to each
[13:07] <ohsix> ah
[13:08] <ubitux> i mean "esample" actually
[13:21] <CIA-119> ffmpeg: 03Clément BSsch 07master * r20a6fa77a6 10ffmpeg/doc/filters.texi: doc: add two similar overlay "side-by-side" examples.
[13:22] <saste> ubitux: ^^ thx
[13:24] <ubitux> np :)
[17:14] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * r4aed3ac86a 10ffmpeg/libavcodec/msmpeg4enc.c: 
[17:14] <CIA-119> ffmpeg: msmpeg4enc: use av_assert
[17:14] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[17:14] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * reaf655384b 10ffmpeg/libavformat/avienc.c: 
[17:14] <CIA-119> ffmpeg: avienc: use av_assert
[17:14] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[18:06] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * r40ffbf20d8 10ffmpeg/tests/fate/aac.mak: 
[18:06] <CIA-119> ffmpeg: fate: fix fate-aac-aref-encode dependancies
[18:06] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[18:06] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * r5015c37b7d 10ffmpeg/libavutil/ (attributes.h internal.h): 
[18:06] <CIA-119> ffmpeg: attributes: move av_restrict fallback from internal to attributes
[18:06] <CIA-119> ffmpeg: This should fix --enable-hardcoded-tables
[18:06] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[19:57] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * r1125606a1f 10ffmpeg/libavcodec/vp3.c: 
[19:57] <CIA-119> ffmpeg: vp3dec: fix null ptr derefernce.
[19:57] <CIA-119> ffmpeg: Fixes ticket1403
[19:57] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[20:55] <ubitux> we seriously need a webdesigner
[20:55] <ubitux> to rework the CSS and stuff :(
[20:59] <michaelni> ubitux, herve volunteered to do that he might be too busy though, maybe you should mail him
[20:59] <michaelni> IIRC he had some problems with texi2html or something
[21:00] <ubitux> well i can take a day or two to do it (next week end for instance)
[21:00] <ubitux> but i have better to do i think :p
[21:01] <ubitux> we just need some kind of bootstrap like website
[21:01] <ubitux> http://twitter.github.com/bootstrap/
[21:01] <ubitux> no need for a particular design
[21:03] <michaelni> ubitux, like i said mail herve :) i dont know what he is working on exactly or if he is busy
[21:03] <ubitux> i don't want to ask to someone in particular to do web stuff
[21:03] <ubitux> it's pretty mean
[21:03] <ubitux> :D
[21:05] <michaelni> its not asking to do, i know he was already working/playing with it
[21:15] <ubitux> i'm playing a bit with the CSS right now :p
[21:15] <ubitux> to at least improve it slightly
[21:33] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * rc390822e18 10ffmpeg/libavcodec/intelh263dec.c: 
[21:33] <CIA-119> ffmpeg: intel h263 dec: support advanced prediction
[21:33] <CIA-119> ffmpeg: Fixes Ticket1292
[21:33] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[21:36] <ubitux> michaelni: http://blackhole.ubitux.fr/0001-css-slightly-improve-general-output.patch
[21:36] <ubitux> what about something like this?
[21:38] <ubitux> the documentation looks less like a big blob of text
[21:39] <ubitux> with the slight emphasis
[21:39] <Compn> heh
[21:39] <Compn> ubitux : show us a page thats been done
[21:39] <Compn> we cant look at css and then imagine how it looks
[21:39] <Compn> :P
[21:42] <ubitux> http://ubitux.fr/pub/pics/_ffmpeg-org-css-0.png
[21:42] <ubitux> http://ubitux.fr/pub/pics/_ffmpeg-org-css-1.png
[21:42] <ubitux> http://ubitux.fr/pub/pics/_ffmpeg-org-css-2.png
[21:42] <ubitux> http://ubitux.fr/pub/pics/_ffmpeg-org-css-3.png
[21:44] <Compn> looks nice :)
[21:47] <ubitux> the diff makes the 1998 website just looking like a website made by a bad designer
[21:48] <ubitux> a *recent*
[21:48] <ubitux> what do you prefer? :))
[21:51] <ubitux> who are the web maintainers? (if any)
[21:52] <Compn> herve 
[21:53] <Compn> and whoever did the site design originally
[21:53] <Compn> i try to add stuff to the site , and michael comes up with ideas too :)
[21:53] <Compn> feel free to commit , as anything to improve the look is welcome
[21:54] <Compn> michaelni : btw on security page, do you want to set up a security contact so exploiters can disclose vulns ?
[21:54] <Compn> or at least put a note on security page
[21:55] <Compn> saying just to post to ffmpeg trac / ffmpeg-devel
[21:55] <Compn> http://ffmpeg.org/security.html
[21:55] Action: Compn afk
[22:03] <durandal_1707> michaelni: should i move adpcm_step table into separate file or linkinkg adpcm_data with vima should be enough?
[22:10] <michaelni> durandal_1707, linking/adding a dependancy in the Makefile should be fine
[22:18] <CIA-119> ffmpeg: 03Stefano Sabatini 07master * rd70a1a507d 10ffmpeg/MAINTAINERS: MAINTAINERS: reorganize entries in the libavfilter section
[22:20] <CIA-119> ffmpeg: 03Paul B Mahol 07master * r54101214d8 10ffmpeg/libavfilter/ (25 files): 
[22:20] <CIA-119> ffmpeg: lavfi: use designated initializers for AVClass
[22:20] <CIA-119> ffmpeg: While here:
[22:20] <CIA-119> ffmpeg:  - add missing .version and .category,
[22:20] <CIA-119> ffmpeg:  - make .class_name consistent across filters,
[22:20] <CIA-119> ffmpeg:  - align declarations.
[22:20] <CIA-119> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[22:26] <michaelni> Compn, I just created "ffmpeg-security at ffmpeg.org" feel free to add it to the security page
[23:00] <CIA-119> ffmpeg: 03Jordi Ortiz 07master * ra7cc78cb11 10ffmpeg/libavformat/tcp.c: 
[23:00] <CIA-119> ffmpeg: tcp: Check the listen call
[23:00] <CIA-119> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[23:00] <CIA-119> ffmpeg: 03Diego Biurrun 07master * rf404c7dcd7 10ffmpeg/doc/general.texi: doc: Add missing protocols to list of supported protocols.
[23:00] <CIA-119> ffmpeg: 03Martin Storsjö 07master * r5f26d4d448 10ffmpeg/libavformat/amr.c: 
[23:00] <CIA-119> ffmpeg: amr: Cosmetic cleanup
[23:00] <CIA-119> ffmpeg: Add spaces around operators, fix brace placement and whitespace to
[23:00] <CIA-119> ffmpeg: match K&R style, vertically align code, remove redundant != 0 and
[23:00] <CIA-119> ffmpeg: convert x == 0 into !x, drop useless braces.
[23:00] <CIA-119> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[23:00] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * r6ca48ad044 10ffmpeg/: (log message trimmed)
[23:00] <CIA-119> ffmpeg: Merge remote-tracking branch 'qatar/master'
[23:00] <CIA-119> ffmpeg: * qatar/master:
[23:00] <CIA-119> ffmpeg:  amr: Cosmetic cleanup
[23:00] <CIA-119> ffmpeg:  mov_chan: Fix operator precedence by adding parentheses
[23:00] <CIA-119> ffmpeg:  doc: Add missing protocols to list of supported protocols.
[23:00] <CIA-119> ffmpeg:  tcp: Check the listen call
[23:00] <CIA-119> ffmpeg: 03Martin Storsjö 07master * r44fdf37c94 10ffmpeg/libavformat/mov_chan.c: 
[23:00] <CIA-119> ffmpeg: mov_chan: Fix operator precedence by adding parentheses
[23:00] <CIA-119> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[23:50] <CIA-119> ffmpeg: 03Stefano Sabatini 07master * r251f398798 10ffmpeg/ffplay.c: 
[23:50] <CIA-119> ffmpeg: ffplay: use key=val syntax for the buffersrc args
[23:50] <CIA-119> ffmpeg: Fix warning:
[23:50] <CIA-119> ffmpeg: [src @ ...] Flat options syntax is deprecated, use key=value pairs.
[23:50] <CIA-119> ffmpeg: Signed-off-by: Marton Balint <cus at passwd.hu>
[23:50] <CIA-119> ffmpeg: 03Stefano Sabatini 07master * r8f45c3141c 10ffmpeg/ffplay.c: 
[23:50] <CIA-119> ffmpeg: ffplay: rename buffer source instance from "src" to "ffplay_buffer"
[23:50] <CIA-119> ffmpeg: The new name is more descriptive.
[23:50] <CIA-119> ffmpeg: Signed-off-by: Marton Balint <cus at passwd.hu>
[23:50] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * rdb83570875 10ffmpeg/ffplay.c: 
[23:50] <CIA-119> ffmpeg: ffplay: fix -vismv 1
[23:50] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[23:50] <CIA-119> ffmpeg: Signed-off-by: Marton Balint <cus at passwd.hu>
[23:50] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * r564bb244eb 10ffmpeg/: 
[00:00] --- Mon Jun 18 2012