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

[irc at mansr.com]

[00:00:06] <kierank> virtualbox can run x86_64
[00:01:36] <BBB> Yuvi: the ppc vp8 tests also fail, could this be a bug in your ppc code?
[00:01:54] <Dark_Shikari> Could it be a bug in your deblock chroma change?
[00:02:01] <BBB> Dark_Shikari: ok, patch is reverted, I'll see what I can do tonight
[00:02:19] <BBB> no
[00:02:25] <BBB> the ppc has been broken for quite a while
[00:02:32] <BBB> as long as the history goes, at least
[00:02:37] <j0sh> BBB:email sent
[00:02:41] <BBB> and it's specific for gcc-4.0.4 also, the rest works fine (??)
[00:02:49] <CIA-99> ffmpeg: rbultje * r24341 /trunk/libavcodec/x86/ (vp8dsp.asm vp8dsp-init.c):
[00:02:49] <CIA-99> ffmpeg: Revert r24339 (it causes fate failures on x86-64) - I'll figure out what's
[00:02:49] <CIA-99> ffmpeg: wrong with it tomorrow or so, then re-submit.
[00:02:55] <BBB> http://fate.multimedia.cx/index.php?history=build&config_id=9
[00:03:30] <BBB> j0sh: can you install yasm?
[00:03:41] <BBB> that's all I should need
[00:03:54] <j0sh> sure
[00:04:03] <BBB> thanks
[00:04:07] <bcoudurier> hi guys
[00:04:18] <j0sh> done
[00:11:25] <BBB> j0sh: did you install gcc, etc?
[00:11:30] <BBB> maybe libc-dev
[00:11:35] <BBB> something basic is missing
[00:11:41] <j0sh> doh, yes
[00:11:44] <j0sh> build-essentials
[00:12:06] <j0sh> installing now
[00:12:07] <Honoome> aaah these binary distributions
[00:12:13] <j0sh> btw
[00:12:23] <Honoome> I challenge you to forget the compiler on gentoo ;P
[00:12:25] <j0sh> i have no idea what the hardware specs on this are
[00:12:40] <j0sh> i dont know if sse3, etc will work if you need that
[00:13:11] <BBB> no, sse2 is enough
[00:13:43] <BBB> can you download http://code.google.com/p/webm/downloads/detail?name=vp8-test-vectors-r1.zip&can=2&q= and put it in my home dir?
[00:13:49] <BBB> maybe wget is installed
[00:14:08] <j0sh> it should be
[00:14:37] <BBB> ok, got it
[00:15:05] <j0sh> also installed git/subversion if you need to work directly from trunk
[00:15:10] <BBB> thanks
[00:16:37] <BBB> at least fate is greener again
[00:23:33] <j0sh> 4 core xeons
[00:23:39] <j0sh> /proc/cpuinfo ftw
[00:24:31] <j0sh> apparently has sse4 if anybody wants to play wit that...
[01:10:51] <lu_zero> aEHM
[01:11:05] <lu_zero> I did test it.
[01:41:01] <Honoome> okay I'll qualify my earlier statement: give lu_zero a step-by-step guide while asking him to test something ;) this includes running "make fate"
[05:24:18] <CIA-99> ffmpeg: mstorsjo * r24342 /trunk/libavformat/movenc.c:
[05:24:19] <CIA-99> ffmpeg: movenc: Free the buffer returned by url_close_dyn_buffer, regardless of the size
[05:24:19] <CIA-99> ffmpeg: This fixes a leak introduced in rev 23942, since we write padding to the
[05:24:19] <CIA-99> ffmpeg: buffer unconditionally.
[05:27:10] <av500> gm CIA-99
[05:27:52] * kshishkov thinks something is wrong with av500
[05:28:37] <thresh> moroning
[05:28:43] * thresh yaawns
[05:29:17] <kshishkov> thresh, mornings are usually better is you move far from exUSSR
[05:31:02] <av500> kshishkov: a quick steam train ride brefore going to the office today? :)
[05:31:06] <thresh> kshishkov: got any tips?
[05:31:28] <thresh> to 'намаслить лыжи'
[05:31:45] <kshishkov> thresh: Turks recommend Switzerland
[05:32:05] <kshishkov> av500: I've not earned enough to buy one, sorry
[05:32:31] <funman> you'd better be rich to enter or even approach Switzerland
[05:32:47] <kshishkov> thresh: also depends on man - some feel good at USA, some prefer Germany, some like Sweden
[05:33:07] <kshishkov> funman: hah, even I've been there
[05:33:24] <funman> you lived there?
[05:34:41] <funman> life (and especially housing) is very expensive
[05:35:02] <thresh> kshishkov: How did you find your employer?
[05:35:02] <funman> ok with Swiss salary though
[05:35:28] <av500> funman: of course you live in germany and work in .CH :)
[05:35:31] <thresh> housing becomes really expensive in Moscow now as well:-(
[05:36:03] <funman> av500: yeah i know this but from the other side of switzerland (my bro lives in france close to geneva)
[05:36:20] <kshishkov> funman: I just went there for a day
[05:36:27] <funman> av500: i bet housing near switzerland is expensive as well?
[05:36:36] <av500> no idea
[05:36:56] <kshishkov> thresh: I'm lazy, it's always employers finding me. When I tried to look for job I was always unsuccessful
[05:37:14] <thresh> kshishkov: suppose I need to learn something useful first ;-)
[05:37:22] <kshishkov> German houses are cheap - as in Ukraine
[05:37:45] <av500> kshishkov: damn, they must be hiding here somewhere
[05:38:07] <kshishkov> thresh: depends on your definition of "useful" - maybe it's enough to let certain people know you can do something
[05:38:33] <funman> hmm freenode has #jobs for jobs opportunities. so bad there's only me and chanserv
[05:38:55] <thresh> maybe Chanserv is hiring.
[05:39:04] <funman> thresh: perhaps start by putting your CV online
[05:39:11] <av500> and make a blog
[05:39:16] <kshishkov> av500: nope, you just don't know prices for real estate in .ua
[05:39:43] * funman read that as .lua
[05:41:01] <thresh> I probably need to translate my CV into more used language, right
[05:50:23] <kshishkov> thresh: from Russian to Moscowian?
[05:52:51] <thresh> kshishkov: I don't have enough practice to speak Moscowian. That, and no Cayennes, Prada or Tissots...
[05:53:27] <funman> there's a reason you use 'free' software, no ?
[05:54:25] <kshishkov> nope
[05:54:27] <Dark_Shikari> cheapskate!
[05:54:41] <kshishkov> all software had the same price in Russia
[05:55:00] <thresh> 2 EUR per CD now, or something like that
[06:11:46] <josh> wbs: how do i disable auth requirements for DSS?
[06:12:29] <josh> i keep getting 401's, no matter how many times i try to re-set the username/pw or disable authentication
[06:17:09] <josh> (for broadcasting)
[06:18:39] <wbs> josh: don't know if you can disable it altogether, but if the server is on localhost, you shouldn't need any password
[06:19:02] <josh> just username then?
[06:19:18] <wbs> no username either
[06:19:48] <wbs> but it sounds weird if you aren't able to use the broadcast password properly
[06:19:50] <josh> still getting 401s
[06:20:21] <josh> yeah
[06:20:30] <wbs> streaming to rtsp://localhost/foobar.sdp using ffmpeg?
[06:20:38] <wbs> or rtsp://username:password@server/foobar.sdp?
[06:20:43] <benoit-> good morning
[06:21:24] <josh> former
[06:21:27] <josh> well, neither work
[06:21:51] <josh> i'm gonna tool around in the darwin config file for a bit
[06:22:29] <wbs> and you set the broadcast password via the admin ui, at http://server:1220, unser general, movie broadcast password?
[06:22:40] <josh> yeah
[06:22:44] <josh> every time i do that
[06:22:49] <josh> and go back
[06:23:03] <josh> it seems to be reset
[06:23:15] <josh> to the admin username
[06:23:28] <wbs> hmmm, sounds like there's some issue with updating some of the files?
[06:25:27] <josh> probably
[06:40:43] <mru> morning
[06:41:12] * Dark_Shikari reminds mru to do a little bit of hunting today
[06:41:27] * mru loads shotgun
[06:43:36] <mru> someone was looking for me earlier
[06:43:47] <mru> Honoome: ^^
[08:15:15] * pJok unleashes his snapdragon power on mru 
[08:16:39] * kshishkov still waits for ARM-based server
[08:17:04] <pJok> aren't there ARM based servers out there...?
[08:17:24] <mru> toy "nas" boxes don't count
[08:17:27] <kshishkov> proper ARM-based servers, with 2GHz multicore CPUs
[08:17:44] <KotH> filling whole rooms with hardware?
[08:18:36] <pJok> kshishkov, doesn't that really require A9 to be out first?
[08:18:44] <kshishkov> nope
[08:18:47] <mru> a9 _is_ out
[08:18:57] <pJok> mru, i know... but i recall having seen a server board out there somewhere with ARM
[08:19:12] <pJok> and out as in widely used...
[08:19:27] <mru> many boards have arm cores in the chipsets
[08:20:18] <lu_zero> as ppcs and mipses
[08:21:14] <pJok> it just lurks inside my brain
[08:21:24] <superdump> how long has the A9 been out? how come there are still so many new products being released that still use A8?
[08:21:25] <pJok> if i suddenly remember where i saw it, i will spam you with it, mru
[08:21:26] <pJok> ;)
[08:21:47] <superdump> just product development time?
[08:21:51] <pJok> superdump, its the apple factor!
[08:21:52] <kshishkov> superdump: different goals
[08:21:58] <mru> superdump: A8 is plenty enough for many applications
[08:22:06] <mru> and probably a lot cheaper
[08:22:15] <mru> there are still arm7 devices being made
[08:22:38] <mru> and development time is a factor too
[08:23:00] <Dark_Shikari> there are still arm5 devices being made
[08:23:07] <mru> Dark_Shikari: no
[08:23:16] <mru> armv5, not arm5
[08:23:40] <mru> arm7 is the oldest anyone still uses
[08:23:52] <mru> some of them are armv4 actually
[08:24:29] <Dark_Shikari> does armv7 mostly map to arm7?
[08:24:31] * kshishkov dislikes that numbering scheme
[08:24:35] <mru> Dark_Shikari: oh no
[08:24:42] <pJok> arm numbering scheme is cryptic at best
[08:24:43] <mru> the vX are architecture versions
[08:24:54] <mru> v4-v7 are currently available
[08:25:04] <pJok> no worse than intels though...
[08:25:12] <Dark_Shikari> er
[08:25:12] <Dark_Shikari> I meant
[08:25:13] <Dark_Shikari> armv4
[08:25:14] <Dark_Shikari> map to arm7
[08:25:18] <Dark_Shikari> sorry, typo
[08:25:29] <mru> arm7 can be v4 or v5
[08:25:34] <mru> there are a few of both
[08:25:41] <mru> same for arm9
[08:25:48] * pJok remembers his nokia 8210 having ARM7TDMI
[08:25:48] <wbs> Dark_Shikari: http://en.wikipedia.org/wiki/ARM_architecture gives quite a good overview (I think)
[08:25:49] <mru> arm11 is always v6
[08:25:57] <Dark_Shikari> is v7 arm13?
[08:26:02] <mru> there is no arm13
[08:26:06] <Dark_Shikari> then what's v7?
[08:26:06] <mru> or 12
[08:26:11] <mru> v7 is cortex
[08:26:15] <Dark_Shikari> they stopped the numbers?
[08:26:15] <mru> and snapdragon
[08:26:22] <Dark_Shikari> Why are there no even numbers?
[08:26:25] <Dark_Shikari> arm11, arm9, arm7...
[08:26:29] <mru> there's 10
[08:26:35] <mru> they're rare though
[08:27:00] <mru> maybe they stopped the numbers because they were confusing
[08:27:28] <iive> names are even more confusing...
[08:27:35] <av500> nothing is as confusing as intel naming
[08:27:49] <mru> that's a given
[08:27:49] <av500> this I7 is has 2 cores? 4 cores? 6 cores?
[08:28:06] <Dark_Shikari> the intel naming makes sense, it's what they do with them that ends up being stupid
[08:28:10] <Dark_Shikari> i3, i5, i7: makes sense, low to high end.
[08:28:15] <Dark_Shikari> Then they start releasing 2 core i7s.
[08:28:16] <Dark_Shikari> What?
[08:28:18] <av500> i just need a 6core, to have all 3.... :)
[08:28:25] <av500> Dark_Shikari: you, in my laptop
[08:28:27] <av500> yup
[08:28:30] <mru> Dark_Shikari: the official names are fine
[08:28:40] <mru> it's the boggleston and whatnot I can't get a grip on
[08:28:43] <pJok> remember, its iX YYY for the intel naming scheme
[08:28:52] <Dark_Shikari> mru: oh, you mean codenames
[08:28:54] <Dark_Shikari> those aren't official names
[08:29:01] <Dark_Shikari> I _prefer_ the codenames
[08:29:02] <mru> but everybody uses them
[08:29:04] <Dark_Shikari> because they're more accurate
[08:29:08] <Dark_Shikari> "i3 i5 i7" says nothing
[08:29:12] <Dark_Shikari> "nehalem" is the name of the architecture
[08:29:15] <pJok> about as informing as nVidias and ATi's naming schemes for their XXXXGT, GTS, GTX model name schemes...
[08:29:17] <Dark_Shikari> it covers _everything_ in that category.
[08:29:18] <mru> i7 940 says something
[08:29:25] <Dark_Shikari> "nehalem" is like "arm11"
[08:29:31] <mru> Dark_Shikari: I know that
[08:29:33] <av500> i7 used to saw "awesome quadcore"
[08:29:41] <av500> not it can be lame laptop core
[08:29:41] <mru> there's just no way to compare them
[08:29:43] <av500> now
[08:29:53] <mru> arm11 is obviously better than arm9
[08:30:01] <mru> and arm1136 is similar to arm1176
[08:30:03] <mru> etc
[08:30:11] <mru> all cortex-a are similar
[08:30:15] <av500> mru: is apple A4 better than A8? :)
[08:30:22] <Dark_Shikari> mru: with intel it's basically the same concept
[08:30:28] <Dark_Shikari> take, for example, since the p4 days
[08:30:33] <Dark_Shikari> original p4: williamette (shiiiiiit)
[08:30:40] <Dark_Shikari> upgraded p4: northwood (less shit)
[08:30:46] <mru> but they're not in alphabetical order or anything
[08:30:57] <Dark_Shikari> crazy-long-stupid-pipeline-p4-that-used-200-watts: Prescott
[08:30:59] <mru> just looking at the names it's impossible to tell what's what
[08:31:14] <Dark_Shikari> Pentium M that sat around beating the crap out of the p4 while Intel hid in shame: dothan
[08:31:16] <mru> prescott is a UK politician so it makes sense that it's shit
[08:31:33] <Dark_Shikari> original Core 2: conroe
[08:31:36] <Dark_Shikari> 45nm core 2 shrink: penryn
[08:31:40] * av500 waits for the Intel Torchwood cpu
[08:31:46] <Dark_Shikari> the latest awesome: nehalem.
[08:31:52] <mru> av500: is that better than a Gotham?
[08:31:57] <pJok> av500, Apple A4 is an A8 ;)
[08:32:03] <av500> pJok: orly?
[08:32:06] <Dark_Shikari> so that's basically 7 arches in the past decade
[08:32:09] <kshishkov> mru: UK has politicians?
[08:32:14] <Dark_Shikari> I ignored core 1, but core 1 was really just a rebranding of the dothan.
[08:32:17] <pJok> av500, but its apple... so half should do just fine...
[08:32:24] <mru> pJok: a4 is soc
[08:32:39] <pJok> mru, i know
[08:32:49] <kshishkov> av500: "torchwood" sounds more like AMD CPU
[08:32:59] <Dark_Shikari> torchwood sounds more like a diablo 2 clone
[08:33:05] <av500> kshishkov: right, I had a few athlons torch themselves
[08:33:09] <Dark_Shikari> Or a primetime TV show
[08:33:16] <av500> Dark_Shikari: :)
[08:33:20] <pJok> Dr. Who spin-off
[08:33:25] <mru> av500: that's the Hogroast chip
[08:34:02] <av500> that was the "dont touch the cpu with a heatsink, silicon edges will splinter off" aera...
[08:35:00] * pJok should fry up his breakfast on a cpu
[08:35:06] <Dark_Shikari> hmm,  mru, intel could pull an ubuntu
[08:35:09] <Dark_Shikari> make the names in alphabetical order
[08:35:14] <Dark_Shikari> that'd run out after 26 arches
[08:35:17] <Dark_Shikari> but it'd work for a while
[08:35:27] <Dark_Shikari> They could name them after fruits.
[08:35:28] <Dark_Shikari> Appleton
[08:35:28] <pJok> should be plenty of presscott processors laying around for that
[08:35:31] <Dark_Shikari> Bananable
[08:35:42] <Dark_Shikari> Cherryroast
[08:36:10] <mru> Dark_Shikari: do you see what I mean?
[08:36:19] <mru> there's no relation _at all_ between the names
[08:36:33] <pJok> Donut, Eclair, Froyo, Gingerbread?
[08:36:35] <mru> short of memorising all of them there's no way to even guess
[08:36:41] <Dark_Shikari> mru: like git hashes
[08:36:47] <Dark_Shikari> well, except you can at least memorize intel's names.
[08:36:48] <mru> Dark_Shikari: :-)
[08:37:05] <av500> i486, i586, i686, i786, i886, i986..... where are we now?
[08:37:10] <Dark_Shikari> lol
[08:37:15] <astrange> you just start over when you reach Z
[08:37:26] <Dark_Shikari> Well, honestly, I think it's easier to memorize 150 pokemon by name than by number.
[08:37:30] <kshishkov> av500: wrapped around and went to i3, i5, i7
[08:37:38] <Dark_Shikari> Which brings me to my next point... CPUs are like pokemon.
[08:37:54] <mru> x86 is a monster, yes
[08:37:55] <Dark_Shikari> Williamette evolved into Northwood!
[08:38:31] <Dark_Shikari> Pentium 4 is trying to learn "SSE3".  But Pentium 4 can only learn 4 abillities.  Which ability would you like to replace to learn "SSE3"?
[08:38:39] <Dark_Shikari> >Sane-length pipeline
[08:38:44] <Dark_Shikari> Pentium 4 has learned "SSE3!"
[08:38:51] <Dark_Shikari> And Pentium 4 has forgotten "sane-length pipeline"!
[08:39:16] * mru has no clue about pokemon
[08:39:28] * mru wishes to keep it that way
[08:39:53] <kshishkov> mru: that's misterious thing mentioned in XKCD along with Ubuntu
[08:39:56] <ubitux> Dark_Shikari: there are more than 493 pokémons atm
[08:39:58] <ubitux> :(
[08:40:01] * av500 wishes elenril would drown Dark_Shikari in tropes
[08:40:03] <Dark_Shikari> ubitux: the ones after the first 150 don't exist.
[08:40:11] <ubitux> :D
[08:40:22] <mru> Dark_Shikari: grow up
[08:40:26] <kshishkov> Dark_Shikari: too much information
[08:40:28] <Dark_Shikari> mru: That would be horribly lame.
[08:40:40] <Dark_Shikari> "growing up" is an excuse made by boring people for not having fun.
[08:41:05] <mru> well, that's true too
[08:43:07] <lu_zero> Dark_Shikari: evolve!
[08:44:11] <kshishkov> lu_zero: he's not Zerg, you know
[08:44:19] <lu_zero> kshishkov: you sure?
[08:44:29] <Dark_Shikari> EVOLUTION COMPLETE
[08:44:35] <lu_zero> oh...
[08:44:45] <kshishkov> lu_zero: not very much. Do Zergs play Touhou games?
[08:44:58] <Dark_Shikari> kshishkov: well, the fairies seem to be like the zerg
[08:44:59] <lu_zero> kshishkov: I'm afraid they do in sc2
[08:45:01] <Dark_Shikari> they're tons of them
[08:45:06] <Dark_Shikari> oh yeah, lu_zero, you have a point
[08:45:10] <Dark_Shikari> there's that touhou clone for sc2
[08:45:50] * lu_zero is wondering who has the rainbow attack...
[08:45:56] <lu_zero> protos.
[08:51:41] <astrange> Dark_Shikari: you don't like bidoof?
[08:52:33] <Dark_Shikari> which one is that?
[08:52:38] <Dark_Shikari> I don't play your newfangled series reboots.
[08:52:47] <Dark_Shikari> the only one I know of is mudkips.
[08:52:50] <Dark_Shikari> and for the obvious reason.
[08:53:07] <astrange> http://tygerstyle.net/wordpress/wp-content/uploads/2007/05/art_011.jpg
[08:53:47] <Dark_Shikari> Oh.  That guy.
[08:54:19] <Dark_Shikari> He looks like a Chia pet.
[08:58:41] <iive> is that pokemon too?
[09:00:56] <av500> lol: http://groups.google.com/a/webmproject.org/group/webm-discuss/browse_thread/thread/45e18bef3c4bd9bb?hl=en#
[09:02:49] * kshishkov invents A-frames that make video better than one with B-frames by definition
[09:03:45] <mru> mpeg1 D-frames were worse for sure
[09:04:04] <Dark_Shikari> Q-frames
[09:04:46] <kshishkov> Z-frames encoded with IJG 9
[09:05:22] <av500> kshishkov: A-frames can be nice for vacation
[09:07:33] <kshishkov> av500: the only vacation I had in my life was June 9th-11th 2010
[09:07:57] <av500> and janneg does not live in an a-frame....
[09:10:35] * elenril shoots av500 
[09:10:47] <elenril> i don't even read tvtropes all that much =p
[09:10:58] * av500 tropes elenril
[09:11:26] <mru> elenril: not anymore, not since you memorised them all
[09:11:32] <av500> http://tvtropes.org/pmwiki/pmwiki.php/Main/TheTropeToEndAllTropes
[09:11:56] * kshishkov wants to kill at least half of av500
[09:12:14] <av500> i'll just grow back
[09:12:31] * elenril kills av500 http://tvtropes.org/pmwiki/pmwiki.php/Main/DeaderThanDead
[09:12:57] <elenril> mru: irrelevant details
[09:13:08] <iive> elenril: i don't know if you read them, but you quote them all the time :P
[09:13:48] <av500> you have been troped
[09:14:00] <av500> you've got trope
[09:14:49] <pJok> never start cleaning up in a mess you enherited when its 32+ degrees where the mess is...
[09:15:29] <kshishkov> yes, let it produce vile stench first
[09:15:44] <kshishkov> and attract flies
[09:16:20] <pJok> its only bitrot
[09:16:27] <mru> bitflies
[09:16:44] <pJok> old outdated equipment that should have been thrown away way before i started in this company
[09:16:56] <av500> and you are the janitor?
[09:16:58] <pJok> (like most of the rest of the equipment we use)
[09:17:04] <mru> bitjanitor
[09:17:06] <pJok> av500, im the IT janitor, yes...
[09:17:14] <pJok> i have all the keys
[09:17:15] <av500> oh
[09:17:31] <pJok> im the IT drone of this company
[09:17:38] <pJok> which just means im in charge of anything with a charge
[09:17:49] <pJok> except video equipment
[09:17:58] <mru> bitpredator?
[09:18:02] <pJok> i wish
[09:18:07] <twnqx> hm, blurays/dvds don't have language info in the stream, do they?
[09:18:21] <mru> twnqx: dvds have it in the ifo files
[09:18:28] <kshishkov> mru: careful, you may mention some versioning system by mistake
[09:18:35] <twnqx> i meant the m2ts/vob alone
[09:18:52] <mru> twnqx: not in the vob
[09:18:55] <mru> don't know about bluray
[09:19:50] <av500> twnqx: for DVD, not in the vob
[09:20:03] <twnqx> mh
[09:20:18] <mru> av500: no professional guess about bluray?
[09:20:34] <mru> can a bluray have 54 audio streams?
[09:20:52] <twnqx> i'm just looking at one with 8 audio and 5 sub streams
[09:21:08] <pJok> mru, if you make an image, i will gladly test if a bluray will play with 54 audio streams ;)
[09:22:11] <pJok> actually i dont think we have proper bluray player software...
[09:22:26] <twnqx> not for menus etc
[09:22:30] <twnqx> the .m2ts plays fine
[09:22:32] <pJok> last time i had to do something with a bluray, i used vlc anyways
[09:23:22] <twnqx> huh, ffmpeg supports everything that can be in a stream
[09:38:30] <pJok> twnqx, untrue.... avi in mov isn't supported ;)
[09:38:44] <twnqx> s/stream/bluray stream/
[09:39:12] <pJok> i actually wonder when demuxer chaining will happen
[09:39:20] <pJok> would be fun to wrap an ogg in an avi in a mov
[09:45:12] <CIA-99> ffmpeg: cehoyos * r24343 /trunk/ (3 files in 3 dirs):
[09:45:12] <CIA-99> ffmpeg: Make MP43 the default fourcc for msmpeg4v3:
[09:45:12] <CIA-99> ffmpeg: DIV3 is not supported on default XP and Vista installations (MP43 is).
[09:59:24] <CIA-99> ffmpeg: mstorsjo * r24344 /trunk/libavformat/aviobuf.c: Remove an assert that was no longer correct nor relevant
[10:10:52] <CIA-99> ffmpeg: mru * r24345 /trunk/tests/ (229 files in 2 dirs): regtest: rename seektest ref files using alphanumeric chars only
[10:18:33] * elenril kicks git-cvsimport
[10:18:41] <elenril> why does it have to be so slow
[10:18:50] <KotH> because it's *effort*
[10:18:55] <mru> cvs is slow
[10:20:15] <CIA-99> ffmpeg: mru * r24346 /trunk/configure: Collect list of seek tests in configure
[10:20:16] <CIA-99> ffmpeg: mru * r24347 /trunk/ (Makefile tests/fate-run.sh): fate: allow running regtests through fate frontend
[10:20:16] <CIA-99> ffmpeg: mru * r24348 /trunk/Makefile: Remove old regtest make rules redirecting to fate-based ones
[10:20:17] <CIA-99> ffmpeg: mru * r24349 /trunk/tests/seek-regression.sh: Remove unused seek-regression.sh script
[10:25:06] <elenril> anybody knows about a git mirror for pgf?
[10:25:27] <elenril> i feel like this could take a few hours
[10:27:52] <lu_zero> pgf?
[10:28:17] <lu_zero> elenril: what are you mirroring?
[10:28:50] <elenril> http://en.wikipedia.org/wiki/PGF/TikZ
[10:29:06] <elenril> a tex package for drawing
[10:29:14] <elenril> it still uses cvs :/
[10:30:45] <KotH> most of tex uses cvs
[10:31:27] <elenril> are they into bdsm or what
[10:32:02] <av500> wasnt tex like buf free? they could use .tgz ...
[10:32:07] <av500> bug free
[10:33:36] <elenril> packages aren't
[10:34:38] <av500> ah
[10:35:24] <KotH> and which tex implementation?
[10:35:33] <lu_zero> and tex is already a perversion in many senses
[10:35:43] <KotH> tetex has been replaced by pdflatex which is going to be replaced by luatex
[10:35:59] <mru> that doesn't sound right
[10:36:03] <elenril> KotH: you mean xetex
[10:36:18] <mru> tetex is/was a tex distribution containing all the different frontends and backends
[10:36:33] <mru> pdflatex is a latex frontend and a pdf backend
[10:36:43] <KotH> lu_zero: then you've never hat a look at metapost/metaobject ;:)
[10:37:10] <mru> gentoo is now installing something called texlive
[10:37:21] <mru> which also contains all the usual frontends and backends
[10:37:32] <mru> I have no idea what luatex is but it sounds scary
[10:37:33] <elenril> yeah, texlive replaced tetex
[10:37:49] <KotH> mru: most distros switched to texlive as tetex wasnt maintained for years
[10:37:57] <mru> yes, makes sense
[10:38:08] <mru> but both contain pdflatex
[10:38:26] <mru> it neither replaced anything nor was replaced
[10:38:50] <elenril> pdflatex and luatex and xetex and godknowswhatelsetex
[10:38:57] <av500> textex?
[10:39:07] <av500> semtex ftw!
[10:39:33] <mru> av500: can I run that on my beagle C4?
[10:39:39] <KotH> semtex for the *BOOM*!
[10:39:52] <av500> mru: dont mix C4 and semtex
[10:40:07] <mru> what happens?
[10:40:22] <av500> i guess nothing, still few people try
[10:42:58] <spaam> mru: do you run gentoo on your beagle? :D
[10:43:05] <mru> of course
[10:43:11] <mru> by beagleS
[10:43:24] <lu_zero> KotH: whats that?
[10:43:34] <lu_zero> lots of beagles
[10:43:38] <mru> lu_zero: the boom?
[10:44:16] <lu_zero> you managed to made them explode?
[10:44:25] <mru> no
[10:44:43] <lu_zero> btw there are interesting plans about having at least pkgcore support remote building
[10:45:14] <mru> what's pkgcore?
[10:47:14] <lu_zero> an alternative implementation of portage
[10:47:26] <lu_zero> still python+C
[10:56:44] <spaam> lu_zero: what is the diff between pkgcore and paludis ? :)
[10:56:59] <mru> all except the p
[10:57:33] <spaam> ;P
[10:58:05] <ods15> does anyone know if cellphones today use software decoding for video or hardware?
[10:58:31] <mru> combination
[10:59:16] <ods15> what sort.. does the software handle the frames individually? (demuxing)
[10:59:50] <mru> they use DSPs and low-level accelerators
[11:00:51] <lu_zero> spaam: one works the other is a bad excuse to show up your knowledge of latin
[11:00:51] <ods15> so just fancy cpu functions, not proper decoding
[11:01:15] <spaam> lu_zero: ok :)
[11:01:28] * lu_zero is a bit critical regarding paludis
[11:01:32] <mru> ods15: there are hw blocks doing things like transform and deblocking
[11:01:39] <mru> sw tells them what to operate on
[11:01:49] <ods15> ok
[11:02:11] <ods15> i thought hardware decoding was more commonplace, i'm a bit surprised that it doesn't do it all
[11:02:27] <mru> ods15: 80% of the work is done by dedicated hw
[11:02:34] <mru> the sw is mostly glue
[11:02:52] <ods15> yeah that's pretty convinient actually, supports a lot of codecs this way
[11:03:11] <kshishkov> only if they are very similar
[11:03:21] <kshishkov> for example, good luck with VPx
[11:04:20] <ods15> depends on how generic the hardware functions are... i don't know any video encoding internals, i mostly expected them to be similar building blocks...
[11:05:18] <kshishkov> yes, but it may be stone, brick or adobe
[11:05:29] <ods15> :)
[11:05:30] <mru> flash?
[11:05:36] <av500> kshishkov: wood too
[11:05:44] <ods15> different q :) how common are b frames on youtube flv's and the like?
[11:05:56] <av500> depends
[11:05:59] <ods15> (is youtube mp4 now? i'm never sure)
[11:06:29] <kshishkov> ods15: youtube now uses your encoder
[11:06:36] <kshishkov> with webm
[11:06:49] <kshishkov> (or maybe they've stopped doing that already)
[11:07:21] <ods15> kshishkov, my encoder is the vorbis encoder in ffmpeg :P i doubt they use that.. do you mean ffmpeg or mencoder?
[11:07:28] <av500> vorbis
[11:07:42] <av500> in ffmpeg
[11:07:50] <ods15> oh, wait, what
[11:07:53] <ods15> haha
[11:08:27] <ods15> heh i've never heard of webm, looking at it now.. does anyone use it? i've actually never seen any html5 videos
[11:08:34] <mru> lol
[11:08:38] <ods15> err, any html5 webpages at all i mean
[11:08:40] <mru> what rock have you been under?
[11:08:50] <kshishkov> Negev desert rock, I think
[11:08:55] <ods15> stone, concrete :P
[11:09:16] <av500> mru: you think he missed much with html5 and wemb?
[11:09:22] <ods15> i FIRST heard of html5 when i was hunting around for a new cellphone a few months ago!
[11:09:24] <lu_zero> ods15: !!
[11:09:30] <mru> av500: jsut surprised he hadn't heard of it
[11:09:33] <lu_zero> you are alive!
[11:09:45] <mru> lu_zero: it could be a zombie
[11:09:47] <ods15> lu_zero, yes, shhh, they haven't gotten to me yet :P
[11:09:48] <mru> in early stages
[11:10:23] <lu_zero> mru: considering ods I'd consider him a changeling
[11:10:52] <ods15> a what?
[11:12:24] <lu_zero> http://whitewolf.wikia.com/wiki/Changeling:_The_Lost
[11:12:32] <lu_zero> hi wbs
[11:13:21] <ods15> kshishkov, i wonder if i can find out if they are really using my vorbis encoder.. that would be pretty cool.. do you know any webm videos on youtube?
[11:13:30] <wbs> hi lu
[11:14:27] <av500> ods15: http://googlesystem.blogspot.com/2010/05/how-to-play-webm-video-on-youtube.html
[11:15:04] <ods15> sigh, webm is theora.. has theora gotten better?
[11:15:13] <mru> is not
[11:15:18] <mru> and has not
[11:15:23] <ods15> (i am wildly out of date, "gotten better" i mean since several years ago)
[11:15:27] <mru> wemb is vp8
[11:15:30] <mru> in matroska
[11:15:52] <kshishkov> and vp8 is theora 2
[11:16:05] <lu_zero> kshishkov: nah
[11:16:19] <kshishkov> lu_zero: just wait for Xiph move
[11:16:28] <mru> vp8 magically made theora worse
[11:16:37] <mru> theora use to be "as good as h264"
[11:16:38] <lu_zero> kshishkov: then will be ffvp9
[11:16:51] <mru> not vp8 is "competitive with h264"
[11:16:55] <mru> and also better than theora
[11:17:09] <mru> rock, scissors, paper...
[11:17:10] <av500> mru: theora was "good enough", vp8 is "gooder enougher"
[11:17:35] <lu_zero> hammer?
[11:17:45] <av500> RPG
[11:18:18] <MrNaz_YMAtv> av500 is vp8 really comparable in quality to h264? that seems like quite a claim...
[11:18:46] <lu_zero> MrNaz_YMAtv: depends on the encoder/settings etc
[11:18:55] <lu_zero> it isn't that bad anyway
[11:19:04] <av500> MrNaz_YMAtv: too H264 BP
[11:19:07] <av500> MrNaz_YMAtv: to H264 BP
[11:19:26] <MrNaz_YMAtv> av500 H264 BP ?
[11:19:31] <av500> base profile
[11:19:36] <MrNaz_YMAtv> is that the simple profile?
[11:19:38] <MrNaz_YMAtv> aahyea
[11:19:40] <av500> the one without the fun
[11:20:01] <MrNaz_YMAtv> yep cool
[11:20:02] <MrNaz_YMAtv> thanks
[11:20:12] <MrNaz_YMAtv> any chance flash will get vp8 support ever ?
[11:20:22] <av500> adobe said it would
[11:20:26] <MrNaz_YMAtv> ooer nice
[11:20:46] <MrNaz_YMAtv> final q... will vp8 support live streaming ?
[11:21:12] <MrNaz_YMAtv> err... dumb q
[11:21:14] <wbs> uh, that hasn't anything to do with the codec, it's just up to the live streaming protocols
[11:21:21] <wbs> but mkv is streamable
[11:21:51] <MrNaz_YMAtv> well.. id prefer to pack it into .flv for live streaming directly from studio to the web site
[11:22:04] <ods15> hrm, this video isn't webm... /me tries to find another one
[11:22:57] <MrNaz_YMAtv> i'm currently doing   camcorder -> firewire port -> dvgrab -> ffmpeg -> flv -> ffserver running in datacenter -> flowplayer   and that gives me a real time broadcast to web site
[11:23:02] <av500> ods15: http://devfiles.myopera.com/articles/1891/custom-controls-webm-720p.html
[11:23:11] <av500> from http://dev.opera.com/articles/view/opera-supports-webm-video/
[11:25:07] <ods15> is this a youtube video?
[11:25:15] <av500> no
[11:25:17] <ods15> i want to find a webm video from youtube
[11:26:38] <ods15> hmm, need to download different firefox or opera for this
[11:40:06] <KotH> hey ods15!
[11:45:52] <ods15> hi KotH !
[11:46:32] <KotH> how come you ended up here?
[11:47:13] <av500> KotH: apparently somebody lifted a rock
[11:48:25] <ods15> i actually needed some info about cellphone video decoding... but now i'm obsessed on finding out if youtube uses my vorbis encoder :P
[11:49:08] <mru> ods15: they did for a short while
[11:49:09] <cartman> lo ods15 , your vorbis encoder still sucks man :-}
[11:49:12] <cartman> hi! ;)
[11:49:16] <mru> until someone told them how shit it was
[11:49:45] <ods15> cartman, yes, i know it does suck
[11:49:58] <ods15> mru, oh! can i find that conversation? it sounds awesom :)
[11:50:00] <KotH> ods15: time to fix it then!
[11:50:18] <mru> ods15: sorry, I don't know where any discussions took place
[11:51:13] <CIA-99> ffmpeg: mstorsjo * r24350 /trunk/libavformat/ (asf.c asf.h): asf: Add asf_jfif_media guid
[11:51:51] <ods15> oh, there's aomsething - http://xiphmont.livejournal.com/51160.html
[11:51:53] <CIA-99> ffmpeg: mstorsjo * r24351 /trunk/libavformat/asfdec.c: asfdec: Handle asf_jfif_media
[11:52:02] <ods15> anyway, thats cool enough for me :P
[11:52:27] <KotH> ods15: how are your studies going?
[11:52:35] <KotH> ods15: or did you switch again? ;)
[11:53:19] <CIA-99> ffmpeg: mstorsjo * r24352 /trunk/libavformat/asfdec.c: asfdec: Don't read the video stream header if there isn't enough data
[11:53:40] <ods15> still at physics/math
[11:54:32] <mru> get onto dsp already!
[11:55:14] <ods15> lol, i think this webm video i download IS my vorbis encoder :) it's vorbis, and it doesn't have the Xiph tag
[11:55:20] <kshishkov> somebody from FFmpeg devs should know that stuff
[11:59:08] <cartman> that explains the crap quality of webm videos?
[11:59:09] <cartman> :p
[12:00:19] <ods15> i actually feel kind of bad about this - http://xiphmont.livejournal.com/51160.html
[12:00:23] <av500> the crap sound rubs on to the video?
[12:00:36] <av500> ods15: dont
[12:00:42] <ods15> ffmpeg using my sucky encoder on youtube does not bode well for vorbis
[12:00:53] <kshishkov> ods15: relax, that guy designs containers worse than you write audio encoders
[12:01:00] <ods15> lol
[12:01:19] <ods15> av500, i actually somewhat blame ffmpeg, i was against using my encoder by default if libvorbis is compiled in
[12:01:52] <kshishkov> now it won't
[12:01:58] * mru blames those who allowed it to be committed in the first place
[12:01:58] <av500> ods15: ah, ffmpeg and it's NIH syndrome....
[12:02:30] <ods15> kshishkov, yeah, i JUST read that it has been disabled by default, good move...
[12:02:55] <av500> ods15: I still blame google for doing no QC on what they encode....
[12:03:16] <kshishkov> av500: does it makes any difference with input users provide?
[12:03:31] <av500> no
[12:03:35] <ods15> av500, yeah, i miswrote, it's bad PR for vorbis in general that ffmpeg does this, not specific to youtube
[12:03:47] <av500> from the POV, they could have stayed with H263 for 99% of their content
[12:03:54] <cartman> ods15: lol
[12:04:01] <av500> the->that
[12:08:41] <ods15> does flv1 have b frames?
[12:09:26] <av500> the h263 variant? no IIRC
[12:29:38] <ods15> is the h263 variant the one commonly used on youtube?
[12:30:20] <ods15> any easy way i can see I/P/B statistics on a file? count or size, prefferably size
[12:30:42] <ods15> i need on H264 files and FLV1
[12:31:15] <kshishkov> ffmpeg -loglevel 9 -i infile -f null
[12:31:25] <lu_zero> ods15: use youtube-dl --all-formats
[12:31:29] <lu_zero> and you'll fetch all
[12:31:57] <lu_zero> youtube-dl --all-formats http://www.youtube.com/watch?v=d1_JBMrrYw8
[12:32:08] <lu_zero> with the latest youtube-dl
[12:32:31] <ods15> hmm, i've already fetched all :)
[12:32:40] <ods15> kshishkov, i'll try that :)
[12:34:44] <ods15> ./ffmpeg: unrecognized option '-loglevel' ? wow i'mwildly out of date
[12:34:51] <ods15> FFmpeg version SVN-r16061, Copyright (c) 2000-2008
[12:35:57] <ods15> kshishkov, it's not showing any ipb statistics that i can see...
[12:52:21] <kshishkov> ods15: it's 2010
[12:52:40] <kshishkov> but in your case -v 99 may work
[12:52:52] <mru> -v still works
[12:53:22] <ods15> yeah i just ran svn update
[12:53:37] <ods15> you'll notice i was about 8000 revisions out of date
[12:55:37] <CIA-99> ffmpeg: mru * r24353 /trunk/tests/fate-run.sh:
[12:55:37] <CIA-99> ffmpeg: fate: run diff even if command fails
[12:55:37] <CIA-99> ffmpeg: The diff may provide useful information even if the command was
[12:55:37] <CIA-99> ffmpeg: unsuccessful. The test is still treated as failed in this case.
[13:04:28] <ods15> kshishkov, it's still not showing me any statistics.. i used '-loglevel 9', i'll try -v 99
[13:05:37] <ods15> heh, well, -v 9 shows more noise than -loglevel 9, but still nothing about p/b frames :(
[13:08:26] <kshishkov> hmm, I remember that debug log level showed picture information
[13:09:04] <CIA-99> ffmpeg: mstorsjo * r24354 /trunk/libavformat/asfdec.c:
[13:09:05] <CIA-99> ffmpeg: asfdec: 10l, fix the minimum asf video stream header size
[13:09:05] <CIA-99> ffmpeg: This fixes the regression test breakage.
[13:09:25] <mru> wbs: thanks
[13:15:29] <wbs> mru: thanks to you for pointing it out so quickly, too. saved potentially many minutes of embarrasment until I would have found out myself :-)
[13:15:56] * mru keeps an eye on fate
[13:17:11] <wbs> on that topic btw, I've got a fate in a screen somewhere, but it's only good for checking if the build has failed or not - it's testing the win ce build
[13:17:52] <wbs> and I'm not really that into ce so that I would have set up some remote testing on such an emulator or something similar
[13:23:49] <Honoome> wbs: the feng patch looks good, but still probably not 100% fixed
[13:24:41] <wbs> Honoome: ok, what issue do you expect?
[13:24:51] <Honoome> wbs: machine with _no_ public IPs ;)
[13:25:11] <wbs> Honoome: umm.. how would you expect it to work then? :-)
[13:25:19] <Honoome> NAT
[13:25:37] <wbs> ah, well, it should work just as well as it did before at least
[13:26:03] <Honoome> yeah no doubt about that :) it just came to me that it wouldn't work in that case
[13:26:08] <Honoome> I'll turn yamato on and apply the patch
[13:26:18] <Honoome> mru: any idea about having obj-$(CONFIG_NO_SMALL) or something? :P
[13:26:32] <mru> $(!CONFIG_SMALL)
[13:26:48] <wbs> well, the packets would be sent from the same IP as the client has connected to, whatever that is, so the nat can map that back in whatever way it wants
[13:26:54] <Honoome> mru: it works?
[13:26:58] <mru> of course
[13:27:02] <mru> look in config.mak
[13:27:16] <mru> ! is a valid character in make variables
[13:27:24] <Honoome> I wasn't expecting it to, okay thanks :)
[13:27:40] <mru> the configure system has many nice, undocumented functions
[13:27:42] <Honoome> wbs: you'd have to mangle the RTSP stream for that to work, a configuration would help
[13:53:33] <BBB> spyfeng: I'll apply your patches today, something went wrong yesterday so didn't get to it
[13:57:10] <mchinen> how do I run a particular seek regression test?
[13:57:25] <mru> mchinen: make fate-seek-foo
[13:57:33] <mru> works since today
[13:57:56] <mru> test dependencies are still a bit weird though
[13:58:00] <mchinen> cool.
[13:58:09] <mru> so it will insist on running the codec tests first
[13:58:42] <Honoome> mru: confirmed that static linking works, will check the osx build in a moment
[13:59:12] <mru> if you've already run those, you can skip them by using make -o fate-codec -o fate-lavf
[13:59:20] <mru> Honoome: static linking of course works
[13:59:34] <mru> or actually not of course
[13:59:38] <mru> by luck
[13:59:49] <mchinen> ok
[13:59:57] <Honoome> by design more than luck :) and by symbolic dynamic linking works as well
[14:00:04] <mru> Honoome: depends
[14:00:15] <mru> is the table alone in an object file in both libs?
[14:00:21] <Honoome> yep
[14:00:27] <mru> then it of course works
[14:00:45] <mru> if it's sharing file with something else it will only work if that file is linked first
[14:00:52] <mchinen> I get messages like +ret: 0         st: 0 flags:1 dts: 0.000000 pts: 0.000000 pos:   8256 size:   614
[14:01:01] <mchinen> I guess these are reference errors?
[14:01:03] <av500> wbs: ping
[14:01:08] <mru> mchinen: what command did you run
[14:01:22] <Honoome> mru: thus design ;) of course I was going to make it stand alone in the object file at that point
[14:01:40] <wbs> av500: pong
[14:01:40] <mchinen> mru: this is just 'make test' and its probably caused by my flac parser.
[14:01:44] <mru> Honoome: I didn't know you'd moved the one in lavc to its own file
[14:02:08] <Honoome> I told you on ML I think
[14:02:09] <av500> wbs: you did that opencore amr stuff?
[14:02:13] <wbs> av500: yeah
[14:02:25] <av500> which is the lib as given by opencore from android no?
[14:02:31] <mru> Honoome: maybe I didn't read carefully enough
[14:02:48] <wbs> av500: not really
[14:03:00] <av500> so what is it?
[14:03:01] <wbs> av500: it's just the amr files ripped out from opencore, with enough wrapping to compile standalone
[14:03:10] <av500> ok
[14:03:15] <av500> thats what I meant
[14:03:24] <av500> and what is the licence?
[14:03:27] <wbs> apache 2.0
[14:03:39] <mru> mchinen: the seek test pass with svn head
[14:03:46] <mru> mchinen: so it must be something you did
[14:03:53] <mchinen> yes, but I don't know how to read the error.
[14:04:01] <av500> wbs: a coworker tries to add it and comes up with gpl3?
[14:04:05] <mru> it's a diff between the output and the reference
[14:04:19] <wbs> av500: apache 2.0 is incompatible with (l)gplv2 if you read the fine print
[14:04:31] <wbs> av500: but compatible with (l)gplv3, so you need to --enable-version3 for ffmpeg to be compatible with it
[14:04:49] <av500> yes, thats what we get
[14:05:03] <mru> btw, I want to rename that flag
[14:05:07] <mru> version3 of what?
[14:05:09] <mru> ffmpeg?
[14:05:25] <wbs> good point
[14:05:34] <siretart> FFmpeg 3.0 sounds kinda cool :-)
[14:05:46] <pJok> ffgpl?
[14:05:56] <wbs> do a slackware, jump a few major numbers just to be as cool as everybody else ;P
[14:06:03] <mru> wbs: 7?
[14:06:13] <kierank> ffmpeg karmic
[14:06:16] <wbs> mru: yeah
[14:06:17] <av500> wbs: so, i need to enable that flag, but what does that mean for the licence of the final ffmpeg?
[14:06:30] <av500> assuming i dont include any gpl3 code
[14:06:48] <mru> nobody knows
[14:06:51] <wbs> av500: ask a good lawyer, or diego
[14:06:59] <mru> a good diego
[14:07:00] <av500> :)
[14:07:04] <mru> so Honoome won't do
[14:07:08] <wbs> :-)
[14:07:16] <Honoome> mru: tsk :P
[14:07:20] <av500> maradonna?
[14:07:30] <av500> no, he lost....
[14:07:30] <Honoome> https://wiki.fsfe.org/EuropeanLegalNetwork/LinkingDocument what about this?
[14:07:46] <av500> Honoome: "This Connection is Untrusted"
[14:07:52] <Honoome> don't tell me
[14:08:14] <wbs> theoretically, I guess you consider all the lgplv2+ code as lgplv3+ only, for that build, and have to abide to that version, even if the code itself initially was lgpl2
[14:08:19] * Honoome still can't understand EFF's insistence of moving the world toward exclusive ssl connections
[14:08:30] <mru> wbs: somehow that doesn't make sense to me
[14:08:50] <mru> Honoome: everybody has an agenda, that happens to be theirs
[14:08:59] <wbs> av500: but if you want real progress - IIRC superdump said that he had heard from someone at packetvideo that said that they're ready to dual-license it to lgpl if it would make us happier
[14:09:04] <mchinen> are parsers supposed to return the file header if encountered?
[14:09:15] <superdump> yup
[14:09:24] <av500> return inside a packet?
[14:09:28] <superdump> i told them to send a message to the -devel mailing list iirc
[14:09:33] <mru> mchinen: what kind of header?
[14:09:38] <mru> flac header?
[14:09:38] <mchinen> ok that must be it.
[14:09:42] <mchinen> mru: yes
[14:10:04] <mru> I don't think you're supposed to send the header to the parser
[14:10:08] <av500> wbs: thing is, we already use the same code on the android side...
[14:10:15] <av500> inside the same product
[14:10:31] <mru> av500: legalese is fun, isn't it?
[14:10:37] <wbs> yeah
[14:10:40] <av500> sure
[14:11:08] <mru> it's like one of these elaborate stories where someone ends up being his own uncle in the end
[14:11:19] <wbs> also, since all the system libs are apache 2.0, is gplv2 userland code forbidden totally? or is that ok with gpl since they're system libs?
[14:11:26] <wbs> and what if you consider opencore-amr a system lib? ;P
[14:11:42] <mru> on that system I guess you could consider it that...
[14:14:17] <CIA-99> ffmpeg: cehoyos * r24355 /trunk/ (10 files in 4 dirs):
[14:14:17] <CIA-99> ffmpeg: Lego Mindstorms RSO muxer and demuxer.
[14:14:17] <CIA-99> ffmpeg: Patch by Rafa?l Carr?, rafael d carre a gmail
[14:14:54] <av500> CIA-99: utf-8 please
[14:15:17] <Honoome> hah, cia and utf8
[14:15:39] <av500> Honoome: your fsf doc is tl;dr
[14:15:44] <mru> av500: that's cia
[14:15:48] <Honoome> not mine
[14:15:59] <mru> right, you were shouting at cia
[14:16:12] <av500> yes
[14:16:14] <mru> thought you'd know by now that doesn't work
[14:16:16] <CIA-99> ffmpeg: cehoyos * r24356 /trunk/doc/general.texi: FFmpeg never supported msmpeg4v1 encoding.
[14:16:21] * mru kicks CIA-99 
[14:16:21] <CIA-99> ow
[14:18:47] <av500> D_IF_init() D_IF_decode() D_IF_exit(), what that DOS 8.3 function names?
[14:19:24] <wbs> av500: well, that are the names of the original amr float sample code
[14:21:06] <wbs> av500: if it is of any help to you, I can relicense the wrapper files to whatever license you want, including public domain. then you should be able to link that file into your binary, and just link against the libraries in the system, given that the function names the wrapper wants exist
[14:21:54] <wbs> superdump: I'd appreciate if you'd remind him
[14:22:13] <av500> wbs: im looking at libopencore-amr.c
[14:22:20] <wbs> av500: ah
[14:22:26] <av500> is that the wrapper? or is there another one?
[14:22:51] <wbs> libopencore-amr itself contains a small wrapper that emulates that interface, using the functions that actually exist in opencore
[14:23:18] <av500> wbs: I will have a look
[14:23:49] <wbs> av500: http://opencore-amr.git.sourceforge.net/git/gitweb.cgi?p=opencore-amr/opencore-amr;a=blob;f=amrnb/wrapper.cpp;h=9af8a0e9ebd58658ed7f4fa6caeddfaf367d0972;hb=66e104a2f55f116eaf83d8140b480dcec8a09b1a
[14:24:12] <j-b> funman?
[14:24:22] <av500> j-back from vacation?
[14:24:38] <wbs> av500: hmm, I'm not sure if I'm legally able to relicense the one for amrwb, though, if you want that one, http://opencore-amr.git.sourceforge.net/git/gitweb.cgi?p=opencore-amr/opencore-amr;a=blob;f=amrwb/wrapper.cpp;h=dd282811acfaa1783fbb7646951d95c4d4cab2d1;hb=66e104a2f55f116eaf83d8140b480dcec8a09b1a
[14:25:06] <av500> wbs, apche is fine for me
[14:25:20] <j-b> av500: yes
[14:26:02] <superdump> av500, wbs : his main focus was getting the code merged into ffmpeg
[14:26:20] <superdump> i had told him that merging library code into ffmpeg was not common practice
[14:26:28] <superdump> but perhaps it might be interesting
[14:26:37] <superdump> if the license were ok and so on
[14:26:38] <mru> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44958
[14:26:38] <wbs> yeah, that's a pity. but using it in general would be less problematic with lgpl anyway
[14:26:38] <av500> GSMInitDecode(&ptr, (int8*)"Decoder"); .....
[14:26:46] <superdump> but he should discuss it with a wider audience
[14:26:59] <av500> they have to relicence to lgpl anyway
[14:27:01] <superdump> and so he said that they could relicense it as lgpl if that would help move things along
[14:27:04] <superdump> right
[14:27:09] <av500> before it could be merged
[14:27:15] <Honoome> what the heck? I can't send email through gmail today?
[14:35:18] <mchinen> how are the ref files generated for flac if there was no parser?
[14:35:52] <av500> magic
[14:36:13] <mru> /dev/random
[14:36:57] <mru> mchinen: note that the ref fails on all seeks
[14:37:15] <mru> so it probably should change
[14:38:05] <mchinen> mru: the ref should change?
[14:38:15] <mru> if you made seeking work, yes
[14:39:55] <mchinen> ok, then i should probably verify that the ts is actually sample accurate through a different test before putting a ref in.
[14:45:12] <BBB> mru: do you have x86-64 somewhere?
[14:45:26] <mru> I have a few
[14:45:45] <BBB> one with gdb, gcc, shell accounts for hungry developers?
[14:45:53] <BBB> I'm using josh's right now, but it doesn't have gdb
[14:45:53] <BBB> :-p
[14:46:28] <mru> I suppose I could give you an account on one of mine
[14:46:36] <mru> do you have one on the ppc already?
[14:46:38] <BBB> no
[15:00:14] <CIA-99> ffmpeg: rbultje * r24357 /trunk/libavformat/mmst.c:
[15:00:15] <CIA-99> ffmpeg: Send a time test to the server, as the spec recommends.
[15:00:15] <CIA-99> ffmpeg: Patch by Zhentan Feng <spyfeng gmail com>.
[15:01:59] <CIA-99> ffmpeg: rbultje * r24358 /trunk/libavformat/mmst.c:
[15:01:59] <CIA-99> ffmpeg: Check the status code of each server responses, and fail if it indicates
[15:01:59] <CIA-99> ffmpeg: a problem.
[15:01:59] <CIA-99> ffmpeg: Patch by Zhentan Feng <spyfeng gmail com>.
[15:06:37] <CIA-99> ffmpeg: rbultje * r24359 /trunk/libavformat/mmst.c:
[15:06:37] <CIA-99> ffmpeg: Fix a compile warning when compiling with DEBUG=1.
[15:06:37] <CIA-99> ffmpeg: Patch by Zhentan Feng <spyfeng gmail com>.
[15:08:27] <CIA-99> ffmpeg: rbultje * r24360 /trunk/libavformat/mmst.c:
[15:08:27] <CIA-99> ffmpeg: Align outgoing messages to 8 bytes, this is required to interact with
[15:08:28] <CIA-99> ffmpeg: most servers. Also remove a case where we manually aligned to 8 bytes,
[15:08:28] <CIA-99> ffmpeg: since this is now no longer needed.
[15:08:28] <CIA-99> ffmpeg: Patch by Zhentan Feng <spyfeng gmail com>.
[15:09:43] <CIA-99> ffmpeg: vitor * r24361 /trunk/libavcodec/atrac3.c: Fix memory leak in ATRAC3 decoder
[15:12:37] <CIA-99> ffmpeg: rbultje * r24362 /trunk/libavformat/mmst.c:
[15:12:37] <CIA-99> ffmpeg: Explicitely set the size of the "ff_asf_head1_guid" header chunk, this is
[15:12:37] <CIA-99> ffmpeg: part of the spec and causes problems otherwise.
[15:12:37] <CIA-99> ffmpeg: Patch by Zhentan Feng <spyfeng gmail com>.
[15:15:06] <CIA-99> ffmpeg: rbultje * r24363 /trunk/libavformat/mmst.c:
[15:15:06] <CIA-99> ffmpeg: Allow the ASF header to be transferred split over multiple packets, as some
[15:15:06] <CIA-99> ffmpeg: servers happen to do. For this, we also move several header-size-related
[15:15:06] <CIA-99> ffmpeg: variables to the MMSTContext.
[15:15:06] <CIA-99> ffmpeg: Patch by Zhentan Feng <spyfeng gmail com>.
[15:57:24] <synapsepg> hello ... this might sound odd ... but has anyone managed to build the ffmpeg-0.6 for WinCE >= 6.1
[15:59:57] <synapsepg> cause I'm struggling with two ARM build chains, and they both fail, at linking stage of libavcodec
[16:00:05] <lu_zero> BBB: if you still need I could give an access as well
[16:00:28] * av500 winces
[16:24:11] <CIA-99> ffmpeg: stefano * r24364 /trunk/libavfilter/vsrc_buffer.c: Add @file doxy.
[16:24:11] <CIA-99> ffmpeg: stefano * r24365 /trunk/libavfilter/vsrc_buffer.c: Apply misc cosmetical style fixes.
[16:26:08] <DonDiego> mru: the build system should run 'make config' if allcodecs.c/allformats.c/etc. have been modified
[16:26:29] <DonDiego> it's annoying to see the build fail because of a definition missing from config.h
[16:27:08] <DonDiego> i'm thinking what would be the best way to achieve it
[16:27:08] <av500> mru: now a good diego is there?
[16:27:14] <DonDiego> ?
[16:27:27] <mru> I've thought of the same thing
[16:27:33] <mru> just not been too bothered by it
[16:27:47] <DonDiego> automake does it :)
[16:27:53] <mru> which is annoying as hell
[16:27:59] <mru> becuase it generally breaks something
[16:28:00] <DonDiego> we should be at least equally good..
[16:28:02] <av500> DonDiego: http://ffmpeg.pastebin.com/7zmFPMM6
[16:29:05] <DonDiego> please
[16:29:14] <DonDiego> at least spell the man's name correctly: maradona
[16:29:22] <mru> DonDiego: anyway, I'll fix it
[16:29:36] <DonDiego> av500: what were you doing?
[16:29:51] <av500> trying to use libopencore_amr with lgpl ffmpeg
[16:30:04] <av500> which needs enable-v3
[16:30:05] <DonDiego> the end result is lgpl v3+
[16:30:09] <av500> yes
[16:30:18] <DonDiego> what was your question then?
[16:34:37] * /join #ffmpeg-devel ...
[16:34:39] *** TOPIC: Welcome to the FFmpeg development channel. | Discussions about the development of FFmpeg itself are ontopic here. | Questions about using FFmpeg or developing with the libav* libraries should be asked in #ffmpeg. | FFmpeg 0.6 has been released! | This channel is now publicly logged.
[16:34:39] *** TOPICINFO: peloverde!~alex at cpe-173-88-148-20.neo.res.rr.com, 1276886498
[18:16:13] * /join #ffmpeg-devel ...
[18:16:15] *** TOPIC: Welcome to the FFmpeg development channel. | Discussions about the development of FFmpeg itself are ontopic here. | Questions about using FFmpeg or developing with the libav* libraries should be asked in #ffmpeg. | FFmpeg 0.6 has been released! | This channel is now publicly logged.
[18:16:15] *** TOPICINFO: peloverde!~alex at cpe-173-88-148-20.neo.res.rr.com, 1276886498
[18:21:15] <mru> DonDiego: btw, you have your automatic reconfigure now
[18:21:57] <Dark_Shikari> awesome!
[18:34:20] * DonDiego looks
[18:35:31] <DonDiego> great!
[18:36:04] <DonDiego> .config needs to be added to svn:ignore though
[18:36:20] <DonDiego> will add it in a moment
[18:36:37] <DonDiego> and i will shamelessly copy it for mplayer :)
[18:38:05] <mru> you may copy it, but only if you feel a little shame
[18:38:31] * mru introduces the Shame Licence
[18:38:43] <mru> do whatever you want, provided you feel shameful doing it
[18:39:14] <kshishkov> aka Conscient Ripoff License
[18:42:53] <DonDiego> nah, i'm a shameless person generally..
[18:43:17] * kshishkov adds that to his stereotypes about Argentinians
[18:43:23] <mru> guess I'll have to add a diego exception clause
[18:43:32] <kierank> but then it won't be gpl compatible
[18:43:52] <kshishkov> add Stallman exception clause too and it will
[18:43:58] <mru> the diego exceptino makes no difference in that regard
[18:44:44] <DonDiego> it would become compatible if i died
[18:44:50] <mru> no
[18:44:51] <DonDiego> since then the exception would be void
[18:44:55] <mru> it's not compatible to begin with
[18:45:03] * DonDiego starts getting paranoid
[18:45:09] <mru> the shame requirement is incompatible
[18:45:21] <CIA-99> ffmpeg: diego * r24371 /trunk: Ignore .config file.
[18:58:02] <peloverde> How do people feel about fixed point?
[18:59:29] <peloverde> Somebody with some money approached me about fixedpoint aacdec
[19:00:09] <_av500_> take it?
[19:00:16] <mru> I don't think anyone is fundamentally opposed to it
[19:00:52] <kierank> only audiophiles are opposed to it
[19:00:53] <peloverde> Do people like the approach used for MP3?
[19:01:08] <mru> it's a hack
[19:01:11] <peloverde> (which I realize was fixed point first)
[19:02:05] <peloverde> I've done pure fixed point before but I've never done a single codebase supporting both
[19:02:46] <BBB> peloverde: it's supposedly easier to maintain
[19:02:54] <mru> huh?
[19:03:20] <BBB> enter: the era of disagreement
[19:03:24] <mru> shared code quickly turns into macro hell
[19:03:33] <Dark_Shikari> It's not unreasonable to do both
[19:03:37] <Dark_Shikari> it's a bit of macroing yeah
[19:03:40] <Dark_Shikari> but it's not insane
[19:03:50] <twnqx> template it
[19:03:51] <mru> the mp3 decoder is done in a very ugly way
[19:03:52] <twnqx> oh, wait...
[19:03:59] <mru> twnqx: same thing
[19:04:05] <Dark_Shikari> of course this could be resolved with C++
[19:04:09] <Dark_Shikari> and operator overloading
[19:04:15] <mru> operator overlording
[19:04:53] <kierank> that's presumably some kind of air and sea assault on europe in c++?
[19:05:17] <Dark_Shikari> spawn more overlords
[19:05:21] <mru> that's what c++ feels like
[19:05:27] <mru> an assault
[19:05:33] <mru> one you're on the wrong side of
[19:06:34] <CIA-99> ffmpeg: mru * r24372 /trunk/configure: configure: create .config file in configure to avoid needless reruns
[19:07:02] <peloverde> I was thinking about trying to macroize the AAC code but using the tremor IMDCT
[19:07:23] <peloverde> but it looks like av_fft was written with some sort of fixedpoint conversion in mind
[19:07:33] <mru> a fixed-point version of our mdct would be awesome
[19:07:52] <mru> peloverde: I think that left the mind just after the typedef was written
[19:09:09] <mru> that sort of typedeffing is useless imo
[19:09:16] <mru> we'll want both float and fixed-point anyway
[19:09:22] <mru> they're not mutually exclusive
[19:09:48] <peloverde> I'm not opposed to a fixed point version of our MDCT but I don't want to do it
[19:10:06] <mru> it would probably be much faster than tremor's
[19:11:12] <peloverde> What about the RockBox IMDCT
[19:11:14] <peloverde> it is LGPL
[19:11:20] <mru> how fast is it?
[19:11:27] <Yuvi> rockbox's is derived from ours
[19:11:38] <Yuvi> iirc they're trying to port it to tremor
[19:11:46] <mru> that's what we're looking for then
[19:12:10] <mru> if by derived you mean using the same split-radix algorithm
[19:12:19] <Yuvi> yeah, they started from our C code
[19:12:47] <peloverde> "Copyright (c) 2002 The FFmpeg Project"
[19:13:01] <peloverde> that seems too old?
[19:13:07] <peloverde> did we do split-radix in 2002?
[19:13:10] <mru> no
[19:13:15] <Yuvi> I know they also did the older one to fixed point
[19:13:34] <mru> just make sure it's the split-radix one
[19:13:40] <mru> anyway, wishlist time
[19:13:49] <mru> I'm doing things to the test system
[19:14:40] <peloverde> mt: ping?
[19:15:08] <mru> aim is to make something more managable than mike's fate
[19:16:09] <mru> so far I can run all the tests and produce a report file with all the results
[19:20:13] <spaam> good :)
[19:20:19] <DonDiego> sounds good
[19:20:37] <DonDiego> bbl
[19:25:29] <peloverde> The FFT that runs under the MDCT says "Copyright (c) 2008 Loren Merritt" :)
[19:25:37] <peloverde> What about a new fate server?
[19:26:34] <mru> that's part of the plan
[19:26:44] <mru> infrastructure is not the issue here
[19:27:01] <mru> but now would be a good time for bright ideas on what to include
[19:27:49] <peloverde> I was thinking rather than using SQLite as the wire format maybe we should use some sort of structured text?
[19:29:42] <Kovensky> YAML?
[19:30:14] <peloverde> I was thinking YAML or JSON
[19:31:13] <mru> for the report I'm using a simple text format
[19:31:17] <mru> one line per test
[19:31:22] <mru> values separated by :
[19:31:37] <Honoome> mru: the reason why I wanted to use it cross-directory was to make it buildable once only
[19:31:41] <mru> field with arbitrary content base64-encoded
[19:31:50] <peloverde> ok, that seems to make sense
[19:31:52] <mru> Honoome: I understand that
[19:32:03] <mru> Honoome: but I don't like it
[19:32:03] <Honoome> and also, using symlinks wouldn't work
[19:32:07] <mru> I know
[19:32:09] <Honoome> mru: any suggestion?
[19:32:16] <mru> #include it in lavc
[19:32:27] <saintdev> peloverde: http://uazu.net/fiview/
[19:32:42] <Honoome> it still has to be on its own object
[19:32:46] <mru> yes
[19:32:47] <peloverde> saintdev: very nice
[19:32:59] <mru> Honoome: so a one-line file #including the other one
[19:33:10] <mru> no, it's not terribly pretty
[19:33:11] <Honoome> hrm not elegant but would work
[19:33:28] <mru> but pulling in objects across libs is dodgy
[19:34:40] <mru> "compile" time is negligible anyway
[19:35:17] <peloverde> mru: I'd like the concept of a configuration to be a little more clear, in the past we had failures that we though were OS specific but turned out to be hardware specific
[19:36:25] <mru> arch, cpu, os, compiler
[19:36:28] <mru> anything else?
[19:36:50] <peloverde> assuming cpu is specific enough that should be sufficient
[19:37:02] <mru> whatever is passed to --cpu
[19:37:32] <peloverde> I want to know what the machine's mm_flags are
[19:37:55] <peloverde> That shows what codepaths get taken
[19:43:00] <Honoome> add uname -a output if uname exists
[19:43:24] <CIA-99> ffmpeg: mru * r24373 /trunk/configure: configure: create .config file where I intended
[19:43:53] <mru> Honoome: that's $arch
[19:44:03] <Honoome> -a not -m?
[19:44:18] <mru> sorry
[19:44:21] <mru> right
[19:44:22] <mru> good point
[19:44:39] <Honoome> -a should tell you the cpu trade name
[19:44:43] <Honoome> even though it's not perfect
[19:44:56] <mru> not quite
[19:45:03] <Honoome> fgrep flags /proc/cpuinfo | head -n1 ?
[19:45:06] <mru> -a is equivalent to -mnrsv
[19:45:22] <mru> anyway, this won't do any good at all for the cross-builds
[19:46:44] <mru> hmm, gnu uname prints more stuff
[19:47:08] <Honoome> Linux saladin.local 2.6.34.1 #10 SMP PREEMPT Mon Jul 5 22:31:17 CEST 2010 x86_64 Intel(R) Core(TM) i7 CPU Q 720 @ 1.60GHz GenuineIntel GNU/Linux
[19:47:24] <mru> I know what it looks like
[19:47:29] <peloverde> My uname -a says "Linux <hostname> 2.6.32-23-generic #37-Ubuntu SMP Fri Jun 11 08:03:28 UTC 2010 x86_64 GNU/Linux"
[19:48:30] <peloverde> "uname (GNU coreutils) 7.4" 7.4-2ubuntu2
[19:49:05] <Honoome> 8.5 here
[19:50:01] <peloverde> wow, I'm kind of surprised ubuntu is still on 7.4
[19:50:14] <mru> 8.5 here too
[19:58:59] <peloverde> janneg: LATM ping?
[20:00:09] <Honoome> mru: sent with the #include hack
[20:07:40] <wbs> BBB: btw, do you have time to check the rtsp-ms patch I sent yesterday?
[20:16:41] <mt> peloverde:  pong
[20:17:13] <peloverde> mt: Looks like I managed to answer my own question in the interim, sorry
[20:17:26] <mt> no problem :)
[20:17:44] <peloverde> but it does look like I will be porting the rockbox fixed point IMDCT/FFT to FFmpeg :)
[20:18:32] <mt> Nice ! :)
[20:18:48] <pJok> ffrockbox?
[20:19:02] <peloverde> more like fffixedpointaudio
[20:22:23] <BBB> wbs: not yet, it looked weird when I briefly looked at it
[20:22:25] <BBB> so needs more time
[20:23:24] <wbs> BBB: ok, it should be quite straightforward I think, so take your time :-)
[20:26:59] <_av500_> http://www.fsf.org/tasks/noscript
[20:28:02] <Honoome> ...
[20:28:29] <Honoome> there's nothing more important than that to waste their time with on the web?
[20:48:34] <CIA-99> ffmpeg: vitor * r24374 /trunk/tests/fate2.mak: WMAVoice regtests
[20:49:57] <mru> Vitor10011: I see you understood how to use the new test functinos
[20:51:59] <Vitor10011> mru: Sure!
[20:52:29] <Vitor10011> mru: I also tested to see if really 2.4 and 2.6 are really interpreted as different numbers ;)
[20:52:38] <mru> of course they are
[21:01:47] <mru> btw, have you guys seen the comments on my latest blog post?
[21:02:27] <Honoome> which one is it?
[21:02:37] <mru> the inline asm
[21:03:25] <_av500_> mru: nobody called an idiot yet...
[21:03:54] <mru> the gcc guy is getting angrier...
[21:05:41] <_av500_> you know my take on this, arm does not seem to be interested in having a good and free compiler
[21:05:58] <mru> s/arm/gnu/
[21:06:04] <_av500_> no, arm
[21:06:11] <_av500_> arm wants to sell stuff
[21:06:22] <Honoome> mru: you know, they are always volunteer, even when they are paid by RedHat, Canonical, ...
[21:06:36] <mru> Honoome: yes, that's what pisses me off
[21:06:42] <Honoome> too bad I can't volunteer to be paid by them :P
[21:06:52] <_av500_> have you tried?
[21:07:57] <Honoome> _av500_: the only thing that ever made someone interested in hiring me (pulseaudio) got me an interview with canonical, but then it drifted apart 'cause of my health
[21:08:51] <_av500_> ic
[21:09:05] <mru> are you blaming them for your health troubles?
[21:09:06] <mru> :-)
[21:10:22] <Honoome> mru: no I could blame gentoo for part of it though
[21:11:01] <Vitor10011> mru: What was again your reason why it was not possible to have a clean (documented in the C spec) syntax for inline asm?
[21:11:34] <mru> I don't recall giving such a reason
[21:11:48] <Vitor10011> mru: I think I asked you in IRC once...
[21:12:04] <mru> although the way the C language is defined it would be rather hard
[21:12:10] <Vitor10011> Why?
[21:12:38] <mru> not everething is a von neumann machine
[21:14:00] <Vitor10011> In what sense? (ie, where would it break?)
[21:14:45] <mru> the best you could do is set aside a keyword, e.g. asm, and leave the contents unspecified
[21:15:10] <Honoome> I guess you might not even emit asm at all in some cases
[21:15:25] <mru> what if you're targeting a turing tape?
[21:15:50] <mru> or anything else without a standard register/alu model
[21:16:31] <Vitor10011> mru: Well, in that case you need a special machine-specific syntax to say what is cloberred, but that's it.
[21:16:48] <mru> everything is machine-specific
[21:17:40] <_av500_> i guess that is why you write asm per cpu arch
[21:17:52] <mru> exactly
[21:18:25] <Vitor10011> The fact of having some syntax for ASM should be required for a future C spec and for all existing archs the machine-specific stuff should be defined.
[21:18:51] <_av500_> no
[21:18:53] <hyc> what's wrong with the way gcc inline asm works? specify input registers, clobbers ...
[21:18:56] <_av500_> eroops
[21:18:59] <_av500_> ooops
[21:19:05] <_av500_> the no was not for here :)
[21:19:28] <mru> gcc syntax works fine for gcc
[21:20:16] <mru> with a differently designed compiler it might not be possible to use that model
[21:25:07] <hyc> well, if your compiler doesn't let you write in terms of input registers and output registers then you probably can't embed ASM code in it anyway
[21:26:02] <_av500_> the compiler passes asm to the assembler
[21:28:46] <mru> some compilers do
[21:28:49] <mru> not all
[21:29:18] <mru> some generate machine code directly from the optimised parse tree
[21:29:50] <mru> I've come across bizarre compiler bugs that only showed up when producing an object file
[21:30:00] <mru> requesting asm output made it go away
[21:33:37] <_av500_> gee
[21:39:34] <BBB> Dark_Shikari: I found it
[21:39:39] <BBB> Dark_Shikari: you'd never believe where it was
[21:39:49] <BBB> Dark_Shikari: it was a 32bit'ism in WRITE_4x4D :'(
[21:40:31] <Dark_Shikari> :(
[21:40:34] <Dark_Shikari> gj
[21:40:51] <mru> what was it?
[21:41:09] <_av500_> mru: *it*
[21:45:47] <BBB> mru: mov [mem], reg
[21:45:52] <BBB> instead of mov [mem], regd
[21:46:07] <BBB> once you see it, you go like "oh, of course"
[21:47:03] <mru> I prefer machines where access size is part of the instruction name
[21:47:11] <mru> more obvious that way
[21:48:28] <Honoome> auuuugh
[21:51:33] <hyc> you could just write your assembler that way regardless
[21:51:52] <hyc> isn't that standard in MIT syntax?
[21:51:53] <twice11> Could "mov.l [mem], reg" have prevented the semantic change?
[21:52:04] <twice11> Oh, without the dot, sorry.
[21:52:45] <twice11> Might break compilation on 64 bit, but that would have helped here.
[21:52:51] <BBB> maybe
[21:52:57] <BBB> but I didn't
[21:54:55] <twice11> mru: There once was a bug in Borland's 16-bit C++ compiler that made it generate an invalid instrution internally.
[21:55:23] <twice11> In default mode, it directly writes an object file and used "DI" at a place where it didn't make sense.
[21:55:27] <mru> gcc can do that too
[21:55:38] <mru> make the assembler choke
[21:55:41] <CIA-99> ffmpeg: skal * r24375 /trunk/libavcodec/libvorbis.c: remove an unneeded av_realloc()
[21:55:47] <twice11> In the generate-asm mode, the operand was missing and the assembler complained.
[21:56:34] <mru> if avr32-gcc is compiled with x86-gcc-4.3 it spits out invalid asm syntax
[21:56:40] <mru> when compiling libgcc
[21:57:33] <BBB> Dark_Shikari: http://ffmpeg.pastebin.com/FTc7Mzhe
[21:58:04] <BBB> Dark_Shikari: tested on core1 with mmx-only, mmx2-only, sse2(forced) x86-32 and on x86-64 (sse2 only), bitexact on all
[21:58:07] <BBB> Dark_Shikari: ok to apply?
[21:58:12] <Dark_Shikari> don't see why not
[21:58:25] <BBB> yesterday, you told me "no more commits" ;)
[22:02:28] <Dark_Shikari> you tested it didn't you?
[22:02:35] <Dark_Shikari> I said no commits until you test on x86_64
[22:02:39] <Dark_Shikari> you did
[22:02:40] <Dark_Shikari> so commit it
[22:03:09] <CIA-99> ffmpeg: mru * r24376 /trunk/configure: configure: make sh_quote() more robust
[22:05:15] <CIA-99> ffmpeg: rbultje * r24377 /trunk/libavcodec/x86/ (vp8dsp.asm vp8dsp-init.c): Chroma (width=8) inner loopfilter MMX/MMX2/SSE2 for VP8 decoder.
[22:19:33] <Honoome> mru: does the latest patch look good for you?
[22:23:31] <mru> why do you include intmath.h?
[22:35:15] <peloverde> I have the worst electric company ever
[22:49:00] <Honoome> mru: to make sure to have its declaration and that it does not get mistaken
[22:49:46] <mru> ah ok
[22:50:11] <mru> then I'm ok with the patch
[22:50:33] <Honoome> okay, I'll still wait till tomorrow just to be on the safe side
[22:52:29] <Honoome> mru: out of curiosity, is there any dvb-s/mhp provider in the uk that beams encrypted bbc?
[22:52:48] <mru> sky?
[22:53:07] <kierank> all fta
[22:53:08] <mru> they're not mhp though
[22:53:18] <mru> is sky fta for bbc?
[22:53:22] <kierank> yes
[22:53:32] <mru> didn't they use to encrypt everything just because?
[22:53:48] <Honoome> hrm on which sat are they? they don't seem to be on fta where sky ita also is
[22:53:52] <kierank> because of "rights". however now they use astra 2d which is focused on britain
[22:53:55] <Honoome> only bbc news is here
[22:54:04] <Honoome> ah there is the trick, astra :/
[22:55:34] <BBB> Dark_Shikari: register saving done so pw_63 is now always in a reg, mmx-m8-15 references removed, tested on x86-64, anything else I should do before I can commit this?
[22:55:42] <kierank> might be a few regions on one of the european footprint birds, i forget though.
[22:56:04] <BBB> once this is committed, I'll work on getting performance charts on x86-64 also, maybe optimize the few cases where ssse3/sse4 helps
[22:56:15] <Dark_Shikari> ok
[22:56:17] <Dark_Shikari> commit that
[22:56:24] <Dark_Shikari> the x86_64 box has ssse3 right?
[22:56:25] <BBB> (pextrw, more register saving by splitting out sse2 functions from mmx-looped ones, etc.)
[22:56:34] <Dark_Shikari> so you can do pshufb with the SPLAT, and you can do the pmaddubsw trick I mentioned
[22:56:36] <BBB> it has everything, it seems
[22:56:38] <BBB> yes
[22:57:16] <Honoome> kierank: if they make use of the satellite reach, unlikely that anything arrives here, too "southern"... I was hoping to get some decent programmes here >_< sigh
[22:57:48] <mru> proxy through the uk and use iplayer
[22:58:15] <kierank> there are unofficial streams out there
[22:58:21] <kierank> some of which are pretty decent quality
[22:58:52] <Honoome> unfortunately I'd rather avoid streaming as my line is already slow by itself :|
[22:59:09] <kierank> if you buy a 2+m dish you might be lucky
[22:59:28] <Honoome> from italy? I'd doubt that :|
[22:59:49] <mru> mount it on a ship in the channel
[22:59:59] <kierank> people do it in southern spain so it might be possibly in italy
[23:00:16] <Honoome> and at that point I might as well just get a sky subscription, even just the "fox" channels (tv series) would be worth it from one point of view
[23:01:03] <kierank> there are maps out there that show what dish sizes you need for 2d
[23:01:30] <Honoome> [watching anything dubbed in Italian when the original is english gives me the creeps nowadays]
[23:01:33] <kierank> the official footprint maps aren't necessarily correct
[23:03:52] <kierank> Honoome: http://www.astra2d.com/italy.html
[23:05:44] <Honoome> hmm if it reaches bologna it might well reach here (bit norther), thanks! :) I'll keep this around, might not be too soonish (A/C comes first) but I'll take a look ;)
[23:20:01] <BBB> how do I see the tree that a git repo came from?
[23:20:17] <mru> uh?
[23:20:24] <BBB> i.e. if I want to pull from a tree on another computer but I'm too lazy (or cannot find) where the tree was on the first computer
[23:20:35] <BBB> svn info displays this
[23:20:40] <mru> git config -l
[23:21:10] <mru> note that a git repo can have any number of remotes defined
[23:21:31] <mru> which is very useful at times
[23:22:39] <Honoome> git remote -v
[23:22:50] <BBB> thanks, git config -l had it
[23:23:19] <mru> config displays everything
[23:23:28] <mru> remote only some informat
[23:23:35] <mru> ion
[23:33:55] <BBB> let's see how x86-64 performs
[23:34:36] <Dark_Shikari> you should go through and do the easy-mode ssse3 stuff first
[23:34:41] <Dark_Shikari> well, before other optimizations that is
[23:35:59] <BBB> I will, I just want to see how it compares, roughyl
[23:36:17] <BBB> on Core1 we're clearly faster now, by about 10-15%
[23:36:29] <Dark_Shikari> that might just be because livpx is dumb
[23:36:33] <Dark_Shikari> and uses sse2 asm
[23:36:58] <BBB> right, so I want to test our current state on a real cpu
[23:37:57] <Dark_Shikari> k
[23:41:01] <BBB> C: 1min47sec, SIMD: 52sec, libvpx: 50sec
[23:41:09] <BBB> not bad, but we can do better
[23:42:05] <spaam> so libvpx is faster
[23:42:06] <Dark_Shikari> so the reason we beat them on core1 is smarter asm function picking.
[23:42:12] <Dark_Shikari> spaam: it likely depends on the test clip and cpu
[23:43:12] <BBB> they have a lot of sse2/ssse3/sse4 asm
[23:43:31] <BBB> I think our mmx* asm is better, maybe our sse2 is on-par, but we don't have enough ssse3/sse4 asm, as you said
[23:43:39] <BBB> and it can be made a lot more optimal in some cases
[23:43:50] <BBB> (because mmx loops, sse* doesn't)
[23:44:27] <BBB> so I'll work on using pmaddusbw, pextrw, better use of registers in no-loop functions, etc.
[23:47:47] <Dark_Shikari> pshufb
[23:47:49] <Dark_Shikari> pshufb
[23:47:50] <Dark_Shikari> pshufb
[23:58:37] <BBB> oh yes pshufb for the splatbreg
[23:58:38] <BBB> :-p
[23:58:54] <BBB> I have a list of this somewhere, I won't forget, I think
[23:59:27] <Dark_Shikari> and everything else
[23:59:30] <Dark_Shikari> pshufb is just plain pure awesome