[FFmpeg-devel-irc] IRC log for 2011-03-10

[irc at mansr.com]

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