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

[burek]

[00:35] <rcombs> if Plex Media Server bundles their modified ffmpeg, and uses it for essential features of the software, does the entire program necessarily become GPL?
[00:36] <BBB> michaelni: comments on emulated_edge? or do you want me to ask pengvado for simd comments?
[00:38] Action: rcombs is looking at Section 2 of http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
[00:38] <nevcairiel> have fun convincing a judge of that
[00:39] <rcombs> "These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on 
[00:39] <rcombs> the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it."
[00:39] <BBB> he's not a lawyer
[00:39] <michaelni> BBB, pengvados comments would be very valuable either way i think, ill take a look at the patch too, just was/am a bit busy
[00:39] <BBB> pengvado: ping if you're interested?
[00:39] Action: rcombs is no lawyer, but the way I'm parsing this it looks like the whole software becomes GPL
[00:40] <BBB> rcombs: does it use libav* or ffmpeg.exe?
[00:40] <BBB> libav* being libav{codec,format,util,etc}, not necessarily libav-the-project (or avconv.exe)
[00:40] <rcombs> BBB: it uses a heavily-modified ffmpeg executable, whose source is available on request
[00:40] <nevcairiel> this is why some companys distribute the gpl  plugins separately, so this part of the license doesn't apply so easily :p
[00:41] <BBB> if the commandline interface itself is not heavily part of the abi (as in a COM-like interface), then I think from a legal pov they are considered separate
[00:42] <rcombs> they seem to think that the transcoder source must be distributed under GPL, but that the entire server doesn't have to be because they only *link* against LGPL code
[00:43] <rcombs> they spawn a "Plex Transcoder" (modified ffmpeg) process via a shell exec
[00:43] <rcombs> with largely ffmpeg-compatible args (some changes)
[00:44] <rcombs> I'm told my request for the Transcoder source is "in the queue"
[01:37] <kierank> ac3 in wav samples anywhere?
[01:42] <TheRyuu> so why am I getting spammed by av_restrict macro redefinition warnings when using msvc?
[02:03] <j-b> kierank: if you get some, please share :)
[02:26] <Compn> rcombs : still need help with ffmpeg violator?
[03:12] <cone-262> ffmpeg.git 03Neil Birkbeck 07master:a11c16a0b0ca: avfilter/vf_psnr: Prevent integer overflow.
[03:12] <cone-262> ffmpeg.git 03Michael Niedermayer 07master:68f328fcdd14: avfilter/vf_psnr: avoid 64bit arithmetic in the inner loop
[03:25] <cone-262> ffmpeg.git 03Carl Eugen Hoyos 07master:705b30e24f9b: Improve pullup documentation.
[03:38] <cone-262> ffmpeg.git 03Lukasz Marek 07master:5b153f81645e: lavf: add SFTP protocol via libssh
[04:50] <durandal_1707> FF_COUNT2LAYOUT does not work for 1 it gives stereo
[04:50] <durandal_1707> this sucks
[04:54] <durandal_1707> nevermind, it seems to work
[09:39] <cone-56> ffmpeg.git 03Martin Storsjö 07master:67e285ceca1c: mem: Handle av_reallocp(..., 0) properly
[09:39] <cone-56> ffmpeg.git 03Michael Niedermayer 07master:6c169c2fa4f3: Merge commit '67e285ceca1cb602a5ab87010b30d904527924fe'
[09:41] <cone-56> ffmpeg.git 03Reimar Döffinger 07master:f76b633a94e1: mpeg4dec: Ensure data is not clobbered too early.
[09:51] <cone-56> ffmpeg.git 03JULIAN GARDNER 07master:97ff584af432: Apply clut changes only to one table.
[09:51] <cone-56> ffmpeg.git 03Reimar Döffinger 07master:29f244e08ee0: dvbsubdec: Check for invalid clut selector.
[11:03] <cone-56> ffmpeg.git 03Paul B Mahol 07master:f35b2fa8c9b8: fate: add adelay test
[11:57] <cone-56> ffmpeg.git 03Vittorio Giovara 07master:01f111bdb21b: h264dec: K&R formatting cosmetics
[11:57] <cone-56> ffmpeg.git 03Michael Niedermayer 07master:de493809f31a: Merge commit '01f111bdb21b4ea6d2ff3ea919d70ae9ca451cf9'
[12:03] <cone-56> ffmpeg.git 03Vittorio Giovara 07master:944c3384305e: h264dec: Add .avc file name extension
[12:03] <cone-56> ffmpeg.git 03Michael Niedermayer 07master:d0171eb8d795: Merge remote-tracking branch 'qatar/master'
[12:17] <cone-56> ffmpeg.git 03Carl Eugen Hoyos 07master:ac82155204f1: Remove '-vf' from pullup documentation example.
[14:01] <BBB> TheRyuu: I believe libav added av_restrict to avconfig.h, then ffmpeg added it to config.h (or vice versa, or some other header combination in whatever order) so ffmpeg has it twice
[14:02] <BBB> TheRyuu: it's harmless b/c both definitions are identical
[14:02] <TheRyuu> I know taht's the point, why isn't it fixed
[14:03] <TheRyuu> it seems trivial to do
[14:06] <TheRyuu> (I was told there were already patches to fix it)
[14:12] <TheRyuu> but whatever, not really concerned about that right now, it was just on my mind at the time, what I am more concerned about is this:
[14:12] <TheRyuu> https://privatepaste.com/4548cbd262
[14:13] <BBB> TheRyuu: oh dunno I'm sure there's some political reason for it, I bet you it's related to either mplayer or some fork consipracy theory
[14:14] <TheRyuu> icl's preprocessor seems to not behave the same (or be broken)
[14:18] <wm4> wow why is libavformat's option api so retarded
[14:19] <wm4> I tried to find out why setting an option on an input context didn't work
[14:19] <wm4> and OF COURSE you can't use av_opt_set() on an AVFormatContext
[14:19] <wm4> no, you have to pass it as dict to avformat_open_input()
[14:20] <wm4> but that's only for some options, which otherwise magically won't work
[14:20] <wm4> what!?!?
[14:20] <ubitux> michaelni: about yadif patch, can't you nest the successive FFABS(j)>X? (if it's not >1, it won't be >2, if it's not >2 it won't be >3, ...)
[14:21] <BBB> TheRyuu: I believe msvc had an issue that looked like that, looks like the preprocessor needs an extra step to expand its arguments
[14:22] <BBB> TheRyuu: why do these macros use __VA_ARGS__ anyway? they're not variable-argument-based at all
[14:22] <ubitux> wm4: i might have find a way for vobsub, i'll send you a new patch soon
[14:22] <michaelni> ubitux, whats the point ? j is a constant
[14:23] <BBB> #define IMPL_ALL(a,b,c) IMPL_USE(lavu, a, b, c) [etc]
[14:23] <BBB> and remove IMPL
[14:23] <wm4> ubitux: ok
[14:23] <BBB> TheRyuu: ^^
[14:23] <ubitux> michaelni: i missed that, thanks
[14:23] <BBB> TheRyuu: then I think it will compile fine
[14:23] <BBB> TheRyuu: also shorter
[14:23] <ubitux> wm4: i got some event disappearing though now, but since they are actually not ordered...
[14:24] <BBB> TheRyuu: you can look at LOCAL_ALIGNED in dsputil.h to see how we solved that for msvc - I think a similar hack will work here too if you want to keep varargs
[14:24] <michaelni> <TheRyuu> (I was told there were already patches to fix it)
[14:24] <michaelni> where ?
[14:24] <wm4> ubitux: does that mean I have to read all packets and then sort them?
[14:24] <ubitux> no don't worry
[14:24] <ubitux> wm4: it's that sometimes... : 
[14:25] <ubitux> timestamp: 00:05:28:369, filepos: 000024800
[14:25] <ubitux> timestamp: 00:05:28:361, filepos: 000025000
[14:25] <TheRyuu> michaelni: I'll poke Daemon404 about it when he's around
[14:25] <cone-56> ffmpeg.git 03Carl Eugen Hoyos 07master:79209f5d6ca3: Allow encoding YUVJ422P and YUVJ444P with libx264.
[14:25] <cone-56> ffmpeg.git 03Michael Niedermayer 07master:8ad2465987d3: Merge remote-tracking branch 'cehoyos/master'
[14:27] <TheRyuu> BBB: ok thanks
[14:29] <TheRyuu> https://privatepaste.com/711989e993 <---because you might as well rice everything right?
[14:39] <TheRyuu> https://warpsharp.info/libav/0001-tools-Fix-apparent-merge-failure.patch
[14:42] <BBB> why are YUVJ*P still there? shouldn't they die at some point?
[14:42] <BBB> anyway let me work on a ffvp9 merge or so
[14:43] <wm4> BBB: they've even added new J formats
[14:43] <wm4> but now that lavfi supports color ranges, maybe they really can go
[14:43] <kierank> BBB: swscale
[14:44] <wm4> swscale supports color ranges...
[14:47] <cone-56> ffmpeg.git 03James Almer 07master:56f17407bc46: matroska: Add the CueDuration element
[14:48] <cone-56> ffmpeg.git 03Alex Smith 07master:eedbc2b56d4c: tools: Fix apparent merge failure
[14:49] <cone-56> ffmpeg.git 03Paul B Mahol 07master:8ac0eb2cd7ce: avfilter/vf_tinterlace: add yuv411p, yuv440p, yuva422p and yuva444p
[14:50] <michaelni> TheRyuu, not sure for whom you posted "https://privatepaste.com/711989e993" but it doesnt apply
[14:50] <michaelni> (would also lack author and commit message)
[14:50] <TheRyuu> it was a joke
[14:51] <michaelni> :)
[14:51] <cone-56> ffmpeg.git 03Paul B Mahol 07master:59d72f8b1647: lavfi/pad,crop,scale: remove options description from filter description
[14:53] <BBB> there's some other patch that should be fun to review
[14:54] <kierank> wm4: based on the J flag, no?
[14:54] <BBB> kierank: no
[14:54] <wm4> the J flag is also respected
[14:54] <BBB> kierank: AVCodecContext has a colorspace entry that is FW'ed to swscale through one if its api functions
[14:54] <BBB> the J is just a proxy for that
[14:54] <kierank> oh
[14:55] <kierank> then i don't know why J exists
[14:55] <wm4> so, J is basically backwards compatibility by now
[14:55] <wm4> but it also has been argued that it's a good thing for lavfi
[14:55] <wm4> because this way color range can be included in filter format negotiation
[14:56] <wm4> and I suppose nobody is brave enough to add proper color range negotiation to lavfi
[14:56] <wm4> because lavfi format negotiation is evil
[14:56] <Daemon404> oh does swscale actually respect the range flag now?
[14:56] <Daemon404> it used to ignored it and rely on the J
[14:56] <wm4> yes, for YUV formats
[14:57] <wm4> it has been there for a while, though it also had some serious bugs
[15:03] <Daemon404> seems pretty unreliable to use it though
[15:03] <Daemon404> e.g. http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=79209f5d6ca31c73260f1c5f5dbaa8395102d9f1
[15:03] <Daemon404> still relies on J
[15:07] <wm4> well, some decoders probably still output J
[15:07] <wm4> because backwards compatibility
[15:08] <wm4> who knows why cehoyos added this, though
[15:08] Action: wm4 keeps wondering why ffmpeg doesn't have detailed commit messages
[15:09] <TheRyuu> that would make it too easy
[15:09] <wm4> have a look at some of the Linux kernel's https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.11.1
[15:09] <wm4> there's barely a commit that has nothing in the message body
[15:10] <durandal11707> send such patches to ml, i'm sure other will start doing the same
[15:10] <durandal11707> except c.
[15:10] <TheRyuu> I think it's the other way around, reject stuff that doesn't have one
[15:14] <cone-56> ffmpeg.git 03Hendrik Leppkes 07master:1c4fa2aaf230: avcodec/fraps: use BT.709 colorspace for YUV Fraps versions
[15:16] <TheRyuu> so what exactly was the original idea behind using av_restrict?
[15:18] <BBB> msvc doesn't have restrict
[15:18] <BBB> it has __restrict
[15:19] <BBB> you can #define restrict __restrict
[15:19] <wm4> msvc being funny as usual...
[15:19] <BBB> but that causes issues in stdlib.h if you have some particular header include order
[15:19] <wm4> though I'm surprised C didn't introduce it as _Restrict
[15:19] <BBB> av_restict workarounds that
[15:20] <wm4> why doesn't the C99 converter just take care of this?
[15:21] <BBB> babies ask why
[15:21] <BBB> real people fix bugs
[15:21] <BBB> I decided to fix the bug this way
[15:21] <wm4> why?
[15:22] <wm4> because now newer msvc most likely won't support plain restrict
[15:22] <TheRyuu> what?
[15:23] <BBB> you seem to infer that the only goal of the msvc2013 team was to compile ffmpeg
[15:24] <wm4> as far as the C compiler part of msvc is concerned, that seems to be the case
[15:24] <BBB> do you have any evidence for that assumption other than third-party posts and he-said-she-said commentaries?
[15:25] <wm4> ffmpeg appearing on MS' slides?
[15:25] <BBB> so one slide mentioning it as one item of a list of items that intend to support with the final release, suggests that the only goal is that one item?
[15:26] <TheRyuu> I'm confused as to what exactly is the issue
[15:26] <wm4> BBB: is ffmpeg the only C project that uses restrict?
[15:27] Action: BBB goes walk the kids
[15:27] <wm4> I thought we'd understand each other more if I asked questions in the same style as you
[15:28] <BBB> probably not
[15:28] <BBB> michaelni: can you approve the ffvp9 patch email to the ml?
[15:28] <wm4> TheRyuu: I think it would be fun to force MS by using as many C99 features as possible
[15:28] <wm4> *to force MS support more of C99
[15:29] <TheRyuu> at this point who really cares what MS does with C99
[15:29] <j-b> they cared about C99, because of C++14 and C11
[15:29] <j-b> and for that, they had to support more of C99
[15:29] <wm4> j-b: really? does MS have real obligations to the C standard committee?
[15:30] <wm4> they've been part of it even on C11, even though they didn't support C99 at all
[15:38] <TheRyuu> https://warpsharp.info/libav/0001-lavu-attributes-Don-t-define-av_restrict.patch
[15:41] <TheRyuu> michaelni: ^
[15:42] <Daemon404> [14:23] <@BBB> you seem to infer that the only goal of the msvc2013 team was to compile ffmpeg
[15:42] <Daemon404> you know
[15:42] <Daemon404> they added stuff we *dont* use
[15:42] <cone-56> ffmpeg.git 03Michael Niedermayer 07master:0506f3fa38a1: avutil/cpu: remove duplicate include
[15:42] <cone-56> ffmpeg.git 03Michael Niedermayer 07master:4bc7a2a64bf2: avfilter: remove duplicate includes
[15:42] <Daemon404> like mixed var and code decls
[15:42] <cone-56> ffmpeg.git 03Michael Niedermayer 07master:d0c61571cfab: avdevice/v4l: remove duplicate include
[15:43] <cone-56> ffmpeg.git 03Michael Niedermayer 07master:49515cb8407b: avformat: remove duplicate includes
[15:43] <Daemon404> [14:29] <@j-b> and for that, they had to support more of C99 <-- eh
[15:43] <Daemon404> it wasnt even MS's work
[15:43] <Daemon404> they license their stdlib off of dinkumware
[15:43] <Daemon404> who has had c99 for quite a while
[15:43] <Daemon404> <_<
[15:50] <cone-56> ffmpeg.git 03Alex Smith 07master:66c2f200b628: lavu/attributes: Don't define av_restrict
[15:50] <j-b> nice, a VP9 decoder appears
[15:52] <JEEB> Daemon404, yeah -- I bet they just didn't want to touch their licensing deals with dinkumware
[15:52] <Daemon404> ;p
[15:53] <Daemon404> hey nevcairiel look above
[16:04] <kierank> Daemon404: oh you're back
[16:04] <Daemon404> ?
[16:04] <kierank> i thought you left this channel
[16:05] <Daemon404> o
[16:05] <Daemon404> yeah
[16:05] <Daemon404> i periodically do when the insanity/inbreeding gets to me too much.
[16:07] <j-b> who is the insaner?
[16:09] <Daemon404> the most insane people do not come on irc
[16:28] <TheRyuu> f:/build/ffmpeg/tools/ffhash.c(90): error: identifier "ssize_t" is undefined since when was icl so fuckign broken
[16:29] <TheRyuu> man apparently I need to check if this builds on older icl's
[16:29] <TheRyuu> because I'm not sure anymore
[16:30] <TheRyuu> fate passes so they work probably
[16:32] <TheRyuu> BBB: that marco did it btw, thanks
[16:40] <TheRyuu> seems it's only broken for me
[17:04] <cone-56> ffmpeg.git 03Lukasz Marek 07master:ef23b7fd6d26: lavf/libssh: add MAINTAINERS entry
[17:04] <cone-56> ffmpeg.git 03Michael Niedermayer 07master:b8a954e46d53: avformat/network: fix duplicate include
[17:04] <cone-56> ffmpeg.git 03Michael Niedermayer 07master:a072acb108f3: avcodec: fix duplicate includes
[17:12] <nevcairiel> daemon404: how did that happen without month of bikeshedding?
[17:23] <ubitux> wm4: can you try this? http://b.pkh.me/0001-avformat-vobsub-WIP-fix-packet-size-calc.patch
[17:24] <wm4> I'm at it
[17:26] <TheFluff> /win/win 25
[17:26] <TheFluff> derp
[17:38] <wm4> ubitux: still getting length 0 packets on the vi stream
[17:38] <ubitux> mmh
[17:39] <wm4> not all are 0, but most are
[17:39] <ubitux> i was too obsessed with the other issue, 'sec
[17:51] <durandal11707> are vp9 samples on fate?
[18:58] <Daemon404> nevcairiel, no idea
[19:22] <ubitux> mmh the main cause of the problem might be related to mpegps_read_pes_header()..
[19:28] <ubitux> fuck that's indeed the reason of the mismatches
[19:36] <BBB> j-b: yeah me and ubitux had that in our playground for a while... simd and mt will come at some point in the future
[19:36] <ubitux> i wanted to work on the simd today
[19:36] <ubitux> but it's been 3 days i'm fighting with vobsub :(
[19:36] <ubitux> i think i finally have the cause of the problem
[19:47] <ubitux> i feel like modifying mpegps_read_pes_header() will make everything explode
[19:47] <nevcairiel> its mpeg, so most likely yes
[19:47] <wm4> D:
[19:47] <ubitux> i guess i'm going to rewrite a simpler version
[19:48] <ubitux> just for my needs
[20:22] <ubitux> any reason you didn't change the assert() to av_assert*()?
[20:23] <ubitux> BBB: ^
[20:23] <BBB> ubitux: oh forgot
[20:23] <ubitux> i don't mind changing that, but i'm not sure what function are performance relevant
[20:23] <BBB> ubitux: can you send a patch to do that (either in our branch or against the patch I sent to ML)
[20:23] <BBB> ask :)
[20:23] <BBB> you can make a diagram
[20:23] <BBB> basically anything called within the context of decode_sb or loopfilter_sb is performance relevant
[20:23] <BBB> the rest is not
[20:23] <ubitux> ok
[20:24] <ubitux> BBB: is your branch in sync with the patch?
[20:27] <BBB> ubitux: I believe so yes
[20:27] <ubitux> k
[20:27] <BBB> order of patches may be slightly off
[20:27] <BBB> but tip is identical
[20:38] <ubitux> BBB: are you working on what's at line 1430?
[20:38] <ubitux> (vp9.c)
[20:39] <BBB> I'm working on mc simd
[20:39] <BBB> so likely no
[20:40] <ubitux> ok
[20:40] <BBB> oh that's just an idea, maybe it's blobby and should be removed
[20:40] <ubitux> i like the idea
[20:41] <BBB> if you want to play around with that, go for it
[20:41] <ubitux> (with the codeblob at the next fixme)
[20:41] <BBB> now that we have a real decoder, we can test that sort of stuff and make sure it a) works and b) is faster
[20:41] <ubitux> yeah well i want to change my mind with that vobsub/mpeg thing so well..
[20:42] <ubitux> i'll check if it's doable with less brain torture than mpegps_read_pes_header()
[20:51] <saste> durandal_1707, LADSPA filter, awesome
[20:51] <ubitux> BBB: where is akiyo sample?
[20:52] <ubitux> BBB: i copied all the webm from libvpx testdata but that's all i have
[20:59] <BBB> I sent it to you by email earlier
[20:59] <BBB> want me to re-send it?
[20:59] <BBB> it's the test sample we used in the beginning
[21:00] <BBB> ~25kb
[21:07] <cone-56> ffmpeg.git 03Michael Niedermayer 07master:21a2b97365b5: avformat/hls: do not limit manifest lines to 1024 chars
[21:14] <ubitux> BBB: ah, ok
[21:15] <ubitux> i have it it's ok
[21:18] <durandal_1707> saste: i'm also right now looking at adding lv2 wrapper
[21:41] <ubitux> BBB: so i have 7 variables of 1 to 2 bits: intra_[la], comp_[la] + fix, ref_[la]; i'm undecided about the order of the lut; do you have any idea what are the most unlikely to change between successive calls (so we put them in the higher dimension)?
[21:45] <ubitux> that might not do much difference though
[21:58] <ubitux> actually i'll do it differently
[22:08] <ubitux> BBB: http://b.pkh.me/0001-WIP-have_-al-codeblob-lut.patch
[22:08] <ubitux> this seems to work :p
[22:14] <ubitux> it makes the code a bit harder to follow though 
[22:44] <saste> durandal_1707, how many ladspa effect did you test?
[22:44] <durandal_1707> why you ask?
[22:44] <saste> also, what if input rate != output rate?
[22:45] <durandal_1707> i doubt that can happen
[22:45] <saste> i'm asking because my experience with sox was that the more filters i tested, the more crashes i discovered
[22:45] <saste> ladspa seems a bit saner than sox
[22:45] <saste> but, no resample filter in ladspa?
[22:47] <saste> http://breakfastquay.com/forum/index.php?p=/discussion/25/why-isnt-there-a-time-streching-ladspa-plugin/p1
[22:47] <durandal_1707> saste: i don't see how that could be possible with api
[22:47] <durandal_1707> i'm not even sure same is possible with lv2
[22:48] <saste> with sox that's possible, and is a mess
[22:48] <saste> lot of internal caching is necessary
[22:48] <saste> also there is no way to ask the library to return N samples, so you need to check and reallocate buffers when required
[22:49] <wm4> maybe support this directly? http://breakfastquay.com/rubberband/
[22:52] <durandal_1707> what is wrong with atempo?
[22:55] <durandal_1707> sox supports 32bit integer only, which sucks
[22:55] <durandal_1707> ladspa 32bit float only, sucks less
[22:56] <durandal_1707> lv2 32 & 64 bit float only, sucks even less, but still sucks
[22:56] <wm4> lavfi doesn't support 24 bit audio or unsigned 16 bit audio :(
[22:56] <durandal_1707> nobody use unsigned 16 bit audio
[22:57] <saste> wm4, s/lavfi/lswr+lavu/
[22:57] <durandal_1707> also you can losslessly convert that with swr
[22:57] <saste> lavfi supports what the rest of FFmpeg supports
[22:57] <wm4> and it doesn't support the endian switched variants either
[22:57] <wm4> I find that a bit strange, because the video formats support all possible permutations
[22:58] <wm4> who will ever use AV_PIX_FMT_GBRP14BE?
[23:00] <durandal_1707> h264 on big endian
[23:01] <saste> ladspa is Linux only, right?
[23:01] <durandal_1707> nope
[23:01] <durandal_1707> it's just name....
[23:01] <saste> Linux Audio Developer's Simple Plugin API => bad name
[23:01] <durandal_1707> lv2 is LADSPA v2
[23:01] <durandal_1707> bad name (tm) v2
[23:03] <durandal_1707> those plugins are normally used with gui
[23:04] <durandal_1707> but for ffmpeg, you will need to be happy with your terminal emulator
[23:05] <durandal_1707> btw, i need to find some reasonably simple but useful lv2 plugin so i could write lavfi host
[23:06] <durandal_1707> all i find are heavily depend on gui crap
[23:08] <wm4> how are they dependent on GUIs?
[23:08] <wm4> GUI configuration dialogs?
[23:09] <durandal_1707> they link to gtkmm (pangomm/cairomm/etc...)
[23:49] <cone-56> ffmpeg.git 03Compn 07master:5dca837ac39a: changelog: add fraps and libx264 changes
[23:51] <durandal_1707> Compn: add changelog changes to changelog?
[23:53] <ubitux> BBB: so i pushed a few things in my branch, feel free to pick whatever you like
[00:00] --- Sun Sep 22 2013