[FFmpeg-devel-irc] IRC log for 2011-02-24

[irc at mansr.com]

[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 at 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 at gmail.com>
[02:29:18] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles at 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 at gmail.com>
[02:29:26] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles at 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 at gmail.com>
[02:29:28] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles at 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 at gmail.com>
[02:29:34] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles at 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 at gmail.com>
[02:29:39] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles at 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 at gmail.com>
[02:29:40] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles at 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 at gmail.com>
[02:29:42] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles at 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 at 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 at 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 at gmail.com>
[02:54:16] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles at 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 at gmail.com>
[02:54:18] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles at 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 at gmail.com>
[02:54:21] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles at 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 at gmail.com>
[02:54:24] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles at 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 at gmail.com>
[02:54:27] <BBB> wtf @ gmail
[02:54:38] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles at 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 at 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 at 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 at gmail.com>
[02:54:42] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles at 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 at 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 at 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-playstationmove-stealorinnovate.jpg
[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-quad-core-i7/
[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 at 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 at 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 at 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