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

[burek]

[00:16] <hyun> is there a reason why ffmpeg doesn't have h264 encoder?
[00:17] <ubitux> there was an experimental one at some point, but libx264 actually does a pretty good job
[00:17] <ubitux> so it's simpler to just have a wrapper
[00:19] <JEEB> it'd be very hard to actually get to the level or over the level of libx264
[00:19] <JEEB> not everything should be NIH'd and reinvented
[00:19] <JEEB> a good (bad) example of NIH and reinvention is the vorbis encoder in libavcodec :P
[00:19] <JEEB> there's a reason why no-one uses it
[00:26] <hyun> do you mean that there is experimental h264 encoder in ffmpeg?
[00:26] <JEEB> no
[00:26] <JEEB> it was posted on the mailing list a couple of years ago IIRC
[00:26] <JEEB> but it was baseline profile only and nowhere as usable as libx264
[00:27] <JEEB> for all intents and purposes you should be using and/or developing libx264
[00:27] <JEEB> it has both GPL licensing as well as separate corporate licensing nowadays
[00:27] <ubitux> there was.
[00:27] <ubitux> the code was in at some point, then deleted
[00:27] <JEEB> k
[00:27] <JEEB> makes complete sense
[00:28] <JEEB> it was just someone's basic implementation
[00:28] <ubitux> one good thing (depending on the PoV) of this encoder is that it wasn't gpl iirc
[00:28] <JEEB> yes
[00:28] <JEEB> but now x264 can be licensed
[00:28] <JEEB> from x264 LLC/CoreCodec
[00:28] <JEEB> quite a few closed source apps now use it
[00:29] <ubitux> mmh?
[00:29] <JEEB> you missed that in 2010 or 11 or so?
[00:29] <ubitux> i guess
[00:29] <JEEB> the licensee just has to release their libx264 internal changes to the x264 project
[00:30] <gnafu> It's been a huge moneymaker.
[00:30] <JEEB> and then the x264 developers either integrate those or not
[00:30] <JEEB> gnafu, yeah
[00:30] <gnafu> Like, /huge/.
[00:30] <ubitux> fun, ok
[00:30] <gnafu> And I guess CoreCodec is going to be releasing their AAC encoder under the GPL and doing the same dual-licensing thing with that.
[00:30] <gnafu> So I've heard.
[00:30] <JEEB> yeah, and CoreAVC
[00:31] <gnafu> Ooh, I dunno if I knew about that :-D.
[00:31] <JEEB> ubitux, see the license header @ http://git.videolan.org/gitweb.cgi?p=x264.git;a=blob;f=x264.h;h=f0fbbd63ac5a4ebbf5f198bc3386c1371b91ec20;hb=HEAD
[00:31] <gnafu> That's there really nice H.264 decoder, right?
[00:31] <JEEB> not really /that/ nice any more, but sure -- the more the merrier
[00:31] <gnafu> Hehe.
[00:31] <JEEB> they really couldn't keep up with the features of libavcodec lately'ish
[00:32] <JEEB> after 10bit 4:2:0 and then 4:2:2/4:4:4 support
[00:32] <JEEB> they seem to have implemented those lately'ish but they've really been mostly interested in the b2b side
[01:03] <Compn> yeah they realized these 10bits were only used by anime pirates ;p
[01:03] Action: Compn trolls
[01:03] <JEEB> nah, just that they didn't care about releasing binaries to "end users" any more
[01:03] <JEEB> they did add 10bit support for 4:2:0 before they did that
[01:04] <JEEB> 4:2:2 and 4:4:4 support was then (supposedly) made, but as "end users" don't really bring in revenue -> we won't be seeing that until the GPL'ification
[01:04] Action: Compn wonders why x264 reinventing ffmpeg and not just merging and getting it over with
[01:05] <JEEB> hm?
[01:07] <Compn> JEEB : http://git.videolan.org/?p=x264.git;a=blob;f=x264.c;h=833cf0ed84f290c40dd8faadb3a2568341bc0e61;hb=HEAD
[01:08] <Compn> x264.c , compiled with swscale and lavf 
[01:08] <JEEB> oh
[01:08] <Compn> why did i look at that code, i regret!
[01:08] <JEEB> don't worry, that's not even trying to reinvent ffmpeg
[01:09] <JEEB> basic input and very basic filters back from the time when ffmpeg was much more worse off if you wanted to use x264
[01:09] <JEEB> latter can be largely ignored
[01:09] <JEEB> basic input is just ffms2/libav* input for x264cli
[01:09] <JEEB> x264-audio /used/ to be a thing back a few years ago, because back then using x264 via ffmpeg was what it was. Nowadays no-one sane really recommends it for anything
[01:10] <JEEB> and it's dead
[01:10] <JEEB> never was merged either into x264 mainline
[01:10] <Compn> rm -rf x264.c
[01:11] <JEEB> hey, I like the x264cli. I input from piped y4m and there's still a a couple of tiny-weeny things I can get done better with it than ffmpeg
[01:12] <JEEB> I do agree that for most intents and purposes that need automated stuff, ffmpeg most probably is better off
[01:12] <JEEB> the only thing that is lacking is the autosetting of refs to level in the libx264 encoder
[01:12] <JEEB> which x264cli does
[01:37] <iive> Compn: x264 didn't reinvent ffmpeg, they kind of forked it.
[01:39] <iive> or at least took some portions of it.
[01:41] <cone-868> ffmpeg.git 03Michael Niedermayer 074b2f696d6e50: flashv: use avcodec_set_dimensions()
[01:41] <cone-868> ffmpeg.git 03Michael Niedermayer 07e9cb533fbb90: flashv: check if keyframe is available, fix null deref.
[01:41] <cone-868> ffmpeg.git 03Michael Niedermayer 07580021cfc458: wavpack: check ch_offset
[01:41] <cone-868> ffmpeg.git 03Michael Niedermayer 07d8a1eb11b720: wavpack: check the blocks sample count, fix out of array accesses
[01:43] <JEEB> iive, I don't think that was done, but possibly some parts of ffmpeg were used as inspiration. Personally I just see multiple input modules (avs/raw/y4m/lavf/ffms2) being plugged into the x264cli command line encoder. If you really want to ask more about it I recommend asking kemuri about it
[10:21] <durandal_1707> ubitux: there is no dsize filter alternative?
[10:21] <ubitux> i think you can do the same with the eval in vf scale
[10:21] <ubitux> but i didn't look closer
[10:27] <ubitux> ah, maybe vf aspect is more appropriate for the comparison
[10:28] <divVerent> hm... or the setsar filter?
[10:28] <ubitux> vf aspect is setsar and setdar filters
[10:28] <ubitux> i'm pretty sure dsize is useles with those filters
[10:29] <ubitux> but we need to look closer
[10:29] <divVerent> "mostly useless" ;)
[10:29] <divVerent> what dsize can do what these can't, is setting the output size independently from the input
[10:29] <cbsrobot> michaelni: there are again 2 pull requests on github: https://github.com/FFmpeg/FFmpeg/pulls
[10:30] <ubitux> divVerent: can you provide an example?
[10:30] <divVerent> ubitux: sure
[10:30] <durandal_1707> cbsrobot: lol
[10:30] <divVerent> mplayer foo.avi -vf dsize=160:120
[10:30] <cbsrobot> well at least we could close them
[10:30] <divVerent> that will use a 160x120 window for playing the file
[10:31] <divVerent> obviously this should only affect ffplay :)
[10:31] <divVerent> and maybe codecs that store display size and not aspect ratio
[10:31] <divVerent> not aware of any
[10:33] <divVerent> it's basically kinda equivalent to setting the window size via the -window_size option of ffplay
[10:33] <divVerent> except that it can calculate the window size using width, height and aspect ratio
[10:34] <divVerent> making -window_size accept formulas that can use these variables would basically replace mplayer's -vf dsize entirely
[10:34] <ubitux> ok
[10:34] <ubitux> thx, will have a look
[10:35] <divVerent> also, -vf dsize has some neat stuff you'd otherwise need ffmpeg formuals for
[10:35] <divVerent> e.g. rounding width/height to multiples of N
[10:35] <ubitux> ffplay -f lavfi -i testsrc=s=800x600 -vf mp=dsize=160:120 has no effect :(
[10:35] <divVerent> I assumed that ;)
[10:36] <divVerent> and if you use dsize=160:160, it has one
[10:36] <divVerent> basically, it looks like ffplay only sees the ratio, but not the absolute values
[10:36] <ubitux> mmh dsize=160:120 it just scales to that size for me with mplayer
[10:36] <divVerent> exactly
[10:37] <divVerent> in mplayer, for each image, both the original size and the display size are stored
[10:37] <ubitux> what's the difference with -vf scale=160:120 then?
[10:37] <divVerent> but no aspect ratio data
[10:37] <divVerent> the difference is who scales
[10:37] <divVerent> with -vf dsize, the GPU will scale
[10:37] <divVerent> but using -vf dsize for this is kinda redundant in mplayer
[10:37] <divVerent> unless you use it for the advanced size controls
[10:37] <divVerent> for anything else it supports the X11 standard -geometry option (or should)
[10:38] <ubitux> ooh ok
[10:38] <ubitux> but this filter has only meanings for the player then
[10:38] <divVerent> advanced size controls, as in, e.g. telling it whether to change the width or the height to get the target aspect ratio
[10:38] <ubitux> it has no place in libavfilter
[10:38] <divVerent> it has meanings for encoding too
[10:38] <ubitux> afaiu
[10:38] <ubitux> ah?
[10:38] <divVerent> but there it's redundant with setsar/setdar
[10:38] <divVerent> ;)
[10:38] <ubitux> okay
[10:38] <ubitux> so we can drop dsize? :)
[10:38] <divVerent> and possibly somewhat complex av expressions
[10:39] <divVerent> in my opinion you can drop it
[10:39] <ubitux> durandal_1707 ^ :)
[10:39] <divVerent> in worst case, someone finds a use that will require a somewhat complex av expression for -vf setsar/setdar
[10:39] <divVerent> in that case, we could use the complex expression as example in the manpage
[10:39] <ubitux> one thing i'm concerned about, is the complexity of expressions with vf scale when you want to scale a video keeping the aspect ratio in a given area
[10:40] <ubitux> i don't know if dsize or anything similar solves this problem in mplayer
[10:40] <divVerent> like, there is actually one possible good use of mplayer's dsize that's hard but not impossible to replicate with setsar
[10:40] <divVerent> namely, rounding to "small fractions"
[10:40] <divVerent> because some codecs, e.g. MPEG-4 ASP, only allow numerator and denominator between 1 and 32767
[10:40] <divVerent> and sometimes the input has higher values there
[10:41] <divVerent> this would be, in mplayer:
[10:41] <cone-390> ffmpeg.git 03Michael Niedermayer 07a8f2420e06d5: remove tests/asynth1.sw
[10:41] <divVerent> -vf dsize=640:480:0
[10:42] <divVerent> would change display size to an integer fraction, where numerator is <= 640 and denominator is <= 480
[10:42] <divVerent> actually, rather... -vf dsize=64:64:0 ;)
[10:42] <divVerent> then it should play well with most resolutions to yield a "good" pixel aspect ratio
[10:42] <ubitux> ah that's exactly that.
[10:43] <divVerent> of course, you can do a similar thing with setsar
[10:43] <divVerent> I assume it provides the sar variable, so...
[10:44] <divVerent> -vf setsar='floor(sar*64+0.5):64'
[10:44] <divVerent> and can be made arbitrarily more complex to rather fit known good SARs exactly ;)
[10:44] <ubitux> is that really a good idea to use set sar for this?
[10:45] <divVerent> yes, but 64 is a bad denominator for this
[10:45] <divVerent> I'd use the lcm of the most common SAR denominators
[10:45] <divVerent> it's a good idea mainly for batch encoding
[10:45] <divVerent> if you know the input, you rather should specify the exact SAR you want
[10:46] <divVerent> in fact, mplayer's "display size is always integer" sometimes is screwing up the SAR to begin with :P
[10:46] <divVerent> so you need this kind of operation more in mplayer than in ffmpeg
[10:47] <ubitux> mmh
[10:47] <divVerent> you mainly need it in ffmpeg when transcoding from a "better" to a "worse" codec (e.g. h264 -> mpeg4)
[10:47] <divVerent> and the original file was screwed up by e.g. mplayer/mencoder's aspect ratio handling
[10:48] <divVerent> main thing when it happened to me: when using mplayer's -vf crop filter
[10:49] <divVerent> as normally, both full screen PAL and NTSC videos have integer display sizes
[10:49] <divVerent> but not so after cropping
[10:58] <michaelni> cbsrobot or others, any clue why i received no note by email about these ?
[10:58] <michaelni> there was a time when i did get notes for pull requests
[10:59] <durandal_1707> you disabled spam?
[11:00] <cone-390> ffmpeg.git 03Mans Rullgard 079eda2a85c64e: configure: remove support for -n flag in print_enabled()
[11:00] <cone-390> ffmpeg.git 03Mans Rullgard 07031aac9861db: ppc: fix some unused variable warnings
[11:00] <cone-390> ffmpeg.git 03Mans Rullgard 07a384f6a7f73a: ppc: replace pointer casting with AV_COPY32
[11:00] <cone-390> ffmpeg.git 03Justin Ruggles 075595368bcc6d: amr: set channel_layout
[11:00] <cone-390> ffmpeg.git 03Justin Ruggles 0739f0e9b8c6f7: apc: set channel layout
[11:00] <cone-390> ffmpeg.git 03Justin Ruggles 07b5d1a15d1b29: bethsoftvid: set channel layout
[11:00] <cone-390> ffmpeg.git 03Justin Ruggles 07ff50d27a6391: bfi: set channel layout
[11:00] <cone-390> ffmpeg.git 03Justin Ruggles 072fe804f316db: bink: set channel layout
[11:00] <cone-390> ffmpeg.git 03Justin Ruggles 07e8088d6e4b12: bmv: set channel layout
[11:00] <cone-390> ffmpeg.git 03Justin Ruggles 070d09a5848f49: cdxl: set channel layout
[11:00] <cone-390> ffmpeg.git 03Justin Ruggles 07a05a63785c47: daud: set channel layout
[11:00] <cone-390> ffmpeg.git 03Justin Ruggles 0749e7af06f2fc: dsicin: set channel layout
[11:00] <cone-390> ffmpeg.git 03Justin Ruggles 07d5ca70b10302: dv: set channel layout
[11:00] <cone-390> ffmpeg.git 03Justin Ruggles 07644d8d2e5abc: flvdec: set channel layout
[11:00] <cone-390> ffmpeg.git 03Justin Ruggles 07d4a105ae5c1b: gsmdec: set channel layout
[11:00] <cone-390> ffmpeg.git 03Justin Ruggles 07f6c3adde4192: gxfdec: set channel layout when applicable
[11:00] <cone-390> ffmpeg.git 03Justin Ruggles 0773e2007f3d43: idroqdec: set channel layout
[11:00] <cone-390> ffmpeg.git 03Justin Ruggles 07024e03701c70: iff: set channel layout
[11:00] <cone-390> ffmpeg.git 03Justin Ruggles 0741a2d9590d89: ipmovie: set channel layout
[11:00] <cone-390> ffmpeg.git 03Justin Ruggles 07437113128315: iss: set channel layout
[11:00] <cone-390> ffmpeg.git 03Justin Ruggles 07ef1b23ad21e3: jvdec: set channel layout
[11:00] <cone-390> ffmpeg.git 03Michael Niedermayer 077eb40d85f225: Merge commit 'ef1b23ad21e3f12fc4ff2a73a6d4d4cd9d630c4b'
[11:07] <cbsrobot> michaelni: I read once that as an owner you do not get notifications
[11:07] <cbsrobot> you need another account for it - or something similar
[11:07] <cbsrobot> not sure it still applies
[11:09] <cbsrobot> michaelni: Users in the Owners group dont receive notifications. You need to create a normal team and add yourself to it to get notifications for that teams repos.
[11:09] <cbsrobot> see http://alexking.org/blog/2011/11/28/not-getting-github-notifications
[11:13] <michaelni> cbsrobot, i had done that and it worked after that but now it doesnt work anymore
[11:18] <cone-390> ffmpeg.git 03Justin Ruggles 0787199d34db5d: mm: set channel layout
[11:18] <cone-390> ffmpeg.git 03Justin Ruggles 07f24b0b1b6cc3: mmf: set channel layout
[11:18] <cone-390> ffmpeg.git 03Justin Ruggles 07f6c6e5aac12e: mpc7: set channel layout
[11:18] <cone-390> ffmpeg.git 03Justin Ruggles 0766d7ceb4aa0a: mvi: set channel layout
[11:18] <cone-390> ffmpeg.git 03Justin Ruggles 07cc57228e31ac: mxg: set channel layout
[11:18] <cone-390> ffmpeg.git 03Justin Ruggles 07232e9c4c4bed: nuv: set channel layout
[11:18] <cone-390> ffmpeg.git 03Justin Ruggles 07d4088efbe22f: oggparsespeex: validate channel count and set channel layout
[11:18] <cone-390> ffmpeg.git 03Justin Ruggles 07c9759eb426ea: omadec: set channel layout
[11:18] <cone-390> ffmpeg.git 03Justin Ruggles 07b5e3e77711c6: psxstr: set channel layout
[11:18] <cone-390> ffmpeg.git 03Justin Ruggles 07444b79c18acc: qcp: set channel layout
[11:18] <cone-390> ffmpeg.git 03Justin Ruggles 0760a585304c28: rmdec: set channel layout for RA version 3
[11:18] <cone-390> ffmpeg.git 03Justin Ruggles 07ce842029ce97: rsodec: set channel layout
[11:18] <cone-390> ffmpeg.git 03Justin Ruggles 07c1ac602d53ab: rtpdec_amr: set channel layout
[11:18] <cone-390> ffmpeg.git 03Justin Ruggles 07a634896cf81b: sierravmd: set channel layout
[11:18] <cone-390> ffmpeg.git 03Justin Ruggles 0757e590e4b8b9: siff: set channel layout
[11:18] <cone-390> ffmpeg.git 03Justin Ruggles 07bfccd76adb51: smacker: set channel layout
[11:18] <cone-390> ffmpeg.git 03Justin Ruggles 071c7587728c81: sol: set channel layout
[11:18] <cone-390> ffmpeg.git 03Justin Ruggles 07a3949fe11fc7: swfdec: set channel layout
[11:18] <cone-390> ffmpeg.git 03Justin Ruggles 077f348bd764e1: tiertexseq: set channel layout
[11:18] <cone-390> ffmpeg.git 03Justin Ruggles 07a94b0267f2e1: tmv: set channel layout
[11:18] <cone-390> ffmpeg.git 03Justin Ruggles 072ce7f820d46a: wc3movie: set channel layout
[11:18] <cone-390> ffmpeg.git 03Justin Ruggles 077b48d93e8abb: westwood_aud: set channel layout
[11:18] <cone-390> ffmpeg.git 03Justin Ruggles 07935fbb66ef32: wtv: set channel layout for mpeg audio
[11:18] <cone-390> ffmpeg.git 03Justin Ruggles 07b9629acb6b64: yop: set channel layout
[11:18] <cone-390> ffmpeg.git 03Michael Niedermayer 07799d749c77de: Merge remote-tracking branch 'qatar/master'
[11:56] <burek> this guy summarized it all :D "The libav people lied and tried to pass their fork off as a rename to casual users. I have no respect for liars."
[11:57] <burek> wrong window :D sorry :D
[12:18] <cone-390> ffmpeg.git 03Stefano Sabatini 078cb76ef275f7: lavc/libtheoraenc: return proper error codes
[12:18] <cone-390> ffmpeg.git 03Stefano Sabatini 079d2a7c04812a: doc/encoders: document libtheora encoder
[12:18] <cone-390> ffmpeg.git 03Stefano Sabatini 07794566520018: lavfi: store and propagate number of channels information in audio buffer properties
[12:43] <burek> is there a way to see versions of compiled external libraries into ffmpeg?
[12:43] <burek> for example, if i want to see what version of libx264 was used when compiling static ffmpeg
[13:29] <durandal_1707> michaelni: they renamed lavu/audioconvert to channel_layout but did not updated avcodec.h
[13:34] <durandal_1707> this just sucks
[13:36] <cone-390> ffmpeg.git 03Michael Niedermayer 07e97a24109c62: avcodec.h: update audioconvert.h header after rename
[13:38] <durandal_1707> michaelni: lol, but i was going to replace all such headers in whole repo
[13:39] <durandal_1707> instead of practise to make myriad commits that shold be squashed into single one
[13:41] <durandal_1707> michaelni: libswresample/audioconvert.h does need lavu/audioconvert.h?
[13:46] <saste> burek: apparently not
[13:47] <michaelni> durandal_1707, try it, if it compiles without or with channel_layout then it didnt need it
[13:49] <durandal_1707> michaelni: well, it may still include it via another header, so i do not do such practice but instead explore contets of file that includes such header
[14:18] <burek> saste, ok thanks
[14:24] <cone-390> ffmpeg.git 03Paul B Mahol 071acd2f6ba7bc: Replace rest of libavutil/audioconvert.h with libavutil/channel_layout.h
[14:27] <cone-390> ffmpeg.git 03Paul B Mahol 0709a0392341ac: paf: set channel layout
[14:34] <ubitux> http://b.pkh.me/0001-ffserver-use-avcodec_descriptor_get_by_name-to-ident.patch  anyone mind this?
[14:35] <ubitux> it looks like a regression to me
[14:35] <ubitux> since "AudioCodec mp3" seemed to work at some point
[14:36] <ubitux> (according to the documentation example)
[14:49] <ubitux> it's kind of a pain to look for a memleak in ffserver&
[14:50] <ubitux> there is no free; most of the "leaks" are harmless, but it's kind of a pain to find the one important :(
[14:55] <michaelni> you could free all things at "exit"
[14:56] <michaelni> and take over ffserver maintaince 
[14:56] <ubitux> i'm trying to fix the leaks yeah, there are a lot of them in the parse_option
[14:56] <ubitux> i guess that's related to the string thing again
[15:42] <j-b> michaelni: hey. yadif is LGPL, but not the asm for x86. Right?
[15:44] <ubitux> yadif looks gpl to me
[15:44] <ubitux> j-b: see the LICENCE file for the gpl stuff
[15:45] <ubitux> and grep '_deps=.*gpl' configure
[15:45] <j-b> ok
[15:46] <michaelni> j-b, GPL but there are multiple companies who offer money to relicense to LGPL, its just slow 
[15:46] <michaelni> someone still needs to make a list of authors and contact them
[15:46] <j-b> ok
[15:47] <michaelni> there was someone on the ffmpeg-devel ML that may or may not be working on that
[15:47] <burek> Google Pagerank for: ffmpeg.org  7/10
[15:47] <burek> nice :)
[15:47] <burek> wikipedia has got 9
[15:48] <j-b> videolan has 8 since years
[15:49] <burek> very good :)
[15:50] <cone-390> ffmpeg.git 03Michael Niedermayer 07327cd0d09b45: mpegts: prevent freeing ones own section in pmt_cb
[15:50] <cone-390> ffmpeg.git 03Michael Niedermayer 074facddd568b7: mpegts: dont set stream info when a decoder has already been opened.
[15:57] <ubitux> btw, how should we test test ffserver?
[15:58] <burek> let's put some webcams :D
[15:59] <ubitux> :)
[16:27] <Compn> j-b / michaelni : well , michael could relicense the first version of yadif under lgpl if he wanted, before anyone made any additions to it :P
[16:27] <Compn> i think it was all his code on that first commit :)
[16:28] <j-b> Compn: I was just wondering, because some people on some mailing lists were saying weird things
[16:28] <Compn> ah
[16:28] <Compn> its currently gpl 
[16:28] <j-b> yes
[16:28] <j-b> and hqnd3d too (asm is LGPL though...)
[16:29] Action: durandal_1707 looking for ast files
[16:31] <Compn> pretty amazing yadif is still considered the best deint
[16:31] <Compn> 6 year old filter
[16:31] <j-b> Not the best, but the best real-time one
[16:31] <Compn> ah
[16:31] <durandal_1707> ^ exactly
[16:33] <j-b> As far as I am concerned, people were always whinning about deinterlacing until we integrated michaelni's yadif. Now not a user scream.
[16:37] <Compn> :)
[16:39] <ubitux> <@j-b> and hqnd3d too (asm is LGPL though...) // then use a asm-to-C tool to get some lgpl version of it
[16:40] <j-b> lol
[16:41] <Compn> dont think thats clean room :P
[16:41] <Compn> looking at mplayer svn history of yadif 
[16:42] <Compn> only seems like reimar, loren, iive and michael have copyrightable changes
[16:42] <Compn> unless i missed something
[16:50] <iive> i don't think I have changes in ffmpeg yadif, i have recent fix in the mplayer one.
[16:51] <iive> the avfilter yadif have the problem fixed in a different way.
[16:51] <Compn> aj
[16:51] <Compn> er ah
[18:04] <cone-390> ffmpeg.git 03Michael Niedermayer 07a0212ecf8452: dcadec: check layout & channel count for consistency.
[18:04] <cone-390> ffmpeg.git 03Michael Niedermayer 07c74cd99986fc: rv10: consider B frames in low delay streams invalid.
[19:28] <cone-390> ffmpeg.git 03Michael Niedermayer 071bd024ec770e: mpeg4videodec: split static decoder table init out
[19:28] <cone-390> ffmpeg.git 03Michael Niedermayer 077c76eaeca279: mpeg4video_parser: init static tables before use, fix nulll ptr deref
[20:07] <cone-390> ffmpeg.git 03Clément BSsch 0741ebbb3b0462: lavf/wtvenc: fix s[tp]_pairs memleak.
[20:16] <durandal_1707> my kudorank is 8
[20:16] <j-b> on ohloh?
[20:17] <durandal_1707> there are others?
[20:17] <j-b> yes
[20:17] <j-b> where is your profile?
[20:17] <j-b> getting kudos from highly ranked people should help a lot.
[20:17] <ubitux> durandal_1707: kochira koso~
[20:18] <durandal_1707> ubitux: ?
[20:18] <ubitux> seems i'm level 8 as well
[20:18] <ubitux> no idea what that means
[20:19] <j-b> it means you are participating to a highly used project, but you have not many kudos in.
[20:20] <j-b> Getting 2 or 3 kudos from higher ranked people should get you to 9 without issues
[20:20] <ubitux> is it a role playing game for developers?
[20:21] <j-b> Well, a bit
[20:21] <JEEBsv> e-penis comparison thingy / a way to take care of one's OCD / supposed way of showing people what you've done
[20:22] <j-b> there are a lot of github analyzers too
[20:22] <j-b> and they appear on your resume
[20:22] <JEEBsv> yeah
[20:22] <JEEBsv> coderwall etc.
[20:22] <ubitux> ok
[20:23] <j-b> coderwall is a bit more annoying than ohloh
[20:23] <j-b> ubitux: well, kudos is a way of leveraging the social part: to get higher rank, you need to "build" your community, de facto.
[20:24] <ubitux> sounds like a web 2.0 hipster playground
[20:24] <JEEBsv> indeed
[20:24] <j-b> So?
[20:24] <ubitux> so nothing :p
[20:24] <j-b> It does not cost much to create a profile
[20:24] <j-b> or claim contributions or asked for kudos
[20:25] <ubitux> does it do anything good?
[20:25] <j-b> but if you ever need to look for work
[20:25] <j-b> ubitux: you are 50 and you are never going to look for work?
[20:25] <ubitux> well i guess i won't have any money left in a few months
[20:25] <ubitux> so i'll reconsider if i don't find a job then :)
[20:26] <j-b> Stupid, IMVHO.
[20:26] <ubitux> what is stupid?
[20:26] <j-b> Well, it is like linkedin, building it takes time. So you should do it when you don't need it.
[20:26] <ubitux> i don't have a linkedin either
[20:26] <ubitux> no facebook as well
[20:26] <j-b> Stupid, IMVHO.
[20:26] <ubitux> *but*!
[20:27] <ubitux> i have a myanimelist!
[20:27] <ubitux> (and a github)
[20:27] <j-b> Everyone can have a github account with 3 followers...
[20:27] <ubitux> i have 20!
[20:27] Action: durandal_1707 0
[20:28] <j-b> Having a 500+ linkedin profile or claiming contributions to very-used project is a bit harder, though
[20:28] <ubitux> is that so hard to find a job?
[20:28] <ubitux> s/that/it/
[20:29] <ubitux> (is it that hard*, meh english.)
[20:29] <j-b> Now? Maybe not. In 5 years, how do you know?
[20:29] <ubitux> i guess i have 5yr to open a linkedin account then
[20:29] <ubitux> and since it will be replaced by 3 differents services since then&
[20:30] <j-b> I understand the no-facebook. I have a harder time understanding the no-linkedin profile or worse ohloh, where your profile is already there!
[20:30] <ubitux> i'm not that fond of creating profiles of myself, and centralizing such information
[20:31] <ubitux> i use github because i don't trust gitweb and stuff on my box, and i use myanimelist because it keeps references up-to-date
[20:31] <j-b> and yet, your ohloh profile already exists.
[20:32] <ubitux> yes, but i don't want to memorize another random password
[20:32] <j-b> openid
[20:32] <ubitux> and if the profile is already there, what's the point?
[20:32] <j-b> because you can merge them
[20:33] <ubitux> merge what? profiles on different projects within ohloh?
[20:33] <j-b> yep
[20:34] <ubitux> i don't think i wish to participate in something else than ffmpeg atm anyway :)
[20:35] <iive> j-b: you can just give them link to your KGB file. no need for other pro-files  ;)
[20:36] <ubitux> j-b: do you think it really is a problem not to sell yourself like a slave on the web? :P
[20:59] <j-b> ubitux: because you are not already sold?
[21:00] <ubitux> not anymore, i'm free \o/
[21:02] <Compn> linkedin is hilarious
[21:02] <Compn> because people are stupid
[21:02] <j-b> and yet you are doing for free stuff thatthe biggest evil companies are using.
[21:02] <Compn> i tried messaging a few people on linked in, and they reply with 'who are you' 
[21:03] <Compn> these social networking sites are stupid that dont accept private messages unless you friend them
[21:03] <Compn> but these people dont friend people they dont know
[21:03] <Compn> :V
[21:03] <ubitux> j-b: sure, good for them
[21:03] <j-b> untrue. You can do that both on linkedin and facebook.
[21:04] <Compn> was a few years ago i last tried linked in
[21:04] <Compn> maybe it chang-ed
[21:04] <Compn> ugh
[21:04] Action: Compn got joolz and j00ru mixed up
[21:04] <Compn> derp
[21:09] <iive> Compn: this is why they are called social. They recreate your real social life.
[21:12] <ubitux> social stuff are just an hypocrit a masquerade, or a game
[21:12] <ubitux> -a
[21:14] Action: ubitux doesn't want to play much
[21:57] <cone-390> ffmpeg.git 03Michael Niedermayer 073669915e93b3: dvdec: check ipcm more completely, avoid assert failure.
[21:57] <cone-390> ffmpeg.git 03Michael Niedermayer 074392e69ad4e4: mov: check stps correctly, avoid overreading 1 element.
[21:57] <cone-390> ffmpeg.git 03Michael Niedermayer 07eab022d863c8: mpegts: prevent freeing ones own section in pat_cb
[21:57] <cone-390> ffmpeg.git 03Michael Niedermayer 077373b3ad043c: pcmdec: consistently use codec_id, fixes out of array reads
[22:25] <cone-390> ffmpeg.git 03Michael Niedermayer 07b1191331363c: avrndec: calculate true_height only when used.
[22:25] <cone-390> ffmpeg.git 03Michael Niedermayer 07001af703c6bf: alac: check channel count more completely, fix out of array read
[22:25] <cone-390> ffmpeg.git 03Michael Niedermayer 07af9ec3dd1d9e: av_probe_input_format3: support NULL as buffer. Fixes null ptr deref
[22:58] <cone-390> ffmpeg.git 03Stefano Sabatini 079a2028d4f4d6: lavfi/frei0r: correctly handle paths longer than 1023 chars
[22:58] <cone-390> ffmpeg.git 03Stefano Sabatini 07334a0d15c6ac: lavfi/frei0r: add additional trailing slash in FREI0R_PATH paths
[23:51] <saste> why people who manage to inscribe themselves to a mailing list fail to read documentation?
[23:52] <beastd> saste: lazyness can be virtue or curse depending on how you apply it
[23:52] <saste> i suppose they're trying to save time...
[00:00] --- Wed Nov 14 2012