[FFmpeg-devel-irc] IRC log for 2010-02-26

[irc at mansr.com]

[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.html
[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/comment-page-1/#comment-4946
[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