[FFmpeg-devel-irc] IRC log for 2010-05-14

[irc at mansr.com]

[05:54:07] <hyc> hmm, seems like something is wrong with the libx264-baseline.ffpreset file
[05:54:34] <hyc> always gives "broken ffmpeg default settings detected"
[05:54:41] <hyc> default and main still seem to work
[05:54:49] <hyc> ipod320 and ipod640 also give the same error
[05:56:34] <hyc> Dark_Shikari: any hints?
[05:59:36] <wbs> hyc: baseline shouldn't be used as such on its own... first load e.g. default or hq or fast or any such, and then baseline or main on top of that, for selecting profile
[05:59:47] <hyc> ohhhh
[06:05:26] <hyc> okwbs: thanks
[09:52:28] <nfl> hi is there an api call for reading from a ByteIOContext which won't advance buf_ptr?
[09:54:54] <mru> read followed by seek back
[09:57:48] <nfl> silly me
[09:59:15] <nfl> that is ugly though
[09:59:31] <mru> are you sure the reason you want this isn't ugly?
[09:59:56] <nfl> pretty sure :)
[10:03:03] <superdump> do you need to 'peek' some data for some reason?
[10:03:35] * mru can't imagine a valid reason to do that
[10:03:49] <nfl> superdump: yes, to read byte header for each frame in g723.1
[10:04:05] <nfl> umm, 2 bits of the 1st byte
[10:05:04] <nfl> perhaps there's a better way?
[10:06:51] <superdump> why do you need to peek it and not read it?
[10:07:02] <superdump> get_bits () perhaps?
[10:07:17] <mru> ByteIOContext...
[10:08:02] <superdump> but why not use a get bits context?
[10:08:28] <superdump> either use byte reading with masks and shifts or get bits
[10:08:48] <mru> I guess he's reading from a file
[10:08:59] <nfl> superdump: i'm calling get_packet in the demuxer with the size calculated from the 2 bits of the 1st byte of each frame
[10:09:04] <mru> that's what ByteIOContext does
[10:09:44] <mru> so read one byte, extract the 2 bits, then read the rest
[10:10:18] <nfl> mru: the first byte needs to be in the packet too
[10:10:28] <mru> so put it there
[10:10:53] <nfl> get_buffer() ?
[10:13:48] <nfl> ah got it now, thanks
[10:14:25] <lu_zero> yawn
[10:15:01] <lu_zero> good morning
[11:48:58] <pengvado> I have a bunch of memory that is allocated but never used. i.e. top says VIRT >> RES. is there any easy way to find out which mallocs those are from?
[11:54:00] <kshishkov> valgrind?
[11:57:04] <nfl> merbanan: ping
[11:59:24] <mt> when using the wma pro decoder, every frame within the packet is output on its own, unless it's ignored for some reason (like being the very first frame in the files or crossing the packet boundary), right ?
[12:01:08] <kshishkov> seems so
[12:35:37] <kierank> do people actually use wma pro?
[12:36:42] <kshishkov> yes
[12:37:16] <kshishkov> and please ask BBB if people use wma speech
[12:37:46] <kierank> ah wikipedia says all the microsoft services use it
[12:37:49] <kierank> (wma pro)
[12:38:08] <kshishkov> people may use it too
[12:53:46] <tetsuo--> what a coincidence, i was just talking to someone about wma audio
[14:09:54] <reynaldo> hi guys
[14:10:23] <mru> hi reynaldo
[14:10:37] <reynaldo> howdy mru, long time no see
[14:11:04] <reynaldo> we had a major earthquake around here a month or so ago, kind of a big deal
[14:11:11] <mru> yeah, I know
[14:11:18] <reynaldo> witha tsunami and all the bells and whistles
[14:11:45] <reynaldo> anyway, things are slowly geting back to normal, so am I
[14:12:08] <reynaldo> got a lot to catch on on -dev :|
[14:15:36] <mru> try not to reignite any finished flame wars
[14:16:45] <reynaldo> will keep that in mind. Guess you had a few :)
[14:17:09] <thresh> is bank wire transfer a really secure payment?
[14:17:11] <BBB> hey reynaldo, great to see you back
[14:17:20] <thresh> OT, sorry :)
[14:17:44] <BBB> wires are safe, yes
[14:17:57] <mru> well, as safe as most alternatives
[14:17:57] <reynaldo> BBB: hi there, thanks.
[14:18:26] <thresh> hehe, well. need to pay some .eu-based company for a device.
[14:18:33] <mru> brown bags with used, non-consecutive notes might be preferable in some cases
[14:18:54] <reynaldo> thresh: secure? don't know. slow? hell yes
[14:19:05] <BBB> expensive? hell yes
[14:19:18] <mru> I can do a wire transfer within the UK for free and with immediate effect
[14:19:18] <reynaldo> that too
[14:19:19] <thresh> hmm
[14:19:27] <mru> internationally it's rather grim
[14:19:34] <reynaldo> mru: I guess he is talking about overseas transfers
[14:19:36] <thresh> guess it all depends on a bank.
[14:19:59] <thresh> not overseas, but russia - cztch.
[14:20:04] <reynaldo> thats the main issue, with an international wire transfer it atually depends on at least two banks
[14:20:08] <thresh> czech :)
[14:20:13] <reynaldo> problems scale fast :)
[14:20:50] <mru> thresh: can you use IBAN?
[14:21:02] <thresh> what is it?
[14:21:09] <mru> guess the answer is no then
[14:21:16] <mru> international bank account number
[14:21:39] <mru> international == eu, .ch + a few more european countries
[14:21:43] <thresh> no idea if i has it. probably not..
[14:22:44] <thresh> i wonder how many % will my bank want
[14:23:04] <mru> my bank charges a flat fee
[14:23:10] <mru> + currency conversion commission
[14:23:27] <mru> the recipient bank may also charge
[14:23:56] <mru> it's usually cheaper to send money in your currency and let the recipient do the conversion
[14:24:40] <thresh> i somehow doubt the companu would accept RUR
[14:24:48] <thresh> company.
[14:25:27] <mru> that's not the question
[14:25:40] <mru> they're account will probably be held in euro
[14:25:49] <mru> so anything going in will be converted
[14:25:54] <thresh> think so, yeah
[14:27:58] <mru> for some reason, banks often take less commission on incoming conversion than on outgoing
[14:28:17] <mru> not that it really matters
[14:28:24] <mru> you're talking about ~2% either way
[14:28:49] <mru> then you'll have a flat fee on top of that
[14:29:13] <mru> typically 10-20 euros or equivalent
[14:30:03] <mru> when sending money, your bank will try to trick you into paying ~double fee with a promise that it will cover all fees on the receiving end
[14:30:30] <mru> the reality is that the receiving fee is usually much smaller, if there is one at all
[14:31:00] <mru> then again, if it's a lot of money, the difference is probably not huge
[14:31:36] <mru> 10 euros this way or that on a 10k transfer isn't worth the time to worry about
[14:59:31] <thresh> yeah, just checked my bank rates on that, it's 1 percent, so about 20 eur..
[15:51:45] <mmu_screen> plop
[15:51:52] <mmu_screen> mru: btw, did you plan anything for RMLL ?
[15:52:06] <mru> rmll?
[15:52:38] <mmu_screen> http://rmll.info
[15:52:56] <mmu_screen> I suppose it answers the question :)
[15:53:14] <mru> oh, that
[15:53:42] <mru> nothing planned
[15:53:58] <DonDiego> mmu_screen: btw, we're now waiting *years* for you to clean up the beos bits in configure and elsewhere..
[15:54:22] <mmu_screen> yeah I know, been waiting for years to get mru not to veto my patches :D
[15:54:28] <mmu_screen> quite busy atm
[15:54:32] <DonDiego> nonsense
[15:54:36] <mru> then I'll just delete the lot
[15:54:47] <mmu_screen> tsss
[15:54:49] <DonDiego> you keep claiming that and it's completely wrong
[15:55:21] <DonDiego> you conveniently forget that i am configure maintainer as well
[15:55:21] <mmu_screen> no it's not
[15:55:29] <mmu_screen> anyway
[15:55:36] <DonDiego> i have never seen any patches from you
[15:55:40] <mmu_screen> yes but they touch other stuff as well
[15:55:59] <mru> maybe that's the problem
[15:56:03] <mmu_screen> anyway, I'll try to come up with another solution that doesn't hack in libavutil/internal.h
[15:56:04] <DonDiego> the patches cannot have been vetoed because they never appeared
[15:56:25] <mmu_screen> I don't have time to argue or dig gmane.net
[15:57:08] <DonDiego> what's missing?
[15:57:26] <DonDiego> apparently a new haiku version was just released...
[15:57:27] <mmu_screen> all those PRI* and INT64_C crap
[15:57:36] <DonDiego> what about them?
[15:57:45] <DonDiego> it's standard posix stuff
[15:57:48] <mmu_screen> BeOS doesn't have them defined
[15:57:59] <mmu_screen> because it predates this POSIX version
[15:58:16] <mru> that means your system is unsupported
[15:58:16] <mmu_screen> Haiku should have them though I didn't check for all of them yet
[15:58:33] <mmu_screen> that means you don't want your software to be portable :p
[15:58:42] <DonDiego> bullshit
[15:58:57] <DonDiego> it means you don't want your OS to support portable software
[15:59:11] <DonDiego> how hard can it be to implement inttypes.h?
[15:59:16] <DonDiego> *once*
[15:59:37] <mmu_screen> I am *not* supposed to port my OS, but the application
[15:59:41] <DonDiego> and then magically see dozens or hundreds of apps compile on your_os_of_choice
[16:00:15] <DonDiego> you will never get anywhere with this attitude
[16:00:25] <DonDiego> why port applications one by one
[16:00:35] <DonDiego> when you can port them dozens or hundreds at a time?
[16:00:48] <DonDiego> oh wait, you're not *supposed* to be sensible
[16:00:55] <peloverde> making a stdint header will solve portability headaches for hundreds of apps
[16:01:14] <DonDiego> better continue down the road to nowhere, because it's the_way_i_have_always_worked
[16:02:04] <DonDiego> mmu_screen: you have *never* provided a single sane argument except "it's *supposed* to work that way"
[16:02:15] <DonDiego> mmu_screen: what gives?
[16:02:48] <DonDiego> mmu_screen: you're neither stupid, nor wearing your ass as hat, so ... - why?
[16:02:58] <DonDiego> why, oh why?
[16:02:59] <DonDiego> ...
[16:03:15] <mmu_screen> ...
[16:03:33] <DonDiego> and then you go mum
[16:03:42] <Dark_Shikari> http://markwadestone.files.wordpress.com/2009/10/asshat4.jpg
[16:03:44] <mru> he's a french beos user... can't get much worse :-)
[16:03:49] <DonDiego> IOW you don't have any arguments
[16:04:34] <DonDiego> also, creating portable headers is not without precedent..
[16:04:53] <DonDiego> notice that people have done it for mingw
[16:05:17] <DonDiego> you could just copy that
[16:05:23] * mmu_screen throws a pile of Minix 3 CDs at mru 
[16:05:28] <mmu_screen> (I do have them)
[16:06:00] <mmu_screen> DonDiego: yes, but I hate having to do this
[16:06:09] <DonDiego> hate what?
[16:06:14] <DonDiego> make your platform usable?
[16:06:19] <mmu_screen> bleh
[16:06:35] <DonDiego> answer me, what is it that you hate?
[16:06:51] <Dark_Shikari> babies.  that's what he hates.
[16:07:41] <DonDiego> i'm losing patience here because i've been pinging your ethereal patches for years now and all i ever hear is nonsense excuses
[16:07:55] <mmu_screen> interestingly btw, libavutil/internal.h has a lot of #ifndef INT16_MIN
[16:08:04] <mmu_screen> aren't those in POSIX either ?
[16:08:09] <mru> I'll gladly remove those
[16:08:23] <DonDiego> sometimes it's "evil trolls after my work", then it's "i absolutely want to go down the road of maximum pain"
[16:08:40] <DonDiego> never anything sane
[16:08:48] <DonDiego> plus: mru != DonDiego
[16:10:19] <peloverde> I don't know it's a fascinating theory, sure i've seen you both in the same room but a master of cybernetics or holography could totally pull it off
[16:10:49] <mmu_screen> sometimes it's "he's been trolling too much, he deserves this in return"
[16:10:57] <mmu_screen> :^)
[16:12:03] <DonDiego> another lame excuse
[16:12:45] <DonDiego> excuses, pretexts, non-sequitur arguments
[16:14:11] <Dark_Shikari> the worst way to spend one's time is to spend hours complaining about having to do something that takes 30 minutes
[16:14:22] <DonDiego> well said
[16:14:43] <Dark_Shikari> and seriously, inttypes?  that's like not having log2
[16:14:50] <Dark_Shikari> eh, worse than not having log2
[16:14:55] <Dark_Shikari> that's like not having "for"
[16:14:58] <DonDiego> mmu_screen: at least be honest and stop pretending that you maintain the beos port of ffmpeg..
[16:15:00] <Dark_Shikari> and saying "oh, but you can just use while"
[16:15:04] <peloverde> "If you don't 'git push' today, your day was a waste of time"
[16:15:22] <Dark_Shikari> peloverde: commit.  pushes should be rare, after testing is done
[16:17:01] <DonDiego> and then he went silent...
[16:17:10] <mmu_screen> DonDiego: I do
[16:17:37] <DonDiego> no, you do not
[16:17:38] <mmu_screen> you're just not making my job easy...
[16:17:50] <DonDiego> if you did, you would work, not flame and heckle
[16:18:03] <DonDiego> quit filibustering and hit the keyboard
[16:18:41] <DonDiego> i've tried to get you to continue countless times
[16:18:45] <mmu_screen> which is what I'm doing when I'm "silent"
[16:19:16] <mmu_screen> let's see if this builds...
[16:20:17] <DonDiego> you've been silent for years and flamed in between, we're talking about getting a single app to compile
[16:20:44] <DonDiego> nothing that should take you more than, say, an hour or two
[16:21:19] <DonDiego> a day or two if you type with your nose, one character per minute
[16:26:42] <mmu_screen> also depends on the compiler speed
[16:26:43] <mmu_screen> ...
[16:28:16] <DonDiego> stop talking nonsense, i work on the slowest dev machine in existence
[16:28:30] <DonDiego> we're talking about 500mhz here
[16:29:02] <mmu_screen> oh I can reinstall on my K6-2 350 if you want...
[16:29:15] <mmu_screen> anyway, seems to be building so far
[16:29:23] <mmu_screen> I'll make a patch tomorrow
[16:29:27] <mmu_screen> gtg
[16:30:28] <mmu_screen> btw, I think the split haiku case in configure was oked, I should probably commit that first
[16:30:39] <spaam> DonDiego: time to buy a new one? :)
[16:31:15] <mmu_screen> I can give him an ssh accound on my K6-2 :DDDD
[16:31:41] <spaam> 350mhz?
[16:31:52] <mmu_screen> I even have a powerpc mac clone around, probably slower
[16:32:02] <mmu_screen> yup
[16:32:15] <mmu_screen> parse error hmmm
[16:32:23] <mmu_screen> before int
[16:32:28] <mmu_screen> C89 I guess
[16:33:15] <nfl> merbanan: ping
[16:33:55] <mmu_screen> ok, all built
[16:34:11] <mmu_screen> tomorrow I'll clean up the other changes I made to make sure they are required
[16:34:14] <mmu_screen> and send a patch
[16:34:15] <mmu_screen> bbl
[16:34:24] <DonDiego> surprise me..
[16:34:42] <DonDiego> are you guys aware of anything that needs to go in 0.5.2?
[16:35:19] <mmu_screen> DonDiego: it's even in iCal :D
[16:35:23] <peloverde> what was the r# for the branch?
[16:35:52] <peloverde> r23017?
[16:37:40] <peloverde> Conrad's schroenc commits may be useful
[16:40:55] <DonDiego> what did he do?
[16:45:18] <peloverde> commits r23025-23030, things like set colorspace info, adaptive GOP by default, keyframe interval
[16:46:22] <Dark_Shikari> and make the "constant quality" mode work properly
[16:47:22] <DonDiego> Yuvi: you around?
[16:50:05] <CIA-7> ffmpeg: alexc * r23132 /trunk/libavcodec/ (aacenc.c aacpsy.c):
[16:50:05] <CIA-7> ffmpeg: aacenc: Fix psy logic.
[16:50:05] <CIA-7> ffmpeg: Set band info before determining scalefactors. Use the look ahead for
[16:50:05] <CIA-7> ffmpeg: windowing decision.
[16:50:06] <CIA-7> ffmpeg: alexc * r23133 /trunk/libavcodec/aacenc.c: aacenc: Select the TLS (two-loop search) as the default scalefactor coder.
[16:50:07] <CIA-7> ffmpeg: alexc * r23134 /trunk/libavcodec/aaccoder.c: aacenc: Use an estimated codebook for the TLS (two loop search).
[16:50:08] <CIA-7> ffmpeg: alexc * r23135 /trunk/libavcodec/ (aaccoder.c aacenc.h):
[16:50:08] <CIA-7> ffmpeg: aacenc: Use exact values when quantizing, not fuzzy values.
[16:50:08] <CIA-7> ffmpeg: This requires us to code small escapes; we can't avoid it.
[16:50:46] <CIA-7> ffmpeg: alexc * r23136 /trunk/libavcodec/aaccoder.c: aacenc: Add a rate only trellis for codebook selection for the TLS.
[16:51:05] <peloverde> Dark_Shikari, ABR AAC at ~64k/channel should now suck significantly less
[16:51:09] <Dark_Shikari> Awesome
[16:51:12] <Dark_Shikari> comparison to FAAC?
[16:51:20] <pJok> what? someoone fixed ffaacenc?
[16:51:37] <peloverde> fixed is a relative term
[16:51:54] <pJok> anything making it better than what it was is fixing
[16:53:29] <peloverde> I haven't spent too much time comparing it to faac, I've mostly just been comparing it to it old self and using nero for cues about the "right way" to handle certain situations
[16:54:24] <BBB> peloverde: \o/
[17:34:55] <Yuvi> DonDiego: pong
[18:06:31] <DonDiego> Yuvi: are you libschro commits 0.5 branch matter?
[18:07:51] <DonDiego> anyway, i gtg now, talk to you later or send me an email
[18:07:53] <DonDiego> bye
[18:28:46] <j-b> who is looking for a job around here, btw ?
[18:29:07] <mru> what can you offer?
[18:29:13] <mru> not that I have time for any more work atm
[18:30:18] <j-b> not a contractor job, I believe
[18:30:46] <mru> if you provide more details, you'll have better chance of someone picking it up
[18:31:28] <j-b> I was just wondering if there were some people unemployed or soon-finishing-univ now around FFmpeg
[18:43:21] <peloverde> j-b, there are but without any details you probably aren't going to attract a lot of attention
[18:43:32] <Dark_Shikari> +1
[18:44:46] * BBB adds a metoo
[18:45:32] <Dark_Shikari> oh, and on the topic of that h265 encoder test I was doing
[18:45:38] <Dark_Shikari> apparently the Intel proposal is even slower
[18:45:42] <Dark_Shikari> 500 times slower than the reference
[18:46:15] <BBB> but is that intrinsic slowness or can it be optimized?
[18:46:25] <BBB> as in, could intel release cpu extensions to alleviate that?
[18:46:26] <Dark_Shikari> intrinsic.  well, I mean, obviously if it used less stupidly slow algorithms
[18:46:35] <BBB> that's the whole point
[18:46:36] <Dark_Shikari> but given the stupidly slow algorithms they use, they're intrinsicly slow
[18:46:39] <BBB> can the algo be optimized?
[18:46:56] <Dark_Shikari> algos like samsung-bbc's "search every quantizer for every single permutation of hierarchical block types"?
[18:47:02] <Dark_Shikari> sure, by NOT DOING THAT
[18:49:08] <mru> aka use some heuristic
[18:52:37] <CIA-7> ffmpeg: mstorsjo * r23137 /trunk/configure: Change inter-protocol dependencies from _deps to _select
[18:56:48] <j-b> peloverde: If I could, I would.
[19:07:57] <_av500_> mru: its a job doing stuff with things of course
[19:12:53] <_av500_> Dark_Shikari: what about "try every possible valid bitstream sequence and select the one that happens to encode the wanted image with the least bits"?
[19:13:46] <BBB> that's h267
[19:14:02] <_av500_> not h666?
[19:14:21] <BBB> lands you straight in hell666
[19:14:31] <j-b> Dark_Shikari: so h265 is still faaaaaaar faaaaaaaaaar faaaaaaaaaaar away ?
[19:14:47] <mru> a few years at least
[19:14:58] <_av500_> j-b: no need for that "mkdir x265" now...
[19:15:11] <Dark_Shikari> _av500_: better
[19:15:14] <Dark_Shikari> try every possible program
[19:15:21] <Dark_Shikari> and select the one which encodes the image with the fewest bits
[19:15:34] * _av500_ order a million monkeys...
[19:15:39] <Dark_Shikari> Put a cap on the runtime, of course, to make it merely EXPTIME as opposed to halting-problem-hard
[19:15:40] <j-b> genetic algo
[19:16:03] * _av500_ never experienced a halting problem....
[19:17:14] <mru> that was just too funny
[19:17:41] <BBB> I can see how some fucked up implementation would use a macro instead of static inline
[19:18:02] <BBB> and do result=MIN(program_a(), program_b(), program_c());
[19:22:53] <Dark_Shikari> that would still be EXPTIME
[19:24:48] <BBB> only if any of the results generates that
[19:24:53] <BBB> what if the results take finitely long?
[19:25:04] <BBB> 1+1+2.5hrs then becomes 1+1+1+2.5hrs
[19:25:08] <BBB> that's another 1 hour
[19:25:09] <Dark_Shikari> it's still EXPTIME
[19:25:14] <BBB> well yeah
[19:25:17] <BBB> but more
[19:25:25] <Dark_Shikari> running an EXPTIME program an exponential number of times is still EXPTIME
[19:25:39] <BBB> I don't do math like that
[19:25:44] <BBB> for me, math has numbers and logic in it
[19:26:04] <Dark_Shikari> no, that isn't math
[19:26:04] <mru> that's not maths, it's complexity theory
[19:26:08] <Dark_Shikari> numbers are arithmetic, not math
[19:26:10] <Dark_Shikari> =p
[19:26:11] <BBB> I barf at statisticians that pride in their sigma and their mu
[19:26:28] <Dark_Shikari> actually, that would have been 2-EXPTIME
[19:26:32] <Dark_Shikari> running an EXPTIME program an exp number of times
[19:26:43] <Dark_Shikari> interesting, EXPSPACE is a subset of 2-EXPTIME
[19:34:19] <BBB> mru: there's still the outstanding question of whether FFMAX() is faster than a typed max() math function
[19:34:29] <BBB> mru: which I admittedly failed to address properly
[19:35:15] <mru> there's no inherent reason for any difference at all
[19:35:45] <peloverde> sometimes you wind up with different generated code because of implicit float casts, but not in this case
[19:36:15] <mru> are the values all float to begin with?
[19:36:28] <Dark_Shikari> it would be nice to have a C-like language with haskell type semantics on compile-time
[19:36:28] <peloverde> in this case they are
[19:36:34] <Dark_Shikari> i.e. no actual difference in compiled asm
[19:36:42] <Dark_Shikari> but the ability to have strong typing and smart typing
[19:36:47] <Dark_Shikari> e.g.
[19:37:05] <Dark_Shikari> type max( type x, type y )
[19:37:08] <mru> but I like to xor my floats with pointers...
[19:37:12] <Dark_Shikari> which takes any x and y of the same type
[19:37:17] <Dark_Shikari> and returns the same type
[19:37:27] <Dark_Shikari> mru: it could be overridable type semantics
[19:37:33] <Dark_Shikari> e.g. you can override the strong typing with explicit casts if youw ant.
[19:37:35] <Dark_Shikari> *want
[19:38:18] <Dark_Shikari> the really great thing about haskell type semantics is that they don't place any runtime requirements on, well, anything
[19:38:22] <mru> bonus points if you can abuse low bits of pointers to hold some extra information
[19:38:26] <Dark_Shikari> so they can be implemented entirely in a compiler
[19:38:32] <Dark_Shikari> mru: then create a type for that
[19:38:40] <Dark_Shikari> PointerWithExtraBits
[19:38:53] <Dark_Shikari> make a function (always inlined, of course) that returns extra information from it
[19:38:58] <Dark_Shikari> etc
[19:39:06] <CIA-7> ffmpeg: alexc * r23138 /trunk/libavcodec/aaccoder.c: fmaxf -> FFMAX to fix pre-C99 systems
[19:40:43] <BBB> I had to add that to the wiki quotes page
[19:40:52] <peloverde> personally I find fmaxf more aesthetically pleasing ;-P
[19:41:26] <BBB> a function has the pleasing side-effect of not calculating the argument twice
[19:41:37] <BBB> FFMAX(x-y, z); calculates the minus twice
[19:41:47] <BBB> I've always found it odd that it was a macro, not a static inline
[19:42:02] <Dark_Shikari> static inline would require it being typed
[19:42:06] <BBB> true
[19:42:26] <BBB> no optimal solution out there I guess :( ohwell shall we recode ffmpeg in haskell then?
[19:42:45] <Dark_Shikari> does C++0x have inferred types?
[19:42:55] <Dark_Shikari> if so, borrow that one feature, ban the rest of the language
[19:43:06] <Dark_Shikari> haskell has much better syntax than anything C++-derived though.
[19:43:13] <Dark_Shikari> having to make classes to define types kinda sucks
[19:43:51] <Orphis> Do someone has any recommandation to give when making a new demuxer format ?
[19:44:43] <BBB> Orphis: use matroska?
[19:45:16] <Orphis> Well adding a new demuxer to ffmpeg, sorry, not creating a brand new format
[19:45:20] <Dark_Shikari> for what format
[19:45:57] <Orphis> http://wiki.multimedia.cx/index.php?title=PSMF
[19:46:42] <Dark_Shikari> that's just MPEG-PS
[19:47:01] <Dark_Shikari> so any "demuxer" should probably be a thin wrapper around ps
[19:48:53] <Orphis> Alright
[20:22:25] <wbs> mru: i noticed that if_any config items can fail to be enabled if the if_any items are enabled after the main item is enabled
[20:22:31] <wbs> that is, if I do e.g. --disable-demuxers --disable-muxers --enable-muxer=(whatever) that enables a demuxer implicitly through a _select, CONFIG_DEMUXERS doesn't get set
[20:23:08] <wbs> this particular case can be fixed by shuffling the order that check_deps is done, but that doesn't feel like a sane solution
[20:53:56] <dezodorant> hi
[20:54:18] <dezodorant> broken build detected
[20:54:31] <dezodorant> http://pastebin.org/237095
[21:16:05] <mru> in b4 the script
[21:20:55] <bcoudurier> no script today
[22:04:01] <hyc> the ffserver docs could use some fleshing out... is an ffm feed supposed to only contain raw audio/video?
[22:04:30] <hyc> all the examples I've seen show ffmpeg reading from e.g. a camera and outputtting to the ffm
[22:05:22] <hyc> I'm trying to grab an rtmpe stream and server it over rtsp
[22:05:32] <CIA-7> ffmpeg: bcoudurier * r23139 /trunk/libavformat/utils.c:
[22:05:32] <CIA-7> ffmpeg: Change MAX_READ_SIZE message during av_find_stream_info to DEBUG level.
[22:05:32] <CIA-7> ffmpeg: It is not harmful and it scares too many users.
[22:06:22] <hyc> the rtmpe stream is flv H.264MP 512x288. I need it transcoded to H.264BP 480x272. that usually isn't a problem
[22:06:44] <hyc> but I don't know if I should do this on the ffmpeg input side, or in the ffserver config
[22:07:52] <hyc> and I seem to be doing something wrong anyway, because I always get an error message "AAC with no global headers is currently not supported"
[22:08:01] <hyc> that shows up when an rtsp client tries to connect
[22:08:58] <hyc> (the audio track is aac)
[22:10:44] <hyc> will ffserver take input from an arbitrary URL? if so I guess I could have it read the rtmpe URL instead of relaying thru ffmpeg first
[22:48:31] <nefrir> hi, I am looking for someone that can explain a bit more the non reindent rule (when commiting)
[22:48:37] <nefrir> when does it applies exactly ?
[22:48:49] <Dark_Shikari> generally if it's more than a couple lines, don't
[22:48:54] <nefrir> only for a bunch a lines untouched ?
[22:48:57] <Dark_Shikari> i.e. if it's enough to make the patch unclear
[22:49:08] <Dark_Shikari> if it's just a couple, you can wing it
[22:49:43] <nefrir> http://pastebin.org/237249 vs http://pastebin.org/237251
[22:49:54] <nefrir> I think http://pastebin.org/237251 is better and should be ok
[22:49:56] <nefrir> but ...
[22:50:24] <Dark_Shikari> I like http://pastebin.org/237249
[22:50:43] <Dark_Shikari> but we should probably get feedback from someone who isn't me
[22:50:47] <nefrir> mmh actually I messe up , it's the opposite I mean
[22:51:02] <nefrir> k, will go with it
[22:51:25] <nefrir> the thing is I reindent but also change the variable in it
[22:51:40] <nefrir> so IMHO it can be commited at the same times but ...
[22:52:11] <nefrir> (as I don't really understand the rationnal when commiting...)
[22:56:43] <nefrir> non reindented is more like: http://pastebin.org/237278
[23:09:14] <CIA-7> ffmpeg: fenrir * r23140 /trunk/libavcodec/dxva2_h264.c:
[23:09:14] <CIA-7> ffmpeg: Fixed h264 long term support with dxva2 AVHWAccel.
[23:09:14] <CIA-7> ffmpeg: Based on a commit for vaapi(r22869).
[23:10:01] <CIA-7> ffmpeg: fenrir * r23141 /trunk/libavcodec/dxva2_h264.c: Reindent after last commit on dxva2 h264 AVHWAccel.
[23:14:09] <nefrir> mmh using dxva2/vaapi/vdpau is complex
[23:14:23] <nefrir> they could have done the parsing themselves
[23:21:24] <bcoudurier> nefrir, when the block to reindent is big
[23:21:27] <bcoudurier> don't
[23:21:54] <bcoudurier> like adding if () { many lines untouched } else { your code }