[00:00:58] <dalias> :/ [00:01:37] <mru> dalias: now that your libc is more or less done, will you do a compiler too? [00:05:32] <dalias> :) [00:05:39] <dalias> that sounds a lot more difficult [00:05:50] <mru> you're probably right [00:06:06] <dalias> libc is "easy" because most functionality is self-contained [00:06:54] <mru> and much of it is trivial [00:07:32] <dalias> the only parts with any major cross-interaction are stdio/locale/malloc/pthread/regex [00:07:52] <mru> I was going to say stdio, malloc, and pthreads [00:08:01] <mru> I don't care much about locale [00:08:32] <mru> how much is libc regex actually used? [00:09:48] <dalias> regex is not used by other things [00:09:55] <dalias> but it depends on locale to some extent [00:09:56] <mru> I mean by apps in general [00:10:22] <dalias> lots of apps don't use it because they either don't trust it to be a good implementation, or they want to know they have certain extensions :( [00:10:39] <mru> gnu grep and friends probably use their own [00:10:50] <dalias> however using the libc regex is the only way you can get access to collation classes [00:11:02] <mru> how so? [00:11:12] <dalias> gnu grep and friends basically do a test if (libc=glibc) use libc else use their own [00:11:35] <dalias> the [=sym=] stuff [00:11:52] <dalias> there's no other api but regex to access that part of the locale data [00:12:23] <dalias> strxfrm uses it but doesn't really provide the application any info other than giving a sort key for the string [00:12:54] <dalias> i would like to eventually support collation classes [00:14:21] <mru> an application could duplicate the entire locale system [00:14:35] <dalias> yeah but then it can't ensure that it matches the system's [00:14:59] <mru> many locales are well-defined [00:15:04] <dalias> and therefore it might not correctly support the user's locale requirements [00:16:16] <dalias> that works for widely-used locales, but if the user has had to define their own or make fixes to their own, an application insisting on using its own version might break :/ [00:16:41] <dalias> at least in the past, glibc was notorious for being extremely slow in following unicode [00:17:23] <dalias> so if your language was one only recently encoded by unicode, or that recently got new important characters added, or that was just never properly tested, you might encounter trouble :( [00:17:34] <mru> yeah, I'm sure there'd be problems in reality [00:18:08] <dalias> i dunno if it's been fixed, but glibc used to consider all non-spacing combining characters (class Mn in unicode) non-letters [00:18:25] <dalias> which breaks many languages, including tibetan, which have non-spacing letters [00:19:05] <dalias> in theory it also breaks hebrew with vowels (which usually aren't written), and thai, i think [00:19:30] <dalias> in that [[:alpha:]]+ will fail to match words in these languages [00:19:44] <mru> great [00:20:19] <mru> I can understand tibetan quirks being overlooked, but hebrew and thai are rather common, no? [00:20:28] <dalias> as long as the application is going thru the libc for locale, at least this is fixable (either the user can fix it locally with localedef, or get it fixed upstream) [00:21:24] <dalias> but if you're bypassing libc and doing it yourself, you need to be extra-careful to use correct character data from unicode, rather than just rolling your own or copying "known correct" data from glibc [00:21:39] <dalias> otherwise you'll make it impossible for users of certain languages to get proper support [00:21:57] <mru> say hi to my enterprise java application [00:28:40] <mru> binutils 2.18 works [00:28:49] <mru> 2.19 and later all fail [00:29:09] <mru> and what's worse, they fail to link anything produced by recent llvm-gcc [00:32:32] <Kovensky> oh, a dalias [00:35:42] <asdf1234> is anyone going to tell Rukhsana Ruby to stop top posting [00:37:51] <kierank> I thought it was someone just asking how to use get but I guess "the url of the repo" is a plausible question to ask right now [00:40:36] <kierank> git* [00:46:29] <dalias> kovensky, ? [01:14:26] <BBB> hah, I have it neared down to a five-liner change [01:27:32] <BBB> http://llvm.org/bugs/show_bug.cgi?id=9307 [01:28:50] <Dark_Shikari> nice [01:29:59] <Compn> isnt ffmpeg in the clang testsuite by now ? [01:30:01] <Compn> ehhe [01:35:23] <BBB> it should be [01:35:27] <BBB> Dark_Shikari: btw that is your patch [01:35:33] <BBB> Dark_Shikari: go be ashamed, you broke clang! :-p [01:35:37] <BBB> (good job!) [01:35:58] <Kovensky> BBB: in case it isn't in the testsuite, open a bug saying that ffmpeg isn't in the testsuite \o/ [01:45:30] <dalias> lol [01:45:32] <dalias> http://www.ohse.de/uwe/articles/whyidontsendapatch.html [01:47:15] <roxfan> o.O a fax [01:47:56] <BBB> probably for copyright transfer agreements [01:48:04] <roxfan> oh [01:49:02] <dalias> yeah [01:54:31] <saintdev> ruggles: http://dpaste.com/442957/ [02:06:21] <dalias> mru, any luck finding me someone for arm port? :) [02:27:41] <mru> dalias: I wasn't aware I was your personal headhunter [02:29:16] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles@gmail.com> master * ra58bcb40b1 ffmpeg/libavcodec/vmdav.c: [02:29:16] <CIA-15> ffmpeg: vmdaudio: fix raw_block_size calculation. [02:29:16] <CIA-15> ffmpeg: The size should depend on the output sample size, not the internal bit depth. [02:29:16] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com> [02:29:18] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles@gmail.com> master * r1328d43313 ffmpeg/libavcodec/vmdav.c: [02:29:18] <CIA-15> ffmpeg: vmdaudio: remove duplicated code by merging mono and stereo decoding. [02:29:18] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com> [02:29:26] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles@gmail.com> master * r9b73f78600 ffmpeg/ (libavcodec/vmdav.c tests/ref/fate/sierra-vmd): [02:29:26] <CIA-15> ffmpeg: vmdaudio: output audio samples for standalone silent blocks. [02:29:26] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com> [02:29:28] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles@gmail.com> master * rdd1af5136f ffmpeg/libavcodec/vmdav.c: [02:29:28] <CIA-15> ffmpeg: vmdaudio: use macros and a local variable for block type. [02:29:28] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com> [02:29:34] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles@gmail.com> master * r6989cb2dae ffmpeg/libavcodec/vmdav.c: [02:29:34] <CIA-15> ffmpeg: vmdaudio: correct the silent chunk count in the first block. [02:29:34] <CIA-15> ffmpeg: This fixes A/V sync with several samples, notably: [02:29:39] <CIA-15> ffmpeg: http://samples.mplayerhq.hu/game-formats/sierra-vmd/swat_*.vmd [02:29:39] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com> [02:29:39] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles@gmail.com> master * r2d213695fc ffmpeg/libavcodec/vmdav.c: [02:29:39] <CIA-15> ffmpeg: vmdaudio: simplify buffer pointer and header size handling. [02:29:40] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com> [02:29:40] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles@gmail.com> master * r7a4fb3fd93 ffmpeg/libavcodec/vmdav.c: [02:29:41] <CIA-15> ffmpeg: vmdaudio: set *data_size to zero when skipping small packets and add a warning log message. [02:29:41] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com> [02:29:42] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles@gmail.com> master * r22f893e1c9 ffmpeg/libavcodec/vmdav.c: [02:30:24] <CIA-15> ffmpeg: vmdaudio: validate block type [02:30:24] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com> [02:33:39] <BBB> ruggles: the rest of your patches doesn't apply, or I'm applying in the wrong order [02:34:02] <mru> aren't they numbered? [02:41:09] <BBB> mru: I aplied them in that order [02:41:11] <BBB> but they stopped applying [02:41:42] <BBB> gmail displays subjects of thread starters, not thread followers [02:42:02] <BBB> so if you send patches as updates in threads but in different order, such as what happened here, I can't see what the order is in my inbox anymore [02:43:49] <mru> they are numbered in the subject, no? [02:45:13] <BBB> yes but if the order changes [02:45:20] <BBB> let's say I had 16 patches numbered 1-16 [02:45:25] <BBB> now I reorder them for whatever reason [02:45:30] <BBB> so what used to be patch 1 is now 3 [02:45:34] <mru> then you have only yourself to blame [02:45:34] <BBB> with 2 new patches before it [02:46:26] <BBB> for using gmail? [02:47:09] <mru> for reordering dependent patches [02:47:12] <mru> and for using gmail [02:48:10] <dalias> mru, :) [02:54:05] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles@gmail.com> master * r8e9027d266 ffmpeg/libavcodec/vmdav.c: [02:54:05] <CIA-15> ffmpeg: cosmetics: remove debugging cruft [02:54:05] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com> [02:54:16] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles@gmail.com> master * r762b386e4a ffmpeg/libavcodec/vmdav.c: [02:54:16] <CIA-15> ffmpeg: vmdaudio: move all silence chunk handling to vmdaudio_loadsound(). [02:54:16] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com> [02:54:18] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles@gmail.com> master * r868f2f4d90 ffmpeg/libavcodec/vmdav.c: [02:54:18] <CIA-15> ffmpeg: cosmetics: reindent after previous commit [02:54:18] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com> [02:54:21] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles@gmail.com> master * rba9516cca8 ffmpeg/libavcodec/vmdav.c: [02:54:21] <CIA-15> ffmpeg: cosmetics: reindent after previous commit [02:54:21] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com> [02:54:24] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles@gmail.com> master * r1574eff3d2 ffmpeg/libavcodec/vmdav.c: [02:54:24] <CIA-15> ffmpeg: vmdaudio: simplify vmdaudio_decode_frame() by handling block_type first, then making a single call to vmdaudio_loadsound(). [02:54:24] <CIA-15> ffmpeg: This also adds output buffer size checks for AUDIO and SILENCE block types. [02:54:24] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com> [02:54:27] <BBB> wtf @ gmail [02:54:38] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles@gmail.com> master * r1108f8998c ffmpeg/ (libavcodec/vmdav.c tests/ref/fate/sierra-vmd): [02:54:38] <CIA-15> ffmpeg: vmdaudio: output 8-bit audio as AV_SAMPLE_FMT_U8. [02:54:38] <CIA-15> ffmpeg: There is no need to expand to 16-bits. Just use memcpy() to copy the raw data. [02:54:38] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com> [02:54:38] <BBB> note how there's two patches called "reindent after previous commit" [02:54:40] <BBB> guess what gmail did [02:54:41] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles@gmail.com> master * r2ec7862db8 ffmpeg/libavcodec/vmdav.c: [02:54:41] <CIA-15> ffmpeg: vmdaudio: remove unnecessary fields from VmdAudioContext and use the corresponding AVCodecContext fields instead. [02:54:41] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com> [02:54:42] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles@gmail.com> master * r1e86d685e0 ffmpeg/libavcodec/vmdav.c: [02:54:42] <CIA-15> ffmpeg: vmdaudio: add out_bps to VmdAudioContext and use it to replace hard-coded sample size. [02:54:42] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com> [02:54:47] <BBB> IT PUT THEM IN THE SAME THREAD [02:54:52] <BBB> that's why they didn't apply [02:54:59] <BBB> crap [02:55:01] <BBB> anyway [02:55:03] <BBB> applied now [03:07:15] <DrMcCoy> You know, ScummVM currently has a VMD decoder that works for, to my knowledge, all VMD files up to the ones in later Addy games (around 1999) :P [03:08:32] <DrMcCoy> ffmpeg currently locks up in, for example, the Woodruff intro. And the GK2 sound has clicks :P [03:10:09] <DrMcCoy> Also, Urban Runner's VMDs have the video frame data Indeo3 encoded [03:15:52] <astrange> file a bug about the lockup, that's a low-grade security issue [03:20:26] <DrMcCoy> Hmm, on second look, it seems to be rather strange behaviour on pause than a straight lookup. It did continue after more than 60 seconds of stalling [03:20:55] <DrMcCoy> Just thought I'd let you know, since there's apparently someone just now working on vmdaudio [03:21:12] <Compn> i think we knows about such issue [03:21:16] * Compn checks roundup [03:21:22] <DrMcCoy> Okays [03:21:56] <Compn> well its not in roundup [03:21:59] <Compn> so could add it [03:22:03] <Compn> :) [03:24:22] <BBB> astrange: what should I do with your -mt patches? you asked me to hold off for now with the 2 you posted, should I wait still? [03:24:53] <astrange> yes. i have a gdb session open on a deadlock with them [03:25:01] <astrange> and i haven't had time to touch it since i opened it :/ [03:25:10] <BBB> heh :) [03:25:19] <BBB> can I help with anything? [03:25:34] <BBB> should I make ffmpeg.c autodetect #thread on -threads0 by reading /proc or so? [03:26:02] <astrange> POSIX method is sysconf(_SC_NPROCESSORS_ONLN) * 1.5 [03:26:37] <astrange> a patch setting that for threads==0 is fine with me. i don't have enough cores to benchmark the * x factor [03:26:44] <astrange> but i'm pretty sure 1.5 is right [03:26:56] <astrange> the deadlock command with those patches is '--args ./ffplay_g -threads 3 /Users/astrange/Downloads/angels_480-huffyuvcompress.avi' [03:27:09] <astrange> with http://samples.mplayerhq.hu/V-codecs/HuffYUV/angels_480-huffyuvcompress.avi [03:27:28] <astrange> gdb --args [03:27:31] <BBB> can't help, I only have 2 cores, I think [03:27:37] <astrange> i can get back to it maybe tomorrow, definitely friday [03:27:54] <BBB> but we can do 1.5 as a start, and then finetune it when someone has a better testcase [03:28:12] <BBB> also, can we already do _both_ slice-based and frame-based mt? [03:28:23] <BBB> for h264 on super-multi-core systems that might provide slight extra benefits [03:29:23] <astrange> it's theoretically possible but not implemented in any codec [03:30:01] <astrange> i think it nearly works if you set thread_count = something active_thread_type = 3 on a frame thread's context in h264 (in the -mt repository) [03:30:27] <astrange> it'd be better to actually respect thread_count. the plan there is basically to count the slices in the previous frame then steal that many threads and use them for slices in the next frame [03:30:54] <astrange> also slice threading in h264 is actually broken atm. the frame crcs don't match. but i don't think the error is visible [03:31:49] <BBB> dark_shikari complained about something related to that also [03:32:22] <BBB> doing this in something like h264 shouldn't be difficukt [03:32:56] <BBB> i.e. not more difficult than frame-based and slice-based separately [03:33:13] <BBB> then again I'm likely missing all kind of details [03:34:25] <astrange> nothing hard about it at all. you just have to turn it on and find the memory allocations you forgot to add [03:38:46] <BBB> fair enough, I can work on that... there's other stuff I wanted to do also, like adding a LIBRARY_SUPPORTS_THREADS like flag for x264 [03:39:09] <BBB> and a CODEC_CAP_SLICE_THREADS so that we don't uselessly allocate threads if the codec doesn't support it [03:39:36] <BBB> and then some way to detect slice-threads in use so we can optimally combine slice-threads and frame-threads [03:39:53] <BBB> if a particular file has only 1 slice, it makes no sense to allocate 2 frame-threads and 8 slice-threads [03:40:04] <BBB> better do 9-1 [03:40:19] <BBB> and if the file has 8 slices, maybe do 6-4, or something, I don't know what the math would be [04:15:18] <peloverde> "Lots of people have talked here about the difficulty in reusing OpenSSL. I once had the distinct displeasure of trying to reuse ffmpeg as a library." [04:15:48] <peloverde> BBB: just access you ffmpeg label via imap [04:16:48] <peloverde> also doesn't linus use gmail [04:16:57] <Dark_Shikari> astrange: michael broke it [04:17:04] <Dark_Shikari> when he reordered how deblocking was done [04:17:13] <Dark_Shikari> his per-row deblocking is broken in the case of slice threading [04:17:19] <Dark_Shikari> the error is DEFINITELY visible [04:17:30] <Dark_Shikari> we found it when testing gaikai, the error propagates until it's atrocious [04:18:17] <kierank> peloverde: thought the quote was from linus [04:18:27] <saintdev> that sounds like lagarith, except that's defined as part of the format ^_^ [04:22:10] <Compn> peloverde : hyc found some good openssl alternatives ... [04:22:30] <Compn> Dark_Shikari : did you report bug to michaelni ? [04:22:48] <Dark_Shikari> yes [04:22:48] <Dark_Shikari> ages ago [04:22:52] <Dark_Shikari> he has no interest in fixing it [04:23:02] <Dark_Shikari> I have bothered him repeatedly [04:42:50] <saintdev> well, I seem to have successfully made ffaac _worse_ [04:42:52] <saintdev> \o/ [04:45:28] <kierank> hurry up and commit [04:47:19] <j45> so do the opposite of what made it worse ;) [04:47:39] <Dark_Shikari> that often makes it worse too [04:47:54] <j45> :p [04:53:44] <saintdev> j45: it's not like negative and positive: !worse != better ... !worse == worser [06:06:00] <peloverde> then fix it yourself or revert it? [06:06:49] <saintdev> peloverde: intermediate steps. just happened to listen to the output, and lol'd [06:24:18] <benoit-> moin [07:38:21] <Dark_Shikari> http://doom10.org/index.php?topic=1353.0 stupid of the day [07:40:18] <elenril> how do i shot web? [07:40:36] <Dark_Shikari> please send me teh codez [08:04:12] <peloverde> exec("neroAacEnc"); problem solved? [08:08:44] <spaam> yes. [08:23:54] <saintdev> hmm, limiting min_snr seems to help quality. and lowers bitrate! [08:40:30] <lu_zero> uh? [08:40:34] <lu_zero> good morning [08:40:44] <spaam> lu_zero: hur är det? :) [08:44:18] <lu_zero> spaam: sett bättre dagar [08:44:30] <lu_zero> if google translate is ok [08:44:35] <spaam> yes :) [08:46:17] <thresh> kshishkov: http://top.rbc.ru/society/24/02/2011/549203.shtml [08:46:23] * lu_zero should check the pronounce [08:47:23] <kshishkov> lu_zero: here you are - http://slayradio.com/mastering_swedish_lesson_3.php it has both speech and text [08:48:18] <kshishkov> thresh: Нургалиев наградил? [08:48:32] <lu_zero> kshishkov: iknow has something but I hadn't the time to clear it yet [08:48:45] <lu_zero> (and I should review my japanese scorecards as well =P) [08:49:03] <kshishkov> lu_zero: I never scored anything in Japanese, easy for me [08:49:29] <thresh> kshishkov: ага, и опустил нанопрезидента [08:49:34] <lu_zero> I need to setup the ime/deadkeys to write the accents =P [08:49:55] <lu_zero> japanese has a builtin js ime so it was easier [08:50:30] * lu_zero has left halfway the french sets since he couldn't type easily the accents... [08:50:30] <kshishkov> thresh: а нефиг под ногами у взрослых мешаться! [08:51:32] <kshishkov> lu_zero: I just assigned combine key, I don't need those weird European letters that much [08:51:53] <lu_zero> kshishkov: how did you set it up? [08:51:58] <saintdev_> privet [08:52:12] * saintdev_ has exhausted his russian knowledge [08:55:57] <lu_zero> what's the difference between sett and Jag ser? [08:56:12] <kshishkov> sett is supine IIRC [08:56:19] <kshishkov> jag ser is "I see" [08:56:49] * lu_zero fed the same expression in different languages [08:57:58] <kshishkov> lu_zero: and look at http://en.wikipedia.org/wiki/Compose_key [09:02:13] <lu_zero> uhmm [09:02:21] * lu_zero will have to remap some of those [09:04:29] <merbzt> is any merge happy person awake ? [09:04:57] <kshishkov> mergentainers? [09:07:55] <cartman> moin [09:09:33] <kshishkov> moinli</KotH-mode> [09:13:34] * KotH stabsli kshishkovli [09:14:20] <kshishkov> KotH: that sounds like that troll book [09:15:04] <lu_zero> merbzt: I'm sad but I'm around [09:15:25] <cartman> wbs: \o/ [09:15:30] <KotH> lu_zero: sad? [09:15:39] <cartman> wbs: send me the Mac gcc patch as an attachment please? :) [09:15:43] <lu_zero> KotH: yup =P [09:15:58] <wbs> cartman: I'm working on it, I'll push it to review.source.android.com when I'm done with it [09:16:04] <cartman> wbs: cool! [09:18:36] <merbzt> lu_zero: sad about what ? [09:19:00] <merbzt> lu_zero: and I need a merge of the mp4 muxing patches from Maksym [09:19:51] <kshishkov> merbzt: ask mru/siretart/BBB when any of them is here [09:20:48] * siretart notices a hilight [09:21:30] <merbzt> siretart: [FFmpeg-devel] [PATCH] mov tkhd' width and height usage [09:22:34] <lu_zero> merbzt: let me have a look [09:22:59] <siretart> this one http://patches.ffmpeg.org/patch/1110/ ? [09:23:09] <siretart> hm. patches.ffmpeg.org could really use some cleanup [09:23:26] <siretart> lu_zero: thanks [09:27:00] <lu_zero> 4D5A5BBC.70400@m1stereo.tv ? [09:27:37] <merbzt> no [09:27:50] <lu_zero> which ones ^^? [09:27:58] <merbzt> verem [09:28:05] <merbzt> @m1stereo.tv [09:28:24] <lu_zero> yes but which email ^^? [09:28:35] * lu_zero pointed the last email by message-id [09:29:52] <lu_zero> 02/15/2011 11:55 AM ? [09:29:54] <merbzt> 02/15/2011 11:55 AM [09:30:06] <merbzt> yes, it needs a fix before commit [09:30:21] <lu_zero> which one? [09:30:32] <lu_zero> could you comment on it the thread? ^^ [09:30:44] <merbzt> I did [09:30:49] <lu_zero> uhm [09:30:58] <lu_zero> ... [09:31:12] * lu_zero should restart the socks5 ssh... [09:34:39] * siretart suggests referencing urls on http://patches.ffmpeg.org [09:37:06] <merbzt> well in this case email is better as I had comments for changes [09:37:47] <kshishkov> siretart: also there are unapplied binkaudio patches IIRC [09:38:15] <siretart> kshishkov: links? [09:42:42] <kshishkov> siretart: http://patches.ffmpeg.org/patch/1214/ http://patches.ffmpeg.org/patch/1215/ http://patches.ffmpeg.org/patch/1216/ http://patches.ffmpeg.org/patch/1217/ http://patches.ffmpeg.org/patch/1218/ http://patches.ffmpeg.org/patch/1219/ [09:43:11] <siretart> can't these patches be merged to a bundle, so that you have only one link? [09:45:47] <siretart> kshishkov: I don't have time right now to look at it, I'd put it on my list for this afternoon/tonight [09:48:08] <kshishkov> siretart: thanks for that [09:56:56] <wbs> cartman: https://review.source.android.com/21419 [09:57:19] <cartman> wbs: lets see [09:58:02] <Kovensky> http://pastebin.com/qcZVZvD8 hah [09:59:08] <kshishkov> Kovensky: wait until elenril hears this [09:59:55] <Kovensky> indeed [10:39:58] <Tjoppen> libavfilter seems to have a rather.. interesting program flow [10:40:22] <Tjoppen> as in, I'm a bit sceptical of filters calling eachother directly [10:46:24] <kshishkov> try gstr**m*r [10:46:41] <Tjoppen> heh [10:47:35] <merbzt> Tjoppen: well the api has been deved for years [10:47:41] <merbzt> it should hold up [10:48:32] <Tjoppen> I'm just a little worried that for instance multi-input graphs appear able to fill up RAM [10:48:45] <Tjoppen> lunchtime [10:50:38] <merbzt> that sounds er, neat maybe [10:54:21] <kshishkov> Tjoppen: Parkinson's law - every program tries to eat all RAM [11:09:44] <mru> btw, latest llvm-gcc passes all the tests [11:11:22] <siretart> \o/ [11:11:35] <mru> clang fails [11:11:48] <siretart> oh, I confused those two [11:11:52] <mru> does that mean it's a frontend problem? [11:12:16] <siretart> could also be a bug in llvm that only the clang frontend triggers [11:12:23] <mru> or that, yes [11:58:45] * elenril throws some vector bosons at kshishkov [11:59:13] * kshishkov relies on air to protect him [11:59:33] <elenril> http://tvtropes.org/pmwiki/pmwiki.php/Main/LuckilyMyPowersWillProtectMe [11:59:59] <kshishkov> nope, I'm merely friends with laws of physics :P [12:00:59] <elenril> they won't protect you in this case =p [12:01:16] <kshishkov> huh? [12:01:47] <kshishkov> I don't think those bosons will survive after colliding any air molecule [12:02:10] <elenril> air generally doesn't shield from γ radiation [12:02:19] <kshishkov> it does [12:02:53] * kshishkov thinks about major source of gamma rays in this system and Earth atmosphere [12:03:08] <elenril> you'd need a pretty thick layer of air for that [12:04:17] <kshishkov> depends on how many particles you can throw [12:04:29] <kshishkov> and with what energy of course [12:04:41] <kshishkov> and their time of life [12:05:57] <elenril> a photon doesn't decay =p [12:06:34] <kshishkov> that's only one instance of vector bosons [12:08:08] <elenril> W and Z aren't very useful when you're building death rays [12:08:51] <kshishkov> well, the only useful death ray ever was built with photons indeed [12:09:14] <siretart> DonDiego: I'm still waiting for your changes for 0.5.4 [12:09:31] * elenril goto uni [12:11:53] <mru> photons may not decay, but they can be absorbed [12:11:56] <mru> and scattered [12:12:05] <kshishkov> and annihilated! [12:15:28] <mru> if you have two of them [12:15:48] <DonDiego> siretart: right... [12:16:42] <kshishkov> or just collide them [12:19:20] <cartman> http://www.halolz.com/wp-content/uploads/2010/03/halolz-dot-com-sony-playsta... [12:19:49] <mru> innovation ended a few decades ago [12:20:13] <cartman> WiiMote was an innovation [12:20:17] <mru> not really [12:20:51] <mru> the transistor was an innovation [12:22:14] <iive> not really, the lamp was. [12:22:23] <kshishkov> well, we were given such definition "innovation is successfully commercialized invention" [12:23:25] <mru> m-w defines it as "a new idea, method, or device" [12:23:31] <mru> there's nothing new in the wiimote [12:23:42] <cartman> http://www.macrumors.com/2011/02/24/15-17-inch-macbook-pro-specs-amd-gpu-qua... [12:23:45] <cartman> official! [12:23:46] <mru> acceleromoters have been around forever [12:23:53] <mru> +spelling [12:24:12] <Tjoppen> by that logic, nothing is an innovation [12:24:20] <Tjoppen> (which may be true) [12:24:31] <mru> Tjoppen: I said the transistor was [12:24:38] <mru> there was nothing quite like it before [12:24:55] <mru> sure, there was the vacuum tube [12:24:56] <Tjoppen> does not the work on the transistor build on top of the work on point contact diodes? [12:25:32] <mru> possibly [12:25:41] <mru> but the difference is fairly large [12:27:10] <iive> first computers were done with vacum tubes/lamps [12:27:11] <mru> the wiimote is just a new gadget built with existing components [12:27:16] <Tjoppen> true. feels like we're walking into a discussion about semantics though [12:27:20] <mru> and it's not even that new [12:28:06] <mru> motion sensors were used well before the wii [12:29:03] <iive> the innovation was not in using motion sensers, but how they were used. [12:29:28] <mru> "making it cheaper" is not an innovation [12:30:35] <mru> another real innovation: the internal combustion engine [12:30:51] <kshishkov> by whom? [12:31:14] <mru> I don't remember who built the first one [12:31:28] <mru> but it was a radically new approach compared to the steam engine [12:31:39] <mru> which was of course also an innovation [12:31:44] <kshishkov> aka external combustion engine [12:32:21] <mru> I find it a bit ironic that a nuclear power plant is really not much more than a glorified steam engine [12:32:39] <Tjoppen> well, I wouldn't be surprised if ICE is an older concept then ECE [12:33:01] <kshishkov> it was hard to get fire inside [12:34:14] <kshishkov> mru: and nuclear plants are also very eco-friendly (unless built in Ukraine) [12:34:16] <iive> Tjoppen: I'm still not aware of ICE that uses gunpowder. [12:34:17] <DonDiego> siretart: http://pastebin.com/Na6ecL4D [12:34:39] <Tjoppen> iive: there were attempts [12:35:18] <Tjoppen> but whatever. IMO there's only two ways to look on these things: either everyone innovates, or noone does (because eveything is built ontop of the works of others) [12:35:23] <kshishkov> it was hard to make homohenous pellets and feed them at constant rate [12:36:12] <kshishkov> Tjoppen: it's the same story with inventions - an improvement should be non-obvious knowing state-of-the-art methods [12:37:14] <mru> Tjoppen: most things are merely minor tweaks of existing technology [12:37:22] <BBB> mru: is it normal that they expect me to find the bug in the compiler? last time they were more helpful [12:37:22] <mru> innovations add something fundamentally new [12:37:41] <mru> BBB: compiler devs can be quite obnoxious [12:37:47] <cartman> BBB: clang people? [12:38:01] <BBB> cartman: yes [12:38:04] <BBB> cartman: I found your bug [12:38:08] <BBB> cartman: http://llvm.org/bugs/show_bug.cgi?id=9307 [12:38:12] <Tjoppen> I don't see the point in making any distinction, because in that case you need to set some kind of limit when things become innovative [12:38:17] <cartman> BBB: Awesome, lets get it fixed [12:38:27] <BBB> cartman: it's a clang bug, I don't fix it, they fix it [12:38:34] <cartman> BBB: I'll bug them :P [12:38:50] <kshishkov> Tjoppen: told you, when it's non-obvious to engineer knowing state-of-the-art methods [12:39:05] <cartman> BBB: you didn't find a bug you just reported a bug with no testcase [12:39:06] <cartman> pffff [12:39:17] <kshishkov> Tjoppen: aka making transistor from diode is not obvious, making solid-state diode - too [12:39:40] <kshishkov> Tjoppen: but using plastic case instead of metal one is not [12:40:01] <BBB> peloverde: where did that quote come from? [12:40:13] <BBB> cartman: I did: download ffmpeg, make fate-vp8 [12:40:15] <BBB> doesn't take long [12:40:33] <cartman> BBB: thats not how compiler bugs are resolved [12:40:39] <cartman> see my older miscompilation results [12:40:42] <cartman> you need a small testcase [12:40:55] <BBB> ffmpeg is small [12:41:06] <cartman> small as in 10-20 lines [12:41:11] <kshishkov> especially if you don't compile motion_est.c [12:41:51] <cartman> I'll bisect it. [12:41:54] <cartman> At least can do that :P [12:42:09] <BBB> cartman: can you bisect which version of clang broke it? [12:42:14] <BBB> (which revision) [12:42:22] <BBB> they asked for that, and you may be much faster than me [12:42:30] <cartman> BBB: yeah will do now [12:42:34] <BBB> thanks [12:42:43] <cartman> no, thank you for reporting it [12:42:46] <cartman> I was being lazy [12:42:50] <mru> a smaller test case is always better of course [12:43:01] <cartman> cd [12:43:04] <cartman> oops [12:43:20] <mru> but I've had arm fix bugs when the best I could say was it happened somewhere in mjpeg.c and was related to inlining [12:43:20] <BBB> good start [12:43:58] <cartman> sometimes compiler developers are in the good mood and they reduce it themselves :P [12:47:02] <BBB> cartman: I think if you tell them which revision broke it, they can figure it out themselves [12:47:29] <BBB> I may try to reduce the testcase but it's a massive amount of work, so I'm not too happy about it... [12:47:48] <cartman> BBB: yeah bisect might work [12:50:47] <uau> BBB: btw that paste doesn't really show it's a compiler bug - it's generally hard to show that unless you already have a reduced testcase or look at the asm output and see something obviously wrong with that [12:51:01] <uau> otherwise there could be undefined behavior somewhere in the program being tested [12:51:58] <mru> the test case should preferably be small enough that there is obviously no undefined behaviour [12:52:37] <mru> and small enough that manually analysing the asm is feasible [12:58:17] <BBB> uau: ENOTMYJOB [12:58:36] <BBB> uau: if the clang developers want an awesome compiler that can compile > hello world, I welcome them to look at this bug [12:59:07] <BBB> uau: if, on the other hand, they are happy to be merely a test subject in our fate suite that fails at random testcases and we don't care to look at, then I'll happily accept that fate and move on [13:00:38] <mru> clang does better than many other compilers at least [13:00:49] <mru> most compilers I try don't even build ffmpeg at all [13:02:32] <uau> BBB: i didn't say that it would be your job to debug it [13:02:59] <uau> but rather that what you've done so far does not reliably show it to be a bug in clang (and not in ffmpeg) [13:03:51] <lu_zero> ^^; [13:05:37] <cartman> http://ffmpeg.pastebin.com/raw.php?i=vcKYPJ8p its gonna be OK :P [13:05:58] <BBB> \o/ [13:06:13] <BBB> go cartman [13:06:22] <cartman> heheh [13:06:24] <BBB> if, after this, they need a reduced testcase, I can look into it [13:06:26] <BBB> but first this [13:06:27] <BBB> :) [13:06:30] <cartman> alright [13:06:42] <cartman> My last week with my MacBook Pro, better use it for good! :P [13:07:19] <kshishkov> cartman: has your ex-boss returned your Android tablet at least? [13:07:36] <cartman> kshishkov: yeah we got many tablets now but now I am going away :D [13:45:44] <BBB> elenril: will look at your patches also [13:52:42] <elenril> awesome [13:53:29] <elenril> btw any ideas for a nice name for put_flush_packet or whatever it's called [13:53:47] <wbs> avio_flush_packet? [13:54:02] <elenril> maybe just avio_flush()? [13:55:12] <wbs> perhaps, I don't remember exactly what that one does, but if it's mostly used by the packet stuff, keeping it in the name might be good, otherwise I don't have much of an opinion on that [13:58:00] <elenril> anyway, going home [13:58:18] <BBB> elenril: will look at it [13:58:23] <BBB> elenril: btw thanks for doing this in small chunks [13:58:28] <BBB> this is great for review purposes [14:08:29] <BBB> mru: did you test whether llvm-gcc also has the vp8 bug? [14:12:24] <mru> BBB: check fate [14:12:30] <mru> it passes [14:15:41] <cartman> mru, BBB even clang r80000 fails and current revision is 120.000 something [14:20:04] <mru> what rev was 2.8 release? [14:30:22] <wbs> cartman: btw, the ndk/gcc-4.4.0/osx fix hit git master now [14:31:39] <cartman> wbs: thanks! [14:31:54] <cartman> not that I'll touch OSX again though [14:32:38] <kshishkov> yes, it's all SuSE for you now [14:32:46] <cartman> indeed so. [15:11:14] <siretart> does one suggest to consider or suggest considering something? [15:12:05] <kshishkov> either [15:12:43] <siretart> thanks [15:13:14] <Dark_Shikari> latter [15:14:02] <siretart> thanks [15:46:10] <BBB> cartman: do a binary dissect between 123237 (known to fail) and 2.8 release (known to be good) [15:46:28] <BBB> cartman: and first confirm indeed that 2.8 release is good [15:50:14] <Dark_Shikari> Gotta love Apple. Introducing an amazing revolutionary new display port that can transfer an amazing 10gbps... almost 60% as much as DisplayPort has supported for half a decade. [15:50:38] <kshishkov> don't forget most confusing sign for it [15:50:46] <Dark_Shikari> Ah yes, its symbol is that of "high voltage, danger". [15:51:12] <cartman> BBB: git cloning llvm atm, svn is being a pain [15:51:22] <kshishkov> and HDMI is 10Gbps too, designed eight years ago [15:52:19] <cartman> kshishkov: Quad Core i7 is pretty though [15:52:59] <kshishkov> cartman: ? [15:56:09] <cartman> kshishkov: I mean the machine itself is good minus the hype [15:57:10] <kshishkov> cartman: and the hype inflates the price [15:57:26] <Dark_Shikari> also, the battery life is 3 hours worse than the previous version. [15:58:00] <cartman> Dark_Shikari: the previous version was lying, this one lies less [15:58:05] <Dark_Shikari> How do you know? [15:58:07] <Dark_Shikari> psychic powers? [15:58:13] <Dark_Shikari> apple isn't even claiming that. [15:58:14] <cartman> Dark_Shikari: using a Mac helps [15:58:17] <cartman> a 2010 mac helps a lot [15:58:22] <Dark_Shikari> You have a new Powerbook? [15:58:25] <Dark_Shikari> I'm pretty sure it isn't in stores yet. [15:58:28] <cartman> even 2 macs helps more ;) [15:58:42] <cartman> previous claim of 8-9 hours was a lie [15:59:00] <Dark_Shikari> Yes, and so is the claim of 5 hours [15:59:02] <Dark_Shikari> they're equally lies [15:59:08] <Dark_Shikari> if 8 hours was overstated by 30%, 5 hours will be overstated by 30% [15:59:16] <cartman> uhm no my MBP works fine with 5 hours [15:59:20] <Dark_Shikari> ... [15:59:22] <Dark_Shikari> You don't have the new MBP. [15:59:26] <Dark_Shikari> How do you know it will last 5 hours? [15:59:32] <Dark_Shikari> ESP? [15:59:35] <cartman> Dark_Shikari: physcic powers [15:59:42] <cartman> you should trust me [15:59:47] <cartman> I am the Mac whisperer [15:59:47] <Dark_Shikari> `-` [16:00:19] <cartman> where the fuck is av500 anyway [16:00:24] <cartman> kshishkov: do you know? [16:01:08] <kshishkov> cartman: probably in business trip or hardly working [16:01:20] <cartman> kshishkov: ah, ok :) [16:01:26] <cartman> one misses his sneaky comments [16:01:37] <kshishkov> sneaky as him? [16:01:55] * cartman is not sure if he has the right word [16:01:58] <cartman> but yes [16:02:06] <cartman> see ya! [16:02:15] <mru> I've had my sony running for 7 hours on a single charge [16:02:53] <kshishkov> mru: what did it run? [16:03:17] <mru> normal linux stuff [16:06:37] <kshishkov> was that with default battery? [16:08:12] <Dark_Shikari> Also, many of these things do run 8 hours -- for the first week [16:08:17] <Dark_Shikari> then they start losing their charge. [16:25:08] <astrange> 10:57 <@Dark_Shikari> also, the battery life is 3 hours worse than the previous version. <- the battery test changed [16:26:01] <astrange> mine (2010) is edition is down to 6400 mAh from 6900 mAh when it was manufactured [16:26:13] <astrange> *mine (2010 edition) [16:26:20] <astrange> which is not much of a loss [16:26:53] <dalias> my eeepc still lasts ~6 hours after almost 2 years [16:27:27] <mru> you'll probably find that the hours have got shorter too [16:27:28] <kshishkov> my Gdium doesn't last from the very beginning [16:27:45] <mru> my gdium battery holds less charge than a brick [16:28:27] <kshishkov> I've never managed to charge it to 100% but you saw me using Gdium at FOSDEM [16:28:36] <dalias> mru, lol [16:28:46] <mru> I'm not joking [16:28:48] <dalias> is that due to posix not having leap-seconds? [16:29:04] <kshishkov> due to RTC being a bit screwed [16:29:56] <mru> on my old laptop the time remaining estimate drops significantly faster than the wall clock [16:30:07] <mru> wall clock dropped from a 3rd floor window, that is [16:32:29] <dalias> well time on the 3rd floor and 1st floor will be slightly different [16:32:32] <dalias> due to gravity [16:32:46] <dalias> :) :) :) [16:32:59] <mru> not if there's a massive weight on the 4th floor [16:33:16] <dalias> your mom is on the 4th floor? [16:33:20] <dalias> ;-) [16:33:51] <mru> reminds me of an accident that happened in sweden a while ago [16:34:05] <mru> a floor collapsed [16:34:20] <mru> the weight watchers were having a meeting in the room [16:36:15] <ruggles> i think i got unlucky with my eeepc. the previous model lasts 6 hrs, mine only lasts 3 hrs, then the next model lasts 6 hrs. it's like they pushed the speed out first, then got the power usage under control in the next round. [16:36:16] <Dark_Shikari> well, naturally. if you're in "weight watchers", you're fat. [16:36:23] <Dark_Shikari> if you weren't, you wouldn't be there. [16:41:11] <ruggles> \o/ make fate passes after modifying all 121 audio decoders! [16:42:23] <ruggles> now it's time to pull/rebase and submit a gigantic patch. [16:42:54] <ruggles> what is the ML size limit? [16:43:22] <dalias> lol why such a big change? [16:43:48] <ruggles> changing audio decoding API to use get/release_buffer() and output to AVFrame [16:44:34] <mru> ruggles: \o/ [16:54:40] <merbzt> ruggles: \o/ [16:54:45] <merbzt> jolly goood [16:55:23] <ruggles> :) it has been an exhausting week. i never realized there were so many audio decoders. [16:55:28] <Kovensky> zomg, now I'll have to do actual work on x264-audio! [16:56:26] <BBB> ruggles: that's awesome! [16:58:08] <peloverde> BBB: it came from HN [16:58:15] <BBB> hn? [16:58:50] <BBB> damnit, apple has a quadcore macbookpro [16:58:54] <BBB> now I have to go buy a new one again [16:59:30] <mru> peloverde: you moved from reddit to hn? [16:59:41] <mru> that's good, you should be less annoyed [17:00:08] <Kovensky> BBB: wait until they release the sandy ones [17:00:32] <mru> i.e. 3 years after everybody else does [17:02:03] <Kovensky> lol [17:02:17] <Kovensky> well, current apple rumors is that the upcoming keynote will announce that [17:04:41] <astrange> it is SNB [17:05:02] <astrange> i7-2720QM [17:06:41] <Kovensky> oh [17:06:44] <astrange> i believe thw hw encoder is used for facetime [17:07:09] * Kovensky wonders if there'll be anything interesting on 10.7 [17:38:47] <kierank> [16:44] ruggles: changing audio decoding API to use get/release_buffer() and output to AVFrame --> \o/ [17:40:06] <Kovensky> what does that change for API users btw? [17:42:19] <ruggles> Kovensky: don't have to allocate their own output buffer. unless they want to override get/release/buffer(). [17:42:35] <Kovensky> o [17:43:12] <ruggles> basically audio decoding will be like video decoding. AVPacket in, AVFrame out, output buffers handled internally. [17:43:15] <Kovensky> but then if I want to cache the output I need to do a memcpy? [17:44:03] <ruggles> only if you use the default get_buffer() [17:44:10] <ruggles> like video decoding [17:46:19] <Kovensky> hm [17:46:42] <Kovensky> I guess I'm better off not caching then, and writing a filter that does the caching if needed [17:47:31] <Kovensky> if I get around to it, that is :X [17:47:38] * Kovensky has thought of several things to reduce his procrastination but he hasn't gotten around to trying them yet [17:48:00] <gnafu> Procrastinators unite! Tomorrow... [17:53:09] <Kovensky> gnafu: nah, maybe next week... [17:53:28] <gnafu> No, next week doesn't work for me. How about early April? [17:55:00] * Kovensky wonders if he should answer that now or later [17:58:23] <gnafu> Better give it some thought and get back to me. [18:27:43] * elenril sees his patches still not applied [18:29:03] <mru> elenril: would you mind marking your old patches in patchwork? [18:36:46] <elenril> done [18:37:58] <mru> thanks [18:52:02] * gnafu sees that someone finally said something about top-posting in the JPEG 2000 ML thread... [18:52:24] <gnafu> :-D [18:56:00] <Dark_Shikari> gg [20:28:49] <spaam> yssna på musik och irka.. nej tack. [20:29:52] <spaam> hmm [20:40:13] <Kovensky> spaam: what's with the BlackSpeech [20:40:36] <spaam> Kovensky: my internet connection did lag ;S [20:41:07] <spaam> and i was going to write that in another channell.. [21:18:54] <saste> mru: there are no checks if pkg-config fails (e.g. in case of missing libs) [21:19:11] <saste> configure succeeds but then linking fails [21:19:24] <mru> example? [21:19:47] <saste> librtmp... I just upgraded and I hadn't libssl installed [21:20:06] <saste> I can see the pkg-config error message on the output but configure exits with 0 [21:20:26] <mru> doesn't the link check fail? [21:20:40] <saste> no [21:20:52] <mru> why not? [21:21:21] <saste> dunno ... going to check the log [21:30:27] <CIA-15> ffmpeg: Anssi Hannula <anssi.hannula@iki.fi> master * r7e06e0ede3 ffmpeg/libavcodec/dca.c: [21:30:27] <CIA-15> ffmpeg: dca: use EXT_AUDIO_ID field to determine core extensions [21:30:27] <CIA-15> ffmpeg: This avoids the core substream extensions scan when the EXT_AUDIO_ID [21:30:27] <CIA-15> ffmpeg: field indicates no extensions or only unsupported extensions. The scan [21:30:27] <CIA-15> ffmpeg: is done only if the value of EXT_AUDIO_ID is unknown or indicates a [21:30:28] <CIA-15> ffmpeg: present XCh extension which we can decode. [21:30:29] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans@mansr.com> [21:36:10] <saste> mru: http://pastebin.com/b2Tmi2VA [21:36:23] <saste> bah a weird opencv / librtmp interaction [21:36:46] <saste> --enable-librtmp fails... --enable-librtmp --enable-opencv doesn't [21:38:39] <mru> hard to guard against that [21:39:44] <saste> mru: anyway it's a minor and unlikely bug.. maybe a preventive check on the result of pkg-config may help [21:40:03] <mru> perhaps [21:40:36] <mru> I'll consider it if we run into more of these [21:40:43] <mru> otherwise it's just clutter [21:40:54] <mru> and you know I'd rather not use pkgconfig at all [21:51:20] <Flameeyes> saste: uhm, how do you install librtmp? [21:52:38] <saste> Flameeyes: I have a local install with --prefix=$HOME [21:52:55] <Flameeyes> saste: ah, hm [21:53:14] <Flameeyes> 'cause if it came from a distro I'd have told you to kick them for not depending on openssl/libssl-dev and variants [22:34:19] <BBB> cartman: any progress? [22:35:53] <spaam> BBB: cartman is not here.. [22:36:09] <BBB> tab completion works for me [22:36:27] <spaam> not for me :S [22:36:45] <spaam> cant find him in the nicklist.. [22:36:56] <mru> no cartman here either [22:37:09] <spaam> 170210 -!- cartman [~ismail@kde/ismail] has quit [Quit: good day] [22:37:21] <spaam> last thing i have about him.. [22:37:44] <spaam> thats ~6h ago... [22:39:13] <BBB> hm [22:39:18] <BBB> why does tab completion work then? [22:39:24] <BBB> the irc bouncer must be screwed up [22:39:28] <mru> bad irc client? [22:39:38] <BBB> bouncer, not client [22:39:46] <BBB> what shall I do today... [22:39:57] <mru> you're using some nasty mac irc client [22:40:01] <BBB> baby sleeps, clang bug report submitted and delegated to cartman [22:40:16] <kierank> BBB: merge ffmpeg-mt ;) [22:40:18] <BBB> it's not nasty, it has pretty colors [22:40:29] <BBB> kierank: astrange asked me to hold, one bug he's working on [22:40:36] <mru> help him [22:41:00] <astrange> read the timestamp thread [22:41:13] <BBB> astrange: I'm demotivated to fix timestamps [22:41:20] <BBB> I'll work on ffmpeg-mt though [22:43:28] <BBB> astrange: sample + command to reproduce bug? [22:43:31] <BBB> I can try [22:43:54] <astrange> http://samples.mplayerhq.hu/V-codecs/HuffYUV/angels_480-huffyuvcompress.avi ffplay -threads 3 [22:45:45] <saste> mru: libcvaux required by libopencv links against librtmp [22:46:00] <saste> mru: so the linking test doesn't fail when libopencv is installed and enabled [22:46:11] <mru> so you do have librtmp? [22:46:29] <mru> sounds like your pkgconfig is busted somehow [22:46:35] <saste> mru: yes but pkg-config was complaining because of the missing libssl [22:46:50] <mru> so do you have it or not? [22:46:54] <saste> mru: no result -> no librtmp flags -> linking failure [22:47:05] <mru> so how did the link test pass? [22:47:45] <saste> mru: the libopenc test added the libcvaux flags to the linker [22:48:08] <mru> how can the configure test pass and the real link fail? [22:48:46] <saste> mru: libcvaux links dinamically against librtmp [22:48:59] <mru> you're still not answering the question [22:49:15] <mru> why do you get an error if the libs are there? [22:49:54] <saste> mru: pkg-config fails -> no output -> no librtmp flags added [22:50:02] <saste> mru: so the configure linking test fails [22:50:15] <mru> but you said it passed [22:50:53] <saste> mru: sorry i've been confusing... it passes with --enable-librtmp --enable-libopencv [22:51:00] <mru> yes [22:51:07] <mru> and then what? [22:51:20] <mru> is there a case where configure succeeds and final link fails? [22:51:25] <mru> if no, there is no problem [22:51:31] <mru> if yes, there is a problem on your computer [22:53:36] <mru> now checking pkgconfig return status might be a good idea [22:53:48] <mru> but your patch isn't the best way to do that [22:57:08] <saste> mru: http://pastebin.com/nBR9HjUj [22:57:48] <saste> mru: anyway feel free to fix the patch of suggest how to improve it [22:58:06] <mru> I will, but not tonight [22:58:32] <saste> no hurry [23:05:44] <BBB> astrange: in ff_thread_get_buffer(), it seems one thread is waiting in pthread_cond_wait(&p->progress_cond, &p->progress_mutex);, with p->parent->buffer_mutex held, and the other thread is blocking in pthread_mutex_lock(&p->parent->buffer_mutex); [23:07:27] <BBB> (with -threads 2 it hangs here too) [23:10:16] <BBB> astrange: is that p_cond_wait() waiting for some other thread to actually "do" the get_buffer()? [23:10:21] <BBB> astrange: and if so, where is that code? [23:12:55] <astrange> yes. it's at the end of submit_frame() [23:13:24] <astrange> ah, i see in my backtrace that the thread which should be doing that (the one that called decode_video) somehow got past there [23:13:31] <BBB> ah, submit_packet() [23:14:17] <BBB> that one is in while (p->state != STATE_INPUT_READY) [23:14:17] <BBB> pthread_cond_wait(&p->output_cond, &p->progress_mutex); [23:14:20] <BBB> I think [23:14:27] <BBB> hm, baby wants a bottle [23:14:30] <BBB> brb [23:18:18] <BBB> astrange: so do you have time to fix it or should I hack a get_buffer() in that wait (and possibly others over there also)? [23:21:02] <astrange> i can look [23:23:17] <kierank> is there any information about how to write a custom get_buffer? [23:23:36] <mru> kierank: probably not [23:24:04] <mru> kierank: I couldn't find any at least [23:24:27] <mru> I did figure it out in the end [23:26:11] <kierank> chromium has one but it's c++ :/ [23:26:27] <mru> feel free to look at omapfbplay [23:29:47] * kierank looks [23:30:35] <mru> note that it probably only works with yuv420 format [23:32:40] <astrange> ffplay contains one [23:32:55] <mru> good luck understanding ffplay [23:37:23] <BBB> astrange: so how come vp3 doesn't suffer from this? I know it's a race but a pretty obvious one, is get_buffer() "thread-safe" for vp3? [23:39:01] <astrange> presumably it's to do with the difference between inter/intra codecs (what the patch 1/2 does) [23:47:41] <BBB> also there's two conds, output_cond and progress_cond, can the two conflict and lead to deadlocks? they share the same mutex... [23:49:04] <mru> a single mutex can never deadlock [23:52:06] <BBB> if multiple threads lock on it, but use different conds to signal the other to wake up [23:52:13] <BBB> then one signals, but the other doesn't wake up [23:53:11] <mru> the mutex is unlocked while blocking on the cond [23:53:13] <BBB> I guess it's not relatd to the mutex but to the conds then [23:53:29] <BBB> right, what I meant is that there's a lot of conds and I'm not sure the logic always makes sense [23:53:33] <BBB> unrelated to the mutex [23:53:48] <mru> it might not make sense, but one mutex alone can never deadlock