[00:09:17] <CIA-92> ffmpeg: michael * r22066 /trunk/libavcodec/h264_mvpred.h: [00:09:17] <CIA-92> ffmpeg: Simplify code in mv_pred. [00:09:17] <CIA-92> ffmpeg: Not benchmarked as this is petty much just code removial. [00:10:53] * DonDiego looks at CIA [00:11:23] <DonDiego> i'm kinda proud of trolling michael into picking up work on the h.264 decoder [00:11:25] <CIA-92> ffmpeg: michael * r22067 /trunk/libavcodec/h264.h: Remove unneeded line of code from the neighbor setting code in h264. [00:11:26] <DonDiego> :) [00:11:45] <DonDiego> there he goes again [00:12:12] <DonDiego> one of those days my trusty old K6-III shall be able to decode the cursed cathedral without framedrops [00:12:18] * DonDiego waves at michael [00:12:26] <DonDiego> hey there old bugger [00:12:26] <DonDiego> :) [00:12:48] <ohsix> did he ever say what kind of computers he had at his disposal? [00:13:18] <DonDiego> P3 500 at some point, dunno what it is now [00:13:25] <DonDiego> old notebook [00:13:34] <DonDiego> but i think he now has an amd64 machine [00:13:46] <mru> he must have something 64-bit [00:13:49] <DonDiego> btw, i called myself a troll up ther [00:13:50] <DonDiego> e [00:13:59] <DonDiego> so ohsix is free to do it as well now [00:14:01] <mru> he broke all 32-bit builds earlier [00:14:14] <mru> different kind of troll [00:14:20] <ohsix> there are kinds? [00:14:36] <ohsix> is it good or bad kinds or something else [00:14:48] <ohsix> diego kind of explained a "good kind" to some extent [00:16:53] <Kovensky> http://www.cracked.com/funny-2724-trolls/ <-- 6 types of trolls [00:44:27] <mru> "I love cruft! [00:44:30] <mru> " -- Monty [00:44:35] <mru> http://lists.xiph.org/pipermail/vorbis-dev/1999-November/008821.html [00:46:09] <peloverde> And I just thought he was becoming obstinate lately [00:48:00] <DonDiego> obstinate -- learn a new word every day.. [00:48:28] <DonDiego> i'm trying hard to find monty's famous ass hat flame.. [00:48:31] <DonDiego> hmm.. [00:49:50] <ohsix> what about brusk? [00:51:06] <mru> you mean brusque [00:51:12] <ohsix> possibly [00:51:37] <ohsix> it says its the same, hur [00:51:41] <ohsix> probably uk eng vs. us eng [00:52:16] <CIA-92> ffmpeg: michael * r22068 /trunk/libavcodec/avcodec.h: Clarify ref_index. [00:52:56] <ohsix> i still use behaviour instead of the dum way though; but not for much else [00:53:36] <mru> spelling should be consistent [00:54:04] <ohsix> i drop the u when theres other our words :< [00:54:07] <DonDiego> http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2007-November/054865.htm... [00:54:22] <DonDiego> "Fine. I give up. [00:54:22] <DonDiego> There are plenty of things about the design worth arguing about... but [00:54:22] <DonDiego> you guys are more worried about the color of the mudflaps on this [00:54:22] <DonDiego> dumptruck. You're rejecting considered decisions out of hand with [00:54:22] <DonDiego> vague, irrelevant dogma. I've seen two legitimate bugs brought up so [00:54:24] <DonDiego> far in a mountain of "WAAAH! WE DON'T LIKE YOUR INDEEEEENT." [00:54:27] <DonDiego> I have the only mplayer/mencoder on earth that can always dump WMV2 [00:54:30] <DonDiego> and WMV3 without losing sync. I just needed it for me. I thought it [00:54:32] <DonDiego> would be nice to submit it for all your users who have been asking for [00:54:34] <DonDiego> this for years. But it just ceased being worth it. [00:54:37] <DonDiego> Patch retracted. You can all go fuck yourselves. Life is too short [00:54:40] <DonDiego> for this asshattery. [00:54:42] <DonDiego> Monty [00:54:44] <DonDiego> " [00:54:47] <DonDiego> sorry [00:54:50] <DonDiego> i just had to quote it in full ;) [00:54:58] <kierank> --> #ffmpeg-trolls [00:55:01] <kierank> ;) [00:55:55] <mru> pot, kettle... [00:57:20] <mru> speaking of frame start/end: http://lists.xiph.org/pipermail/vorbis-dev/1999-November/008792.html [01:02:08] <ShadowJK> DonDiego, is this h264 spree adding up to any measurable overall gains since he started? :-) [01:02:19] <janneg> sigh, the additional 2G RAM were just good enough for 30 additional frames of scenes/01_intro/01.blend [01:02:38] <ShadowJK> It's obviously constantly getting faster and faster, curious about the "big picture" though [01:03:15] <janneg> ShadowJK: yes, it was already 15% faster in january [01:03:35] <ShadowJK> compared to when? [01:03:54] <mru> december [01:04:41] <janneg> r21156 vs r21328 [01:05:12] <janneg> r21156 was just before micheal started [01:05:18] * iive tries does new build. [01:05:48] <ShadowJK> oh wow, that's amazing [01:26:21] <DonDiego> <xiphmont_> Vorbis still stands up nicely. Theora, OTOH, is a a bit embarrassing. [01:26:25] <DonDiego> * dalias tries to be polite about theora.. [01:26:27] <DonDiego> <xiphmont_> rather, it's a bit embarrassing until you look at the code, then it's alot embarrassing. [01:26:30] <DonDiego> <xiphmont_> and that's 70% 'really fucking stupid encoder, really On2, be ashamed' and 40% 'format [01:26:33] <DonDiego> design flaws'. It's so bad it adds up to 110%. [01:26:36] <DonDiego> <xiphmont_> I plan to help Theora limp along not too embarrassingly until it can be replaced for [01:26:39] <DonDiego> real-- possibly 2-4 years. [01:26:41] <DonDiego> <xiphmont_> Theora is actually fixable tho. The amount of low-hanging fruit is staggering. [01:26:44] <DonDiego> <xiphmont_> I mean, an entropy backend that results in *more* bits being written than went in? It's [01:26:47] <DonDiego> just... wow. [01:26:50] <DonDiego> SCNR [01:26:52] <DonDiego> more monty quotes :) [01:27:21] <mru> that's a classic [01:30:57] <DonDiego> definitely [01:31:06] <iive> i'm sure you full quite them, so the search engines could index this text :) nice catch. [01:33:47] <ohsix> monty is the guy that was on the vp8 thread? [01:34:35] <astrange> they're already in multimedia wiki quotes [01:36:16] <DonDiego> i just added it [01:36:24] <DonDiego> i couldn't believe it was missing [01:36:39] <DonDiego> the ml quote i mean, not monty on irc [01:37:04] <DonDiego> ohsix: yes, monty is christopher "monty" montgomery from xiph [01:39:05] <CIA-92> ffmpeg: michael * r22069 /trunk/libavcodec/h264.h: Remove useless check of the 2 left MBs of a pair being in the same slice. [01:42:47] <mru> but hey, he has (had?) some good opinions too: http://lists.xiph.org/pipermail/vorbis-dev/2000-September/010088.html [01:45:37] <ohsix> even a busted clock is right twice a day [01:45:52] <mru> but what about a clock that runs backwards? [01:46:24] <ohsix> if its the same form factor of clock that only that aphorism works for, wether it goes backwards or forwards ... since its broke, is moot [01:48:40] <janneg> mru: depends on the speed it runs [01:48:50] <mru> -1 speed [01:49:23] <mru> and the answer is 4 [01:51:10] <ohsix> oh, if it wasn't broken, huhhuuh i get it, nice [01:54:29] <mru> "Most people would rather die than think, and most people do." -- Bertrand Russell [02:03:37] * justlooking wonders if this clock is a quarts clock, how much space does it have for time as it's relative , is it traveling at near light speed, and is it near a black hole! sleeps now. [02:07:32] <DonDiego> http://blog.gingertech.net/2010/02/20/googles-challenges-of-freeing-vp8/comm... [02:07:35] <DonDiego> SCNR ;) [02:07:52] <DonDiego> man, i have been procrastinating at work today.. [02:11:01] <peloverde> damn I hate C's constant rules [02:13:32] <peloverde> There is far to much crap that the compiler should know at compile time but isn't required to [02:13:55] <peloverde> so I have to fall back to the stupid preprocessor [02:16:27] <ohsix> what is it this time? [02:17:49] <peloverde> had a static const array and needed to size another array based on the first arrays largest (last) value [02:17:58] <ohsix> ah [02:21:25] <kierank> i wonder if it's possible to use hpet to make the timing of rtp output packets dvb compatible [02:23:02] <ohsix> what does it mean to be compatible, just higher resolution? you can get something like a 14mhz counter and programmable wakeups from most machines with hpet support [02:24:08] <kierank> someone told me there's lots of rules about how the timing between each packets [02:24:29] <kierank> packet* [02:25:10] <ohsix> as marked or in their actual delivery? it can get you more accurate timestamps but you could also just derive them as sent i think [02:25:35] <kierank> the actual rate that the program sends them out [02:25:49] <kierank> apparently a lot of programs/hardware encoders send them out in bursts [02:36:35] <DonDiego> bah [02:36:40] <DonDiego> silvia closed comments.. [02:37:19] <[1]kierank> lol [02:54:53] <CIA-92> ffmpeg: michael * r22070 /trunk/libavcodec/h264.h: [02:54:53] <CIA-92> ffmpeg: Remove 3 mv_cache zeroing instructions that zeroed the right side. [02:54:53] <CIA-92> ffmpeg: This seems unneeded as nothing seems to ever set it to non zero values. [03:28:40] <CIA-92> ffmpeg: michael * r22071 /trunk/libavcodec/ (h264.c h264.h): Move init of right side of ref_cache from fill_caches() to init_the_darn_decoder(). [03:29:04] <Dark_Shikari> LOL [03:42:24] <DonDiego> gnite [04:01:52] <MrNaz_yma> if anyone can add me to roundup i'll help with bug testing as much as i can [04:26:42] <peloverde> Are there negative repercussions to setting frame_size to zero in AVCodec init()? [04:26:59] <mru> why would you do that? [04:27:12] <mru> is the demuxer being dishonest? [04:27:16] <peloverde> yes [04:27:23] <peloverde> just like with sample_rate [04:28:41] <peloverde> It's the whole backwards compatible HE-AAC thing [04:29:21] <mru> so why zero? [04:29:30] <mru> why not the actual frame size? [04:29:39] <mru> otoh zero should be fine [04:29:47] <peloverde> because we don't know until we decode the first frame [04:29:47] <mru> what does vorbis do? [04:29:56] <mru> it has variable-size frames anyway [04:30:44] <peloverde> avccontext->frame_size = FFMIN(vc->blocksize[0], vc->blocksize[1]) >> 2; [04:30:44] <pengvado> vorbis sets frame_size to the smaller of the possible sizes [04:31:10] <peloverde> I'm trying to figure out what libfaad does but I can't seem to find any code to deal with it [04:31:11] <mru> hmm [04:31:30] <astrange> the frame_size field as defined for mov should be 0 for vorbis, i hope the muxer does that [04:31:31] <mru> imo any app should be prepared to deal with a zero [04:31:52] <mru> zero would simply mean unknown [04:32:17] <peloverde> the thing is try_decode_frame sets the frame size, but then when the codec is reopened it gets clobbered [04:32:37] <peloverde> something similar happened with sample_rate in ffplay [04:33:07] <peloverde> I'm installing libfaad to see what happens [04:33:21] <peloverde> sigh, I thought the whole point of this was not needing libfaad [04:33:24] <mru> my apps mostly ignore the avctx from lavf [04:33:35] <mru> only copy out the bare essentials into a fresh one [04:34:11] <peloverde> the problem is that ffplay hardly considers anything essential [04:34:23] <peloverde> then gets pissy when things aren't inited [04:34:43] <mru> ffplay is rubbish [04:35:09] <peloverde> yes but ffplay is our go to sample code [04:35:17] <peloverde> so people blindly copy the ffplay rubish [04:35:22] <mru> I'd never look at ffplay as a reference [04:36:14] <peloverde> we really should fix ffplay because so that people can [04:36:21] <peloverde> and by we I mean someone else :) [04:36:32] * mru ducks for cover [04:36:35] <astrange> av500's patch worked for me [04:36:52] <astrange> aurally anyway [04:37:09] <peloverde> av500's patch as useful as it is, just papers over the real issue [04:53:32] <peloverde> Does ffplay have a way to force a decoder? [05:09:05] <peloverde> dammit, I forgot that faad just assumes SBR based on LC sample rate [05:16:53] <j0sh> i have a question re: h264 [05:17:26] <j0sh> intra blocks can only be 16x16, am i correct? [05:19:32] <j0sh> if so, why is IS_INTRA also checked for 8x8 blocks in the code for direct prediction? [05:19:53] <mru> because there are 8x8 intra blocks [05:20:05] <j0sh> ok thanks [05:20:38] <j0sh> what about for 16x8 or 8x16? [06:25:40] <thresh> moroning [06:29:07] <kshishkov> here it's been idioting since yesterday [06:30:31] <thresh> since 10 years, i'd say :p [06:32:06] <kshishkov> well, at least you have nice figurehead for president [06:32:41] <thresh> :) [06:39:38] <ohsix> whats idioting? [06:40:13] <kshishkov> virtually everything, exceptions are not worth mentioning [06:42:07] <ohsix> oh, i thought you were talking about an election or something [06:43:26] <kshishkov> well, there was presidental inauguration yesterday [07:31:02] <byteme`> kshishkov: I keep thinking of an AK-47 when I read your nick [07:31:18] <kshishkov> why? [07:31:53] <byteme`> Somehow your nick is reminding me of 'Kalashnikov' [07:32:26] <kshishkov> well, if you scramble some middle letters and throw some 'a's then yes [07:32:27] <kierank> lol [07:32:32] <mru> sssshhh, it's a secret [07:33:29] <kshishkov> mru: du vet ju att jag Àlskar skovel [07:33:38] <byteme`> heh [07:34:23] <mru> ah yes, the shkovel [07:35:16] <kshishkov> not everybody got shotgun and raised floor [07:35:40] <elenril> morning [07:35:49] <kshishkov> got morgon [07:35:53] <elenril> does anybody think ffmpeg should copy metadata and chapters by default? [07:36:57] <kshishkov> byteme`: in any case, it's mostly the fact you don't know much about Russian names (which is OK outside certain parts of Asia). [07:37:11] <kshishkov> elenril: could be, yes [07:37:30] <byteme`> kshishkov: yeah I'm american... so I know next to nothing about Russian names [07:37:55] <byteme`> though, you might be impressed that I've actually been out of the US. [07:38:21] <byteme`> I've been to the UK, Australia, and the Phillipines [07:38:22] <kshishkov> Canada or Mexica? [07:38:30] <kshishkov> ah [07:38:34] <byteme`> I've been to Mexico as well [07:38:55] * mru thought he'd say texas [07:39:02] <kshishkov> and I've been only to homeland and Ukraine [07:39:03] <byteme`> lol [07:39:14] <astrange> texas is the most US part of the US [07:39:23] <astrange> elenril: yes [07:39:27] <byteme`> kshishkov: you live in Russia? [07:39:35] <kshishkov> astrange: not for the last two years [07:39:47] <kshishkov> byteme`: no, never been there either. Nor want to. [07:40:21] <byteme`> I have a friend that immigrated to the US from Georgia [07:40:33] <thresh> georgia is not exactly a country [07:41:05] <kshishkov> it's both country and state [07:41:12] <byteme`> it has it's own flag and constitution? [07:41:48] <thresh> yeah, but a tie-chewing killer instead of a president [07:42:16] <kshishkov> thresh: you listen too much to Georgian propaganda [07:44:36] <byteme`> I've wanted to go to that region but haven't had the courage to do it [07:44:59] * thresh plans to go to caucasus this summer [07:45:06] <av500> elenril: why not? [07:45:52] <kshishkov> byteme`: I'd advise against it. [07:46:07] <thresh> for an american it would be nice in Georgia [07:46:49] <byteme`> I'm not sure how Americans are viewed in that region... probably not very good [07:46:57] <kshishkov> thresh: yes, how many people know English there? [07:47:22] <mru> in america? not many... [07:47:32] <kshishkov> byteme`: it's feud there, so neither Russians nor even local people are liked there very much [07:47:54] <byteme`> yeah Russian invasion? [07:48:01] <thresh> haha "invasion" [07:49:15] <elenril> av500: because it only really works with one infile and one outfile [07:49:28] <byteme`> I acutally don't know much about the conflict. American media doesn't report the conflict very often. I have to actually watch news from Europe or the Middle East to get current events ( or read internet news ) [07:49:46] <av500> elenril: sounds to me like the 95% use case [07:49:51] <byteme`> anyway, sorry for being offtopic [07:49:53] <byteme`> :) [07:50:08] <kshishkov> byteme`: I'd say it was a clash of imperial ambitions from the both sides, so don't mind it [07:51:00] <kierank> europe's got bigger problems anyway [07:52:07] <byteme`> kshishkov: The conflict is unfortunate :( [07:52:21] <av500> elenril: doing 1:N copy to me makes sense to preserve as much meta info as was present in the source file [07:52:33] <av500> doing M:N I'd say peopl know what they are doing... [07:53:05] <av500> (err, M:N, no pun intended....) [07:55:11] <kshishkov> av500: well, shortening "Big Buck Bunny" with Ronald around is much more hilarious [07:55:53] <av500> kshishkov: agree, I hate it when I can't tab complete that long abbreviation... [08:56:43] <CIA-92> ffmpeg: benoit * r22072 /trunk/libavcodec/avcodec.h: Fix typos in ref_index documentation. [09:14:30] <CIA-92> ffmpeg: michael * r22073 /trunk/libavcodec/h264.h: [09:14:30] <CIA-92> ffmpeg: Simplify code to set cbp_* [09:14:30] <CIA-92> ffmpeg: this seems 1 cpu cycle slower even though we practically just remove code. [09:14:30] <CIA-92> ffmpeg: Speed loss seems caused by the merge of if(left_type), iam commiting this [09:14:30] <CIA-92> ffmpeg: anyway as i cant imagine this to be anything but compiler messup. [09:40:07] * av500 does not like how tightly lavf and lavc are tied together [09:41:27] <kshishkov> no, it's lavf tied to lavc, lavc is rather free [09:41:38] <av500> right [09:43:13] <kshishkov> what can you suggest then? [09:45:01] <av500> demuxer: demuxes [09:47:23] <kshishkov> yes, and muxer: dances [09:49:43] <merbzt> can I generate a vararg call in C [09:49:50] <phaidros> guys I am still struggling with ffmpeg and capturing from alsa, docs seems quite outdated in that part, examples over the internet are not working, one little example: [09:49:55] <lu_zero> merbzt: like? [09:50:18] <kshishkov> merbzt: look at av_log definition [09:50:41] <phaidros> using: "arecord -Dplughw:1,0 -c 2 -r 44100 -f CD | aplay" for capturing and playing is ok, putting ffmpeg in between like this: [09:50:51] <phaidros> arecord -Dplughw:1,0 -c 2 -r 44100 -f CD | ffmpeg -ab 256000 -ac 2 -i - -acodec adpcm_ima_wav - | aplay [09:50:57] <phaidros> doesnt work. [09:51:00] <av500> merbzt: iirc there was some implementation specific bit around how varargs are actually implemented, so it might not be protable [09:51:14] <av500> phaidros: #ffmpeg? [09:51:40] <phaidros> av500: yeah, I am always getting pointed to the docs, which are not talking bout that part. [09:51:44] <kshishkov> av500: (s)printf call in libc [09:52:13] <merbzt> lu_zero: if a struct has an int array and with n values, I want to send all the args to another vararg function [09:52:22] <phaidros> av500: thanx, so I ll give up on ffmpeg for now as streaming solution. anyways, thanks for suggesting codecs yesterday. [09:52:23] <kshishkov> phaidros: you forgot to specify input and output type (format and codec) [09:52:34] <phaidros> rly? hmm [09:52:42] <av500> phaidros: sure give up [09:53:12] <kshishkov> merbzt: maybe you'll need to create va_list [09:53:45] <phaidros> kshishkov: input type for pipe? output type for pipe? [09:54:07] * KotH thinks that phaidros should go to #ffmpeg as suggested [09:54:10] <lu_zero> the function to pass out the stuff would have a ... argument [09:54:21] <lu_zero> and then you'll use a va_list to feed it [09:54:30] <av500> merbzt: http://bytes.com/topic/c/answers/218657-creating-va_list [09:54:38] <phaidros> KotH: thx [09:55:09] <av500> kshishkov: thats where the non-portable kicksin iirc [09:55:34] <av500> KotH: why did you not just let him give up? [09:57:02] <kshishkov> av500: see "rickrolling" [09:57:50] <KotH> av500: i believe in the good and just in people [09:58:29] <kshishkov> KotH: but you don't look an idiot. So I gather you're lying! [09:58:43] <KotH> lol [09:58:50] <KotH> kshishkov: dont judge people by their looks ;) [09:59:20] <kshishkov> KotH: I don't judge them at all until they've acted a bit [10:00:56] * KotH does not act, he just types [10:01:15] <kshishkov> typing is an action as well [10:03:25] <KotH> asädlfjaü0fjadfansdfüoaishdfaüsdfnhasdlfkna [10:03:34] * KotH just acted in an irrational way [10:04:15] <kshishkov> KotH just donated some umlauts to this IRC channel [10:04:57] * elenril thinks BofH should start using UTF-8 [10:06:03] <kshishkov> elenril: doesn't he? [10:06:44] * elenril doesn't think so [10:07:22] <kshishkov> なぜ [10:07:52] <kshishkov> jag ser tyska bokstav, det mÃ¥ste bli UTF-8 [10:11:21] * KotH is characterset challenged [10:13:21] <elenril> KotH: /set recode_out_default_charset utf-8 =p [10:20:07] <KotH> elenril: this replaces all non-iso8859-1 characters with ?, which is not as i'd like it [10:20:28] <elenril> /set term_charset utf-8? [10:20:37] <elenril> +get a sane terminal [10:21:23] <KotH> that' needs more work than you'd think [10:21:45] <KotH> it's easier for me to let you cope with my latin1 [10:21:47] <KotH> ;) [10:22:20] <elenril> orly [10:22:27] <twnqx> 'morning [10:22:51] * Kovensky has a script that kicks anyone that outputs non-UTF-8 on channels he has +o [10:23:09] <twnqx> evil kov! [10:23:11] <Kovensky> inb4 "that's UTF8ism!" [10:23:16] <Kovensky> hi twnqx [10:23:51] <KotH> that's rassism! [10:24:38] <Kovensky> =p [10:24:50] <Kovensky> and hurf @ vmwares (lack of) ability to keep track of time [10:25:00] <elenril> why vmware [10:25:02] <Kovensky> my VM's clock has skewed 12h behind the computer clock [10:25:05] <twnqx> normal [10:25:16] * elenril reinstalling windoze in his virtualbox atm [10:25:29] <Kovensky> elenril: because I don't need any GUI (or CLI) with vmserver; I can just set it up to automatically start up the VM [10:25:43] <Kovensky> and then I just ssh to it when it finishes booting ._. [10:26:05] <elenril> isn't vmware evil proprietary software? [10:27:57] * byteme` likes kvm [10:30:27] <twnqx> errr what [10:31:14] <KotH> someone, most likely elenril, stole all your pings [10:31:28] <twnqx> no i mean... [10:31:38] <twnqx> <-- twnqx has quit (Ping timeout: 240 seconds) i saw my own ping timeout? [10:32:10] <av500> near death experience [10:32:18] <twnqx> heh [10:32:31] <twnqx> and i hate sitting in airports with the plane being late >_> [10:33:25] <twnqx> Kovensky, did you answer my last question? :X [10:35:24] <av500> twnqx: if the plane was early, there would be no point sitting at all, no? [10:35:57] <byteme`> sitting on the plane is the hard part imo [10:36:25] <pross-au> twnqx: depends if there is free alcohol [10:36:44] <pross-au> (and not having to drive at your destination) [10:37:01] <av500> pross-au: bring an eski... [10:37:17] <twnqx> i'll have to drive [10:37:19] <twnqx> but... well. [10:37:27] <twnqx> first i'll have to catch my connecting flight... [10:37:39] <twnqx> plane change margin went from 1:10 to 0:40 already :S [10:40:29] <byteme`> delta has free alcohol on all international flights. :) [10:40:52] <twnqx> lufthansa too [10:41:01] <twnqx> but it's the national leg that's late [10:42:01] <pross-au> urgh delta sounds american [10:43:16] <bilboed-tp> byteme`, errrr... no it doesn't [10:43:43] <bilboed-tp> except for the *one* you get with your meal [10:43:57] <byteme`> I could be thinking of united airlines [10:44:03] <bilboed-tp> same [10:44:16] <byteme`> I went to australia last year and drank free [10:44:23] <bilboed-tp> Qantas ? :) [10:44:29] <byteme`> united or delta [10:44:32] <byteme`> forget which one [10:44:43] <bilboed-tp> sure, maybe on the 16 hour flights they make an exception :) [10:44:49] <KotH> air lines went down the drean after the us attacked iraq [10:45:03] <KotH> food sucks, drinks suck, service sucks [10:45:03] <twnqx> nah [10:45:07] * KotH blames the US [10:45:26] <kshishkov> KotH: ever tried Ukrainian airlines? [10:45:29] <bilboed-tp> the US carriers were already crap before that :) [10:45:35] <twnqx> well ok, with a high frequent traveler status and european/arabien airlines milage may vary :P [10:45:42] <twnqx> arabian* [10:45:43] <pross-au> i remember delta having good sized economy seating [10:46:27] <kshishkov> there are only two good places [10:46:37] <byteme`> bilboed-tp: I just checked the website, united offers free drinks when traveling to australia or europe [10:46:57] <av500> 1) offer free drinks [10:47:03] <av500> 2) charge for toilets [10:47:06] <av500> 3) ... [10:47:20] <kshishkov> byteme`: so they are suggesting you have to be drunk to fly there? [10:47:25] <byteme`> heh [10:47:50] <byteme`> kshishkov: I think they'd like people to be a bit medicated for a 17 hour flight [10:48:13] <pross-au> free drinks on trips to australia are completely understandable. [10:48:37] <pross-au> just preparing you for the local conditions [10:48:41] <twnqx> lufthansa offers beer on national flights :S [10:48:54] <kshishkov> French airlines should offer wine then [10:48:58] <av500> but not Hefeweizen :( [10:49:17] <twnqx> dunno, refuse to fly with klm/air france again [10:49:19] <pross-au> twnqx: same here on Qantas Domestic after 3~4 pm free grog [10:52:32] <twnqx> yey boarding [10:57:38] <CIA-92> ffmpeg: siretart * r22074 /branches/ (0.5 0.5/libavcodec/huffyuv.c): [10:57:38] <CIA-92> ffmpeg: Make sure we dont read over the end. [10:57:38] <CIA-92> ffmpeg: Fixes issue1237. [10:57:38] <CIA-92> ffmpeg: backport r19322 by michael [11:52:09] <CIA-92> ffmpeg: pross * r22075 /trunk/MAINTAINERS: Add myself as maintainer of the bink demuxer and bink audio decoder [13:16:48] <MrNaz_out> how do i get a login name for roundup? i can help with ffserver [13:16:58] <kshishkov> register [13:17:13] <MrNaz_out> i get the error "you do not have permission to register the user class" [13:17:25] <MrNaz_out> and no, i'm not registering with the username as "class" :P [13:18:06] <KotH> are you using "user"? [13:18:07] <kshishkov> find lu_zero here and complain to him [13:18:10] <KotH> SCNR ;) [13:18:29] <MrNaz_out> heh no i'm trying to register with my nick [13:18:55] <lu_zero> uh? [13:19:09] <MrNaz_out> "mrnaz' [13:19:21] <MrNaz_out> uh? [13:19:23] <MrNaz_out> ? [13:20:15] <lu_zero> MrNaz_out: I just joined [13:20:20] <lu_zero> tell me everything ^^' [13:21:34] <MrNaz_out> i click register, i enter "mrnaz" as the username, enter my password twice and my email address... when i click Register, I get the message: "You do not have permission to register the user class. [13:21:35] <MrNaz_out> " [13:21:41] <MrNaz_out> unless i'm already registered or something... [13:22:28] <MrNaz_out> i tried password reset, but both my username and email address are unknown [13:22:41] <lu_zero> O_O [13:22:44] <lu_zero> let me see [13:22:51] * KotH guesses bad karma [13:23:11] <MrNaz_out> KotH but i always get modded up on slashdot [13:23:27] <KotH> MrNaz_out: that's where you accumulate your bad karma! :) [13:23:38] <MrNaz_out> http://slashdot.org/~MrNaz/comments see? :P [13:24:02] <kshishkov> we seem not to care about /. much [13:24:08] <lu_zero> damn! [13:24:16] <kshishkov> (only as a source of cheap laughs) [13:26:03] <lu_zero> sigh [13:27:04] * kshishkov smells some roundup issue [13:27:07] <av500> lu_zero: hack or hang? [13:28:09] * Kovensky suggests trac and runs away [13:28:32] * av500 trac's Kovensky [13:29:32] <MrNaz_out> lu_zero you want to register for me? maybe my IP or subnet is banned for spamming or something [13:40:11] <lu_zero> MrNaz_out: I'm trying to figure out what's wrong [13:40:22] <lu_zero> meanwhile [13:40:29] <lu_zero> mrnaz is the username you want? [13:40:44] <lu_zero> which is the email you'd like to have? [13:40:57] <av500> spam! [13:44:26] <lu_zero> _maybe_ I fixed it [13:44:50] <lu_zero> they changed the permission needed to register from create user to register user [13:45:46] <kshishkov> renamed or added? it can be fun doing registation without creating actual user [13:46:25] <lu_zero> sigh [13:46:31] <lu_zero> let me see... [13:46:42] <lu_zero> just changing it breaks [13:49:53] <lu_zero> MrNaz: try again [13:50:55] <lu_zero> it works now [13:52:42] <MrNaz_out> worked... thanks [13:52:44] <MrNaz_out> what was wrong ? [13:53:24] <kshishkov> new permission name and old DB obviously [13:55:14] <lu_zero> new api and older schema... [14:19:09] <kshishkov> heh, Michael admits that H.264 is now quantum scale where it's impossible to benchmark separate part without seriously affecting its speed and produced code [14:33:16] <CIA-92> ffmpeg: siretart * r22076 /branches/ (0.5 0.5/libavcodec/vorbis.c 0.5/libavcodec/vp3.c): (log message trimmed) [14:33:16] <CIA-92> ffmpeg: fix the remaining ogv segfaults from issue 1240. [14:33:16] <CIA-92> ffmpeg: First commit: [14:33:16] <CIA-92> ffmpeg: Make decode_init fail if the huffman tables are invalid and thus init_vlc fails. [14:33:16] <CIA-92> ffmpeg: Otherwise this will crash during decoding because the vlc tables are NULL. [14:33:17] <CIA-92> ffmpeg: Partially fixes ogv/smclock.ogv.1.101.ogv from issue 1240. [14:33:18] <CIA-92> ffmpeg: backport r19355 by reimar [14:47:12] <CIA-92> ffmpeg: benoit * r22077 /trunk/ffmpeg.c: [14:47:12] <CIA-92> ffmpeg: Prevent overflow of start_time + recording_time. [14:47:12] <CIA-92> ffmpeg: Patch by Francesco Cosoleto gmail($name) [15:03:48] <CIA-92> ffmpeg: michael * r22078 /trunk/libavcodec/h264.h: [15:03:48] <CIA-92> ffmpeg: Remove some useless operations from the code setting left_cbp. [15:03:48] <CIA-92> ffmpeg: maybe 0.5 cpu cycles faster [15:06:01] <janneg> kshishkov: ^^^ [15:08:45] <janneg> it's already over 20% faster compared to r21156 [15:08:57] <mru> :-) [15:09:09] <Dark_Shikari> is there a way to find out at what file offset a difference between two files occurs? [15:09:18] <mru> cmp [15:09:45] <Dark_Shikari> it prints chars/lines, not bytes [15:10:11] <mru> LC_ALL=C cmp [15:10:27] <Dark_Shikari> no effect [15:10:39] <mru> and chars != bytes? [15:10:41] <Dark_Shikari> I guess I can just ignore lines [15:10:49] <Dark_Shikari> next: to find at what frame in the file this is :/ [15:11:00] <mru> heh [15:11:23] <mru> you need to write a parser that dumps out the syntax elements in text form [15:11:28] <Dark_Shikari> we already have that [15:11:30] <Dark_Shikari> JM tracedec [15:11:52] <mru> well, use it [15:12:04] <Dark_Shikari> well, for 352x288, it occurs on byte 16822384 of raw yuv [15:12:22] <mru> division... [15:12:26] <Dark_Shikari> frame 110 or 111 or so [15:12:43] <Dark_Shikari> yup, frame 110. [15:18:39] <andoma> Dark_Shikari: i made some app a while ago that compare raw yuv frames and printed which macroblock the error occured in [15:18:43] <andoma> and deltas, etc [15:18:48] <Dark_Shikari> Oh, nice [15:19:00] <andoma> but i've no idea where it is :) [15:19:02] <Dark_Shikari> lol [15:19:09] <andoma> it floated on tha ffmpeg-dev mailing list for a while [15:19:17] <andoma> i'll make a quick check [15:19:23] <Dark_Shikari> well elecard's yuv tool can sorta do that [15:19:26] <Dark_Shikari> it's not automated enough though [15:19:28] <mru> andoma: does it also print which C function the error is in? [15:19:34] <Dark_Shikari> lol [15:19:37] <andoma> mru: yes if you pass -v [15:19:50] <av500> mru: it does not propose NEON replacement, code? bah [15:21:39] <andoma> Dark_Shikari: http://www.olebyn.nu/~andoma/yuvcmp.c [15:21:55] * BBB holy shits [15:22:20] <Dark_Shikari> nice, thx [15:22:28] <BBB> I was in a taxi last night in the midst of a snow blizzard, that's pretty darn scary [15:22:55] <andoma> totally undocumented, but i'll guess you figure it out, it's like ./a.out a.raw b.raw 1920 1080 [15:23:32] <andoma> and 'pixelcmp' or 'blockdump' as extra option, i've no idea what they do anymore though :) [15:25:59] <kshishkov> BBB: here it may be pretty scary to take a taxi [15:26:17] <mru> in paris it's impossible to take a taxi [15:26:25] <av500> mru: you have to know how :) [15:26:40] <mru> be a cab driver? [15:27:00] <CIA-92> ffmpeg: michael * r22079 /trunk/libavcodec/h264.h: [15:27:00] <CIA-92> ffmpeg: Only load the topleft mv/ref when the topright is unavailable. [15:27:00] <CIA-92> ffmpeg: 8 cpu cycles faster. [15:27:06] <av500> mru: last cab driver managed to hit another cab... [15:27:15] <av500> slowly enough luckily [15:27:16] <kshishkov> I've heard that shouting at French in Russian helps with anything [15:29:06] <kshishkov> guess where the word "bistro" come from? [15:29:56] <mru> hmm, bistro wars? [15:30:18] <kshishkov> no, from Russian word for "quickly [do it]" [15:30:36] <kshishkov> learnt by French in the beginning of XIX century [15:31:17] <av500> "...However, this etymology is not accepted by several French linguists as there is, surprisingly, no occurrence of this word until the end of the 19th century.[1][2][3]" [15:31:49] <kshishkov> any reason to believe them? [15:32:15] <mru> english got it from french in early 20th century apparently [15:32:16] * av500 only believes fflinguists [15:32:29] <kshishkov> mru: Swedish too [15:33:09] <av500> if the russians got it from the swedish, it will create an endless loop [15:33:21] <kshishkov> no, it's of Slavic origin [15:33:56] <kshishkov> but it may be a bit puzzling why certain West Ukrainian short sausage is called "gurka" [15:34:13] <mru> from swedish of course [15:34:21] <kshishkov> javisst! [15:34:29] <mru> hardly anything to do with the gherkas [15:34:58] <mru> or gurkha, as some would spell it [15:35:00] <mru> or ghurka [15:35:05] <mru> they can't make up their minds [15:35:16] <kshishkov> no, they simply can't pronounce it [15:35:50] <merbzt> Chinese patches [15:36:13] <merbzt> and a potentially good one also [15:36:50] <kshishkov> better fix gcc though [15:37:13] <mru> yes [15:37:22] <mru> that's likely to give worse code on other machines [15:38:15] <merbzt> unpossible [15:39:05] <kshishkov> mru: go to farm and test ;) [15:42:18] <mru> one insn worse on alpha [15:43:32] <Dark_Shikari> nobody cares about alpha [15:43:37] <Dark_Shikari> ARM matters, x86 matters [15:43:40] <Dark_Shikari> PPC _maybe_ matters [15:43:40] <MrNaz_out> Dark_Shikari i have questiosn for you@ [15:43:41] <Dark_Shikari> alpha? lol [15:43:42] <MrNaz_out> ! [15:43:44] <Dark_Shikari> ask then [15:43:45] <mru> alpha is first in alphabetical order [15:43:50] <Dark_Shikari> lol [15:44:07] <mru> I have a script that compiles bits of code with a dozen compilers [15:45:59] <mru> one insn less on arm due to gcc nonsense [15:46:10] <mru> probably same execution time on modern cpus though [15:46:15] <mru> due to dual-issue [15:46:21] <Dark_Shikari> if all else is the same, faster on x86 is better [15:47:06] <MrNaz_out> video archiving... i'm outputting from premiere, into uncompressed avi and i'm trying to find a solution for archiving... i've investigated h.264 lossless and got 35mbits, which is acceptible... however that's 720x576... when i switch to using HD the bitrate will be unacceptibly high... do you ahve any suggestions? [15:47:13] <mru> one worse on avr32 [15:47:19] <Dark_Shikari> MrNaz_out: don't use lossless then [15:47:25] <lu_zero> mru: what are you doing? [15:47:25] <mru> looks better on bfin [15:47:53] <mru> ia64 looks horrible both ways [15:47:58] <mru> I can't make heads or tails of ia64 asm [15:48:06] <MrNaz_out> Dark_Shikari the video is interlaced... is there a good way to archive interlaced footage using lossy compression ? [15:48:14] <kshishkov> mru: neither can Intel [15:48:18] <Dark_Shikari> MrNaz_out: x264, crf 10? [15:48:46] <Dark_Shikari> qpmin 0 [15:49:37] <lu_zero> .... [15:49:39] <MrNaz_out> will that be safe for interlaced content? and whats the story with -ilme ? [15:49:41] <mru> one insn worse on mips [15:50:17] <kshishkov> lu_zero: he's testing small H.264 optimization proposed on ML [15:50:19] <mru> guess we don't care too much about cpus with expensive shifts [15:50:40] <CIA-92> ffmpeg: siretart * r22080 /branches/ (0.5/libavformat/asfdec.c 0.5): [15:50:41] <CIA-92> ffmpeg: Avoid divisions by 0 in the ASF demuxer if packet_size is not valid. [15:50:41] <CIA-92> ffmpeg: r19330 by reimar [15:50:42] <lu_zero> let me dig the ml [15:50:44] <Dark_Shikari> MrNaz_out: --interlaced [15:50:57] <MrNaz_out> aah [15:51:15] <MrNaz_out> will --interlaced help when using h.264 lossless? [15:51:34] <MrNaz_out> (oh i just realized that i'm asking all this in the wrong channel... switching) [15:51:42] <Dark_Shikari> MrNaz_out: yes [15:52:12] <mru> 4 insns worse on sh4 [15:52:18] <av500> sh4 is dead [15:52:33] <kshishkov> and we don't care about it which is more important [15:52:35] <mru> yes, but apparenly I have a compiler... [15:52:44] <mru> x86 looks better for sure [15:53:01] <mru> we could add a special case to gcc for this :-) [15:53:04] <mru> not very hard [15:53:05] <Dark_Shikari> lol [15:53:14] <Dark_Shikari> like that #ifdef ARM stuff in coreavc [15:53:26] <mru> coreavc has too much ifdef [15:53:30] <mru> most of them dead too [15:53:45] <Dark_Shikari> :/ yeah [16:07:52] <MrNaz_out> who is rbultje [16:08:11] <kshishkov> Ronald Bultje, should be obvious [16:08:26] <MrNaz_out> as in.. what's is irc nick [16:08:30] <kshishkov> BBB [16:08:36] <MrNaz_out> ta [16:09:54] <av500> janneg: any more luck with BBB ? [16:11:42] <janneg> av500: I can now render frames I couldn't before but slowly. currently 50 minutes per frame [16:11:57] <av500> wow [16:12:35] <av500> we might start saving to get the real BBB over here from NY... [16:12:59] <janneg> and there are still frames which gets OOM-killed with 6G [16:13:14] <BBB> av500, huh? [16:13:33] <av500> janneg: leave those to mru [16:16:22] <kshishkov> BBB: you should've chosen nick which is not an abbreviation of some movie av500 and janneg talk about [16:23:03] <CIA-92> ffmpeg: mstorsjo * r22081 /trunk/libavformat/rtspenc.c: [16:23:03] <CIA-92> ffmpeg: RTSP muxer: Use a local copy of the AVPacket for sending to the chained muxer [16:23:03] <CIA-92> ffmpeg: This way, we avoid overwriting stream_index in the user's AVPacket [16:23:03] <CIA-92> ffmpeg: with a nonsense value. [16:25:02] <janneg> av500: sure but if want it finished before linuxtag we'll need at least another quadcore. ETA at my current average speed 28 weeks but only 14 weeks left [16:26:10] <av500> janneg: I am full afk next week, but once back I can look into setting that QC up [16:26:17] <av500> and render some stuff on the I7 [16:26:41] <merbzt> av500: what are you rendering ? [16:26:44] <merbzt> BBB ? [16:26:56] <janneg> and 70 weeks with 50 minutes per frame [16:27:17] <janneg> merbzt: yes, BBB at 2700x1440 for the videowall [16:27:37] <Dark_Shikari> lol [16:27:39] <janneg> lol [16:28:20] <av500> you mean video_BBB_2700_1440.mkv? [16:28:35] <_BBB_> that doesn't work :) [16:28:41] <av500> dman [16:28:54] <kshishkov> merbzt: sounds reasonable, rendering me may not fit into that resolution [16:29:04] <lu_zero> _BBB_: ping [16:29:35] <KotH> janneg: if you need a machine for distributed rendering, let me know [16:29:55] <_BBB_> lu_zero, yes [16:31:38] <av500> KotH: yes [16:31:57] <_BBB_> lu_zero, hm, you mean pause before teardown is "normal"? [16:32:01] <_BBB_> I thought it was kind of weird [16:32:32] <KotH> av500: ? [16:33:08] <KotH> av500: ah.. [16:33:17] <KotH> av500, janneg: how much computing power do you need? [16:33:49] <janneg> KotH: we need every machine with more than 4G we can get [16:33:55] <KotH> hmm.. [16:34:06] * KotH has a dual core xeon hat home.. dunno how fast it is [16:34:15] <av500> KotH: mem is the issue [16:34:16] <KotH> havent even unpackaged it, because i had no use [16:34:20] <KotH> 4G [16:34:25] <av500> not enuf :( [16:34:31] <KotH> how much does it need? [16:34:47] <av500> [17:12] <janneg> and there are still frames which gets OOM-killed with 6G [16:35:26] <lu_zero> _BBB_: teardown should just invalidate the rtsp session and reset the rtsp state machine [16:35:42] <janneg> 6G seems to to be mostly fine, I doubt we need more than 12G [16:35:43] <lu_zero> usually a teardown follow a disconnect from the transport layer [16:36:14] <lu_zero> so most of the time on teardown the server will just stop rtp streams and such [16:36:18] <lu_zero> but [16:36:56] <lu_zero> you might have some implementation behave differently and still being on spec [16:37:01] <KotH> janneg, av500: hmpf.. i would need to buy new 2G dimms [16:37:19] <KotH> the machine is fully equiped with 4*1G [16:38:13] <av500> KotH: :( [16:38:23] <KotH> janneg, av500: do we have a sponsor? :) [16:38:24] <av500> my QC has 2x2, I'd buy 2x2 more for it [16:39:13] <_BBB_> lu_zero, hm... ok, I didn't expect that, I thought teardown was just the end-of-it-all [16:39:22] <lu_zero> you might have [16:40:01] <av500> KotH: the QC here has not enuf ram anyway, I guess corp will pay for more [16:40:17] <lu_zero> usually you do not [16:41:22] <lu_zero> it's just to be safe [16:41:41] <lu_zero> TEARDOWN is supposed to free all the resources [16:41:49] <lu_zero> so it _should_ be the end of everything [16:42:21] <lu_zero> but it's nicer to issue a pause (stop) before [16:42:38] <KotH> av500: can you can manage to get 160EUR from somewhere, i'd buy the ram and put the machine online :) [16:42:40] <_BBB_> ok, I see [16:42:51] * lu_zero is re-checking [16:43:37] <av500> KotH: I can try to win a local snowboard race next week... [16:44:42] <lu_zero> http://pastie.org/844372 [16:45:39] <lu_zero> the section seem to make the current code fine as well [16:45:52] <KotH> hmm... dont we have some money in ffmtech already? [16:46:16] <kshishkov> maybe not yet [16:48:23] * elenril pokes Honoome_ [16:49:45] <KotH> av500, janneg: anyways. if you want a machine with xeon 3065 x2.3 and 4G ram, let me know [16:49:58] <KotH> av500, janneg: if you find 160EUR for the ram, then too ;) [16:50:32] <Dark_Shikari> this is amazing [16:50:33] <Dark_Shikari> http://www.youtube.com/watch?v=sRYPEBEGIcY [16:50:37] <Dark_Shikari> intel ad for the core i7 in japan [16:50:38] <Dark_Shikari> "8 threads" [16:50:42] <mru> janneg: would another c2q 4G help at all? [16:51:13] <kshishkov> Dark_Shikari: their ad "your office - your plantation" was better [16:52:11] <janneg> I'm currently looking if there's a easy and fast way to estimate how much RAM a frame needs [16:52:37] <kshishkov> +infinity? [16:53:22] <kshishkov> or maybe f(size) = size*N + M [16:53:57] <kshishkov> or num_of_polygons*N + M + size*N [16:54:20] <av500> (..)^random_large_number [17:03:38] <KotH> strange... my server at hetzner has amd 64 X2 Dual Core Processor 5600+, but reports 1GHz [17:03:51] * KotH thinks there is something fishy going on at hetzner [17:04:09] <kshishkov> frequency control in action? [17:04:11] <janneg> KotH: cpufreq? [17:04:17] <kshishkov> or simply VM? [17:04:18] <KotH> none installed [17:04:21] <KotH> root server [17:04:29] <KotH> so, "my" machine [17:04:47] <KotH> could be that they underclock the cpu to save power [17:05:54] <janneg> KotH: in /proc/cpuinfo? run cpuburn for each core and look again [17:11:38] <mru> janneg: I can put a c2q/4G online if it'll help [17:11:58] <av500> put more ram online too [17:12:10] <mru> don't have more [17:12:22] <mru> and I don't want to bog down the i7 with rendering [17:12:23] <av500> beg, steal, borrow [17:12:27] * DonDiego wants a pony [17:12:37] * av500 wants a steak sandwich [17:12:48] <mru> DonDiego: gimme that ram and I'll render you one [17:12:58] <kshishkov> av500: ask DonDiego when he gets a pony [17:13:03] * KotH notes, cpuinfo is not static [17:13:11] <wbs> lu_zero: (martin here, hi) - regarding pause/teardown in rtsp, should I wait for the reply to pause before proceeding with teardown (using ff_rtsp_send_cmd), or just fire away pause, teardown (using ff_rtsp_send_cmd_async as I do now), then close the connection? [17:13:12] <av500> kshishkov: my daughter will cry [17:13:13] <mru> DonDiego: not "render you a pony" as a wizard might of course [17:13:15] * KotH notes further, that he has cpufreq active but didnt know it [17:14:03] <kshishkov> av500: don't slaughter her pony then [17:15:03] <KotH> janneg: another 2.8GHz amd 64 dual core with 4G ram, if you can use that [17:15:19] <mru> av500: fork it first, then she can keep it _and_ you get your sandwich [17:16:49] <KotH> janneg: and that one with a 100Mbps network connection, so you could transfere the data fast too :) [17:17:20] <av500> we still have a light ram issue [17:19:25] <KotH> yeah.. [17:19:45] <KotH> as i said, find a sponsor, i get the ram and you'll get a machine just for yourself [17:23:34] <KotH> av500, janneg: i can borrow 8G from a friend [17:23:46] <KotH> av500, janneg: so you can get a machine if you want [17:24:01] <av500> KotH: \\\ooo//// [17:24:28] * kshishkov records that sign as "The Great Cthulhu is awakened" [17:24:59] <elenril> fhtagn! [17:38:31] <KotH> av500, janneg: i get the ram tomorrow, maybe i'll have the time to set up the machine on sunday, maybe not [17:38:53] <av500> ok, as said, I am awol for 1w [17:39:11] <av500> then I will try to get more mem here and setup a login [17:45:32] <janneg> KotH: great. ping me if you're ready. thanks [18:00:34] <mru> I'm bringing my machine up just in case [18:08:41] * KotH wonders where he put that machine anyways [18:08:58] <KotH> and what name shall i give it? [18:12:28] <kshishkov> bbbch obviously [18:13:22] <CIA-92> ffmpeg: vitor * r22082 /trunk/libavcodec/eatgv.c: [18:13:23] <CIA-92> ffmpeg: Do not read beyond end of input in EA-TGV. This should avoid FATE test #362 [18:13:23] <CIA-92> ffmpeg: result depending on uninitialized data. [18:13:23] <CIA-92> ffmpeg: FATE result may change for this test. [18:13:44] <KotH> hmm... stupid question: i have to perform a%b, b is a power of 2, but can be anything between 8 and 512, is there anyway that i can tell gcc to not do a modulo operation, but optimize it? [18:14:12] <KotH> short of coding this by hand [18:14:18] <KotH> (which would probably slower) [18:14:27] <mru> b==1<<x, x==3..9? [18:14:38] <KotH> yes [18:14:53] <mru> a & ((1<<b)-1) [18:14:55] <kshishkov> gcc can't take hints anyway [18:15:07] <KotH> mru: thanks! [18:15:22] <mru> know your power of 2 maths [18:15:49] <KotH> mru: uhmm... shouldnt that be b<<1 ? [18:15:59] <mru> no [18:16:07] <mru> 1<<b == pow(2, b) [18:16:22] <mru> b<<1 == b*2 [18:17:17] <KotH> and why do i need 2^b ? :) [18:17:44] <mru> I'm stupid [18:17:47] <mru> a & (b-1) [18:50:56] <CIA-92> ffmpeg: fenrir * r22083 /trunk/libavcodec/dca.c: [18:50:56] <CIA-92> ffmpeg: Fixed a segfault in the DCA decoder with corrupted streams. [18:50:56] <CIA-92> ffmpeg: It happens when the number of channels defined by DCAContext:acmod is lower [18:50:56] <CIA-92> ffmpeg: than DCAContext:prim_channels. In this case, dca_subsubframe() will call [18:50:56] <CIA-92> ffmpeg: qmf_32_subbands() using s->channel_order_tab[] entries equal to -1. [19:21:53] <j-b> Anyone with a 6.1 vorbis file? [19:24:39] <peloverde> j-b, rob added support for the new vorbis surround stuff so my guess is he might [19:25:16] <j-b> peloverde: his mail speak about 7.1 one, not about 6.1 one [19:25:42] <peloverde> "New channel layouts have been added to the Vorbis spec [1] for 6.1 and 7.1 channels. Attached is a patch for adding such support to the FFmpeg decoder." [19:26:12] * Kovensky wonders how many compliant 5.1 files are around [19:26:13] <j-b> yes, and then speaks about the 8.ogg from monty [19:26:27] <Kovensky> I remember downloading a fansub that used 5.1 vorbis but had the channel layout completely wrong in ffmpeg [19:26:33] <Kovensky> but it was right in corevorbis [19:26:40] <peloverde> why do none of the caf samples have codec names attached [19:26:44] <Kovensky> guess which decoder the encoder insisted in using [19:33:05] <peloverde> Can we run ffprobe over the samples archive and dump that to some sort of database to try to catalog it better? [19:34:17] <mru> feel free [19:35:14] <_av500_> peloverde: so the simple solution finds no love? (wrt heaac) [19:35:26] <peloverde> I understand why the old samples are a mess but I don't understand why the new ones are equally worthless [19:35:34] <mru> _av500_: love don't come easy... [19:35:46] <_av500_> mru: I know [19:36:20] <peloverde> _av500_, your update patch probably makes the most sense [19:36:49] <peloverde> having to check each demuxer manually (which is what I'm doing now) is a huge pain in the ass [19:36:56] <_av500_> as we open the codec twice already, no use to throw the data away [19:37:24] <mru> codec-specific hacks in every demuxer is silly idea [19:37:36] <_av500_> ack [19:37:48] <_av500_> codec-agnostic ftw [19:38:02] <peloverde> I agree [19:38:30] <_av500_> now, lets find KotH and a pizza hut... :) [19:43:13] <janneg> mru: the 4G machine is useful as long as there are frames which can be rendered with 4G. I'm hacking the job generation scripts used for their renderfarm [19:48:08] <peloverde> And for reasons mysterious to me ffplay doesn't appear to be working on my system [19:48:46] <_BBB_> http://web.mit.edu/xiphmont/Public/theora/demo.html <- I guess they know after all :) [19:49:29] <wbs> _BBB_: hi :-) [19:50:35] <Kovensky> _BBB_: oh you [19:54:12] <peloverde> Is there a reason why ffplay would refuse to play audio and refuse to exit? [19:54:32] <Kovensky> refuse to exit? o_O [19:55:07] <peloverde> I can sit there and tap q or escape or hit the wm close button and it just sits there [19:55:20] <peloverde> frozen and refusing to do anything [19:55:36] <_BBB_> Kovensky, huh? [19:55:48] <_BBB_> wbs: oh, hi martin :) [19:56:06] <_BBB_> wbs: svn account holders get ops here, not sure how to ask for it but you're a svn holder after all :) [19:56:36] <wbs> _BBB_: ooh :-) [19:57:01] <Kovensky> <@_BBB_> Kovensky, huh? <-- that way you prevent us from using tab complete to talk about BBB :( [19:57:03] <_av500_> peloverde: I have that when somebody else has the soundcard [19:57:14] <wbs> _BBB_: thought it was finally time to enter this channel too, to perhaps speed up some discussions, if needed :-) [19:57:14] <_BBB_> Kovensky, indeed1 [19:57:29] <_BBB_> Kovensky, you have no idea how noisy it gets when you guys are working on that video [19:57:32] <peloverde> _av500_, that was my thought.... it really should try to handle the situation more gracefully [19:57:46] <Kovensky> wbs: all developers should be here, actually [19:57:48] <Kovensky> http://www.codinghorror.com/blog/2008/11/is-email-efail.html [19:58:16] <_av500_> peloverde: I already once tried to debug it, but then it looked like SDL totally trashed gdb... [19:59:12] <Kovensky> _av500_: there are instructions in the SDL FAQ on how to make it not hijack gdb [19:59:27] <_av500_> ah, thx [19:59:46] <_av500_> I did not assume such malice... :) [19:59:54] <Kovensky> heh :) [20:03:09] <Kovensky> _av500_: SDL_INIT_NOPARACHUTE <-- OR it with the flags given to SDL_Init [20:03:17] <Kovensky> accidentally found it on mplayer's configure.log lol [20:03:26] <_BBB_> wbs: so about that url_concat() patch, there's the thing that it sort of induces you to require two buffers [20:03:43] <_BBB_> wbs: because you'll never, ever use the hostname just by itself, it's part of a larger thing [20:03:49] <DonDiego> _BBB_: the channel overlords can instruct chanserv to give op permanently [20:03:58] <DonDiego> me and mans for example :) [20:04:08] <_BBB_> oh, our overlord is here :) [20:04:11] <Kovensky> /mode #ffmpeg-devel +o wbs [20:04:13] <Kovensky> also works [20:04:14] <Kovensky> :) [20:04:23] <Kovensky> even if only until he leaves the channel lol [20:04:41] <DonDiego> wbs: you have not registered.. [20:04:47] <wbs> Kovensky: perhaps, yes - mail is a bit easier as long as one doesn't have all that much continuous time to commit [20:05:00] <_BBB_> wbs: I'm not saying that you need to make it like url_concat(target, size, proto, auth, host, port, path);, but I guess you see what I mean, right? [20:05:14] <_BBB_> wbs: also, don't use url_concat() on uninitialized memory, I have bad experience with that :) [20:05:22] <_BBB_> I mean, av_strlcat() [20:05:23] <_BBB_> sorry [20:05:24] * Kovensky finds mailing lists too unconvenient [20:05:53] <wbs> DonDiego: hmm, I registered with nickserv after joining, should I perhaps disconnect/part or something? [20:06:08] <_BBB_> /cycle [20:06:29] <wbs> \o/ [20:06:35] <DonDiego> welcome aboard :) [20:06:36] <Kovensky> /o\ [20:06:54] <wbs> thanks :-) [20:08:10] * _BBB_ wonders if he should reply to the list for archiving purposes [20:08:43] <wbs> well, I guess we can take the initial discussion here at least and the summarize the points on the list [20:08:53] <_BBB_> I guess [20:09:05] <Kovensky> isn't the IRC discussion archived now? :) [20:09:10] <Kovensky> big brother is watching, etc [20:09:35] <wbs> _BBB_: yeah, mostly we've gotten the url components from url_split earlier, but the url assembly code is a bit different in each case, so I'm not sure about a fullblown "assemble these components into a url" function [20:09:46] <_BBB_> so what I don't like about your patch is that it induces behaviour like this: char buf[..]; url_concat(buf, sizeof(buf), "some host"); snprintf(url, "tcp://%s:%d/%s", buf, etc); [20:09:50] <_BBB_> I don't like the temporary buf [20:10:17] <wbs> yeah, that's one issue indeed [20:10:35] <wbs> that's the reason for the other suggestions I had, but they're not pretty either [20:10:53] <_BBB_> since it's not speed-critical, maybe a fullblown function is OK [20:10:58] <_BBB_> at least it'll do the correct thing [20:11:06] <_BBB_> unless it's speed-critical [20:11:08] <_BBB_> which I doubt [20:11:34] <wbs> I highly doubt it's speed critical, too, the string will probably be passed blindly into getaddrinfo at some point anyway [20:12:17] <wbs> so you're suggesting a fullblown "assemble these things into an url" function? the problem with that is that there's quite a bit of individual cases out there [20:12:34] <_BBB_> url_split() exists and works... should be OK, I guess [20:12:45] <_BBB_> but I agree it'll be big and probably a bit ugly [20:13:08] <wbs> e.g. the Host: string in http, it needs to be of the form [123::1]:80, so that's a special case compared to building the tcp://[123::1]:80/ url [20:14:19] <_BBB_> really? host needs to be []-enclosed also? [20:14:25] <_BBB_> (in the HTTP header you mean, right?) [20:14:28] <wbs> yeah [20:14:46] <wbs> otherwise, if contacting an ipv6-vhost, how could the server parse out what's part of the ip and what's the port? [20:15:24] <wbs> e.g. Host: [123::456:789]:8080, without [] it's completely ambiguous [20:15:46] <_BBB_> good question [20:15:48] <_BBB_> ok [20:15:50] <_BBB_> hmm... [20:15:52] <_BBB_> hmm... [20:15:58] <_BBB_> and again hmm... [20:16:03] <Rathann> no, without [] it's not a valid host:port pair [20:17:58] <DonDiego> ##### MESSAGE TO MICHAEL ##### [20:18:09] <DonDiego> the cursed cathedral sample is broken.. [20:18:46] <Kovensky> </##### MESSAGE TO MICHAEL #####> [20:19:37] <kierank> needs more xml metadata [20:19:56] <kierank> <message type="communication" to="michael" from="dondiego" about="cathedral"> [20:21:33] <Kovensky> --- [20:21:35] <Kovensky> message: [20:21:38] <Kovensky> to: michael [20:21:41] <Kovensky> from: dondiego [20:21:45] <Kovensky> about: cathedral [20:21:50] <Kovensky> - IT BORKEN [20:21:54] <Kovensky> ... [20:22:26] <_av500_> would DonDiego forget the "."? [20:22:48] <Kovensky> no, '...' is the YAML EOF marker [20:23:22] <_BBB_> wbs: ok, I don't have an off-hand solution but again, if you can somehow get rid of the temp buffer, I'd greatly appreciate it [20:23:31] <kierank> actually my message fails because i didn't specify a schema [20:23:44] <Kovensky> lulz [20:23:47] * Kovensky <3 yaml [20:24:04] <_BBB_> wbs: worst-case, it's ok for me to make the function return [ip::ip]:port if proto == NULL (for HTTP purposes) [20:26:58] <wbs> _BBB_: after revisiting the code, we mostly have cases of tcp://%s:%d, and a few special cases with the http host header, an proto://host:port/path url in rtmp, and then the rtp://host:port?localport=%d&ttl=%d in rtsp... so I guess it would be quite simple to cover them all with such a function [20:30:35] <DonDiego> hrmpf [20:30:47] <DonDiego> the cathedral sample works with ffplay.. [20:31:16] <KotH> av500: i'm here [20:31:24] <KotH> av500: but pizza hut isnt ;) [20:35:12] <wbs> _BBB_: so, what about function signature like this: void url_join(const char* proto, const char* host, int port, const char* fmt, ...); [20:35:53] <_BBB_> what is fmt? [20:36:13] <wbs> a normal printf format for the rest of the url [20:36:36] <wbs> in rtsp, there's some ?localport=%d&ttl=%d that otherwise needs a temp buffer [20:37:29] <_BBB_> isn't var_args a portability nightmare? [20:38:24] <wbs> libavutil/avstring.c already uses them, don't know if it's confined to that place only or if it's used freely at other places too [20:38:44] <_BBB_> no, you're right, if it's used then it's ok [20:38:51] <_BBB_> if you add good doxy I guess it's OK [20:39:50] <wbs> ok, I'll give it a shot. with this change, the modifications to the individual protocols become very non-intrusive [20:53:05] <_BBB_> I like that [20:57:31] <KotH> janneg: what do you need to have installed? [21:01:46] <_BBB_> wbs: I sent a summary to the list [21:03:18] <wbs> _BBB_: great, thanks [21:03:46] <wbs> _BBB_: regarding having this as a non-public function, in what header should it be added? are there any libavformat "global" headers that aren't installed? [21:07:47] <janneg> KotH: only blender [21:17:31] <_BBB_> wbs: I suppose if I say "where-ever url_split() is", that's not the right answer? [21:18:53] <wbs> _BBB_: yeah, that'd be my first choice, too, but it's in avformat.h, and everything there is public/exported, right? [21:19:15] <_BBB_> url_split() isn't... [21:19:35] <_BBB_> well, since michael reads IRC log anyway: [21:19:44] <_BBB_> add it there and wait for him to say that it should be in a new header [21:19:50] <_BBB_> and let's take it from there [21:20:21] <wbs> ooh, there's an HAVE_AV_CONFIG_H section in avformat.h - then I guess it's ok to put it there [21:40:07] <ShadowJK> BBB, i don't know how anyone can read the intermixed drivel and actual content in one day batches like that :) [21:46:10] <_av500_> /tools/ircdigest? [21:47:33] <DonDiego> i tend to agree, reading irc logs can be a huge waste of time [21:47:37] <DonDiego> just like irc ;) [21:51:35] <KotH> lol [21:55:11] * KotH is an idiot [21:55:26] <DonDiego> we know, we know.. [21:55:28] <DonDiego> *sigh* [21:55:30] <DonDiego> ;-p [21:55:33] * KotH used a x86 install cd instead of an x86_64 [21:55:39] <DonDiego> lol [21:55:43] <DonDiego> k, gtg, cu [22:01:28] <ShadowJK> KotH, I've done that, but that was just because I didn't want to wait a week for the amd64 dvd to download :) [22:03:16] <Yuvi> hm, avformat_seek_file is still considered under construction [22:03:49] <Yuvi> did gstreamer / whoever else ever come up with actual suggestions / gripes? [22:03:54] <KotH> ShadowJK: well, in this case it's an issue [22:04:01] <KotH> ShadowJK: as i need a 64bit system [22:04:38] <ShadowJK> how old is this debian etch anyway [22:04:40] <peloverde> Why am I getting 403s on some of the samples? [22:04:42] <ShadowJK> i think that's what I'm running on it [22:05:01] <KotH> peloverde: which ones? [22:05:16] <peloverde> asian-commercials-are-weird.flv [22:05:28] <KotH> too many downloads [22:05:35] <KotH> use ftp with developer login [22:07:03] <astrange> oh, i still need to complain that there's no public index-reading function [22:10:23] <wbs> BBB: there, sent a new mail with the new function, and an example of converting all the protocol code to use it [22:12:55] <KotH> astrange: send script [22:32:47] <KotH> http://www.brainblog.to/item/2010/01/der-super-hacker [22:38:23] <andoma> KotH: that guy is awesome! [22:43:33] <janneg> KotH: lol [22:45:25] * janneg still wonders why windows resolves http://google.com [22:46:35] <CIA-92> ffmpeg: michael * r22084 /trunk/libavcodec/h264_cabac.c: [22:46:35] <CIA-92> ffmpeg: Optimize (amvd>2)+(amvd>32), about 1 cpu cycles faster. [22:46:35] <CIA-92> ffmpeg: patch by Zhou Zongyi @ zhouzy () os punkt pku dot edu speck cn [22:46:43] <KotH> prolly because there are too many windows admins who think the protocol is part of the hostname [22:48:04] <janneg> broken dns a.k.a. sitefinder could be another reason [22:48:17] <Kovensky> is that still about that hacker that says tracert shows you the IPs of the computers accessing google? [22:48:22] <Kovensky> well, "hacker" [22:48:32] <janneg> yes [22:48:50] <Kovensky> lulz [22:48:51] <andoma> perfect hire [22:48:59] <Kovensky> I saw that on larry oysterman's blag [22:49:17] <Kovensky> he said the guy owned him a new monitor because he spat coffee on his lol [22:55:17] <KotH> janneg: is there a minimal version of blender you need, or is debian/outdated ok? [22:58:01] <janneg> yes, it's sitefinder. 24.28.193.9 is allocated to roadrunner and not google [22:58:27] <janneg> KotH: no idea. I use the latest 2.49b [22:58:48] <KotH> janneg: hmm.. ok. i'll put debian/testing on [23:00:03] <janneg> ok, 2.46 might be too old, testing has the 2.49b [23:01:09] <KotH> janneg: i'll install gcc&co too, so you can compile anything you need or dislike ;) [23:02:50] <janneg> shouldn't be necessary, blender, vim, ssh and rsync should be enough [23:06:07] <Kovensky> debian/stale :) [23:06:08] * Kovensky ducks [23:52:44] <KotH> night boys