[FFmpeg-devel-irc] IRC log for 2010-07-13

[irc at mansr.com]

[00:12:24] <bcoudurier> hehe
[00:13:55] <Compn> huh
[00:13:57] <peloverde> If you think his assessment is inaccurate and/or biased then simply give an official answer
[00:14:02] <Compn> _skal_ : so got any answers? :P
[00:14:07] <Compn> unrelated to Dark_Shikari
[00:14:10] <Compn> ignore him
[00:14:19] <Dark_Shikari> peloverde: google is allergic to certainty
[00:29:36] <Kovensky> <+hyc> C >> C++ <-- what would happen here? would the C first get shifted to the right by C bits and then incremented?
[00:30:07] <Kovensky> actually, that would always result in 1 wouldn't it
[00:49:03] <pengvado> undefined behaviour
[00:50:19] <CIA-99> ffmpeg: alexc * r24227 /trunk/libavcodec/aacsbr.c: aacsbr: Eliminate double precision arithmetic.
[00:51:03] <_skal_> surprisingly
[00:51:39] <_skal_> considering that log2(C) <= C
[00:52:11] <_skal_> compiler should hardcode 0 for this one
[00:56:35] <peloverde> ^ yay FFMIN() </sarcasm>
[01:01:56] <Compn> so skals not going to answer any of my dumb questions ? :(
[01:02:23] * Compn wants tons of samples
[01:21:45] <kierank> bcoudurier: how much do you know about smpte timecode?
[01:23:28] <bcoudurier> a bit
[01:24:00] <bcoudurier> I probably can answer your questions
[01:26:57] <kierank> do you know if there are any variations to the way it's encoded?
[01:27:07] <bcoudurier> a ton
[01:27:31] <kierank> there a lot of bits between the timecodes that I have no idea what they do: http://gitorious.org/ffmpeg-e-distribution-audio/ffmpeg-e-distribution-audio/blobs/master/libavcodec/edist.c
[01:27:38] <kierank> line 303 onwards
[01:28:08] <bcoudurier> lol at the name
[01:28:24] <bcoudurier> yup standard in dv
[01:30:00] <bcoudurier> oh you mean these 9 bits ?
[01:30:11] <kierank> yes all these bits in between
[01:30:35] <kierank> afaik the metadata has a "full" timecode whatever that means
[01:30:41] <kierank> so there must be more stuff there
[01:32:51] <bcoudurier> crc ?
[01:33:04] <bcoudurier> vitc comes with crc usually
[01:33:07] <bcoudurier> these 8 bits
[01:33:12] <bcoudurier> at the end
[01:34:25] <kierank> hmm maybe
[01:34:32] <bcoudurier> yeah it's binary group
[01:34:36] <bcoudurier> these 9 bits
[01:34:40] <bcoudurier> see SMPTE 2019 DNxHD
[01:35:44] <bcoudurier> or better SMPTE 12M
[01:37:45] <kierank> ok, thanks
[01:38:41] <bcoudurier> woah do you need to clip the values ? :>
[01:39:42] <kierank> dunno, it was more of a sanity thing
[01:40:59] <bcoudurier> 8 bytes total ?
[01:41:41] <kierank> iirc yes
[01:41:51] <kierank> anyway sleep time
[01:41:52] <kierank> night
[01:41:56] <bcoudurier> looks like DNxHD one
[01:42:07] <bcoudurier> good night
[01:43:49] <bcoudurier> maybe they shuffled things around
[03:39:41] <peloverde> siretart: Parts of README.Debian seem out of date
[06:18:14] <saintdev> is there an existing FIR filter?
[06:20:44] <kshishkov> yep, take any DSP book
[06:21:08] <saintdev> in lav* :P
[06:21:44] <kshishkov> resamplers
[06:22:04] <kshishkov> and MC interpolation code
[06:22:11] <kshishkov> no generic code though
[06:22:39] <kshishkov> may I offer you IIR filter since we have one?
[06:24:03] <saintdev> kshishkov: yeah i know about the iir
[06:27:36] * Sho_ imagines the Monty Python cheese shop sketch with filters
[06:28:05] <Sho_> s/sketch/skit/
[06:30:03] <twice11> The MP3 and DTS/DCA band mixers are also some sort of FIR filter.
[06:30:04] <kshishkov> Sho_: yes, we're fresh out of Wiener filters as well
[06:30:15] <kshishkov> indeed they are
[06:47:44] * benoit- is scratching his head on 24219
[06:49:43] <mru> benoit-: and scratch you may
[06:50:07] <benoit-> mru: why did you add that?
[06:50:13] <mru> I don't know
[06:50:17] <mru> it doesn't make sense
[06:50:30] <benoit-> agreed
[06:53:19] <mru> there must be something in the german water...
[06:54:14] <av500> mru: btw: http://ahoipolloi.blogger.de/stories/1663338/
[06:55:05] <mru> :-)
[06:55:22] <CIA-99> ffmpeg: mru * r24228 /trunk/libavcodec/avfft.c: 100l: really fix fft external API init functions
[06:56:16] <mru> lovely comments too
[06:56:28] <mru> lu_zero: "Ein Bisschen Hitze und die Deutsche Züge werden Italienisch."
[06:57:46] <benoit-> :)
[07:06:22] <av500> lol "modify the code"
[07:07:07] <mru> my favourite commit message is "fox typos"
[07:07:30] <av500> well, this is telling at least
[07:08:05] <kshishkov> mru: "fix something"
[07:08:25] <mru> that's one of mine
[07:08:36] <mru> actually it was "musb: fix something" iirc
[07:08:46] <kshishkov> indeed, I remember
[07:08:50] <av500> but I cant understand how they could add new functionality without renaming all the variables before, what's up with china these days
[07:09:15] * kshishkov wonders what's the deal about xavs - we have native en and decoder anyway
[07:09:35] <av500> NIIC syndrome
[07:10:12] <mru> we don't have an avs encoder
[07:11:16] <kshishkov> I thought we got one - or at least almost got it
[07:13:26] <av500> 1st rule of a succesful fork, make the code undiffable to the parent: http://xavs.svn.sourceforge.net/viewvc/xavs/trunk/matroska.c?r1=9&r2=27
[07:14:24] <kshishkov> 0th rule - relicense it a dozen times, preferably to nonexistent licenses
[07:14:39] <mru> lol @ the checkin comment
[07:14:42] <KotH> moin
[07:14:48] <kshishkov> shalom
[07:14:56] <benoit-> KotH: morgen
[07:15:31] <kshishkov> "modify the bugs" ?
[07:17:04] <av500> "first commit with no asm support"
[07:17:16] <saintdev> av500: first commit, aka fun with sed
[07:27:50] <cartman> av500: there should be a global coding style ;)
[07:28:02] <av500> of course, mine!
[07:34:29] <cartman> I would care much, if only there was something global
[07:35:44] * mru declares the global style to be the one without bugs
[07:36:04] * kshishkov always suspected it's nonexistent anyway
[07:44:08] <Sho_> cartman: hey
[07:44:32] <cartman> lo Sho_ :)
[07:44:44] <Sho_> cartman: so you do still know how to start an IRC client! :)
[07:44:55] <cartman> Sho_: seems so! :)
[07:45:03] <Sho_> nice :)
[07:45:19] <cartman> yeah nice to see friends around =)
[07:45:47] <Sho_> cartman: have to run off right now actually :-( but nice to see you around again!
[07:45:58] <cartman> Sho_: see ya!
[07:46:04] <Sho_> ditto :)
[07:50:29] <lu_zero> mru: ?
[07:50:34] <mru> lu_zero: !
[07:50:59] <ohsix> no better use for the interrobang
[07:51:15] <lu_zero> mru: .
[07:51:46] <kshishkov> what's stock price for other punctuation signs?
[07:51:55] <lu_zero> the lastlog gave me
[07:51:58] <lu_zero> 08:54 <@mru> lu_zero: "Ein Bisschen Hitze und die Deutsche Züge werden Italienisch."
[07:52:16] <mru> "a little heat and the german trains become italian"
[07:52:53] <mru> referring to the meltdown the german trains suffered this weekend
[07:53:25] <lu_zero> I was missing the news
[07:53:45] <lu_zero> sounds fair
[07:57:25] <lu_zero> mru: could you point me to a good arm/neon reference?
[07:57:36] <lu_zero> all I have is overly verbose
[07:58:25] <av500> arm website
[07:58:53] <lu_zero> av500: that is overly verbose AND chaotic =P
[07:59:30] <av500> prob mru to write one
[07:59:33] <av500> prod
[08:00:27] <lu_zero> av500: so the best docs so far are those =|
[08:01:13] <av500> I know no better ones
[08:01:29] <mru> the ARM ARM is the best I know of
[08:01:42] <mru> it's the only accurate and complete one I know of too
[08:02:55] <cartman> mru: what is there any "C/ASM for dummies"
[08:03:02] <cartman> s/what//
[08:03:20] <cartman> arm arm is pretty techical stuff
[08:03:31] <mru> asm coding _is_ technical
[08:05:06] <benoit-> cartman: what would you need apart from the instruction description to know what an instruction does?
[08:05:30] <cartman> benoit-: an introduction  to asm :)
[08:06:03] <av500> its a series of instructions...
[08:06:41] <cartman> never mind :)
[08:06:43] <Dark_Shikari> you could read one of the 5 chatlogs from every time that I've done my "asm tutoring" =p
[08:06:50] <cartman> I forgot your mocking potential :P
[08:06:54] <Dark_Shikari> where I've given about half a dozen separate people 2-hour tutorials on asm
[08:06:58] <Dark_Shikari> (all of whom went on to write great asm)
[08:07:17] <cartman> one question I would ask is
[08:07:32] <cartman> Should you be writing good C before good ASM?
[08:07:33] <mru> Dark_Shikari: that was sse, not arm
[08:07:58] <mru> cartman: not required
[08:08:08] <benoit-> cartman: I'd say no
[08:08:10] <mru> there were good asm coders before C was invented
[08:08:10] <cartman> mru: interesting
[08:08:43] <benoit-> I know people unable to write proper C code who are really good assembly-wise
[08:09:10] <mru> there is a connection between asm and C
[08:09:22] <mru> you must understand the machine to write well in either of them
[08:09:27] <Dark_Shikari> mru: I know
[08:09:30] <mru> but C is also more than that
[08:09:44] <Dark_Shikari> but if you want to "learn asm" IMO it doesn't matter what you start with -- the core concept is identical
[08:09:48] <Dark_Shikari> once you understand the core concept
[08:09:50] <Dark_Shikari> you can go learn any instruction set
[08:09:54] <Dark_Shikari> of course, every instruction set has its quirks
[08:10:04] <Dark_Shikari> and on some you have to care about different things than others
[08:10:09] <mru> true
[08:10:10] <Dark_Shikari> e.g. in neon scheduling matters, x86 not so much
[08:10:25] <mru> but x86 asm distracts from the core concept by being so full of quirks
[08:10:50] <Dark_Shikari> It's hard to say it's quirky when there's only about 3 other simd languages that matter to compare to
[08:11:00] <Dark_Shikari> neon, altivec, sse.... what others?
[08:11:05] <lu_zero> Dark_Shikari: spu
[08:11:13] <Dark_Shikari> isn't spu just an altivec derivative?  or is it a bit fancier?
[08:11:26] <mru> neon needs much fewer mind-bending hacks to be efficient
[08:11:46] <Dark_Shikari> I'd say it needs more
[08:11:49] <Dark_Shikari> scheduling is hard
[08:11:53] <mru> not really
[08:11:54] <Dark_Shikari> especially on an arch with a very high ratio of latency to throughput
[08:12:00] <Dark_Shikari> on x86 you can bullshit it all and it still works
[08:12:07] <lu_zero> Dark_Shikari: it has some more instructions and you get some new concepts about memory management
[08:12:09] <mru> loop unrolling is all you need
[08:12:13] <Dark_Shikari> lu_zero: oh true, there's the DMA
[08:12:35] <Dark_Shikari> though that isn't really asm per se, that's more of an architecture thing
[08:12:39] <lu_zero> so in itself is a bit interesting
[08:12:46] <Dark_Shikari> i.e. it affects how you build your application
[08:12:48] <Dark_Shikari> and less the asm
[08:13:04] <lu_zero> (more stuff exposed)
[08:13:12] <mru> it does affect the code in some ways
[08:13:33] <lu_zero> more or less like the ppc atomic primitives vs x86 ones
[08:13:34] <mru> you really must process data a block at a time
[08:13:38] <mru> you can't go jumping about
[08:14:08] <lu_zero> and you know in a quite rought way if your code is overly bloated ^^;
[08:17:18] <cartman> how do you learn the "main concept" ?
[08:17:47] <mru> by years of hard work
[08:17:57] <lu_zero> the main concepts....
[08:17:59] <cartman> hard work needs to start with something :)
[08:18:17] <lu_zero> well you have to know how the cpu usually work
[08:18:20] <kshishkov> main concept, ele card, div x, whatever
[08:18:22] <mru> or flip through the manual and apply common sense
[08:18:45] <cartman> lu_zero: thats a good start :)
[08:18:56] <cartman> a computer architechture book
[08:19:05] <lu_zero> mru: before maybe knowing a bit about pipelining, cicles per instruction and such help
[08:19:07] <mru> for ARM, I recommend the ARM ARM
[08:20:10] <lu_zero> after that all you need is an indexed/searchable doc
[08:20:27] <lu_zero> with instruction name - what it does - latency/quirks
[08:21:05] <KotH> oi cartman
[08:21:10] <cartman> lo KotH
[08:21:23] <cartman> whats the name for the arm arm book btw?
[08:21:25] <cartman> Google is confused
[08:21:37] <KotH> arm architecture reference manual
[08:21:51] <cartman> ah thanks KotH , always a useful guy!
[08:22:02] <mru> cartman: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0406b/index.html
[08:22:15] <KotH> and if you want an intro into asm, go to a used book store, and grab yourself an copy of an old x86 asm book
[08:22:29] <cartman> KotH: I am working on ARM tablets these days
[08:22:34] <cartman> would be interesting to learn arm asm
[08:22:35] <mru> KotH: that sounds like bad advice
[08:23:03] <mru> x86 asm has very little in common with arm
[08:23:13] <cartman> mru: got the pdf version? :)
[08:23:20] <mru> just download it
[08:23:26] <mru> you probably have to register
[08:23:26] <cartman> need registration
[08:23:30] <mru> but it's harmless
[08:23:32] <cartman> oh k
[08:23:33] <mru> they won't spam you
[08:23:35] <lu_zero> cartman: it's free
[08:25:06] * lu_zero obviously forgot which email he registered with...
[08:25:57] <cartman> I was already registered, it seems
[08:25:57] <cartman> :)
[08:27:29] <Dark_Shikari> mru: x86 asm has the same things in common with arm that it has in common with all asm
[08:27:37] <Dark_Shikari> it's really all the same shit.
[08:27:38] <mru> which isn't a lot
[08:27:45] <Dark_Shikari> at most, it might be
[08:27:51] <Dark_Shikari> "oh cool, I can do this with arm that I couldn't do with x86"
[08:27:55] <Dark_Shikari> or "crap, can't do this on arm"
[08:28:01] <Dark_Shikari> but really, it's all the same shit.
[08:28:14] <mru> in the sense of "instructions do stuff with registers" yes
[08:28:29] <Dark_Shikari> the hardest concepts to grasp are the basic ones.
[08:28:40] <mru> but arm is a strict load/store architecture
[08:28:40] <Dark_Shikari> once you have those, everything else is easy.
[08:28:42] <lu_zero> x86 hides a _lot_ from you
[08:29:26] <mru> x86 has only a few registers and relies on memory operands
[08:29:37] <mru> a naive translation to arm will stink badly
[08:29:49] <Dark_Shikari> But why would you ever translate?
[08:30:10] <mru> if you learned x86 asm you might still be thinking in those terms
[08:30:25] <Dark_Shikari> I don't see the relevance
[08:30:27] <Dark_Shikari> asm is just a set of tools
[08:30:33] <Dark_Shikari> different arches have different tools
[08:30:44] <Dark_Shikari> if you went up to a carpenter and said "build this desk without a screwdriver"
[08:30:48] <Dark_Shikari> he could do it
[08:30:53] <Dark_Shikari> just like going to an x86 asm programmer and saying
[08:30:54] <av500> of course
[08:30:54] <mru> yes, and you can't do fine woodwork with a jackhammer
[08:30:56] <Dark_Shikari> "don't use memory operands"
[08:31:08] <Dark_Shikari> or saying "hey, you now have 16 registers."
[08:31:10] <av500> who needs a screwdriver for a desk anyway...
[08:31:16] <Dark_Shikari> av500: IKEA!
[08:31:26] <mru> comes with a little allen key
[08:31:40] <Dark_Shikari> the gods of particleboard
[08:31:43] <kshishkov> mine still required screwdriver to assemble
[08:32:12] <av500> you just need glue! :)
[08:32:26] <av500> and a biscuit router
[08:32:38] <lu_zero> what's bisquit router?
[08:32:40] <lu_zero> a
[08:33:02] <kshishkov> I can route busquits to myself without any tools
[08:33:02] <Dark_Shikari> one that goes well with butter
[08:33:06] <ohsix> it plunge cuts slots to put little wedges of wood that absorb glue in
[08:33:21] <av500> lu_zero: http://images.meredith.com/wood/images/p_biscuit.jpg
[08:33:24] <av500> yummy
[08:34:51] <lu_zero> ^^;
[08:35:18] * kshishkov wants to hint that modern furniture may include metal and glass
[08:35:53] <av500> meh
[08:38:28] * kshishkov pries av500's book "Stumps - the only way to build furniture" from his hands
[08:39:31] <av500> kshishkov: no stumps involved: http://www.flickr.com/photos/av500/3694812587/
[08:39:57] <benoit-> wow! what an award: http://www.downloadroute.com/images/av-awards/FFmpeg-FFmpeg.png
[08:40:06] <av500> and ok, you need a screwdriver for the hinges
[08:40:07] <benoit-> I hope you guys are proud of that
[08:40:18] <benoit-> such an achievement
[08:40:31] <av500> well, good time to add ffads...
[08:40:40] <benoit-> we've been waiting for that all our lives; and there it is, at least!
[08:41:05] <Dark_Shikari> the reason sites "award" those is to try to get you to put the award on your page
[08:41:08] <Dark_Shikari> and link back to them
[08:41:14] * kshishkov waited for something completely different
[08:41:56] <av500> Hmm, i can photoshop such an award in 5 minutes
[08:42:28] <kshishkov> av500: please do - The Official FFmpeg Seal of Approving FFmpeg
[08:48:06] <av500> http://imagebin.ca/view/SN_zA5v.html
[09:03:52] <Dark_Shikari> so should I crosspost http://mailman.videolan.org/pipermail/x264-devel/2010-July/007508.html
[09:03:55] <Dark_Shikari> to ffmpeg-devel?
[09:03:57] <Dark_Shikari> or ffmpeg-users?
[09:05:19] <kshishkov> wasn't Google using inhouse H264 encoder?
[09:05:35] <Dark_Shikari> no, they use x264 now for youtube
[09:07:10] * kshishkov wants FFmpeg Enterprise Edition bundled with it
[09:07:27] <Dark_Shikari> What special features are in Enterprise Edition?
[09:07:31] <Dark_Shikari> besides the gold-plated manual
[09:07:43] <kshishkov> it's harder to use
[09:08:00] <Dark_Shikari> impossible.
[09:08:28] <kshishkov> do you usually use ed for editing?
[09:08:51] <Dark_Shikari> lol
[09:08:51] <peloverde> Dark_Shikari: Reddit hates you today :)
[09:08:59] <mru> link?
[09:09:02] <Dark_Shikari> only today?
[09:09:06] * mru wants to gloat :-)
[09:09:09] <peloverde> especially today?
[09:09:09] <peloverde> http://www.reddit.com/r/programming/comments/cougf/x264devel_announcing_commercial_licensing_for_x264/
[09:10:23] <kshishkov> Dark_Shikari: also why your x264 page spells FFmpeg name without capital F's?
[09:10:53] <Dark_Shikari> fuck that.
[09:10:57] <Dark_Shikari> lol
[09:11:00] <Dark_Shikari> it's a unix tool
[09:11:03] <Dark_Shikari> therefore, it is all lower case
[09:13:13] <av500> Dark_Shikari: clever plot, 1st diss VP8, then sell X264 :)
[09:13:41] <Dark_Shikari> yes, I'm horribly evil
[09:13:57] <Dark_Shikari> except for the part where x264 isn't competing with vp8.
[09:14:28] <peloverde> I never noticed that gregory maxwell wrote a rebuttle http://lists.wikimedia.org/pipermail/wikitech-l/2010-May/047795.html
[10:08:55] * mru has enough of ubuntu and installs portage on top of it
[10:09:24] <Dark_Shikari> lol
[10:14:38] <lu_zero> gentoo-prefix or just taking over?
[10:14:55] <Dark_Shikari> http://x264dev.multimedia.cx/?p=486
[10:15:12] <mru> lu_zero: hostile takeover
[10:15:16] <lu_zero> ^^;
[10:15:26] <lu_zero> rsync is wonderful for that
[10:15:51] <mru> I'm just emerging things I as need them
[10:16:01] <lu_zero> ^^;
[10:16:01] <av500> Dark_Shikari: now imagine google opening up to bistream changes in order to add "interlaced" :)
[10:16:28] <av500> "due to popular demand"!
[10:16:41] <elenril> Dark_Shikari: inb4 mpeg-la paid you
[10:16:42] <lu_zero> argh
[10:38:30] <KotH> mru: but at least it teaches you the basics of asm
[10:38:42] <KotH> mru: unlike all of these reference books, which teach you only the details
[10:39:07] <mru> KotH: what "it"?
[10:39:36] <kshishkov> mru: "x86 asm for complete dummies"
[10:39:39] <twice11> "it" seems to be the x86 asm introduction book mentioned some hours ago.
[10:54:41] <Dark_Shikari> http://graphjam.files.wordpress.com/2010/07/funny-graphs-good-team-playing-bad-world-cup-parodox-england-still-winning-spain-japan-germany.png
[10:55:29] <thresh> parodox, orly
[10:55:52] <av500> Dark_Shikari: nice
[10:55:59] <mru> where's north korea in that graph?
[10:56:10] <mru> them being there at all was the biggest paradox
[10:56:21] <av500> them returning home is a paradox
[10:56:39] <mru> are they still alive?
[10:57:15] <av500> go to north korea and check
[11:03:49] <av500> hmm, http://graphjam.files.wordpress.com/2010/06/funny-graphs-where-trolls-really-live.png
[11:13:47] <cartman> av500: lol
[11:15:14] <Dark_Shikari> http://graphjam.files.wordpress.com/2010/06/funny-graphs-talents-of-the-italian-team-in-the-world-cup.png
[11:38:18] <lu_zero> Dark_Shikari: I'm wondering
[11:38:22] <spaam> av500: so mru live with his mother....
[11:38:42] <lu_zero> how hard would be add vp8 to x264?
[11:38:53] <Dark_Shikari> I've answered this before; not too difficult
[11:39:06] <Dark_Shikari> just a quick scan of the files that would need or not need changing
[11:39:29] <Dark_Shikari> analyse.c: not many changes, mostly just removing stuff
[11:39:33] <Dark_Shikari> cabac.c: rewrite
[11:39:36] <Dark_Shikari> cavlc.c: remove
[11:39:36] <mru> spaam: no, I live under a bridge
[11:39:39] <thresh> so you'll rename to xp8?
[11:39:46] <Dark_Shikari> encoder.c: partial rewrite, mostly header stuff and reference handling
[11:39:49] <Dark_Shikari> lookahead.c: unchanged
[11:39:51] <Dark_Shikari> macroblock.c: rewrite
[11:39:55] <Dark_Shikari> me.c: mostly unchanged
[11:40:01] <Dark_Shikari> ratecontrol.c: tiny minor changes
[11:40:10] <Dark_Shikari> rdo.c: rewrite the trellis (or remove), everything else the same
[11:40:14] <Dark_Shikari> set.c: rewrite, that's header stuff
[11:40:22] <Dark_Shikari> slicetype.c: keep the same, just turn off b-frames
[11:42:45] <kshishkov> what about AVS :{
[11:44:37] <wbs> Dark_Shikari: how hard would that be to integrate in x264 itself, to keep both h264 and vp8 encoding in the same codebase?
[11:44:52] <Dark_Shikari> not unreasonable.
[11:45:01] <Dark_Shikari> especially if you don't implement all of vp8.
[11:46:16] <kshishkov> well, I think you've still not implemented all of H.264
[11:46:55] <Dark_Shikari> of course, but vp8 is quite a bit smaller.
[11:47:04] <kshishkov> good for them
[11:47:05] <Dark_Shikari> for example, not implementing alt refs would make things simpler.
[11:47:25] <kshishkov> B-frame reordering :)
[11:47:26] <Compn> x264vp8 could corner both encoding markets
[11:47:27] <Compn> lulz
[11:48:20] <lu_zero> and would be another implementation
[11:48:26] <Compn> bwahaha
[11:48:34] <lu_zero> making the whole vp8 stuff more interesting
[11:48:35] <Compn> well, better than on2 encoder
[11:49:16] <lu_zero> since you might then have a better leverage about adding stuff on vpnext
[11:49:39] <Dark_Shikari> I would commit a patch to add vp8 support.
[11:49:58] <thresh> oh come on, x264 getting more and more bloated
[11:50:10] <lu_zero> thresh: shut up =P
[11:50:25] <kshishkov> thresh: what do you expect, it's going corporate
[11:50:33] <thresh> :)
[11:50:53] <Dark_Shikari> yeah, damn those "useful features" like audio support
[11:51:06] <thresh> yeah, heard of unix way of doing stuff? :)
[11:51:29] <Dark_Shikari> yes, that's called gstreamer
[11:51:34] <Dark_Shikari> piping between modules...
[11:51:36] <Dark_Shikari> oh wait, we hate that =p
[11:51:42] <kshishkov> thresh: they had it that way, then somebody decided to listen to users
[11:51:45] <thresh> that's not nix way I knew about it
[11:51:55] <Dark_Shikari> well, ffmpeg is definitely not the nix way
[11:52:04] <thresh> i wasnt claiming that ;P
[11:52:04] <Dark_Shikari> everything stuffed together into a bunch of interdependent, inseparable libs
[11:53:20] <kshishkov> oh, and they all depend on libc/libm
[11:54:21] * Compn tries to imagine installing 100 different projects just to get same functions as ffmpeg
[11:54:43] <Compn> no, dont think so
[11:54:57] <Dark_Shikari> nobody said the unix way was inherently right.
[11:55:15] <thresh> sure it is, ask stallman!
[11:55:28] <Dark_Shikari> no no no
[11:55:30] <Dark_Shikari> he's not about unix
[11:55:33] <Dark_Shikari> he's about GNU/LINUX.
[11:55:34] <kshishkov> thresh: luckily, it has nothing to do with him
[11:55:41] <kshishkov> GNU/Hurd
[11:55:52] <kshishkov> or GNU/EMACS
[11:55:59] <DonDiego> stallman is a lisp hacker from a community that predates unix
[11:56:10] <Dark_Shikari> I'd just like to interject for a moment. What you're referring to as Linux, is in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning GNU system made useful by the GNU corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX.
[11:56:16] <kshishkov> IIRC it was McIlroy who invented pipes and helped defining Unix way
[11:56:18] <DonDiego> please revisit your history lessons before trolling
[11:56:27] <thresh> ;-)
[11:56:32] <Dark_Shikari> DonDiego: >predates unix
[11:56:38] <Dark_Shikari> I'm pretty sure unix was around before he was born.
[11:56:47] <thresh> my brain melts here, cant use it...
[11:56:48] <DonDiego> he?
[11:56:56] <DonDiego> he == stallman?
[11:56:59] <Dark_Shikari> Unix was 1969.
[11:57:04] <Dark_Shikari> oh, wow, you're right
[11:57:06] <Dark_Shikari> he's really fucking old
[11:57:08] <Dark_Shikari> 1953
[11:57:19] <DonDiego> remember what i told you about the history lesson?
[11:57:20] <thresh> you thought he's in this 30s?
[11:57:27] <Dark_Shikari> no, 40s
[11:57:35] <Dark_Shikari> DonDiego: he was hacking on lisp when he was 16?
[11:57:36] <kshishkov> thresh: Russians are not supposed to think with _brain_ anywau
[11:57:38] <kshishkov> *anyway
[11:57:41] <Dark_Shikari> I doubt that.
[11:57:51] <DonDiego> around that age
[11:57:58] <DonDiego> but unix was not used everywhere then
[11:58:08] <Dark_Shikari> well of course.
[11:58:11] <thresh> kshishkov: yes, everything is decided by party and pm
[11:58:26] <pross-au> What's the relevance of lisp again?
[11:58:28] <Dark_Shikari> even today unix isn't "used everywhere".
[11:58:30] <DonDiego> he was a lisp hacker before he got exposure to unix even iirc
[11:58:34] <Dark_Shikari> pross-au: HAVE YOU READ YOUR SICP TODAY?
[11:59:07] <Dark_Shikari> My other car is a cdr.
[11:59:18] <kshishkov> thresh: not only that, you should know traditional Russian way of doing things and proverb "русский человек _задним_ умом крепок"
[11:59:53] <thresh> kshishkov: nice troll. ;-)
[11:59:59] <KotH> Dark_Shikari: sounds like you've read the whole of it :)
[12:00:03] <siretart> peloverde: what do you mean specifically?
[12:00:04] <kshishkov> pross-au: it serves the role of Visual Basic for not so dummy people - learning language, internal script language, etc
[12:00:46] * kshishkov wonders where's the browser with LispScript support though
[12:01:01] <KotH> kshishkov: it's called emacs
[12:01:07] <mru> browsers are written by dummies
[12:01:19] <mru> and yes, emacs has a browser
[12:01:29] <mru> worst browser ever btw
[12:01:32] <Dark_Shikari> it needs a text editor though
[12:01:37] <Dark_Shikari> imho
[12:01:42] <kshishkov> mru: worse than text editor?
[12:01:57] <mru> Dark_Shikari: I'm writing code, what would I do with a text editor?
[12:01:58] <pross-au> Do should it be called GNU/FFmpeg?
[12:02:04] <mru> FFgnu
[12:02:04] <av500> at least it has a good mailer...
[12:02:13] <av500> FFmpegnu
[12:02:18] <mru> av500: it really does
[12:02:37] <pross-au> I mean, the first versions only worked on gcc
[12:02:49] <pross-au> Just like Linux
[12:03:00] <spaam> mru: do you watch movies in emacs? :)
[12:03:00] <kshishkov> Emacs also demonstrates huge deviation from Unix way BTW
[12:04:46] <av500> spaam: he watches movies in md5sum....
[12:05:14] <kshishkov> av500: indeed, I saw him doing so
[12:06:11] <thresh> stallman uses vlc
[12:07:32] <pross-au> thresh: which codecs?
[12:07:39] <lu_zero> thresh: how so?
[12:07:47] <thresh> I only know about V4L
[12:08:16] <thresh> http://mailman.videolan.org/pipermail/vlc-devel/2007-October/035357.html
[12:08:20] <thresh> see attachment in the end
[12:08:31] <kshishkov> thresh: good point against VLC, I'll remember that
[12:08:44] <thresh> ;-)
[12:24:37] <foehn> does someone know of a fixed-point port of wmaenc ?
[12:30:34] <kshishkov> foehn: rockbox devs do
[12:34:29] <av500> encoder?
[12:37:04] <foehn> only saw a decoder in their sources
[12:38:46] <kshishkov> ah, fixed-point encoders are not that popular
[12:40:27] <av500> encoding in WMA is not popular anyway
[12:41:15] <foehn> how about fixed-point mp3 ?
[12:45:08] <kshishkov> unlikely
[12:45:26] <kshishkov> of course you can do that but why?
[12:48:05] <foehn> I need either a wma or mp3 encoder for an arm9 cpu
[12:50:39] <kshishkov>  well, Google in help
[12:53:39] <foehn> didn't find anything...
[12:54:06] <av500> commercial solutions exist for sure
[12:56:07] <foehn> that's true, but I'm looking for open-source
[12:56:26] <foehn> would even offer a bounty for implementing it in ffmpeg
[12:56:30] <kshishkov> just make one then
[12:58:04] <av500> there is this "shine" thing
[13:03:35] <foehn> yep, I was thinking of trying to integrate it into ffmpeg
[13:03:50] <foehn> but it's rather slow, needs 130Mhz+ on an ARM9E
[13:05:11] <av500> patches welcome I guess...
[15:14:50] * KotH could need a search function over the samples collection
[15:16:06] <mru> search for what?
[15:16:49] <KotH> i need a 640x480 sized sample of at least 1min size, mpeg4 asp, audio doesnt matter
[15:17:05] <mru> make one
[15:18:41] <av500> ffmpeg -i ....
[15:19:30] <thresh> or ffprobe, indexed
[15:29:54] <Jianwen> hi
[15:31:38] <KotH> could someone with a state of the art PC (aka i7 class) do me a favor and run time for i in `seq -w 1 1000`; do convert -size 640x480 xc: +noise Random blah${i}.png;done and tell me the numbers? thanks
[15:51:12] <KotH> .o0(looks like all those with fast machines run away)
[15:54:06] <lu_zero> I have a lousy quad core would be ok?
[15:54:59] <KotH> what cpu?
[15:55:04] <lu_zero> phenom
[15:55:25] <KotH> i'd say that sounds ok
[15:56:04] <lu_zero> let me unbreak imagemagick on that box
[15:56:43] <KotH> unbreak?
[15:57:33] <mru> real    2m9.076s
[15:57:33] <mru> user    2m18.284s
[15:57:33] <mru> sys     0m5.126s
[15:57:49] <KotH> mru: cpu?
[15:57:54] <mru> i7 940
[15:58:02] <KotH> GHz?
[15:58:06] <mru> 2.93
[15:58:11] <KotH> thanks a lot!
[15:58:23] <mru> in tmpfs btw
[15:58:32] <KotH> that's ok
[15:58:54] <KotH> i need a guestimate for how much faster an up to date machine is, compared to what i have here ^^'
[15:59:02] <pengvado> did you intend to bench both the noise generator and the png encoder?
[15:59:10] <KotH> yes
[16:15:24] <spaam> KotH: what do you get? :)
[16:16:57] <iive> mru: i thought your computer had ecc ram.
[16:18:04] <KotH> spaam: real    13m35.476s
[16:18:24] <spaam> what kind of cpu is that? :O
[16:18:34] <KotH> p4 1.6ghz
[16:18:51] <KotH> i wouldnt ask for a fast machine if i'd have one at hand ;)
[16:22:32] <microchip_> KotH: Willamette?
[16:24:02] <KotH> microchip_: gesundheit!
[16:24:10] <microchip_> ?
[16:24:29] <microchip_> i was asking if the p4 was a Willamette (which is the worst p4 core arch)
[16:25:30] <microchip_> ya know, under the p4 you have Willamette's, Northwoods, Prescotts, etc
[16:27:17] <KotH> i have no fucking clue
[16:27:34] <twice11> 1.6GHz sounds like the first core arch.
[16:27:46] <microchip_> it must be a Willamette, no Northwood or Prescott has such low frequency
[16:28:36] <microchip_> iirc, Nrothwoods start at 1.8 GHz
[16:28:44] <microchip_> or was it 2?
[16:36:42] <twice11> Wikipedia says northwood starts at 1.6GHz.
[16:37:15] <twice11> Easiest disctinction: Willamette has 256KB L2, Norhtwood 512
[16:37:39] <mru> CELERON!!!
[16:38:05] <twice11> Dual Celeron 300A @ 450 (cheapest SMP ever)?
[16:59:14] <KotH> mru: selerie is something to eat, not something to run computers with ;)
[17:04:22] <Kovensky> <KotH> spaam: real    13m35.476s <-- o_o'
[17:04:27] <Kovensky> real    6m18.229s
[17:04:27] <Kovensky> user    4m53.368s
[17:04:27] <Kovensky> sys     0m23.692s
[17:04:31] <Kovensky> (Sempron 2800+ @ 1.7GHz)
[17:05:10] <twnqx> O_O
[17:05:31] <KotH> Kovensky: it's a p4 :)
[17:05:43] <Kovensky> I could test on a T2370 but it'd be on a cygwin+win7 so you'd get hours of sys
[17:05:51] <KotH> lol
[17:07:24] <Kovensky> either that or it'd overheat and suffer an emergency shutdown
[17:07:33] <Kovensky> shit idles at 70C at best ._.
[17:07:41] <KotH> o_0
[17:07:54] * Kovensky is forcibly throttling it to 80% speed to avoid reaching 100C
[17:11:58] <twnqx> i once throttled a cpu clockspeedwise to avoid blowing the fuse in a plane >_>
[17:54:08] <alien_> im looking for the bes video converter but im a newbie so i need a screen that shows me what im doing,,not terminal
[17:54:16] <alien_> can someone help
[17:54:47] <peloverde> "Questions about using FFmpeg or developing with the libav* libraries should be asked in #ffmpeg."
[17:55:54] <alien_> so even if u know u wont tell me necause im not in that channel
[17:56:29] <twnqx> ffmpeg doesn't show
[17:56:39] <twnqx> actually, none of the good tools do :P
[17:56:52] <alien_> not good
[17:56:55] <twnqx> also, an encoder just encodes. nothing to see here.
[17:56:58] <alien_> hard to work for newbies
[17:57:43] <alien_> see somebody that wants to work with linux need a degree on computers
[18:01:00] <Compn> twnqx : recommend 'super' next time :P
[18:02:40] <CIA-99> ffmpeg: mru * r24229 /trunk/libavcodec/avfft.c: avfft: remove useless parens
[18:12:23] <peloverde> "This seems like a real mess. How come that Opera managed to release a (supposedly) compatible WebM decoder?
[18:12:23] <peloverde> " WTF are people really that retarded
[18:12:42] <BBB> opera uses libvpx, no?
[18:13:02] <BBB> I emailed their CTO once, he doesn't like ffmpeg - at all
[18:13:04] <peloverde> opera uses libvpx wrapped via gstreamer
[18:13:09] <BBB> he calls "the whole thing" a mess
[18:13:30] <elenril> ffmpeg is clearly evil
[18:13:56] <elenril> decodes other formats than theora etc
[18:14:51] <BBB> "ffmpeg makes vp8 violate h264 patents"
[18:14:56] <kierank> lol
[18:14:59] <mru> by sharing code between h264 and vp8
[18:15:09] <kierank> flawless logic right there
[18:15:12] <BBB> absolutely
[18:15:22] <mru> I wouldn't be surprised if someone said that and meant it
[18:15:40] <mru> like mozilla believe using ffmpeg to decode theora is illegal
[18:15:42] <BBB> it's sad how that kind of mindset is supported by supposedly "pro-free-software" tards
[18:16:04] <BBB> mozilla knows better, at least their board... just some people around it are insanely stupid, like chris blizzard
[18:16:06] <mru> the "tard" part says it all
[18:16:27] <BBB> after all, mozilla funded that website to convert any video to theora^d^dwebm
[18:16:32] <BBB> what's its name again?
[18:16:39] <BBB> miro?
[18:16:39] <kierank> wehavetoomuchgooglemoney.com
[18:16:47] <mru> youtube?
[18:17:02] <BBB> mirovideoconverter.com
[18:17:04] <BBB> funded by mozilla
[18:17:07] <BBB> uses ffmpeg internally
[18:17:19] <elenril> >convert any video
[18:17:25] <elenril> so yeah, what else could they use
[18:17:50] <BBB> gstreamer?
[18:17:53] <BBB> oh wait
[18:17:54] <kierank> so you use supposedly evil patented software so you can avoid using evil patented software
[18:18:00] <kierank> more flawless logic
[18:19:10] <elenril> BBB: actually tons of user have no idea they're using ffmpeg
[18:19:39] <elenril> it needs more publicity
[18:20:52] <peloverde> elenril: I agree
[18:21:46] <BBB> I've said that once
[18:21:50] <kierank> turn ffmpeg into some sort of emotional argument and you'll get all the publicity you like
[18:21:53] <kierank> that's what xiph do
[18:22:09] <BBB> but all projects that use ffmpeg to supposedly free you from the patented evil outside world, they all refuse
[18:22:34] <BBB> I don't think they even know that ultimately, we're all on the same side
[18:22:35] <BBB> but ohwell
[18:22:36] <kierank> also you need to make vlc change their name to ffmpeg/vlc
[18:22:48] <jai> lol
[18:23:08] <kierank> and if anyone just says plain "VLC" inflict a verbal tirade on them
[18:23:13] <elenril> lawl
[18:23:39] <mru> ff/vlc
[18:24:01] <BBB> just ffvlc
[18:24:08] <BBB> fstreamer
[18:24:14] <BBB> fnome
[18:24:37] <BBB> we should rewrite glib and base it on libavutil and call it lavulib
[18:24:53] <peloverde> What about firefogg
[18:25:09] <jai> lavc/lavf bindings for python/ruby might get some publicity
[18:25:14] <jai> well atleast on reddit
[18:25:21] <kierank> or haskell
[18:25:27] <peloverde> That's another thing people say they use to avoid ffmpeg, but it really wrapps FFmpeg
[18:25:41] <jai> kierank: dons will do that :)
[18:25:42] <peloverde> Can we ask free software projects taht ship ffmpeg binaries to credit FFmpeg?
[18:25:49] <BBB> peloverde: yes
[18:26:01] <BBB> but the definition of "credit" in legal terms is rather unspecific
[18:26:06] <mru> someone should create a libavcompat of lavc wrappers api-comptible with everything we replace
[18:26:07] <jai> peloverde: of course
[18:26:14] <BBB> source code attribution might be enough already
[18:26:19] <jai> one would assume they do that already, but you never no...
[18:26:22] <BBB> so gpl-compliant projects that ship source would never have problems
[18:26:27] <mru> and then insist that anything using libpng or is derived from ffmpeg and thus patented
[18:26:33] <jai> *know
[18:26:36] <mru> s/or//
[18:26:44] <peloverde> BBB, jai: I don't really care about full source offfer yada yada, but credit and a link is more than reasonable
[18:26:58] <BBB> peloverde: I fully agree
[18:27:01] <jai> indeed
[18:27:09] <BBB> peloverde: I think most projects do that, we should ask the ones that don't to still do it
[18:27:16] <mru> the full source code thing is a nice stick to beat them with
[18:27:29] <BBB> http://gstreamer.freedesktop.org/modules/gst-ffmpeg.html - no ffmpeg link
[18:27:41] <jai> BBB: yell at them ;)
[18:27:44] <BBB> who was the gst kid in here again?
[18:27:54] <mru> bilboed
[18:27:55] <jai> bilboed isnt around
[18:27:56] <peloverde> superdump ;)
[18:28:01] <mru> BBB
[18:28:20] * elenril sees no mention of ffmpeg at http://www.mplayerhq.hu/design7/info.html
[18:28:25] <peloverde> http://firefogg.org/ has no mention
[18:28:29] * kshishkov suspects it's everybody except him
[18:28:41] * elenril blames KotH 
[18:29:38] <elenril> youtube doesn't give credit!
[18:29:59] <BBB> youtube doesn't distribute
[18:30:00] <jai> _skal_: ^
[18:30:06] <jai> but credit would be nice :)
[18:30:10] <BBB> agreed
[18:30:18] <BBB> bbc doesn't credit
[18:30:24] <BBB> although they openly admit on our mailinglist
[18:30:31] <KotH> i'd rather take their money than their credit ;)
[18:49:11] <peloverde> http://bugs.launchpad.net/firefogg/+bug/605132
[18:50:18] <jai> peloverde: thx for doing that
[18:52:05] <jai> also, now that ffprobe is in trunk, maybe we can remove it from projects.html?
[19:01:21] <peloverde> Is it better to just add these free software projects to the projects using FFmpeg page or wait until they reach some level of "compliance"?
[19:03:48] <peloverde> Also the tcvp link is dead
[19:16:26] <_av500_> tcvp ftw!
[19:23:06] <mru> heh
[19:23:41] <mru> it's probably the most over-engineered thing I've ever made
[19:24:24] <mru> but that's what you get when you take two crazy EE students and give them too much time
[19:25:09] <mru> it actually started out as an assignment at uni
[19:25:39] <mru> it went out of control somewhere along the way
[19:27:33] <peloverde> Does anyone remember the name of the thread where the audio overhaul is being discussed?
[19:27:44] <mru> which one of them?
[19:28:07] <mru> I guess pross-au's thread is more focused
[19:28:47] <astrange> [FFmpeg-devel] [PATCH+RFC] AVFrame for audio
[19:30:14] <mru> hmm, look what I found http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/10208
[19:31:20] <peloverde> You mean we discuss something for a while, fail to reach consensus, and shelve it? Unthinkable
[19:31:35] <mru> this is extra good
[19:31:47] <mru> it has felker _and_ kabi
[19:32:02] <mru> and alex as bonus troll
[19:45:54] <peloverde> "This isn't a case of the pot calling the kettle black, it's a case of the pot calling the kettle a chicken eating n***r and joining the KKK" a +14 comment on reddit about DS http://www.reddit.com/r/programming/comments/cp216/vp8_a_retrospective/c0u5z5b
[19:47:06] <mru> where is this mythical hardware that only supports baseline?
[19:47:46] <elenril> >implying D_S wrote the h.264 standard
[19:47:46] <Honoome> peloverde: well, didn't you know that reddit is the place where "rebels" who only rant about the status quo find peace?
[19:49:49] <Honoome> okay now can somebody tell me how is it possible that people feel like ccache helps them with building stuff that uses C++ like kdelibs when a) the object files are HUGE so the hashing/copying is a huge hit b) the longest step ever is the linking ?
[19:50:28] <mru> when did linking get so expensive?
[19:50:47] <peloverde> when people started using c++?
[19:50:56] <mru> 10 years ago, I always knew the wait was almost over when I saw the link command
[19:51:20] <mru> a 1-hour build would link in less than a minute
[19:51:25] <mru> and even that would be extreme
[19:51:33] <elenril> my laptop spends ages in iowait when trying to get enough free ram for linking
[19:51:39] <mru> elenril: get more ram
[19:51:43] <elenril> inb4 get more ram
[19:51:46] <elenril> lol
[19:51:55] <peloverde> When I only had 2GB ram I couldn't link chrome
[19:52:02] <Yuvi> now we have LTO so you can get C++ link times even with C
[19:52:19] <mru> does lto give you _anything_ else?
[19:52:30] <mru> apart from a few bonus bugs
[19:53:35] <Honoome> Yuvi: and what happens with C++ link time?
[19:53:37] <twice11> LTO should give you the performance advantage of inline functions without having to expose source code in header files.
[19:53:52] <Yuvi> not really for C unless you wrote it without caring about performance
[19:54:30] <Honoome> LTO basically is just a way to fix the conudrum of "extern inline functions" as far as I can tell
[19:54:33] <jai> i dunno about gcc's lto but firefox seemed to benefit a bit with ltcg turned on in VS
[19:55:07] <peloverde> Firefox is C++
[19:55:25] <jai> yeah
[19:55:41] <mru> Honoome: what conundrum?
[19:55:46] <Yuvi> Honoome: well, c++ has a number of other problems with inlining class functions and templating that LTO fixes, still makes link times astronomical
[19:55:58] <mru> it's a valid optimisation of course, but "extern inline" has no such meaning according to spec
[19:56:32] <Honoome> mru: in C++ it should have iirc
[19:56:54] <mru> how did the optimising linkers in all the old unixes manage btw?
[20:01:04] <hyc> there weren't a lot. aix is the only one I recall. maybe mips.
[20:01:38] <mru> I never looked into the details but many linkers have -O flags
[20:01:52] <Honoome> gnu ld has it as well
[20:01:55] <mru> I'm pretty sure I've seen it on sun
[20:01:55] <Honoome> but it does not perform LTO
[20:02:01] <mru> Honoome: only for compatibility with sun
[20:02:08] <Honoome> nope it does a couple of things
[20:02:23] <mru> the gnu linker accepts tons of sun flags and then ignores them
[20:02:40] <mru> almost everything gnu is closely modeled on sun
[20:03:03] <mru> not that there's anything bad about that
[20:03:24] <Honoome> too bad they stopped taking hints from Sun ELF extensions a bit of time ago
[20:03:43] <mru> NIH got the better of them
[20:03:44] <Honoome> I wouldn't have minded if GNU ld produced the padded .dynamic section that allows to _add_ RPATH
[20:04:04] <mru> without rewriting the entire file
[20:04:09] <Honoome> obviously
[20:04:18] <Honoome> anyway ld -O1 does changes a bit of the
[20:04:24] <Honoome> shared object generation
[20:05:56] <hyc> The MIPS linker actually made code changes, replacing larger offsets with smaller ones where possible, and relocating to compensate
[20:06:40] <mru> and the aix linker does some bizarre things
[20:06:52] <mru> because they designed such a twisted abi
[20:13:28] <peloverde> I need to get filtered Internet or something, I read reddit and get angry and lose motivation to actually work on FFmpeg
[20:13:51] <mru> how about simply not reading it?
[20:14:28] <Honoome> peloverde: not reading reddit is a perfectly valid solution
[20:16:30] <peloverde> easier said than done
[20:16:51] <Honoome> peloverde: it's like reading comments on bugs for me... I ask for broken documentation to be killed, I get the door slammed in my face (bug closed right away), I call the doc bullshit and I'm called the relations police at me, I reopen to public the bug and I'm the rude one
[20:25:37] * pJok turns off any http access for peloverde 
[20:27:39] <kierank> pJok: you are the master of the internets?
[20:27:53] <mru> isn't that al gore?
[20:29:41] <Honoome> kierank: he only has to be the sysadmin at peloverde's isp
[20:31:52] <BBB> peloverde: are you one of those who spends half day reading slashdot etc.? :-p
[20:32:21] <peloverde> somedays I do :(
[20:33:04] <BBB> seriously, you should stop doing it
[20:33:18] <mru> it rots your brain
[20:33:30] <BBB> after a year or so, so when you're beyond your initial "ohmygod I'm depressed because I cannot read slashdot-tards", you'll suddenly feel so much better
[20:33:48] <BBB> slashdot is like crack
[20:33:52] <BBB> you think you like it
[20:34:23] <mru> 10 years ago it was actually interesting at least some of the time
[20:34:45] <spaam> mru: so http://www.theregister.co.uk/ is bette? :P
[20:34:47] <spaam> better
[20:35:11] <peloverde> I don't even particularly like it but it's easy... far easier than chasing bugs through ffaacenc
[20:35:17] <mru> spaam: hardly comparable
[20:35:34] <mru> peloverde: bug debugging is more satisfying when you succeed
[20:35:46] <mru> there's no such thing as succeeding on /. or reddit
[20:35:53] <peloverde> So I go to gawk and at some point I feel involved
[20:35:54] <mru> unless you are a pure troll
[20:36:58] <elenril> mru: http://encyclopediadramatica.com/List_of_ways_to_win_at_the_internet
[20:37:05] <peloverde> What happened to required "-strict experimental" for aac, "./ffmpeg -i ../../exp/cdn.wav out.m4a" seems to work and it isn't generating ALAC
[20:37:46] <BBB> peloverde: faac?
[20:37:52] <kierank> mru: this guy won reddit http://www.reddit.com/r/entertainment/comments/cp190/the_old_spice_man_responds_to_the_internet/
[20:39:03] <saintdev> oh wow he posted on reddit also
[20:39:24] <pJok> mru, Obama is the master of the internet... he has the killswitch
[20:39:37] <peloverde> kierank: Do you see what you are doing to me?! ;)
[20:40:08] <peloverde> BBB, nope, I don't "--enable-nonfree"
[20:44:43] <Honoome> peloverde: I thought faac was only considered gpl, not nonfree?
[20:44:55] <peloverde> Honoome: You are thinking of faad
[20:45:09] <peloverde> faac cribs a bunch of ISO reference code
[20:45:19] <mru> considered gpl...
[20:45:34] <Honoome> which version? I know there was a faad version with an advertising clause that is gpl-incompatible
[20:45:40] <Honoome> but I don't remember specific trouble with faac beside patents
[20:45:44] <bcoudurier> peloverde, it doesn't work by codec_id
[20:46:04] <Honoome> mind you, before rms and the freetards made a fuss about gentoo we were pretty liberal for what concerns licenses
[20:46:32] <peloverde> Honoome: Its exactly the same as the old lame issue back in the day
[20:46:51] <mru> gentoo is still pretty liberal
[20:47:05] <Honoome> mru: less so than we used to be
[20:47:13] <Honoome> we're still "hiding" with the fact that we don't provide binaries ;)
[20:47:14] <bcoudurier> mru
[20:47:20] <mru> it lets me link whatever the hell I want against curl, even if curl is linked against openssl, for instance
[20:47:24] <bcoudurier> I found a patch somewhere that use attribute hidden
[20:47:30] <bcoudurier> for some symbols like ff_pb*
[20:47:51] <bcoudurier> that makes compilation work with PIC when compiling statically in a shared library
[20:47:58] <bcoudurier> what's wrong with this approach ?
[20:48:31] <mru> I see no relation between symbol hiding and pic
[20:48:49] <peloverde> If i use out.webm it tries to use ffvorbis
[20:48:59] <bcoudurier> linker says it cannot relocate ff_pb*
[20:49:15] <mru> yes, that won't go away by hiding it
[20:49:18] <bcoudurier> it does
[20:49:22] <mru> weird
[20:49:28] <mru> are you using -Bsymbolic as you should?
[20:49:31] <bcoudurier> I use __attribute__(hidden)
[20:49:39] <bcoudurier> default configure flags
[20:49:43] <bcoudurier> just --enable-pic
[20:49:46] <bcoudurier> for x86_64
[20:49:52] <mru> well, does it use -Bsymbolic?
[20:50:04] <bcoudurier> yes
[20:50:08] <Honoome> mru: -Bsymbolic still allows the symbol to be exported
[20:50:18] <Honoome> hidden visibility avoids exporting it
[20:50:24] <mru> yes, but internal references are bound directly to the local one
[20:50:32] <mru> tey can't be interposed
[20:50:42] <Honoome> true but I guess here the linker is dying because of the exported copy not the local one
[20:50:55] <mru> that's weird
[20:51:01] <Honoome> seen weirder
[20:51:06] <mru> exporting a symbol doesn't create relocations
[20:51:32] <bcoudurier> it's when creating a shared library from libavcodec.a
[20:51:40] <bcoudurier> more specifically a python c binding
[20:51:51] <bcoudurier> on x86_64
[20:51:55] <mru> does --enable-shared work?
[20:51:57] <Honoome> bcoudurier: are you using -Bsymbolic when linking the binding?
[20:52:12] <bcoudurier> ah not when linking the binding, no
[20:52:13] <mru> -Bsymbolic has no effect on the .a
[20:52:23] * Honoome hands mru the harisen
[20:52:31] * Vitor1001 is in a soc-student answering frenzy ;)
[20:52:57] <bcoudurier> if we require so, maybe we should put that in the FAQ
[20:53:10] <bcoudurier> I just added hidden to the ff_pb*
[20:53:27] <Honoome> to be honest I wouldn't mind if we started hiding symbols :P
[20:53:33] <mru> I had no idea we required anything like that
[20:53:41] <mru> and we do hide loads of symbols
[20:54:00] <Honoome> yeah?
[20:54:07] <mru> the version scripts do that
[20:54:16] <mru> building a shared lib from a .a isn't really supported
[20:54:19] <mru> by us
[20:54:26] <mru> too many caveats
[20:54:27] <Honoome> mru: that only hides them at .so time :P
[20:54:34] <bcoudurier> that very useful though
[20:54:39] <mru> Honoome: of course
[20:54:41] <bcoudurier> at least for bindings
[20:54:44] <mru> you can't hide them in the .o files
[20:54:47] <mru> nothing would work then
[20:55:02] <Honoome> mru: you can mark them hidden in the .o files
[20:55:16] <mru> yeah, I suppose
[20:55:20] <Honoome> that way when producing another .so from them (without the version script) they won't be exported
[20:55:29] <mru> but every patch anyone posted to do that was full of hack
[20:55:31] <Honoome> and bcoudurier's use case would work out of the box
[20:55:33] <Honoome> yes I know
[20:55:35] * Honoome posted one
[20:55:46] <mru> I know you did
[20:55:52] <mru> and it wasn't pretty
[20:56:20] <Honoome> bcoudurier: I'm not sure how useful it is for bindings tbh... distros would probably dislilke that :P
[20:56:40] <bcoudurier> well I'm talking about distros
[20:56:45] <bcoudurier> I'm talking about tools I deploy
[20:56:58] <mru> linking the the .so makes more sense to me
[20:57:04] <mru> *linking to
[20:57:10] <bcoudurier> and usually when it's static I have way less problems
[20:57:34] <bcoudurier> I'm not _talking_ about distros, sorry
[20:57:38] <mru> rpath tricks not good enough?
[20:58:40] <bcoudurier> dunno, I've never used that
[20:59:26] <bcoudurier> also compiling static permits to not upgrade existing tools
[20:59:44] <bcoudurier> meaning no weird problems because of upgrade
[21:00:02] <bcoudurier> but that would also be fixed by rpath I guess
[21:13:19] <peloverde> What are people's thoughts on mono bitrates?
[21:14:19] <mru> never really thought about them
[21:15:14] <peloverde> maybe someday I'll understand this obsession with stereo
[21:15:17] <peloverde> :)
[21:35:32] <Kovensky> I remember when I was trying to stuff 1h of music in under 25mb with lame
[21:36:00] <Kovensky> downmixing to mono was the single largest quality drop, even if I kept the same bitrate as the stereo encode
[21:36:51] <mru> sounds odd
[21:36:57] <Kovensky> I prefered to lower the bitrate and raise the lowpass a little bit (thus getting more artifacts, but somewhat more surviving detail)
[21:37:07] <mru> stereo to mono downmix shouldn't lose _that_ much quality
[21:37:38] <Kovensky> http://money.cnn.com/2010/07/13/technology/windows_xp/index.htm?source=cnn_bin&hpt=Sbin
[21:37:44] <Kovensky> link not related, but lol
[21:38:11] <Kovensky> mru: probably the downmixing algo sucked, lame just does averaging
[21:38:23] <mru> is there another way?
[21:38:46] <Kovensky> I may just be making up stuff (I suck at math), but maybe biasing towards the extremes would help
[21:38:59] <mru> what does that mean?
[21:39:21] <Kovensky> averaging is very noticeable when there are stereo effects like guitar switching from left to right or vice-versa, or when there's enough stereo separation in the original
[21:39:37] <mru> you lose the separation of course
[21:39:42] <mru> but that's expected
[21:39:44] <Kovensky> the "further" the sound is from the average, the more it dies down
[21:41:02] <mru> how else would you do it
[21:41:14] <mru> imagine placing your two speakers side by side
[21:41:32] <mru> so they effectively become a single source as far as your perception is concerned
[21:42:14] <mru> either one at max amplitude will obviously be only half as strong as both at max at the same time
[21:42:29] <Kovensky> I just wonder if adding a bias towards "extremes" would help
[21:42:39] <Kovensky> I never actually looked into psychoacoustics (but I'd like to)
[21:42:42] <mru> I'd be more worried about the sided cancelling out
[21:43:01] <mru> if you have the same frequency with opposite phase on either channel
[21:43:22] <mru> in a stereo setup you'd still hear something
[21:43:33] <mru> depending on your listening position
[21:44:29] <Kovensky> yeah
[21:45:18] <mru> maybe some kind of frequency-domain averaging would work better
[21:45:48] * Kovensky should study DSP
[21:46:06] <Kovensky> I find it a really interesting subject but I never find time / good sources =p
[22:09:43] <peloverde> I love one I see a bug and it turns out to be at least to or three actual bugs
[22:23:11] <Compn> i think its more fun when you find a bug and do a quick one-line hack but then its rejected because you have to refactor a ton of code to make ti all right :P
[22:25:40] <mru> even better is when you have a small, clean patch fixing the problem, but fails to fix an unrelated problem someone remembers when seeing the context of the diff
[22:26:34] <Compn> oh those are fun
[22:26:51] <Compn> what about 'oh i've had that in my tree for a year, i should have committed it...' replies?
[22:27:06] <peloverde> http://firefogg.org/ Fixed
[22:31:26] <mru> Compn: at least those get it fixed
[22:35:03] <peloverde> What do people think about a "powered by FFmpeg" logo? would that be too 1990s?
[22:37:45] <mru> I have a better idea
[22:38:01] <mru> sell licences to display the ffmpeg logo
[22:38:13] <mru> like dolby etc
[22:38:38] <peloverde> Who would we sell them too? The FFmpeg hosting people>
[22:38:54] <mru> anyone who'll buy
[22:38:56] <kierank> why would anyone buy one?
[22:39:06] <saintdev> google
[22:39:10] <mru> if we sue them if they display it without paying...
[22:39:19] <saintdev> oh wait they "don't use ffmpeg" ;)
[22:39:28] <hyc> how much do the logos have to sell for to cover the cost of a laywer?
[22:39:38] <Dark_Shikari> hyc: lol
[22:39:52] <peloverde> I would rather not get into Mozilla style trademark trolling
[22:39:58] <Dark_Shikari> +1
[22:40:28] <mru> my favourite is the debian logo
[22:40:29] <hyc> and registering a trademark costs money and lawyer time already
[22:40:46] <mru> some troll used a standard brush applied to a default spiral in adobe illustrator or similar
[22:41:02] <mru> and now they throw a hissy fit whenever someone else uses the same default settings
[22:41:54] <saintdev> don't steal their magic smoke
[22:42:02] <hyc> if they actually paid to register a mark then they're obligated to object whenever anything similar comes along. otherwise the registration is invalidated
[22:43:44] <peloverde> You can still have a broadly license a trademark and protect it against specific abuses
[22:45:07] <peloverde> Intent is a big part of the law even though programmers are uncomfortable with it
[22:45:10] <hyc> either way, you have to demonstrate that you were proactive in all cases. You have to show that you negotiated a license, or that you pursued an infringer.
[22:45:28] <hyc> if you can be shown to be negligent, your mark can be ruled to be abandoned.
[22:45:49] <peloverde> no you don't, you can lay out guidelines for use and only go after people that break those guidelines
[22:46:04] <peloverde> you don't need to negotiate individual licenses with each user
[22:47:15] <hyc> hmmm. I suppose. But in general, licenses require mutual agreement to be enforceable.
[22:48:09] <michaedw1> the best part of the debian smoke is that it's an "homage" to Buzz Lightyear's chin spiral
[22:48:31] <mru> hyc: yes, but trademarks are protected without a contract
[22:48:34] <mru> just like copyright
[22:48:52] <Dark_Shikari> michaedw1: lol
[22:49:04] <saintdev> michaedw1: lol
[22:49:14] <michaedw1> just like copyright, a trademark is a legislatively created basis for a tort claim
[22:49:44] <mru> most trademarks are only granted in a narrow field though
[22:49:55] <hyc> yes
[22:49:59] <mru> so that linux washing powder doesn't infringe
[22:50:20] <hyc> but registration means you're getting exclusive use. in order to allow anyone else to use it, you have to explicitly licens to them.
[22:50:46] <mru> if they fall within the same field
[22:50:47] <michaedw1> not exactly.  depends on what sort of "use" they're making of it.
[22:51:20] <hyc> And then there's perfectly non-infringing stuff, which you can still make a fuss over. Like DEC over "Nothing sucks like a Vax."
[22:51:25] <mru> if your trademark registration only covers computer programs, I can sell furniture under the same name without bother
[22:51:36] <michaedw1> they can use it in "better than Brand X" comparisons too
[22:52:00] <michaedw1> they just can't apply it to their own products
[22:52:37] <mru> yes, using a trademark to refer to the thing it was registered for is ok
[22:52:52] <michaedw1> or imply that they are affiliated with it, or otherwise try to make use of the goodwill associated with it
[22:53:07] <michaedw1> including with their own "confusingly similar" mark
[22:54:45] <michaedw1> the trademark registration procedure, like the patent application procedure, exists largely to establish a standardized set of factoids that will be useful in the event of litigation
[22:55:38] <michaedw1> you don't really find out how broad the scope of your trademark is until you try to sue someone for misappropriating it
[23:14:10] <kierank> i love it when there's a massive chunk of code that doesn't seem to be ever used and i don't have to reverse engineer it
[23:18:03] <Honoome> kierank: only if you were to reverse it you'd find it's actually the answer to life, the universe and everything
[23:19:03] <Honoome> (nop isn't 0x42 in x86, is it?)
[23:19:14] <Honoome> 0x90 maybe?
[23:22:07] <Dark_Shikari> 0x90 yes
[23:23:09] <lu_zero> yawn
[23:23:35] <Honoome> lu_zero: since for one rare occasion we _are_ debugging ffmpeg :P
[23:23:43] <lu_zero> eh..
[23:23:52] <Honoome> well, you are, I'm playing MI2 :P
[23:24:05] <lu_zero> mi2?
[23:24:21] <Honoome> monkey island 2
[23:24:38] <lu_zero> Honoome: tell me how to make gdb watch a field a struct across different function calls
[23:24:51] <Honoome> trying to get the "less than three hours completion" trophy
[23:25:10] <Honoome> lu_zero: I could suggest you voodoo programming to stay on topic :P
[23:25:55] <Honoome> although I guess 3dfx failing cut that option out
[23:26:41] <Honoome> lu_zero: watchpoints should refer to memory areas iirc
[23:27:22] <Honoome> maybe mru has a better idea
[23:27:33] <mru> use printf
[23:28:03] <hyc> just print &struct->field and then watch the address
[23:28:24] <mru> watchpoints rarely work the way you hope
[23:28:42] <hyc> heh. use them enough times and you get used to how they actually work.
[23:29:06] <mru> I know how they work
[23:29:13] <mru> it's just rarely useful
[23:29:35] <mru> maybe if your code is sloppy they can be useful
[23:29:47] <mru> if you really have no clue what is writing where
[23:30:30] <hyc> or if you're chasing an overrun caused by some library that you didn't write...
[23:30:38] <mru> valgrind
[23:31:08] <peloverde> valgrind is king
[23:31:46] <hyc> valgrind is nice, but it still requires you to know something about your code.
[23:31:52] <lu_zero> I'm pretty much puzzled
[23:32:02] <bcoudurier> valgrind ownz
[23:32:17] <mru> if you don't know anything about your code, you're doing something very wrong
[23:32:20] <Honoome> lu_zero: no I am
[23:32:20] <lu_zero> since I don't know where and when the avcontext->start_time gets garbled
[23:32:44] <hyc> and valgrind won't help you find overruns that don't cause immediate SEGVs
[23:32:58] <bcoudurier> it does here ?
[23:33:02] <Honoome> hyc: uh yes it would
[23:33:07] <Honoome> it lists all invalid memory accesses
[23:33:08] <hyc> a watchpoint is still better for that
[23:33:21] <hyc> Honoome: nobody said the access had to be invalid.
[23:33:54] <hyc> overrunning a couple of packed fields in a struct
[23:34:04] <hyc> or a large array offset that lands in another valid memory region
[23:34:07] <peloverde> valgrind will find illegal and uninitialized reads before the SEGV
[23:34:32] <mru> valgrind pads allocations enough that most overruns are caught
[23:35:01] <mru> if something writes to a totally random address that happens to be in a valid block, it won't notice of course
[23:35:03] <lu_zero> so
[23:35:03] <Honoome> hyc: if it's a large offset it'll be caught, the structure I'm not sure
[23:35:07] <lu_zero> it starts 0
[23:35:35] <lu_zero> av_open_input_stream sets it to AV_NOPTS_VALUE
[23:35:52] <mru> printf the value in a bunch of places where you think you know what it should be
[23:35:59] <mru> or at least can tell if it's bad
[23:36:02] <lu_zero> sdp_parse sets it back to 0
[23:36:06] <bcoudurier> demuxer or in av_find_stream_info
[23:36:15] <mru> then binary search
[23:36:24] <lu_zero> av_update_stream_timings botches it
[23:37:09] <mru> looks like you already know the answer then
[23:37:20] <lu_zero> now the question is _why_ it does that?
[23:37:31] <mru> I'm afraid no debugger can tell you that
[23:37:39] <mru> you'll have to read the code and understand it
[23:37:46] <mru> scary, I know
[23:38:43] <lu_zero> mru: what's scary is that I'm afraid to know
[23:38:55] <lu_zero> since makes _no_ sense
[23:39:08] <Honoome> you wrote the code by chance?
[23:39:19] <lu_zero> you cannot set to negative a stream that starts at 0
[23:39:26] <lu_zero> and you know that
[23:39:44] * Honoome knows eah
[23:39:50] <bcoudurier> what's the status of faad btw ?
[23:39:52] <lu_zero> Honoome: if the rtsp.c code is at fault maybe
[23:40:01] <bcoudurier> removed, right ?
[23:40:05] <mru> yes
[23:40:13] <bcoudurier> thanks
[23:40:37] <Honoome> lu_zero: not from feng side though, right?
[23:42:47] <Honoome> if I do finish mi2 in less than half an hour I'll take a look if you can cut down the area
[23:44:03] <lu_zero> the strange assumption is in ffmpeg apparently
[23:47:39] <Honoome> which function?
[23:47:51] * Honoome just finished mi2
[23:49:15] <lu_zero> av_update_stream_timings
[23:50:42] <Honoome> lu_zero: quick way for me to reproduce?
[23:51:34] <lu_zero> open demuxer_avf.c in feng
[23:51:51] <lu_zero> feed av_open_input_file with an rtsp url
[23:52:16] <lu_zero> e.g. rtsp://media.lscube.org/tests/tc.mov?tcp
[23:52:42] <Honoome> you mean you don't know why it appears to be -1 when you try to seek to -1?
[23:53:12] <lu_zero> no
[23:53:35] <lu_zero> s->start_time gets overwrote
[23:53:39] <lu_zero> hi j0sh
[23:53:44] <lu_zero> so from a proper 0
[23:53:54] <lu_zero> as parsed by sdp_parse
[23:53:57] <lu_zero> you get garbage
[23:54:16] <Honoome> may I ask you for a favour then? :P
[23:54:18] <lu_zero> and I'm wondering what ffmpeg/ffplay does to prevent that
[23:54:40] <Honoome> testcase it down to simple calls...
[23:55:16] <lu_zero> Honoome: quite feasible
[23:56:57] <lu_zero> avformat_alloc_context + av_open_input_file + av_find_stream_info
[23:57:00] <lu_zero> that's all
[23:57:34] <Honoome> write a .c file, will ya?