Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

March 2011

1 participants
10 discussions

IRC log for 2011-03-12
by irc＠mansr.com 13 Mar '11

13 Mar '11

[00:02:05] <mru> hi j0sh, tsunami over? [00:02:16] <j0sh> yep [00:02:23] <mru> anything happen? [00:02:28] <j0sh> i'm on oahu, didn't get hit as hard as maui or the big island [00:02:32] <kierank> welcome back j0sh [00:02:45] <j0sh> naw, the sea level is slightly higher and the marina a bit dirtier, otherwise its business as usual [00:04:04] <j0sh> but apparently my building was on cnn last night [00:04:27] <j0sh> and, inexplicably, it's also on honolulu's groupon today too [00:05:37] <j0sh> it's no japan though [00:11:39] <lu_zero> ^^; [00:49:10] <mru> ruggles: were you running more tests or what? [02:10:35] <Dark_Shikari> http://seclists.org/nmap-dev/2011/q1/767 [02:10:38] <Dark_Shikari> .... oh god this is hilarious [02:28:30] <saintdev> Dark_Shikari: was just reading that on my way home, lol [02:44:34] <asdf1234> what's hb gray? [02:47:59] <saintdev> HB Gary is the company that got owned by Anon after their CEO attempted to [02:48:07] <saintdev> 'expose' them [02:48:25] * saintdev smacks his enter key [02:49:03] <Sean_McG> o_O; [03:07:46] <asdf1234> saintdev: what? [03:08:18] <roxfan> asdf1234 has been living under a rock? [03:08:31] <saintdev> roxfan: apparently [03:08:34] <roxfan> http://arstechnica.com/tech-policy/news/2011/03/hbgaryanonymous-special-rep… [03:50:52] <Compn> the one thing that always makes me laugh out of the whole hbgary thing [03:51:00] <Compn> was the line 'and remotely wiped his ipad' [03:54:23] <Compn> if it was 'remotely wiped his laptop' it wouldnt be funny [03:54:29] <Compn> but ipad ? laughs every time [04:00:38] <ruggles> mru: sorry. dinner... bedtime... i'll get it done first thing in the AM [04:38:37] <saintdev> peloverde: ping [10:27:08] <_av500_> gm [10:27:38] <_av500_> time for godzilla to get in action [10:29:33] <lu_zero> uh? [10:30:30] <thresh> _av500_: no, for mechagodzilla [10:30:54] <_av500_> whoever can blow out the nuclear fire [10:31:30] <ohsix> you can only blow out a fire if that's its oxidizer D: [11:36:04] <CIA-36> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * ra5444fee06 ffmpeg/ (configure libavcodec/Makefile libavcodec/x86/Makefile): [11:36:04] <CIA-36> ffmpeg: Add CONFIG_AC3DSP symbol to simplify makefiles [11:36:04] <CIA-36> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [12:26:24] <lu_zero> lastlog mms [12:31:42] <Kovensky> 09:28.25 Bocom: "If u add USA's 9-11-01 & Japan's 3-10-11 you get 12-21-12 ? WTF?" <-- mind blown [12:39:53] <Tjoppen> numerology \o/ [12:40:52] <kshishkov> dynga [13:42:32] <Tjoppen> does anyone know of a good binary diff tool? it needs to do a proper diff, not just byte for byte [13:43:04] <Tjoppen> as in an edit distance type diff. my use case is comparing two mxf's [13:43:26] <Dark_Shikari> mru: I'm waiting on a response to my patch 3/4 to commit the other 3, since there's dependencies [13:50:13] <BBB> Dark_Shikari: vp8 patches are fine with me, don't expect a long review from me, working on vc1 ;) [13:50:29] <Dark_Shikari> don't need one [13:50:33] <Dark_Shikari> need approval on patch 3/4 [13:50:38] <Dark_Shikari> it's a trivial one [13:50:40] <BBB> mans already gave one [13:50:48] <Dark_Shikari> oh [13:50:53] <Dark_Shikari> fast. [13:50:54] <Dark_Shikari> thanks mru [13:51:25] * Flameeyes <3 HE-AAC [13:51:30] <BBB> patch 4/4 is insane magic btw [13:51:33] <BBB> how do you do that? [13:51:39] <BBB> do you use tools for that? [13:51:55] <mru> brain? [13:51:57] <Flameeyes> BBB: pahole (in dwarves) can help with that, not sure if Dark_Shikari is using it though [13:52:00] <kierank> Flameeyes: why do you love he-aac [13:52:17] <Dark_Shikari> BBB: brain [13:52:22] <Dark_Shikari> and what do you mean insane magic? [13:52:22] <mru> kierank: maybe it's the other way around [13:52:28] <Dark_Shikari> I didn't even track offsets when I started [13:52:30] <Flameeyes> kierank: sky.fm radio not glitching even if I'm downloading opensuse and another fuckload of stuff :D [13:52:32] <Dark_Shikari> I just PUT THE IMPORTANT SHIT AT THE TOP [13:52:32] <Dark_Shikari> lol [13:52:37] <mru> kierank: maybe it's just he-aac f*cking him in the arse [13:52:42] <Dark_Shikari> To track offsets during my fine tuning... [13:52:44] <Dark_Shikari> offsetof() [13:52:53] <Dark_Shikari> But PUTTING THE IMPORTANT SHIT AT THE TOP is generally enough [13:52:59] <Flameeyes> Dark_Shikari: give a try to pahole.. quite nice [13:53:05] <Flameeyes> I've been using it extensively on feng [13:53:05] <Dark_Shikari> I'll try it sometime, on windows atm `-` [13:53:09] <Dark_Shikari> But yeah, sounds cool [13:53:29] <Dark_Shikari> oh, also, BBB [13:53:32] <Dark_Shikari> to check binary size [13:53:42] <Dark_Shikari> I configured with falign-functions, falign-labels, falign-loops, falign-jumps, all equal to 1 [13:53:48] <Dark_Shikari> which -Os does too, I guess [13:54:01] <Dark_Shikari> This is useful to see if changing a variable's type hurts instruction size [13:54:08] <Dark_Shikari> i.e. int -> uint8_t [13:54:34] <BBB> right [13:54:52] <BBB> ok, so PUT THE IMPORTANT SHIT AT THE TOP is what I should learn [13:54:54] <Dark_Shikari> but there's no insane magic, it's basically all ad hoc [13:54:55] * BBB remembers [13:55:02] <Dark_Shikari> Now, if you want insane magic [13:55:08] <Dark_Shikari> see my patch to use -128 byte struct offsets [13:55:10] <Dark_Shikari> `-` [13:55:19] * Flameeyes is the tools guy so would suggest codiff in pahole to track size difference in functions [13:55:31] <Dark_Shikari> too bad there's only about one function [13:55:35] <Dark_Shikari> everything except two functions is inlined [13:55:43] <Dark_Shikari> I wonder if this makes gcc more dumb [13:56:09] <Flameeyes> even more so? [13:56:53] <BBB> Dark_Shikari: the function is frigging fast :-p [13:57:03] <BBB> I never tested if the inlining helps or hurts [13:57:04] <Dark_Shikari> BBB: http://pastebin.com/pEbAnGug [13:57:06] <BBB> it seemed like it'd hlp [13:57:18] <Dark_Shikari> think about that for a moment until you squirm [13:58:40] <BBB> I don't get it [13:58:50] <BBB> is this b/c an offset of 128 fits in 1 byte [13:58:53] <BBB> and 256 does not? [13:59:04] <BBB> so [-128,127] makes the instruction sizes one byte smaller? [13:59:09] <BBB> (rough guess) [13:59:10] <mru> 3 bytes [13:59:17] <Dark_Shikari> [ptr+X] is 1 address byte for -128 to 127 [13:59:19] <mru> there's no 16-bit offset [13:59:19] <Dark_Shikari> for X [13:59:19] <BBB> oh it's not 1,2 or 4 bytes, it's 1 or 4 bytes? [13:59:26] <Dark_Shikari> and 4 address bytes for larger [13:59:27] <Dark_Shikari> yes [13:59:29] <Dark_Shikari> there's only 1 vs 4 [13:59:30] <BBB> I didn't know, I always thought it was 1, 2 or 4 [13:59:32] <BBB> ok [13:59:37] <Dark_Shikari> So you can access the first 128 bytes of a struct cheaply [13:59:41] <Dark_Shikari> and the rest is 3 extra bytes. [13:59:46] <mru> immediats for arithmetic can be 2 bytes iirc [13:59:55] <mru> at least in some modes and for some operations [13:59:58] <BBB> crazy shit dude [13:59:59] <Dark_Shikari> But... if you offset your pointer by 128 bytes [14:00:07] <Dark_Shikari> You can access the first 256 bytes of a struct cheaply. [14:00:10] <BBB> why doesn't gcc do that? [14:00:16] <BBB> for inlined or static functions at least [14:00:18] <Dark_Shikari> There's a bit more to this. [14:00:23] <Dark_Shikari> First, let's look at these functions we have here. [14:00:30] <Dark_Shikari> func1() is compiled correctly on gcc 3.4. [14:00:40] <Dark_Shikari> on gcc 4.0 through 4.5, it's compiled badly, because the constant folding is fucked up [14:00:52] <Dark_Shikari> it does a redundant lea at the start to subtract 128 from the pointer [14:00:57] <Dark_Shikari> i.e. "folding" up the operation [14:01:02] <Dark_Shikari> this results in 12 bytes of extra pointless instruction coding [14:01:10] <Dark_Shikari> 4.6... it's fixed again. [14:01:17] <Dark_Shikari> Now, let's go back to using this optimization in a compiler. [14:01:23] <Dark_Shikari> In gcc 1.46 or so... IT USED THIS OPTIMIZATION. [14:01:32] <Dark_Shikari> on m68k at least. [14:01:37] <BBB> :D [14:01:38] <Dark_Shikari> It got lost in the transition to gcc 2 [14:01:44] <BBB> who cares about m68k [14:01:46] * BBB runs [14:01:52] <BBB> is it used on x86? [14:01:52] <Dark_Shikari> This optimization is legal even in the general case in C (!) [14:02:03] <Dark_Shikari> Because pointers are not guaranteed to be equal to their integer representations [14:02:09] <Dark_Shikari> i.e. you're allowed to store pointers in an abnormal manner [14:02:15] <Dark_Shikari> And that manner you store them in can differ per-type [14:02:20] <Dark_Shikari> so you could choose to do it only for the structs of your choice. [14:02:47] <Dark_Shikari> ... but no, gcc doesn't do this at all in any version in the past decade. [14:02:52] <BBB> :( [14:02:58] <Dark_Shikari> And in anything between 4.0 and 4.5, it OPTIMIZES OUT the optimization [14:02:59] <BBB> you should fix gcc :p [14:03:01] <Dark_Shikari> even if you do it yourself [14:03:31] <kshishkov> BBB: what about applying JV decoder with the latest patches? [14:04:43] <Tjoppen> xgcc? [14:04:45] <Tjoppen> :) [14:04:51] <Dark_Shikari> more like xcc [14:04:59] <Tjoppen> right. [14:05:16] <BBB> kshishkov: it's already approved [14:05:18] <BBB> commit it anyone [14:05:31] <BBB> kshishkov: I fixed ~50% of p frame postfilter bugs in vc1 [14:05:34] <BBB> still 50% remaining [14:05:40] <Dark_Shikari> postfilter? [14:05:44] <BBB> deblock [14:06:05] <kshishkov> loop filter [14:06:11] <BBB> oh yeah [14:06:11] <Dark_Shikari> that isn't a postfilter [14:06:15] <BBB> baby makes my brain go mushy [14:06:30] <mru> Dark_Shikari: actually, you're only partially right about the validity of doing this in general [14:06:38] <mru> C allows it, but the x86 abi does not [14:06:50] <CIA-36> ffmpeg: Jason Garrett-Glaser <jason(a)x264.com> master * r628b48db85 ffmpeg/libavcodec/vp8.c: [14:06:50] <CIA-36> ffmpeg: VP8: use a goto to break out of two loops [14:06:50] <CIA-36> ffmpeg: A break statement was supposed to break out of two loops, but only broke out of one. [14:06:50] <CIA-36> ffmpeg: Didn't affect output, just could have been marginally slower. [14:06:55] <CIA-36> ffmpeg: Jason Garrett-Glaser <jason(a)x264.com> master * rb1d2f812c9 ffmpeg/libavcodec/vp8.h: [14:06:55] <CIA-36> ffmpeg: VP8: token probs doesn't need padding [14:06:55] <CIA-36> ffmpeg: prob[0] is the only prob array ever accessed, so prob[1] can serve as padding [14:06:55] <CIA-36> ffmpeg: for prob[0]. [14:06:57] <CIA-36> ffmpeg: Jason Garrett-Glaser <jason(a)x264.com> master * r1eeca88691 ffmpeg/libavcodec/ (vp8.c vp8.h): [14:06:57] <CIA-36> ffmpeg: VP8: optimize VP8Context struct ordering [14:06:57] <CIA-36> ffmpeg: Shaves at least 3KB off code size on x86, should improve cache utilization. [14:06:57] <CIA-36> ffmpeg: This would probably be useful to do for other decoders/encoders as well. [14:07:08] <CIA-36> ffmpeg: Jason Garrett-Glaser <jason(a)x264.com> master * r3efbe13739 ffmpeg/libavcodec/vp8.c: VP8: fix function declaration [14:07:10] <Dark_Shikari> mru: well, yes. [14:07:16] <ruggles> is there a shortcut to 'git add' all modified files? [14:07:22] <mru> ruggles: git add -a [14:07:24] <mru> iirc [14:07:25] <BBB> -a [14:07:28] <mru> but be careful [14:07:28] <BBB> right [14:07:35] <ruggles> cool thanks. i'll check git status first. [14:07:42] <BBB> or shell expand [14:07:46] <BBB> git add file-*.txt [14:07:54] <BBB> git gui is lovely also [14:08:00] <Dark_Shikari> mru: you might also break some apps that violate that aspect of the C standard. [14:17:07] <Tjoppen> re: git guis, a colleague recommended SmartGit [14:17:23] <Tjoppen> haven't tried it yet though [14:17:43] <mru> plain old "git gui" works nicely [14:18:28] <ruggles> wow... the C version of ac3_rshift_int32() is the same speed as MMX when unrolled by 16 [14:18:41] <CIA-36> ffmpeg: Stefano Sabatini <stefano.sabatini-lala(a)poste.it> master * r5dbe78bf91 ffmpeg/ffmpeg.c: [14:18:41] <CIA-36> ffmpeg: ffmpeg: remove unused variable in ffmpeg_exit() [14:18:41] <CIA-36> ffmpeg: Fix the warning: [14:18:41] <CIA-36> ffmpeg: ffmpeg.c: In function ‘ffmpeg_exit’: [14:18:41] <CIA-36> ffmpeg: ffmpeg.c:509: warning: unused variable ‘j’ [14:18:42] <CIA-36> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [14:18:43] <CIA-36> ffmpeg: Hendrik Leppkes <h.leppkes(a)gmail.com> master * r0215006ab7 ffmpeg/libavcodec/ (avcodec.h vc1dec.c): [14:18:43] <CIA-36> ffmpeg: VC1: Export profile/level [14:18:44] <CIA-36> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [14:18:45] <Dark_Shikari> on what cpu, ruggles? [14:18:49] <ruggles> athlon64 [14:18:57] <Dark_Shikari> not surprising [14:19:01] <Dark_Shikari> it probably has one simd shift unit [14:19:04] <ruggles> and the sse2 is still slower of course [14:19:04] <Dark_Shikari> and two scalar shift units [14:23:20] <Tjoppen> speaking of putting important shit at the top, would that be something beneficial to do to AVCodecContext while bumping major? [14:23:28] <ruggles> doh. scratch that. messed up the test. it is the same speed as the SSE2 version though... [14:25:21] <elenril> Tjoppen: you just volunteered ;) [14:28:48] <Tjoppen> :o [14:38:45] <BBB> Tjoppen: first clean up to remove stuff that's only used in one encoder, and make them private as AVOptions [14:53:01] <pengvado> Dark_Shikari: k8's 64bit scalar shift is 1/.33, its mmx shift is 2/.5, and its xmm shift is 2/1 [14:53:09] <pengvado> all of those will be memory bound [15:08:00] <ruggles> that's weird. why would gcc use "sar m32,cl" for rshift_int32 but use "movswl/shl/mov" for lshift_int16? [15:08:20] <ruggles> instead of "shl m16,cl" [15:08:34] <mru> maybe the latter doesn't exist [15:08:44] <ruggles> my docs say it does [15:08:58] <mru> ignore me then [15:16:35] <Kovensky> http://i.imgur.com/JuLxU.png lol [15:17:11] <mru> maybe not everybody knows the origin of that word [15:17:35] <mru> it's not like they teach it in school [15:17:47] <mru> at least not any school I ever attended [15:17:51] <Kovensky> it was taught in school here ._. [15:18:10] <Kovensky> both about tsunamis and the origin of the word (no explanation of why 'tsunami' though, just that it's a japanese word) [15:19:15] <mru> and even with the japanese origin, it's not necessarily called that in japanese [15:19:50] <Kovensky> at least in every japanese TV channel I've seen it was written as 津波 [15:20:06] <Kovensky> TBS, NHK and Fuji that is [15:20:11] <mru> I wouldn't be surprised either way [15:20:44] <Kovensky> talking about TV channels, apparently TV Tokyo is broadcasting Letter Bee (with the tsunami warning overlay at all times) [15:21:01] <Kovensky> all the other channels are still in constant news mode though [15:21:37] <mru> isn't the immediate danger over? [15:21:51] <mru> apart from those power plants [15:21:56] <Kovensky> everyone is still on tsunami alert [15:22:16] <mru> still risk of aftershocks? [15:22:17] <Kovensky> specially since the aftershocks will continue for months [15:22:41] <mru> I thought major aftershocks usually came within days [15:22:49] <Kovensky> just 2h ago there was a shindo 5- aftershock [15:22:50] <mru> which it hasn't been yet, come to think of it [15:22:54] <Kovensky> 30m ago a shindo 4 [15:23:11] <Kovensky> (the shindo 5- one was rated at richter 6) [15:28:33] <Kovensky> mru: http://dl.dropbox.com/u/1099186/viewtv.html if you wanna watch btw [15:28:47] <Kovensky> (yohkosonews has english voiceover) [15:29:07] <mru> I think bbc covers it well enough for me [16:48:16] <Kovensky> 13:34.32 JEEB: http://folderman.tv/up/s/fotv13137.gif [17:27:32] <mnzaki> Hello! I'm hoping to apply to GSoC for the libavfilter audio work and has some questions about the difficulty level and prerequisite knowledge I would need, and mentor availability of course [17:28:28] <mru> stefano should be your man for that [17:28:33] <mru> saste on irc [17:30:09] <mnzaki> Thanks I will wait for him then! Are there usually a lot of appC[C[C[C[Clicants? [17:30:27] <mnzaki> s/[C// stupid irssi [17:30:43] <mru> slow terminal? [17:31:05] <mnzaki> ssh :S long unrelated story [17:31:20] <mru> yeah, irssi does that sometimes on slow links [17:31:32] <mru> and no need to explain yourself [17:32:00] <mru> so anyway, mind telling us a little about yourself? [17:35:11] <mnzaki> Well, I'm a college freshman from Egypt. I started programming since about 5 years ago, but only a bunch of light stuff. The more recent and mroe interesting work was on a kernel driver for the N900 (but again nothing MAJOR) adding functionality for control of the hardware filters [17:35:58] <mru> hmm, what filters? [17:36:43] <mnzaki> audio filters :D The on-board chip had some interesting functionality that was not enabled, 2 cascaded IIR filters and a 3D stereo effect [17:37:37] <mru> that's not part of the omap3 is it? [17:37:37] <mnzaki> I actually got to the point where I could load IIR filter params from userland onto the chip, but then was too lazy to cook up some presets and a GUI [17:37:41] <mnzaki> it is! [17:37:45] <mru> what? [17:38:01] <mru> which part? [17:38:02] <mnzaki> the chip, I don't recall the name... but it's part of the omap [17:38:05] <mnzaki> hold on [17:38:16] <mru> I don't remember anything like that in the trm [17:38:30] <mnzaki> the tlv320aic34 [17:38:36] <mru> that's not the omap [17:38:43] <mnzaki> it isn't? oh well [17:39:07] <mru> they're probably using an external audio processor [17:39:11] <mru> makes sense [17:39:13] <mnzaki> anyways, it's on the N900, which is what matters :D [17:39:30] <mru> the omap3 doesn't have much dedicated audio stuff at all [17:40:37] <mnzaki> I'm actually working on a little project right now involving rtmp broadcasting and I needed to do some ffmpeg and/or sox stuff when I ended up on GSoC [17:41:54] <mnzaki> There's a slight problem though, I have only got the basics (wrt the math and implementation) down on filtering in general and I'm wondering just how much would I need to know to even attempt this task [17:42:57] <wbs> lavfilter audio stuff is more about framework munging than actual lowlevel audio coding still, I think [17:43:11] <mru> yeah [17:43:44] <mnzaki> ah good to know I suppose. As I understood things from the wiki there would be a lot of porting from other frameworks/libs [17:44:07] <mnzaki> btw anyone know where the soc svn is?? trying to pull it gets me redirected to the git repo and it's not on there [17:45:13] <mru> are you trying to use svn over http? [17:45:23] <mru> that doesn't work [17:45:25] <mru> never did [17:45:55] <mnzaki> really? ok I just pulled over svn:// thanks [17:46:34] <wbs> it might be beneficial to check saste's git repos if you find some of the soc lavfi stuff there [17:46:34] <mnzaki> is this outdated or have things that were moved over to git been removed from the soc svn? [17:46:49] <wbs> probably not removed from soc svn, but I'm not sure if all of it was there [17:47:25] <wbs> don't remember if lavfi soc audio stuff was in svn or in some git clone last summer, and saste might have worked on it further from that since then [17:48:00] <mnzaki> ok, so need to wait for saste. [17:48:46] <mnzaki> So, again, are there usually lots of applicants? What would I need to do/have for a chance at this? [17:49:26] <wbs> I guess the most important point is showing that you're able to work with the code, and perhaps even more importantly, are able to work socially with the rest of the project [18:16:08] <elenril> so any new and awesome ideas about a name for ff_get_v? [18:16:19] <mru> ff_get_w [18:16:32] <_av500_> ff_go_get_them [18:16:55] <kshishkov> ff_get_radix7_vlc [18:17:06] <mru> it's not radix 7 [18:17:09] <Tjoppen> wouldn't that be radix128? [18:17:18] <_av500_> ff_get_bytes_from_memory_and_make_then_l33t_numberz [18:17:42] * elenril stabs _av500_ [18:17:52] <elenril> where are my asf chapters [18:18:15] <_av500_> chapter 1: patience is a virtue [18:21:48] <kshishkov> mru: I think I got that name somewhere in MIDI-related specs [18:22:20] * kshishkov curses since av_memcpy_backptr doesn't really work as expected [19:47:58] <kierank> what's the reason behind lavf passing through wrapped around timestamps in TS. Shouldn't lavf be independent of container idiosyncrasies? [19:49:13] <mru> wrapped or "randomly" reset? [19:51:44] <kierank> well randomly reset timestaps would also get passed through if that's what you mean [19:53:29] <_av500_> handling the wrap is a can of worms [19:57:57] <kierank> _av500_: a can of worms for the calling app, lavf or both? [19:58:10] <mru> in general [19:58:44] <mru> you need to carefully track which pts/dts refer to old/new pcr etc [19:59:16] <mru> and with a little bad luck, the reset will happen at different times in different streams [19:59:36] <mru> you're likely to see new timestamps in video before audio, for instance [19:59:47] <mru> once they pass through decoders they'll be in sync of course [20:07:08] <kierank> btw do you know anything about the dvbsub timing model mru? [20:07:14] <mru> no [20:12:15] <_av500_> kierank: imagine 2 wraps in a file and seek to a certain timestamp [20:12:22] <_av500_> which is it [20:13:07] <kierank> yeah that's what i was thinking [20:13:16] <kierank> but I don't need seeking so it's not a big deal for me :) [20:14:49] <kshishkov> DVD images are not that popular ;) [20:37:15] <_av500_> Flameeyes: usb charging is tricky [20:37:34] <_av500_> the scheme that aapl uses differs from the one that everybody else uses [20:38:03] <_av500_> the "chinese charger standard" is just to put 100ohm between DP and DM [20:38:27] <_av500_> then devices know its a charger and they can pull more than 100/500mA [20:38:48] <_av500_> aapl scheme is very elaborate and has diferent resistor values for different devices [20:57:36] <Flameeyes> _av500_: yeah I remember reading about apple's "detection" — but not sure if it works both way or not [21:32:37] <DonDiego> btw, where is cartman? [21:33:09] <_av500_> lost in german customs [21:33:24] <_av500_> or still looking for a flat [22:10:11] <ruggles> mru: does this look ok for float version of scale_coefficients()? [22:10:12] <ruggles> void ff_float_to_int32(int32_t *dst, const float *src, int len, uint8_t scale_bits); [22:11:00] <mru> I really need the bits to be a constant [22:11:20] <mru> the float-to-fixedpoint instruction takes an immediate for that [22:11:49] <ruggles> hmmm. so you want ff_float_to_fixed24() [22:12:10] <mru> it's not going to change, is it? [22:12:26] <ruggles> no, just not as reusable for other things [22:12:37] <mru> but twice as fast [22:13:12] <mru> unless it checks for specific values and jumps [22:13:13] <ruggles> it won't make much difference on x86, but if it's that much better on ARM it's worth having [22:13:32] <mru> it's the difference between doing mul+conv and just conv [22:17:46] <mru> anything holding back those latest patches now? [22:17:57] <ruggles> mru: checking specific values might be ok. we probably only need 31 for sample format conversion and 24 for ac3. and a generic version for whatever else wants to use it. [22:18:12] <mru> 31? [22:18:17] <ruggles> someone to ok the x86 [22:18:57] <mru> for converting pre-scaled float to int16 I used some tricks [22:19:05] <mru> BBB: review request [22:20:01] <ruggles> well, we could require pre-scaled float for int32 as well i guess. but it might be a better fit for some decoders to have it done during conversion. [22:20:33] <mru> we should do whatever is fastest [22:20:50] <mru> we could add a field for requested scale [22:20:57] <mru> and decoders can honour or ignore it [22:24:37] <ruggles> that works. should we have 2 functions or just jmp to pre-scaled section if scale_bits is 0? [22:26:48] <mru> we'll see when we actually write it [22:30:03] <ruggles> ok [22:31:54] <ruggles> hmm. videolan git repo allows non-fastforward merge? [22:32:25] <mru> don't care [22:33:23] <mru> I guess cherry-picking got boresome [22:33:35] <mru> and writing code too hard [23:05:30] <BBB> mru: ? [23:05:39] <BBB> which patch? [23:05:44] <BBB> I'll look at my review queue tomorrow [23:05:48] <BBB> had to buy a baby crib today [23:05:52] <mru> BBB: ruggles' [23:05:54] <DonDiego> :) [23:05:55] <BBB> he didn't fit the small cradle anymore [23:20:42] <ruggles> mru: i'm leaning towards separate functions. float_to_int32() and float_to_fixed32() [23:21:30] <mru> which functions are you talking about? [23:22:47] <ruggles> pre-scaled float to int32 and [-1.0,1.0] float to int32 with adjustable scale [23:23:00] <mru> but for what purpose? [23:23:17] <mru> I though we were talking about the fixed24 one a while ago [23:25:18] <ruggles> ah, well i guess on arm it might be better to have that separate too... on x86 the scale vs. no-scale leads to lots of code duplication if not separated. [23:25:39] <mru> which functions are you talking about? [23:26:34] <ruggles> scale_coefficients() for ac3 float. and to be reused in format conversion eventually. [23:27:24] <mru> for neon any constant scale can be applied with the conversion [23:27:35] <mru> well, power of two scale [23:27:44] <mru> aka fixed-point fractional bits [23:27:54] <mru> but it's a _constant_ [23:28:12] <ruggles> imm8? [23:28:20] <mru> imm something at leat [23:28:22] <mru> +s [23:28:25] <mru> probably imm5 [23:29:53] <mru> the point is a runtime variable is useless [23:31:51] <ruggles> but it could be done by comparison + jump. and a macro used to reduce code duplication. [23:32:09] <mru> but in practice it will always be 24 [23:32:13] <mru> that's a useless jump [23:33:07] <ruggles> what about format conversion when the decoder doesn't scale? [23:33:15] <mru> use a different function [23:33:40] <mru> there's only a handful of realistic cases here [23:34:26] <mru> output will be int16, int32, or fixed24 [23:34:33] <mru> input can be scaled or not [23:36:18] <ruggles> for fixed24 it will not be scaled. because you could just use the int32 function in that case. [23:36:33] <mru> so it's one less case to consider [23:37:01] <mru> if you're lazy you can always implement them all by calling a generic function [23:37:41] <mru> for int32 output scaled or unscaled input doesn't really matter [23:37:43] <ruggles> or just make a macro :) [23:37:44] <mru> for neon [23:38:15] <mru> for int16 output one can get clever with scaled input [23:38:31] <mru> at least when also interleaving [23:38:38] <mru> as in the asm we have currently [23:39:42] <ruggles> ok, well i'll do more testing and cleanup and send a patch tomorrow. i'm out for the night. [23:55:19] <peloverde> I feel like if it takes you 5 hours to compile FFmpeg you are doing it wrong: http://reviews.cnet.com/8301-19736_7-20042217-251.html [23:57:00] <kierank> i remember it taking 5 hours to compile ffmpeg back in 2000 on a pentium pro

1 0

IRC log for 2011-03-11
by irc＠mansr.com 12 Mar '11

12 Mar '11

[00:00:08] <kierank> wow [00:00:21] <kierank> didn't know there was a new one [00:01:04] <ruggles> mru: since half the bands are only 1 coeff, do you think it would speed up the function to unroll and hardcode the start/end of the inner loop? [00:01:14] <kierank> Sean_McG: is there a diff anywhere [00:01:27] <Sean_McG> file diff? probably not [00:01:58] <kierank> well something showing the new bits [00:02:30] <Sean_McG> "A/52:2010 clarified several areas of ambiguity in A/52B identified by CEA working group R4.3 WG12. Additional [00:02:33] <Sean_McG> items were identified by TSG/S6 members and subsequently addressed." [00:02:49] <kierank> yeah [00:02:51] <kierank> just saw that [00:02:54] <ruggles> really? I didn't know that. the ETSI version is newer, but i think it's still 2008. [00:03:11] <Sean_McG> this was November 2010 [00:04:16] <kierank> still doesn't specify e-ac3 t-std... [00:04:31] <ruggles> t-std? [00:04:39] <kierank> transport stream system target decoder [00:04:53] <kierank> buffering model for transport streams [00:05:34] <ruggles> ah [00:06:50] <mru> ruggles: I did unroll it [00:07:43] <ruggles> mru: oh, ok. i'm curious to see it. [00:10:44] <mru> what do you think is the best way to integrate it? [00:20:12] <ruggles> mru: if the band number is <= 27 we should be able to calculate the number of bands to loop with 1 coeff rather than re-checking band_start_tab[] for every band [00:21:41] <ruggles> same for the rest, calculate number of bands with the same size and where to stop before doing the inner loop [00:23:00] <ruggles> it's 1x18, 3x7, 6x6, 12x4, 24x5. depending on where you start and end of course. [00:35:15] <ruggles> and if the non-zero start coeff makes it too expensive, we can special-case the coupling channel (or enhanced coupling channel) [00:42:13] <j0sh> kshishkov: ping [00:48:23] <mru> http://www.cs.purdue.edu/homes/dec/essay.criticize.html [00:50:53] <Sean_McG> hahaha! "Wasn't all this done years ago at Xerox PARC?" [00:59:37] <j0sh> for NEON long operations, if i do something like vaddl.u8 Qd, Dn, Dm, will the result in Qd be 16-bit? [00:59:56] <mru> yes [01:00:01] <mru> that's the point [01:00:24] <j0sh> alright cool [01:01:44] <roxfan> long = result is twice as long [01:01:50] <roxfan> narrow = result is twice as short [01:02:32] <mru> now explain wide [01:03:06] <j0sh> result and first operand are twice the width of the 2nd [01:03:31] <roxfan> wide is 2x = 2x * 1x [01:03:31] <j0sh> vaddw Qd, Qn, Dm [01:04:30] <mru> you were supposed to give an answer of the form "wide = result is twice as ..." [01:04:41] <roxfan> sorry :( [01:05:00] <mru> I know what it does... [01:05:46] <j0sh> also, if i barrel shift on a long instruction, will it overflow or is the result placed in the result [01:05:54] <mru> huh? [01:06:28] <j0sh> say i do vaddl.u8 q0, d3, d4, lsl 3 [01:06:30] <roxfan> neon insns can't use barrel shifter [01:06:37] <mru> eh what? [01:06:39] <j0sh> ohh ok [01:06:44] <mru> of course it's a barrel shifter [01:06:53] <mru> do you guys know what that means? [01:07:05] <roxfan> but afaik you can't use it the same way as with gprs [01:07:36] <mru> neon instructions don't have an inline shifter for one operand, no [01:07:38] <j0sh> mru: the shift is applied before the operation takes place [01:07:47] <mru> that's not what barrel shift means [01:08:11] <mru> a barrel shifter is a unit that can shift by any number of bits in one clock cycle [01:08:20] <mru> as opposed to iterating one bit at a time [01:08:45] <mru> the term says nothing about how it's wired into a system [01:09:05] <j0sh> but that's the behavior of the shifter on arm, no? [01:09:30] <mru> all modern cpus have barrel shifters [01:09:47] <roxfan> j0sh: there are two-op shift instructions in neon however [01:10:04] <roxfan> hmm there's even Vector Shift Right and Accumulate [01:10:05] <j0sh> alright i just assumed that to mean the shift could be done as part of the instruction [01:11:01] <mru> so you learned something today [01:11:25] <j0sh> i try to every day :) [01:11:31] <Sean_McG> ^^; [01:12:01] <roxfan> cuter pictures http://blogs.arm.com/software-enablement/277-coding-for-neon-part-4-shiftin… [01:12:04] <roxfan> *cute [01:13:14] <j0sh> sweet [01:13:29] * mru prefers reading the ref manual [01:13:53] <Kovensky> up up down down left right left right a b [01:14:18] <roxfan> at times ref manual is too detailed and you don't see the big picture [01:14:36] <mru> then you read it again [01:14:38] <j0sh> yeah and with the manual i'm not sure where to start sometimes [01:14:45] <j0sh> it's good for what it is, a reference [01:15:13] <j0sh> but noobs like me appreciate the pictures starting out :) [01:15:27] <mru> the ref manual has pictures too [01:17:51] <j0sh> hm most of the diagrams i see are instruction encodings [01:18:10] <mru> vzip has some pictures iirc [01:18:12] <mru> and vrev [01:18:46] <j0sh> ah, indeed [01:19:39] <mru> the instruction listings aren't all there is to the manual either [01:22:01] <mru> ruggles: anyway, how do you think it's best to plug in asm for bit_alloc_calc_bap? [01:22:48] <Sean_McG> holy shit it's after 8PM already [01:22:51] * Sean_McG should eat! [01:24:14] <ruggles> mru: probably add to ac3dsp for after the -960 case and pass AC3DSPContext to the shared function. [01:24:37] <mru> why do the 960 case in C? [01:24:40] <mru> it's trivial [01:24:47] <ruggles> what, just call memset? [01:25:00] <mru> what did you expect the compiler to do? [01:25:50] <mru> now that you mention it though, it can probably be done more efficiently [01:26:01] <ruggles> well, yeah i guess so. i haven't done much asm except some simple x86 simd. [01:26:42] <mru> is the bap pointer aligned or anything? [01:27:21] <ruggles> in the encoder it is. i'll have to double-check the decoder though. [01:27:54] <ruggles> not aligned in the decoder. but easily can be. [01:33:14] <CIA-36> ffmpeg: Benjamin Larsson <benjamin(a)southpole.se> master * r35d7d6f748 ffmpeg/libavformat/isom.c: [01:33:14] <CIA-36> ffmpeg: Add one more avc intra fourcc and extend the description [01:33:14] <CIA-36> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [01:44:06] <mru> is there some reason for all aligned arrays being at the end of AC3DecodeContext? [01:59:31] <mru> hmm, dsputil already has a memset(0, 128) function [02:01:28] <mru> how often does the -960 case occur anyway? [03:01:03] <Compn> merbanan : haha! were those emails a requisite of selling live.com to microsoft? :P [03:01:41] <Compn> or is that bbb's ? [03:20:39] <BBB> astrange: are you interested in mentoring a -mt project for soc this year, or rather not? [03:21:21] <BBB> not ffmpeg-mt-based per se, just threading-related, e.g. partition-threading in vp8, or more frame-based threading in various codecs where possible, maybe encoding-mt, ... [03:21:28] <mru> 18% speedup of ac3enc on arm so far [03:22:04] <Sean_McG> for when I do the same for altivec, how do I get performance numbers? [03:22:26] <mru> people still care about altivec? [03:22:32] <BBB> time ./ffmpeg -i file file.ac3 [03:22:40] <mru> or ffmpeg -benchmark ... [03:22:45] * Sean_McG shrugs, I do [03:35:58] <astrange> BBB: i don't think a project touching mpegvideoenc will succeed. i'd be ok with a project touching codecs [03:36:07] <astrange> let me check the time commitment requirement for mentors [03:37:49] <BBB> astrange: ok [03:46:21] <Compn> 1500 lines added to dsputil? [03:46:42] <Compn> THE BEAST GROWS! [03:51:59] <Compn> oh nm i read that incorrectly [03:52:03] <Compn> just moving code around [03:52:04] <Compn> whew [05:02:02] <Dark_Shikari> http://www.jwz.org/doc/cadt.html [05:11:00] <pasteeater> are regressions considered "important" in roundup or is priority more subjective? [05:12:08] <Dark_Shikari> crashes are important [05:22:50] <pengvado> anyone know a good library for runtime generation of x86 code? [05:23:20] <Dark_Shikari> what sort of runtime generation? [05:23:21] <Dark_Shikari> compilation? [05:23:25] <pengvado> jit [05:23:26] <Dark_Shikari> if so, llvm I'd assume [05:23:37] <Dark_Shikari> what are you jitting this time around? [05:23:44] <pengvado> desmume [05:23:50] <Dark_Shikari> .... desmume is entirely interpreted? [05:23:54] <pengvado> yes [05:23:58] <Dark_Shikari> jesus fucking christ [05:24:02] <Dark_Shikari> no wonder it's so damn slow [05:24:19] <Dark_Shikari> Hasn't ARM->x86 emulation been done well somewhere before? [05:24:50] <Dark_Shikari> My guess would be LLVM would probably be the best approach, but it might be rather heavy a dependency. [05:24:57] <pengvado> including timings? and dma? [05:25:10] <Dark_Shikari> a lot of games seem to work without emulating timings [05:25:15] <Dark_Shikari> I disabled that first [05:25:23] <Dark_Shikari> DMA can be interpreted [05:25:26] <Dark_Shikari> http://stackoverflow.com/questions/1413734/most-portable-jit-compiler-libra… [05:25:34] <pengvado> without *accurate* timings, sure [05:25:35] <Dark_Shikari> libjit, llvm [05:25:48] <pengvado> even with everything disabled it still keeps track of a static cost per opcode [05:26:14] <Dark_Shikari> then I would do the following: [05:26:25] <Dark_Shikari> 1) Track every possible entry point and exit point to the code [05:26:38] <Dark_Shikari> 2) Calculate the runtime of all chunks of code in there, cache it [05:26:57] <Dark_Shikari> 3) If there's a register jump, jump to a set of code that handles that and sees if that exact indirect jump has been taken before [05:27:04] <Dark_Shikari> 4) sum up these chunks as you cross the code [05:27:17] <drv> there's libcpu, but it's not anywhere near finished afaik [05:27:18] <Dark_Shikari> ... or you could just add an "add" for every single instruction you use. [05:27:30] <Dark_Shikari> doubling the total instruction count [05:27:50] <Dark_Shikari> ... you planning to get this committed? [05:28:03] <pengvado> dunno [05:28:33] <Dark_Shikari> libjit seems to be pretty nice [05:28:37] <Dark_Shikari> dunno if llvm is better [05:29:48] <pengvado> tried libjit. it incurs some overhead by exposing a risc isa. also can't omit frame pointers. [05:30:21] <Dark_Shikari> "exposing a risc isa"? [05:30:25] <pengvado> in principle it would run an optimization pass, but it doesn't [05:30:33] <Dark_Shikari> .... oh blagh. [05:30:35] <pengvado> just translates each risc instruction independently to x86 [05:30:39] <Dark_Shikari> ok, then llvm is much better [05:31:07] <Dark_Shikari> I've used llvm assembly for a class assignment, it was pretty simple [05:35:06] <Dark_Shikari> iirc it's not too different from jvm assembly [05:35:08] <Dark_Shikari> it's stack-based [05:35:18] <Dark_Shikari> or wait, no [05:35:19] <Dark_Shikari> it's register based [05:35:23] <Dark_Shikari> SSA [05:35:39] <Dark_Shikari> Now I remember having to write the SSA stuff. [05:35:54] <Dark_Shikari> useful trick for writing SSA assembly easily: simply make a new variable with every single line. [06:04:51] <astrange> code-copying is an easy way to write a jit [06:05:09] <astrange> it's basically what n64 emus do, they don't do register allocation or anything [06:05:25] <astrange> and i'm afraid llvm might be too slow for complex unclean inputs [06:12:03] <Dark_Shikari> astrange: ? [06:12:14] <astrange> ? about what? [06:12:19] <Dark_Shikari> unclean input? [06:12:47] <astrange> translating a DS instruction trace into llvm's SSA IR produces a large number of IR entries [06:13:00] <Dark_Shikari> Is a DS game that large, instruction-wise? [06:13:16] <Dark_Shikari> ... though a ROM is like, 512MB. [06:13:19] <Dark_Shikari> er, 256MB [06:13:24] <astrange> not even that, you recompile a straight-line block as you jump to it [06:13:25] <pengvado> 150000 instructions [06:13:44] <astrange> static recompilation of the whole game at once usually isn't done [06:13:50] <Dark_Shikari> I don't see something wrong with a preprocessing pass to recompile the game once [06:14:24] <astrange> they might use self modifying code [06:14:28] <pengvado> while most of the code is in rom, a little bit is executed from writable memory [06:14:39] <Dark_Shikari> the game itself does code generation? [06:14:55] <Dark_Shikari> self-modifying code sounds much scarier than generated code [06:15:32] <pengvado> not *very* self-modifying [06:15:49] <pengvado> I've seen at most 2 different contents of any given executed address [06:16:42] <pengvado> but yes, I can't just preprocess [07:34:43] <j0sh> how do you set the value of a neon register in gdb? [07:39:18] <j0sh> nvm i rtfm'd [08:03:11] <thresh> where is your japan now [08:03:17] <thresh> http://pit.dirty.ru/lepro/2/2011/03/11/45754-103441-5f43a93c2f0f571c44f4dae… [08:03:26] <Dark_Shikari> welcome to 2 hours ago [08:03:54] <thresh> our bytes are usually delayed [08:04:08] <kshishkov> thresh: неужто кто-то бросил валенок в пульт? [08:04:30] <thresh> kshishkov: ага, "чуть-чуть изменили магнитное поле Земли" [08:04:51] <thresh> незачем было Курилы требовать обратно и флаги жечь! [08:07:36] <j0sh> kshishkov: are the y/u/v offsets in swscale (that are used for mmx) safe to reuse for neon, provided i follow the same algorithm? [08:08:16] <j0sh> from a preliminary inspection they seem OK [08:08:29] <kshishkov> not sure [08:09:01] <kshishkov> at least for other struct offsets were different depending on whether you used Apple toolchain or sane toolchain [08:10:13] <j0sh> the values are loading no problem, at least under gcc/linux [08:10:24] <j0sh> havent tested on iOS yet [08:10:28] <kshishkov> exactly [08:10:46] <j0sh> i guess i'm not sure about the numbers themselves [08:11:08] <j0sh> like, the bfin algorithm is similar but uses a shift of 2 (x4) and the offsets are different accordingly [08:11:42] <kshishkov> just add av_log(NULL,0,"offset is %d\n",(char*)&context->urCoef - (char*)context) [08:11:49] <j0sh> although i'm not sure where the coeff/offset numbers come from, and why they work. they seem to be pulled out of thin air [08:13:36] <kshishkov> Ramiro was documenting them [08:13:43] <cartman> moin [08:13:50] <kshishkov> grüß dich [08:13:55] <j0sh> hmmm the tsunami warning alarms just went off here [08:14:21] <kshishkov> cartman: you should've switched greeting, ask local people if you don't believe me [08:14:38] <cartman> kshishkov: ok :) [08:14:43] <cartman> j0sh: japan? [08:15:05] <j0sh> cartman: hawaii [08:15:13] <thresh> same stuff for Russian lands on Pacific coast [08:15:22] <KotH> i've read japan? [08:15:28] <kshishkov> j0sh: offset is the difference between address of field in structure and structure address itself [08:15:34] <thresh> KotH: there is no japan now [08:15:40] <KotH> though! [08:15:41] <cartman> KotH: Earthquake in Japan [08:15:43] <cartman> big one [08:15:46] <KotH> huh? [08:15:51] <j0sh> kshishkov: ohh, so that's what it is for [08:16:08] <kshishkov> j0sh: yep [08:20:33] <Tjoppen> ooh, 9-10 bit H.264 decoding posted [08:20:53] <Tjoppen> irock: is that pullable from your github repo as well? [08:20:59] <Dark_Shikari> Yuuuup, 10-bit decoding \o/ [08:21:27] <Tjoppen> because when I tried it a few days ago it crashed on samples coming from media composer [08:21:59] <av500> does 10bit make my scen rips faster? [08:22:02] <av500> scene [08:22:14] <Tjoppen> the ones I already uploaded to mplayerhq I believe [08:22:18] <kshishkov> Dark_Shikari: when those patches are applied I'll have more evidence that FFmpeg is a Swedish project [08:22:26] <Tjoppen> SWEDISH STYLE [08:22:27] <Dark_Shikari> \o/ [08:23:16] <kshishkov> Tjoppen: thanks for reminding [08:24:25] <peloverde> greetings hobos and ninjas! [08:24:32] <thresh> what's the technical advantage of 10bit? [08:24:58] <kshishkov> peloverde: and AACenc writers! [08:24:59] <spaam> 2bits more then 8 [08:27:20] <Tjoppen> wasn't there also something about 10-bit encoding surprisingly being more efficient for 8-bit data? I recall some discussion about that a while back [08:27:46] <Tjoppen> like the improved accuracy making x264 happier [08:28:01] <Dark_Shikari> 10-15% better compression [08:28:04] <Dark_Shikari> helps more at lower bitrates [08:30:00] <irock> Tjoppen: I've refactored the code heavily over the last few days. maybe I pushed code that was incomplete. else I'd appreciate a proper bug report :) [08:30:27] <Tjoppen> I can try again later today [08:30:40] <irock> ok, thx [08:52:54] <j0sh> i'm being evacuated [08:52:57] <j0sh> wish me luck [08:53:29] <thresh> hm, hawaii is far far away from japs [08:57:42] <thresh> kshishkov: http://comicsia.ru/i/41/d9-16857.jpeg [08:58:38] <Tjoppen> lol [08:58:56] <kshishkov> thresh: да, торсионщики сильны [08:59:29] <thresh> Tjoppen: can you read russian? [08:59:41] <thresh> kshishkov: промазали немного, правда [08:59:47] <Tjoppen> no, but the absence of NA is quite obvious [08:59:59] <Tjoppen> well, I understand да :) [08:59:59] <thresh> yeah, but most fun is written [09:00:08] <Tjoppen> I see [09:01:36] <thresh> "the scheme of alleged geological changes as a result of the gravitational corrections by 'A-241' device [09:02:01] <Tjoppen> doomsday device? [09:05:17] <Tjoppen> irock: ffplay crashes, decoding is a bit off (at least when transcoding to a bunch of jpegs) [09:08:57] <irock> Tjoppen: I know ffplay doesn't like the patch. I guess I'll have to fix that.. [09:10:06] <Tjoppen> ok. there also seems to be something off when converting the pixel format as well (see the sample I PM:ed) [09:22:17] <spaam> irock: how do you test it ? using mplayer ? [09:24:25] <irock> I've tested it with x264. bitexact to dump-yuv for everything I've tried [09:54:45] <siretart> BBB: there, first sandy fate runs: http://fate.ffmpeg.org/x86_64-avx-linux-gcc-4.5/ [11:22:29] <Mathias2> I just wanted to submit a bug... [11:22:34] <Mathias2> so I registered on the bugtracker [11:22:41] <Mathias2> clicked the activation link in my email [11:22:46] <Mathias2> I got an error there... [11:23:12] <Mathias2> but I still logged in and the first thing I was presented with is the complete user list with email adresses and phone numbers [11:27:10] <Mathias2> Nobody interested in this kind of critical security flaw? [11:28:46] <Dark_Shikari> people are probably alseep [11:28:50] <Dark_Shikari> wait until later [11:29:58] <Mathias2> I will try it later... [11:30:00] <siretart> lu_zero: ^^ [11:31:11] <kshishkov> siretart: do you care to push new decoder? [11:32:01] <siretart> kshishkov: sorry, I'm about to leave for skiing weekend with work collegues [11:32:27] <siretart> just returned from a business trip last night [11:33:51] <kshishkov> that sucks [11:34:32] <lu_zero> Mathias2: which error? [11:35:25] <Mathias2> The "I can see everyones email and phone number on the bug tracker" security issue [11:35:37] <Mathias2> and probably change it too [11:36:08] <Mathias2> (no, there is no save button, so I probably can't change them) [11:36:38] <Compn> people put their phone numbers into the bug tracker ? ;P [11:36:58] <Mathias2> just like every 20th [11:37:35] <Mathias2> But I'm not supposed to see everyones email right? [11:37:53] <Compn> all our emails are public anyways [11:38:03] <Compn> how else are people supposed to report bugs [11:38:10] <Mathias2> I can also see the SHA hashes of passwords that were changed [11:38:25] <Mathias2> aren't they supposed to use the bugtracker? [11:38:26] <Compn> https://roundup.ffmpeg.org/user [11:38:30] <Compn> thats what you are talking about ? [11:38:33] <Compn> the userlist ? [11:38:55] <Mathias2> thats it [11:39:03] <Mathias2> is that supposed to be visible to everyone? [11:39:11] <Mathias2> with mail, changed password hashes and so on? [11:39:34] <Compn> i dont see changed password hashes [11:39:39] <Mathias2> https://roundup.ffmpeg.org/user10 [11:39:42] <Compn> sounds like a bug [11:40:33] <Compn> you can report it on the bugtracker maybe :) [11:40:45] <Compn> as you can see, my password is now set to *encrypted* :) [11:40:52] <Mathias2> :) [11:41:07] * Compn finds another roundup to look at [11:41:59] <Compn> ah forgot have to login [11:42:15] <Compn> Mathias2 : anyways, mru or lu_zero would be the ones to ask about it [11:49:13] <lu_zero> Mathias2: what's the problem exactly? [11:53:11] <Compn> Mathias2 can see emails and password hashes! :P [11:53:39] <Mathias2> you know when I register somewhere, I'm kinda used to that my email is not published to everyone else [11:54:08] <Mathias2> the hashes are salted so probably useless, so the security implications are probably not that severe [11:54:24] <Mathias2> but still, its not what I would expect to happen [11:54:54] <kshishkov> lu_zero: also can you please push JV decoder? [12:10:53] <Mathias2> great... now I tried to file the bug report, wrote the text and got an error after submitting [12:11:09] <Mathias2> and when I get back, the text field is empty... [12:12:42] <Flameeyes> lu_zero: uhm okay tell me again why we use roundup? :P [12:13:42] <lu_zero> Flameeyes: because somebody asked vehemently not to use bugzilla [12:13:52] <Flameeyes> lu_zero: who? [12:14:05] <lu_zero> michael [12:14:52] <mru> let's change then [12:15:00] <mru> recent bugzilla versions are actually quite nice [12:15:11] <mru> a few years ago they were rather clunkier [12:15:12] <kshishkov> are they secure enough? [12:15:17] <mru> who cares? [12:15:21] <lu_zero> kshishkov: they work fine [12:15:27] <mru> ooooh, someone can see my bugs!!#!@11! [12:15:28] <Flameeyes> kshishkov: both me and lu_zero already manage one each [12:15:32] <lu_zero> and are a breeze to setup [12:15:39] <Flameeyes> mine's on valid ssl as well [12:16:14] <kshishkov> mru: have you ever heard of PHP? [12:16:20] <lu_zero> for that we should ask for a proper certificate [12:16:37] <mru> php isn't inherently insecure [12:16:49] <Flameeyes> kshishkov: bugzilla is in Perl [12:16:59] <mru> it comes (or used to at least) with some rather ridiculous defaults though [12:17:08] <mru> and there's a lot of really poor code written for it [12:17:32] <kshishkov> and I heard that mod_php in Apache was secure as a shoelace for padlock [12:17:46] <mru> maybe [12:17:49] <mru> but does it matter? [12:18:01] <thresh> you've never seen mod_perl then [12:18:13] <mru> well, I don't run apache at all [12:18:19] <kshishkov> thresh: I cherish my ignorance [12:18:23] <mru> to much black magic for my liking there [12:18:28] <Flameeyes> kshishkov: they added support for fcgi in php recently [12:18:37] <thresh> yeah like years ago [12:18:48] <thresh> they added support for fpm some time ago [12:18:50] <kshishkov> Flameeyes: I don't care about PHP [12:18:51] <mru> php has had fcgi for much more than a year [12:19:02] <thresh> which is better than spawn-fcgi, for sure [12:19:21] <iive> wasn't there some security researcher who left php development because others didn't accept his improvements of the security? [12:19:22] <Flameeyes> to me anything in the past two years is "recently" for what concerns php [12:19:27] <Flameeyes> I haven't used it directly in over six... [12:19:33] <thresh> iive: suhosin guy [12:19:44] <kshishkov> Flameeyes: never used it at all [12:19:45] <thresh> adding security to a sieve [12:19:58] <Flameeyes> thresh: heh... and I had to fix suhosin myself at some point... [12:20:03] <thresh> needless to say, with suhosin patch enabled, almost no webapps do work [12:20:34] <kshishkov> thresh: в советских реалиях - усилить охрану на проходной, а забор по прежнему не чинить [12:20:37] <iive> this for me is the definition of inherently insecure [12:20:40] <Flameeyes> thresh: like setting up mod_security with the default settings? [12:21:01] <thresh> Flameeyes: no, just enabling suhosin results in non-working code :) [12:21:19] <Flameeyes> thresh: no doubt, the bloody thing didn't link in properly to libcrypt to begin with [12:21:24] <thresh> hehe [12:21:26] <Flameeyes> and only worked if php was bringing libcrypt in itself... [12:21:36] * kshishkov wonders why WMAL is not 1st-tier project for gsoc [12:22:18] <Flameeyes> okay this box is doing a bloody update, not nice to work on... gotta fetch the laptop [12:22:31] <thresh> kshishkov: because BINK is? [12:22:43] <kshishkov> thresh: neither is Bink encoder :( [12:27:52] <thresh> oh, VLC doesnt play bink files [12:28:05] <mru> fix it! [12:28:12] <thresh> yes sir [12:28:41] <kshishkov> mru: can any of you push JV decoder? [12:29:01] <kshishkov> should be another format that VLC doesn't support [12:45:33] <thresh> kshishkov: hey, I dont want to recompile full VLC once again just because of you! [12:46:14] <kshishkov> thresh: it's mostly because of Peter [12:47:39] <thresh> you sneaky ukrainians [12:48:33] <kshishkov> thresh: could be worse [12:48:46] <kshishkov> thresh: sneaky Indians or Chinese [12:48:53] <thresh> kshishkov: true [12:49:55] <kierank> thresh: troll ukranian politics [12:50:46] <kshishkov> kierank: they know only one way to troll - accuse Ukraine of stealing gas [13:17:26] <thresh> are there any bink samples to test? the ones I randomly picked on samples, do not [13:18:02] <thresh> hmm, I may need to recompile ffmpeg [13:18:11] <av500> again? [13:18:28] <thresh> not VLC this time! [13:19:15] <pross-au> thresh: there are bink samples in the fate suite [13:19:34] <kshishkov> thresh: http://samples.mplayerhq.hu/game-formats/bink/ [13:20:41] <pross-au> no bink 'd' samples yet.. [13:21:08] <spaam> pross-au: you know what you have to do. [13:22:35] <pross-au> Yep. Night! [13:22:43] <Compn> KotH : oh man this is gonna set anime releases back ;\ [13:22:57] * Compn wonders if japan is ok [13:23:16] <kshishkov> pross-au: no worries, I don't have even decoder for it [13:24:14] <KotH> Compn: dunno.. didnt had time to call my friends overthere [13:27:03] <spaam> they lost some trafic .. http://www.jpnap.net/english/jpnap-tokyo-i/traffic.html [13:34:10] <Compn> we had some .jp devels in here didnt we ? [13:34:13] <Compn> wonder how they are doing [13:34:25] <JEEB> most of those that are online are alright [13:34:34] <Compn> Chikuzen : are you in japan ? [13:34:38] <JEEB> yah, he is [13:34:53] <Compn> [04:08] <j0sh> i'm being evacuated [13:34:53] <Compn> [04:08] <j0sh> wish me luck [13:34:53] <Compn> [04:08] * j0sh (~josh(a)cpe-24-161-146-104.hawaii.res.rr.com) Quit (Quit: Lost terminal) [13:34:59] <Compn> ooh hawaii too [13:35:07] <JEEB> yah, not surprising [13:35:17] <JEEB> the tsunami's probably going there, too [13:35:28] * Compn never saw 'japan sinks' movie [13:36:15] <JEEB> watching TBS live, but afterquakes have been coming in every 20-30min or so [13:36:50] <kierank> Compn: that's incredibly chilling [13:39:04] <lu_zero> OUCH [13:39:45] <thresh> do I need to provide something special to libav to be able to demux&play bink ? now it's like Unknown block type 11 etc spam [13:40:29] <spaam> bad joke: [13:40:30] <spaam> "chin up Japan. If you watch Godzilla backwards, it's about a giant lizard who helps rebuild a half destroyed city and then moonwalks back into the ocean" [13:40:57] <kshishkov> thresh: extradata? codec_tag? [13:53:58] <thresh> kshishkov: ffplay doesnt set those :P [13:54:27] <kshishkov> thresh: and yet FFplay works and VLC doesn't [13:54:36] <kshishkov> thresh: so which is superior? [13:54:48] <thresh> not really works [13:55:05] <thresh> ffplay doesnt know anything about xinerama for instance :) [13:59:41] <thresh> hmm, CGOOD3.bik is ok [14:01:48] <kshishkov> it's bink-b :) [14:02:35] <thresh> original.bik is the one causing troubles [14:07:19] <pengvado> Dark_Shikari: llvm assembly, or C code that generates the internal representation of llvm assembly? the latter is like an order of magnitude more verbose. [14:41:57] <DonDiego> yo [14:42:23] <kshishkov> y? [14:53:10] <lu_zero> ya(wn) ? [14:54:40] <kshishkov> lu_zero: Yet Another Wasted Night? [14:57:54] <mru> ruggles: ping [14:58:10] <ruggles> mru: pong [14:58:45] <mru> do you know what the distribution of values is typically like in compute_mantissa_size? [14:58:53] <mru> and can nb_coefs be zero? [14:59:51] <ruggles> nb_coefs cannot be zero [15:00:05] <kshishkov> it has hardcoded floor value IIRC [15:00:15] <ruggles> and do you mean for all mantissas? [15:00:39] <kshishkov> CPL/LFE/FWB ones :) [15:01:58] <ruggles> for nb_coefs: minimum 73 max 253 for full-bandwidth channels. 7 for lfe. 36 minimum for coupling i think. [15:02:31] <ruggles> oh wait, no coupling can be 12 [15:04:04] <ruggles> mru: compute_mantissa_size will depend greatly on the bandwidth. the majority of bits are for mantissas. [15:04:36] <ruggles> s/bandwidth/bitrate [15:04:46] <ruggles> well, and bandwidth too i guess [15:11:15] <mru> that tiny function is using a lot of cpu time [15:11:22] <ruggles> mru: the exponents and other misc bits have a very narrow range not depending on bitrate. the rest of the bits are mantissas. [15:17:01] <mru> hah, I'm faster than gcc [15:17:45] <kshishkov> of course you are [15:18:03] <kshishkov> not on compiling stage though [15:22:11] <ruggles> can i compile ffmpeg with manscc? [15:22:21] <kshishkov> too expensive [15:22:28] <ruggles> :) [15:23:09] <mru> probably, yes [15:25:08] <mru> but I bet it would fly [16:17:00] <Compn> mms://nhk-world.gekimedia.net/nhkw-highm [16:17:05] <Compn> watch nhk live in english [16:17:09] <Compn> evacuation notices [16:29:17] <lu_zero> kshishkov: poing [16:40:25] <mru> another 7.5% faster [16:40:44] <mru> by writing compute_mantissa_size in asm [16:40:54] <av500> what codec? [16:40:57] <mru> ac3enc [16:45:41] * kierank wonders who is funding ac3enc opts [16:45:50] <mru> ARM [16:45:53] <kierank> LOL [16:46:01] <kierank> it seems they don't care about their relationship with dolby then [16:46:24] <mru> they've suddenly decided that open source matters [16:46:25] <av500> what does arm want it for? [16:46:36] <Compn> av500 : dumb ac3 recievers no doubt [16:46:37] <Compn> :P [16:47:52] <av500> Compn: can I stop listening to these tsunami warnings now? my coworker are rebelling [16:48:08] <Compn> av500 : haha, i was looking for a better stream but gave up [16:48:45] <mru> av500: are they starting a tsunami of their own? [16:48:58] <mru> av500: btw, don't you have a door to your office? [16:49:10] <av500> I also have very good speakers [16:49:34] <mru> s/good/loud/ [16:50:04] <av500> they even make fancy disco lights when loud [16:51:39] <twnqx> Oo [16:54:15] <av500> twnqx: overvoltage protection with glow lamps [17:17:19] <kshishkov> lu_zero: piong [17:17:54] <mru> ruggles: can the bap pointer passed to compute_mantissa_size be guaranteed one extra element? [17:18:12] <mru> over-reading by one makes it faster [17:18:17] <ruggles> mru: yes [17:18:26] <ruggles> 3 extra elements in fact [17:18:36] <mru> cool, so I'm safe then [17:18:40] <ruggles> max nb_coefs is 253 [17:18:54] <mru> and 256 are allocated, I take it [17:19:01] <ruggles> yes [17:19:28] <ruggles> 256*6*channels [17:19:43] <mru> yeah, I noticed they're allocated as one block [17:20:21] <ruggles> yes, allows processing all at once or separately. and swapping the base pointer around. [17:20:30] <mru> btw, http://git.mansr.com/?p=ffmpeg;a=shortlog;h=refs/heads/ac3 [17:22:48] <ruggles> awesome [17:24:00] <lu_zero> kshishkov: do you recall enough of flv? [17:24:27] <kierank> lu_zero: what do you want to know [17:24:27] <kshishkov> lu_zero: depends on "enough" [17:25:00] <lu_zero> trying to get a data stream in flv [17:25:11] <lu_zero> the spec states something about scriptdata [17:25:14] <lu_zero> but not much [17:25:31] <lu_zero> and seems that there isn't a real way to signal it in the headers [17:26:06] <kshishkov> FLV headers are next to nonexistant [17:26:19] <kierank> the flv header is three characters [17:26:37] <kshishkov> wrong [17:26:49] <kshishkov> they also have one byte to denote streams present [17:26:52] <lu_zero> there is one for stating if there is video or audio or both [17:26:55] <kshishkov> and some other junk [17:27:09] <lu_zero> but I couldn't see a bit for metadata [17:28:02] <kshishkov> http://www.adobe.com/content/dam/Adobe/en/devnet/swf/pdf/swf_file_format_sp… mentions HasMetadata flag [17:28:33] <ruggles> mru: nice build system patch. that should be committed. [17:28:47] <mru> I'll reshuffle those commits later [17:29:54] <lu_zero> I read the flv pdf looks like it was lacking [17:32:03] <lu_zero> uhm [17:32:19] <mru> ruggles: what's the status of your latest batch? [17:32:41] <lu_zero> I need something useful to encode a generic stream that's not video or audio [17:33:06] <lu_zero> s/encode/mux-and-signal/ [17:33:20] <ruggles> mru: well, thought i would finish today but my main dev computer is acting weird. i'm working on my laptop, but i'm not as efficient... [17:33:46] <mru> ok, so you're still working on it [17:33:55] <mru> just making sure it wasn't sitting in the corner all forgotten [17:34:09] <ruggles> yes. cleaning it up. [17:35:37] <kshishkov> lu_zero: IIRC FLV can have generic metadata blob with AS[13]-encoded data [17:53:28] <lu_zero> kshishkov: that part is more or less clear to me [17:54:00] <lu_zero> the doubt is how to make ffmpeg show the data stream [17:54:27] <kshishkov> tere's no way currently [17:54:42] <kshishkov> script data will be treated as metadata and parsed so [17:55:25] <kshishkov> the only way is to add there AMF blob handling and to pretend they are data packets [18:07:24] <lu_zero> so there isn't a sane way [18:08:24] <lu_zero> either I put a start blob and have ffmpeg look for it on start [18:08:55] <lu_zero> or hack ffmpeg to always declare the data stream and if it's there or not I'll discover later [18:15:09] <kshishkov> exactly [18:16:09] <kshishkov> though IIRC flv demuxer does some parsing at the beginning to find out if streams are really there, so the first dummy blob can help (just with string "ffmpeg_data_stream_present=true" ;) [18:17:13] <lu_zero> that's the idea [18:17:24] <lu_zero> but I wasn't that _happy_ of that [18:18:02] * kshishkov is not happy of FLV overall [18:23:36] <lu_zero> kshishkov: sadly [18:29:08] <ruggles> does git have an easy way to "git reset --soft HEAD^" and "git commit -a" with the original commit message so i don't have to copy/paste the commit message? [18:34:05] <BBB> git --amend -c HEAD? [18:34:27] <kshishkov> BBB: please push Peter's JV decoder [18:34:39] <BBB> kshishkov: please fix our vc1 decoder [18:35:00] <BBB> I'll push stuff this weekend if I get any second off from my wife ;) [18:35:07] <BBB> for now, I need the vc1 decoder to not suck [18:35:22] <kshishkov> BBB: IIRC loop filtering order was changed to be bitexact - ironic, isn't it? [18:35:35] <kshishkov> why? [18:35:48] <BBB> why not [18:35:53] <BBB> DonDiego: please fix issue455 [18:36:25] <mru> BBB: -c HEAD is default [18:36:58] <ruggles> BBB: thanks. i haven't tried using amend [18:49:45] <iive> kshishkov: 4 down, 4 to go. [19:10:35] <Dark_Shikari> pengvado: llvm assembly [19:10:51] <Dark_Shikari> we wrote a program that compiled a basic C-like language into llvm asm [19:11:03] <Dark_Shikari> llvm asm is like an SSA version of JVM asm [19:11:15] <Dark_Shikari> As in, our program did the parsing, lexing, and turned it into llvm statements [19:11:20] <Dark_Shikari> and llvm did the optimizing and assembling [19:11:32] <Dark_Shikari> we gave LLVM the ssa asm. [19:11:46] <mru> so you wrote a compiler frontend [19:12:01] <Dark_Shikari> yes. [19:23:42] <DonDiego> BBB: no idea what to do about kandalu - they stopped using ffmpeg apparently, but they obviously violated our license in the past [19:24:10] <DonDiego> at least they claim not to use ffmpeg anymore [19:24:52] <DonDiego> i haven't checked their programs manually (again) - that's likely quite a bit of work and might require an iphone or a mac [19:25:38] <Zor> Dark_Shikari: what was your experience with llvm? did it have reasonable APIs, did it optimize well, etc [19:26:01] <mru> llvm is a compiler like any other [19:27:36] <mru> with one difference: it is designed to be usable as a library as well [19:41:04] <Kovensky> 16:11.04 Dark_Shikari: llvm asm is like an SSA version of JVM asm <-- SSA? [19:42:56] <gnafu> Kovensky: Perhaps one of these: [19:42:57] <gnafu> http://en.wikipedia.org/wiki/SSA#Computing_and_data_analysis [19:42:57] <gnafu> ? [19:43:15] <gnafu> I'm guessing this one: [19:43:16] <gnafu> http://en.wikipedia.org/wiki/Static_single_assignment_form [19:44:07] <gnafu> And the "Compilers using SSA form" section mentions LLVM, so I'm going to increase my confidence to 95-99%. [19:47:02] <lu_zero> kshishkov: which is the thread I should look for? [19:53:01] <Dark_Shikari> Zor: we didn't handle that part of it, the professor wrote the interface [19:53:03] <Dark_Shikari> or actually [19:53:05] <Dark_Shikari> we outputted raw asm [19:53:08] <Dark_Shikari> and just ran llvm on that asm [19:53:13] <Dark_Shikari> so not even our professor did. [19:53:22] <Dark_Shikari> So we didn't actually call the lib, but it's probably not very different [19:54:51] <Zor> I'm contemplating using it in a language-neutral VM [20:09:00] <mru> ruggles: ping [20:09:30] <ruggles> mru: pong [20:09:56] <mru> extract_exponents is my new victim [20:10:39] <ruggles> ok. notice the patch set i'm working on modifies that. [20:11:00] <ruggles> gets rid of exp_shift [20:11:04] <mru> cool [20:11:14] <mru> right, I remember that [20:11:42] <ruggles> also, some of these functions will need to take start/end instead of nb_coefs for channel coupling [20:12:09] <ruggles> now start is 0, but coupling channel does not start at 0 [20:12:13] <mru> count is just a subtraction away [20:13:36] <ruggles> indeed. but the start pointer won't be aligned. [20:13:46] <mru> so be it [20:14:20] <ruggles> just letting you know in case that affects how you're implementing it [20:14:48] <mru> unaligned load/store is slower of course [20:14:58] <mru> but if that's how it has to be... [20:17:00] <mru> the patch you already posted just gets rid of exp_shift [20:17:12] <mru> which simply means there's one thing less to do [20:18:13] <mru> how far away is the final version of that patch? [20:20:34] <ruggles> mru: i think my computer might fixed now *crossing my fingers* so i can send a new patch within an hour or so [20:20:46] <mru> great [20:21:35] <DonDiego> BBB: your opinion on kandalu? [20:45:53] <ubitux> do you guys plan to make a sws_scale2() someday in order to change the crazyness of the const in the prototype? [20:46:47] <ubitux> the src parameter is quite annoying [20:48:51] <mru> it's _all_ annoying [20:49:49] <kshishkov> at least it's well optimised for NEON [21:25:03] <vcs> I know this is not the vlc channel, but why would the -ss parameter work on ffplay (i support seeking and give all streams a duration), but not when i build into vlc? the bar just stays at once place and when it seeks, it just stops playing like it hit the end of the file [21:28:05] <vcs> i based my demultiplexer on avidec.c, and seeking/duration with avi files work fine [21:38:44] <ubitux> http://git.ffmpeg.org/?p=ffmpeg.git;a=blob;f=libavformat/utils.c;hb=HEAD#l2… ← can anyone tell me why is there this exception here? [21:39:18] <kshishkov> SBR? [21:40:09] <ubitux> is it the only codec in this case? [21:41:04] <ubitux> (http://en.wikipedia.org/wiki/Spectral_band_replication ?) [21:41:12] <mru> because lavf is _all_ exceptions [21:41:35] <ubitux> i was just surprised to find this exception here [21:41:50] <kierank> if you try and create libraries to handle all types of formats/codecs you're bound to have exceptions [21:50:44] <ubitux> (is it normal to have access to the whole user list in the roundup?) [21:52:42] <ubitux> it seems i have more permissions than i should have [21:53:10] <ruggles> mru: sending ac3 patch set soon. just need to run Atom benchmarks. [21:53:10] <ubitux> like removing messages or access to the whole user list [21:53:20] <Mathias2> I asked the same question about the permissions earlier this day :) [21:53:48] <mru> ubitux: if you don't want people to know somthing about you, don't write it on the bloody internet [21:54:23] <Mathias2> but how am I supposed to send in bugreports, when the bugtracker needs registration and a valid email address? [21:54:24] <ubitux> what about the remove option? [21:54:41] <mru> talk to lu_zero about those things [21:54:45] <ubitux> ok [21:54:45] <Mathias2> plus, how should I know that when I register on the bugtracker, my email is visible to everyone? [21:55:00] <mru> you should assume _everything_ on the internet is [21:55:29] <Mathias2> youre right there... [21:55:45] <Mathias2> still, IMO it should be changed [21:55:59] <mru> you can always register with a throwaway gmail address or something [21:56:29] <Mathias2> I do that for services I don't know [21:56:39] <Mathias2> but I thought ffmpeg are not the bad guys, so what the hell [21:59:38] <Dark_Shikari> email addresses are for people to contact you [21:59:47] <Dark_Shikari> >_> [22:04:25] <mru> we're not the bad guys [22:04:30] <mru> did we ever send you spam? [22:13:05] <Mathias2> you didn't send me spam, but everyone that registers can send me spam [22:14:44] <Dark_Shikari> Um, it's an email address. It's on the internet. People can spam you. [22:14:51] <Dark_Shikari> And they will nicely go into your spam filter. [22:14:54] <Dark_Shikari> And you will never see them again. [22:16:29] <Mathias2> well since a few months ago spammers started to know my real name I don't have much to loose anyways [22:17:01] <Mathias2> was because a show where I bought somehow lost their database... [22:17:14] <mru> I get thousands of spam mails _every day_ [22:17:42] <mru> one or two of those sneak through the filters far enough that I see them [22:17:47] <mru> but still in the spam box [22:17:57] <Mathias2> congratulations, I hope you can spare me the joy [22:18:30] <mru> I've never tried to hide my email addresses [22:18:44] <mru> and every address I've used since 1999 still works [22:19:00] <mru> and I don't have a spam problem [22:28:50] <ruggles> mru: after the patches i sent, extract_exponents() can operate on the whole buffer instead of one block at a time. [22:29:03] <mru> even better [22:59:20] <CIA-36> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r3f8040db3e ffmpeg/configure: (log message trimmed) [22:59:20] <CIA-36> ffmpeg: configure: improve pkg-config support [22:59:20] <CIA-36> ffmpeg: This adds helper functions for checking packages with pkg-config [22:59:20] <CIA-36> ffmpeg: and managing the associated flags. [22:59:20] <CIA-36> ffmpeg: Note that pkg-config use is still discouraged due to widespread [22:59:21] <CIA-36> ffmpeg: poor practices resulting in broken flags in many situations. A [22:59:22] <CIA-36> ffmpeg: few badly designed packages require flags only obtainable using [22:59:33] <CIA-36> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r4fa18c5666 ffmpeg/configure: [22:59:33] <CIA-36> ffmpeg: configure: use pkg-config helpers [22:59:33] <CIA-36> ffmpeg: This makes existing pkg-config uses as well as the libsdl checks [22:59:33] <CIA-36> ffmpeg: use the new pkg-config helper functions, which should be more [22:59:34] <CIA-36> ffmpeg: robust against broken systems. [22:59:34] <CIA-36> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [22:59:38] <CIA-36> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * redaf1ae276 ffmpeg/configure: (log message trimmed) [22:59:38] <CIA-36> ffmpeg: configure: allow checking multiple functions in check_func_headers() [22:59:38] <CIA-36> ffmpeg: This makes it possible to pass a space-separated list of functions [22:59:38] <CIA-36> ffmpeg: to check_func_headers and check_lib2. If any function is missing, [22:59:39] <CIA-36> ffmpeg: none are enabled as available, so this should only be used for [22:59:39] <CIA-36> ffmpeg: all-or-nothing sets, i.e. groups in which none will be used if any [22:59:40] <CIA-36> ffmpeg: one is missing. [23:03:22] <asdf1234> in justin's last patch, if this is for performance, shouldn't the first jz in ac3_%1shift_int%2_%4 be moved out? saves a call [23:05:53] <mru> ruggles: ^^ [23:08:14] <peloverde> I'm freeeeeeeeeeeeeeeeeeeeeeeeeeeeee [23:08:21] <mru> congrats [23:09:32] <iive> ? [23:09:50] <Dark_Shikari> BBB: ping [23:12:50] <asdf1234> ruggles: also, why align 8 vs something else? [23:13:12] <mru> you'd rather have 7 or 9? [23:14:24] <asdf1234> how about 16 or 4? why 8? [23:19:33] <ruggles> asdf1234: that's what is fastest in all the tests i did [23:22:33] <ruggles> asdf1234: i'll try moving the check out. i think it was slower when i first wrote the int16 version a while ago. but it's worth re-testing. [23:22:39] <DonDiego> peloverde: ? [23:24:06] <peloverde> today was my last day at zoran [23:26:16] <peloverde> I have the whole weekend to work on whatever I want without any employment agreements hampering me [23:27:32] <DonDiego> :) [23:27:47] <gnafu> peloverde: Their website looks cheesy. [23:27:53] <DonDiego> there's plenty of stuff awaiting review... [23:28:12] <mru> peloverde: when do you start your new job? [23:28:18] <kierank> peloverde: where are you going? [23:28:19] <DonDiego> i'll try to take some time off when i'm back from travelling... [23:28:57] <gnafu> Like, there's a green laser blowing up (communicating with?) a satellite, and a bunch of smiling faces. [23:29:08] <peloverde> I start Monday with these people: http://www.youtube.com/watch?v=Tlmho7SY-ic [23:29:29] <peloverde> I was supposed to have most of this week to myself but I let zoran pull me back for it [23:31:04] <gnafu> peloverde: Oh, that's right. Are you going to help with integrating xvp8 into YouTube's workflow? ;-) [23:32:44] <kierank> good to see youtube recognising ffmpeg [23:33:03] <mru> I don't see that they are [23:33:11] <kierank> they do privately anyway [23:38:59] <asdf1234> ruggles: ok, just wondering. i haven't run tests either [23:44:07] <asdf1234> ruggles: i don't think you need that arg if you move out the check for that matter [23:45:03] <asdf1234> oh nvm [23:55:13] <mru> can we just decide on something soon? [23:55:20] <mru> this is blocking my work [23:56:54] <Dark_Shikari> Anyone want to bench my vp8 decoder patch? [23:56:58] <Dark_Shikari> My computer has too high stddev to do it

1 0

IRC log for 2011-03-10
by irc＠mansr.com 11 Mar '11

11 Mar '11

[00:05:12] <Sean_McG> hmmm, I always have to reset my tty after running FATE on OS X [00:05:37] <mru> some test failing? [00:05:50] <Sean_McG> no, it's all green [00:07:25] <Shu> fate also has issues if you cancel in the middle of it [00:10:48] <Sean_McG> does ccache work properly across compiler versions? [00:11:29] <mru> that's dragon territory [00:11:33] <Sean_McG> ah [00:23:42] <Sean_McG> http://theoatmeal.com/comics/sriracha [00:24:06] <j0sh> mru: how do you debug ffmpeg on an iOS device? gdb on it (from cydia) crashes whenever i try to display contents of the q NEON registers [00:24:17] <j0sh> and i can't set breakpoints unless i upload my code too [00:24:30] <mru> j0sh: I don't touch ios devices [00:24:36] <j0sh> :) [00:25:02] <mru> debug on linux [00:31:22] <lu_zero> j0sh: remote debug =P [00:31:28] <lu_zero> and don't use cydia ^^; [00:31:55] <j0sh> lu_zero: yeah trying to see if i can hook up xcode's gdb somehow [00:32:46] * j0sh wishes he didn't leave his beagleboard at home [00:32:58] <j0sh> then linux debugging would be an option [00:34:16] <lu_zero> ^^; [00:34:34] <lu_zero> I could give you access to one of my efikas [00:35:27] <j0sh> sure [00:36:18] <Dark_Shikari> http://thedailywtf.com/Articles/Logging-the-Logger.aspx <--here's a great way we can improve av_log [03:00:22] <Kovensky> 21:11.37 mru: that's dragon territory <-- http://static.arstechnica.com/20090828/llvm-logo.png [03:58:38] <Dark_Shikari> time to shrink ffmpeg.exe by doing nothing but reordering a struct [03:58:47] <Dark_Shikari> start: 6485518 bytes. [04:02:12] <Dark_Shikari> or, well, let's go by the size of vp8.o [04:02:14] <Dark_Shikari> so it doesn't round. [04:02:39] <Dark_Shikari> 82026 bytes [04:03:09] <Dark_Shikari> 78574 [04:03:38] <Dark_Shikari> 78494 [04:03:53] * Dark_Shikari should find a way to count bytes while ignoring the header functions. [04:20:15] <Dark_Shikari> Is there a way to print the layout of a C struct, byte-offset wise? [04:22:09] <astrange> readelf --debug-dump=something [04:22:23] <Dark_Shikari> on windows? [04:24:30] <astrange> not sure. what does gcc -g do on wndows? [04:24:31] <astrange> i [04:50:43] <Dark_Shikari> ... what's the option to change the alignment of functions in gcc? [04:50:49] <Dark_Shikari> so there's no padding bytes inserted. [04:51:23] <Dark_Shikari> I found the one for stack alignment [04:52:28] <Yuvi> http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html claims it's __attribute__((aligned(x))) [04:52:50] <Dark_Shikari> oh, you can't make it a commandline option [04:53:01] <Yuvi> -falign-functions=1 ? [04:53:28] <Dark_Shikari> oh, you can. [04:54:25] <Yuvi> oh the function attribute can't decrease alignment anyway [04:54:46] <Dark_Shikari> oh, lame. [04:54:58] <Yuvi> command-line should allow no alignment though [04:56:12] <Dark_Shikari> are there any other falign things that go by default? [04:56:13] <Dark_Shikari> like loops? [04:56:16] <Dark_Shikari> which I should turn to 1? [04:56:50] <Dark_Shikari> jumps, labels, loops, functions [04:57:16] <Dark_Shikari> I see, -Os does these [06:14:15] <Dark_Shikari> oh my god I just had the most terrible idea ever. [06:14:34] <Dark_Shikari> So, on x86, memory args of the form [reg+X] take 1 byte for X=-128 to 127 [06:14:37] <Dark_Shikari> and 4 bytes for larger. [06:14:49] <Dark_Shikari> This means it's beneficial to fit your working set, or as much as possible, inside 128 bytes. [06:15:08] <Dark_Shikari> .... but.... if you're a gigantic jackass... you can subtract 128 from your avctx->priv_data pointer. [06:15:18] <Dark_Shikari> And add it back every time you access a variable within. [06:15:28] <Dark_Shikari> Or, wait, add it first, then subtract it back. [06:15:31] <Dark_Shikari> This gives you double the space. [06:37:43] <Dark_Shikari> #define ss ((VP8Context*)(((uint8_t*)s)-128)) [06:37:44] <Dark_Shikari> #define priv_data (((VP8Context*)(((uint8_t*)avctx->priv_data)+128))) [06:37:45] <Dark_Shikari> kill me now [06:37:58] <Dark_Shikari> I think this might even be legal c [06:48:33] <elenril> is that lisp? [06:50:04] <thresh> lol [06:53:35] * elenril pokes BBB [06:54:33] <Zor> lisp [06:54:34] <Zor> where [06:54:43] <Zor> I want to see all the pretty parentheses [06:57:15] <KotH> salut [06:57:35] <av500> +1 [06:57:48] <thresh> moroning [07:55:02] <spaam> God morgon :D [08:05:07] <pJok> god morgon :) [09:20:31] <osmancorp> Hello [09:23:14] <spaam> Hello [09:23:44] <j0sh> is there a way to negate a 64-bit value in NEON? [09:24:01] <j0sh> VNEG only works up to 32-bit elements [09:28:44] <kshishkov> veor q0, q0, q0 \n vsub.i64 qX, q0, qX ? [09:30:17] <spaam> vsub.i128 you get 128bit ? [09:30:47] <spaam> Is there any 64bit arm cpu's? [09:31:04] <j0sh> kshishkov: hmm that's clever [09:31:19] <j0sh> spaam: i don't know but my values are 64bit [09:31:35] <j0sh> i hope that doesnt compilicate later calculations [09:32:37] <av500> spaam: no [09:33:04] <av500> the A15 is still a 32bit cpu, but has a 64bit address range [09:34:01] <j0sh> that's... puzzling. so integers are 32bit but pointers are 64? [09:34:20] <cartman> moin [09:34:52] <av500> j0sh: no [09:35:00] <av500> its more like PAE [09:35:20] <av500> the OS can have several 32bit processes running in a 64bit address space [09:35:32] <av500> and each can have the full 32bit range [09:36:37] <j0sh> ah i see, so it's mapped a bit like virtual memory [09:36:43] <av500> yes [09:36:47] <av500> virtual virtual memory [09:36:54] <spaam> av500: ok :) [09:37:43] <kshishkov> and that's in time when even China porduces 64-bit MIPS :( [09:38:13] <av500> kshishkov: so, go to china then [09:38:17] <osmancorp> someone could help me in understanding you it structures libavcodec ? please ..... [09:38:50] <av500> quoi? [09:38:58] <kshishkov> av500: I don't want to go to ARMland either [09:39:20] <kshishkov> av500: nor to United States of x86 [09:40:00] <osmancorp> oups av500 sorry mon anglais is too bad [09:40:17] <av500> mon francais aussi [09:40:27] <osmancorp> :) [09:40:41] <merbzt> anyone have the mpeg2 video specs ? [09:40:51] <av500> google? [09:40:52] <kshishkov> av500: allemanes? [09:41:04] <av500> wie bitte? [09:41:27] <kshishkov> merbzt: ITU H.262 [09:41:29] <osmancorp> I have questions about the structures libavformat? [09:41:59] <av500> osmancorp: try asking [09:42:13] <kshishkov> av500: well, that should be common language for non-English and non-French speaker [09:42:58] <kshishkov> av500: also it's good for philosophy and "I have questions about the structures libavformat?" is clearly philosophical question [09:45:01] <osmancorp> FFstream in a structure we find several other kinds of structure: an array of AVStream structure that contains the information for each stream then we find that it contains AvFormatParameter indescribable and AvInputFormat and AvOutput format that contain information that I do not understand too [09:46:48] <osmancorp> during initialization ffserver we construct a linked list structure that will contain all FFsteram the media? [09:48:54] <osmancorp> well my question is basically what a feed in ffserver? is it just the feed that we define in the configuration file ffserver which allows to define a different format for the same media [09:49:31] <av500> lu_zero: ffserver?!? [09:50:49] <osmancorp> I think I made much progress in understanding Libava but it still seems very difficult because it requires an understanding of system programming, networks and especially understand the video (pts, dts, elementary packet stream) etc. .... [09:50:55] <osmancorp> yes FFserver [09:51:00] <av500> libava? [09:51:04] <osmancorp> yes [09:51:18] <osmancorp> libavformat , libavutil , libavcodec :) [09:51:55] <osmancorp> frankly the people who programmed these libs are really very strong :) :) [09:52:19] <av500> some are also very big [09:52:30] <osmancorp> lol :) [09:52:36] <osmancorp> i don't know :) [09:54:54] <osmancorp> I get a lot of things about these libs on the internet but unfortunately I did not find much and I am doing a detailed documentation on using these libs and I must say it is a pleasure but very restrictive [09:55:43] <kshishkov> The Real Programmer's principle - "it was hard to write, it should be hard to understand" [09:56:06] <osmancorp> here is the page of my documentation which currently is not very complete but it takes shape slowly: https: / / sites.google.com / site / lavideolinux / [09:56:12] <av500> osmancorp: the documentation is mostly in all these .c and .h files [09:57:34] <osmancorp> yes I know but it must be said that if ever all-I do not know about this wonderful irc:) [09:58:39] <av500> osmancorp: asking "explain libav* to me" wont get you far [09:58:48] <av500> try to rather ask specific questions [09:58:56] <Dark_Shikari> explain the universe to me [09:58:58] <Dark_Shikari> explain math to me [09:59:06] <Dark_Shikari> what's an integral. explain from first principles. [09:59:07] <av500> *and* this channel is about development of FFmpeg, not about using it [09:59:18] <av500> Dark_Shikari: it's a big "S" [09:59:26] <kshishkov> Dark_Shikari: those are demands, not questions :P [09:59:42] <av500> kshishkov: so: "I have a doubt, what is the universe" [09:59:53] <kshishkov> av500: that's a statement [10:00:07] <av500> kshishkov: so: "dear Sir, I have a doubt, what is the universe?" [10:00:27] <osmancorp> my project is to document the use of Libava it is true that the doc is already in the headers and sources, but for me it's still difficult to piece together the puzzle. [10:00:46] <kshishkov> av500: last part of it is a question, the rest is statement [10:01:03] <av500> Haarspalterei [10:01:51] <osmancorp> sorry I spammed your irc I understand that it is strictly reserved to the development of ffmpeg [10:02:16] <kshishkov> and discussions of trains or Sweden [10:02:26] <av500> as said, unless you ask *specific* questions, you will get little help [10:02:30] <pJok> kshishkov, anything swedish really [10:02:42] <av500> swedish sugar water [10:02:49] <pJok> rutebaka [10:03:20] <osmancorp> which is responsible for the developement of ffserver? [10:03:28] <kshishkov> av500: in Belgium it was hard to find even sugar water [10:03:34] <kshishkov> pJok: rutabaga [10:04:17] <pJok> close [10:04:18] <av500> osmancorp: svn blame ffserver.c [10:04:25] <av500> or git blame [10:04:54] <av500> ah, fabrice [10:06:03] * pJok hands kshishkov the semla [10:06:34] <osmancorp> ok thanks av500 [10:06:49] * kshishkov accepts it [10:31:56] <Kovensky> 06:59.06 Dark_Shikari: what's an integral. explain from first principles. <-- my calculus professor actually did a complete proof that different numbers differ by a set ammount and is using it to prove limits... somehow [10:33:23] * kshishkov would just throw Principia Mathematica at the person asking that [10:37:04] <Kovensky> also, http://wiki.puella-magi.net/Mathematics_of_Madoka_Magica [10:37:13] <Kovensky> middle school maths are serious business, apparently [10:37:30] * Kovensky didn't even know modular maths existed [10:37:33] <superdump> "different numbers differ by a set ammount" [10:37:35] <superdump> what? [10:37:50] <Dark_Shikari> wait you didn't know about modular math? [10:37:56] <Dark_Shikari> how did you think rsa worked, pixie dust? [10:37:56] <superdump> it makes me think of the sum of 1/n not being convergent thing [10:38:36] <Kovensky> superdump: a proof that "for every number a and b that such that a < b, there's a natural nonzero number t where a + t = b" [10:38:47] <Kovensky> Dark_Shikari: I never studied cryptography :X [10:38:48] <Dark_Shikari> that sounds more like limits [10:38:57] <Dark_Shikari> Kovensky: read wikipedia [10:39:00] <Dark_Shikari> and you'll already know more than sony [10:39:07] <Kovensky> heh [10:39:20] <divVerent> superdump: hehe, that 1/n one was actually nontrivial... [10:39:24] <superdump> the RSA stuff was one of the first things we learned at university (on a maths and physics course) [10:39:32] <divVerent> easy to intuitively see it, but harder to do it right [10:39:49] <superdump> mmm [10:39:50] <Kovensky> if I ask "what's RSA" to pretty much everyone, they'll just repeat the question at me [10:40:30] <Kovensky> s/everyone/anyone/ [10:40:34] <kshishkov> TLA [10:40:44] <Dark_Shikari> how about diffie-hellman, that's a simpler one [10:40:53] <divVerent> how is DH simpler than RSA :P [10:41:09] <Kovensky> the first time I heard about diffie-hellman was when I was reading on the HDCP crack lol [10:41:16] <kshishkov> divVerent: because it's basis [10:41:18] <Dark_Shikari> http://upload.wikimedia.org/wikipedia/en/c/c8/DiffieHellman.png [10:41:28] <Dark_Shikari> it's pretty freaking system. [10:41:30] <Dark_Shikari> *simple [10:41:30] <Dark_Shikari> blah [10:41:55] <divVerent> kshishkov: they both basically depend on the same [10:42:00] <divVerent> but sure [10:42:04] <Dark_Shikari> RSA is basically a superset of DH [10:42:10] <divVerent> just saying, if you get DH, you automatically get RSA too [10:42:17] <divVerent> but typically, RSA is taught first at uni [10:42:26] <divVerent> even though it does a bit more [10:42:53] <divVerent> who is this Alice anyway [10:42:55] <divVerent> ;) [10:42:59] * kshishkov had nothing like that [10:42:59] <Dark_Shikari> the person who talks to bob [10:43:14] <divVerent> hm... so we finally know the answer to "Alice? Who the .... is Alice?" [10:43:26] <Kovensky> "Evil Eve", isn't it supposed to be "Malone"? :) [10:43:32] <kierank> alice is a cake [10:43:34] <divVerent> wasn't that Mallory? [10:43:41] <Dark_Shikari> Alice is the Seven-Colored Puppeteer. [10:43:45] <Kovensky> or Mallory? derp [10:43:49] <kshishkov> kierank: and one German ISP mascot [10:44:03] <Dark_Shikari> http://en.touhouwiki.net/wiki/Alice_Margatroid [10:44:04] * Dark_Shikari ducks [10:44:06] <divVerent> and somehow got lost in some kind of wonderland [10:44:18] <Kovensky> http://en.wikipedia.org/wiki/Alice_and_Bob#List_of_characters [10:44:23] <divVerent> haha [10:44:27] <divVerent> EVERYTHING is on wikipedia [10:44:32] <divVerent> relevancy? ha! [10:44:36] <Flameeyes> divVerent: I'm not :P [10:44:47] <kierank> av500: aww dibona didn't respond to my troll [10:44:56] <divVerent> Flameeyes: let's fix that [10:45:06] <divVerent> Chuck... that guy must be qutie evil [10:45:12] <divVerent> is it Chuck Norris, the quantum computer bruteforcer? [10:45:38] <Kovensky> 07:44.33 divVerent: relevancy? ha! <-- >implying it's not relevant [10:45:56] <kshishkov> kierank: finish x262 and write xvp8 to shame both him and BBB [10:46:41] <divVerent> Kovensky: well... more like, implying that the normal wikipedia relevancy nazis should not consider that relevant [10:46:44] <divVerent> I just don't get it... [10:46:52] <kshishkov> Kovensky: the greatest drama in ru.wikipedia.org was around an article "Mayonaise Jar" [10:46:59] <divVerent> how come every character of every TV show is "relevant", but people who actually do something useful are not [10:47:41] <av500> divVerent: not in german wikipedia [10:47:42] <Kovensky> divVerent: that's... irrelevant ;) [10:48:02] <divVerent> av500: even in the german one :P [10:48:06] <Kovensky> also, the portuguese wikipedia really SUCKS :/ [10:48:16] <kshishkov> Kovensky: Portugal too [10:48:21] <Kovensky> it's one of the foreign wikipedias with the most articles but like 90% of them are 1 or 2 paragraph stubs [10:48:35] <av500> stubpedia [10:48:41] <Kovensky> the ones that aren't are partial or full translations of the equivalent in english wikipedia (with the same wording, constructs and whatnot, just directly translated) [10:49:16] <kshishkov> I heard the same applies to Polish wikipedia [10:49:24] <kierank> kshishkov: x262 kind of works now (no thanks to me i must add) [10:49:37] <kshishkov> except they mostly translated from German wikipedia [10:49:51] <av500> kierank: and x261? [10:50:01] <kshishkov> kierank: I believe you. Sounds like a situation with ffaacenc ;) [10:50:12] <av500> can't you make it x26y and y a command line switch? [10:50:21] <kierank> av500: x261 is x262 without interlaced [10:50:29] <av500> see [10:50:38] <Kovensky> kierank: that's arguably an improvement [10:50:53] <kshishkov> av500: and x263 can be rebranded as xvid2 [10:51:33] <av500> and vp8 can be H266 [10:52:02] <kshishkov> nope [10:52:19] <kshishkov> it's VP10 would be copied from H.266 [10:52:52] <kierank> kshishkov: it's better than ffaacenc [10:53:12] <kshishkov> kierank: how well it encodes sound then? [10:54:14] <Dark_Shikari> I love how compiling gcc can result in SINGLE COMPILE COMMANDS taking over 2 minutes [10:55:04] <kierank> kshishkov: https://github.com/kierank/x262/wiki/TODO [10:55:10] * kshishkov offers Dark_Shikari libavcodec/motion_est.c [10:55:32] <Dark_Shikari> nowhere near as bad [10:55:34] <Dark_Shikari> that takes, what, 2 seconds? [10:56:46] <kshishkov> not on my Gdium [11:00:32] <lu_zero> good morning... [11:02:57] <kshishkov> god morgon [11:03:16] <kshishkov> lu_zero: tried Efika MX Smartbook in field, seems to work fine and long [11:03:41] <cartman> lu_zero: ffmpeg does support rtmp right? [11:03:52] <kshishkov> lu_zero: say no [11:05:59] <iive> cartman: kind of. reading only, we have native support without encryption and librtmp for everything. [11:06:32] <av500> cartman: you moved? [11:06:58] <cartman> av500: yeah, looking for a flat atm. [11:07:13] <cartman> iive: just need to watch TV over rtmp, guess it'll work [11:07:38] <av500> cartman: pkk broadcasts in rtmp? [11:07:52] <cartman> av500: yeah [11:08:40] <kierank> haha [11:08:52] <cartman> it feels nice to be unmonitored :D [11:09:10] <kshishkov> so you think [11:09:19] <av500> monitored by other ppl [11:09:24] <cartman> not the Turkish keywords :D [11:09:46] <av500> pkk is well understood here too [11:09:51] <kshishkov> Turkish? in Germany? ridiculous! [11:10:04] <cartman> av500: yeah they live in Belgium too [11:10:07] <cartman> that should tell something [11:10:22] <av500> cartman: and why do you insist to pay cash for the flat, and only for 1 month? [11:10:43] <cartman> av500: 6 months [11:10:57] <kierank> saintd3v: what does [lagarith @ 0x1b72040] Unsupported Lagarith frame type: 0x3 mean? [11:10:59] <cartman> cash only because I am not registered yet :D [11:11:07] <av500> and why do you want to learn to drive, but not to stop? [11:11:13] <cartman> av500: lol [11:11:18] <kierank> rofl [11:11:40] <cartman> the guy at the border paused for a minute [11:11:40] <kshishkov> kierank: it means that our decoder does not support frame type 3 [11:11:42] <cartman> bastards [11:11:50] <kierank> kshishkov: wtf is frame type 3 [11:12:12] <av500> 1= intra, 2 = extra, 3 = ultra [11:12:48] <kierank> ah FRAME_ARITH_YUY2 [11:12:49] <cartman> av500: do they have HTC repair around here? For Nexus1. [11:13:12] <kierank> BBB: get google to use more efficient shipping [11:13:15] <av500> cartman: yes, HTC phones are built by former cuckoo clock makers in back forest.... [11:13:22] <kierank> they sent a massive box for one small t-shirt [11:13:30] <kshishkov> av500: well, VC-1 has I-frames, two types of P-frames and B-frames [11:14:03] <kshishkov> av500: proof or they are made in Offenbach! [11:14:23] <av500> offfenbach makes the leather pouch only [11:14:55] <av500> cartman: tbh, no idea, why not ask htc? [11:15:12] <cartman> av500: I meant unofficial ones that you may have used for your N1 [11:15:41] <av500> I did not break mine yet [11:16:52] <av500> and if I did, I would just my BFF for another one [11:17:40] <av500> just ask [11:17:56] <kshishkov> TI makes phones now? [11:19:36] <av500> that is not my BFF [11:21:27] <kierank> av500: i am your bff, right? [11:21:54] <kshishkov> kierank: if you buy him new phone [11:22:09] <kierank> I have a samsung gt-e1080i [11:22:14] <kierank> do you want it av500? [11:22:42] <av500> no, i want a gt-e1080p [11:23:08] <kshishkov> but it doesn't play blurays! [11:23:47] * av500 makes sure never to be seen with kierank while he uses that phone [11:24:10] <kierank> I had to buy it in order to get free delivery on a purchase [11:24:18] <kshishkov> av500: http://codecs.multimedia.cx/wp-content/uploads/2011/02/av500.jpg [11:24:30] <kierank> it was the most useless phone i've ever used [11:24:31] <av500> on the receipt it was labeled "stuffing material"? [11:24:45] <kierank> I thought at least it had wap [11:24:48] <kierank> but how wrong was I [11:25:09] <spaam> kshishkov: is that 15" laptop in his hand? [11:25:26] <av500> the 15" is behind it [11:25:37] <av500> thats the 22" desktop replacement [11:27:02] * lu_zero is back again [11:27:16] <lu_zero> av500: btw we got a new kernel release with some improvements [11:27:22] <lu_zero> kshishkov: nice to know =) [11:28:14] <av500> lu_zero: you missed a chance to explain ffserver [11:28:33] <thresh> whats the use of wap anyway [11:28:41] <av500> thresh: waste money [11:28:58] <thresh> no, well, my company actually gets money for that [11:29:09] <thresh> s/my company/the company I work for/ [11:29:11] <av500> thresh: waste costumer money [11:40:57] <lu_zero> 12:27 <+av500> lu_zero: you missed a chance to explain ffserver [11:41:06] <lu_zero> something _not_ that nice [11:41:11] <lu_zero> that's the explanation [11:41:14] <av500> :) [11:45:21] <lu_zero> btw [11:45:34] <lu_zero> mpegts+rtp+free.fr [11:46:49] <kierank> ? [11:49:05] <kshishkov> kierank: that's for av500 [12:39:41] <thresh> http://twitter.com/#!/asolovyov/statuses/45783939197059073 [12:40:02] <thresh> kshishkov: and the other one for you, http://twitter.com/#!/asolovyov/statuses/45815636840038400 [12:44:01] <kshishkov> thresh: м-да, и ведь не поспоришь [14:18:58] <Dark_Shikari> checking for unsigned short... yes [14:18:59] <Dark_Shikari> checking size of unsigned short... 2 [14:19:01] <Dark_Shikari> die autotools die [14:19:44] <JEEB> o_O [14:20:22] <Tjoppen> well, that's marginally useful. less useful is checking for functions that'd cause compilation failure if they didn't exist - hence obvious [14:20:38] <kshishkov> checking for Fortran IV... not found [14:20:53] <kierank> doesn't autotools do sizeof(uint32_t) or similar [14:21:01] <kshishkov> Tjoppen: ever heard about #include <stdint.h>? [14:22:04] <Tjoppen> ever heard of platforms with non-8-bit multiple word sizes? [14:22:47] <Tjoppen> FATE needs a PDP-8 test server :) [14:23:45] <mru> kierank: I've seen that [14:23:54] <mru> although that one isn't a given [14:24:05] <mru> CHAR_BIT isn't necessarily 8 [14:24:18] <av500> 16 on some ti dsp [14:24:27] <mru> but I've seen configure scripts (claim to) check for uint32_t being 32 bits [14:24:58] <Tjoppen> also, C++ needs stdint.h [14:26:06] <lu_zero> mru: paranoid safety check for bogus headers? [14:26:40] <mru> have you ever seen it fail? [14:26:59] <mru> it only makes sense adding tests for things known to occasionally fail [14:27:05] <lu_zero> mru: sure [14:27:25] <lu_zero> note, on autotools you could just force C99 and have it drop those [14:28:13] <mru> 10 years ago it made sense to check for uint32_t *existing* [14:28:22] <mru> many systems didn't have it [14:28:30] <mru> and those that did, put it in different places [14:28:36] <lu_zero> mru: sure [14:28:48] <mru> but I've never seen it with the wrong size [14:28:56] <Tjoppen> why check at all? why not just let the compile fail? [14:29:56] <lu_zero> http://pastebin.com/AqCA6Qyh [14:30:08] <lu_zero> sample autotools more or less sane [14:30:13] <lu_zero> (thanks to Flameeyes) [14:30:54] <Flameeyes> feng.. that's the far side of sane though :P [14:32:48] <lu_zero> eh eh [14:38:16] <JDarnley> Dark_Shikari: did configure manage to complete? [14:38:24] <Dark_Shikari> yes [14:38:28] <Dark_Shikari> it just takes ages [14:38:40] <kierank> JDarnley: I was just thinking of a man who likes his autotools ;) [14:38:43] <Dark_Shikari> I'm trying to compile gcc 4.6 to do testing on because it's the first compiler since 3.4 that does constant folding properly [14:39:00] <Dark_Shikari> it only took them about 10 intermediate versions to go back to the old level of suckage [14:39:03] <JDarnley> kierank: ;) [14:39:05] <hyc> sad... [14:39:32] <hyc> autotools, definitely one of my least favorite things [14:39:40] <Dark_Shikari> http://pastebin.com/pEbAnGug every version of gcc between 4.0 and 4.5 inclusive will generic awful code for func1 [14:39:44] <Dark_Shikari> llvm does too [14:39:54] <Dark_Shikari> a redundant arithop *and* 9 bytes of wasted opcode [14:39:58] <hyc> at least I figured out hwo to short-circuit the unnecessary fortran and C++ checks on my projects [14:41:18] <mru> Dark_Shikari: isn't that reading uninitialised values? [14:41:32] <Dark_Shikari> yes, that's irrelevant [14:41:38] <Dark_Shikari> func2 is just for example to show how func1 is supposed to work [14:41:38] <mru> no it's not [14:41:43] <Dark_Shikari> func1 is the only thing that's actually compiled [14:41:49] <Dark_Shikari> func2 is an example calling function. [14:42:20] <Dark_Shikari> http://pastie.org/1654972 example [14:42:58] <hyc> that's an example of proper code, I take it [14:43:06] <mru> you'd like it to use signed 8-bit offets instead? [14:43:14] <Dark_Shikari> yes [14:43:19] <Dark_Shikari> that's an example of bad code [14:43:25] <Dark_Shikari> note an entirely redundant instruction and 9 bytes of wasted spaces [14:43:32] <Dark_Shikari> if you remove the "lea", the code gets 12 bytes smaller total [14:43:40] <hyc> ah yes [14:43:41] <Dark_Shikari> this is because gcc's constant folding is broken [14:44:01] <Dark_Shikari> if you factor out the address expressions, there is absolutely no reason to extract the "-128" as an operation on *in [14:44:02] <hyc> that's pretty terrible [14:44:09] <mru> if you decide to put any such hacks in ffmpeg, please make them conditional on x86 or something [14:44:21] <Dark_Shikari> mru: I was going to make the offset amount different per-arch. [14:44:27] <Dark_Shikari> i.e. make it 4096 on ARM. [14:44:34] <mru> why? [14:44:41] <Dark_Shikari> To make larger offsets fit in the instruction space. [14:44:43] <mru> arm has 12 bits + sign bit [14:44:46] <Dark_Shikari> Yes. [14:44:55] <Dark_Shikari> however, -4095 to -1 is wasted. [14:44:59] <Dark_Shikari> Just as -128 to -1 is wasted on x86. [14:45:02] <mru> do you have structs larger than 4k? [14:45:07] <Dark_Shikari> h264 probably does [14:45:10] <Dark_Shikari> mpegenc probably does [14:45:17] <mru> then fix those instead [14:45:25] <Dark_Shikari> yes I agree on ARM it's much less useful [14:45:28] <mru> hacks like this is asking for bad code [14:45:33] <Dark_Shikari> I was able to shave off over 4% size off vp8dec on x86 [14:45:37] <Dark_Shikari> just by REORDERING THE STRUCT. [14:45:38] <mru> unless you are ver, very careful [14:45:45] <lu_zero> 15:39 <+hyc> at least I figured out hwo to short-circuit the unnecessary fortran and C++ checks on my projects [14:45:51] <lu_zero> that had been fixed since ages... [14:46:01] <Dark_Shikari> mru: technically, the C spec allows the compiler to do this itself [14:46:07] <Dark_Shikari> because it doesn't require that pointers be stored as integers [14:46:08] <mru> of course it does [14:46:12] <hyc> lu_zero: yeah, this was ages ago [14:46:15] <Dark_Shikari> i.e. pointer representation doesn't have to be equal to the integer cast of the pointer [14:46:19] <hyc> i sent them the patch [14:46:26] <Dark_Shikari> AND, different types can have different pointer representations. [14:46:35] <Dark_Shikari> therefore, it could do this just for structs of its choice. [14:46:48] <Dark_Shikari> i.e. store the pointer with a +128 offset. [14:46:58] <Dark_Shikari> and apply a -128 offset on all reads. [14:47:08] <Dark_Shikari> I imagine this would probably be a difficult optimization though. [14:47:15] <Dark_Shikari> here's how I did this in vp8.c: [14:47:16] <Dark_Shikari> #define ss ((VP8Context*)(((uint8_t*)s)-128)) [14:47:34] <hyc> yes, it's quite a pain actually in gcc. I did this on the m68k stuff ages ago [14:47:36] <Dark_Shikari> no I'm not planning to commit that part. [14:47:58] <hyc> +/-128 and +/-32768 [14:48:04] <Dark_Shikari> 32768? [14:48:08] * av500 renames jason to (((Dark_Shikari))) [14:48:11] <hyc> m68k has 16 bit offsets too [14:48:17] <Dark_Shikari> ah [14:48:25] <Dark_Shikari> wait, there was an m68k compiler that did this? [14:48:45] <mru> Dark_Shikari: I agree with what you're saying [14:48:50] <hyc> gcc 1.43, when I was a gcc maintainer [14:49:00] <Dark_Shikari> 1.43?!! [14:49:05] <Dark_Shikari> Did they drop that or something? [14:49:14] <hyc> yeah, they threw out a lot of stuff when they went to 2.0 [14:49:26] <mru> but since you've seen yourself that compilers fuck it up if you do the offset manually, I would prefer that you only did it for cases verified not to get worse [14:49:29] <hyc> but it was also used on MIPS [14:49:39] <Dark_Shikari> mru: no, it didn't fuck it up [14:49:42] <Dark_Shikari> it just reverted the optimization [14:49:50] <mru> and added an instruction [14:49:50] <Dark_Shikari> because it constant folded in the wrong direction [14:49:52] <Dark_Shikari> no [14:49:54] <Dark_Shikari> well, yes [14:50:00] <Dark_Shikari> but that instruction would be once per top-level function [14:50:14] <mru> and there's no telling what it will do in untested cases [14:50:16] <Dark_Shikari> But yeah it'd be better to ifdef it based on which compilers we know do the optimization right. [14:50:19] <mru> so just don't do it, ok [14:50:22] <Dark_Shikari> But yeah I probably won't [14:50:27] <Dark_Shikari> I can fit *most* of the vp8 working set in 128 bytes. [14:50:31] <Dark_Shikari> Not counting big things (dct blocks) [14:50:32] <mru> it's ok if you do it for tested cases [14:50:37] <mru> arch+compiler [14:50:58] <mru> reordering structs is another matter [14:51:01] <mru> that should be safe [14:56:43] <Dark_Shikari> fucking gmp [14:56:53] <Dark_Shikari> mpfr fails to configure because it can't find __gmpz_init [14:57:00] <Dark_Shikari> what exists: ___gmpz_init [14:57:04] <Dark_Shikari> aksdjf;laksjdflasjdflkjasd;lkfjas;ldkfja;sldkjfas;ldkj [14:57:42] <Dark_Shikari> screw this I'm going back to gcc 3.4 [14:57:45] <hyc> stupid naming conventions for the win [14:58:23] <mru> for the win32 [14:58:37] <Dark_Shikari> _______________________do_stuff() [14:59:20] <mru> guess how much fun I had building gcc 4.5.2 on irix [14:59:29] <Dark_Shikari> a lot. [14:59:35] <mru> something like that [14:59:49] <hyc> what compiler did you buld it with? [15:01:54] <hyc> i was having fun trying to build a Linux kernel for my phone the other day. was using gcc 4.3.1, had to update to 4.6 so it would produce a kernel small enough for the bootloader [15:02:47] <mru> iirc I managed to bootstrap it with mipspro [16:41:45] <irock> mru: I sent a patchset to the ffmpeg-devel ml. did it get stuck in the moderation queue? [16:42:33] <mru> "Diabolische Rhetorik: Intensiv Seminar am 03. Mai 2011 in K?ln" ? [16:42:40] <irock> no [16:42:53] <mru> then it's not there [16:43:02] <irock> ok. then it's my email relay [16:43:02] <Zor> now that's one interesting title [16:55:36] <xwang> hello anyone knows which function transfer the bits to int ? [16:55:57] <mru> can someone translate that into a question? [16:57:21] <xwang> like int channels = bits2int(CH_LAYOUT_STEREO); [16:57:41] <av500> I would guess the function is bits2int() [16:58:14] <xwang> is there a function called bits2int of ffmpeg ? [16:58:27] <mru> no, but there is one called av_popcount [16:59:48] * av500 fetches av_popcorn [17:04:27] <xwang> thanks:) [17:09:18] <BBB> mru: popcount is useless on x86 because you can't use popcnt b/c of portability :( [17:09:52] <mru> BBB: av_popcount() still exists [17:10:34] <mru> it does some bit twiddling and comes up with the correct answer [17:46:13] <mru> ruggles: ping [17:46:18] <ruggles> pong [17:46:37] <mru> I'm getting a lot of cycles spent in ff_ac3_bit_alloc_calc_bap [17:46:54] <mru> and that function can easily be made twice as fast on arm [17:47:12] <elenril> BBB! [17:48:03] <BBB> elenril: ping [17:48:05] <BBB> er [17:48:05] <BBB> pong [17:48:07] <BBB> thing [17:48:24] <elenril> url_setbufsize isn't committed yet [17:48:27] <elenril> and ff_get_v [17:48:29] <jb_holidays> 'moroning [17:48:30] <ruggles> mru: that's surprising. it would be great to optimize it though since it's used in the ac3 decoder as well. [17:48:34] <elenril> that's evil! [17:49:33] <mru> arm has a nifty instruction to shift and saturate in one cycle [17:49:56] <BBB> elenril: ff_get_v is a horrendous name [17:50:07] <BBB> elenril: I wouldn't dare touch it, it may break the kernel or something [17:50:07] <elenril> BBB: got a better idea? [17:50:18] <elenril> it's private anyway [17:50:47] <BBB> url_setbufsize was fine I believe, but depended on ff_get_v and you didn't want me to do evil to your patches by applying them out of order :-p [17:52:17] <BBB> shouldn't you introduce a seekable in URLContext also if you're going to do this? [17:52:23] <BBB> after all, right now it's not very informative [17:52:36] <elenril> later when i get to urlcontext stuff [17:52:46] <BBB> fair enough [17:52:53] <BBB> that patch looks really nice [17:53:00] <elenril> if a certain somebody ever gets to applying my patches [17:53:00] <BBB> can I apply it without depending on other patches? [17:53:12] <BBB> I got a day job for the next 7 days, still, you know? :-p [17:53:27] <elenril> day jobs are overrated [17:53:47] <BBB> says ur physics phd student [17:54:02] <elenril> not phd [17:54:09] <BBB> postdoc? [17:54:10] <elenril> only mgr [17:54:11] <BBB> faculty? [17:54:14] <BBB> what's a mgr [17:54:39] <BBB> you've got a master's degree but not yet pursuing a phd? [17:54:46] <BBB> or yet^d? [17:55:11] <elenril> mgr == magister [17:55:19] <elenril> == master in your weird terminology =p [17:55:58] <ruggles> mru: the function does do a lot of unneeded looping because of the band structure. maybe that could be simplified as well. [17:56:40] <ruggles> mru: half the bands are only 1 coeff wide [17:57:04] <elenril> anyways [17:57:15] <elenril> better ideas for ff_get_v name? [17:57:41] <elenril> if not, an ugly name is better stuffed away in a private header [17:57:42] <mru> leave it private for now [17:57:58] <elenril> mru: that's what my patch does [17:59:41] <lu_zero> elenril: get_vlc if you like [18:00:04] <mru> that name is already taken [18:00:24] <BBB> a better name, even for a private function, would be useful [18:00:42] <BBB> ffio_read_varlen() or so? [18:08:01] <elenril> sent [18:08:13] * elenril checks what's next [18:08:32] <elenril> url_ferror :/ [18:09:44] <BBB> that wasn't a definitive answer btw, just a suggestion [18:09:54] <BBB> url_ferror() needs work b/c it breaks image2 output [18:10:02] <BBB> just remove the url_Ferror() in utils.c maybe [18:10:09] <BBB> but check make fate and make sure it doesn't break [18:10:26] <elenril> make fate fails for me for unknown reasons [18:10:49] <mru> BBB: those failing url_ferror() should be removed [18:11:03] <mru> any error should already be returned by ->write_packet [18:12:25] <BBB> I agree [18:12:37] <BBB> elenril: fixing make fate is useful [18:12:37] <BBB> :) [18:12:50] <BBB> btw fate looks incredibly green right now [18:12:55] <BBB> we should break it [18:13:05] <BBB> also, most failures are either exotic archs or icc [18:13:12] <BBB> I wonder if we can bribe the icc guys into fixing their shit [18:13:16] <elenril> o_0 it doesn't fail now [18:13:21] <elenril> magic! [18:13:28] * BBB pours some stars over elenril [18:15:30] <elenril> meh, it thrashed my terminal [18:17:09] * elenril makes fate [18:22:19] <BBB> you mean killed further typing? [18:22:35] <BBB> macosx by any chance? it does that for me every time I use make -j8 or when it fails [18:22:51] <mru> you're hitting the same problem takis sent a patch for [18:23:17] <elenril> me? macos? how rude =p [19:31:10] <ruggles> BBB: it does that to my terminal too when one of the fate tests crashes [19:32:21] <ruggles> so if i'm only testing 1 codec i normally do a manual test first to make sure it won't crash, then run fate. [19:32:41] <mru> </dev/null should prevent it [19:32:48] <mru> but I'll apply takis' patch [19:38:26] <ruggles> so his patch will only allow using q on windows? [19:38:44] <mru> yes [19:38:49] <mru> ctrl-c works fine in unix [19:39:06] <ruggles> ah, i see [19:39:09] <mru> systems with tcsetattr() have sane signal handling [19:39:16] <mru> there's no need to do both [19:39:34] <mru> and it's more in line with typical unix behaviour [20:36:08] <mru> BBB: lol, "v" is an unambiguous thing... [20:44:38] <vcs> Hi, what can i do to signal to a player that the stream is over? I have tried returning AV_EOF as well as setting the AVStream.duration, but neither of those seem to get ffplay to stop playing at the end [20:45:01] <_av500_> it never ever stopped for me [20:45:02] <mru> if the stream is over, what does it play? [20:45:14] <_av500_> crickets [20:45:17] <vcs> nothing. shouldn't it quit :P [20:46:04] <ruggles> does -autoexit work? [20:46:43] <vcs> yes that does actualy, i was assuming i was doing something wrong when it looks like its ffplay that handles when to stop :P [20:46:44] <vcs> thanks [20:47:55] <ruggles> if the output sample format is SAMPLE_FMT_DBL and the decoder supports FLT or S32, which should be chosen? [20:50:16] <ruggles> if range is +/- 1.0 so S32 is better, right? [20:57:24] <BBB> vcs: ffplay allows seeking back at EOF, so that's why it doesn't quit [20:58:22] <BBB> ruggles: S32 is probably better than FLT, depends a little on the type of content... DBL<->FLT requires no value scaling [20:58:24] <BBB> if that matters [21:00:11] <ruggles> well, it's a hypothetical situation currently so I'm going with S32 [21:06:01] <mru> S32 has more dynamic range than FLT [21:06:20] <mru> 32 bits vs 23 or whatever float has [21:06:58] <mru> people using double probably don't care about a little extra overhead [21:07:14] <mru> after all, their speaker cables had a 1e1000% markup [21:10:09] <iive> i think that the exponent of the float gives it much better dynamic range... [21:10:50] <mru> I meant precision [21:11:03] <mru> must be something wrong with that coffee I bought yesterday [21:12:18] <mru> however, the dynrange of s32 should be plenty [21:36:52] <irock> mru: could you check again if my mails got into moderation? subject is something like "support for 10-bit h264 decoding" [21:37:58] <mru> nothing in the queue [21:38:11] <mru> what address are you sending from? [21:38:14] <mru> I can check the logs [21:38:16] <irock> oskar(a)irock.se [21:39:35] <mru> nothing from you all day [21:40:21] <irock> thanks. I guess I'll have to resend the patchset then [21:40:50] <jermy> I like the sound of it. Another step closer towards AVC Intra decode [22:35:00] <irock> mru: I resent the patchset. could you please check again? [22:35:17] <mru> now I see it [22:35:23] <irock> :) [22:39:28] <Dark_Shikari> You're fucking awesome you know that. [22:39:33] <Dark_Shikari> Does this allow 8, 9, and 10 in the same build? [22:39:41] <irock> yes [22:40:53] <Dark_Shikari> god damn fucking awesome. [22:41:01] <Dark_Shikari> how does it output, does it output to 16-bit pixels? [22:41:08] <Dark_Shikari> or will we need to add a 10-bit pixfmt? [22:41:19] <irock> it's in the patches [22:41:28] <Dark_Shikari> .... awesome. [22:41:29] <irock> 9- and 10-bit pixel formats [22:41:33] <Shu> \o maybe the 10-bit x264 will actually be used [22:41:44] <Shu> and sorry for being late on asm :/ [22:41:56] <Dark_Shikari> No problem! [22:42:00] <Dark_Shikari> Once it's in, writing asm will be easy [22:42:03] <irock> Shu: Jumpyshoes? [22:42:07] <Shu> yup [22:42:20] <Shu> my pubkey is on the other computer which is currently off [22:42:24] * Sean_McG returns [22:42:30] <irock> ok [22:42:54] <Shu> er, i guess private key [22:46:51] <andoma> irock: nice work [22:46:57] <irock> thanks [22:48:07] <Sean_McG> your name matches your skill ;) [22:49:47] <irock> well, it wasn't too hard given the xp from last summers gsoc [22:50:57] <Jumpyshoes> silly age limits [22:51:35] <mru> Jumpyshoes: when you get older you'll like them [22:52:09] <Jumpyshoes> that might be true, but i don't like them now [22:52:20] <mru> simple solution: get older [22:52:43] <Jumpyshoes> that takes time [22:52:57] <mru> patience is a virtue [22:55:16] <Jumpyshoes> which i lack [22:55:38] <ohsix> yet comes with time [22:56:34] <Sean_McG> mru: what's the story with Justin's ac3enc patches now? is he doing another revision? [22:56:45] <mru> ruggles: ^^ [22:58:57] <BBB> irock: nice patchset [22:59:12] <BBB> irock: quite ugly in some parts, but not bad, as the dutch would say (that's a compliment :) ) [23:00:08] <irock> BBB: thanks. I noticed that gmail changed the from address to an address I don't use though [23:00:51] <irock> but I guess I could receive on the mails directly on the ml [23:01:32] <BBB> astrange: ping for mpeg-mt :-p [23:08:47] <BBB> ruggles: stupid question, but why (dnet) don't we write a bitstream reader that reads 16-bits a a time in a swapped fashion? [23:08:53] <BBB> then you don't need the memcpy [23:09:01] <BBB> shouldn't be difficult [23:09:27] <Sean_McG> using like bswap() or whatnot? [23:10:23] <mru> like the one we have for 32-bit [23:10:35] <BBB> perhaps... might be ugly and would probably need to be templated to not lead to a significant slowdown [23:10:42] <BBB> but just a different idea [23:12:26] <ruggles> BBB: well, currently the bitstream reader is chosen at compile-time, right? [23:13:44] <mru> yes [23:14:44] <ruggles> so either that would have to change or we would have to create a separate AVCodec and template the decoder. [23:14:59] <BBB> no need for separate AVCodec [23:15:10] <BBB> just choose which function to call depending on a boolean [23:15:16] <BBB> but yes you need to template the decoder [23:15:29] <BBB> oh man baby keeps crying [23:16:29] <ruggles> what do you mean by "which function"? the different bitstream readers use the same functions. [23:16:54] <BBB> you'd template ac3_decode_frame() [23:17:02] <BBB> frame_ac3 and frame_dnet [23:17:18] <BBB> and have ac3_decode_frame() call the relevant one depending on endianness of header in first call [23:17:48] <ruggles> ?? but all of the decoder uses get_bits() not just ac3_decode_frame() [23:18:05] <BBB> right, but each function is nested in ac3_decode_frame [23:18:15] <BBB> so from that point on it's like having two decoders [23:18:20] <BBB> but with one single AVCodec [23:18:31] <BBB> I think we're hinking the same thing but I say it wrong, or so [23:19:36] * mru tries to figure out how a script he wrote works [23:19:45] <Sean_McG> lol [23:21:41] <CIA-36> ffmpeg: Benjamin Larsson <benjamin(a)southpole.se> master * raecd0a4496 ffmpeg/libavcodec/ (avcodec.h mpeg12.c): [23:21:41] <CIA-36> ffmpeg: Export profiles from the mpeg2 video decoder [23:21:41] <CIA-36> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [23:24:16] <ruggles> BBB: too complex. ac3_decode_frame() uses the ac3 parser as well, which also uses the bitstream reader. [23:25:31] <ruggles> so the ac3 header parsing would have to be split out from the ac3 parser and templated as well [23:26:15] <ruggles> lots of mess to slightly speed up... realaudio? [23:26:23] <BBB> yeah good point [23:26:27] <Sean_McG> heheheh [23:26:29] <BBB> it was just a thought :) [23:26:32] <BBB> bad thought apparently [23:26:35] <ruggles> :) [23:26:42] <mru> BBB: that's why the baby cried [23:26:48] <BBB> he sleeps now [23:26:50] <BBB> I see a sign [23:26:56] <BBB> hum [23:27:10] <BBB> well you guys are the audio gods so do what you feel is right :) [23:31:19] * mru watches fate roar into action [23:34:14] <mru> I still have lots of spare capacity btw [23:36:19] * Sean_McG is waiting for SPARC to finish FATE, then will power it down and power up PPC Mac [23:37:10] <astrange> BBB: i merged into the mt repository, it's moving forward [23:37:46] <merbanan> I demand a backwards reading bitstream reader [23:37:54] <merbanan> to speed up atrac3 [23:38:12] <Sean_McG> people have atrac3 content?! [23:38:26] <merbanan> sure the ps3 can encode it [23:38:29] <Sean_McG> I have MiniDiscs, but my MD deck is not NetMD [23:38:44] <merbanan> Sean_McG: we have a decoder for that now [23:38:57] <merbanan> and it is possible to get the bitstream with consumer hardware [23:39:19] <Sean_McG> the only output I have is headphones, not even S/PDIF (only input) [23:39:40] <Sean_McG> it's a Sony MZ-R50 [23:40:01] <Sean_McG> haven't used it in years now though [23:41:13] <BBB> merbanan: uh, you could write it yourself :-p [23:41:20] <merbanan> no [23:41:23] <merbanan> I demand [23:41:39] <merbanan> please save my dog also [23:41:52] <Sean_McG> hahahah [23:42:23] <BBB> I wonder if merbanan looks like sheldon from the big bang theory [23:43:26] <merbanan> I'll send you a nudie later [23:43:35] <Sean_McG> x_X; [23:43:45] <BBB> you can send it to my other email addy if the file is too big for my gmail addy [23:43:55] <BBB> you know which one I'm talking about [23:45:18] <merbanan> hot_spanking_fudge(a)live.com, yeah I have that address [23:46:16] <Jumpyshoes> that's a good email address [23:46:24] <kierank> nearly as good as Compn's [23:46:38] <Jumpyshoes> what is Compn's? [23:47:34] <BBB> merbanan: don't forget the +nudie at the end, so it autofilters correctly [23:48:08] <kierank> Jumpyshoes: patriotact(a)gmail.com [23:48:17] <Jumpyshoes> lol [23:55:39] <mru> ruggles: I wrote an asm version of ff_ac3_bit_alloc_calc_bap and it did get faster [23:56:09] <mru> some 5% overall [23:57:02] <ruggles> mru: great. did you pass-in the band size table? or something else? [23:57:18] <mru> exactly as the C version [23:57:58] <ruggles> ah. how do you use a global table in asm? i've never tried. [23:58:11] <mru> just reference it by name [23:58:42] <kierank> bit allocation was the slowest part of dolby e iirc [23:59:38] * Sean_McG downloads A/52:2010 PDF [23:59:50] <kierank> there's a 2010 edition? [23:59:53] <Sean_McG> yeah [23:59:56] <Sean_McG> atsc.org

1 0

IRC log for 2011-03-09
by irc＠mansr.com 10 Mar '11

10 Mar '11

[00:00:19] <Compn> i heard people get dumber after being hired at google [00:00:25] <Compn> its probably the good food and atmosphere [00:01:31] <skal> ahm [00:02:07] <iive> BBB: are you going to move to another city? [00:02:10] <Dark_Shikari> everything about on2 staff can be summed up by "after nearly a year, plus 5-10 years of prior development, it's still 50% slower than ffvp8, which has less than a man-month invested in it." [00:02:35] <Compn> skal probably knows :D [00:02:57] <gnafu> Dark_Shikari: I'd say you play that up too much, but I can't. You have every right to be proud about that and gloat :-D. [00:03:01] <Compn> Dark_Shikari : thats not fair, the code ffvp8 uses has many man months invested in it [00:03:17] <Compn> e.g. all the h264 and idct whatnot code [00:03:17] <Dark_Shikari> you mean like... the h264 pred code copied from the spec? [00:03:22] <Dark_Shikari> idct is new to ffvp8 [00:03:27] <Dark_Shikari> the h264 pred is trivial and takes 1 hour to write [00:03:31] <Dark_Shikari> and half of it needed to be changed [00:03:36] <Dark_Shikari> and for emulated edge, like most was rewritten [00:03:49] <Compn> thats the only h264 shared code ? [00:03:58] <Dark_Shikari> yes [00:04:46] <Dark_Shikari> there's a bit of code imported from vp5/6, but that was mostly rewritten [00:04:51] <Dark_Shikari> for speed optimizations [00:05:08] <Compn> ah i thought it reused a lot more code [00:05:24] <Compn> since the commit was < thousand lines [00:05:30] <Compn> er < few thousand [00:05:46] <Dark_Shikari> the asm was another few thousand [00:05:56] <Dark_Shikari> but yes, it's a pretty small decoder. [00:08:32] <Sean_McG> hey folks [00:09:05] <gnafu> Sean_McG: Howdy! [00:09:11] <Sean_McG> :) [00:10:42] <BBB> Compn: vp8 isn't as elaborate as h264, you could compare it to h264 baseline in complexity. that's nice because it's much easier to write a full vp8 decoder, whereas our h264 decoder is massive and still doesn't implement everything [00:11:15] <mru> vp8 could be a bit less bizarre in place though [00:11:17] <BBB> it shares a little here and there, things like edge emulation, it will share edge extension when I implement it, h264 prediction, a few other minor things, but by and large it's new code [00:11:19] <mru> *places [00:11:29] <BBB> oh absolutely, some things are a little funky [00:11:52] <mru> saturating in strange places, unusual rounding, etc [00:12:07] <BBB> the edge default values for prediction are a little weird [00:12:39] <BBB> "slices" (what was that called again?) is implemented in a funny way that isn't as easy to implement as h264 or vc1 slices [00:12:46] <BBB> partitions, I believe [00:13:26] <BBB> because partitions can depend on each other and aren't contiguous, but rather interleaved on a line-by-line basis [00:13:47] <mru> what's the point in that? [00:13:55] <BBB> you could use it for threading [00:14:05] <BBB> but because they depend on each other it'll be much more complex than h264 slice threading [00:14:05] <mru> you said they depend on each other [00:14:08] <BBB> right [00:14:17] <BBB> so you need pthread_cond_() stuff [00:14:24] <mru> that's not all [00:14:38] <mru> slices are typically used for some error resilience as well [00:14:47] <mru> a damaged block doesn't ruin the entire picture [00:14:56] <BBB> good point [00:14:59] <BBB> I hadn't thought of that [00:15:14] <mru> that's why they were invented in the first place [00:49:34] * lu_zero wonders how intepolation/enhancement layers could work [00:51:07] <lu_zero> (as in pick just the even pixels instead of doing slices) [01:36:15] <mru> fate is compiling on haiku [01:39:47] <saintdev> mru: would have been better if you had made a haiku out of it [01:47:53] <mru> testing [02:03:09] <saintdev> whoa! gentoo bugzilla has a new color theme [02:18:26] <lu_zero> saintdev: bugzie4 [02:18:38] * lu_zero is __really__ thinking about it [02:18:54] * lu_zero recently update 3.6 on lscube and it went _really_ smooth =P [02:19:59] <saintdev> it looks, gasp, modern! [02:54:06] <siretart> moroning [03:46:39] <Sean_McG> o_O; [04:31:59] <xxthink> I have ever downloaded a ffmpeg version: ffmpeg-r22950 [04:32:14] * Sean_McG claps [04:32:17] <xxthink> How can I find the corresponding git version now? [04:36:20] <pengvado> git log --grep='Originally committed as revision 22950' [04:39:20] <xxthink> pengvado, Great!!! [08:44:58] <Tjoppen> morrn [08:45:05] <kshishkov> god morgon [08:45:46] <thresh> moroning, fellow ffmpeg developers [08:46:16] <kshishkov> moronings are for VLC, här har vi bara goda morgnar [08:46:34] <thresh> har har something something reminds me of Jar Jar Binks [08:47:03] * kshishkov has a special codec for that [09:18:12] <pross-au> Bink Bink [09:21:43] <kshishkov> indeed [09:33:13] * KotH blinks [09:33:36] <kshishkov> KotH KotH Blinks is our new hero? [09:33:59] <pross-au> thats a cool name for a codec [09:34:16] <pross-au> But we dont have five CCs, only four [09:34:45] <kshishkov> BLNK then [09:35:25] <saintdev> why do we need the 'L', just abbreviate it BINK....oh, erm wait.. [09:38:07] <kshishkov> saintdev: finish ffaacenc soon, ffbinkaudioenc awaits! [09:38:48] <saintdev> not touching that with a 39.5' pole [09:39:00] <kshishkov> which one? [09:39:46] <saintd3v> the latter [09:39:57] <kshishkov> there are two of them [09:40:04] <kshishkov> RDFT and FFT-based [09:41:35] <saintd3v> yeah, still not dealing with a bink audio encoder.. [09:42:25] <kshishkov> saintdev: AAC then? [09:44:54] <pross-au> Urgh [09:44:59] <saintd3v> guess it'll have to be.. [09:45:11] <pross-au> Waiting for 'Bink Mk II' [09:45:11] <saintd3v> :p [09:45:31] <kshishkov> pross-au: we had it supported long before Bink Mk I aka Bink-b [09:46:44] <saintd3v> ghost might be interesting, once monty gets to work on it. [09:46:55] <kshishkov> and aoyumi [09:48:27] <saintd3v> you think he'll help out with ghost like he did vorbis? [09:48:43] <kshishkov> I think otherwise it would be futile [09:48:53] <Tjoppen> isn't celt close to being frozen? [09:48:57] <KotH> kshishkov: aoyume? [09:49:02] <Tjoppen> -> ffceltdec [09:49:40] <pross-au> its frozen [09:49:42] <saintd3v> KotH: AoTuV Vorbis [09:50:51] <KotH> ok, then it's aoyume :) [09:52:17] <kshishkov> KotH: that should demonstrate again how far I am from psychoacoustics [09:52:40] <KotH> kshishkov: it only demonstrates that you are far from japan :) [09:52:58] <kshishkov> KotH: well, http://www.geocities.jp/aoyoume/aotuv/ says "(c)2003-2011 蒼弓／AOYUMI" [09:54:26] <KotH> hmm.. ok... [09:54:35] * KotH should read the whole page... not just the url [10:37:49] <kierank> _av500_: http://news.ycombinator.com/item?id=2301439 [10:40:35] <av500> you troll my BFF [10:40:40] <av500> outrageous! [10:41:31] <kshishkov> av500: no, he didn't troll TI [10:41:56] <av500> bah [10:42:28] <kierank> av500: not a troll [10:42:31] <kierank> a statement of fact [10:44:00] <kierank> av500: wow your post of http://parliamentfights.wordpress.com/ is brilliant [10:44:36] <av500> thats why so many ppl upvoted it [10:58:16] <CIA-36> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * rfb61a7c534 ffmpeg/libavformat/id3v2.c: [10:58:16] <CIA-36> ffmpeg: id3v2: fix typo in error message [10:58:16] <CIA-36> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [12:14:26] <mru> all hail kostylev, we have win64 on fate again [12:14:48] <BBB> wbs: I thought you had push access? [12:14:56] <BBB> mru: indeed, I noticed yesterday night, I'm so happy [12:15:08] <BBB> finally I will know again when I break win64 [12:15:16] <BBB> I still miss ramiro though [12:15:46] <mru> well, apparently he _likes_ being oppressed [12:16:23] <spaam> Nice.. no red stuff :D [12:17:32] <spaam> nice segfault on icc / ia64. [12:17:49] <wbs> BBB: no, I don't [12:38:11] <lu_zero> meanwhile I'm finishing prepping up minw32 cross autobuilds [12:44:29] <spaam> lu_zero: Nice.. for ming64 also? [12:45:55] <lu_zero> spaam: never tried mingw64 [12:46:48] <lu_zero> cross compiling for windows something that does not have autotools or proper build system is quite problematic [12:47:52] <lu_zero> (ffmpeg is good, autotools are usually good, cmake does not, many homebrew not as well) [12:48:23] <lu_zero> brb [12:57:41] * mru curses haiku a little [12:58:40] <kshishkov> too small OS? [13:08:27] <mru> hah, cursing helped [13:09:36] <kshishkov> because it's toy oS [13:09:53] <kshishkov> people constantly curse in Russia but nothing improves there [13:10:17] <mru> well, hopefully fate/haiku should be self-running now [13:11:34] <kshishkov> any other OSes to consider? [13:11:43] <kshishkov> like plan9 [13:12:14] <kshishkov> or RISC OS [13:12:25] <mru> plan9 is too fucked up [13:12:32] <mru> it can't talk to anything but plan9 [13:12:44] <spaam> but plan9 works [13:12:48] <spaam> cool name.. [13:12:53] <mru> and it doesn't have a C compiler [13:13:13] <kshishkov> depends on C value [13:13:25] <mru> they removed the #if directive [13:14:18] <av500> and #else? [13:14:29] <mru> they have #ifdef, not #if [13:14:52] <kshishkov> well, they say "greatly simplified preprocessor" [13:14:54] <av500> #if considered harmful? [13:15:17] <mru> and they have obsession with ugly guis [13:15:21] <mru> +an [13:15:27] <Zor> many people believe that the #if preprocessor directive is the root of all the evil pp forests [13:15:31] <kshishkov> av500: too lazy to compute conditions in preprocessor I suspect [13:15:42] <mru> no, they consider it unnecessary [13:15:47] <mru> and therefore it must go [13:15:48] <kshishkov> Zor: no, it's #define [13:16:06] <Zor> kshishkov: #define is not bad if you can only #ifdef [13:16:10] <Zor> in that mindset anyway [13:16:12] <mru> it's not hard at all to write bad code without #if [13:16:15] <mru> witness java [13:17:24] <kshishkov> mru: it's easy to write bad code in any language [13:17:34] <mru> exactly [13:17:49] <mru> so removing features in an attempt to make it harder is misguided [13:19:50] <kshishkov> BCPL? [13:21:05] * av500 forces kshishkov to write bink encoder in CICS [13:22:09] <kshishkov> av500: after xvp8 [13:34:12] <kierank> silly fruit company [13:34:14] <kierank> not fixing its bugs [13:38:35] <kshishkov> do they acknowledge them at all? [13:39:09] <mru> kshishkov: they are infallible [13:39:17] <mru> they are the very definition of perfection [13:40:14] <kshishkov> indeed! [13:40:31] <av500> you are just holding it wrong [13:40:32] * kshishkov still doesn't go to buy their products [13:46:08] <mru> mmu_man: is there an ntp client for haiku? [13:49:42] <mmu_man> mru: don't think so [13:50:01] <mru> what kind of a joke os is this? [13:50:17] <kshishkov> mru: joke os [13:50:47] <mmu_man> http://ports.haiku-files.org/wiki/net-misc/ntp [13:51:05] <mmu_man> you can send a patch [13:51:16] * kshishkov thinks Haiku is intended for pleasing all three of its developers by the fact it exists, nothing else [13:53:30] * mmu_man thinks kshishkov should just send patches instead of complaining [13:53:45] <mru> mmu_man: not complaining, mocking [13:53:50] <mru> there's a difference [13:54:00] <mru> diff -u haiku linux | sendmail mmu_man [13:55:20] <kshishkov> mmu_man: why should I complain? I don't use it and not sure if I've ever touched it [13:56:31] <mmu_man> mru: you'll be over quota [13:57:08] <kshishkov> yes, send shell script for replacing Haiku with stage3 instead [14:13:30] <mru> ruggles: ping [15:21:44] <Ayad123> i need begin to configure the ffmpeg, i need have the best option or synthaxe to convert and optimize a best quality of my video avi to swf or flv [15:22:46] <av500> -> #ffmpeg [15:30:57] <lu_zero> could be interesting having haiku using pkgcore or portage [15:31:34] <mru> shouldn't be too hard to put gentoo prefix on it [15:31:41] <lu_zero> mru: sure [15:31:54] <kshishkov> just replace it completely with Gentoo [15:31:57] <lu_zero> but they could use pkgcore and leverage what we provide [15:32:23] * lu_zero usually offer that to every os starting to think about package management [15:32:32] <lu_zero> sad minix preferred pkgsrc [15:32:42] <mru> they'd be better off porting the gui and filesystem to linux [15:32:48] <lu_zero> and haiku decided to make a workalike [15:32:58] <lu_zero> mru: I prefer having variety [15:33:26] <lu_zero> linux can be wrong, freebsd can be wrong, having both wrong at the same time is less likely ^^; [15:33:50] <mru> the only variety you get with these fringe OSes is different levels of non-support for mainstream modern hardware [15:34:12] <mru> they lack the manpower to write drivers for every device that comes out [15:34:37] <mru> better to put it on top of a kernel that does all that for you and focus on what makes it different [15:35:52] <kshishkov> lu_zero: minix is sad indeed [15:36:04] <mru> minix can't do that for obvious reaons [15:36:17] <mru> having a different kernel being the entire point of their existence [15:36:54] <kshishkov> well, that's the point [15:37:02] <kshishkov> every OS should have some goal [15:37:24] <kshishkov> for Minix it's to demonstrate The Holiest Microkernel Architecture [15:37:24] <ubitux> i don't know if roundup maintainers have been noticed by it, but i was unable to register with a message telling maintainers will get noticed [15:37:31] <ubitux> can anyone confirm it? [15:37:45] <kshishkov> for Haiku - to provide more shiny and useless OS than MacOS X [15:37:48] <mru> a minix-like architecture might be good for building highly reliable systems [15:38:04] <mru> for 99% of cases performance is more imporant though [15:38:44] <mru> engineering is all about making tradeoffs [15:38:50] * av500 wishes he could reboot the linux usb subsystem only [15:39:09] <mru> all these fringe systems tend to take at least one of these tradeoffs to the very extreme in one direction or other [15:39:19] <mru> av500: modprobe -r usb? [15:39:36] <mru> av500: don't do it with a usb keyboard [15:40:17] <mru> in a modular linux kernel, many subsystems can be restarted like this [15:40:47] <av500> modules in "strange" states often refuse to unload [15:40:52] <mru> if any core data structures have been corrupted you're stuffed of course [15:40:59] <mru> av500: modprobe -rf [15:41:12] <mru> the -rf flag works with many commands... [15:41:28] <av500> mru: I know all that [15:41:38] <av500> still I had cases where it did nothing [15:41:47] <mru> yes, I've had those too [15:42:05] <mru> and sometimes the hardware itself gets into a nasty state and needs a power cycle to reset properly [15:42:15] <av500> so it would be nice to be able to tell linux: forget that subsystem and make a new one :) [15:43:18] <kshishkov> mru: I believe Minix would encourage Windows approach to drivers, i.e. "crash at your heart desire" [15:43:56] <av500> kshishkov: sadly the other option fails as well [15:44:04] <av500> "this driver is bugfree" [15:44:06] <av500> lol [15:44:25] <kshishkov> but it's more appealing to me [16:15:49] <BBB> astrange: ping [16:19:16] <spaam> http://who-t.blogspot.com/2011/03/how-to-dos-developer.html [16:19:28] <mru> old [16:19:55] <spaam> mru: good [17:25:10] <ruggles> mru: pong [17:26:25] <mru> ruggles: I'm optimising ac3 for arm [17:26:33] <mru> and I'm seeing simd potential everywhere [17:27:15] <ruggles> yes, there is a lot of potential. [17:27:46] <ruggles> i would certainly be interested in where you see it though [17:28:24] <mru> well, the float scale_coefficients() would be an obvious one [17:28:37] <mru> neon has an instruction for that [17:28:50] <ruggles> yeah, i have that written already [17:28:54] <mru> cool [17:29:06] <ruggles> just need to submit it. it's kinda ugly due to the float param, but it works [17:29:14] <mru> float params? [17:29:22] <ruggles> the scalar [17:29:27] <mru> scalar? [17:29:33] <mru> I see a 24 [17:30:02] <mru> that needs to be a constant for neon [17:30:03] <ruggles> oh, i wanted to make it more generic. [17:30:11] <ruggles> for use with format conversion as well [17:30:18] <mru> the float to fixed takes only an immediate for the fractional bits [17:31:33] <ruggles> maybe a generic float scale factor is not needed then. [17:31:50] <mru> not if you want twice the speed [17:33:09] <ruggles> i don't think x86 has that though. we would have to scale the float to the proper range first. [17:33:31] <ruggles> but still the function could take an int [17:33:33] <mru> if you don't have that instruction you obviously have to do it the hard way [17:34:50] <mru> got any more unsent patches? [17:35:09] <mru> and don't bother doing neon stuff, I'm paid to do that [17:35:24] <ruggles> no other asm [17:36:24] <mru> that loop we were talking about yesterday could be simded I think [17:36:49] <ruggles> yeah, i tried once and it was slower, but i was thinking about trying again [17:36:59] <mru> and apply_rematrixing() [17:37:06] <ruggles> yeah, i tried that too [17:37:23] <ruggles> 1) none of the bands are on a 16-byte boundary [17:37:30] <BBB> mru: why don't you mentor a soc project? [17:37:46] <mru> BBB: I get 10x more money doing it myself [17:38:04] <ruggles> 2) the first 3 bands are only 12 coefficients wide [17:38:05] <BBB> you get a person doing it for you, and you can earn money doing something else in the mean time [17:38:27] <mru> I'll probably be mentoring for beagleboard again [17:38:30] <ruggles> but doing the whole thing in asm might be better. [17:38:50] <mru> apply_rematrixing should be easy to do in pure asm [17:40:21] <ruggles> i'm trying to focus on getting my feature patches done right now, but i'm keeping a list of where i think asm optimization will help. [17:52:04] * iive mark [18:06:00] <jb_holidays> hello [18:06:18] <jb_holidays> av500: kshishkov: at CeBIT, people have asked for Bink support :D [18:06:57] <mru> jb_holidays: you didn't recognise av500 in his disguise? [18:08:28] <jb_holidays> I didn't ! [18:09:34] <ruggles> mru: what other good optimization opportunities do you see for ac3enc? [18:09:45] <mru> I see loops everywhere [18:09:59] <mru> need to figure out which ones are taking time [18:11:28] <mru> now in ac3_exponent_min(), what are the rules for nb_coefs? [18:14:12] <ruggles> i'll double-check. it was multiple of 16, but then i changed something in the loop so it doesn't have to be. but i forget what the exact behavior is. [18:14:40] <ruggles> unfortunately, that will have to change anyway for channel coupling [18:14:57] <mru> what will have to change? [18:15:48] <ruggles> my current patch always calls it with nb_coefs=256 for simplicity, but i might have to just special-case the coupling channel. [18:16:12] <ruggles> because it doesn't start on 16-byte boundary [18:16:32] <mru> non-aligned is easy enough to handle [18:16:44] <mru> not multiple of 16 is worse [18:18:38] <ruggles> well, it only operates on multiples of 8 or 16. and rounds up due to how it is implemented. [18:18:48] <ruggles> that probably needs to be documented [18:18:49] <jb_holidays> michaelni: ping [18:20:44] <mru> ruggles: there's a bug somewhere [18:20:53] <michaelni> pong [18:20:55] <mru> it's not giving the same result as the C version [18:21:07] <michaelni> jb_holidays, pong [18:21:24] <ruggles> really? it passes regression testing. [18:21:49] <mru> maybe that's just luck [18:22:41] <ruggles> and the result would not decode if it didn't work properly. [18:24:43] <mru> well, I'm seeing nb_coefs=223 here [18:24:53] <ruggles> yes, that's correct [18:25:01] <mru> that's not a multiple of 16 [18:26:14] <ruggles> right [18:26:58] <mru> so the simd functions write more than they should [18:27:01] <mru> and the output differs [18:27:33] <ruggles> it's ok for it to write more than it should [18:27:47] <mru> the encoded output differs [18:28:12] <mru> so either md5 is wrong or you're wrong [18:28:14] <ruggles> ah, that would be the exponent grouping. [18:28:39] <ruggles> i can fix that. the extra exponents are not decoded, but they are encoded. [18:29:41] <ruggles> exponents are encoded in groups of 3, 6, or 12 so sometimes more are encoded than are actually used [18:32:56] <mru> so how do we fix it? [18:33:13] <ruggles> several ways... [18:33:53] <ruggles> 1) require multiple of 16 for nb_coefs [18:34:31] <ruggles> 2) handle it in group_exponents() [18:34:48] <ruggles> 3) handle it in encode_exponents_blk_ch() [18:35:26] <mru> 4) require the simd functions to handle a non-multiple of 16 [18:42:52] <ruggles> 5) pass nb_coefs+3 [18:47:28] <spaam> ??? [18:47:35] <spaam> PPROFIT [18:49:18] <ruggles> mru: i can't reproduce the differing md5 even with a big file... which x86 version of the function are you using? [18:54:54] <ruggles> maybe it's just luck. it's probably a rare case. [18:59:54] <ruggles> mru: could you check if passing nb_coefs+3 fixes your sample? [19:05:39] <mru> ruggles: all the x86 functions give the same differing output here [19:06:32] <ruggles> what about nb_coefs+3? [19:07:44] <jermy> ugh. I'm not having as much fun as I'd hoped with the smoothstream decoder. [19:08:23] <kshishkov> try RealMedia [19:08:55] <BBB> astrange: ping [19:09:18] <kshishkov> BBB: use ping-mt [19:09:27] <BBB> might have race conditions [19:09:39] <jermy> I've got a parser for the metadat files, but having a demuxer in the same style as applehttp is doomed since the chunks don't decode properly [19:09:46] <lu_zero> jermy: smoothstream -> ms-segmented-asf? [19:10:03] <lu_zero> jermy: use the protocol approach [19:10:09] <jermy> nah. Segments of mp4 [19:10:09] <mru> ruggles: different again [19:10:16] <lu_zero> of mp4? [19:10:16] <mru> why would +3 fix anything? [19:11:03] <lu_zero> segments of mp4.... [19:11:08] <jermy> and the audio is seperate, so it probably needs a demuxer to sync, no? [19:11:17] <lu_zero> so you must use the demuxer approach [19:11:18] <ruggles> mru: because it would ensure that at least that many exponents are processed. and none after that will be used. [19:11:43] <jermy> yeah. little packets with a moof header and a mdat [19:12:06] <mru> well, the c and simd versions still differ [19:12:47] <jermy> I'm just wondering at what point do I copy some bits of the mov demuxer and create my own codec context [19:13:46] <ruggles> mru: the encoded output differs even with nb_coefs+3? [19:13:51] <mru> yes [19:14:33] <ruggles> ah. i just thought of another thing... [19:14:40] <ruggles> an issue i came across during channel coupling [19:15:08] <ruggles> exponent strategy decision does sum of all 256 exponents [19:15:55] <ruggles> so rare cases it could be putting it above or below the threshold [19:17:11] <mru> and I just had to choose a sample where it did [19:18:03] <ruggles> part of my coupling patch changes the exponent strategy decision to work for any number of coefficients. [19:18:34] <ruggles> but that should be fixed ASAP [19:33:22] <vcs> where can i find documentation on the int64 timestamp used in *_read_seek functions? Is it some predefined format? [19:34:45] * mru attempts to complete the census form [19:35:03] <kierank> not meant to do it yet mru [19:35:17] <mru> only opened it now [19:35:31] <kierank> do it online [19:35:37] <kierank> you're meant to do it on the 12th iirc [19:35:42] <mru> 27th [19:35:46] <mru> but most of it won't change [19:35:58] <kshishkov> name - mru, nationality - troll, occupation - see above [19:36:16] <mru> it's not like my age or place of birth will change before the end of the month [19:39:50] <kierank> still should sent it electronically, way more efficient [19:39:56] <mru> of course [19:40:37] <mru> the website doesn't require all at once [19:40:52] * kierank has been waiting on the oyster card helpline for 30 mins now [19:41:52] <kshishkov> kierank: isn't British service known to be relaxed? [19:42:07] <kierank> dunno [19:43:12] <ruggles> kierank: how is dolby e decoding coming along? [19:43:43] <kshishkov> it's for gsoc 2011 [19:48:02] <BBB> vcs: what do you mean? [19:48:13] <BBB> vcs: it's a time units as set in AVStream->time_base [19:48:47] <BBB> vcs: so if time_base is num=1,den=1000000, then it's in microseconds, if time_base is num=1,den=44100, then it's an audio sample counter, etc. [19:49:20] <BBB> vcs: and so on for whatever is your favourite way to handle timestamps, it's supposed to maintain timestamp accuracy regardless of source timebase [19:49:30] * mru sets timebase to 1 aeon [19:49:36] <vcs> ahh so its dependant on that [19:50:24] <kierank> lol BBB too many people editing the wiki [19:53:37] * kierank wonders what happens if you send the census paperwork as well as filling it out online [19:54:24] <mru> they compare them, and if different come and take you away [19:55:33] * kierank won't mind being shipped to australia [19:56:22] <kshishkov> shackled? [19:56:35] <mru> kierank: http://www.youtube.com/watch?v=hnzHtm1jhL4 [20:02:22] <mru> ruggles: I'm getting 4% cycles in memcpy [20:02:27] <mru> I find that disturbing [20:03:48] <ruggles> mru: what about deinterleave_input_samples()? [20:04:16] <mru> I think I need to turn off some inlining to get sensible numbers [20:05:16] <ruggles> the others can probably be addressed with some restructuring, but that memcpy() is necessary [20:06:02] <mru> I guess [20:06:27] <mru> unless running on a dsp with modulo addressing [20:06:31] <mru> neat stuff, that [20:09:16] <ruggles> mru: one of the things on my list to try is having a reference block for exp and bap rather than copying them. [20:15:29] <mru> ffs, I can't make this damn thing not inline everythign [20:19:34] <mru> what is it with gcc and function names? apply_window.clone.4.clone.14 [20:27:09] <mru> that one can be simded [20:28:36] <BBB> kierank: not seeing it (?) [20:28:54] <kierank> works now [20:29:10] <kierank> for a while the database had an error [21:13:16] <kierank> mru: http://users.softlab.ece.ntua.gr/~ttsiod/cpp.html [21:13:19] <kierank> </troll> [21:14:33] <mru> aaaauuuuggh, WHY do some people prefix all struct names with 'tag'? [21:14:37] <mmu_man> http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_Of_Code_2011 [21:14:43] <mmu_man> "This Account Has Been Suspended" [21:14:48] <mmu_man> !? [21:15:02] <gnafu> kierank: "to say something in less words, means that you are wise about it" [21:15:04] <mmu_man> mru: cause M$ said so [21:15:07] <gnafu> That's a lesson I need to learn :-P. [21:15:22] <BBB> mru: because it's short and awesome [21:15:54] <mru> I've even seen it _mandated_ by corporate coding standards [21:16:06] <superdump> perhaps that happened because mike started mirroring the samples archive [21:16:12] <gnafu> mmu_man: Ooh, looks like someone's been hitting the samples mirror a bit too hard. [21:16:18] <mru> here's the funny part, I ignore said coding standards and nobody noticed [21:16:20] <superdump> and someone found it objectionable / it used too much bandwidth [21:16:46] <gnafu> Does anyone know what hosting provider he uses? [21:17:02] <mru> a crappy one [21:17:06] <mru> by the looks of it [21:17:53] <BBB> I emailed mike [21:17:55] <BBB> he'll fix it [21:18:55] <gnafu> BBB: Give it to Mike(y). He'll [fix] anything! [21:20:16] <mru> kierank: some ideas in c++ are good, templates perhaps being one of them if used in moderation [21:20:27] <mru> but the syntax is disgustingly ugly [21:20:52] <mru> and typical c++ coders tend to write more code than average c programmers to solve the same problem [21:21:21] <mru> I guess I dislike how it is used at least as much as the language itself [21:23:49] <Flameeyes> mru: I actually like C# better than C++ :| [21:24:04] <mru> never used it so I can't say [21:24:07] <Dark_Shikari> A<B>> [21:24:55] <Flameeyes> mru: it has most of the concepts of C++, but reduced syntax complexity, and a saner standard library [21:25:26] <elenril> and it's inherently evil by virtue of its creator =p [21:25:42] <mru> microsoft have done a few good things [21:26:25] <DonDiego> greetz from tel aviv [21:26:34] <Flameeyes> hi DonDiego [21:26:39] <Dark_Shikari> C# is actually rather less awful than java [21:26:48] <DonDiego> and don't ask me about anything ffmpeg-related, my email is bust :) [21:27:13] <elenril> less awful than java << that carries no information [21:27:25] <Flameeyes> elenril: C++ is more awful than java [21:27:37] <elenril> is it? [21:27:38] <mru> depends [21:27:42] <elenril> you can use it like C [21:27:49] <elenril> then it's certainly less awful than java [21:27:49] <mru> in c++ you're not forced to do all that crap [21:27:53] <mru> people just do it anyway [21:28:04] <Flameeyes> elenril: C++ used as stroustrup and company wants it to be done is much more awful than java [21:28:11] <mru> oh, for sure [21:29:28] <Dark_Shikari> BBB: ugh [21:29:29] <Dark_Shikari> in vp8.c [21:29:30] <Dark_Shikari> if (!nnz4) break; [21:29:35] <Dark_Shikari> we're only breaking out of the inner loop. [21:29:37] <Dark_Shikari> oooops. [21:29:44] <Dark_Shikari> I want a break statement that breaks out of two loops. [21:30:10] <elenril> goto! [21:30:12] <Flameeyes> Dark_Shikari: that's called goto [21:30:15] <Dark_Shikari> I know [21:30:23] <Dark_Shikari> But then I have to start making labels [21:30:24] <Dark_Shikari> end1 [21:30:26] <Dark_Shikari> end2 [21:30:27] <Dark_Shikari> end3 [21:30:31] <Dark_Shikari> because labels aren't scoped. [21:30:50] <Flameeyes> after_$action [21:30:55] <Flameeyes> or done_$action [21:31:08] <Dark_Shikari> after_for [21:31:10] <Dark_Shikari> after_for1 [21:31:12] <Dark_Shikari> after_for [21:31:14] <Dark_Shikari> *after_for2 [21:31:20] <Flameeyes> the for is doing something isn't it? [21:31:22] <Dark_Shikari> true [21:31:54] <Flameeyes> done_parsing, done_checking, found_maximum ... [21:40:12] <Dark_Shikari> another problem [21:40:14] <Dark_Shikari> libavcodec/vp8.c:1293: error: label at end of compound statement [21:40:19] <Dark_Shikari> you can't put a label at the end of a {} block [21:41:43] <mru> put a ; after [21:42:06] <Dark_Shikari> chroma_idct_end: ; makes me want to stab myself [21:42:17] <mru> then stab yourself and write it [21:43:32] <Flameeyes> I usually add it _after_ the {} block [21:43:57] <Dark_Shikari> the structure is: [21:43:58] <mru> that doesn't work if the block is a loop [21:44:21] <Dark_Shikari> for0 { if1 { if2 { for3 { for4{ stuff } } } } } [21:44:28] <Dark_Shikari> we need to break out of "stuff" and go to the next iteration of "for0" [21:44:28] <mru> if you have triple-nested loops and want to break from the innermost and continue the outer, that's the sane way [21:44:49] <Flameeyes> mru: right sorry I didn't consider that [22:20:22] <kierank> http://www.cnx-software.com/2011/03/09/video-wall-with-beagleboards-and-ffm… [22:24:24] <roxfan> oh i saw that one at fosdem [22:24:49] <Compn> i think mru owns one of those [22:25:17] <mru> av500 owns the displays of the mark 1 aka "the beast" [22:25:24] <kierank> mru is mentioned in the video [22:28:05] <Shu> the age limit on GSoC is still bugging me ;-; [22:28:28] <mru> paying minors is always a hassle [22:28:40] <Shu> by the time i get paid it's okay [22:28:41] <kierank> Shu: did you get your t-shirt [22:28:42] <Shu> just not at the start [22:28:46] <Shu> i did lol [22:28:52] <kierank> got mine today in a massive box [22:29:00] <mru> or should I say minors are such a hassle... [22:29:13] <Shu> kierank: mine was XXL <_< [22:29:19] <Shu> kierank: forgot to say what size [22:29:19] <kierank> mine was too small [22:29:31] <kierank> should have chosen medium [22:29:39] <Shu> did you get small? [22:29:46] <kierank> yup [22:30:09] * kierank thought it was going to be american small [22:30:12] <Shu> i shoulda gotten small [22:30:40] <kierank> Shu: you could come up with an "arrangement" with someone for gsoc [22:30:43] <mru> kierank: I made the same mistake with gsoc last year [22:30:45] <kierank> if you catch my drift [22:31:06] <Shu> i do have a job this summer [22:35:08] <Shu> oh, one of the projects is optimzing h264. [22:54:43] <kierank> I wonder if kshishkov will be interested in reverse engineering Harmonic RTP [23:03:06] <Flameeyes> Harmonic RTP? [23:03:33] <kierank> yes they seem to have made their own proprietary implementation [23:04:02] <Flameeyes> used where? [23:04:13] <kierank> in harmonic products [23:05:04] <kierank> and also i need to write/find a way of making ffmpeg just open a udp port and accept udp/rtp data [23:05:07] * Flameeyes doesn't know harmonic [23:05:24] <kierank> big broadcast company [23:05:43] <mru> from what little I've seen, they seem as annoying as any other such company [23:07:23] <Flameeyes> kierank: uhm based off where? /me really never heard of it and wikipedia doesn't help [23:07:32] <kierank> USA [23:07:51] <Flameeyes> that explains it [23:08:39] <kierank> there seems to be a dll with the protocol in it [23:08:44] <kierank> and some documentation of the api [23:21:12] * lu_zero is pondering to write a small subset of rtp/rtsp in javascript... [23:21:19] * lu_zero should go back to sleep [23:28:09] <Sean_McG> o_O; [23:30:06] <lu_zero> Sean_McG: consider it an inside joke [23:30:11] <Sean_McG> will do [23:30:14] <Sean_McG> ;) [23:30:30] <lu_zero> even if it's feasible and shouldn't be _that_ bad [23:31:11] <lu_zero> (given you hardcode mkv headers)

1 0

IRC log for 2011-03-08
by irc＠mansr.com 09 Mar '11

09 Mar '11

[11:03:09] * Terminating due to: TERM [11:05:41] * /join #ffmpeg-devel ... [11:05:45] *** TOPIC: Welcome to the FFmpeg development channel. | Discussions about the development of FFmpeg itself are ontopic here. | Questions about using FFmpeg or developing with the libav* libraries should be asked in #ffmpeg. | Channel is logged. [11:05:45] *** TOPICINFO: merbzt!~benjamin(a)m83-186-120-172.cust.tele2.se, 1295456661 [11:08:33] * Terminating due to: TERM [11:10:53] * /join #ffmpeg-devel ... [11:10:57] *** TOPIC: Welcome to the FFmpeg development channel. | Discussions about the development of FFmpeg itself are ontopic here. | Questions about using FFmpeg or developing with the libav* libraries should be asked in #ffmpeg. | Channel is logged. [11:10:57] *** TOPICINFO: merbzt!~benjamin(a)m83-186-120-172.cust.tele2.se, 1295456661 [11:31:21] <kshishkov> _av500_: have you sued them for infringement? http://moviebarcode.tumblr.com/ [12:19:32] <Tjoppen> oops, accidentally send ML replies directly to BBB instead of the list :) [12:21:10] <kshishkov> that's what you get with those 'To: author\nCC: list' mails [12:21:26] <mru> why did people start doing that suddenly? [12:24:18] <Tjoppen> it only seems to happen with people using gmail [13:02:01] <BBB> Tjoppen: sorry, seems gmail decided to make reply-to-all really reply-to-all on MLs, it didn't use to do that [13:02:06] <BBB> anyway [13:02:12] <Tjoppen> I see [13:02:14] <BBB> elenril: make fate-lavf-bmp fails because of your second patch [13:02:23] <BBB> Tjoppen: so all my mails get sent twice now [13:02:36] <BBB> maybe this is their way of decreasing the amount of spam in statistics [13:02:44] <BBB> after all, twice as much non-spam mail \o/ [13:03:13] <Tjoppen> lol [13:03:39] <BBB> saintd3v: I'm gonna ask a really stupid question [13:04:03] <BBB> saintd3v: does it make sense, and is it at all practically useful, to share psymodels between different audio encoders, e.g. ac3 and aac? [13:05:28] <kshishkov> BBB: nope, they have different ways to allocate bits [13:05:33] <BBB> Tjoppen: thanks for re-sending patches, I'll look at it [13:05:42] <mru> hmm, go to SF apr 5-13 or not... [13:07:01] <Tjoppen> hm, any good reason why vf_overlay.c:259 checks for RGB output when the filter only ever reports supporting YUV420P output in query_formats()? [13:07:03] <BBB> mru: go :) [13:07:07] <BBB> mru: I may be there that week [13:07:46] <kshishkov> mru: who's paying for the flight? [13:08:06] <mru> kshishkov: I probably have to pay that myself [13:08:22] <kshishkov> mru: then the answer is close to "no" [13:08:36] <mru> why? [13:08:45] <mru> flight isn't that expensive [13:08:52] <kshishkov> if you're not going to receive something extra nice there why go? [13:09:33] <mru> visit the local ffdevs and others [13:09:39] <mru> view the scenery [13:09:45] <mru> all the usual reasons to go places [13:09:53] <kshishkov> well, if you haven't seen it then go [13:10:01] <BBB> there's like 4 ffdevs there that week [13:10:11] <BBB> alex, mike, david and me (possibly) [13:10:14] * kshishkov wants to cut Falukorv with morakniv in Orsa or Borlange [13:10:19] <BBB> then there's baptiste and jason a little south [13:10:27] <BBB> and possibly others [13:10:32] <mru> kshishkov: orsa is probably the most boring place in all of europe [13:10:34] <BBB> astrange: ping re: mpeg* -mt patches :-p [13:10:49] <mru> borlänge is known mostly for its high crime rates [13:10:52] <kshishkov> mru: try Ukraine then [13:11:14] <mru> nobody goes to borlänge voluntarily [13:12:00] * kshishkov has visited Skärholmen and Rinkeby so far, sees no reason not to visit Borlänge [13:12:16] <mru> you do seek out the worst places... [13:12:28] <mru> nobody visits those two places either [13:12:51] <kshishkov> I've covered the other regions of Stockholm [13:13:36] <mru> hell, why hesitate... I'll just go [13:14:55] <iive> pay kshishkov's ticked and he will come with you. [13:15:31] <iive> ticket. [13:15:47] <mru> ok, done [13:18:20] <kshishkov> iive: to USA? I'm third-world country citizen [13:18:44] <iive> forth. [13:19:10] <iive> i forgot... [13:20:35] <iive> I thought that you are already EU citizen. [13:20:49] <kshishkov> nope, it's not fast [13:21:04] <kshishkov> especially since I don't consider marriage [13:21:05] <mru> iive: he has a slave labour visa [13:21:33] <kshishkov> mru: in Ukraine we use term "gastarbeiter" [13:22:19] <iive> i've heard that word too. I've always thought it is german. [13:22:28] <mru> it is [13:23:01] <kshishkov> there are quite a few German words in Ukrainian language [13:23:34] <pJok> in soviet ukraine, german words you? [13:24:09] <kshishkov> pJok: IIRC that's called "jive" [13:25:22] <kshishkov> pJok: also guess where Yakov Smirnoff was born [13:39:46] <pJok> kshishkov, same place as Alexander Kalashnikoff? [13:40:46] <kshishkov> pJok: who's that? [13:43:57] <iive> kshishkov: I though he invented the vodka. [13:46:13] <kshishkov> iive: actually it's mostly Mendeleev who gets (wrongly) blamed for that [13:46:31] <iive> my bad. [13:47:14] <mru> I thought vodka was thought to be the fifth element in russua [13:47:17] <mru> russia [13:49:19] <kshishkov> yes, so nobody was sober enough to record when it was created [13:52:06] <kshishkov> but since Mendeleev wrote a thesis on spirits (including ethanol) and water compounds, he's credited for inventing Real Russian Vodka [14:35:28] <Tjoppen> the overlay filter drops frames randomly [14:36:33] <mru> probably the same old timestamp nonsense as usual [14:37:10] <Tjoppen> I'm trying to write a crossfade filter to evaluate whether lavfi is any good. I based it off of vf_overlay, which seems to drop frames even if both inputs are PAL [14:37:33] <mru> I told you it's nonsense [14:38:31] <Tjoppen> so I see. why do the filters take over the program flow actually? [14:39:06] <Tjoppen> it's fine for straight filters I guess, but for anything advanced it's just asking for trouble [14:42:12] <kshishkov> wasn't causing more trouble our goal (FFmpeg EE and such)? [14:42:57] <lu_zero> Tjoppen: remove the timestamp guessing code and see what's the result [14:43:43] <mru> simple hack method: remove entire contents of compute_pkt_fields() and tb_unreliable() [14:44:54] <kshishkov> why it's still in git.ffmpeg.org then? [14:46:43] <lu_zero> hyc: you around? [14:47:55] <kshishkov> lu_zero: you use wrong handshake [14:50:09] <lu_zero> kshishkov: meanwhile I noticed again an interesting shortcoming of libavfilter... [14:53:29] <lu_zero> if you try to transcode a file with multiple video stream [14:53:59] <lu_zero> the output will have the same resolution set... [14:54:12] <Tjoppen> I made compute_pkt_fields*() and tb_unreliable() return zero/do nothing [14:54:21] <Tjoppen> then I overlayed a DV onto itself [14:54:30] <lu_zero> Tjoppen: works or not? [14:54:33] <kshishkov> lu_zero: also it doesn't support resolution change. Or palette change. [14:54:41] <Tjoppen> using vsrc_movie. fun fact: the order of the inputs to the overlay filter matters [14:54:52] <lu_zero> Tjoppen: known issue [14:55:15] <Tjoppen> aah [14:56:45] <Tjoppen> shouldn't the overlay filter poll the inputs or something like that? or multi-input filters in general [14:57:39] <Tjoppen> this is the sort of thing I don't get with the current design - does it do proper flow control and how does it keep filters from starving? [15:02:17] <lu_zero> no idea =| [15:03:38] <Tjoppen> hence why I think filters shouldn't call eachother, but rather report whether they're starving and let some kind of "driver" call them [15:04:24] <Tjoppen> bonus: no need for vf_fifo [15:04:55] <lu_zero> Tjoppen: that would require a eventloop [15:05:05] <lu_zero> and possibly a separate thread [15:05:44] <Tjoppen> yes, of course. well, you wouldn't need extra threads [15:05:55] * lu_zero notices that is also a problem shared with the network layer... [15:06:13] <lu_zero> Tjoppen: eventloop migth do alone [15:06:22] <Tjoppen> but you'd have to inspect the graph to see which filters can work, and flush them until you can put frames on the input pads furthest back [15:07:11] <Tjoppen> yeah, the protocols share a similar problem. like http.c reading a writing in the same thread, which may cause trouble [15:07:24] <Tjoppen> or rather, doing so without poll() [15:07:40] <lu_zero> Tjoppen: or doing so overpolling =P [15:07:51] <lu_zero> or doing so overpolling AND blocking [15:08:35] <lu_zero> or doing so overpolling AND blocking AND causing desyncs ^^; [15:08:44] <Tjoppen> \o/ [15:10:30] <kshishkov> insert vf_monkey [15:10:50] <vladimir__> elenril: Regarding the issue with id3v2 frames, i've opened an issue #2650, and uploaded the sample file. [15:10:59] <_av500_> thx [15:11:06] <BBB> 2 vladimirs [15:21:48] <lu_zero> sigh [15:21:49] * BBB pokes astrange [15:22:07] * lu_zero isn't exactly fond of touching libavfilter... [15:22:16] <BBB> so ask saste to do it for you [15:22:28] <lu_zero> and/or figure out why it breaks... [15:22:53] <lu_zero> BBB: I asked to fix the scaling issue on the multiple outputs ... [15:25:31] <lu_zero> sigh [15:26:09] <lu_zero> we should really move to bugzilla... [15:35:28] <kshishkov> lu_zero: NAGzilla which really bugs devs till they fix issue [15:35:54] <lu_zero> kshishkov: a bugzilla plugin? [15:40:28] <kshishkov> I just made it up, feel free to develop it in any form you like [15:40:40] <kierank> irc bot [15:41:01] <ffnagbot> kshishkov: do vc-1 interlaced [15:41:18] * mru interlaces vc1 with bink [15:41:20] <kierank> forgot bbb and xvp8 [15:41:51] * lu_zero swscales xvp8 [15:43:43] <kshishkov> kierank: unfortunately for you proper ffnagbot nick is owned by mru [15:44:05] <kshishkov> mru: make a fine hash out of it (aka TS) [15:44:20] <kierank> [15:44] Notice from NickServ: ffnagbot is not registered. [15:44:46] <kierank> mru: watched the troll hunter yet? [15:44:51] <mru> yeah [15:44:54] <kshishkov> kierank: hint - look at nicks present here starting with "ff" and ending with 'bot' [15:45:11] <kierank> the bit right at the end was hillarious [16:18:11] <BBB> kshishkov: you could at the very least help make vc1 be spec-compliant for the implemented features [16:18:18] <BBB> kshishkov: you know the code better than me, it'll take me forever [16:27:33] <kshishkov> BBB: I'd help when I have time. But now I'm going afk till next morning (as usual) [16:27:48] * BBB waves [16:27:51] <kshishkov> BBB: it's just my life now - too little free time [16:30:53] <BBB> you sound like you're in business [16:30:59] <BBB> wasn't student life just so much better? [16:31:02] <BBB> always have too much free time [16:32:53] <gnafu> BBB: But wasn't that only because you procrastinated more? [16:32:59] <gnafu> That's what I did -_-. [16:37:34] <iive> BBB: are all I frames bitexact? [16:37:56] <BBB> iive: up to some stage they are [16:38:03] <BBB> iive: I'm working on it, give me some slack :) [16:38:17] <BBB> I'm trying to go one sample at a time [16:38:26] <BBB> this particular sample (no overlap filter), I/B are bitexact [16:38:28] <BBB> P frames are npot [16:39:31] <iive> i know how tedious making something bitexact is. you can have all the slack you want. [16:40:36] <Silverion> [16:41:47] <iive> are there P-frames that are bitexact. are all MB affected? [16:42:08] <Silverion> [16:43:31] <lu_zero> uhmm [16:43:36] <lu_zero> stranger and stranger [16:44:03] <lu_zero> libavfilter doesn't seem at fault [16:57:20] <BBB> ruggles: re: your avcodec_decode_audio4() patch, should the contents of InternalBuffer be made a union such that it takes less memory? [16:58:27] <ruggles> BBB: you mean audio params or video params? [16:58:32] <BBB> yes [16:58:44] <BBB> width/height versus samplerate/channels etc. [16:59:03] <BBB> might be a lot of work, not sure if it's worth it... but it would save a few bytes of allocated memory [16:59:53] <ruggles> i don't think it's worth the complexity. we don't do that for any other a/v structs do we? [17:07:36] <lu_zero> I'd postpone it [17:07:44] <lu_zero> add just a comment for the future [17:07:48] <lu_zero> meanwhile [17:07:59] * lu_zero stares at ffmpeg.c [17:16:33] <lu_zero> ugh [17:16:37] <lu_zero> wonderful... [17:16:59] <lu_zero> ffmpeg.c:3256-7 [17:17:10] <lu_zero> no wonder I get those... [17:34:46] <ruggles> lu_zero: you mean video_enc->width = frame_width; video_enc->height = frame_height; ? [17:36:50] <lu_zero> yup... [17:37:34] <lu_zero> it behaves in an unexpected way with more than a single stream per type [18:36:18] <kierank> merbanan: weren't you working on 10-bit dnxhd? [18:59:55] <ruggles> kierank: do you know if there is a way to use Pro Tools plug-ins without having Pro Tools? [19:00:39] <kierank> ruggles: i have no idea [19:02:02] <ruggles> ok. that ac3 encoder demo you pointed me to is a pro tools plug-in... [19:02:45] <kierank> really [19:02:58] <kierank> i thought you could also use the app standalone [19:03:06] <_av500_> ruggles: ask kshishkov to RE it [19:03:25] <kierank> dolby actually has a consistent api so i could tell you it right now [19:03:35] <kierank> _av500_ [19:04:07] <in3xes> Where is the soc repo? [19:04:28] <in3xes> All the links redirect to git.ffmpeg.org [19:04:44] <ruggles> _av500_: i don't need it RE'd. i just need to do some black-box comparisons. [19:05:21] <ruggles> kierank: System Requirements: Pro Tools HD/LE/M-Powered 7.0 and later [19:06:25] <kierank> this one right ? http://www.neyrinck.com/en/products/dolby-digital [19:07:15] <kierank> you can ask bcoudurier as well if you want [19:09:45] <BBB> ruggles: nice quality improvement there in your patches btw [19:10:16] <ruggles> BBB: thanks [19:47:37] <BBB> kshishkov: ping again [19:47:54] <mru> BBB: ja == jump if cf=0 && zf=0 [19:48:33] <BBB> I didn't know that sub set the carry flag for unsigneds [19:48:37] <BBB> if it does, that's fine [19:48:46] <BBB> I think kshishkov was drunk when he wrote the vc1 decoder [19:48:55] <BBB> we should buy him more wodka so he can get drunk again and fix it [19:49:11] <BBB> he inverted horizontal and vertical logic for the loopfilter and the edge checks [19:49:18] <roxfan> sub sets the same flags as cmp [19:49:44] <BBB> that is, for the v loop filter, the one basically between a top and a bottom block, he checks left/right, and for the h loop filter, the one filtering between a left and a right block, he checks top/bottom [19:49:54] <mru> "The OF, SF, ZF, AF, PF, and CF flags are set according to the result." [19:50:23] <roxfan> and it doesn't distinguish signed and unsigned numbers... that's why you have two sets of some j instructions [19:50:47] <roxfan> like ja and jg [19:52:35] <BBB> that's what I thought [19:52:42] <BBB> but ruggles says he tested it and it didn't crash or hang [19:52:47] <BBB> if he tested it and it worked, then it's fine [19:52:59] <BBB> I only care that it works [20:40:06] <saintdev> mru: "Is it impossible to align the thing it points to now?" <--Right now, it points to _nothing_, it's uninitalized. [20:40:30] <mru> yeah, I realised that [20:40:36] <mru> you said alignment first [20:40:54] <saintdev> that's what i thought it was before i was able to look into it more [20:41:45] <spaam> lu_zero: data suport patch? [20:42:13] <spaam> support [20:44:04] <saintdev> BBB: I don't know enough about other codecs to say yes/no. AAC and MP3 more than likely could, they're similar enough. [20:44:26] <lu_zero> spaam: sent on the ml weeks ago [20:44:33] <lu_zero> supports -dcodec copy [20:44:38] <saintdev> from what I understand of ac3 from ruggles, it probably could, but i'm not sure [20:46:36] <ruggles> saintdev: what was the question? [20:46:53] <saintdev> <BBB> saintd3v: does it make sense, and is it at all practically useful, to share psymodels between different audio encoders, e.g. ac3 and aac? [20:47:55] <ruggles> if the same model could work with different band structures, then yes [20:48:21] <saintdev> what about block switching? [20:49:32] <ruggles> possibly. if it is made generic enough. i.e. separate transient detection and window size decision [20:51:17] <ruggles> generic transient detection would be helpful regardless. e-ac-3 has a way for the encoder to essentially manually reduce transient pre-noise by specifying their location and a portion of the signal to copy over the pre-noise. [20:54:09] <ruggles> our current ac3 encoder doesn't seem to be very sensitive to pre-echo though, probably due to the way exponents are coded. but when you throw in channel coupling it does get worse. [20:54:11] <saintdev> hmm, so we may need to modify the API and separate those [20:58:37] * elenril sees no patches applied today [20:58:41] * elenril blames BBB [20:59:16] * _av500_ hums: "the BBB took my patches away..." [21:01:04] <kierank> "my the BBB cried...I'm taking your patches and flying away. Now elenril can't have his meta today..." [21:01:12] <kierank> bye bye [21:01:38] <elenril> i didn't work on any meta for at least a week =p [21:01:58] <kierank> don't ruin american pie [21:27:48] <spaam> RFC: if i trying to make a protocol for gz and bz2 files.. (-i gz:file)... should i have both in same file archive.c or sperate (gz.c and bz2.c) ? [21:28:28] <kierank> why are you doing that spaam [21:28:30] <_av500_> spaam: only for local files? or also -igz:http://... [21:29:25] <kierank> spaam: why not working on libavsequencer [21:29:26] <spaam> kierank: i need to code something other then my .py script.. [21:29:46] <spaam> _av500_: local files is the plan first [21:30:05] <wbs> spaam: if they can share some code, it's better to keep them in the same file, if not, it doesn't really matter much if you split them or not, perhaps rather split them then [21:30:18] <spaam> _av500_: maybe it wont be hard to fix -igz:http:// later. [21:30:37] <spaam> wbs: ok :) [21:30:49] <wbs> spaam: just make sure it uses an URLContext for reading the input, then it's easy to plug in whatever other urlprotocol there [21:31:40] <spaam> ok. thanks for the tip :) [21:39:27] * Flameeyes waits for libffrar [22:00:05] <saintdev> Flameeyes: wouldn't that be libavrar.. [22:00:38] <Flameeyes> saintdev: libavchive? [22:01:36] <saintdev> only on potatoes, tyvm [22:04:33] * saintdev holds out for libavace [22:04:35] <Flameeyes> guh? [22:27:48] <lu_zero> yawn [22:28:07] * lu_zero made a small stupid thing that should do something like [22:28:25] <lu_zero> while ((err = av_read_frame(ic, &pkt)) >= 0) { av_interleaved_write_frame(oc, &pkt); av_free_packet(&pkt); } [22:28:42] <lu_zero> I let the reader guess what happens [22:30:42] <mru> crashes or loops forever [22:31:35] <lu_zero> first is right [22:31:39] <lu_zero> guess why [22:31:50] <mru> humour me [22:34:01] <lu_zero> SIGFPE in av_frac_add, called by compute_pkt_fields2 ... [22:34:28] * lu_zero is checking that the time_bases are copied over and they are... [22:34:47] * lu_zero murmurs something about compute_pkt_fields2 trying to be smart [22:37:15] <lu_zero> and what's wonderful is that gdb is confused by it being inlined [22:42:10] * lu_zero sets a denominator to the st->pts and wonders why ist has 0/0... [22:46:34] <CIA-36> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * r66e5b1df36 ffmpeg/ (64 files in 2 dirs): [22:46:34] <CIA-36> ffmpeg: avio: deprecate url_feof [22:46:34] <CIA-36> ffmpeg: AVIOContext.eof_reached should be used directly instead. [22:46:34] <CIA-36> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [22:46:40] <CIA-36> ffmpeg: Nathan Caldwell <saintdev(a)gmail.com> master * r31ff9bd7b8 ffmpeg/libavcodec/ (aacenc.c aacenc.h): [22:46:40] <CIA-36> ffmpeg: aacenc: Fix a segfault in search_for_quantizers [22:46:40] <CIA-36> ffmpeg: This reverts the removal of scoefs from AACEncContext. [22:46:40] <CIA-36> ffmpeg: It resulted in scoefs being a NULL pointer when [22:46:40] <CIA-36> ffmpeg: search_for_quantizers() is called. [22:46:40] <CIA-36> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [22:48:00] <lu_zero> works =P [23:26:10] <mru> ruggles: ping [23:26:24] <ruggles> mru: pong [23:26:34] <mru> is there something wrong with your mul64 patch? [23:26:40] <mru> looks good to me [23:26:44] <ruggles> nothing wrong. just unnecessary. [23:26:53] <mru> using mul64 is good [23:27:05] <mru> gcc is too stupid to use the fast instructions on many cpus [23:27:15] <mru> like arm [23:27:53] <mru> gcc insists on doing it the hard way even though there's a single instruction that does it [23:28:32] <ruggles> the range of the coefficients is [-32768,32767] so the 32-bit multiply is fine [23:28:43] <mru> you're misunderstanding [23:28:56] <mru> arm has an instruction for 32x32->64 mult [23:29:00] <mru> gcc doesn't use it [23:29:40] <mru> actually, you should be using MAC64 there [23:29:46] <mru> arm has an instruction for that too [23:29:47] <ruggles> ah, i see. even though it converts to 64-bit to add to the sum. [23:30:32] <roxfan> mla is 32-bit if you don't need 64 [23:30:56] <mru> there's also smlalbb for 64 += 16x16->32 [23:32:10] <roxfan> hmm https://bugs.launchpad.net/gcc-linaro/+bug/643479 [23:34:18] * lu_zero messes up another bit with libaformat [23:35:08] <ruggles> yes, MAC64() seems to be the better thing to do [23:35:34] <mru> if those values are really 16-bit we should add a macro for that too [23:35:45] <mru> int64 += int16*int16 [23:40:14] <ruggles> i've gone over it several times, and i'm pretty sure they can't be outside 16-bit range. if they are, the encoder will be wrong. that's one of the added asserts that i recently sent a patch for. [23:42:43] <BBB> btw [23:42:43] <BBB> http://chromium.googlecode.com/issues/attachment?aid=-109601759276715865&na… [23:42:45] <BBB> auch [23:42:55] <BBB> our vp8 decoder beats libvpx with 2 threads [23:43:01] <BBB> that's quite awesome [23:43:10] <lu_zero> ^^; [23:43:12] <lu_zero> nice [23:43:20] <BBB> *almost beats [23:43:22] <BBB> anyway [23:43:26] <BBB> should implement that [23:43:29] <saintdev> lol [23:44:18] <gnafu> BBB: Very nice. [23:46:38] <gnafu> BBB: How long 'til you start at Google? The 28th? [23:46:55] * gnafu can hardly wait for an xvp8 release. [23:47:15] <BBB> I start the 28th [23:47:24] <lu_zero> Seems stream 0 codec frame rate differs from container frame rate: 29.98 (65535/2186) -> 29.97 (10000000/333667) [23:47:27] <lu_zero> wonderful [23:50:06] <iive> BBB: you are going to work at google? [23:52:51] <gnafu> iive: Yep. Workin' on xvp8 :-D. [23:55:23] <Compn> i'm confuse [23:55:39] <Compn> why google hiring you to fix up vp8 encoder when they have all on2 staff? :P [23:57:52] <BBB> I guess they're hoping that I can complement their staff in some way [23:59:48] <saintdev> complement, as-in: "That's so cute. Now go play outside while the adults work on xvp8."

1 0

IRC log for 2011-03-04
by irc＠mansr.com 05 Mar '11

05 Mar '11

[00:00:05] <BBB> although the samples look good to me already [00:00:06] <BBB> odd [00:00:34] <BBB> maybe kshishkov was just too lazy to confirm binary exactness or so [00:01:20] <Kovensky> 20:52.57 mru: aftermath is what remains after a disaster, such as a maths degree <-- lol [00:02:56] <j45> BBB: interlace? [00:03:12] <BBB> j45: perhaps... trying to go from small to big features [00:03:15] <BBB> interlace is massive [00:03:27] * j45 was afraid of that [00:03:47] <BBB> also, the original goal was to have a set of samples for testing binary compatibility of my optimizations [00:03:58] <BBB> not sure how I got to implementing vc1 missing features [00:04:05] <j45> all those bbc interlace vc1 discs cause support requests for us [00:11:34] <BBB> j45: us=? [00:11:42] <j45> handbrake [00:11:52] <BBB> oh I see [00:11:56] <BBB> put a bounty on it :) [00:12:10] <BBB> I'll see if I can look into it [00:12:12] <j45> with who's money :p [00:12:14] <BBB> interlace isn't easy :) [00:12:49] * kurosu nominates xvc1-interlaced as BBB's next project [00:12:58] <j45> hehe [00:13:10] <BBB> kurosu: I don't think anyone would pay for that *grin* [00:13:48] <kurosu> because people already have for xvp8 ? :p [00:13:55] <kurosu> oh wait [00:13:57] <kurosu> ;) [00:16:17] <gnafu> kurosu: I just... Wow. xvc1? [00:16:28] * gnafu cries inside. [00:16:45] <j45> s/cries/dies/ [00:16:57] <mru> lies [00:17:52] <BBB> gnafu: I thought it was rather funny :) [00:18:15] <BBB> brb [00:24:21] <gnafu> BBB: Didn't someone suggest xbink the other day? I think that would be more productive than xvc1 :-P. [00:24:43] <gnafu> Or perhaps x261. [00:25:02] * gnafu encoded a couple movies to H.261 the other day, complete with G.711 audio. [00:25:15] <gnafu> It's interesting to use standards that are older than yourself. [00:26:29] <gnafu> Or at least close. They weren't standardized until shortly after I was born, but the technologies obviously were there beforehand. [00:29:34] <gnafu> I think I created the video and audio streams using mencoder, but only ffmpeg could manage putting them into a container (and AVI was the only thing that worked). [00:31:51] * Sean_McG waits for his SPARC to try bootstrapping gcc again, this time with C and C++! [00:32:21] <Sean_McG> not sure what broke, but any time I try to build with anything other than --enable-languages=c it craps out [00:41:02] <gnafu> Do you think it's save to say I risk no patent lawsuits if I were to publish video in H.261 format with G.711 audio in an AVI container? [00:41:05] <gnafu> *safe [00:41:19] <gnafu> I'm guessing that's all expired. [00:42:30] <gnafu> Perhaps a truely free baseline codec for web usage! [00:43:16] * Sean_McG resists urge to say something [00:43:59] <gnafu> Sean_McG: I'll stop now. [00:44:53] <lu_zero> gnafu: use nut as container [00:45:28] <gnafu> lu_zero: Aah, I'll have to try that ;-). [00:48:51] * Sean_McG files another gcc bugzilla [00:53:17] <Sean_McG> hmmm I should really convert to ZFS root. [00:56:13] <Sean_McG> ah rats... not without another SCSI disk :( [02:16:48] <BBB> elenril: please look at https://roundup.ffmpeg.org/issue2638 [02:51:38] <Jumpyshoes> BBB: should i comment on https://roundup.ffmpeg.org/issue421 ? [02:54:30] <BBB> if I understand correctly, benjamin was in touch with them [02:54:32] <BBB> wait for him [02:54:38] <BBB> or better, ask him [02:55:58] <Jumpyshoes> BBB: okay [03:15:09] <Jumpyshoes> for wmaprodec.c, what is called before decode_init? i.e. what sets up the AVCodecContext before the call? [03:41:18] <ruggles> Jumpyshoes: i think the user calls avcodec_alloc_context() then avcodec_open(). [03:46:10] <BBB> and in between, the user filsl in the AVCodecContext [03:47:26] <Jumpyshoes> ah, okay, thanks [04:54:52] <in3xes> Writing a video encoder from scratch in one summer is not possible?? [04:56:05] <in3xes> or decoder? [05:01:17] * in3xes notices most of them are related to audio codecs in SoC ideas page [05:05:06] <pengvado> quite possible, if you're good at it. the probability that a random student will do so is somewhat lower. [05:08:02] <Dark_Shikari> I wrote a video encoder from scratch in one weekend [05:08:07] <Dark_Shikari> and that was when I was much crappier than I am now., [05:08:13] <Dark_Shikari> to be fair it wasn't very good [05:16:01] <in3xes> pengvado: Is there any open standard codec for implementation? from scratch? [05:19:27] <kierank> in3xes: implementation of what? [05:20:13] <in3xes> kierank: video encoder [05:21:33] <in3xes> kierank: I would like to work on a video encoder this summer. I am looking for one. [05:22:11] <in3xes> prefarably who's specs are open [05:22:48] <in3xes> s/prefarably/preferably [05:23:03] <_av500_> vp8 [05:23:07] <_av500_> cough [05:23:09] <kierank> bear in mind video encoders are hard and iirc few (or none) have been completed at gsoc [05:23:56] <in3xes> _av500_: Seems Dark_Shikari already completed it [05:24:00] <in3xes> no? [05:24:52] <kierank> no [05:25:55] <in3xes> Oh, that was decoder :-| [05:26:32] <_av500_> so? write a better one :) [05:26:51] <kierank> you should try something easier in3xes [05:27:24] <_av500_> bink [05:27:36] <in3xes> kierank: Okay [05:29:13] <saintdev> Dark_Shikari: moar photon! [05:32:52] <saintdev> -ab 64k | bitrate= 70.7kbits/s with mp4 overhead [05:33:29] <saintdev> peloverde: <saintdev> -ab 64k | bitrate= 70.7kbits/s with mp4 overhead [05:37:39] <Dark_Shikari> god damn charliogne is such a troll [05:38:24] <saintdev> hmm, still a ways off at high bitrates [05:40:42] <peloverde> that's close to 10% [05:41:19] <kierank> Dark_Shikari: i feel like trolling him back [05:41:43] <saintdev> peloverde: well it's better than 90k when you asked for 64k [05:41:56] <saintdev> peloverde: also muxing overhead is reported as ~5% [05:42:17] <kierank> "So which of our sins will our children have to hide" [05:43:39] <Dark_Shikari> kierank: talk about h.262 [05:52:59] <kierank> Dark_Shikari: you mean h.262 scalable or the crappy vlcs or what? [05:55:01] <peloverde> if muxing overhead is 5% then the muxer is doing something wrong [05:56:08] <saintdev> peloverde: dunno [05:56:11] <saintdev> ./ffmpeg -y -i ~/codecs/samples/comp.wav -strict experimental -acodec aac -ab 64k ~/test.mp4 [05:56:28] <saintdev> size= 783kB time=90.82 bitrate= 70.7kbits/s [05:56:37] <saintdev> video:0kB audio:749kB global headers:0kB muxing overhead 4.526981% [05:57:28] <saintdev> drops considerably for higher bitrates. it's almost 10% @ 32k [05:58:03] <saintdev> mplayer reports the same bitrate as doing the calculation [05:58:50] <Dark_Shikari> kierank: refer to mpeg-2 has h262 [05:58:51] <Dark_Shikari> *as [05:58:59] <kierank> oh yeah of course [06:02:26] <Sean_McG> mru: where do I get an ebuild for gcc 4.6 SVN on ppc gentoo? [06:04:20] <saintdev> there isn't one (probably masked) in portage? [06:04:39] <saintdev> nope, guess not [06:06:58] <saintdev> Sean_McG: toolchain overlay [06:07:08] <pengvado> what, just "h262"? not "ISO/IEC 13818-2 / ITU-T H.262 / MPEG-2 Video"? [06:08:39] <Sean_McG> lol [06:09:11] <saintdev> Sean_McG: http://overlays.gentoo.org/proj/toolchain/browser/sys-devel/gcc/gcc-4.6.0_p… [06:09:18] <saintdev> of course that's a live svn ebuild [06:10:02] <Sean_McG> yeah I just found that [06:10:02] <Sean_McG> cheers [06:17:28] <kierank> pengvado: he gets annoyed when you call standards by their H.26x name [06:19:27] * av500 updates Asim [06:19:27] <av500> damn, update failed [06:19:27] * saintdev gives av500 an Asimo [06:19:27] <av500> yes, but does it run in qemu? [06:20:42] <saintdev> probably not, it apparently runs VxWorks [06:28:51] <peloverde> if he doesn't like the h.names maybe he should make the mpeg versions free [06:36:37] <av500> not his call [06:43:34] <peloverde> why are some mpeg standards free? [06:44:42] <peloverde> like 14496-12, -20 [06:46:50] <av500> because they are useless? [06:47:08] <peloverde> -12 is fairly useful [06:47:25] <superdump> non-patentable methods enclosed? (what is -12?) [06:47:37] <peloverde> ISO Base Media File [06:47:44] <av500> which is what? [06:47:51] <av500> .mp4? [06:47:51] <peloverde> .mp4 [06:47:57] <peloverde> the core parts [06:48:03] <superdump> <@superdump> non-patentable methods enclosed? [06:48:13] <av500> well, I can understand they do not dare to ask for money for a file format [06:48:31] <peloverde> What does patentability have to do with it? [06:48:45] <av500> the damage by 15 wrong RE'd version is probably higher [06:50:19] <peloverde> everyone passes cracked specs around anyway so I doubt that is a good reason [06:51:25] <peloverde> if they can make 14496-12 free I don't understand why they can't make 14496-10 or 13818-2 free [06:51:53] <peloverde> except I suppose they don't need to make the latter two free because they are available elsewhere [06:52:40] <peloverde> but when the one with your name costs money and the other guy is giving it away for free, you should expect people to call it by the other guy's name [06:54:22] <saintdev> H.264 >> MPEG-4 AVC [06:57:53] <thresh> morning [06:58:34] <saintdev> what would be the correct way to do this: assert(bit_save <= 0.3f && bit_save >= -0.05000001f); ? [06:59:06] <saintdev> -0.05000001f should be -0.05f, but the assert still triggers if bit_save == -0.05 [07:00:12] <siretart> finally, ffmpeg 0.6 got hammered into debian/wheezy. Using with a quite large hammer [07:01:27] <elenril> nice [07:01:33] <elenril> time for 0.7? ;) [07:08:13] <Sean_McG> ah yes I remember Debian Eternal Beta Syndrome well [07:36:07] <ffmpeg> i'm trying to compile my project against libavcodec, libavutil and libavformat and i'm trying to access the H264Context. Therefore, i need to include the headers libavcodec/h264.h and libavutil/internal.h. However, the compiler is complaining about av_alias16 and av_alias32 being undefined [07:36:20] <kierank> you can't do that [07:36:32] <kierank> H264context is not public [07:36:40] <av500> hint: internal != external [07:37:13] * elenril grants av500 the CaptainObvious award [07:37:44] * av500 gladly takes it [07:37:55] * av500 meta thanks elenril [07:41:43] <ffmpeg> kierank: i'm not sure i understand. as far as i can tell the compiler here is complaining about av_alias16 and av_alias32 not being declared. If i look in the intreadwrite.h source file i see three av_alias union defintions. i do not understand how these three unions are all declared av_alias [07:42:01] <kierank> you can't include h264.h in your project [07:42:17] <av500> ffmpeg: you are compiling against non-public headers [07:42:21] <av500> that does not work [07:42:27] <av500> as you found out [07:43:04] <ffmpeg> is there a convenient way to make them public? [07:43:36] <kierank> no [07:43:40] <kierank> what are you trying to do [07:47:30] <ffmpeg> i m trying to access all the motion data and mode data from the H264Context [07:47:45] <kierank> all of that is exported i think [07:49:14] <ffmpeg> what do you mean with exported? [07:49:39] <kierank> exported to the public api [07:51:52] <ffmpeg> where can i find these functions? [07:52:02] <kierank> libavcodec/avcode.h [07:52:06] <kierank> avcodec.h* [07:52:09] <ffmpeg> i only know of high level api (working on packets etc.) [07:55:42] <ffmpeg> can you explain me the three av_alias definitions in libavutil/intreadwrite.h? why does this not introduce a compiler error when compiled with the makefile? [07:56:29] <kierank> anyway this discussion for #ffmpeg [08:10:20] <j0sh> any NEON experts still awake? [08:11:22] <kshishkov> me knows a bit on NEON, sahib [08:11:31] <j0sh> oh, good, you're perfect [08:11:40] <j0sh> i'm trying my hand at NEONifying swscale [08:11:59] <j0sh> there are a few different algos that are uses for yuv->rgb [08:12:04] <j0sh> im not sure which is best suited [08:12:45] <j0sh> there's a LUT approach, there's the one you used in your MMX code

1 0

IRC log for 2011-03-03
by irc＠mansr.com 04 Mar '11

04 Mar '11

[00:59:47] <Sean_McG> when using av_log(), how do you give the log entry a meaningful tag rather than [ NULL @ <addr> ] ? [01:11:40] <astrange> pass a struct as the first argument whose first member is an AVClass * [01:12:00] <mru> not worth the trouble for a quick debugging hack [01:12:20] <Sean_McG> OK [01:23:39] <Sean_McG> style question: true/false, TRUE/FALSE, or 0/1 ? [01:24:01] <mru> !/nil [01:24:10] <mru> if (cond) [01:24:13] <mru> if (!cond) [01:24:51] <mru> one day I'm going to sneak in #define TRUE 1, #define FALSE 2 somewhere [01:25:00] <Sean_McG> LOL [01:25:28] <mru> or #define TRUE 256 to fuck with people who typedef char bool [01:41:03] <Sean_McG> when I reply to update a patch, which message ID should I reference... the last patch submission, or the latest reply? [01:42:30] <mru> whatever makes sense [01:43:22] <Sean_McG> OK [01:44:32] <Sean_McG> sent [02:44:11] <BBB> Yuvi: btw the ipad2 looks really nice. just mentioning, no reason why I'm pointing this out specifically to you, just, you know, saying... :-p [02:47:57] <Sean_McG> hahah [02:49:39] <kierank> BBB: omg now it's white [02:50:17] <BBB> I know, it's got a new color, I gotta go buy one [02:50:28] <BBB> well actually, that's unfair, I never had an ipad1 and pre-ordered the ipad2 a while ago [03:02:58] <astrange> employee discount doesn't work on new products for a while [03:05:29] <Jumpyshoes> BBB: how much is it gonna cost? [03:05:49] <astrange> price is the same [03:05:59] <Jumpyshoes> oh. is it just white? [03:06:10] <astrange> http://store.apple.com/us/browse/home/shop_ipad/family/ipad/start?mco=OTY2O… [03:06:53] <astrange> http://store.apple.com/us/browse/home/specialdeals/ipad?mco=OTY2ODY4NQ [03:07:04] <Jumpyshoes> that is expensive [03:09:37] <astrange> refurbished is a good deal. there's really no reason to upgrade from the base model [03:14:01] <Jumpyshoes> i don't buy apple products [03:14:07] <Jumpyshoes> i was lucky enough to get a free itouch though [03:59:33] <Jumpyshoes> what is nfc quantization? [03:59:57] <mru> no f*cking clue [04:01:11] <Jumpyshoes> it probably isn't important [04:02:52] <kierank> google says noise feedback coding [04:03:10] <Jumpyshoes> huh [04:08:39] <Sean_McG> I'm with mru on that one ;) [04:19:32] <Jumpyshoes> is there a way to make my cygwin configure nonretarded [04:24:51] <Sean_McG> yeah, switch to *ix ;) [04:25:49] <Shu> i should not have run make -j. i love it when cygwin freezes my entire box [04:26:31] <kierank> haha [04:26:50] <drv> i have to use cygwin at work, makes me die inside [04:27:12] <Shu> i hate vim copy paste more than i hate cygwin [04:36:26] <Jumpyshoes> AVERROR_PATCHWELCOME [04:38:48] <Jumpyshoes> i didn't know this existed [04:40:20] <Sean_McG> hahahahah [04:47:42] <saintdev> peloverde: ping [04:57:59] <Jumpyshoes> how do i just make ffmpeg? is it just "make ffmpeg"? it isn't work for me in cygwin [05:00:10] <saintdev> me english parser isn't work either. [05:00:44] <Jumpyshoes> how do i make ffmpeg and not ffplay, ffserver, etc? [05:00:52] <kierank> --disable-ffplay --disable-ffserver [05:00:56] <kierank> in ./configure [05:01:10] <Jumpyshoes> oh great, another configure run <_< [05:01:23] <saintdev> make ffmpeg works4meTM [05:02:28] <Jumpyshoes> i bet cygwin is being retarded again [05:21:45] <drv> you probably have to say make ffmpeg.exe [05:26:52] <saintdev> drv: good point [05:37:01] <peloverde> saintdev: pong [05:44:08] <Jumpyshoes> can i get ffmpeg to surpress compiler warnings? [05:46:39] <mru> close eyes [05:48:16] <Jumpyshoes> well [05:48:20] <Jumpyshoes> i do want to see compiler errors [05:49:20] <ohsix> add -Werror [05:49:29] <drv> haha [05:52:56] <drv> wow, make -j (giantnumber) makes make significantly faster on cygwin [05:53:18] <kierank> make isn't the problem on cygwin, it's configure [05:53:29] <drv> yeah, configure is painful, but even make is super slow [05:54:39] <ohsix> configure just runs lots of test programs, not good for cygwin [05:55:38] <mru> configure runs the compiler, just like make does [05:56:15] <ohsix> the tests are very short lived, and also ran themselves sometimes [05:56:16] <elenril> mru: already awake or still awake [05:56:34] <mru> still... [05:57:00] <drv> the compiler runtime is almost negligible compared to the time spent sitting around waiting for process bringup and teardown [05:57:29] <ohsix> yep [05:57:40] <kierank> I guess I find configure painful on cygwin because you can't see anything going on. at least make looks like its doing something [05:57:51] <ohsix> emulating the address space stuff on fork on windows is very very slow [05:58:38] <j0sh> in swscale, are c and accelerated conversions supposed to return identical output? [05:58:52] <j0sh> swscale-test with --disable-mmx returns totally different numbers [05:59:17] <ohsix> "only with -bitexact" or something of that nature, i'd surmise [05:59:55] <ohsix> but c & asm for filters should be the same i think (but don't know) [05:59:56] <j0sh> hm [06:03:33] <drv> hm, make -j12 is roughly 35 seconds vs make -j1 at 6m21s, which is pretty close to scaling linearly, just feels really slow [06:04:23] <mru> on what hw? [06:04:55] <drv> i7, 6 cores with ht [06:05:07] * mru wishes he could use all the 900 cores on the supercomputer he's currently logged into [06:05:38] <kierank> haha they're arguing about QCIF vs QSIF on jvt-experts now [06:05:58] <mru> 240 vs 288 [06:06:34] <mru> I call them both epsilon [06:07:51] <saintdev> kierank: in latin? [06:08:00] <kierank> no, english today [06:13:43] <saintdev> kierank: quad-QCIF? [06:14:04] <kierank> lol [06:14:41] <saintdev> QSIF-HD =P [06:21:24] <kierank> mru: logged on to watson? [06:22:18] <spaam> kierank: mru is watson. [06:22:37] <kierank> watson is powerpc iirc [06:22:42] <kierank> mru must be an arm version [06:23:07] <saintdev> POWER7 [06:24:39] <saintdev> This is a RAD video game codec. [06:26:36] <kierank> What is codec? [06:26:56] <Sean_McG> mmmm POWER7 [06:27:17] <saintdev> No, Watson. [06:27:46] <KenJennings> What is Bink? [06:28:20] <saintdev> lol [08:16:22] <in3xes> ffmpeg [08:16:35] <in3xes> oops! sorry [08:17:57] <andoma> good morning internet! [08:18:11] <Zor> why hello [08:18:23] <thresh> moroning [08:18:48] * av500 hands thresh some water [08:25:07] <pJok> god morgon :) [08:25:24] * pJok thought most of the drama was over on the ML [08:28:33] * av500 lols at the QCIF drama on jvt-experts [08:29:19] <thresh> av500: does it come with antisleeping pills? [08:29:26] <av500> nah [08:29:46] <av500> thresh: and its way to polite [08:30:04] * thresh was asking about the water [08:30:14] <av500> thresh: "little" warer [08:30:17] <av500> thresh: "little" water [08:30:23] <thresh> i'm puzzled [08:30:41] <av500> I see that [08:30:47] * av500 sends thresh back to bed [08:41:50] <kshishkov> av500: link please [08:46:34] <av500> kshishkov: to what? jvt? [08:46:50] <kshishkov> yep [08:46:57] <kshishkov> and to all their resources [08:47:11] <av500> you want teh codez? [08:50:47] <kshishkov> not sure [08:51:51] <kshishkov> but I dislike the fact that most jvt-related places ask for login/password [08:54:43] <av500> thats how one develops "open" standards, no? :) [08:57:16] <thresh> http://lwn.net/SubscriberLink/430118/39152afef931d92e/ [08:58:58] <kshishkov> av500: I though the proper way is to buy proprietary stuff and release its sources as "open spec" [09:01:15] <av500> thresh: that does not mention FFmpeg [09:01:57] <kshishkov> or getopt.c [09:03:11] <thresh> av500: I had an impression that bashing google is completely on-topic here [09:03:46] <kshishkov> thresh: and here's a companion piece http://www.h-online.com/open/news/item/Controversy-surrounds-Red-Hat-s-obfu… [09:04:22] <thresh> yeah [09:05:04] <av500> and? [09:05:16] <av500> gplv4 can mandate .patch files [09:05:38] <thresh> RHEL5 kernel comes with 2000 of those [09:05:46] <thresh> no git whatsoever [09:05:57] <av500> grep git GPL [09:06:42] <thresh> ha ha you evil proprietor [09:06:46] <av500> gplv5 can then mandate *all* GPL code to live in a git on stallmans gdium only [09:07:26] <av500> oh, and its not online all the time, so print out patches and mail them.... [09:07:31] <kshishkov> av500: he has yeelong - gdium is not open enough for him [09:07:49] <av500> yeehav then [09:08:57] <av500> gplv6 can then mandata that only RMS can even write GPL code [09:09:32] <kshishkov> av500: <offtopic> can you build new ArchOS player on http://www.loongson.cn/product_info.php?id=31 specially for him?</offtopic> [09:09:58] <thresh> The source is configured: with a handwritten shell script [ +10 points of FAIL ] [09:11:41] <kshishkov> The source is not configured at all [+100 points of FAIL] [09:12:15] <av500> Your project only does releases as attachments in web forum posts [ +100 points of FAIL ] --> ffforum.org [09:13:58] <kshishkov> Linux kernel seems to gather lots of points on that test IIRC [09:14:15] <av500> its a FAIL [09:14:25] <kshishkov> GNU Hurd NG! [09:14:32] <wbs> tanenbaum knew that 20 years ago, already [09:14:33] <av500> it starts by being a fork of minix [09:15:01] <av500> and linus was not involved in the parent project either [09:16:00] <kierank> [08:52] kshishkov: but I dislike the fact that most jvt-related places ask for login/password --> not really [09:16:03] <kierank> anyone can register [09:16:12] <ohsix> fork of minix? [09:16:17] <av500> so why ask for a password then? [09:16:34] <av500> ohsix: it uses 3 letters [09:16:45] <av500> out of 4 [09:16:54] <av500> clearly a fork [09:17:01] <kierank> av500: to stop spammers and "plz send me the codes types" [09:17:07] <ohsix> ah, good one; awesome to start flamin' too [09:17:08] <kierank> doesn't work 100% i must add [09:17:19] <kshishkov> doesn't work at all I think [09:17:35] <kshishkov> because Chinese/Indians are hard-working [09:17:37] <av500> kierank: signing up to a ml is one thing [09:17:49] <av500> reading the archives behind a pwd is another [09:19:12] <thresh> so ffmpeg gets 10 points of FAIL, and vlc only 5 points of FAIL [09:19:15] <kshishkov> av500: that's to prevent spammers reading if somebody sent the codez so they can ask it immediately after registration [09:19:33] <kshishkov> thresh: autotools count for +666 point of FAIL [09:19:44] <thresh> autotools <3 [09:19:55] <ohsix> also a good place to start a flame [09:41:20] <cartman> moin [09:42:39] <av500> cartman: packed? [09:43:27] <cartman> av500: packed for a small holiday, flying next Wednesday! :) [09:43:45] <av500> dont come via frankfurt, its not safe [09:44:19] <kshishkov> only for brain [09:44:45] <kshishkov> and fortunately München airport should be ideal for him [09:44:49] <cartman> av500: coming directly to Nürnberg [09:45:35] <kshishkov> av500: BTW, what do _you_ have against the airport? [09:45:48] <av500> kshishkov: http://www.dawn.com/2011/03/03/two-us-airmen-killed-in-frankfurt-airport-sh… [09:46:53] <av500> kshishkov: I have nothing against it [09:46:56] <kshishkov> av500: Kosovo, US, Frankfurt - a dangerous combination indeed [09:46:58] <cartman> yeah :/ [09:47:15] <av500> kshishkov: now add KKP people [09:47:21] <cartman> lol [09:47:57] <kshishkov> av500: what is KKP? Some Chinese newspaper? [09:48:54] <pJok> god morgon kshishkov [09:49:02] <kshishkov> goda morgnar, pJok [09:49:13] <av500> kshishkov: no, cheap trick to fool cartman's controlling officers [09:49:39] <cartman> hahah :) [09:50:05] <kshishkov> cartman: well, we know you're all for free Kurdistan ;) [09:50:13] <av500> kshishkov: damn yoi [09:50:15] <av500> u [09:50:31] <av500> suse cannot afford to lose another employee [09:50:38] <av500> they are so few already [09:50:46] <kshishkov> good riddance! [09:52:38] <cartman> bah [09:52:50] <cartman> wait one week and then you can joke all day long :P [09:53:29] <av500> then it wont be fun [09:53:51] <cartman> true :P [09:53:51] <av500> until we learn your BND trigger words [09:54:56] <kshishkov> cartman: anyway, you'll be in Bavaria and we in Germany [09:55:13] <cartman> I am OK with that [09:55:21] <cartman> as long as visa says Germany [09:55:26] <kshishkov> :) [09:56:01] <kshishkov> don't forget to try Bayrische traditionell Weißdöner and Leberköfte [09:56:27] <cartman> I'll make sure :P [09:56:46] <thresh> uhmm, bavarian dirndls [09:57:05] <cartman> http://placekitten.com/ [09:59:19] <kshishkov> thresh: сарафаны с кокошниками лучше? [10:00:02] <thresh> kshishkov: "uhmm" означало http://4.bp.blogspot.com/_dH3Lwg9Gc1Y/SXfkSS2puPI/AAAAAAAAAPc/9528CDmviHg/s… [10:04:23] <av500> BSAC, do I ever need that? [10:05:46] <kierank> av500: some korean or japanese thing uses it iirc [10:06:56] <kshishkov> kierank: then they are ven crazier than anybody thought [10:07:08] <peloverde> korean broadcast tv uses bsac [10:07:39] <peloverde> t-dmb [10:08:14] <av500> yes [10:08:19] <av500> besides dmb [10:10:46] <kshishkov> that's very dmb IMO [10:10:56] <thresh> It also counts for substantial FAIL if "all your web site has is a picture of a marijuana leaf," as he said one small-scale open source project does. [10:11:10] <kshishkov> what convenient features does BSAC have? [10:11:47] <kierank> kshishkov: the feature that it is in 14496-3 [10:13:39] * kshishkov thinks it's very obvious that there are a lot of things in 14496-3 [10:14:08] <kshishkov> why not TwinVQ then? [10:14:43] <kshishkov> or somebody just wanted to exercise arith coding patents belonging to them? [10:14:49] <kierank> of course [10:15:24] <peloverde> fgs bullshit [10:16:09] <kshishkov> fgs? [10:17:11] <peloverde> fine grained scalability [10:18:41] <kshishkov> then why it's allowed to have SBR-in-BSAC ? [10:21:20] <peloverde> bsac still has arithmetic coding [10:22:39] <peloverde> and doesn't bsac+sbr use "Scalable sbr"? [10:24:19] * kshishkov wonders how well "scalable" and "arithmetic coding" go along [10:25:22] <kierank> kshishkov: anything can be scalable when you're mpeg [10:26:04] <kierank> like hevc scalable [10:26:44] <kshishkov> kierank: your phrase sounded like one of the songs from the South Park movie [10:27:06] <pJok> anything is scalable if you use just add enough math to it [10:27:48] <kshishkov> pJok: if you add enough cores [10:29:32] <kshishkov> kierank: just look at the last lines - http://www.metrolyrics.com/im-super-lyrics-south-park.html [10:30:40] * kshishkov lols hysterically at "byte-swapped IMA ADPCM data" on ML [10:32:49] * av500 suggests a parser [10:33:16] <av500> or libavswap [10:34:18] <kshishkov> thanks, he decided to use parser already [10:34:41] <kshishkov> I'd propose bitstream filter instead [10:34:45] <kierank> lol libavswap [10:35:20] <av500> pmi, but why was wrong about just swapping the damn bytes in the RM demuxer? [10:35:26] <av500> why->what [10:36:33] <kshishkov> it's a hack [10:38:30] <av500> kshishkov: so is the de-interleaving of cook also a hack and should be done in an outside parser? [10:38:30] * kshishkov found that RM specs has only one instance of "DNET" - the word "idnetify" [10:38:37] <kshishkov> av500: nope [10:38:48] <kshishkov> actually RM specifies a number of interleavers [10:38:50] <av500> kshishkov: dnet is a 2byte interleaving :) [10:38:54] <av500> solved [10:38:57] <av500> next [10:39:07] <kshishkov> av500: nope [10:39:30] <kshishkov> files with it have "Int0" interleaver - i.e. no interleaving was done [10:40:54] <av500> jaja [10:41:25] <av500> just go ahead and add more memcpy [10:51:28] <kierank> plz send me codez for memcpy [10:52:03] * cartman hands kierank a 0day memmove [10:52:18] <kshishkov> cartman: memmove is more robust [10:52:27] <av500> kierank: here: http://www.gtk.org/ [10:52:45] <av500> ah, no that was teh codez for strcmp [10:52:59] <kierank> av500: same thing, no? [10:53:02] <cartman> kshishkov: no need for overlap check [11:03:30] <kshishkov> mate! [11:06:44] <pross-au> ksh [11:07:45] <kierank> kshishkov: you should go and visit pross-au [11:08:06] <pross-au> Bring ya swag [11:09:19] <kshishkov> pross-au: http://zod.sourceforge.net/ [11:09:27] <pross-au> Cmdr Zod? [11:09:52] <pross-au> Hey cool [11:09:52] * pJok wonders how a codec designed by ffmpeg commitee would look like [11:09:52] <kshishkov> just look at it [11:10:05] <pJok> rather, format... audio+video+container [11:10:13] <kshishkov> pross-au: so guess your work would be appreciated, mate [11:10:48] <kshishkov> pJok: never completed due to bikesheds [11:11:34] <pJok> kshishkov, possibly... [11:11:40] <pross-au> consensus was obtained on the container [11:11:49] <pJok> kshishkov, isn't ffv1 designed by ffmpeg committee? [11:12:34] <Dark_Shikari> you mean michael [11:12:47] <kshishkov> pJok: nope, ffv1/snow and maybe nut were designed by one man [11:12:53] <pJok> ah [11:13:10] <pJok> Dark_Shikari, tomato potato [11:22:04] <iive> kshishkov: this is a lie [11:22:49] <iive> at least the nut bit. [11:23:01] <kshishkov> that's why I said "and maybe NUT" [11:23:10] <kshishkov> I know Oded worked on it [11:23:14] <iive> then don't say it. [11:25:52] <pross-au> somebody should really survey usage of the many formats available.. would make for an interesting read [11:27:59] <iive> pross-au: avi,mkv,mp4,ogm in that order. [11:29:36] <pross-au> what? no .bik! [11:29:42] <av500> .rmvb [11:29:48] <av500> all of china uses that [11:30:03] <cartman> indeed [11:30:05] <av500> and .wmv for all the pron [11:30:10] <iive> not really, they are still at vcd :P [11:30:13] <cartman> av500: I wonder why though (rmvb) [11:30:16] <pross-au> could be a fun survey then [11:30:20] <av500> cartman: nobody know [11:30:22] <av500> cartman: nobody knows [11:30:27] <av500> even real does not know [11:30:31] <av500> we asked them [11:30:33] <cartman> lol [11:30:48] <cartman> we have 1080p rmvb samples from China [11:30:50] <cartman> amazing [11:30:59] <av500> cartman: theory is that at some point in time, real producer "worked" for the chinese [11:31:04] <av500> and these people just stuck to it [11:31:07] <cartman> :D [11:31:19] <av500> or it was the easiest to cracj [11:31:20] <av500> k [11:39:13] <pross-au> and avi is popular because, its legacy, good enuff? [11:39:25] <kshishkov> yep [11:39:36] <kshishkov> be thankful WTV is not that common [11:39:52] <pross-au> Windows has had built in support for WMV for over a decade now [11:40:38] <pross-au> truth be told, i started thinking about a wtv muxer [11:44:55] <pJok> pross-au, just to mess with wtv specs? [11:46:26] <pross-au> to help build a better demuxer [11:46:44] <pross-au> because theres a lot of unknowns in there [11:48:16] <pross-au> it seems any modules/filters int the wtv streaming graph can write chunks, so theres a lot of proprietary chunks in the wtv file [11:51:51] <kshishkov> so it's completely the same in design as OLE archives (aka M$ Office document formats) [11:52:15] <pJok> kshishkov, not that odf is much better [11:53:04] <cartman> [applehttp @ 0xc19180]Receiving 1 variant streams [11:53:07] <cartman> awesome :D [11:53:19] <pross-au> kshishkov: precisely [11:53:26] <spaam> cartman: wait until you have 2 variants.. [11:53:39] <av500> or 42 [11:53:41] <cartman> was 8 variants [11:53:45] <cartman> it autoselected [11:53:46] <cartman> :D [11:54:09] <cartman> now I can watch our turtleneck Steve showing iPad2 [11:54:34] <Compn> variants? [11:54:37] <Compn> sounds like mbr [11:55:38] <Compn> [06:45] <av500> we asked them [11:55:40] <pJok> cartman, good ol' appleSteve [11:55:40] <Compn> lol! [11:55:42] <Tjoppen> no negative feedback on my wav patches at all? this must be a first :) [11:55:59] <mru> Tjoppen: you got a wtf from michaelni [11:56:09] <cartman> pJok: indeed [11:56:17] <Compn> av500 : next you'll have to ask china , but i guess its 'what everyone else is using' like divx/h264 in the rest of the world [11:56:44] <Tjoppen> I don't see why. I rearranged the some code that was already there [11:57:59] <av500> Compn: yes [11:58:09] <av500> Compn: they even did a survey back in the days [11:58:28] <av500> Compn: and found that .rmvb was only used for P2P content :) [11:59:51] <merbzt> Tjoppen: indentation I think [12:01:10] * Compn wonders how many hardware rmvb players there are in china now [12:01:17] <Compn> using ffmpeg code [12:02:33] <spaam> cartman: 2 [12:04:55] <Tjoppen> then he must have missed that it's rearranged code [12:08:58] <iive> Tjoppen: i think it have more to do with the possibility of seeking to int64_max position. [12:09:26] <iive> or rather offset. [12:13:02] <Tjoppen> hm [12:13:22] <Tjoppen> right, might not want to set next_tag_ofs to INT64_MAX [12:24:45] <mru> #ifdef Is_True_On [12:25:08] <Tjoppen> enum { TRUE, FALSE, FILE_NOT_FOUND }; [12:59:08] <thresh> kshishkov: http://lenta.ru/news/2011/03/03/hmao/ [13:00:45] <kshishkov> thresh: ну и страна, однако [13:02:44] <JEEB> Великая страна Россия [13:06:15] <kshishkov> JEEB: so would you prefer to live in Grand Duchy of Finland or Österbotten (if current country is not available)? [14:20:50] <in3xes> What is the correct place for title, author, year etc.? [14:24:19] <twnqx> isn't metadata just built as a list of attribute/value pairs? [14:25:05] <kierank> ask elenril [14:27:09] <JEEBsv> kshishkov: I'm not sure. Might choose Österbotten. [14:27:13] <JEEBsv> My name is fully Swedish anyways [14:27:14] <JEEBsv> lol [14:37:33] <in3xes> elenril: ping [14:44:52] <J_Darnley> What do you mean by "correct place"? [14:52:35] <in3xes> J_Darnley: Fields in AVFormatContext are deprecated. So where should I put them? [14:52:56] <J_Darnley> The AVMetadata struct [14:53:10] <J_Darnley> Using the supplied functions [14:53:21] <elenril> av_metadata_set2 [14:53:35] <J_Darnley> like that ^ [14:53:48] <in3xes> Okay [14:54:30] <kshishkov> elenril: today I ate lie from a can [14:59:37] <elenril> http://tvtropes.org/pmwiki/pmwiki.php/Main/BlatantLies [15:00:00] <kshishkov> elenril: nope, different lie - the one featured in Portal [15:00:33] <elenril> there really was a cake [15:00:37] <elenril> and it was delicious too [15:01:12] <kshishkov> yes, since I happen to live in a region where that cake originated from, I tried it [15:03:58] <elenril> btw [15:04:06] <elenril> anyone wants to mentor playlists? [15:14:55] <in3xes> Isn't that an abandoned project? [15:15:43] <elenril> yeah, it failed in the last gsoc [15:16:23] <in3xes> btw, I am a student :) [15:16:38] * elenril is a student too [15:20:20] <BBB> elenril: you want to do playlists? [15:20:24] <BBB> elenril: that's a massive task [15:20:29] <BBB> elenril: I thought you were busy [15:20:41] <BBB> in3xes: want to participate in gsoc? [15:21:03] <elenril> BBB: can't be THAT bad [15:21:16] <BBB> I've been told it eats your soul [15:21:23] <elenril> maybe i could recycle something from the previous attempt [15:43:12] <BBB> elenril: if possible [15:43:17] <BBB> elenril: would you mind going through that code? [15:43:41] <BBB> elenril: my impression was that the student sort of went off by himself, didn't discuss and so some code might be useful but the concept at large isn't very useful [15:43:49] <BBB> i.e. first plan how to integrate it, then code [15:43:52] <BBB> not the other way around [15:51:08] <in3xes> BBB: yes [15:53:11] <BBB> in3xes: what project (or type of work) are you interested in? [15:53:24] <BBB> elenril: btw I'm all for you doing playlists, you'll have a much higher chance of success than anyone else [15:53:40] <BBB> I'm just affraid it's like the kernel block layer: waterloo for everyone [15:54:03] <elenril> what's wrong with kernel block layer? [15:54:10] <elenril> and who'd mentor it? you? [15:54:18] <Kovensky> BBB: stalingrad > waterloo [15:54:56] * av500 proposes a neon audioconvert and downmix [15:55:03] <av500> mru to mentor it [15:55:06] <BBB> elenril: dunno... we'll have to find someone [15:55:40] <mru> Kovensky: hardly, stalingrad is an obscure paris metro station, waterloo is one of the main rail hubs in london [15:56:39] <Kovensky> ofc london would name one of their main rail hubs after one of the most famous defeats for france :D [15:56:44] <kierank> yup [15:56:56] <kierank> the rail hub that had trains to france too [15:57:35] <mru> and it's right next to trafalgar square [15:57:52] <mru> baptiste mumbled something when he visited... [15:58:29] <elenril> maybe wbs... [15:58:54] <kshishkov> Kovensky: well, all Russian/Ukrainian railroad stations are named after one in London [15:58:56] <in3xes> BBB: Any suggestion? [15:59:07] <kierank> mru: nope, waterloo's on the other side of the thames [15:59:37] <mru> close proximity [15:59:44] <mru> it's <10m walk [15:59:53] <kierank> yeah i suppose [16:00:37] <mru> the various rail/tube stations in that area are weird [16:03:33] <kierank> a lot of them are right next to each other because in the 1800s competing rail companies built them there [16:06:51] <Kovensky> http://www.cracked.com/article_18550_5-true-war-stories-that-put-every-acti… <-- #5 on why stalingrad > waterloo [16:09:35] <j-b> hello people! [16:09:56] <lu_zero> hi [16:10:13] <mru> hello french [16:11:42] <av500> j-b: booze on monday? [16:12:45] <j-b> av500: NO! [16:12:56] <j-b> av500: I take a true week of holidays :D [16:13:01] <av500> pah [16:13:06] <j-b> like no Internetz [16:13:07] <av500> lazy french [16:13:26] <j-b> French, yeah... Lazy, no [16:18:26] <av500> why is audioconvert.h not exported? [16:18:36] <av500> what am i missing? [16:19:56] <kierank> in libavutil? [16:23:58] <av500> kierank: ffplay.c uses av_audio_convert [16:24:27] <av500> I want to use it too [16:24:36] <av500> but I fail to find it in installed headers [16:24:39] * av500 feels stupid [16:25:04] <kierank> it is in mine [16:25:08] <kierank> oh wait [16:25:09] <kierank> no it isn't [16:25:45] * av500 is trying a codec that returns goddam float values [16:51:58] <av500> kierank: ok, I replaced all of audioconvert with one line I stole from it... [16:51:59] <thresh> paris has a stalingrad metro station? most bizarre [16:53:06] * kierank adds av500 to hall of shame [16:53:24] * av500 laughs evil laugh [17:00:01] <mru> we should have a hall of flame [17:07:54] <BBB> elenril: as for the cafdec patch, I'd recommend to leave that for now, I don't think it really helps all that much [17:09:05] <elenril> get_strz has to be replaced anyway [17:09:53] <elenril> and since the size of the chunk is already known (and other parts of the code already rely on it being correct), we might as well use it [17:15:00] <BBB> the whole file appears to not deal with, say, the case where there's a few padding bytes after a chunk [17:15:13] <BBB> so I wouldn't say that the size is used at all [17:21:27] <elenril> yeah, i noticed that too [17:21:32] <elenril> but it's used in other places [17:22:59] <elenril> ok, i'll remove it from the patch [17:23:17] <elenril> not like i care about this demuxer [17:26:27] <BBB> elenril: that's what I thought also, like, I don't even know what caf is :-p [17:26:40] <BBB> elenril: "thanks for not caring" sounds weird though [18:33:23] <elenril> sure is netsplitty [18:33:36] <lu_zero> a lot [18:33:38] <elenril> do we turn url_ftell into a macro as well? [18:43:52] <elenril> ffmpeg can't dump attachments, right [18:44:21] <elenril> lu_zero: weren't you working on this? [18:46:15] <lu_zero> elenril: posted a patch [18:47:19] * elenril searches for it [18:54:21] <elenril> hmmm....fate still fails for me [18:54:26] * elenril wonders [19:05:14] <lu_zero> elenril: found it? [19:07:12] <elenril> yeah, will try now [19:08:31] <lu_zero> it should be able to streamcopy data streams [19:08:42] <lu_zero> well it is for nut -> anything [19:09:31] <elenril> what i want is to dump an attachment into file [20:28:25] <BBB> elenril: thanks [21:12:10] <merbanan> where is the gitorious clone ? [21:15:59] <lu_zero> http://gitorious.org/ffmpeg/ffmpeg I think [21:16:19] <merbanan> can you send a patch for the homepage [21:21:21] <Compn> huh ? [21:21:36] <Compn> ffmpeg.org homepage you mean ? [21:22:08] <merbanan> y [21:23:03] <Compn> merbanan : svn://svn.mplayerhq.hu/ffmpeg.org [21:23:03] <Compn> iirc [21:23:22] <Compn> E:\mplayer-testclips\ffmpeg.org>svn info [21:23:23] <Compn> Path: . [21:23:23] <Compn> URL: svn://svn.mplayerhq.hu/ffmpeg.org [21:23:36] <Compn> yep thats it [22:33:29] <Sean_McG> hi folks [22:35:24] <gnafu> Howdy, Sean_McG! [22:36:24] <Sean_McG> how goes? [22:52:34] <Jumpyshoes> how do you find the MSB in a int? i.e. ceil of log2(x) [22:58:54] <mru> Jumpyshoes: count leading zeros [22:59:09] <mru> in ffmpeg you can do av_log2() [22:59:16] <Jumpyshoes> oh, okay [22:59:19] <mru> it does whatever is best on your cpu [23:39:05] * Kovensky hurfs here too [23:39:07] <Kovensky> 20:36.37 Kovensky hurfs @ the vector math professor [23:39:07] <Kovensky> 20:37.02 Kovensky: he was doing pretty well... until he said that a 3D vector with the constraint "|y| = z" could point to any octant :| [23:39:10] <Kovensky> 20:37.31 Kovensky: and he insisted on it despite my objections [23:39:14] <Kovensky> 20:37.48 Kovensky: he compared "|y| = z" to "z = ±y", despite it making no sense [23:39:17] <Kovensky> 20:38.09 Kovensky: and found hard to understand when I said that "|y| = z" implies that z is positive [23:40:10] <mru> actually, it's non-negative [23:40:19] <mru> positive means strictly >0 [23:40:26] <mru> but you're right [23:41:53] <Kovensky> hopefully that's the extent of the confusion :/ [23:42:13] <Kovensky> in b4 he asks it on a test and expects the "points anywhere" answer [23:42:53] <Jumpyshoes> Kovensky: vector math as in multivariate calculus? [23:43:41] <Kovensky> idk yet [23:43:45] <Kovensky> this is the 3rd day of uni =p [23:43:58] <Jumpyshoes> well what was in the course description? [23:44:02] <Kovensky> (calculus is strictly an university level topic in brazil) [23:44:19] <Kovensky> I don't have access to those yet, only when I get my student number [23:44:41] <Jumpyshoes> how do you know what classes you're taking then ._. [23:44:59] <Kovensky> 1st semester students automatically are assigned to the 1st semester modules, and they give you a table with the modules/hours [23:45:33] <Jumpyshoes> i see [23:46:18] <Kovensky> I should receive mine sometime next week if there are no delays [23:47:06] <Jumpyshoes> so are you in the US equivalent of high school? [23:47:43] <Kovensky> equivalent of university, actually [23:47:46] <mru> vector calculus is calculus with vector-valued functions [23:47:59] <Kovensky> TJ is the weird one, based on what I hear about american schools ._. [23:48:29] <Jumpyshoes> i see [23:48:38] <Kovensky> (interestingly, in both portuguese and swedish, education levels are "lower" than in english) [23:48:45] <mru> so instead of y = f(x) you have (t,u,v) = f(x,y,z) [23:48:49] <mru> if in 3 dimensions [23:48:57] <mru> you can have any number of dimensions [23:49:02] <Jumpyshoes> you should cover vector calculus in multivariate calculus [23:49:30] <Kovensky> such as "high school" being 'ensino médio' ("middle school"), university being the "high school" [23:49:57] <Kovensky> idk if this inversion exists in swedish, but undergraduation in english is called graduation in portuguese, and english's graduation is post-graduation in pt [23:50:21] <Jumpyshoes> i've always heard it as elementary school --> middle school --> high school --> college/university --> grad school --> PhD [23:50:37] <Kovensky> talking about post-sth, reminds me of brazilian discordians translating aftermath to the equivalent of "post-mathemathics" [23:50:57] <Kovensky> (aftermath being the last month of the discordian year) [23:51:11] <Jumpyshoes> what in the world is aftermath [23:51:24] <mru> in swedish "högskola" (literally "high school") is a not-quite-university [23:51:43] <mru> they teach at the same level but aren't authorised to give out certain degrees [23:52:54] <mru> aftermath is what remains after a disaster, such as a maths degree [23:53:29] <Jumpyshoes> lol [23:53:49] <BBB> yiihaa [23:53:53] * BBB has vc1 slices working [23:53:56] <BBB> that was about time [23:54:05] <BBB> was getting bored of debugging the same issue over and over again [23:54:11] <mru> take my brother for instance, he has a phd in maths and still he's only a lowly c++ codemonkey [23:54:15] <BBB> yet another feature that NOBODY USES finally supported in ffmpeg :-p [23:54:49] <BBB> mru: don't "hogskola" give out bachelor degrees? the dutch ones do nowadays [23:55:14] <mru> they give out some degrees, not sure exactly what the rules are [23:59:28] <BBB> what useless vc1 feature shall I add support for now? [23:59:33] <BBB> maybe luma/chroma scaling!!

1 0

IRC log for 2011-03-02
by irc＠mansr.com 03 Mar '11

03 Mar '11

[00:00:23] <Sean_McG> yeah I wonder if it's a Debian patch [00:00:42] <Sean_McG> (or OBSD) [00:02:06] <Sean_McG> BTW I like how that poisonous people video mentions the big names we all know for being irritating: Theo deRaadt, DJ Bernstein(sp?), and uh... the 3rd isn't coming to me [00:05:12] <Dark_Shikari> stallman? [00:05:32] <Sean_McG> yeah, probably. [00:14:16] <peloverde_at_wor> I thought it was drepper [00:14:33] <peloverde_at_wor> stallman's brand of annoying is a little more on the weird and creepy side [00:15:02] <Sean_McG> yeah, as in: for god sakes dude, BUY A RAZOR [00:17:19] <iive> i guess nobody invented libre razors. [00:17:29] <Sean_McG> indeed. [00:17:37] <mru> peloverde_at_wor, Yuvi: will you guys be in the bay area around april 10? [00:18:12] * mru is thinking of popping over for a week or so [00:19:01] <peloverde_at_wor> I will be [00:20:28] <mru> going to the ELC conf by any chance? [00:24:35] <BBB> peloverde_at_wor: do you want to mentor bsacaac again this year? [00:24:50] <mru> BBB: oh right, you're moving to that area too... [00:24:54] <mru> when does that happen? [00:24:58] <BBB> not there yet at that time [00:25:05] <BBB> actually, I may be [00:25:06] <BBB> not sure [00:25:12] <peloverde_at_wor> BBB: sure, if any students are interested [00:25:15] <BBB> permanent move is a little later, but I may be around then anyway [00:26:39] <BBB> peloverde_at_wor: ok, re-added [00:27:37] <Jumpyshoes> sigh gsoc ;( [00:28:01] <mru> feeling left out? [00:28:20] <Jumpyshoes> i want to do something this summer [00:29:16] <peloverde_at_wor> The foundation can probably find money if you are interested and unelligible for gsoc [00:29:17] <mru> code! [00:29:18] <BBB> we should get you to do wmalossless [00:29:30] <BBB> Jumpyshoes: yeah, I thought a company was going to donate for wmalossless? [00:29:38] <Jumpyshoes> waiting on that [00:29:41] <BBB> Jumpyshoes: we can propose that the foundation helps [00:29:51] <BBB> Jumpyshoes: just start coding, we'll find at least some funding for it [00:29:59] <Jumpyshoes> huh, okay [00:30:00] <vcs> mmm, the bug went away with the version i got from GIT :) [00:30:23] <Jumpyshoes> i think the wmalossless header is an asf header [00:30:36] <mru> what a surprise [00:30:55] <Jumpyshoes> where is that coded in ffmpeg? [00:41:41] <CIA-15> ffmpeg: Baptiste Coudurier <baptiste.coudurier(a)gmail.com> master * rfffdee89cc ffmpeg/libavformat/movenc.c: [00:41:41] <CIA-15> ffmpeg: movenc: fix tkhd height for imx [00:41:41] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [00:41:41] <CIA-15> ffmpeg: Baptiste Coudurier <baptiste.coudurier(a)gmail.com> master * r99bbc781e9 ffmpeg/libavcodec/ (dnxhdenc.c dnxhdenc.h): [00:41:41] <CIA-15> ffmpeg: dnxhd: allow encoding with Avid Nitris compatibility. [00:41:42] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [00:41:43] <CIA-15> ffmpeg: Baptiste Coudurier <baptiste.coudurier(a)gmail.com> master * r06ed4873e6 ffmpeg/libavformat/movenc.c: [00:41:44] <CIA-15> ffmpeg: movenc: use correct tag for dvcpro hd [00:41:44] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [00:41:53] <BBB> Jumpyshoes: nowhere [00:42:00] <BBB> Jumpyshoes: but likely it's similar to the one in wmaprodec.c [00:42:27] <Jumpyshoes> hrm, okay [00:42:47] <Dark_Shikari> Hmm [00:42:54] <Dark_Shikari> is it possible to union an array element? [00:43:03] <mru> elaborate [00:43:13] <Dark_Shikari> e.g. vp56mv bmv[16]; [00:43:16] <Dark_Shikari> vp56mv mv; [00:43:19] <Dark_Shikari> make "mv" overlap bmv[15]. [00:43:49] <mru> why not just say bmv[15]? [00:43:49] <Dark_Shikari> ... I guess that's almost more Fortran-like than C-like. [00:45:14] <Kovensky> does the ordering of local variables affect how stack is allocated or does the compiler decides how to arrange it? [00:45:26] <mru> unspecified [00:45:45] <Kovensky> I also suppose that assuming the stack grows downwards is dragon territory [00:45:52] <mru> oh yes [00:46:01] <mru> there are 4 stack modes [00:46:16] <Dark_Shikari> I could make a define, I guess [00:46:24] <Dark_Shikari> just kinda ugly to use bmv[15] in 50 places [00:46:31] <mru> #define it [00:46:56] <Dark_Shikari> #define mv might break a lot of things. [00:46:59] <Dark_Shikari> even within a file [00:47:18] <mru> then don't [00:47:29] <Kovensky> use a pointer? [00:47:40] <mru> pointers are evil [00:47:57] <mru> well, not the pointers as such [00:48:03] <mru> but what they might or might not alias [00:48:05] <Kovensky> they do their job though [00:48:05] <Kovensky> =p [00:49:37] <Kovensky> even if you have to just use *mv everywhere, it's still better than bmv[15], although not as cute as just mv [00:49:50] <Dark_Shikari> pointers hurt performance [00:49:51] <mru> that's not the issue [00:50:01] <mru> the compiler can't know it's the same as bmv[15] anymore [00:50:16] <mru> and will assume it migth be just about anything [00:50:55] <Kovensky> if it's a local variable, I'm pretty sure good analysis would be able to tell whether the point is modified or not [00:50:56] <mru> you can often gain a lot of performance by pulling struct fields into local variables, doing stuff, and writing them back [00:51:28] <Kovensky> pointer* [00:51:43] <mru> not the pointer, what it points to [00:52:00] <Kovensky> ic [00:52:03] <Kovensky> damn multithreading! [00:52:04] <mru> take two pointers, int *a, *b; [00:52:06] <mru> *a = 0; [00:52:10] <mru> what is *b now? [00:52:16] <mru> you don't know [00:52:27] <mru> unless you can prove that a != b [00:52:32] <mru> and more often than not, you can't [00:52:47] <mru> multithreading has nothing to do with it [00:53:21] <mru> this is where the restrict keyword can be used [00:54:11] <mru> it's a promise that for the lifetime of the restrict-qualified pointer, every access to whatever it points to will be done through a pointer derived from said pointer [00:55:12] <mru> and that's fine, ignoring for the moment that gcc ignores it [00:55:22] <mru> but it doesn't help in the opposite situation [00:55:47] <mru> where you have a pointer you _know_ is an alias for something but you can't tell the compiler [00:56:11] <mru> usually you can of course simply use that other name directly [00:57:07] <Kovensky> 21:52.30 mru: unless you can prove that a != b <-- that's a case of uninitialized pointer access though [00:57:49] <Kovensky> if you have { int *a, b; a = b; *a = 0; }, you can be sure that *a == b [00:59:31] <mru> void foo(int *a, int *b) { *a = 0; *b = 1; return *a; } [00:59:37] <mru> what does that function return? [01:00:40] <peloverde_at_wor> trick question, it's void [01:01:32] <pasteeater> Sean_McG: your ML replies seem to be orphaned for me at least. no "References" header? [01:01:35] <mru> s/void/int/ [01:02:12] <mru> pasteeater: blame the crackberry [01:02:15] <Sean_McG> pasteeater: probably my BlackBerry not doing that [01:02:36] <Sean_McG> unless you mean the code, which I used 'git send-email' [01:03:11] <pasteeater> not the code [01:03:24] <Sean_McG> OK it's the BB then [01:03:51] <Kovensky> 21:59.37 mru: what does that function return? <-- ENOCLUE [01:04:00] <Sean_McG> and I don't include the original text otherwise Diego chews me out for top-posting [01:05:25] <mru> Sean_McG: http://cache.gawkerassets.com/assets/images/4/2010/09/500x_angrybirds.jpg [01:05:48] <Sean_McG> mru: hahahah [01:06:02] <mru> Kovensky: with the return type corrected, the answer depends on the values of the pointers passed in [01:06:39] <Kovensky> yes, which is an unpredictable case since it depends on exernal data [01:06:42] <Kovensky> external* [01:07:23] <peloverde_at_wor> suppose they are marked restrict? [01:07:40] * Kovensky never dealt with restrict [01:08:01] * Kovensky reminds himself of his 11yo self which took weeks until understanding what static meant [01:08:49] <mru> static is a storage class specifier [01:09:04] <Kovensky> I know [01:09:10] <Kovensky> it modifies a declaration tough :> [01:09:16] <Kovensky> which restrict also does :E [01:11:27] <mru> hmm, clang does something with the restrict keyword [01:23:57] <Dark_Shikari> Hmm, I can get vp8macroblock down to 68 bytes [01:24:00] <Dark_Shikari> 64 bytes would be awesome [01:24:47] <mru> what have you got so far? [01:25:17] <Dark_Shikari> ? [01:25:43] <mru> your statement implies you've reduced it from what it is currently [01:25:47] <Dark_Shikari> 72 -> 68 [01:25:49] <Dark_Shikari> the MVs are 64 bytes [01:25:58] <Dark_Shikari> skip/mode/refframe/partitioning are 4 [01:26:11] <Dark_Shikari> splitting the latter out would get the mvs alone into 64 bytes, but you'd have to keep track of two separate structs [01:26:24] <Dark_Shikari> and I don't think we can get mvs below 4 bytes each [01:26:36] <Yuvi> mru: yep, I'll be around [01:26:40] <Dark_Shikari> Guess I probably can't. [01:26:52] <mru> I suppose using bit fields of <8 bits for some of those others could reduce it a little [01:26:59] <mru> actually no [01:27:03] <Dark_Shikari> wonder if it's worth doing a totally-confusing reordering of the mvs to save 4 bytes from 72 -> 68 [01:27:06] <Dark_Shikari> might save a few instructions too [01:27:07] <mru> vp56mv has align(4) [01:27:35] <Dark_Shikari> the core idea: the last MV in the macroblock is always [15] [01:27:39] <Dark_Shikari> so 16x16: [15] [01:27:46] <Dark_Shikari> 16x8: [7], [15] [01:27:48] <Dark_Shikari> 8x16: [13], [15] [01:27:50] <mru> Yuvi: cool, I'll let you know if I decide to go [01:27:53] <Dark_Shikari> 8x8: [5], [7], [13], [15] [01:27:57] <Dark_Shikari> 4x4: [0]...[15] [01:28:12] <Dark_Shikari> currently it's [0], [0][1], [0][1], [0][1][2][3], and [0]..[15]. [01:29:00] <mru> depends on where I can find to stay cheaply too [01:29:11] <Dark_Shikari> where are you heading? [01:29:23] <mru> bay area, mid april [01:29:32] <Dark_Shikari> what's there? [01:29:46] <mru> bunch of ffdevs and a linux conference [01:30:00] <Dark_Shikari> Is this that google thing? [01:30:05] <mru> no [01:30:06] <Dark_Shikari> Could we get that scheduled then? `-` [01:30:17] <mru> what google thing? [01:30:32] <Dark_Shikari> Google offering to host an ffmpegdev party [01:30:35] <Dark_Shikari> all expenses paid [01:31:05] <Jumpyshoes> woah what [01:31:28] <mru> Jumpyshoes: just another day in the glamorous life of the multimedia hacker [01:32:40] <Jumpyshoes> well i get to go to google in may which is nice [01:32:53] <Jumpyshoes> i haven't been to san francisco before [01:32:58] <mru> damn, I've run out of compilers to break again [01:33:07] <Dark_Shikari> clang is probably still buggy as fuck [01:33:17] <mru> of course [01:33:28] <mru> I filed a bunch of bug reports earlier this week [01:33:38] <mru> no response yet [01:33:47] <mru> waiting for fixes on armcc [01:33:57] <mru> got open bugs on gcc [01:34:57] <mru> fixed a few things in path64 mips backend [01:35:09] <Jumpyshoes> i thought gcc never did anything [01:35:19] <mru> there was a hilarious bug there [01:35:35] <mru> they used %d instead of %x to print some alignment values [01:35:40] <Jumpyshoes> wat [01:35:40] <mru> guess what happened [01:36:06] <mru> shit got misaligned and crashed of course [01:36:14] <Jumpyshoes> rofl [01:36:30] <mru> unfortunately I don't have hardware to test it properly [01:37:36] <Jumpyshoes> gcc is a wonderful compiler ;) [01:37:41] <mru> waiting for a login on a supercomputer for that [01:37:45] <mru> Jumpyshoes: this wasn't gcc [01:37:49] <mru> it was pathscale [01:37:54] <Jumpyshoes> oh [01:38:23] <Jumpyshoes> that's a really stupid bug [01:38:29] <Jumpyshoes> on the devs part [01:38:40] <mru> simple typo [01:38:44] <Sean_McG> I've been helping with gcc 4.6 on Solaris... it's not considered one of their "primary platforms" (presumably because it's not FOSS), but they've been really good about responding to the Bugzillas I've filed [01:38:44] <mru> could happen to anyone [01:39:08] <Sean_McG> we have *1* P1 bug left before release of 4.6, so hopefully that will be soon [01:39:33] <mru> the rest have been downgraded so as not to taint the release [01:39:38] <mru> that's what they usually do [01:40:01] <Sean_McG> I'd have to look at the history, but there are some P1s that aren't really P1s [01:40:18] <mru> and P2s that are really P1s [01:40:47] <mru> gcc is a lottery [01:40:51] <Sean_McG> anyways I'm not gonna argue... compilers are complicated [01:41:02] <mru> if you get the attention of the right dev things move along [01:41:12] <mru> otherwise they can sit ignored or even rejected for years [01:41:36] <Sean_McG> I think any open source project can have that problem [01:41:53] <mru> most gcc devs are paid full time [01:41:55] <mru> to work on gcc [01:42:02] <Sean_McG> fair point [01:42:17] <mru> it's their job, the "but it's open source" excuse doesn't work for them [01:42:42] <mru> so far, arm have fixed all bugs I've reported by the next release [01:43:03] <mru> releases happen every few months [01:48:41] <Compn> rukhsana : btw have you worked with compression or codecs or anything similar before ? jpeg2000 is wavelet and one of the harder things to master... [01:49:28] * Compn wonders how big jp2k spec is [01:50:40] <Yuvi> 190 pages, plus 332 pages of extensions [01:50:49] <Compn> how big is h264 spec ? [01:50:55] <Dark_Shikari> ~800, but that's including SVC/MVC [01:51:02] <Dark_Shikari> AVC-only is about 300 [01:51:09] <Compn> ehe [01:51:12] <Dark_Shikari> the actual substantive part is about 150 [01:53:02] <rukhsana> sorry Compn [01:53:08] <rukhsana> i was away [01:53:30] <rukhsana> i used ffmpeg a lot in my research [01:53:45] <rukhsana> especially i used mpeg4 encoded video [01:54:15] <rukhsana> i am reading the code too [01:55:17] <Compn> ok, no problem. just thought i'd warn you :) [01:55:51] <Compn> kshishkov : what are you up to now? still reverse engineering ? [01:56:10] <rukhsana> what exactly the problem in current JPEG 2000 in ffmpeg? [01:56:27] <Compn> the decoder is incomplete [01:56:35] <rukhsana> could you please give little bit idea about it? [01:56:51] <rukhsana> so, encoder is complete? [01:56:51] <Compn> and possibly has some bugs [01:57:07] <Compn> i dont think there is encoder at all [01:59:30] <rukhsana> i see in the code, there is a encoder [02:00:11] <rukhsana> and there is a decoder, however probably incomplete [02:00:11] <Compn> ah i havent looked at it [02:00:44] <rukhsana> ok [02:02:14] <rukhsana> do you suggest me to work on any other stuff except jpeg 2000 as everyone is saying its hard to master [02:02:53] <rukhsana> since i used ffmpeg before, i am a little bit familiar with it [02:17:34] <hyc> can someone explain to me why ffmpeg can rewrap an h264 video from MP4 to MKV format, but coming back again it fails due to out of order timestamps? [02:18:09] <kierank> hyc: because mkv doesn't have dts and ffmpeg has to guess them [02:18:13] <hyc> if I extract the video out to raw h264 file, I can remux it as mp4 then [02:18:26] <kierank> and at the moment it guesses them incorrectly [02:19:26] <hyc> interesting [02:20:13] <hyc> so why does going out to raw h264 and coming back work? is someone else doing a better job of guessing? [02:23:48] <Compn> hyc : is there an option to disable dts whatnot in the muxer ? [02:24:07] <hyc> there may be but I didn't specify anything [02:24:21] <Compn> i think baptiste is mp4 maintainer [02:24:28] <Compn> might send him an email with a sample command line [02:24:41] <Compn> e.g. ffmpeg -i http://samples.mplayerhq.hu/mkv/blah.mkv out.mp4 [02:25:03] <Compn> of course, probably not a problem with mp4 muxer but somewhere else [02:25:19] <hyc> yeah, I'm guessing mkv demux [02:25:42] <hyc> but I don't understand what the actual problem is, since the demux output obviously decodes and plays [02:25:44] <Compn> non monotone timestamp error or what ? [02:25:50] <hyc> yes, exactly [02:26:01] <Compn> and just vcodec copy ? [02:26:06] <hyc> yep [02:27:09] <Compn> ah yes [02:27:56] <Compn> http://roundup.ffmpeg.org/issue807 [02:27:59] <Compn> theres the bug [02:28:43] <Compn> and some patches [02:28:43] <Compn> :) [02:38:46] <hyc> thx [02:41:06] <hyc> I had already found one of those patches, from roozhou. applied to current git, didn't fix the error [02:41:19] <hyc> but I hadn't read this bug yet. will see if it sheds any more light [02:44:55] <hyc> and currently if I try: ffmpeg -i foo.mkv -vcodec copy -acodec copy /tmp/bar.mkv it fails with [02:45:09] <hyc> [matroska @ 0x178a160] Application provided invalid, non monotonically increasing dts to muxer in stream 1: 30 >= 30 [02:47:38] <Compn> yeah, i can see this is an annoying bug ;\ [02:49:07] <hyc> changing the >= to > in libavformat/utils.c shuts up the error [02:50:02] <hyc> and the resulting file plays fine [02:50:24] <Compn> in a non-ffmpeg based player ? [02:50:30] <hyc> hmmmmmmm [02:50:33] <Compn> thats always the trick [02:50:39] <hyc> dunno if I have such a thing [02:50:41] <Compn> stupid buggy lavf will play stupid buggy lavf files :P [02:50:49] <Compn> well... quicktime if you are lucky [02:51:17] <hyc> flash too I suppose [02:51:21] <Compn> maybe latest microsoft product and flash yep [02:51:31] <Compn> silverlight does mp4/h264 [02:51:33] <Compn> iirc [02:51:45] <hyc> hmmm, yeah, dunno what silverlight is doing [02:52:07] <Compn> a thousand mp4 files per video because mp4 cannot be streamed live ;p [02:52:11] <Compn> ehe [02:52:26] <hyc> lol. yeah, saw that. so ridiculous [02:52:46] <hyc> clearly the folks who created the mp4 format overlooked something obvious :P [02:53:27] <hyc> much as I think rtmp is a miserable protocol, at least it supports live streaming with flv [02:54:24] <hyc> btw http://www.metacafe.com/channels/highlandsun/ [02:54:40] <hyc> I uploaded videos from a concert my band played Feb 13 [02:55:13] <hyc> recorded in AVCHD, dropped down to 720x480 with ffmpeg [02:55:30] <hyc> watermark added using movie filter [02:55:38] <hyc> which hopefully will go into the main repo soon [02:59:19] <kierank> hyc: well mp4 was meant to be a storage format [03:00:11] <kierank> probably mpeg created a streaming system that nobody uses [03:00:40] <kierank> and to play devils advocate a bit I don't think they anticipated the whole http progressive download thing at all [03:01:03] <ohsix> would be quite a trick if they had [03:01:29] <Compn> kierank : mpegts is i guess the streaming solution [03:01:39] <Compn> thats what apple uses now [03:02:49] <Compn> hyc : thats a lot of kilts :p [03:02:50] <Compn> hehe [03:03:41] <Compn> got a downloadable album or should i just rip audio out of these vids :P [03:04:07] <Compn> my non internet-savvy dad enjoys listening to new music [03:09:05] <kierank> Compn: yeah [03:09:21] * kierank watches hyc's band [03:10:35] <hyc> lol I need to go get another kilt [03:11:13] * Compn should purchase one as well [03:11:47] <Compn> wonder if i should look up my colors or just go camo [03:11:54] <Compn> the 'cargo kilt' maybe [03:12:39] <gnafu> I remember Pat on The Screensavers would always talk up Utilikilts back in the day. [03:12:44] <gnafu> Seems so long ago now... [03:12:46] <Compn> yes that guy [03:12:46] <hyc> yeah, I'm not so keen on the camo thing. but don't have a clan to look up ;) [03:12:50] <Compn> thats what i'm talkin about [03:15:13] <Compn> metacafe keeps refreshing off your page tho, the next mvid in the lineup was a ceelo song hehe [03:15:34] <hyc> bizarre :P [03:15:35] <gnafu> Compn: Which one? [03:15:43] <Compn> ceelo 'its ok' [03:15:55] <gnafu> Fun; I just heard that for the first time the other day. [03:15:56] <hyc> Compn: have it all on youtube too, I just didn't have the watermarks on those [03:16:10] <hyc> takes friggin hours to upload this stuff on crap cable [03:16:17] <Compn> watermark is unobtrusive which is nice [03:17:19] <hyc> yeah, did several runs playing with transparency in gimp before I settled on that [03:18:13] <Compn> i dont know when avfilter is going to be merged [03:18:17] <Compn> stefano would know [03:18:32] <Compn> or is it already merged, but some filters arent ? [03:18:33] <Compn> hmm [03:18:41] <hyc> avfilter is there, movie is not [03:18:45] <Compn> ah [03:19:06] <hyc> which is even more confusing because movie is in the avfilter doc on ffmpeg.org [03:19:33] <Compn> hehe [03:52:02] <Sean_McG> has there ever been any thought into localizing error messages in ffmpeg? using libintl or summat? [03:52:22] <Compn> have you seen mplayer's localization ? [03:52:31] <Sean_McG> no [03:52:52] <Compn> not sure if its better / worse than libintl [03:53:02] <Compn> but something to look at anyhow [03:53:12] <mru> needless complexity [03:53:37] <Compn> also, there was a limitation that only one language could be compiled at any time, but i think uau might have been working on it to support all langs in one binary [03:53:47] <Sean_McG> I'm an English speaker myself, but whatever [03:54:11] <mru> there's not much textual interaction other command line flags anyway [03:54:16] <mru> and you don't want to translate those [03:54:40] <Compn> i think mplayers system isnt that complex :P [03:54:54] <mru> feel free to translate the documentation though [03:54:59] <Sean_McG> that's fine if you don't want it, I was just curious [03:55:10] <mru> that's my personal opinion [03:55:23] <mru> translations take a lot of effort to maintain [03:55:34] <Sean_McG> this is true [03:56:07] <Compn> somehow mplayer's translations are up to date :P [03:56:39] <mru> maybe that's because mplayer hasn't been very actively developed for some years [03:56:57] <mru> and it doesn't contain a great deal of text either [03:57:01] <Sean_McG> it does kinda take someone willing to "step up to the plate" for each localization, and if that's too much to ask then yeah I guess there's no point [03:57:23] <mru> someone has to step up and stay up forever [03:57:33] <mru> it's not a one-off task [03:57:43] <Sean_McG> that's what I meant [03:57:51] <Compn> thats like saying someone has to maintain the same code forever [03:57:59] <Compn> but whatever, night [03:58:00] <mru> no [03:58:04] <Sean_McG> sleep well [03:58:26] <mru> if the code is changed at all, and chances are it will, the translations will need updating [03:58:44] <mru> but it's unlikely that every code contributor is able to update the translations for the strings he affects [03:58:59] <Compn> its the exact same as what we have now [03:59:08] <mru> no it's not [03:59:29] <mru> as it is now, if you change the code you're done [03:59:38] <mru> you don't need to _also_ fix 200 translations [03:59:40] <Compn> just replace translation with x86/asm/ssse3/ppc/64bit/bsd [04:00:07] <mru> stop trolling [04:00:13] <Compn> if a translation gets changed it reverts back to the english [04:00:23] <Sean_McG> OK OK, forget I brought it up [04:00:26] <Compn> lol [04:00:35] <ohsix> _() for strings you'd want to translate ftw [04:01:02] <mru> blatantly ignoring that _ is a reserved identifier at file scope [04:01:37] <ohsix> o noes [04:01:46] <Compn> the only thing bad i'd say is that it makes debugging other languages somewhat harder , like 1% harder maybe :P [04:02:14] <mru> it's a pile of maintenance burden for little or no benefit [04:02:31] <mru> the strings people actually use most of the time, the command line flags, won't be translated anyway [04:02:34] <Compn> i havent seen many requests for ffmpeg translations [04:02:53] <Compn> of course i havent been looking specifically for it [04:03:04] <mru> for a gui app it's an entirely different matter [04:03:47] <mru> the vast majority of strings in ffmpeg are either options or error messages [04:04:00] <mru> the former should not be translated and the latter should rarely be seen [04:04:30] <mru> and most people understand a bit of english [04:05:17] <ohsix> and if they don't fuck 'em [06:28:12] <kierank> oh god, mxf over rtp [06:35:04] <Dark_Shikari> !!!!! [06:35:08] <Dark_Shikari> mxf over rtp jesus fucking christ [06:35:13] <Dark_Shikari> what next, ogg over avi over mxf over rtp? [06:40:31] <kierank> what's worse is that jpeg2000 is being put in those mxf files [06:47:50] <peloverde> ugh, finally home from work [06:54:21] <Dark_Shikari> Hmm, I need to write a regular expression to cover multi-line comments [06:54:25] <Dark_Shikari> e.g. /* ... */ [06:54:43] <Dark_Shikari> so I need some way to have an expression that matches "anything that doesn't contain */" to cover the middle. [06:54:49] <Dark_Shikari> how do I do that? I only know how to do that for single characters. [06:54:53] <Dark_Shikari> i.e. "not *" [06:54:57] <Dark_Shikari> not "not */" [06:55:10] <pengvado> I can do that in perl. dunno about posix regex. [06:55:23] <Dark_Shikari> this is for lex [06:55:27] <Dark_Shikari> dunno what features it does [06:55:55] <Dark_Shikari> how would one do it in perl? [06:56:23] <Dark_Shikari> ... though it's alex, not lex. [06:56:43] <pengvado> the simple way is /\*.*?\*/ [06:57:44] <pengvado> however, that can fail if it's part of a larger regex, since *? prefers the smallest match possible but other constraints can make it take a larger one [06:58:49] <pengvado> the robust way is /\*((?!\*/).)*\*/ [06:59:07] <Dark_Shikari> hmm, the ? parse-errors. [07:30:57] <Dark_Shikari> Hmmm. If jb_CeBIT doesn't apply for GSOC with videolan, can x264 sneak in through ffmpeg this time around? [07:31:01] <Dark_Shikari> I assume ffmpeg is applying. [07:31:51] <kierank> in b4 each ffmpeg fork applying for gsoc [07:33:12] * elenril thinks there should be a gsoc project to merge x264 into ffmpeg [07:34:01] <kierank> gl with that elenril [07:39:00] <cartman> moin [07:46:36] <irock> BBB, Dark_Shikari, ... : pong [07:48:26] <irock> I've got 8-10 bit working in the same build [07:49:33] <irock> what I need to do is basically to organize the code into good patches [07:52:00] <irock> then maybe a few review rounds ;) [07:53:06] <KotH> ohayou gozaimasu [07:53:11] <spaam> hey KotH :DD [07:53:12] <cartman> moin KotH [07:53:16] <cartman> irock: awesomeness [07:58:02] <spaam> cartman: do you think we will see it before summer ? :D [08:08:02] <wbs> anyone with push access caring to push the aviobuf-fill_buffer() patch I sent a few days ago, which was ok'd? [08:08:21] <Dark_Shikari> anyone ever going to fix threads auto with ffmpeg? [08:08:23] <Dark_Shikari> It's still broken [08:08:44] <Dark_Shikari> if nobody fixes it within a week, I'm going to rip out threads support from libx264.c [08:08:57] <Dark_Shikari> also, a user is reporting -threads 32 resulting in 6 threads [08:08:59] <Dark_Shikari> astrange: this is your fault [08:47:22] <uau> Compn: i didn't make mplayer's old translation system work with multiple languages [08:47:34] <uau> rather i ripped out the old system and replaced it with a libintl-based one [08:47:39] <uau> the old system was just horrible crap [08:48:49] <siretart> who is actually suggesting to localize ffmpeg?! [08:49:46] <av500> locals? [08:50:00] <siretart> are they? [citiation needed] [08:50:20] <kierank> pfft everyone speaks english [08:50:21] <kierank> it's fine [08:50:30] <thresh> orly [08:50:39] <wbs> nobody really is suggesting it, Sean_McG asked curiously about it but retracted his question ;P [08:50:42] <av500> localized variable names please [08:50:55] <wbs> av500: especially with hungarian notation [08:51:03] <kierank> I don't see the need for anything like unicode [08:51:08] <Dark_Shikari> for( int わたし=0; わたし<4; わたし++ ) [08:51:15] * Dark_Shikari hides. [08:51:16] <kierank> people in #x264 for example should use a proper language [08:51:24] <av500> s->opaque_réorganisés [08:51:35] <kierank> silly non-english laguages right there with their square boxes [08:51:41] <Dark_Shikari> use a proper font bozo [08:51:48] <kierank> nah, who needs foreign languages [08:51:49] <Dark_Shikari> UTF-8 is the future [08:51:49] <av500> what is a font bozo? [08:51:54] <kierank> pfft [08:51:56] <kierank> english is the future [08:52:07] <thresh> chinese looks more promising [08:52:09] <thresh> or indian [08:52:20] <elenril> more like utf-8 is the present [08:52:20] <kierank> thresh: a lot of indian/chinese speak english [08:52:21] <Dark_Shikari> Ｌｅｔ’ｓａｌｌｕｓｅｆｕｌｌ－ｗｉｄｔｈＥｎｇｌｉｓｈｆｏｎｔｓｔｈｅｎ． [08:52:33] <kierank> boo hoo i can't see your square text [08:52:39] <Dark_Shikari> It's english though! [08:52:56] <iive> actually all indian speak english. [08:53:07] <Dark_Shikari> iive: I have a doubt about this. [08:53:10] * Dark_Shikari ducks. [08:53:10] <microchip_> rupee rupee? [08:53:17] <av500> Dark_Shikari: lol, google translate detects you full width as japanese :) [08:53:17] <Dark_Shikari> Please send me teh codez. [08:53:46] <elenril> >full width [08:53:46] <Dark_Shikari> "I have a doubt about the codes. Can someone please send me the codes." [08:53:50] <elenril> >weaboo detected [08:53:56] <kierank> Dark_Shikari: it's not "Please", it's "plz" [08:53:58] <iive> Dark_Shikari: they have over 48 local dialects, and they were english colony. [08:53:58] <Dark_Shikari> 「weeaboo」? [08:54:29] <elenril> don't they have a special rune for question mark? [08:54:36] <av500> ¿ [08:54:50] <Dark_Shikari> ？ [08:54:54] <thresh> that's a spanish rune [08:55:17] <thresh> i'm actually puzzled why wouldnt they just use a proper question mark [08:55:20] <av500> ¡ [08:55:25] <Dark_Shikari> One goes at the start of the sentence [08:55:27] <Dark_Shikari> one goes at the end [08:55:31] <thresh> iKnow [08:55:32] <av500> !yeah¡ [08:55:36] <Dark_Shikari> ¿Why? [08:55:45] <av500> ¡because! [08:56:00] <kierank> hmmm those spanish characters are not square boxes [08:56:08] * kierank goes to delete all i8n fonts [08:56:08] <Dark_Shikari> yes, because the problem is your font [08:56:13] * Dark_Shikari punts kierank [08:56:29] <av500> kierank: your gaelic font is broken [08:56:40] <av500> or garlic? [09:14:02] <peloverde> the only non-ascii codepoint that's worth while is U+0CA0 [09:15:16] <peloverde> (i kid) [09:59:58] <lu_zero> good morning [10:00:04] <lu_zero> wbs: let me pick it up [10:16:48] <CIA-15> ffmpeg: Martin Storsjö <martin(a)martin.st> master * re360ada2d1 ffmpeg/libavformat/aviobuf.c: (log message trimmed) [10:16:48] <CIA-15> ffmpeg: aviobuf: Write new data at s->buf_end in fill_buffer [10:16:48] <CIA-15> ffmpeg: In most cases, s->buf_ptr will be equal to s->buf_end when [10:16:48] <CIA-15> ffmpeg: fill_buffer is called, but this may not always be the case, if [10:16:48] <CIA-15> ffmpeg: we're seeking forward by reading (permitted by the short seek [10:16:49] <CIA-15> ffmpeg: threshold). [10:16:50] <CIA-15> ffmpeg: If fill_buffer is writing to s->buf_ptr instead of s->buf_end (when [10:17:06] <wbs> lu_zero: thanks :-) [10:19:11] <lu_zero> sorry for the delay =P [10:20:00] <wbs> care to push the av_pkt_dump patches from last week, too? [10:20:07] <lu_zero> let me check it [10:20:28] <lu_zero> btw I'm about to send some patches I prepared with diego [10:40:13] <CIA-15> ffmpeg: Martin Storsjö <martin(a)martin.st> master * r863c471638 ffmpeg/libavformat/ (avformat.h utils.c): [10:40:14] <CIA-15> ffmpeg: libavformat: Add av_pkt_dump{, _log}2, taking an AVStream parameter [10:40:14] <CIA-15> ffmpeg: This removes a fixme issue, by allowing the av_pkt_dump functions [10:40:14] <CIA-15> ffmpeg: to use the correct time base. [10:40:14] <CIA-15> ffmpeg: Signed-off-by: Luca Barbato <lu_zero(a)gentoo.org> [10:40:26] <CIA-15> ffmpeg: Martin Storsjö <martin(a)martin.st> master * r5e33e7bdac ffmpeg/ffmpeg.c: [10:40:26] <CIA-15> ffmpeg: ffmpeg: Use av_pkt_dump_log2 [10:40:26] <CIA-15> ffmpeg: This makes dumped packet timestamps proper for streams with [10:40:26] <CIA-15> ffmpeg: timebases other than AV_TIME_BASE. [10:40:27] <CIA-15> ffmpeg: Signed-off-by: Luca Barbato <lu_zero(a)gentoo.org> [10:50:14] <ffmpeg> how do i enable the tprintf functions in ffmpeg while debugging? [10:50:37] <ffmpeg> is there a specific option i have to set during the configure stage? [10:51:13] <kshishkov> go to channel named after you [10:53:14] <av500> or just use av_log [10:53:51] <ffmpeg> i want to see the output of the calls to the tprintf function that are already in the source code [10:56:21] <kshishkov> uncomment #define TRACE in libavcodec/get_bits.h and rebuild FFmpeg [11:17:45] <ffmpeg> -loglevel debug option does not seem to work, do i have to set something else? [11:44:42] <DonDiego> [OFFTOPIC]: has anybody had issues with disappearing mouse cursors under X? this is driving me nuts here at work... [11:44:53] <kshishkov> you? [11:45:21] <DonDiego> +else [11:45:24] * elenril mumbles something about unhelpful commie trolls [11:46:08] <kshishkov> DonDiego: like https://bugs.launchpad.net/xorg-server/+bug/63905 ? [11:47:11] <DonDiego> not sure if this is related, hmmm [11:47:43] <kshishkov> have you tried "swcursor" option as recommended there? [11:48:23] <DonDiego> i will in a moment... [11:48:40] <DonDiego> i get the problem intermittently, not just after X restarts.. [11:49:23] <elenril> DonDiego: try software cursor? [11:49:46] <DonDiego> on it, i need to reboot :-( [11:53:30] <iive> is that on mac? [11:54:39] <DonDiego> no, linux machine, i have two sitting under my desk here [11:54:52] <av500> running? [11:54:58] <kshishkov> av500: sitting [11:55:12] <av500> sitting what distribution? [11:55:39] <kshishkov> probably it has something to do with video card designer [11:56:17] <iive> i mean, mac hardware. what is the video card? [11:56:25] <cartman> av500: I got a report from a user that February firmware update for A101 did not fix the buggy DPI report problem [12:06:20] <av500> cartman: i saw the fix in our svn [12:06:26] <av500> i dunno to what release it maps [12:07:12] <DonDiego> running sw cursor now - hopefully this will help... [12:08:36] <cartman> av500: hmmmpf ok [12:42:53] <ffmpeg> how can i set the avctx->debug flag to 1 via ffmpeg command line parameters? [12:49:14] <ffmpeg> i m trying to print out the picture info using the -debug pict flag parameter [12:49:32] <mru> -loglevel debug [12:50:19] <ffmpeg> i do that too [12:51:03] <ffmpeg> but when i debug in h264.c for example i see FF_DEBUG_PICT_INFO set (as expected) but s->avctx->debug unset [13:01:02] <kierank> so if I need to access raw frame data from get_buffer in another thread, how do i make sure ffmpeg isn't reading the same data (e.g. as a reference frame) [13:05:53] <mru> access for read or write? [13:06:09] <mru> it's fine to have several readers [13:06:09] <kierank> for read [13:08:13] <kierank> that makes sense [13:14:24] <mru> once ffmpeg calls release_buffer it's up to you to not return the same buffer in get_buffer until you're done with it [13:17:56] <mru> morning DonDiego [13:18:40] <kshishkov> he was here today (unlike his mouse cursor on X11) [13:19:19] <mru> indeed, he left only a while ago [13:19:52] <mru> still, I hadn't greeted him yet today [13:22:26] <DonDiego> moin :) [13:26:53] <pross-au> Q: anyone working on PIX_FMT_BGR48LE/BE? [13:27:40] <Tjoppen> pross-au: a while back [13:27:52] <pross-au> Ta [13:28:59] <pross-au> can u post a wip patch [13:30:15] <Tjoppen> oh, wait. you said BGR, not RGB. I thought you meant whether anyone had looked at the existing stuff [13:30:38] <pross-au> B-G-R [13:30:47] <pross-au> PhantomCINE uses it [13:30:49] <Tjoppen> sry, nope [13:30:55] <pross-au> we already have RGB48LE/BE [13:30:57] <pross-au> Cool thanks [13:31:58] <Tjoppen> I presume you mean support in libswscale? [13:32:32] <Tjoppen> just adding it would be trivial, but sort of useless if you want to be able to scale it to something displayable :) [13:33:05] <kshishkov> pross-au: it's easy, mate. Just swap order of components [13:45:26] <pross-au> sure its easy, i dont want to redo work already done [13:45:38] <pross-au> that okay, i can swap Red and Blu [13:51:28] <cartman> just had a farewell party in my name \o/ [13:51:58] <DonDiego> this reminds me: my last birthday was exactly one year ago... [13:52:08] <av500> cartman: do you also have concrete shoes on your feet? [13:52:23] <av500> DonDiego: http://2.bp.blogspot.com/_2rl9OV3Auts/TOpwmT9ZaQI/AAAAAAAAKEI/11oBtWePFdg/s… [13:52:24] <kshishkov> cartman: "we are glad to get rid of you"-type? [13:52:38] <cartman> kshishkov: be back soon type :) [13:52:52] <kierank> cartman: what do non-alcoholic leaving parties involve? [13:53:03] <av500> sweet tea [13:53:07] <cartman> kierank: congrats. and such :) [13:53:11] <kshishkov> ayran [13:53:25] <cartman> cola of course [13:53:43] <av500> americas black gold [13:53:58] <cartman> av500: call the border police for next week :P [13:54:07] <av500> cartman: they are informded [13:54:15] <cartman> /o\ [13:54:17] <kierank> cartman: where are you going? [13:54:22] <cartman> kierank: Germany! [13:54:29] <av500> gastarbeiter! [13:54:31] <DonDiego> saste: i reviewed the -map patch, but possibly not the latest version, i hope the comments apply nonetheless [13:54:35] <kshishkov> cartman: I thought it would be Bavaria instead [13:54:35] <cartman> Ich möhte delicious köfte! [13:54:59] <cartman> kshishkov: yeah :P [13:55:00] <kshishkov> av500: don't call him that, it's my profession [13:55:22] <cartman> I promised to go back to home in 4 years [13:55:28] <cartman> I'll keep my promise :P [13:55:32] <av500> promised who? [13:55:37] <av500> your pkk buddies? [13:55:40] <cartman> av500: myself :P [13:55:49] <av500> gee, ffmpeg left [13:55:56] <cartman> lol [13:55:57] <kierank> av500: that guy's a bit of a weird character [13:55:59] <kshishkov> cartman: that's approved by av500 [13:56:09] <kierank> he sits in #x264dev with a username representing the problem he has [13:56:12] <kierank> talks to nobodoy [13:56:14] <cartman> :D [13:56:16] <av500> kshishkov: i dont mind another döner vendor [13:56:18] <kierank> except PMs people [13:56:36] <cartman> kierank: /nick x264 ? [13:56:45] <kierank> cartman: he uses the nick transcode [13:56:49] <cartman> :D [13:56:49] <kierank> because he has problems transcoding [13:56:52] * thresh . o O ( /nick gottagetsomesleep ) [13:56:52] <cartman> lol [13:57:02] <cartman> /nick av500 [13:57:05] <cartman> bah already taken [13:57:30] <kshishkov> kierank: "with a username representing the problem he has" <- FFmpeg is a problem!? [13:57:46] <cartman> av500: don't worry my contract is indefinite :P [13:57:47] <kierank> of course [13:57:49] <kshishkov> av500: I think two or three döner vendors should be enough for you [13:58:03] <av500> 2-3 million you mean [13:58:15] * cartman will eat köfte [13:59:03] <kshishkov> av500: no, personally for you [14:00:56] * kierank forgot about the turkish people in germany cliche [14:01:39] <cartman> kierank: never gets old [14:02:04] <kshishkov> kierank: well, at laest they (along with Chinese and Indians) make Real British Food [14:02:18] <kierank> Real British Food = NULL [14:02:32] <av500> Weetabix [14:02:43] <kierank> marmite [14:02:49] <kierank> and crumpets [14:02:49] <av500> scones and clotted cream [14:02:51] <cartman> köfte [14:03:46] <kshishkov> cartman: they are too ashamed to admit they build empire where Sun never sets off only to get better food than at the Isle [14:09:18] <CIA-15> ffmpeg: Baptiste Coudurier <baptiste.coudurier(a)gmail.com> master * rfb98507126 ffmpeg/libavcodec/vc1dec.c: [14:09:18] <CIA-15> ffmpeg: vc1: fix decoding when end sequence is present [14:09:18] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [14:09:32] <CIA-15> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * rff1efc524c ffmpeg/libavcodec/pthread.c: [14:09:32] <CIA-15> ffmpeg: threads: allow thread count of zero [14:09:32] <CIA-15> ffmpeg: This moves setting the thread count to a minimum of 1 to [14:09:32] <CIA-15> ffmpeg: frame_thread_init(), allowing a value of zero to propagate [14:09:32] <CIA-15> ffmpeg: through to the codec if frame threading is not used. This [14:09:33] <CIA-15> ffmpeg: makes auto-threads work in libx264. [14:09:34] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [14:37:36] * pross-au not happy [14:38:05] <kshishkov> it happens [14:38:29] <pross-au> wtv changes [14:38:39] <cartman> what thee [14:38:56] <kshishkov> is it M$ binary hierarchically-structured format? [15:14:16] <siretart> greetings from TI @embedded-world [15:14:27] <lu_zero> siretart: oh [15:14:31] <lu_zero> who's there? [15:14:43] <siretart> they present again the 6 monitor beasty wall running on the beagle boards [15:14:56] <siretart> it was just me and a few collegues [15:15:21] <siretart> I'm already back in my office, I've been just a few hours at the exhibition [15:15:30] <lu_zero> I see [15:16:07] <lu_zero> do you happen to know lutin(a)debian.org ? [15:16:23] <siretart> it's kinda convinient to have such trade fairs in the home city :-) [15:16:29] <lu_zero> indeed =) [15:16:40] * siretart does a mia-query on lutin [15:17:04] * lu_zero wants to organize something in Torino for ffmpeg [15:17:21] <lu_zero> I let Puria try to organize first something for mongodb [15:17:52] <lu_zero> if it goes well I'll try to redo changing the subject [15:19:04] <siretart> lu_zero: last gpg activity from lutin on 26 Sep 2010, last activity in general on 08 Nov 2010. It seem strange that it seems that his last upload wasn't signed by himself [15:19:20] <lu_zero> uhm [15:19:39] <lu_zero> I wanted to ask him about evas and friend in debian [15:19:52] <lu_zero> since I'd appreciate a lot two updates ^^ [15:24:32] <av500> siretart: so you saw Marie-Claire [15:27:48] <in3xes> Why av_log() is not giving any output if log level is not 16? [15:28:50] <lu_zero> in3xes: sounds strange [15:28:56] <lu_zero> have a look at the code [15:29:23] <siretart> av500: I met two guys only [15:29:39] <av500> ah [15:37:12] <DonDiego> bye [15:52:19] <in3xes> Anyone responded to my question? I got disconnected. [15:54:28] <J_Darnley> [Wed 16:28:50] <@lu_zero> in3xes: sounds strange [15:54:28] <J_Darnley> [Wed 16:28:56] <@lu_zero> have a look at the code [15:55:28] <av500> the code? outrageous! [15:56:09] <lu_zero> wbs: ping [16:02:00] <in3xes> It gives output if I write only av_log(NULL, AV_LOG_ERROR, ...). But, code says it works if it is less than current loglevel [16:02:46] <in3xes> I tried passing arguments grater than 16, but nothing happened. [16:06:10] <lu_zero> in3xes: to what? [16:07:41] <in3xes> lu_zero: ffmpeg -loglevel "number" -i inputfile that is what I am doing [16:08:54] <lu_zero> in3xes: use the words [16:09:00] <lu_zero> -loglevel debug [16:09:12] <in3xes> Tried that too [16:09:56] <in3xes> Order of these arguments matters? [16:12:42] <in3xes> Weird! Works now :) [16:19:17] <lu_zero> ^^; [16:22:20] <mru> lu_zero: do you know anything about the llvm and clang ebuilds? [16:24:40] <lu_zero> mru: they worked for me so I didn't have to hack on them [16:25:01] <mru> I'm just confused about the interaction between them [16:25:11] <mru> clang depends on llvm but still pulls out all the llvm source [16:27:54] <lu_zero> I can have a look [16:28:34] <lu_zero> http://llvm.org/bugs/show_bug.cgi?id=4840 [16:29:15] <lu_zero> that's why it's pulling llvm apparently [16:29:28] <lu_zero> the bug seems partially fixed but I'm not reading it fully [16:31:37] <lu_zero> so I'm not sure it's still needed [16:42:25] <mru> question is, does the clang ebuild link against the intalled llvm libs or does it build its own? [16:45:09] * mru patches both just to be sure [16:48:38] <lu_zero> should link to the system one [16:48:58] * lu_zero spots a problem in cross building clang... [16:48:59] <lu_zero> meh [16:49:11] * mru is not surprised [16:59:57] <lu_zero> wbs: I'd set the rtp enqueuing by default and expose the enqueue function by default [17:00:18] <lu_zero> right now we are dropping rtp packets on interleave in theory [17:07:02] * mru is nice today and sends patch to llvm [17:17:52] <mru> uau: ping [17:18:02] <uau> ? [17:18:30] <mru> consider this: [17:18:35] <mru> #define foo(x) 1-x [17:18:38] <mru> foo(-1) [17:18:46] <mru> is that allowed to expand to 1--1? [17:19:06] <mru> gcc inserts spaces making it 1- -1 [17:19:14] <mru> the former obviously doesn't compile [17:20:05] <uau> i don't remember that by heart [17:20:14] <av500> c standard says? [17:20:26] <av500> mru: arent you supposed to recite that by heart? [17:20:28] <mru> it doesn't say anything explicitly [17:21:14] <mru> adding whitespace is clearly allowed, but I don't think it's required [17:21:21] <CIA-15> ffmpeg: Ronald S. Bultje <rsbultje(a)gmail.com> master * r8cf9a09d40 ffmpeg/libavcodec/vp3.c: vp3-mt: fix deadlock when first frame is not a keyframe. [17:21:34] <av500> #define foo(x) 1-(x) [17:21:34] <BBB> so astrange was going to send patches for mpeg-mt right? [17:21:35] <av500> solved [17:21:38] <mru> yes, I know [17:21:47] <mru> and I have a patch for that [17:21:48] <av500> mru: isnt one supposed to add () around macro params? [17:22:36] <mru> well, yes [17:22:44] <mru> but someone didn't, and it fails with some compilers [17:25:32] <elenril> BBB: i'll send a patch with proper authorship in a sec [17:27:11] <astrange> BBB: yes, but today i will do schoolwork [17:31:39] <BBB> astrange: ah, who needs school :-p [17:32:00] <peloverde> Says Dr. BBB, PhD [17:33:02] <kshishkov> probably that's the reason [17:33:32] <mru> look what good it did him [17:33:43] <mru> he wasted away precious years he could've spent on coding [17:34:01] <kshishkov> a totally useful degree he's going to use along with aquired knowledge [17:34:16] <gnafu> mru: And who knows? Maybe he wouldn't have had that kid if he didn't get a PhD! [17:34:20] <gnafu> Think about it. [17:34:46] <mru> http://xkcd.com/583/ ? [17:35:06] * gnafu conceals his love for children by making fun of someone who has what he hopes to have in a few years... [17:35:44] <gnafu> mru: Nice. [17:39:12] <kshishkov> gnafu: quite possible - all that free time as a student... [17:40:15] <lu_zero> theheh [17:42:48] <gnafu> Speaking of babies, one of my coworkers is showing off his grandson (kids stopped in). [17:43:16] <gnafu> kshishkov: Sure. Late nights "studying," eh? Eh?! [17:43:40] <gnafu> Hittin' the "books"? [17:43:45] * gnafu will stop now. [17:44:48] <kshishkov> gnafu: in Ukraine students usually study only during or after the exam, so they fill the rest of time with something else [17:46:03] <uau> mru: i think inserting spaces is required - as far as i can see the translation phases are defined in terms of preprocessing tokens (rather than having text output from the preprocessor), and nothing would merge the two '-' tokens into one '--' token [17:47:05] <kshishkov> uau: it was common way in K&R times at least [17:47:39] <uau> what was common? having a separate text preprocessor? maybe, but that doesn't affect the semantics [17:48:05] <mru> it was common for preprocessors to do a literal textual replacement, nothing more [17:48:12] <kshishkov> exactly [17:48:17] <mru> they even expanded macro params inside string literals [17:51:15] <kshishkov> reminds me of our C class - http://khpi-iip.mipk.kharkiv.edu/library/extent/prog/fuer/f92.html [17:53:59] <uau> kshishkov: that seems to demonstrate exactly the -- case - what does the comment 2.1 refer to? [17:54:08] <Compn> KotH : i replied to your hijack mail [17:54:53] * Compn doesnt want anyone going thinking they are ignored :p [17:57:27] <kshishkov> uau: the fact preprocessor does exact replacement, from outer level to deeper one [17:59:26] <mru> <@kshishkov> reminds me of our C class <-- C doesn't have classes, are you sure it wasn't c++? [18:00:34] <kshishkov> mru: that thing is too hardcore for C++ IMO [18:00:52] <kshishkov> mru: and we didn't have C++ [18:01:01] <mru> re the link, thank goodness russian borrowed computing words from english [18:02:14] <kshishkov> indeed [18:02:27] <kshishkov> that's how I understand computer German too [18:03:50] <lu_zero> .fr made the whole thing more interesting [18:04:02] <kshishkov> as expected from French [18:07:16] <bilboed-pi> kshishkov, yuck, wtf is that code ? [18:07:36] <mru> russian [18:08:20] <bilboed-pi> no I meant who on earth teaches to program in such butt-ugly way ? [18:08:22] <kshishkov> an excerpt from old C excercise book - guess the output from code [18:09:19] <kshishkov> IIRC it's also from American author and was bundled with Russian K&R translation [18:09:37] <bilboed-pi> I would just slap a Z as the mark for whoever hands that as the result to an excercise [18:09:58] <kshishkov> you completely miss the point [18:11:25] <lu_zero> kshishkov: language barrier I guess ^^ [18:11:50] <mru> if you call a fortran function from C, do you need a langauge barrier? [18:12:02] <kshishkov> not on VMS [18:13:09] <kshishkov> and what's wrong on studying not very correct code with unexpected output to demonstrate pitfalls? [18:13:24] <mru> that's a good thing to do [18:35:14] <KotH> Compn: thanks [18:37:35] <Compn> oo reimar replied too [18:37:36] <Compn> ehe [18:57:42] <wbs> lu_zero: pong [18:58:04] <wbs> lu_zero: could you rephrase what you tried to say about rtp interleaving, I didn't at all understand what you tried to say :-) [18:59:16] <lu_zero> wbs: ff_rtsp_read_reply [18:59:58] <lu_zero> it could drop useful rtp packets [19:00:41] <wbs> if called with return_on_interleaved_data == 0 when a packet is pending to be read? [19:01:29] <wbs> and yes, I can see that happening, not sure if I see it as a big issue, but if you could avoid it cleanly, you can give it a try :-) [19:03:34] <lu_zero> the idea is to just queue up the packet [19:03:44] <lu_zero> you already did most of the work =) [19:04:03] <wbs> ah, indeed I did :-) [19:05:45] <lu_zero> noticed today while messing with sctp support [19:05:52] <Dark_Shikari> astrange: "I approved the patch" [19:05:53] <Dark_Shikari> what patch? [19:05:57] <Dark_Shikari> you didn't attach a patch to your email [19:06:36] <astrange> takashi mochizuki's [19:08:07] <lu_zero> it just need to enable it by default with a size of at least 3 I think [19:12:56] <Dark_Shikari> astrange: it no longer applies [19:14:45] <astrange> ah [19:15:08] <astrange> because of ff1efc524cb3c60f2f746e3b4550bb1a86c65316 [19:15:17] <iive> mans committed his own fix, I think. [19:15:17] <astrange> but that should also fix it [19:15:21] <astrange> yes [19:15:44] <Dark_Shikari> oh, nice. [19:15:52] <iive> astrange: i think i said that on #x264 hours ago :P [19:16:00] <mru> it seemed silly to set up the whole threading machinery with a single thread [19:32:06] <lu_zero> look like the rentry_transfer_wrapper is bogus... [19:35:45] <lu_zero> or maybe my sctp implementation... [19:35:59] <lu_zero> I guess I'll need to reshape it more properly =P [21:24:13] * Sean_McG makes himself a chai latte [21:25:10] <kshishkov> Sean_McG: if it's not Trocadero it's not worth mentioning here [21:25:38] <Sean_McG> it's not, it's just a Tassimo cartridge ;) [21:27:32] <lu_zero> kshishkov: you should try the chinotto e gazzosa lurisia [21:27:46] * lu_zero makes a mental note to bring a sample next time [21:27:47] <kshishkov> lu_zero: tl;dr [21:28:03] <lu_zero> =? [21:28:13] <kshishkov> too long name [21:28:27] <lu_zero> gazzosa? [21:28:27] <Sean_McG> hahahaha [21:28:32] <lu_zero> or chinotto? [21:28:55] <kshishkov> three combined together [21:29:06] <lu_zero> two different drinks [21:29:11] <kshishkov> ah [21:29:27] <lu_zero> lurisia being the producer [21:29:36] <kshishkov> anyway, time to quote you and go to sleep [21:29:39] <kshishkov> *yawn* [21:29:44] * kshishkov goes to sleep [21:30:00] <lu_zero> http://www.lurisia.it/index.php?method=section&id=3261 [21:30:09] <lu_zero> good night [21:52:32] <Sean_McG> are those beers? [22:03:21] <Sean_McG> how do I get gdb to break inside h264_mp4toannexb_filter? [22:03:47] <Sean_McG> I'm guessing the symbol is missing because it's declared static [22:07:22] <Tjoppen> are you runnig ffmpeg_g? [22:07:27] <Sean_McG> yeah [22:07:49] <Tjoppen> then my guess it has them as debug symbols anyway [22:08:00] <Tjoppen> +is [22:08:14] <Sean_McG> (gdb) list h264_mp4toannexb_filter [22:08:15] <Sean_McG> Function "h264_mp4toannexb_filter" not defined. [22:08:39] <Sean_McG> and yet I know it's being called because my error message is getting displayed [22:08:56] <Sean_McG> I can list other functions [22:09:03] <Tjoppen> un-staticize it then :p [22:09:08] <Sean_McG> k [22:10:05] <mru> static or not shouldn't matter [22:11:36] <Sean_McG> yeah, it didn't... still no symbol [22:12:59] <Yuvi> could always do 'break <file>:<line>' [22:13:17] <Sean_McG> ah OK [22:13:36] <Sean_McG> I'm not used to gdb -- too pampered by the GUI debuggers [22:13:42] * Sean_McG *sheepish grin* [22:15:34] <Tjoppen> *hampered [22:16:10] <Sean_McG> I dunno, I really like the one in Xcode [22:20:31] <Sean_McG> can I step into it from it's upstream caller somehow? [22:31:20] <Sean_McG> what the.... [22:33:21] <Sean_McG> ahhh it's called through a function pointer... argh :| [22:43:40] <Sean_McG> mru: should I be overly concerned about lines that cause the "cast discards qualifiers from pointer target", or just leave them be? [22:49:39] <mru> Sean_McG: depends [22:50:11] <Sean_McG> in this case it's discarding const [22:50:30] <mru> some of those are unvoidable [22:50:34] <mru> what are the types involved? [22:50:38] <Sean_McG> that's... kinda what I figured [22:51:51] <mru> for example, it's impossible to implement strstr() without such warnings [22:53:28] <Sean_McG> a 'uint8_t **poutbuf' and a 'const uint8_t *buf' that's being cast just to '(uint8_t *)' [22:53:40] <Sean_McG> in that same h264_mp4toannexb [22:54:28] <mru> yeah, those are unfixable [22:54:33] <Sean_McG> OK [22:54:43] <Sean_McG> is there a way to disable the warning on just that line? [22:55:08] <Sean_McG> (only to reduce warning noise) [22:57:13] <mru> not that I know of [22:57:19] <Sean_McG> OK [23:25:30] <Sean_McG> hm, looks like it was OS X giving me grief... Solaris gladly lets me set a breakpoint

1 0

IRC log for 2011-03-01
by irc＠mansr.com 02 Mar '11

02 Mar '11

[02:52:12] <hyc> anybody used the movie and overlay filters recently? I can't seem to get it to work with a transparent background [02:52:40] <hyc> always get opaque black. wondering if the gif or png decoder is losing the alpha info [02:52:52] <hyc> or if the movie or overlay filter is ignoring the alpha [02:53:16] <BBB> I've heard that happens with indexed pngs on the ML [02:53:55] <hyc> ok, I'll try RGB instead [02:55:38] <hyc> thanks BBB, that does the trick [03:00:10] <BBB> it's still a bug [03:00:13] <BBB> anyway :) [03:00:33] <hyc> yeah. it actually butchers it completely for indexed PNG [03:01:00] <hyc> thebackground is the right size, the foreground is squashed to like 1/8th the true width [05:17:04] <kierank> astrange: ping [05:18:31] <astrange> here [05:20:01] <kierank> are you familiar with get_buffer and similar? [05:20:47] <astrange> more than nothing, but i haven't written my own that didn't just call back into avcodec [05:21:13] <kierank> any idea what's wrong with: http://pastebin.com/Q05nP9VC [05:31:19] <kierank> spaam: https://github.com/BastyCDGS [05:32:04] * Sean_McG sighs, 00:30 already -- where does the time go?! [05:41:53] <peloverde> saintdev: ping [05:42:44] <astrange> kierank: i think you're missing the loop at the bottom of ffplay.c input_get_buffer() [05:43:41] <kierank> i see [05:43:43] <kierank> will try [05:43:45] <kierank> thanks [05:53:22] <kierank> astrange: still segfaults [05:56:31] <Sean_McG> does it by any chance segfault at the memset()? [05:57:28] <Sean_McG> also, can you valgrind it? [05:57:52] <kierank> oh it doesn't segfault. it complains about a free actually [05:58:21] <Sean_McG> ah... free()-ing something that is NULL? [05:58:32] <kierank> well valgrind complains throughout h264 decoding [05:58:34] <kierank> like crazy [05:58:41] <kierank> then it crashes at av_freep [05:59:37] <Sean_McG> you multithreaded? some kinda double-free()? [06:00:08] <kierank> it's a threaded app yes but everything stays in one thread [06:05:48] <kierank> I might try the avfilter get buffer [06:06:05] <kierank> damn vm has crashed [06:06:30] <Sean_McG> ensured everything is properly re-entrant? [06:07:37] <kierank> i believe so [06:10:53] <saintdev> peloverde: pong [06:40:38] <kierank> wow there's a guy called mans on breakfast news and they pronounced his name correctly [06:44:19] <saintdev> what, it doesn't rhyme with hands? [06:44:21] * saintdev ducks [07:23:06] <KotH> hoi zäme [07:29:09] <j0sh> are the swscale-test supposed to be identical across configurations? (say, with and without mmx disabled) [07:29:27] <j0sh> swscale-test results* [07:41:09] <kierank> jb_CeBIT: anything good? [07:45:30] <jb_CeBIT> no idea [07:45:44] <peloverde> really compelling (and long) starcraft vlog for those who partake: http://www.youtube.com/watch?v=NJztfsXKcPQ [07:51:56] <spaam> peloverde: that episode is really nice [07:58:33] <Tjoppen> I do watch day9 every now and then, but I hadn't seen that one [08:01:39] <Tjoppen> coffee time [08:07:50] <spaam> Tjoppen: see it.. one of the best :) [08:10:35] <kierank> spaam: our colleague basty is still updating his repo [08:11:07] <spaam> kierank: Nice [08:11:27] <spaam> maybe we can get avseq into ffmpeg after the summer [08:11:51] <kierank> avseq needs another round of gsoc [08:12:07] <spaam> yeah [08:12:12] <kierank> top priority [08:13:04] <Tjoppen> I think my sarcasm detector needs calibrating [08:53:09] <kierank> hmmm it segfaults in h264 now so I guess that's better than a double free [08:56:10] <av500> triple free ftw [09:10:46] <lu_zero> yawn? [09:11:59] <av500> sure [09:26:07] <kierank> michaelni: can you help me figure out why this get_buffers implementation is broken http://pastebin.com/Q05nP9VC [09:49:16] <michaelni> kierank, look at mplayer/trunk/libmpcodecs/vd_ffmpeg.c for a working impl. or elaborate on brokwn and i could try to look at it when i have time (not now) [09:49:55] <wbs> michaelni: would you care to look at the aviobuf fill_buffer() bugfix I posted two days ago? I'd value your opinion on it [09:50:03] <kierank> michaelni: h264 decoding writes over the end of the buffer in MPV_frame_end amongst many places [09:50:09] <kierank> michaelni: thanks, didn't think of mplayer [09:50:25] <michaelni> kierank, allocate more bytes at the end? [09:51:33] <kierank> tried that. still crashed [09:52:17] <michaelni> kierank, why now? [09:53:19] <kierank> valgrind's still running [09:53:27] <michaelni> wbs, ill try to look over it later today [09:53:31] <wbs> michaelni: ok, thanks [09:53:38] <michaelni> no prob [09:53:56] <kierank> still manages to write over the end somehow [09:54:16] <kierank> as well as loads of other h264 "Conditional jump or move depends on uninitialised value(s)" [09:55:15] <Kovensky> 06:49.35 MisterHatt: Kuukunen: I'm against GM as I dont trust it [09:55:19] <Kovensky> 06:50.15 Kuukunen: because after eating GM food, the meat you eat might have GENES in it o_o [09:57:10] <kshishkov> Kovensky: exactly [10:01:01] <michaelni> kierank, your code is definitly wrong if CODEC_FLAG_EMU_EDGE is not set [10:01:18] <kierank> yeah that's not a problem [10:01:30] <kierank> my ffmpeg is only compiled in with emu_edge codecs [10:02:08] <michaelni> so what is w/h and the allocated w/h and where it writes over the end and what is linesize? [10:04:58] <kierank> original: w: 720 h: 576 allocated: w: 752 h: 610 [10:06:03] <kierank> linesizes: 0: 752 1: 384 2: 384 3: 0 [10:12:08] <michaelni> kierank, do all decoders crash or just h264? [10:12:53] <kierank> only tested h264 so far. will try an mpeg-2 sample [10:13:38] <kierank> mpeg-2 works fine [10:13:40] <kierank> only h264 broken [10:14:13] <kierank> interesting... [10:14:14] <michaelni> progressive ? PAFF ? MBAFF? [10:16:10] <michaelni> also try to allocate alot more, like 3 times what should be neede maybe the picture when you see it will give you a hint [10:16:45] <kierank> PAFF = fail (720x576), progressive = fail (1280x720), mbaff = fail (1920x1080) [10:16:56] <kierank> lemme find some mpeg-2 4:2:2 just to try that [10:17:36] <iive> kierank: valgrind can log the errors to file, then you can skip it much faster [10:20:39] <kierank> mpeg-2 422 works so it's just an h264 issue so far [10:21:18] <michaelni> and just to be sure check that you have CODEC_FLAG_EMU_EDGE set [10:22:42] <michaelni> and that things like lowres are not set [10:25:38] <kierank> oh wait, crap emu_edge is off for mpeg2/h264. I meant I'm only using dr1 codecs [10:29:02] <kierank> ...aand all works fine now [10:29:06] <kierank> Thanks a lot michaelni [10:29:56] <michaelni> no prob :) [10:29:58] <spaam> :) [10:30:22] <michaelni> ill need to do some work now ... [10:30:45] <michaelni> s/ill/i/ [10:38:38] <vipw> wbs: fwiw, android uses httplive:// instead of applehttp:// [10:40:09] <wbs> vipw: hmm, okay [11:28:26] <DonDiego> mru: would there be any reason to prefer 'git archive' over just rolling a tarball with plain tar? [11:28:55] <wbs> DonDiego: git archive is at least "cleaner" in that it won't accidentally grab other files laying in the same directory, and won't include .git [11:29:22] <DonDiego> i'm working from a clean clone... [11:30:00] <wbs> then it probably mostly differs in avoiding the .git directory, and won't have to write all the files to the FS before tarring them [11:30:02] <DonDiego> but git archive could be useful to generate the tarball without git metadata.... [11:30:02] <av500> still has .git [11:34:38] <mru> git archive includes a comment in the tar/zip identifying the rev it was built from [11:34:50] <mru> not important, but could be handy [11:35:03] <DonDiego> i'm putting that in the VERSION file [11:35:15] <DonDiego> btw, right now i use [11:35:29] <DonDiego> $(cat ffmpeg/.git/refs/heads/master) [11:35:31] <DonDiego> for that [11:35:40] <mru> why? [11:35:43] <Flameeyes> git describe [11:35:45] <mru> run version.sh [11:35:59] <Kovensky> git describe always prefers tags Flameeyes [11:36:06] <Flameeyes> and is that bad? [11:36:11] <Kovensky> ofc [11:36:17] <Flameeyes> why would it be? [11:36:28] <mru> if you run version.sh you'll get exactly the same string as a straight build would [11:36:35] <mru> that has to be what you want [11:36:41] <Kovensky> because then you'll get 0.6.2M-githash [11:36:44] <Kovensky> or sth like that [11:36:48] <Kovensky> depending on what is the latest annotated tag [11:37:00] <mru> that's usually a good thing [11:38:26] <Flameeyes> especially since I'd expect tags not to be set over master, but over branches, most of the time [11:38:43] <Flameeyes> so you'd have 0.6-$hash on master, and 0.6.2-$hash on branch [11:39:22] <Kovensky> if there is no tag set on master, git describe doesn't work [11:42:46] <mru> --always [11:42:59] <mru> stop speculating and just run version.sh already [11:44:15] <DonDiego> shall i just use the output of version.sh unmodified? [11:44:46] <DonDiego> i.e. 'git-00ba041' or similar instead of 'git-snapshot-00ba041' or whatever? [11:45:31] <mru> yes [11:45:48] <mru> why should the build ID differ based on how the sources were obtained? [11:57:56] <wbs> mru: btw, where does git archive include the version number? [11:58:09] <DonDiego> VERSION [11:58:15] <DonDiego> version.sh looks for that file [11:58:46] <wbs> yes, but what is set and where in order for git archive to produce it? [11:59:06] <DonDiego> no git archive involved [11:59:20] <mru> wbs: nothing at the moment [11:59:26] <wbs> I meant this: [11:59:26] <wbs> 13:34 <mru> git archive includes a comment in the tar/zip identifying the rev it was built from [11:59:42] <mru> wbs: it uses some comment field [11:59:47] <wbs> oh, ok [11:59:51] <DonDiego> ah, ok, sorry, misundestood you.. [12:00:09] <mru> but git archive can be made to put info in a real file too [12:08:23] <DonDiego> ok, tarball generation script done... [12:20:23] <DonDiego> git snapshot: 35M, source snapshot: 3.9M [12:23:07] <pross-au> 3.9M, for 12 years of work. Niice [12:23:45] <mru> it's 23M uncompressed [12:23:53] <mru> tar [12:24:20] <pross-au> I am thinking more about entropy [12:24:41] <mru> it does compress well [12:25:02] <pross-au> Small is beautiful [12:27:44] <kshishkov> pross-au: how're Z cutscenes doing, mate? [12:28:47] <pross-au> They're doing funny [12:28:54] <pross-au> Zero progress [12:29:00] <pross-au> Demuxer works [12:29:10] <pross-au> Just need to finish jvdec [12:29:54] <kshishkov> what's that? [12:30:41] <pross-au> JV dec is the Bitmap Brothers Z Video Decoder [12:32:29] <pross-au> (Jonathon's Video i suspect [12:35:53] <pross-au> I'll return to JV, maybe after i polish up the bayer patch [12:36:09] <kshishkov> good luck on them all [12:36:30] <pross-au> Dont need luck [12:36:31] <pross-au> Need time [12:36:39] <pross-au> Its in short supply [12:37:07] <kshishkov> you tell me [12:53:32] <spaam> pJok: ska du pÃ¥ OSD ? [12:53:51] <spaam> http://opensourcedays.org [12:55:37] <pJok> spaam, japp [12:55:50] <spaam> pJok: nice [12:56:22] <spaam> funderar pÃ¥ att besÃ¶ka det ocksÃ¥ :) [12:56:32] <pJok> bra idÃ© [12:56:36] <spaam> date? [12:56:48] <pJok> lÃ¶rdag [12:57:05] <spaam> amen nu tÃ€nkte jag inte pÃ¥ det datum.. ;P [12:57:10] <pJok> ah :P [12:57:19] <pJok> mÃ¶tes i malmÃ¶? [12:57:41] <spaam> pjta varfÃ¶r inte. mÃ¥ste ju Ã€ndÃ¥ byta tÃ¥g hÃ€r sÃ¥ :) [12:57:51] <pJok> hehe [14:23:28] * thresh has fun decyphering http://lists.maemo.org/pipermail/maemo-developers/2011-March/028202.html [14:24:06] <av500> thresh: russian hacker trying to unlock a N900? [14:24:43] * elenril thinks his hovercraft is full of eels [14:25:01] <kshishkov> elenril: you're not Hungarian, you can't use this phrase [14:25:26] <elenril> racism! [14:25:28] <kshishkov> av500: sounds more like Russian hacker trying to disguise his N900 in wireless network [14:25:36] <mru> this is the first time I've seen a mac address referred to as cynical [14:25:47] <av500> kshishkov: he is not hungarian since his nick is not pwszElenril [14:25:58] <thresh> mru: probably because he thinks there should be a PC address instead or something [14:26:46] <kshishkov> mru: in Russia even MAC addresses may be cynical about their owners [14:27:16] <av500> PU:TI:N0:WN:SY:0U [14:27:39] <kshishkov> that's only for Presidential iPad [14:27:57] <av500> oops, so I picked the wrong MAC here [14:28:20] <mru> now that we're off-topic, does anyone know a way to coerce the name of the dynamic linker out of gcc? [14:28:39] <kshishkov> ln -s ? [14:28:46] <av500> s/ld/../ [14:28:47] <mru> that is, the value it passes to ld -dynamic-linker [14:29:08] <mru> usually something like /lib/ld.so [14:29:17] <kshishkov> gcc -dumpspecs [14:29:17] <thresh> -dumpspecs? [14:29:39] <av500> %{muclibc:%{mglibc:%e-mglibc and -muclibc used together}/lib/ld-uClibc.so.0;:/lib/ld-linux.so.2} [14:30:01] <mru> yes, I know that [14:30:10] <mru> but I'd rather not try to parse that mess [14:30:40] <kshishkov> grep it then [14:31:14] <mru> look, I can think of all the obvious ways myself [14:31:31] <mru> I was hoping someone knew a secret option similar to -print-libgcc-name [14:32:00] <mru> s/name/file-name/ [14:34:42] <av500> gcc -print-prog-name=ld [14:34:52] <mru> that prints the static link editor [15:04:41] <spaam> kierank: "sound reproduction with a voice soundchip"... maybe we need to tell him about avseq [15:33:07] <BBB> kshishkov: I'll debug against the ref decoder... I'm just doing this for fun btw, I know vc1 is unused :) [15:33:17] <BBB> so obviously any feature from vc1 is therefore also unused [15:44:27] <kshishkov> BBB: well, some baseline features are used [15:44:57] <kshishkov> BBB: but some of them I've seen only in reference files (and maybe that's for good) [15:45:25] <kshishkov> like luma/chroma scaling - which should be done only for output but not for reference copy [15:45:46] <kshishkov> BBB: and unfortunately interlaced mode was used [15:48:24] <kshishkov> BBB: and I had to fix some issues at your GSoC'11 page [15:52:44] <BBB> kshishkov: ok, thanks [15:58:21] * elenril summons reviews [15:58:44] <kshishkov> * elenril fails as both summoner and stabber [15:58:45] * av500 reviews summons [15:58:57] <av500> REJECTED [16:00:08] <elenril> you're all lazy and evil [16:00:24] * elenril goes to rewrite ffmpeg in php [16:00:25] <av500> that sums it up nicely [16:01:10] * kshishkov makes sure elenril's PHP is implemented in Java [16:21:08] <lu_zero> using a ruby virtual machine? [16:21:21] <av500> written in lua? [16:23:05] <kshishkov> with lua interpreter in hardware BASIC [16:23:34] <gnafu> As long as it runs on my TI-83, I'm happy. [16:23:44] <BBB> elenril: sorry, I thought I said they were ok? [16:48:05] <BBB> anyone have ideas for GSoC2k11? [16:48:15] <BBB> preferrably with proposed mentors, that being all of you [16:48:47] <CIA-15> ffmpeg: Alexander Strange <astrange(a)ithinksw.com> master * rad9791e12b ffmpeg/libavcodec/pthread.c: [16:48:47] <CIA-15> ffmpeg: pthreads: Fix bug introduced with thread_safe_callbacks [16:48:47] <CIA-15> ffmpeg: For intra codecs, ff_thread_finish_setup() is called before decoding starts [16:48:47] <CIA-15> ffmpeg: automatically. However, get_buffer can only be used before it's called, so [16:48:47] <CIA-15> ffmpeg: adding this requirement broke frame threading for them. Fixed by moving the [16:48:48] <CIA-15> ffmpeg: call until after get_buffer is finished. [16:48:49] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [16:48:53] <CIA-15> ffmpeg: Alexander Strange <astrange(a)ithinksw.com> master * r76d8846c4e ffmpeg/libavcodec/huffyuv.c: [16:48:53] <CIA-15> ffmpeg: huffyuv: Add multithreading support [16:48:53] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [16:50:26] <av500> BBB: libavseq2 [16:53:39] <BBB> kshishkov: is http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_Of_Code_2011#Suppor… OK with you? [16:54:02] <BBB> kurosu: do you want to help mentor the optimizations for vc1dec also? [16:56:08] <elenril> no h264? [16:56:14] <elenril> as for gsoc -- playlists? [16:56:49] <av500> libavmetadata [16:57:18] <spaam> BBB: what about avseq? :D [16:58:24] <av500> [17:50:26] <av500> BBB: libavseq2 [16:58:46] <spaam> av500++ [16:59:08] <spaam> av500: after that we can have libavseq-ng [16:59:15] <BBB> hm... [16:59:16] <BBB> no [16:59:18] <BBB> :) [16:59:37] <elenril> BBB: if they're ok, maybe you could commit them ;) [16:59:54] <BBB> elenril: would you like to mentor a gsoc task? [16:59:54] <elenril> also i still didn't see any comments on avio_get_str [16:59:59] <BBB> after all you are our top committer [17:00:02] <elenril> lol [17:00:24] <elenril> that only means i know basics of sed ;) [17:02:12] <elenril> i'd rather try studenting, but i'll be busy with my diploma work during the summer [17:06:00] <BBB> astrange: would you like to help mentor students into adding -mt support to more decoders (e.g. vp8)? or be a student yourself and merge -mt? [17:06:43] <merbzt> elenril: we could slot you a not so time demanding task [17:07:09] <elenril> BBB: there's so much left to merge? [17:07:09] <BBB> or, rather, figure out your own task - what would you like to work on that you think you can finish over a summer? [17:07:22] <BBB> elenril: not really, but some decoders aren't -mt yet after the merge [17:07:28] <BBB> some of them are nice to -mt for PR purposes [17:07:30] <BBB> e.g. vp8 [17:09:58] <elenril> when is the deadline for student applications? [17:11:18] <BBB> hasn't opened yet [17:11:45] <BBB> march 28-april 8 [17:12:05] <elenril> good [17:12:57] <BBB> I have your url_fseek->avio_seek patch queued [17:13:15] <BBB> the other one replaced url_fskip() with url_fseek(SEEK_CUR), right? [17:13:29] <BBB> you sure you don't want a macro? I think mru preferred a macro [17:13:53] <mru> I don't mind either way [17:14:28] <BBB> ok, I'll queue that also then [17:16:17] <BBB> the line that mru pointed out there needs a change though [17:16:21] <BBB> it adds a needless < 0 [17:16:28] <BBB> can you re-post the patch, elenril ? [17:17:00] <BBB> or alternatively I can fix it myself [17:17:34] <elenril> ? [17:17:51] <BBB> see [FFmpeg-devel] [PATCH 2/3] lavf: replace all uses of url_fskip with avio_seek [17:17:58] <elenril> changed version should be equivalent to old code [17:18:37] <elenril> url_fskip returns 0 on success, < 0 on error [17:18:49] <BBB> in a for loop, you change for(;;url_fskip){.. into for(;;avio_seek(SEEK_CUR < 0) { .. [17:18:59] <BBB> it's the increment part of the for loop, not the conditional part of the for-loop [17:19:03] <BBB> the <0 isn't useful [17:19:05] <elenril> so the for() would terminate after first successful skip [17:19:18] <BBB> for(start;condition;increment){ [17:19:18] <elenril> seek() returns new offset on success, <0 on error [17:19:29] <BBB> the increment part return code is not checked [17:19:36] <elenril> ok, i should learn to read [17:19:39] <BBB> for(i=0;i<count;i++){.. [17:27:20] <BBB> elenril: all queued [17:27:24] <BBB> will run fate and commit [17:27:29] <BBB> did you have more patches than those 3? [17:27:51] <elenril> avio_get_str [17:28:19] <BBB> oh right [17:28:57] <BBB> doesn't apply [17:29:00] <BBB> needs a rebase likely [17:30:12] <BBB> elenril: just hold on before rebasing it until I've at least pushed the other 3 patches [17:31:33] <elenril> i'll rebase it [17:32:15] <elenril> no conflicts here [17:32:29] <BBB> because I didn't push the other 3 yet [17:32:32] <BBB> pushed now [17:32:40] <elenril> i rebased against those [17:32:45] <BBB> hm [17:32:46] <BBB> weird [17:32:49] <BBB> it doesn't apply for me [17:32:51] <BBB> let me try again [17:32:52] <elenril> git magic [17:32:58] <BBB> can you resend anyway? [17:33:04] <mru> BBB: how are you applying? [17:33:13] <BBB> git am -s < emailbox [17:33:19] <mru> try git am -3 -s [17:33:24] <BBB> what is -3? [17:33:27] <BBB> n/m [17:33:28] <mru> 3-way merge [17:33:29] <BBB> I'll --help it [17:34:02] <elenril> done [17:34:05] <BBB> ty [17:36:17] * elenril kicks CIA-15 [17:36:37] <BBB> I don't see your patch yet either [17:36:39] <elenril> did it die? [17:36:48] <BBB> maybe it's busy [17:36:55] <CIA-15> ow [17:43:45] <CIA-15> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * r6b4aa5dac8 ffmpeg/libavformat/ (90 files): [17:43:45] <CIA-15> ffmpeg: avio: avio_ prefix for url_fseek [17:43:45] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [17:43:45] <CIA-15> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * re356fc57a2 ffmpeg/libavformat/ (62 files): [17:43:46] <CIA-15> ffmpeg: lavf: replace all uses of url_fskip with avio_seek [17:43:46] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [17:43:47] <CIA-15> ffmpeg: Anton Khirnov <anton(a)khirnov.net> master * r0300db8ad7 ffmpeg/libavformat/ (avio.h aviobuf.c): [17:43:47] <CIA-15> ffmpeg: avio: deprecate url_fskip [17:43:48] <CIA-15> ffmpeg: avio_seek should be used instead [17:43:48] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje(a)gmail.com> [17:45:01] * elenril kicks obscure sw written in fortran [17:46:08] <av500> obscure sw written in fortran waits for elenril to wither away [17:46:48] <av500> then has drink with obscure sw written in cobol [19:40:36] <vcs> hi, im developing a new demuxer for libavformat and seem to have run into a bug... this the right channel to ask about? [19:43:37] <vcs> anyways... Sometimes when I use url_fseek in my demuxer (with valid position in the file, verified), i keep getting "Assertion failed: s->buf_ptr == s->buf_end, file libavformat/aviobuf.c, line 314" the values from the assertation: PTR: 30f076e END: 30f1878 END-PTR: 110a. any idea what i could be doing wrong? seems to only happen when i use url_fseek. Here is a full backtrace (the violating function being fill_buffer in aviobuf.c): http://pastebin.com/ [19:44:13] <BBB> vcs: yes, this is the right channel [19:44:30] <gnafu> vcs: Your message was cut off after pastebin.com/. [19:44:37] <vcs> http://pastebin.com/CzUiwfAH [19:45:53] <gnafu> vcs: Thanks. [19:46:57] <vcs> im going to keep going through the aviobuf to try and see if i can figure this out, but if you have seen this before/know anything about that section of the code any help would be appreciated [19:49:21] <vcs> I guess I should note I am cross compiling on linux for windows, but the BT makes that obvious :) [20:01:07] <BBB> vcs: could we see your demuxer? [20:02:00] <vcs> sure, it is open source after all... give me a sec [20:07:39] <BBB> iive: stop trolling please [20:08:20] <BBB> iive: I have never revoked anyone's commit access and I have never told anyone not to review anything. in fact, I highly recommend everyone to review and I continues ask michael and baptiste to review the stuff they consider "theirs" [20:08:23] <vcs> http://pastebin.com/QwCPYciP [20:08:25] <BBB> iive: what you're saying is insulting [20:08:32] <BBB> vcs: will have a look [20:09:19] <vcs> thanks, basically im just trying to get video playback working (which is just mpeg4) so audio stuff is not initialzed yet [20:10:32] <vcs> problem happens at line 222 (i had not put the GPL header on it yet) [20:11:01] * gnafu looks at the ML archives to figure out what the heck BBB is talking about... [20:12:06] <BBB> can't directly see whaht's wrong with it [20:12:11] * BBB looks again [20:12:33] <iive> BBB: I think I mentioned roots. I expect this to be their response of this situation. [20:12:47] <Compn> BBB : does michael have commit rights to ffmpeg.org homepage repo ? [20:13:00] <vcs> BBB: I will try to compile and run on linux and see if I get the same results [20:13:02] <iive> and michael did post his patch and it got accepted by carl. Diego have not posted his "similar" patch yet. [20:13:15] <vcs> thanks for the look though, is much appreciated [20:13:30] <Compn> iive : BBB says that doesnt matter since diego was 'working' on it first [20:13:50] <iive> by reverting the patch you "de-facto" took away the right of carl to review and commit. [20:14:08] <av500> Compn: iive: do you think, the situation improves by these "commit speed" games? [20:14:14] <iive> and I expect roots to counter this "loophole" very soon. [20:14:28] <iive> av500: is there something wrong in the patch itself? [20:14:48] <av500> iive: the current issues FFmpeg has are not "technical" [20:15:18] <Compn> av500 : do you think there is a problem with such patch made by a main developer of ffmpeg ? [20:16:08] <Compn> av500 : is diego here or is he busy with work ? i dont remember his current status but for a while he didnt have time for the project... [20:16:15] <Compn> to respond to the speed question of yours [20:16:55] <Compn> its not even a controversial patch [20:18:15] <astrange> BBB: i'm already employed fulltime so i don't meet the student requirements. mentoring looks possible. i'll check [20:18:28] <astrange> fulltime during the summer, i mean [20:19:32] <iive> BBB: but let's be constructive. Who can review michael's patch. Can you review it and apply it, so the matter could be quickly resolved? [20:19:38] <hd987> BBB: You do realize by saying things like "we can probably put a link to Michael's repo" and "Looks good to me [... ] As Michael said, it might be nice to be able to point [...], but let that not hold up this initial patch." you serve nothing other than to feed the confrontational nature of things? I mean how much harder would it have been to be fair and say "hey ok let's post them both and give them equal foot [20:19:39] <hd987> ing" [20:20:06] <Compn> hd987 : well , he reverted michael's patch because we think diego has a patch that does that [20:20:27] <Compn> hd987 : 'why not just apply the second hunk later?'... [20:20:53] <iive> I think diego patch already got committed, but it is about git.ffmpeg.org, not git.videolan.org [20:21:10] <Compn> iive : we are talking about svn://mphq/ffmpeg.org [20:21:15] <Compn> for homepage [20:21:31] <iive> for the links to snapshots [20:21:42] <Compn> are in the homepage repo [20:21:44] <Compn> ? [20:21:51] <iive> links are. [20:22:04] <hd987> Compn: my point is that people are aware the other repo exists, even so much as point it out in communications, but then relegate it to "later" [20:22:26] <Compn> hd987 : ah [20:22:56] <hd987> thus, it just feeds the confrontational nature of things... [20:22:59] <Compn> hd987 : yeah, its annoying to be sure [20:23:03] <Compn> iive : oh, i see [20:23:21] <Compn> i dont care about the patch so much so but i want to know if michael can edit ffmpeg.org repo [20:23:30] <Compn> maybe mru knows [20:23:48] <iive> no he can't [20:24:15] <Compn> or if roots changed michaelni's access, did they send him a note at all? [20:24:20] <iive> i guess roots removed him after he changed the repo link in the middle of the flamewars. [20:24:32] <iive> (without sending patch first). [20:24:45] <mru> michaelni's access was revoked after he defaced the page once [20:24:54] <mru> he noticed as he tried to do it again [20:24:56] <Compn> ah yes, i had bugged mru to fix it for a week [20:25:23] <mru> I suggest adding snapshot links to the repo table [20:25:55] <Compn> michaelni : did anyone tell you that your access was 'revoked' ? [20:26:21] <Compn> so you guys threw out the policy then, i'm assuming ? [20:30:46] * Compn frustrated [20:38:25] <michaelni> Compn, noone told me [20:40:34] <Compn> shitty way to run a server that is [20:40:47] <michaelni> and mru, adding a link to the source code repository is not "defacing" [20:43:05] <lu_zero> yawn [20:43:24] <lu_zero> you insult people, you get some results... [20:43:51] <lu_zero> still polite discussion might lead to more interesting results [20:43:58] <lu_zero> but it's just my opinion [20:44:00] <lu_zero> btw [20:44:03] <lu_zero> oink [20:44:16] <michaelni> lu_zero, where did i insult anyone? [20:44:35] <lu_zero> michaelni: I explained you before [20:44:39] <michaelni> btw, lu_zero your yawn & oink are insulting [20:44:47] <lu_zero> I'm tired [20:44:54] <michaelni> me too [20:45:08] <lu_zero> so yawning should be allowed [20:45:19] <lu_zero> regarding oink [20:45:31] <michaelni> its allowed just odd timing [20:45:32] <lu_zero> well it's a swine reference. [20:45:41] * lu_zero just got home [20:45:49] <michaelni> well you noticed the From != michael [20:45:57] <michaelni> on that mail [20:46:12] <michaelni> with that "swine" [20:46:20] <lu_zero> yes, the oink was not referred to you =) [20:46:44] <lu_zero> I was thinking about using it as generic greetings to the other swines =P [20:46:49] <lu_zero> that said [20:47:20] <michaelni> ahh, who do you mean by "other swines"? [20:47:37] <lu_zero> reference to the carl email [20:47:56] <mru> nÃ¶ff said, let it rest [20:49:39] <thresh> oh more fun in fflandia [20:49:59] <thresh> seriously guys, you need to gather together and share a couple of beers [20:50:13] <mru> a bunch of us did at fosdem [20:50:17] <mru> some refused to come [20:51:02] <spaam> thresh++ [20:52:29] <thresh> mru: I obviously mean two opposing sides, not the only one [20:52:39] <lu_zero> thresh: we tried our best [20:52:54] <lu_zero> the next step might be gather in vienna [20:52:59] <mru> thresh: we had beer with the gstreamer guys [20:53:07] * lu_zero would bring some troll beers [20:53:13] <thresh> mru: wow, and no one was injured?! [20:53:19] <lu_zero> thresh: nope [20:53:26] <mru> turns out they were actually quite nice [20:53:45] <ubitux> when they were lying on the floor with shard everywhere? [20:53:53] * lu_zero knew already [20:53:56] <lu_zero> ubitux: nope [20:54:11] <lu_zero> that reminds me two things [20:54:14] <lu_zero> bilboed: poing [20:56:23] <vcs> hmmm.. seems the assert problem is occuring when the buffer size is at max (len is equal to IO_BUFFER_SIZE) when using url_fseek when it calls fill_buffer.. seems icreasing the buffer it only delays the problem till that many bytes later.. should i be doing another call to clear the buffer before i perform a url_fseek in my demuxer? [21:00:01] <lu_zero> which demuxer? [21:00:15] <av500> http://pastebin.com/QwCPYciP [21:02:54] <vcs> its a new one i am writing for a video format used by a company that does public safety video recording. code is GPL of course but im not sure how useful it will be to anyone :) [21:04:32] <vcs> basically my question is is there something special i need to do to clear the existing buffer before a url_fseek/get_buffer call [21:05:20] <BBB> astrange: that would be cool [21:05:38] <vcs> because I seem to be triggering the assert at line 315 in aviobuf.c [21:05:39] <BBB> vcs: I don't think so, the code looks fine on a first look, was gone for a bit, let me look again [21:06:05] <vcs> BBB: i did a step by step walkthrough of the call to fill_buffer [21:06:35] <vcs> well hmm, i have confused myself now [21:07:24] <BBB> astrange: if you can come up iwth a good task description for a gsoc2011 project for a student that involves ffmpeg-mt, please post it to me or put it on multimediawiki and we'll get it up [21:07:45] <BBB> astrange: also, don't worry about it being -mt only, you can combine things like slice+frame-based vp8 multithreading in the same task [21:07:55] <BBB> astrange: but totally up to you [21:12:55] <kshishkov> BBB: I'm against those VC-1 features - they are rather small and completely unimportant since no known real file uses them [21:13:08] <kshishkov> BBB: except for NEON opts of course [21:13:37] <kshishkov> BBB: interlaced VC-1 samples are at least known to exist [21:13:55] <av500> yes, came across one today [21:14:00] * mru has seen many at kshishkov's office [21:14:05] <av500> in my sample collection, didnt know I had one [21:14:35] <kshishkov> mru: you got them all and left nothing for me [21:17:58] <BBB> kshishkov: what if I mentor the other features? [21:18:20] <BBB> kshishkov: ffmpeg's main purpose is to contain obscure video format features that nobody ever heard of, isn't it? [21:18:34] <kshishkov> BBB: but only if they are used [21:18:42] <BBB> I have one sample where they are used!!! [21:19:21] <kshishkov> reference samples don't count [21:19:28] <BBB> oh :( [21:19:46] <kshishkov> work on missing H.264 features instead [21:20:01] <spaam> BBB: "ffmpeg's main purpose is to contain obscure video format features that nobody ever heard of" .... why remove sonic codec then? ;P [21:20:13] <BBB> same reason I guess, no samples [21:20:23] <BBB> but I have no real opinion on sonic, I've never heard of it [21:20:39] <av500> BBB: its a very fast hedgehog [21:20:52] <kshishkov> av500: and it owns DivX [21:20:53] <BBB> my lab publishes papers on sonic hedgehog, the protein [21:21:33] <av500> see, its everywhere [21:23:11] <kshishkov> nevertheless, unsupported existing codecs outside lab environment are FFmpeg's prey [21:23:52] <iive> define unsupported. [21:24:12] <Dark_Shikari> Well, hmm [21:24:17] <Dark_Shikari> if we have Sonic, we could write an extension to it [21:24:19] <Dark_Shikari> called Tails. [21:24:38] <BBB> Dark_Shikari: you want to mentor a student for gsoc this year? [21:24:44] <Dark_Shikari> I'm going to be mentoring for x264 [21:24:53] <BBB> I know [21:24:53] <Dark_Shikari> ... 'course, we'll need projects to mentor... [21:25:00] <BBB> but you could mentor ffmpeg also :-p [21:25:16] <Dark_Shikari> I could, if you have something interesting enough [21:25:37] <thresh> Dark_Shikari: going to be an admin for standalone application? [21:25:38] <lu_zero> Dark_Shikari: I was wondering if you'd be interested in mentoring celt [21:25:48] <Dark_Shikari> no way [21:25:51] <thresh> not sure jb is going to do admin work this year [21:25:51] <Dark_Shikari> I don't know enough about audio [21:25:57] <lu_zero> ah [21:26:01] <Dark_Shikari> thresh: j-b isn't?? [21:26:11] <Dark_Shikari> wait, then who is apping for videolan? [21:26:12] <BBB> oh [21:26:12] <thresh> you better ask him, but that's an impression I had [21:26:15] <BBB> kshishkov: https://roundup.ffmpeg.org/issue1477 [21:26:21] <BBB> kshishkov: it's used for rtp/vc1 [21:26:37] <BBB> kshishkov: so it _is_ used :) [21:27:11] <BBB> kshishkov: can I add RTP/VC1 support to that list also? might even be a good qualification task [21:27:21] <BBB> (just payload depacktizing, not actual proper decoding) [21:27:25] <kshishkov> BBB: that's not a valid proof, it's probably slight bitstream change [21:27:26] <Dark_Shikari> interlaced vc-1 should be a gsoc project [21:27:37] <BBB> Dark_Shikari: it is [21:27:45] <BBB> kshishkov: ? [21:27:54] <Dark_Shikari> you should add optimization gsoc tasks [21:28:03] <Dark_Shikari> like to write things like vc-1 asm, etc [21:28:09] <Dark_Shikari> Imagine if you had done this for google code-in [21:28:16] <Dark_Shikari> you'd have 5000 new asm functions by now [21:28:17] <BBB> Dark_Shikari: I'm working on that, trying to find proper mentors is a task [21:28:23] <kshishkov> BBB: it's completely wrong in decoding IIRC [21:28:31] <Dark_Shikari> I can help mentor asm [21:28:37] <BBB> cool [21:28:49] <kshishkov> but slices support is one day of work for student at most [21:28:50] <BBB> kshishkov: I'd like to keep the tasks, I'll mentor these parts, if you're ok with that [21:28:56] <kshishkov> scling is similar [21:29:13] <BBB> kshishkov: and I'll work on it anyway, so I might fix it myself before gsoc starts [21:29:17] <BBB> then we don't have to care at all [21:29:21] <kshishkov> BBB: mentor whatever you like, I'm too busy+lazy to get off your share [21:29:38] <BBB> kshishkov: will you mentor vc1 interlaced if there's a student? [21:30:14] <kshishkov> BBB: yep, but not officially [21:30:25] <av500> only over pm? [21:30:35] <kshishkov> or IRC [21:30:43] <BBB> kshishkov: ok [21:32:14] <kshishkov> anyway, time to sleep. VC-1 related questions will be ignored for next 11 hours [21:32:27] <BBB> Dark_Shikari: proposals for optimizations? one I had in mind is to speed up dct coeff reading (like mans did for the neon code) and implement edge extension after reference frame reading for faster MC in subsequent frames in the vp8 decoder (similar to how I implemented ff_emulated_edge_mc simd) [21:32:30] <spaam> "Christophe Gisquet" who is that? [21:32:33] <BBB> kshishkov: love you too [21:32:39] <BBB> spaam: he wrote the existing vc1 asm [21:32:42] <Dark_Shikari> BBB: Write asm for shit [21:32:44] <BBB> spaam: he agreed to mentor [21:32:49] <spaam> BBB: ok :) [21:32:51] <BBB> Dark_Shikari: oh right got it [21:32:56] <BBB> Dark_Shikari: h264 asm ideas maybe? [21:33:18] <Dark_Shikari> h264 is the last thing that needs asm [21:33:22] <Dark_Shikari> though someone could help irock out [21:33:36] <BBB> what needs asm according to you then? [21:33:45] <BBB> swscale? :-p [21:33:51] * BBB gives lu_zero the ;ppl [21:33:53] <BBB> look* [21:34:18] <lu_zero> BBB: swscale needs to be de-asmified first =P [21:35:02] <spaam> lu_zero: what are you waiting for? :D [21:35:27] <Dark_Shikari> BBB: 10-bit h264, vc1, porting all of x264's encoding asm, etc [21:37:29] <spaam> Dark_Shikari: 10bit h264., there was a dude in #x264 working on that? [21:37:41] <Dark_Shikari> yes, irock [21:37:43] <Dark_Shikari> he has working decoding in ffmpeg [21:37:48] <Dark_Shikari> challenge will be getting it merged [21:37:53] <Dark_Shikari> but it's done and bit-exact iirc [21:37:58] <Dark_Shikari> there are ffdshow builds with it iirc [21:38:23] <mru> submit, review, commit [21:38:27] <mru> what's the holdup? [21:38:33] <Dark_Shikari> making 8-bit and 10-bit work in the same build [21:38:39] <Dark_Shikari> templating the entire decoder [21:38:46] <Dark_Shikari> in a way that doesn't piss everyone off and look horribly ugly [21:39:08] <mru> so it's not done [21:39:18] <Dark_Shikari> I never said it was `-` [21:39:28] <mru> 21:37 <@Dark_Shikari> but it's done [21:39:54] <Dark_Shikari> well, it's done as in it decodes correctly `-` [21:39:55] <spaam> so tamplate some stuff and remove it from other things.... [21:41:43] <BBB> Dark_Shikari: yeah, I thought we agreed you'd have to template the decoder... anyway, I'm sure irock knows how to do this [21:42:35] <j0sh> h264 is becoming the new swscale [21:43:03] <j0sh> templates flying everywhere [21:43:04] <BBB> j0sh: no, there's at least >1 person that thinks he knows how it works [21:43:05] <BBB> :-p [21:43:11] <j0sh> heh [21:44:08] <BBB> Dark_Shikari: are x264 people ok with that under lgpl? [21:44:09] <spaam> BBB: so who knows swscale? lu_zero ? [21:44:14] <Dark_Shikari> what is "that" [21:44:20] <BBB> Dark_Shikari: C code, ASM code [21:44:25] <Dark_Shikari> what c code [21:44:31] <BBB> ASM code then [21:44:36] <Dark_Shikari> which asm code [21:44:42] <BBB> the one that irock is porting [21:44:47] <Dark_Shikari> he hasn't touched any asm yet [21:44:48] <BBB> or writing [21:45:17] <BBB> is irock a college student? [21:45:31] <Dark_Shikari> I think so [21:45:44] <BBB> can we sign him up for gsoc? [21:45:54] <BBB> you could mentor him [21:46:14] <BBB> .o(***magic***) [21:46:16] <Dark_Shikari> he was a student last year [21:46:26] <astrange> 16:42 < j0sh> h264 is becoming the new swscale <- someone write libhwscale [21:46:59] <BBB> btw, astrange, what's next re: your -mt merging? I just applied your huffyuv patch, am looking forward to the next patchset </nudge> :p [21:48:52] <astrange> mpeg1 is the next thing to merge [21:48:58] * beastd wonders why Carl Eugen's commit was offending but secretly overtaking the project wasn't [21:49:34] <astrange> few more small bugs first. i found a vp3 sample that deadlocks :/ [21:53:18] <BBB> astrange: if you need me to help debugging, let me know, I'd love to get a better handle on that code anyway so debugging it is useful for me :) [21:56:24] <astrange> helgrinding... [22:00:28] <astrange> ==47941== Thread #5: Bug in libpthread: recursive write lock granted on mutex/wrlock which does not support recursion ==47941== by 0x1003B6D76: frame_worker_thread (pthread.c:289) [22:00:44] <mru> ouch [22:01:02] <astrange> http://people.xiph.org/~maikmerten/youtube/fred-K170-V465.ogv [22:01:03] <Dark_Shikari> helgrind doesn't support condition variables so isn't it kinda useless? [22:01:30] <astrange> it detects deadlocks if you run with --error-limit=no [22:01:35] <mru> Dark_Shikari: correctly analysing the associated mutexes should be enough [22:02:15] <mru> condition variables in themselves are very hard to abuse [22:06:30] <rukhsana> Hi [22:06:53] <BBB> astrange: hah, indeed [22:07:27] <wbs> BBB: care to push the aviobuf-patch that michaelni ok'd? [22:07:44] <iive> astrange: I have that in the config file :) [22:08:12] <iive> astrange: i also have something to increase the backtrace depth and log the output to file [22:08:30] <wbs> vcs: what ffmpeg version are you working on? there's no assertion that looks even remotely like the one you're trigging in my aviobuf.c [22:08:50] <superdump> astrange: i'm sure you get asked every five minutes but, what is left to be merged from ffmpeg-mt? [22:08:56] <vcs> 0.6.1 [22:09:03] <michaelni> wbs, push to videolan :) [22:09:21] <wbs> vcs: try the latest from git, that sounds like some bug that might have been fixed at some point [22:09:27] <Dark_Shikari> 0.6.1 is ancient [22:09:29] <Dark_Shikari> I told you to update [22:09:33] <wbs> michaelni: that's of course an option :-) [22:09:47] <vcs> oh shit, my bad. I was building on windows so I just used the version from the tutorial. [22:09:50] <BBB> I can push in a bit [22:09:50] * vcs slaps himself [22:10:20] <vcs> I feel dumb, but I think you guys just have saved me alot of time :) [22:10:30] <lu_zero> vcs: ^^ [22:10:35] <lu_zero> hi rukhsana [22:11:01] <rukhsana> I am working on JPEG 2000 [22:11:09] <rukhsana> I am still studying [22:11:18] <rukhsana> to understand the code [22:12:07] <vcs> so should I use the main repository? I know there are no guarantees, but should it be stable enough to develop with? [22:12:11] <Dark_Shikari> yes [22:12:31] <wbs> vcs: the latest git version should mostly be more stable than the releases [22:12:50] <wbs> except for when there's some large regression, but such are most often fixed within a day or so [22:12:58] <astrange> superdump: mpeg* [22:13:00] <mru> and fate will tell [22:15:03] <BBB> astrange: and h264 [22:15:18] <astrange> that's mpeg4 part 10 [22:22:06] <BBB> astrange: the problem is probably that the first frame is not an i-frame [22:22:20] <BBB> so it waits on progress on the ref frame which does not exist [22:22:30] <BBB> note how without threads the first frame is green [22:22:53] <BBB> astrange: discard all non-i-frames before the first i-frame and you should be ok [22:23:12] <mru> green is gorgeous [22:23:26] <BBB> green means "inexperienced" in dutch [22:23:30] <BBB> amongst other things [22:23:48] <astrange> if there's no ref AVFrame, there shouldn't be anything calling cond_wait though [22:24:01] <BBB> it is really waiting :) [22:24:15] <BBB> maybe it creates an empty ref frame that is never called report_prorgress() on? [22:24:16] <astrange> h264 does generate fake ref AVFrames, but i don't remember seeing it in vp3. some printf tracing should find it [22:25:00] <BBB> if you trace the ff_thread_{report,await}_progress() calls, you'll see both hang on the first wait [22:25:05] <BBB> and progress is never reporter [22:25:07] <BBB> s/r/d [22:25:47] <mru> if an empty ref is created, shouldn't it be reported as complete immediately? [22:26:35] <BBB> probably [22:26:36] <BBB> but it isn't [22:27:27] <astrange> ah it converts the p frame to i when it prints the not a keyframe warning [22:27:34] <astrange> it's probably to do with that [22:34:19] <BBB> shouldn't we just discard the frame instead of attempting to decode it? [22:34:31] <BBB> I guess some of the data might be correct [22:34:34] <BBB> most won't be though [22:34:45] <jannau> [22:35:35] <iive> for h264 there is mode where no keyframe are issued. the image is supposed to be completely recovered after X frames (where X is written in the bitstream by the encoder). [22:35:58] <astrange> vp3 doesn't use error resilience [22:36:03] <Dark_Shikari> that isn't exactly how it works [22:36:08] <Dark_Shikari> it's supposed to be recovered when frame num == some value [22:36:10] <Dark_Shikari> not after n frames [22:36:14] <Dark_Shikari> this is not EXACTLY the same thing. [22:36:22] <astrange> if it did, you would see the recoverable data and the rest would be something better than bright green [22:37:08] <Jumpyshoes> Dark_Shikari: so can you have like frame 1, 50, 150, 255, etc as fully recovered frames? [22:37:17] <Dark_Shikari> it works like this [22:37:18] <iive> Dark_Shikari: not sure I see the difference. [22:37:20] <Dark_Shikari> current framenum = X [22:37:31] <Dark_Shikari> recovery_frame_cnt = Y [22:37:38] <Dark_Shikari> framenum when things are recovered = (X+Y)%(max frame num) [22:37:45] <Dark_Shikari> iive: b-frames don't increment framenum usually [22:38:14] <mru> BBB: a P (or B) frame might have all or many blocks intra coded [22:38:34] <BBB> mru: true, good point (I'm not familiar with vp3 though) [22:38:49] <iive> Dark_Shikari: details.... [22:38:50] <BBB> anyway, I'm sure astrange will soon post a patch :-p [22:39:02] <mru> me neither, but I assume it has an intra MB mode [22:39:49] * BBB wonders whether to apply elenril's patch as-is or integrate reimar's changes [22:42:14] <BBB> Dark_Shikari: can you discuss with irock if he wants to participate as a student integrating his 10-bit h264 changes into ffmpeg? [22:42:20] <BBB> or irock ^^ [22:42:29] <Dark_Shikari> whenever he wakes up here really [22:44:32] <BBB> what else would be a useful/fun gsoc task with a mentor [22:45:19] <BBB> michaelni: want to mentor a student again this year? [23:28:47] <peloverde_at_wor> anyone know a good tool to view SEIs? [23:30:47] <mru> hexdump [23:31:34] <mru> or whip up a parser [23:31:36] <mru> can't be too hard [23:32:23] <vcs> if get_buffer is now depricated, what replaced it? [23:32:27] <vcs> in the devel branch [23:32:44] <mru> avio_read [23:32:48] <vcs> ahh, thanks [23:50:41] <Sean_McG> hmmm... wondering why gsm-ms is failing on kostylev's sparc64-linux box -- does Debian's gcc typically produce 32 or 64 bit binaries by default (with no -m32/-m64)? [23:53:54] <Sean_McG> I know older gcc's had a zero/sign-extension behaviour difference on SPARC [23:54:04] <Sean_McG> but I don't think that's it [23:55:04] <mru> that's just a bug [23:55:10] <mru> it used to show up on ppc too [23:55:14] <mru> same gcc version [23:55:33] <DonDiego> gnite [23:57:39] <Sean_McG> ah, so not worth investigating further then [23:58:42] <mru> 4.2 isn't maintained iirc [23:58:52] <Sean_McG> aye, earliest is 4.3 [23:59:02] <mru> then there's little point [23:59:54] <mru> it's curious though that it passes on openbsd

1 0

IRC log for 2011-02-28
by irc＠mansr.com 01 Mar '11

01 Mar '11

[00:05:01] <mru> here's another good error message: UNREACHABLE executed! [00:05:11] <Sean_McG> o_O; [00:05:24] <mru> followed by a stack dump [00:06:50] <peloverde> when they say better errors I think they mean from the parser, that sounds like an ICE [00:06:57] <mru> yeah [00:07:28] <mru> I was just a bit surprised to see it [00:07:41] <mru> all I did was ask it to build for darwin [00:08:05] <mru> clearly I wasn't supposed to do that [00:08:11] <Sean_McG> heheheh [00:10:10] <roxfan> at least you didn't get "impossible happened" [00:10:20] <mru> actually, that's what it says [00:10:31] <roxfan> "The most irritating message while using ICL Algol 68 error was [00:10:31] <roxfan> Impossible Happened [00:10:31] <roxfan> Adding a blank card could fix the problem." [00:10:55] <mru> you sound old [00:11:04] <roxfan> i am quoting :) [00:11:15] <mru> ah, so you are [00:13:26] <Yuvi> mru: Sounds like an internal error in mc (the integrated asaembler$ [00:13:40] <mru> Yuvi: which one? [00:14:04] <Yuvi> The error interfacing with taeget maxhine [00:15:22] <peloverde> saintd3v: do we want to initialize the bit reservoir to the full 6144? [00:16:28] <Yuvi> And yeah, the ICE error messages aren't helpful to users; theyre stripped out of release builds even I think [00:17:18] <mru> the "interface with target machine" error is reported from EmitAssemblyHelper::AddEmitPasses() [00:17:37] <mru> which lives in clnag/lib/CodeGen/BackendUtil.cpp [00:20:53] <peloverde> also as far as num_bark does shouldn't we use calc_bark(sample_rate/2)? [00:24:29] <mru> Yuvi: it never gets as far as actually doing anything [00:24:50] <mru> if my interpretation of -debug-pass is correct [00:25:13] <mru> with working targets, -debug-pass=Executions prints lots of stuff [00:25:20] <mru> when this error occurs, it prints nothing [00:30:24] <peloverde> saintd3v: as far as the energy spreading stuff goes, is there a separate patch somewhere. Did I miss it? [00:34:33] <peloverde> also can you break out the parts that are just reorganizing code? Alternatively I can do it [00:34:43] <peloverde> I just don't want to screw up your patch set [00:59:54] <Sean_McG> why the hell does GNU Make swallow up $O from $ORIGIN in a Makefile? [01:00:26] <mru> $(name) [01:04:09] <lu_zero> fun... [01:04:35] * lu_zero is trying to convince ffmpeg to streamcopy an additional video track... [01:04:50] <Dark_Shikari> -vcodec copy -newvideo? [01:04:58] <Sean_McG> now it's trying to substitute for that variable... [01:05:21] <peloverde> saintd3v: maybe we should continue this discussion on a medium less ephemeral than irc [01:05:24] <lu_zero> Dark_Shikari: yup [01:05:26] <lu_zero> but [01:05:30] <lu_zero> after the filename [01:05:37] <lu_zero> Aaand [01:05:44] <Dark_Shikari> yup [01:05:56] <lu_zero> you might not get anything in the stream =P [01:07:32] <lu_zero> now I'm wondering what's wrong with it [01:07:36] <mru> Sean_McG: oh, you want $$ORIGIN then, if you want the $ literal [01:07:58] <Sean_McG> I do... and I just tried that but it's still substituting [01:08:00] <lu_zero> since using output_example to create nut files work well [01:08:26] <lu_zero> creating ts ones does not at all [01:19:28] <Compn> ffmpeg needs playlist/concat support [01:21:38] <lu_zero> Compn: first it'd need to have more sense =P [01:23:09] <saintdev> peloverde: hehe [01:23:39] <saintdev> i scared him off 0_0 [01:37:05] <saintdev> <peloverde> saintd3v: do we want to initialize the bit reservoir to the full 6144? <-- i didn't think so, but that's what i thought 3gpp did. however it does not. i was looking at the wrong variable. [01:37:39] <peloverde> ok [01:37:50] <saintdev> peloverde: also 6144 is per channel? [01:38:34] <peloverde> yes, per channel [01:41:30] <saintdev> num_bark - should be bandwidth (as the comment says), but we don't have a cutoff currently. so sample_rate/2 should be correct. [01:42:54] <saintdev> yes energy spreading is a separate patch, once i finished it, i realized it would be rather useless without the rest of this, so i was just going to combine the patches [01:43:58] <saintdev> most of the cosmetics are split out already [01:46:10] <peloverde> the last hunk of aacpsy.c looks purely cosmetic [01:46:47] <peloverde> or at least pure factorizing [01:47:00] <saintdev> yeah, it is that's already a separate patch [01:48:24] <saintdev> it was just easier to do git diff origin, than to specify a range [04:53:57] <peloverde> saintdev: cool [05:01:24] <peloverde> If you want to git send-email that and any of the other patches that are cosmetic or otherwise split out, it would be appreciated [05:28:47] <kierank> any idea if v210 can be SIMDed? [06:09:38] <spaam> God morgon :D [06:10:15] <kshishkov> god morgon [06:12:32] <pJok> god morgon [06:13:12] <kierank> hello [06:13:21] <kierank> top of the morning to you [06:13:56] <thresh> moroning [06:33:04] <Sean_McG> happy $TIMEZONE [06:44:18] <cartman> moin [06:44:50] <spaam> hey cartman. where is kenny? [06:45:01] <cartman> bastards killed him [06:45:10] <spaam> :( [06:45:22] <spaam> time to get to work .. bbl :) [06:45:27] <cartman> see ya [06:51:03] <saintdev> wow: ffmpeg -y -i ~/codecs/samples/comp.wav -strict experimental -acodec aac -ab 128k ~/test.mp4 [06:51:44] <saintdev> sounds ok [06:52:41] * saintdev needs new headphones [07:10:30] <divVerent> ffmpeg API "hint"... [07:10:48] <divVerent> av_rescale_q(av_rescale_q(x, LARGETIMEBASE, SMALLTIMEBASE), SMALLTIMEBASE, LARGETIMEBASE) == x [07:10:54] <divVerent> as long as LARGETIMEBASE >= SMALLTIMEBASE [07:11:00] <divVerent> this is currently true, but can I rely on this staying true? [07:11:13] <divVerent> (it follows mathematically from the round-to-nearest mode) [07:12:04] <divVerent> to prove this, simply disprove >= x+1 and <= x-1 ;) [07:12:49] <divVerent> I need this in my code to ensure both unique stream and codec timestamps to prevent encoding errors [07:13:12] <divVerent> my current code basically does frame skipping etc. based on the "worse" of the two time bases, and rescales to the other [07:14:07] <divVerent> and in case the worse time base is the stream time base, I have to rescale stream pts to codec pts before avcodec_encode_video, and rescale codec pts back to stream pts to feed libavformat from coded_frame [07:14:20] <divVerent> and this is where my assumption comes in [07:16:20] <divVerent> one case where this comes in is Matroska BTW... Matroska's timebase is milliseconds, and I need this "convert back and forth is fine" assumption in case the codec time base is better than 1000fps [07:24:12] <divVerent> the assumption is OBVIOUSLY true if codec time base divides the stream time base... but my question is: in the current implementation I can rely on the assumption, can I in the future? [07:33:46] <Tjoppen> why not use rational numbers? [07:40:15] <divVerent> because the pts field in AVFrame doesn't want them [07:40:39] <divVerent> basically, I have to ensure that the pts fed to libavcodec are monotonous [07:40:44] <divVerent> and the pts fed to libavformat are unique [07:41:16] <divVerent> so my only way is to already restrict the ones I pass to libavcodec [07:41:28] <divVerent> as I there is no direct correspondence between the frame fed into libavcodec, and the output [07:50:43] <spaam> mmm kall trocadero [07:54:52] <Tjoppen> ruggles: got some samples for you [07:56:12] <Tjoppen> if I put them on the ftp, can we get them up on samples.mplayerhq? [08:00:22] <kierank> samples of what? [08:00:44] <Tjoppen> lxf [08:00:59] <Tjoppen> one with 20-bit pcm, which is what ruggles is after [08:01:19] <kierank> lxf? [08:01:24] <kierank> or mxf? [08:02:12] <Tjoppen> lxf, yes [08:02:35] <kierank> never heard of that one [08:03:42] <Tjoppen> neither had I, nor had most of the internet. I managed to reverse engineer it [08:04:02] <Tjoppen> it's output by some broadcast gear made by harris [08:08:37] <spaam> whyyy cartman why ? [08:09:12] <cartman> spaam: I don't own a Mac :) It was given to me due to my current work [08:09:45] <spaam> cartman: you dont have to give it back? just say you d [08:09:48] <spaam> did that [08:10:12] <cartman> spaam: this is a special built 2.66 Core i7 device, costs ~3000$ [08:10:16] <cartman> they won't donate me that [08:10:42] <spaam> who said about donate? you can borrow it for loooong time :) [08:10:46] <cartman> LOL [08:10:53] <cartman> not here :) [08:12:18] <cartman> I hope they will let me "borrow" the Nexus1 though [08:14:45] <spaam> that is a old phone.. why whould they get that back? :) [08:15:06] <cartman> spaam: I am asking myself the very same question :P [08:15:18] <cartman> I need more generous $BOSS [08:45:44] <av500> gm [08:46:28] <kierank> hello [08:47:34] <cartman> av500: back from holiday? [08:49:19] <kshishkov> cartman: nope, that was work, now to holiday in Darmstadt office :) [08:49:40] <cartman> kshishkov: ah [08:49:46] <kierank> kshishkov: where did av500 go? bangalore? [08:49:47] <cartman> slacking as usual [08:50:27] <av500> cartman: yep [08:53:25] <kshishkov> kierank: do you want to visit Bangalore yourself? [08:53:37] <av500> kierank: I was there: http://maps.google.com/maps?f=q&sll=37.0625,-95.677068&sspn=70.0649,114.257… [08:53:54] <kierank> kshishkov: no but I thought av500 was the outsourcing expert [08:59:22] <kshishkov> lol - http://stbit.ru/index.php?option=com_content&view=article&id=5&Itemid=4&lan… <- if there weren't enough Russian wavelet-based codecs [09:00:13] <thresh> ты просто завидуешь [09:00:28] <kshishkov> ага, щазз [09:01:12] <kshishkov> помнится, знакомый профессор говорил: "не берись за вейвлеты, ими китайцы занимаются" [09:31:00] <saintdev> peloverde: you there? [09:31:08] <peloverde> pong [09:31:29] <saintdev> i caught a bug in bit demand calculation [09:32:09] <saintdev> ctx->frame_bits + size - bits [09:32:34] <saintdev> if the actual number of bits used is much greater than size, this goes negative [09:32:42] <saintdev> giving us a negative desired PE [09:32:50] <peloverde> ok [09:33:07] <peloverde> I thought I saw a check for that somewhere [09:33:11] <kshishkov> sounds very true to life [09:33:14] <peloverde> maybe it was something else [09:33:28] <saintdev> not sure how to fix it, because we need "the actual number of bits in the bitreservoir" [09:34:23] <peloverde> can you repost the url? [09:35:00] <saintdev> let me paste a new one, because i changed the initialization for bitres [09:35:06] <peloverde> ok [09:36:22] <peloverde> I hate that windows is so ununixy [09:36:29] <saintdev> peloverde: http://pastebin.com/rfpQh0y9 [09:38:00] <saintdev> afaikt what 3gpp does is "min(bit_factor, 1 - 0.3 + bitres_bits / frame_bits)" [09:38:29] <saintdev> which doesn't seem to have any logic to it that i can spot [09:38:47] <saintdev> and i refuse to put something i don't understand in, just because 3gpp does it [09:39:28] <peloverde> are we talking about near line 104 of the patch? [09:40:13] <saintdev> erm, line 104 is the modifications to AacPsyCoeffs... [09:40:43] <peloverde> I mean 148 [09:40:54] <peloverde> but I guess taht is init [09:41:02] <saintdev> that's the initialization of the bitres. [09:41:18] <saintdev> 226-256 is calculation of bit demand [09:41:18] <peloverde> int calc_bit_demand()? [09:41:22] <saintdev> yes [09:42:12] <saintdev> so for line 255 3gpp does: [09:42:50] <saintdev> return FFMIN(ctx->frame_bits * bit_factor, ctx->frame_bits * (1 - 0.3 + bits / ctx->frame_bits)) [09:44:49] <saintdev> ...which still leads to an infinite loop, wth [09:45:14] <saintdev> only this time desired pe is positive [09:47:49] <saintdev> maybe it's because of where i set bitres bits = frame_bits [09:48:54] <saintdev> ok, maybe that wasn't the issue... [09:49:52] <saintdev> i still see negative pe being an issue, because then it will attempt to zero every band. [09:50:39] <peloverde> What about section 5.6.4 Out of Bits Prevention? [09:51:37] <saintdev> that should happen in quant [09:52:41] <saintdev> psymodel ends at 5.6.1. 5.6.2+ is all quant [09:53:32] <peloverde> yes, but this bit demand being negative is a result of quant using too many bits, no? [09:53:54] <saintdev> which is fine, as we're using bits from the bit resevoir [09:55:17] <saintdev> or rather we _sould be_ using bits from the reservoir [09:55:49] <peloverde> But if 'bitreservoirBits' is negative doesn't that men we have used bits that aren't in the reservior? [09:58:14] <saintdev> i guess maybe this is where we need to reduce min snr, and allow more holes [09:59:56] <saintdev> ...or maybe not... [09:59:58] <saintdev> pe = 9.377437, desired = 3600.179932 [10:03:10] <saintdev> although obviously quant is having trouble fitting everything in one frame [10:04:09] <kshishkov> well, IIRC when file had a second of silence at the beginning it was even funnier [10:05:15] <saintdev> well i have a file with a lot of silence at the beginning (not sure exactly how long it is), but it handles that just fine. [10:06:01] <saintdev> it just seems to loop forever if it starts to go way over it's allocated bits [10:07:14] <saintdev> well i think i'm going to come back to this tomorrow, can't think right now. [10:07:32] <saintdev> i really don't want to have to rework quant...yet [10:16:13] <spaam> which version of gcc did came with -march=native ? :) [10:19:03] <kierank> google says 4.2 [10:19:52] <spaam> Nice [10:20:31] <spaam> then i can use it with portage on my macbook pro :) [10:21:49] <kshishkov> huh, so gcc couldn't produce native code before 4.2? [10:22:32] <Flameeyes> kshishkov: -march=native is "auto-tuning" [10:23:01] <lu_zero> kshishkov: -march=native is -march=guess-what-are-you-running-on [10:23:15] <cartman> uses rand() [10:23:25] <kshishkov> and pleases Gentoo users [10:23:28] <kierank> cartman: rand() produces a major improvement [10:23:47] <Flameeyes> it's more or less the same as -march=$yourcpu plus parameters' tweaking based on cache size of the currently-used CPU [10:24:04] <lu_zero> kshishkov: so they don't have to guess for themselves what's their cpu [10:24:08] <Flameeyes> not fantastic, but makes it easier to share the same _configuration_ between two hosts [10:25:06] <kshishkov> lu_zero: laaaaame [10:25:11] <peloverde> -march=core2 ought to be good enough for anybody [10:25:56] <kshishkov> not on my Cortex-A8 [10:26:07] <peloverde> fair enough [10:26:24] <cartman> -march=coretexa8 :p [10:27:29] <kierank> -march=placebo [10:27:30] <JEEB> I remember -march=i386 making faster binaries than core2 the last time marcan tested it :3 [10:28:00] <kierank> -march=placebo -mtune=grain [10:29:06] <spaam> :) [10:29:45] <kshishkov> kierank: -mtune=benny-lava [10:30:34] * kierank googles that [10:31:22] <kierank> I don't get it [10:31:28] <kshishkov> http://www.youtube.com/watch?v=ZA1NoOOoaNw [10:32:20] <kierank> yeah but what's that got to do with -mtune? [10:32:22] <peloverde> JEEB: that seems off seeing as i386 lacks sse2 and every benchmark I've seen has scalar sse2 kick x87's ass [10:32:59] <kierank> kshishkov: at least mine was a reference to x264 [10:33:01] <kshishkov> kierank: it's quite fine tune. And words make little sense (like GCC tuning) [10:33:17] <kierank> ah [10:34:04] <JEEB> peloverde, yes -- by all marks it _seems_ off, I'll have to see if I have the things he tested it with still somewhere in my browser's memory [10:35:10] <peloverde> I think if -O3 is on -ftree-vectorize is on which is generally terrible [10:36:15] <peloverde> i386 shouldn't generate bad vector code because i386 lacks vector instructions [10:47:54] <iive> it's kind of strange, i386 doesn't issue cmov and in theory should increase mispredictions a lot. i686 should issue cmov and not turn on sse by default. [10:49:07] <Flameeyes> iive: are you sure i686 turns on cmov? [10:49:26] <iive> yep [10:50:11] * av500 wonders if it's wise to read the -devel backlog before lunch [10:51:02] <kshishkov> av500: nothing special there, just filter out usual flames [11:31:33] <kierank> anything look wrong with this get buffer implementation: http://pastebin.com/Q05nP9VC [11:33:32] <mru> would you be asking if there wasn't? [11:33:52] <kierank> no [11:36:32] <mru> the pic->age value looks wrong [11:36:40] <mru> I have no idea what it means [11:36:55] <mru> but I had to duplicate the magic from default_get_buffer() to make it work [11:37:39] <iive> sequential number used to skip mc if the data hasn't changed [11:38:02] <mru> it's not documented [11:38:08] <mru> and totally nonobvious what it does [11:38:46] <mru> cartman: you're friendly with clang, right? [11:38:51] <kierank> avcodec.h says "Set to INT_MAX if the buffer has not been used yet." [11:39:05] <cartman> mru: for some definition of "friend", yes [11:39:26] <mru> cartman: any idea if backends other than x86 and arm are expected to work at all? [11:39:45] <mru> I get "error: unable to interface with target machine" when trying to cross-compile to anything else [11:39:48] <cartman> mru: the answer would be no, afaik [11:39:53] <mru> and segfault when running natively on ppc [11:40:06] <cartman> ppc one should be reported probably [11:40:20] <cartman> but Apple i [11:40:24] <cartman> is dropping PPC support [11:40:32] <cartman> so I wouldn't be surprised [11:40:46] <mru> and the mips backend looks like a complete joke [11:40:56] <cartman> some of them are toys afaik :) [11:42:53] <Kovensky> 08:40.20 cartman: but Apple is dropping PPC support <-- finally? [11:43:09] <kierank> hehe even vlc doesn't know what to do with age [11:43:32] <cartman> Kovensky: in 10.7 yeah [11:43:46] <Kovensky> wasn't 10.6 intel-only btw? [11:43:56] <mru> they have ppc emulation iirc [11:43:59] <cartman> Kovensky: true but it supported PPC emulation [11:44:03] <Kovensky> oic [11:44:14] <Kovensky> it isn't installed by default though [11:44:16] <cartman> no moar ppc for you [11:44:33] <Kovensky> I don't even know why I installed Rosetta, it's not like I have any PPC apps [11:44:38] <Kovensky> lul [11:44:54] <cartman> Kovensky: got MS Office? [11:45:04] <Kovensky> pirated 2011 [11:45:25] <cartman> possibly it installed Rosetta [11:45:27] <cartman> I think [11:45:45] * cartman pets his valid M$ licenses [11:45:52] <Kovensky> well, I installed Rosetta myself on the custom install options for OSX's setup =p [11:46:13] <Kovensky> my OSX doesn't have a valid license either =p [11:46:18] <Kovensky> >10.6.3 iso from tpb [11:46:19] <cartman> bah [11:46:22] <Kovensky> >installed on non-apple hardware [11:46:48] <cartman> I bet you pirate ffmpeg too!!111!! [11:46:56] <Kovensky> hah [11:47:54] <mru> why would anyone voluntarily install osx? [11:48:14] <Kovensky> I wanted a unix with a non fucked up GUI [11:48:29] <mru> so fail on both accounts [11:48:48] <pross-au> why would anyone voluntarily wear a turtle neck sweater [11:48:58] <mru> they cause cancer [11:50:19] <Kovensky> 08:48.30 mru: so fail on both accounts <-- how so? it's a unix, and the GUI isn't like X's clusterfuck of incompatible and mostly ugly GUI toolkits [11:50:51] <mru> mach is not a unix [11:51:12] <mru> the true unixes are sysv and bsd and their derivatives [11:51:31] <Kovensky> didn't apple pass mach through SUS [11:51:39] <Kovensky> the SUS certification that is [11:51:43] <mru> macos is a conglomerate of microkernel with bits of bsd and some homebrew stuff bolted on in a haphazard fashion [11:51:54] <cartman> it works ;> [11:51:57] <mru> I disagree [11:52:41] <cartman> I'll format this Mac soon and give it away, so I'll agree this time :P [11:52:45] <lu_zero> 12:47 < Kovensky> I wanted a unix with a non fucked up GUI [11:52:56] <lu_zero> I'd debate on the gui part [11:53:22] <mru> osx may pass the certification tests, but it's not a unix in spirit [11:53:23] <lu_zero> regarding the "unix" I'd say that Haiku is as unix as macosx... [11:53:46] <cartman> Mac is eyecandy and some people love that [11:54:05] <cartman> I'd be happy if Linux just provided ClearType like font rendering, rest is useless for me [11:54:26] <mru> I'm quite happy with my 8-point non-aa fonts [11:54:29] <av500> cartman: you need cleartype for 5x7 fonts? [11:54:30] <Kovensky> 08:52.57 lu_zero: I'd debate on the gui part <-- I'm not arguing that Aqua is prettier than everything else; I'm arguing that it at least is consistent [11:54:35] <cartman> av500, mru bah [11:54:56] <mru> consistently annoying [11:55:07] <cartman> neeed better font rendering [11:55:29] <Kovensky> mru: as opposed to X, which is inconsistently consistently annoying [11:55:43] <elenril> >itt people having no clue what X is [11:56:00] <mru> what elenril said [11:56:07] <cartman> X [11:56:15] <cartman> X & Y comes with Math. :p [11:56:15] * Kovensky sees a bikeshed [11:56:28] <pJok> mru, don't forget a lot of NeXT stuff [11:56:31] * cartman paints it black [11:57:25] <pJok> i see a bikeshed and i want to paint it black? [11:57:49] * pJok thinks that the song from Rolling Stones originally was about bikesheds [11:58:03] * mru was thinking about that song too [11:58:43] <lu_zero> Kovensky: having used it I must say that Aqua is as inconsistent as other toolkits... [11:58:46] <av500> "... I see the votes go by..." [11:58:53] <lu_zero> that said [11:59:47] <lu_zero> is there a particular reason why mpegts isn't outputting the fake teletext data I'm putting? [12:00:03] * lu_zero inspected the generated file and the data is there... [12:00:05] <pJok> mru, friend of mine was looking around at itunes, found some 20 year old api references [12:00:28] <av500> pJok: iturns20 [12:00:55] <kierank> lu_zero: do you write the correct descriptors [12:00:58] <pJok> i think it was Quartz [12:03:02] <lu_zero> kierank: good question [12:03:07] <lu_zero> I hacked it up [12:03:35] <kierank> until there's a descriptor it's just private data [12:04:14] <lu_zero> http://ffmpeg.pastebin.com/mYYntQY6 [12:04:26] <lu_zero> kierank: private data would be fine as well [12:04:38] <lu_zero> (given that it would be outputted) [12:04:52] <Kovensky> 08:58.44 lu_zero: Kovensky: having used it I must say that Aqua is as inconsistent as other toolkits... <-- I wasn't referring to internal inconsistency (which is mostly unseen on most software, at least software that I've used), the main annoyance I have with software that targets X is that there are so many toolkits to chose from [12:04:57] <Kovensky> Tk, GTK, FLTK, wx, Qt, Swing, and if you run anything that doesn't use the same toolkit as everything else you're running it will instantly look out of place, even if you have a theme design to emulate another toolkit [12:05:03] <Kovensky> +ed [12:06:56] <elenril> ....choose programs using the same toolkit if you care so much? [12:07:21] * pJok hands Kovensky the bikeshed and paint [12:07:47] <Kovensky> elenril: doesn't make the issue go away, and you don't always have a choice [12:08:11] <Kovensky> (other than TakingTheThirdOption of not using it at all, but that's silly) [12:08:36] <mru> and on osx it doesn't exist at all then [12:09:51] <Kovensky> it exists, but is rather rare [12:10:20] <Kovensky> in 4 months of using osx I've only encountered pcsx2, desmume and wireshark that don't follow the interface [12:10:53] <Kovensky> well, and jdownloader, because it insists in using custom swing skins, and clementine, for being a not-so-good qt4 port of amarok [12:11:16] <mru> on X11 you get a choice of sticking with one toolkit for consistency or using whatever apps work best regardless of look [12:11:24] <mru> on osx you only get one choice of toolkit [12:11:36] <mru> so the apps using other toolkits are simply not available [12:12:12] <Kovensky> pcsx2, desmume and wireshark all use gtk [12:12:22] <Kovensky> with the fucking ugly raleigh theme <_< [12:12:39] <Kovensky> clementine uses qt4-aqua [12:12:50] <elenril> can i have some reviews for avio_get_str? [12:47:39] <mru> elenril: is skip(n) any different from seek(n, SEEK_CUR)? [12:48:45] <kshishkov> maybe in behaviour over non-seekable streams [12:50:07] <mru> that would be crazy [12:50:15] <mru> I think skip should be replaced with seek [12:50:33] <kshishkov> made into macro? [12:50:34] <mru> and seek updated to handle non-seekable streams in that special case if necessary [12:51:58] <elenril> only in return value it seems [12:52:46] <elenril> seek returns new position or error, skip returns 0 or error [12:53:53] <elenril> fun fact: seems the return value isn't used anywhere [12:54:12] <kshishkov> of course [12:55:06] <kshishkov> reminds me of one of paranoic definitions - always checks if file was closed successfully [12:55:15] * av500 skips elenril [12:55:39] <hyc> well, close() can fail on NFS [12:56:05] <Flameeyes> hyc: and how do you recover from that? [12:56:20] <hyc> no way I know of [12:56:26] <mru> hyc: and many other ways [12:56:44] <Flameeyes> so the question is: "why testing an error at all if you cannot recover from it?" [12:56:55] <mru> you may not be able to recover, but alerting the user that something went wrong is still nice [12:57:00] <hyc> you can re-open and re-write [12:57:44] <av500> hyc: if you still have the data [12:58:08] <av500> which at the time you call close() you might not have [12:58:30] <hyc> true [13:04:29] <BBB> kshishkov: any progress? [13:05:02] <BBB> kshishkov: ref decoder does weird frame ordering also, looks really weird, as if the bitstream itself )or the encoder) is broken [13:05:18] <kshishkov> BBB: so you can't accuse me [13:05:27] <BBB> well [13:05:32] <BBB> did you look at it? [13:05:59] <kshishkov> nope, your message was soothing [13:06:04] <BBB> hm... [13:06:24] <kshishkov> if ref decoder does the same then it's right by definition [13:06:28] <kierank> BBB: you'd probably know the answer to why this is broken: http://pastebin.com/Q05nP9VC [13:07:39] <BBB> nope [13:07:54] <kierank> :/ [13:12:13] <BBB> sorry, I'm not familiar with the get_buffer stuff [13:12:42] <kshishkov> and why not just compare it to default implementation [13:12:57] <kierank> because default implementation does a ton of bizzare things [13:15:17] <kierank> I'm starting to think libavutil might be broken [13:15:31] <kshishkov> :) [13:17:25] * kierank doesn't want to give in and use memcpy [13:50:18] <DonDiego> kshishkov: what's the point you see in keeping sonic? [13:57:39] <lu_zero> DonDiego: it's an interesting codec IMHO [13:57:56] <lu_zero> yet would be nice implementing CELT [13:58:05] <mru> it's not interesting if it doesn't work [13:58:18] <DonDiego> i don't doubt it, but ffmpeg is not the place to carry interesting experimental research codecs [13:58:41] <DonDiego> not in the master branch that is, people are of course welcome to play with them in priv branches [13:58:54] <mru> on that note, how about dropping snow? [13:59:11] <DonDiego> same sentiment from my side [13:59:28] <merbzt> snow works [13:59:37] <merbzt> sonic doesnt [13:59:37] <mru> perhaps [13:59:43] <DonDiego> snow may even have a few samples in our collection, but i see little point in it also [13:59:58] <mru> snow is still an abandoned, experimental codec [14:00:04] <merbzt> same as with alot of game formats [14:00:04] <DonDiego> it's also one huge drop of monolithic mn-style code... [14:00:10] <merbzt> should we drop them also ? [14:00:19] <DonDiego> game formats are used in the wild [14:00:26] <DonDiego> and samples exist [14:00:43] <elenril> well there are people playing with snow [14:00:44] <merbzt> snow samples exist also [14:01:22] <merbzt> just mark snow as experimental if it isn't already [14:01:47] <DonDiego> of course there are people playing with it - so? nobody doubts that people out there are doing codec research [14:02:03] <DonDiego> but mainline ffmpeg is not the place to carry such stuff, much less indefinitely [14:02:10] <mru> snow uses lots of dubious programming practices that are hard to fix [14:02:22] <kshishkov> mru: and wavelets! [14:02:26] <DonDiego> same applies to nut really - it never made it past the toy stage [14:02:28] <lu_zero> snow is still good [14:02:36] <lu_zero> DonDiego: I'm using nut in production... [14:02:43] <lu_zero> please let it be ^^; [14:02:49] <DonDiego> glad to hear that [14:02:53] <DonDiego> which implementation? [14:02:56] <mru> nut can stay [14:02:58] <lu_zero> ffnut [14:03:04] <av500> nutjobs.org [14:03:09] <DonDiego> last i talked to ods15 about it libnut and ffnut disagreed [14:03:15] <mru> it's not a huge burden, and it's useful for regression testing [14:03:30] <elenril> snow is a huge burden? [14:03:35] <lu_zero> and I think snow should stay till we get dirac or jpeg2k [14:03:47] <DonDiego> snow takes ages to compile [14:03:53] <lu_zero> then we could reconsider it [14:04:17] <Flameeyes> saste: which ld version are you using? [14:04:33] <lu_zero> DonDiego: the next code in we could ask help to document both [14:05:02] <kshishkov> DonDiego: I've just tried encoding and decoding Sonic-in-NUT and it worked fine [14:05:11] <saste> Flameeyes: GNU ld (GNU Binutils for Debian) 2.20.1-system.20100303 [14:05:25] <Flameeyes> saste: uhm... funny [14:05:43] <Flameeyes> I wonder if Debian patched it up [14:07:25] <kshishkov> DonDiego: Sonic in .mkv works fine too [14:08:08] <lu_zero> where is broken then? [14:09:02] <DonDiego> it's still just a toy, what's the point of it? [14:09:24] <DonDiego> saste: i think you have a bunch of patches for me to review, could you point me at some of them? [14:09:29] <lu_zero> DonDiego: same could be said with vorbis before the atouv effort [14:09:48] <kshishkov> DonDiego: it give us two audio codec in stats [14:10:41] <lu_zero> and I think that experimental codecs are good to show and test the ffmpeg as codec toolkit [14:11:05] <saste> DonDiego: Add detail to the documentation for ffmpeg -map [14:11:39] <saste> then there are the filters which have been already pushed to videolan [14:12:41] <saste> nut is useful... it's the only format which supports rawvideo with all the supported ffmpeg pixel formats [14:12:57] <mru> yes, nut is useful for such reasons [14:12:58] <lu_zero> among the rest [14:13:40] <DonDiego> very well, nut topic closed then, that leaves snow and sonic :) [14:13:49] <elenril> let's vote! [14:13:53] * elenril ducks [14:14:09] <kshishkov> DonDiego: they are featured codecs for NUT [14:14:09] <saste> on the other hand... snow is interesting from the research point of view [14:14:12] <DonDiego> better - let's vote *right away* before discussion... [14:14:32] <saste> maybe a good idea would be to fund more work on it.. it was proposed some years ago and then discarded [14:14:47] <saste> at that time there was a guy which was willing to fund it [14:14:55] <saste> at least in part (2k iirc) [14:15:19] * elenril recalls Dark_Shikari claiming that wavelets are doomed [14:15:29] <mru> they are [14:15:56] <Dark_Shikari> if you want to do a research codec, go work on that CELT/lapped DCT hybrid codec thing. [14:16:14] <kshishkov> especially if you want research video codec [14:17:02] <saste> Dark_Shikari: i have no serious knowledge related to DSP/codec compression technology [14:17:11] <saste> Dark_Shikari: so my opinion doesn't count [14:19:32] <lu_zero> wavelets are different, so different problems and different solutions [14:19:46] <lu_zero> still I liked a lot the lift optimizations =p [14:20:19] <lu_zero> regarding celt it looks really promising [14:20:40] <Dark_Shikari> The only "CELT-like" part of the lapped DCT thing is just the separate energy/shape coding [14:22:02] <lu_zero> Dark_Shikari: are you willing to mentor a summer of code to have an initial toy about it? [14:22:23] <Dark_Shikari> There's already a WIP prototype by the xiph guys that is busy not being worked on [14:22:37] <DonDiego> saste: your patch or the ones sent by mike scheutzow? [14:23:12] <saste> DonDiego: i addressed some of the issues raised by BBB [14:23:31] <saste> DonDiego: so the last patch of the thread [14:26:56] <lu_zero> Dark_Shikari: would make sense being re-implemented on ffmpeg? [14:27:21] <Dark_Shikari> It's still hacky research stuff, dunno [14:33:46] <CIA-15> ffmpeg: Mans Rullgard <mans(a)mansr.com> master * r00ba041cb3 ffmpeg/configure: [14:33:46] <CIA-15> ffmpeg: Use --sysroot flag for clang [14:33:46] <CIA-15> ffmpeg: Although not documented, clang does support the --sysroot flag, and it [14:33:46] <CIA-15> ffmpeg: does the right thing. Use this flag intead of -isysroot which only [14:33:46] <CIA-15> ffmpeg: applies to header file searches, not the linker. [14:33:47] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans(a)mansr.com> [14:34:09] <ruggles> the description of Bonk, which Sonic is based on, sounds very similar to wavpack lossy but without the lossless correction data. nothing about it looks particularly cutting-edge compared to anything being done today. [14:34:55] <mru> bink version o = bonk? [14:35:21] <kshishkov> ruggles: look at the date ;) [14:35:40] <kshishkov> mru: no, 'twould be Australian Binko [14:35:57] <ruggles> 2001 [14:37:06] <ruggles> i suppose that was pretty experimental in '01. but why should we try to imitate it now? or fix our broken imitation? [14:37:42] <kshishkov> why do you call it broken? [14:37:57] <ruggles> it doesn't work for me. [14:38:04] <kshishkov> it does for me [14:38:39] <mru> sonic.c has had exactly one non-cosmetic/maintenance commit [14:38:52] <kshishkov> initial? [14:38:54] <mru> yes [14:39:01] <mru> that was in 2004 [14:39:24] <mru> just kill it [14:39:32] <mru> it is clearly nothing but a maintenance burden [14:41:21] <lu_zero> with a message like [14:41:23] <ruggles> kshishkov: hmmm it does seem to be working now. i don't know why it didn't work for me before. [14:41:35] <lu_zero> "superceeded by wavpack" ? [14:41:47] <kshishkov> ruggles: maybe it was shy? [14:42:02] <ruggles> ah, that's it. doesn't support 48kHz but doesn't fail. [14:42:28] <lu_zero> if it is working I'd rather have it preserved or ask first if somebody would have interest on it [14:43:08] <lu_zero> otherwise I'd just add a branch for it called historic [14:45:44] <ruggles> i'm not interested in it, but i'm ok with keeping it around. maybe flag it as experimental though. [14:46:23] <kshishkov> definitely [14:48:13] <mru> nobody is every going to touch it again, much less use it [14:48:18] <mru> -y [15:05:05] <kshishkov> it's the only hybrid lossy/lossless encoder we have [15:05:39] <spaam> does sonic work ? [15:05:43] <kshishkov> yep [15:06:57] <spaam> then why remove it if it still work ? why do files need love every year? :) [15:07:05] <lu_zero> then might be worthy as foundation [15:07:09] <kshishkov> because API changes [15:07:29] <lu_zero> kshishkov: anything could be used to implement a wp encoder? [15:07:33] <ruggles> i fixed the sample rate issue. it's a bug. but a simple one. i'll send a patch. [15:08:01] <kshishkov> lu_zero: yep, original BSD-licensed WavPack sources should do [15:08:10] <kshishkov> lu_zero: and ruggles for implementor ;) [15:10:03] <ruggles> there is a lot on my plate, but if a wavpack encoder would be wanted by enough people and the foundation would provide enough money, i would definitely consider doing it after i finish ac3. [15:11:33] <spaam> ruggles: how much work is left on ac3? :) [15:11:55] <lu_zero> ruggles: sounds like a plan =) [15:12:04] <ruggles> spaam: maybe a month if i'm lucky. 2 months if i'm not. [15:12:48] <spaam> ruggles: ok :) not that far away then :) [15:18:45] <DonDiego> spaam: for some reason code rots if you don't touch it - never noticed how it gets uglier on its own from year to year? [15:19:14] <kshishkov> DonDiego: it's just the rest of environment improving [15:19:56] <kshishkov> DonDiego: so for enterprise code it's the other way round - while other code gathers ugly hacks that one stays clean and nice looking fresh from India [15:48:59] <astrange> why do we need a wavpack encoder if flac exists? [15:49:44] <merbzt> the hybrid thingy [15:49:54] <merbzt> but I don't really see the point either [15:50:02] <mru> dts-hd or whatever variant [15:50:33] <Tjoppen> meh. just add a lossy option to the flac encoder [15:50:35] <mru> but there's nothing inherently good about a hybrid design [15:50:53] <kshishkov> astrange: and I heard that WV has better 7.1 support than Flac [15:51:10] <mru> the _only_ reason to use a hybrid codec is for adding an optional lossless layer to an existing lossy codec [15:51:31] <astrange> http://wiki.hydrogenaudio.org/index.php?title=Lossywav [15:52:06] <kshishkov> mru: for DTS-HD it's DCT codec + lossless residue, for WavPack and Sonic it's the same compression algorithm but with lossy coding of prediction errors [15:52:29] <mru> and what's the point? [15:52:36] <mru> does it gain anything other than complexity? [15:52:52] <kshishkov> it has almost no overhead [15:53:10] <kshishkov> and lossy part doesn't feature usual DCT artifacts [15:53:38] <ruggles> put the lossy part on your portable media player? i actually have one that supports wavpack. [15:54:30] * av500 has a portable media player with a 500GB hard drive [15:54:39] <ruggles> ...but i still use separate flac & mp3 files [15:58:12] <ruggles> only somewhat important benefit i can see is to reduce storage complexity. avoid having 2 sets of files (and metadata) for lossless and lossy. but there are other more standardized solutions like mpeg4-sls. [16:29:46] <kshishkov> well, I'd mourn Sonic for a few nanoseconds if you remove it [16:37:54] <in3xes> while demuxing, ffmpeg doesn't process audio and video packets differently? Both are just packets right? [16:41:08] <Tjoppen> well, there's parsers. and things like the dv demuxer which treats audio a bit special [16:42:42] <ruggles> in3xes: depends on the format too. The demuxer creates the packets, so it might have to do different things to create audio vs. video packets. [16:43:38] <Tjoppen> "it depends" [16:45:02] <in3xes> Okay. [16:46:07] <in3xes> Then how a parser finds whether a chunk of data is audio or video? [16:46:40] <av500> ffplay.c [16:47:01] <av500> well, the demuxer knows that from the file format it demuxes [16:47:01] <Tjoppen> the demuxer says what codec each stream is, and may or may not elect to use a parser per stream [16:47:32] <av500> in3xes: what are you after? [16:48:18] <in3xes> right now, for vivo demuxer, but in general for knowledge... [16:51:03] <in3xes> So, each stream needs different codec to decode it, basically audio and video are different streams...right? [16:52:06] <twnqx> right [16:54:03] <in3xes> I am a bit confused about how streams and packets are linked, can anyone enlighten me? Please? [16:54:45] <twnqx> umm multiple packets form a stream? [16:55:37] <av500> in3xes: audio and video has frames [16:58:01] <in3xes> av500: each frame is a packet? [16:59:43] * in3xes feels dumb :-| [17:00:22] <ruggles> in3xes: usually yes. but there are some cases where the demuxer can't determine where frames start/end so a separate parser is required to separate the series of packets into a series of frames. [17:00:27] <av500> in3xes: yes, in most containers [17:01:10] <av500> in3xes: just imagine you are given 2 series of audio and video frames, how would you "package" them? [17:01:44] <mru> chop them up into tiny pieces and throw them in a pan with some oil [17:01:45] <in3xes> one after after another mentioning size and type of each frame? [17:02:06] <in3xes> OH [17:02:09] <av500> in3xes: you just invented a simple muxer [17:02:13] <av500> e.g. .flv [17:02:32] <av500> add the timestamp and you are done [17:02:55] <in3xes> Okay [17:03:04] <ruggles> mru: making me hungry... time for lunch [17:03:24] <av500> ruggles: go eat some audio packets then [17:04:11] <mru> mpeg stir fry, yummy [17:04:17] <in3xes> One last question: Why is the max_stream number is 20? [17:04:35] <mru> it won't be for long [17:04:59] <av500> in3xes: because nobody will needs more then 20 streams, ever [17:05:02] <Tjoppen> the limit will be removed in the next minor bump [17:05:05] <Tjoppen> (right?) [17:05:09] <Tjoppen> *major [17:05:11] <mru> yes [17:05:26] <in3xes> I mean, why not just 2? [17:05:45] <bilboed-pi> multi-audio files [17:05:50] <Tjoppen> and subtitles [17:05:56] <in3xes> Oh, Okay [17:05:57] <Tjoppen> and "data" stream. etc [17:05:59] <av500> and album art [17:06:09] * bilboed-pi slaps in multiplexed mpeg-ts just for kicks [17:06:20] <Tjoppen> yes, ts can have hundreds [17:06:32] <Tjoppen> hell, even avi supports 100 streams [17:06:33] <mru> 1<<13 give or take [17:06:37] <av500> we should make stream_count a float [17:06:49] <bilboed-pi> mru, 0x1fff can't be used [17:06:54] <mru> that's the take [17:06:58] * bilboed-pi nods [17:07:00] <mru> and 0 is reserved for pat [17:07:03] <mru> and pmt needs one [17:07:13] <mru> so (1<<13)-3 [17:07:23] <mru> dvb reserves a bunch more too [17:09:52] <in3xes> Thank you all :) [17:24:54] <astrange> http://astrange.ithinksw.net/clang/ffmpeg/ ran out of curiosity [17:25:17] <astrange> the logic errors are all noise that's not worth reading, but dead code might be worth something [17:34:22] <peloverde> Some of the "This statement is never executed" seem strange [17:34:41] <mru> totally outrageous is more accurate [17:35:04] <astrange> i think i'd just ignore everything it says that involves a loop [17:35:19] <mru> ok, there goes 102% of the code [17:35:41] <peloverde> at least the general logic errors are generally related to variables that are technically mutable but don't change across multiple loop passes [17:49:06] <ods15> 16:03:09 <@DonDiego> last i talked to ods15 about it libnut and ffnut disagreed [17:49:22] <ods15> wow, i don't remember at all what the discrepencies are... [17:50:00] <ods15> I do remember for certain that I kept "nut_version 2" in libnut to force it to be non-compliant, and the spec says that the only supported version is 3... [17:50:37] <mru> my /dev/random disagrees with yours [17:50:59] <ods15> :) not sure what you meant there [17:51:10] <ods15> i usually use /dev/urandom anyway :P [17:51:18] <mru> you mentioned a spec... [17:51:31] <mru> I find /dev/random easier to understand [17:51:36] <ods15> well, do you consider ffnut to be /dev/random ? [17:52:04] <av500> [vc1 @ 0x8098360]Interlaced WVC1 support is not implemented [17:52:09] * av500 glares at kshishkov [17:52:28] <ods15> eh, cmon, i've seen worse... maybe i'm blind to it as i know nut very well, but i think it wasn't that bad... [17:52:43] <mru> the spec is incomprehensible [17:53:18] <mru> I've tried several times to read it but had to give up [17:53:38] <av500> the nut spec? [17:53:47] <mru> it's random blathering mixed with pseudocode of undocumented syntax [17:53:49] <JEEBsv> it makes you go nuts [17:53:52] * JEEBsv ducks [17:54:34] <iive> av500: I think you can only make him finish it, if you threaten him with extradition (for real). [17:54:59] <av500> iive: extradiction *to* Real will help even more [17:55:17] * ods15 looks up extradiction [17:55:36] <av500> ods15: a free plane flight with a bag over your head [17:55:42] <ods15> yeah, got it [17:56:24] <gnafu> Actually, "extradiction" might be something like super enunciation. "Extradition," on the other hand, would be what av500 said. [17:56:28] * gnafu ducks. [17:56:48] <iive> av500: no, that's rendition. extradition is without bag. [17:58:28] <av500> iive: so one can watch the movie? [17:59:14] <iive> av500: sure if the tv and headphones work. [18:07:47] <ods15> ok i don't understand match_time_delta ... [18:09:04] <ods15> i can only guess that it is related to streaming, because i remember michaelni wanted some timestamp thing for streaming (iirc it was about setop boxes clocks staying synced to encoder clock), but i don't see how it is realted or what this match_time_delta is supposed to do... [18:09:57] <av500> PCR [18:10:03] <av500> like PCR in TS [18:10:43] <av500> ah no [18:15:47] * elenril couldn't understand how index in nut works last time he looked at it [18:23:50] <ods15> elenril, yeah, i JUST looked at that code.. and, well, i admit it's a bit of a over-complicated compression algo, but it is not a big deal... [18:24:43] <ods15> took me about a minute, but i managed to figure out again what it means... [18:25:12] <elenril> maybe because you wrote it =p [18:25:15] <ods15> i admit, that's not a fair test, since i wrote (parts of) it, but it was quite a few years ago it [18:25:29] <ods15> caught me in mid type :) [18:25:52] <elenril> you can expect any kind of intelligence from people writing demuxers [18:25:56] <elenril> *can't [18:26:44] <ods15> i don't really expect anything at all :) i'm not really interested in this anymore [18:27:08] <ods15> i am actually interested, from a pedagogial point of view, how it could be written better... [18:28:11] <ods15> i think it should have a comment right before it: "WARNING: the following pseudo code is an obfucated semi-compression algo..." [18:29:34] <ods15> besides that, not sure what more should be done... it's already pretty much the C code that it ought to be anyway (the code in libnut/demuxer.c is the same almost line-for-line), so understanding it is not really a prequisite for implementing it... [18:34:41] <elenril> BBB: i don't think making a macro for seek(SEEK_CUR) is a good idea [18:47:26] <BBB> elenril: uhm... ok, I guess, just changing all functions is fine also [19:12:48] <BBB> kshishkov: I guess the frame or MB layer in vc1 has no way to specify what the last mbrow is for a slice? the only thing I can think of right now is tot est that we're atthe end of the input buffer after each mbrow [20:15:54] <mru> hmm, which compiler shall we torment today? [20:18:09] <andoma> http://en.wikipedia.org/wiki/Lattice_C [20:22:59] <saintdev> Turbo C [20:23:41] <mru> real ones please [20:24:24] <Dark_Shikari> Borland [20:24:33] <saintdev> Dark_Shikari: that's Turbo C [20:24:41] <Dark_Shikari> Oh, yeah. [20:24:45] <Dark_Shikari> QBASIC [20:24:47] * Dark_Shikari runs [20:25:41] <elenril> msvc? [20:26:14] <mru> I said real [20:26:30] <saintdev> i think you need to better define real [20:28:48] <mru> something people use and has a fighting chance of building ffmpeg [20:29:18] <elenril> BBB: what's up with -mt? [20:29:35] <saintdev> according to wikipedia, lots of people use Turbo C [20:29:50] <saintdev> "It has since been widely adopted for educational use, especially in India" [20:29:50] <JEEBsv> lol [20:29:53] <JEEBsv> ah yeah [20:29:59] <JEEBsv> Yeah, I know Indians who use it :/ [20:30:06] <saintdev> JEEBsv: lol [20:30:54] <JEEBsv> But it's really easy to get them to other compilers when their lecturer or whatever doesn't expect only Turbo C [20:41:33] <BBB> astrange: what's up with ffmpeg-mt? [20:41:40] <BBB> elenril: waiting for astrange to fix his patch after I told him how to :-p [20:41:55] <elenril> why don't you fix it yourself =p [21:04:58] <astrange> i'll do it now [21:05:54] <astrange> can you apply patches when i just reply to the thread about them? typing out the send-email command takes a while [21:08:55] <spaam> mru: pcc? [21:09:18] <BBB> astrange: yes [21:09:23] <BBB> astrange: and thank :) [21:09:25] <BBB> +s [21:11:31] <mru> spaam: already tried [21:11:32] <mru> it failed [21:12:00] <mru> too many ICEs in critical places for workarounds too [21:14:26] <spaam> mru: watcom ? [21:14:37] <spaam> http://en.wikipedia.org/wiki/Watcom_C_compiler [21:14:57] <saintdev> djgpp [21:15:09] <mru> djgpp is gcc [21:15:20] <saintdev> oh, didn't know that [21:15:21] <mru> and isn't that what's behind fate/dos? [21:15:41] <lu_zero> mru: did you report pcc people the issues? [21:15:43] <lu_zero> btw [21:15:47] <lu_zero> tcc ? [21:15:52] <wbs> mru: yes, djgpp is behind fate/dos [21:16:09] <spaam> mru: int? [21:16:11] <spaam> cint [21:16:57] <spaam> it was a interpreter . [21:17:21] <Flameeyes> fate/dos? [21:17:28] <spaam> tcc? [21:17:56] <saintdev> Flameeyes: my thoughts exactly [21:18:11] <Flameeyes> saintdev: my thoughts are "dos fate is to die"... [21:18:21] <Flameeyes> dos's [21:18:22] <Flameeyes> dos' [21:18:23] <saintdev> lol [21:18:24] <Flameeyes> whatever.. [21:18:48] * Flameeyes waits for lu_zero to hit him with a branch... [21:18:48] <wbs> I do think it's quite dead already... michael kostylev seems to be running the tests with dosemu [21:18:58] <Flameeyes> not for the pun though [21:19:06] <Flameeyes> wbs: not even qemu/freedos? [21:19:30] <wbs> but I guess it's useful for routinely testing stuff in weird header environments at least [21:20:08] <wbs> Flameeyes: no, it seems to be dosemu (which runs the code without emulation iirc), but it uses quite a few components from freedos [21:20:30] <wbs> that is, it's kinda virtualized [21:20:44] <wbs> but qemu can do that too, right? [21:21:18] <Flameeyes> dosemu last I knew wasn't really an emulator as much as an implementation of the BIOS/DOS interrupts [21:22:01] <wbs> yeah [21:22:29] <wbs> it at least probably has the lowest overhead and simplest integration for actually running all the tests, without having to do the building within that environment [21:24:17] <iive> dosemu is virtualizator. [21:30:54] <BBB> \o/ vc1 slices are mostly working [21:31:27] <JEEBsv> congrats [21:37:37] <gnafu> BBB: Who cares about VC1? Why aren't you workin on xvp8? [21:37:39] * gnafu ducks. [21:37:54] <JEEBsv> :D [21:42:27] <kurosu> are there still any new bluray being produced with vc1 encoded video ? [21:42:44] <astrange> we have to support old ones too [21:43:23] <gnafu> kurosu: For the sake of the children, I hope not. [21:45:40] <kurosu> and what about vp8 and kittens ? [21:47:14] <gnafu> kurosu: Isn't that redundant? I always thought VP8 /was/ kittens./ [21:49:41] <gnafu> "Every time you code for VC1 support, God kills a kitten." [22:38:34] <Sean_McG> that meme is so tired. [22:40:16] <mru> every time you use a meme, god kills a kitten [22:40:24] <Sean_McG> indeed [22:40:30] <Sean_McG> and hiya mru [22:49:10] <lu_zero> mru: and every time you use a god kitten kills a meme? [22:50:10] * mru does not use gods [22:52:11] <BBB> slices in b/p frames work [22:52:14] <BBB> slices in i frames break [22:52:15] <BBB> grmbl [22:52:20] * BBB summons kshishkov [22:54:00] <kurosu> yo dawg, i put more meme in your meme so that you can meme while you meme [22:54:40] <BBB> kurosu: do you know anything about vc1 slices? [23:00:30] <kurosu> BBB: no, i just now a bit about regular slices as found in other standards [23:00:40] <kurosu> *know [23:04:22] <mmu_man> eh [Announce] Now Accepting Applications for Mentoring Organizations for GSoC 2011 [23:04:51] <Kovensky> http://www.99chan.in/b/src/129876700594.jpg :awesome: [23:05:29] <BBB_> mmu_man: already done [23:06:50] <lu_zero_> uhmm

1 0