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

[irc at mansr.com]

[00:22:55] <CIA-17> ffmpeg: michael * r21694 /trunk/libavcodec/h264_direct.c: Reorder and factorize mb_type ifs, 1 cpu cycle faster and simpler.
[00:24:25] <astrange> 1?
[00:44:46] <Dark_Shikari> 1? lol
[00:48:49] <Honoome> mru: so right now the metadata handling has an hash table in libavformat… could we get that to use a general implementation in libavutil to make it usable by libnemesi, pretty please? :D
[00:50:04] <Honoome> and after this request (checked on ffmpeg's code this morning with Luca, I got home about at 2300), I think I'll resume the usual schedule: shower, then bump, hack, do stuff a bit, then sleeeep ^^;;
[04:57:22] <Dark_Shikari> I think elecard's decoder may have eclipsed quicktime as the most buggy h264 decoder
[04:57:44] <Dark_Shikari> I'm up to at least the 5th bug found just through x264 streams
[04:58:11] <Dark_Shikari> someone should make a stream analyzer that uses libavcodec, so that it isn't as broken
[05:01:49] <Compn> you still test quicktime? :P
[05:02:49] <Dark_Shikari> no
[06:39:30] <Dark_Shikari> michael posted a response to IRC on the ML
[06:39:31] <Dark_Shikari> how many known sec holes does 0.5 have?
[06:39:31] <Dark_Shikari> do you guys want to backport all security fixes or just release a 0.5.1
[06:39:32] <Dark_Shikari> with 12 months of unfixed secholes?
[06:39:40] <Dark_Shikari> siretart: ^
[07:16:28] <benoit-> hej
[07:16:34] <kshishkov> hejsan
[07:39:40] <siretart_> Dark_Shikari: I just wrote michael a private mail, asking for a few more days. I'm not really available today
[07:39:56] <Dark_Shikari> I think he's asking which one you intend to do
[07:40:47] <siretart_> the one that I already have in the package?
[07:41:03] <siretart_> in fact, there is about a dozen of patches
[07:51:45] <superdump> is this re: michael's re to the irc log?
[07:51:53] <Dark_Shikari> yes
[07:51:57] <superdump> about backporting sec fixes
[07:56:10] <CIA-17> ffmpeg: kostya * r21695 /trunk/ (8 files in 3 dirs): Indeo 5 decoder
[07:56:31] <superdump> \o/
[07:56:58] <Dark_Shikari> \o/
[07:57:00] <superdump> today is a truly great day
[07:57:03] <superdump> :)
[07:57:17] <superdump> i remember all those years ago when i actually wanted to decode indeo 5
[07:57:22] * kshishkov goes to update issue 142
[07:57:27] <Dark_Shikari> it's still the second most popular missing video format in ffmpeg
[07:57:38] <kshishkov> same with me, but it turned out I wanted more to decode Indeo 4
[07:57:43] <superdump> i don't remember what it was actually used for
[07:58:13] <astrange> oh, i meant to write a comment about the bink decoder, but i forgot it
[07:58:30] <astrange> i think it was about if(get_bits1(&gb)) x = -x;
[08:00:56] <kshishkov> I've just looked at it, seems fine
[08:01:16] <astrange> it seemed like it could be branchless
[08:01:35] <Dark_Shikari> int bit = get_bits1(&gb);
[08:01:44] <Dark_Shikari> x = (x + bit) ^ bit; or something similar
[08:01:48] <Dark_Shikari> forgot the exact sequence
[08:02:30] <kshishkov> it can - get_bits1() * 2 - 1
[08:02:38] <kshishkov> and multiply by x
[08:03:00] <Dark_Shikari> slower
[08:03:03] <Dark_Shikari> my method is two ops
[08:03:12] <Dark_Shikari> it's the same method as absolute value
[08:03:14] <Dark_Shikari> conditional negation
[08:03:21] <Dark_Shikari> x = (x - sign) ^ sign;
[08:03:23] <Dark_Shikari> is absolute value
[08:03:39] <Dark_Shikari> oh, you have to do "int bit = -get_bits1(&gb);"
[08:03:48] <Dark_Shikari> since "sign" must be -1 if negative, 0 if positive
[08:03:54] <Dark_Shikari> so that's three ops
[08:03:58] <Dark_Shikari> negate, subtract, xor.
[08:04:09] <kshishkov> isn't -x = ~x + 1 ?
[08:04:33] <Dark_Shikari> that's how the trick works
[08:04:46] <Dark_Shikari> (x - sign) ^ sign
[08:04:50] <Dark_Shikari> if sign == 0, it == x
[08:04:56] <Dark_Shikari> if sign == -1, (x + 1) ^ -1
[08:05:00] <Dark_Shikari> which results in ~x + 1
[08:05:06] <astrange> too bad there's an fp copysign() but not an integer one
[08:05:14] <kshishkov> it should be other way around - x^sign - sign
[08:05:42] <kshishkov> calculate it for x = 1 for example
[08:06:48] <Dark_Shikari> (x - sign) ^ sign
[08:06:53] <Dark_Shikari> (x - -1) ^ -1
[08:06:59] <Dark_Shikari> (0) ^ -1
[08:07:00] <Dark_Shikari> -1
[08:07:01] <Dark_Shikari> correct.
[08:07:13] <kshishkov> x - -1 = 2
[08:07:27] <Dark_Shikari> er, then it's (x+sign)^sign.
[08:08:24] <kshishkov> that could work
[08:09:34] * kshishkov suspects that in Bink video decoder performance would be #1 priority
[08:10:32] <Dark_Shikari> I would say compatibility is
[08:10:38] <Dark_Shikari> we don't intend to provide a replacement for bink's libraries
[08:10:43] <Dark_Shikari> for games, etc
[08:14:00] <kshishkov> but at least one engine uses it alreadt
[08:14:03] <kshishkov> *already
[08:14:22] <KotH> salut!
[08:14:22] <Dark_Shikari> isn't that rather pointless?
[08:14:32] <Dark_Shikari> assuming bink owns patents, games will probably still want to buy the royalty
[08:14:36] <Dark_Shikari> er, buy the license
[08:14:41] <Dark_Shikari> at which point there's no benefit gained by not using official software
[08:15:03] <kshishkov> I mean opensource recreation of game engine
[08:15:16] <Dark_Shikari> ah.
[09:20:15] <jez999> pross-au: now i'm thinking of implementing the source address limitation by adding it to the URL in string form
[09:20:26] <jez999> like "file.sdp?sourceaddr=1.2.3.4&sourceaddr=2.3.4.5
[09:20:27] <jez999> "
[09:21:31] <pross-au> rgr
[09:21:38] <pross-au> thats another optiom
[09:21:44] <pross-au> *option
[09:31:37] <jez999> apparently more platform-independent
[10:49:55] <mru> morning
[10:50:40] <kshishkov> god engelsk morgon
[10:51:16] <benoit-> good morning
[12:01:49] <ramiro> siretart: ping
[13:55:07] <jez9999> this place is a morgue today
[13:59:32] <_av500_> let the dead rest in piece
[14:00:07] <mru> rest in pieces?
[14:00:14] <_av500_> mru: ys
[14:00:21] <mru> pisces?
[14:00:56] <_av500_> yuck
[14:01:17] <kshishkov> depends on if you are in astrology or Quake
[14:02:03] <_av500_> or a fishmonger
[14:05:11] <mru> in swedish "the fishes" and "the fishermen" have the same translation
[14:05:19] <mru> "fiskarna"
[14:06:04] <kshishkov> "far, f\aar f\aar f\aar? nej, f\aar f\aar lamm"
[14:07:10] <mru> "buffalo buffalo buffalo buffalo buffalo buffalo buffalo buffalo"
[14:07:13] <mru> add punctuation
[14:07:27] <_av500_> ,.,.!?1
[14:07:41] <kshishkov> IIRC, some of the b's were capital
[14:08:03] <_av500_> mru: guess what, gg writes their own media fw....
[14:08:13] <mru> "dogs dogs dog dog dogs"
[14:08:37] <_av500_> patches patchesp patches patches
[14:09:05] * kshishkov thinks it will reduce to "developers developers developers"
[14:09:14] <thresh> ехал гитлер через гитлер
[14:15:20] <KotH> kshishkov: but you'd have to jump around and shout for 5 min
[14:15:46] <kshishkov> KotH: not me
[14:15:49] <kierank> who said sit down!
[14:16:36] <kshishkov> throw a chair!
[14:16:52] * KotH throws Jag0 trough the channel
[14:18:34] <kshishkov> do you know him?
[14:18:45] <KotH> no
[14:18:47] <mru> now he knows KotH...
[14:18:56] <kshishkov> or just testing how far you can trust him?
[14:18:57] <KotH> do i have to know him to be able to throw him?
[14:19:09] * KotH doesnt trust anyone
[14:19:48] <kshishkov> and you are rumored to have visited MN
[14:20:07] <KotH> i never acknowledeged it
[14:20:13] <KotH> and i never said i trust mn
[14:20:42] <_av500_> KotH: jihad, jihad, jiahd?
[14:21:45] <KotH> _av500_: nope
[14:21:55] <KotH> _av500_: JIHAD! JIHAD! JIHAD!
[14:21:56] <KotH> ;)
[14:21:58] <_av500_> right
[14:22:28] * KotH did that once at a party
[14:22:33] <KotH> after that, everyone knew me :)
[14:22:39] * kshishkov remind KotH that Turks were always afraid of Ukrainians
[14:22:44] <jai> way to break the ice...
[14:22:57] <KotH> kshishkov: afraid? i doubt so
[14:23:13] <KotH> kshishkov: but who wants a country that's in worse state than iraq?
[14:24:31] <kshishkov> KotH: it was since Turkey foundation and till XVIIth century, I think
[14:28:11] <benoit-> KotH: and you wonder why I don't want you at my wedding :)
[14:28:39] <_av500_> benoit-: the turks bring a lot of gold to weddings
[14:28:52] <KotH> benoit-: lol
[14:29:35] <kshishkov> _av500_: too bad those Turks hhaven't heard of that
[14:30:08] <_av500_> at least they bring schoggi
[14:30:25] <mru> _av500_: gold... hmm, might invite KotH to mine then, if it ever happens
[14:30:27] <kshishkov> kebab
[14:30:38] <kshishkov> mru: too gold mine
[14:30:42] <kshishkov> *to
[14:30:45] <_av500_> mru: gold plated DB9?
[14:31:13] <mru> you said "a lot"
[14:31:23] <KotH> gold plated db25?
[14:31:28] <drv> lol
[14:32:03] <drv> must be sure to buy an aston marton serial port for my next box
[14:32:12] <kshishkov> a simple 100g gold bar is enough
[14:32:18] <KotH> mru: and you cannot complain, with all the schoggi you got :)
[14:32:57] <KotH> kshishkov: i'd send you one, if i could make sure it would reach you and not got.. "displaced" at customs
[14:33:30] <kshishkov> KotH: send me a swiss resident permit instead
[14:36:45] <_av500_> kshishkov: it is called "a million dollar" and might be hard to send to you as well
[14:37:14] <kshishkov> _av500_: there should be other ways
[14:37:52] <kshishkov> if I had $1m I could apply as political refuge
[15:02:23] <_av500_> kshishkov: if you had $1m you could apply as anybody :)
[15:05:31] <kshishkov> _av500_: it's next to impossible to earn that kind of money here and not be tangled into politics
[15:11:43] <mru> well, go buy some red tape and get started
[15:13:10] <KotH> _av500_: well.. i dunno how it is in .de, but in .ch someone with $1m is considered poor ;-)
[15:14:16] <twnqx> in .de it's RICHFAG
[15:14:24] <twnqx> because, you know, taxes :P
[15:15:07] <KotH> twnqx: taxes?
[15:15:17] <mru> if you have that kind of money you don't pay taxes
[15:15:18] <twnqx> exactly.
[15:15:19] <KotH> twnqx: i thought every german has an account in .ch? :)
[15:15:25] <twnqx> well *i* do
[15:15:31] <_av500_> KotH: could you ask if i am on the CD?
[15:15:44] <KotH> _av500_: i'm not data broker ;)
[15:16:08] * KotH only deals in money, weapons, women and drugs
[15:16:20] <twnqx> one nuclear warhead, please
[15:16:33] * KotH doesnt sell these
[15:16:45] <twnqx> :(
[15:16:45] <_av500_> twnqx: ask kshishkov, he is closer to them
[15:16:54] <KotH> i wouldnt want to give anyone something that might kill all my prospective customers, would i?
[15:24:45] <jez9999> BBB: hey
[15:28:05] <kshishkov> twnqx: ask thresh, he is the closest to them
[15:28:47] <thresh> i know a guy who knows a guy who knows another guy and i think we can make a deal
[15:29:18] <kshishkov> otherwise, you can always buy one at North Korea, ask mru for help
[15:30:13] * mru doesn't know any north koreans
[15:30:36] <kshishkov> well, you know south koreans
[15:31:20] <mru> they're not allowed anywhere near the border
[15:31:20] <_av500_> only need to s/nor/sou/
[15:31:28] <KotH> or just go diving in florida
[15:31:49] <KotH> there is still a bomb liying there, waiting to be found
[15:31:49] <jez9999> BBB: slight problem with the idea of putting valid source IP(s) in the URI's query string.  not all URIs support query strings. :-)
[15:32:48] <BBB> jez9999, ?
[15:32:58] <jez9999> most problematically, file:
[15:33:04] <BBB> you mean http://uri?opt=x would be problematic?
[15:33:05] <BBB> we know that
[15:33:07] <BBB> it sucks
[15:33:18] <mru> jez9999: files don't have a source address
[15:33:19] <BBB> I've been sitting on a solution for that for a while, and it's not done yet
[15:33:22] <mru> so why does it matter?
[15:33:28] <jez9999> they do if they represent a stream (sdp) :-)
[15:33:33] <mru> eh?
[15:33:44] <jez9999> sdp demuxer parses the sdp file and opens a udp port
[15:33:49] <BBB> mru: sdp files is a "hack" for rtsp without the manager connection
[15:33:56] <mru> omg
[15:33:56] <BBB> mru: it's quite common, even apple does it
[15:34:19] <BBB> think of sdp as rtsp without the rtsp control connection
[15:34:42] <BBB> it sucks major ass, and he's having problems with it that are common for this kind of ... hack? :)
[15:34:52] <BBB> but we'll support it someday
[15:34:56] <BBB> (we already do)
[15:35:00] <BBB> (but not perfectly)
[15:36:42] <jez9999> i'm thinking that reverting to plan C is the last bad option
[15:36:52] <jez9999> specify valid source address(es) in AVFormatContext
[15:37:02] <jez9999> s/last/least/
[15:38:05] <mru> when something seemingly trivial doesn't have an obvious solution you're usually looking in the wrong place
[15:38:28] <jez9999> i didnt say it was seemingly trivial
[15:38:41] <mru> filtering by source address is seemingly trivial
[15:38:56] <jez9999> not when the ffmpeg developers are anal about what goes in the API :-)
[15:39:01] <mru> if it doesn't seem that way to you, you're probably doing the wrong thing
[15:39:33] <jez9999> i already have a workable solution... in proof-of-concept
[15:39:42] <jez9999> that's how trivial it is
[15:40:03] <mru> but an incorrect one
[15:40:09] <jez9999> bleh
[15:40:31] <BBB> jez9999, I won't accept that either
[15:40:35] <BBB> jez9999, it's too complicated
[15:41:01] <BBB> I don't want a list of source IPs in avformatcontext, or worse yet, a source ip in avpacket
[15:41:20] <BBB> if the sdp lacks information that rtsp has (ssrc, or source ip), then we should add that to the sdp
[15:41:28] <BBB> if it's not part of sdp, then add it to the uri containing the sdp
[15:41:32] <BBB> seems pretty simple to me
[15:41:36] <jez9999> so what, we invent a new RFC for SDP then? :-)
[15:41:50] <BBB> I don't want to bloat avformatcontext with stuff that's wrong just in sdp
[15:41:51] <jez9999> the uri containing the SDP does not support a mechanism to do that
[15:42:09] <BBB> I'd like to enhance the sdp RFC
[15:42:17] <BBB> if you look on google, several people have asked about this
[15:42:26] <jez9999> heh
[15:42:32] <BBB> (look for ssrc sdp collision, for example)
[15:42:43] <BBB> it's apparently a common theme
[15:42:53] <jez9999> so all that needs to be done is go through the whole process of composing, submitting, and getting accepted a new SDP RFC
[15:43:08] <jez9999> well im sure it's the technically correct ideal but there's no way i have that kind of time or manpower to get it implemented
[15:43:55] <jez9999> i'm not RealNetworks
[15:44:16] <kshishkov> why do you mention that name?
[15:44:30] <jez9999> just strikes me as a company that would have the time and inclination to do that
[15:44:35] <jez9999> if they needed to
[15:45:02] <mru> lol
[15:45:15] * kshishkov strongly dislikes Buffering Inc.
[15:45:22] <mru> the realnetworks solution is to drop all packets and display "Buffering..."
[15:45:54] <kierank> you forgot about opening the Real MessageCentre (TM)
[15:46:17] <jez9999> anyway your assertion is that the only acceptable solution is a revised SDP RFC, right?
[15:46:23] <jez9999> any devs around that don't think that?
[15:46:34] <jez9999> if not, i'll try and get a more sane patch into Xuggler
[15:49:58] <kshishkov> then you should stalk for aclarke, not BBB
[15:50:11] <jez9999> i know, im just asking ffmpeg devs first
[15:50:13] * mru counter-stalks aclarke
[15:50:54] <_av500_> mru: I managed to show the videowall to key ti ppl here in nice, inside one of their demos :)
[15:51:30] * mru looks around... beagles are still here...
[15:51:45] <BBB> jez9999, ???
[15:51:45] <kshishkov> _av500_: thanks for saving them money on advertising
[15:51:47] <BBB> I never said that
[15:51:51] <_av500_> well, they saw the utube video :)
[15:51:58] <BBB> jez9999, I said, add a ?opt=val to the sdp file
[15:52:07] <BBB> 99% of the time, you'll be reading the sdp file locally
[15:52:08] <merbzt> _av500_: where did you get all the screens ?
[15:52:09] <jez9999> 'to the file'?
[15:52:16] <jez9999> you mean inside the file?
[15:52:21] <BBB> I'm aware that for http, that might not work, but I'm aware of that issue and in the process of fixing it
[15:52:22] <_av500_> merbzt: no, i showed them the utube video
[15:52:24] <BBB> no, as part of the uri string
[15:52:33] <BBB> ./ffplay file.sdp?opt=val
[15:52:41] <jez9999> how does that work for file:/path/to/file.sdp
[15:52:41] <jez9999> ?
[15:52:41] <_av500_> they wanted to demo android utube player over 3g, i entered the right url for them :)
[15:52:53] <BBB> or xuggler: av_open_input_file("file://file/file.sdp?opt=val");
[15:53:01] <mru> _av500_: well played
[15:53:03] <_av500_> so, it was a demo inside a demo
[15:53:04] <BBB> maybe I'm missing a / there
[15:53:12] <merbzt> but at FOSDEM
[15:53:20] <merbzt> where did you get those ?
[15:53:20] <jez9999> BBB: as far as i can tell, the file protocol handler expects file:/path/to/file.sdp
[15:53:28] <jez9999> BBB: if file: is missing, it adds it
[15:53:30] <_av500_> merbzt: i brought them there
[15:53:36] <merbzt> ok
[15:53:37] <jez9999> so you can say /path/to/file.sdp
[15:53:38] <_av500_> in all their 60pounds glory
[15:53:48] <BBB> jez9999, yes
[15:53:59] <jez9999> then it passes that through to open(), which doesnt like a query string being at the end
[15:54:13] <mru> easy to fix
[15:54:14] <jez9999> nor should it.  in the URL RFC, file: isn't meant to have query strings
[15:54:21] <jez9999> so it would be incorrect to support thewm
[15:54:23] <jez9999> them
[15:54:25] <_av500_> merbzt: I had 5 unused in the office and one from ebay
[15:56:01] <BBB> jez9999, I'm aware of all that. but it works, and we're trying to separate string "options" from the uri, but that's not done yet
[15:56:05] <BBB> so for now, it's ok to do that
[15:56:26] <jez9999> it doesnt work... where is the code that separates out the query string for file: URIs?
[15:56:43] <BBB> you would add it to the sdp handler?
[15:56:59] <jez9999> the sdp handler doesn't get invoked, the file protocol handler fails
[15:57:17] <BBB> hm, I guess the file doesn't exist... crap, this is how rtsp fixes these issues
[15:57:26] <BBB> ok, then go fix that bug also then as part of this bug ;)
[15:57:50] <jez9999> except that that 'bug' is a correct implementation of RFC 1738 :-)
[15:57:50] <BBB> I will, again, not accept new stuff being added to avformatcontext specifically for source ips
[16:00:06] <jez9999> if the SDP and URL RFCs provide no mechanism to pass this data through, the logical conclusion would be that ffmpeg needs to provide its own mechanism
[16:00:14] <jez9999> not that you break RFC 1738
[16:00:39] <mru> or that the rfc is broken
[16:00:56] <jez9999> possibly
[16:04:33] <mattg> mru: i've been using libavcodec on arm (iphone 3gs, so has neon) and am getting green frames when there's "too many reference frames" errors, but plays fine when compiled with --disable-asm and also plays fine on x86 ffmpeg. have you come across this at all?
[16:04:39] <jez9999> how long until ffmpeg accepts passing options separately from the URI?
[16:04:58] <mru> mattg: I don't have an iphone, so no ;-)
[16:05:15] <mattg> have you seen it on any neon device though?
[16:05:19] <mru> no
[16:05:44] <mattg> gcc has issues with stack alignment on arm, could it be related do you think?
[16:05:45] <mru> do you get those error messages even when it displays correctly?
[16:05:49] <mattg> yes
[16:06:05] <mattg> exactly the same error messages
[16:06:09] <mru> do you have a sample file I could try?
[16:06:29] <mattg> yes i can provide one - let me try and create a decent one for you
[16:06:35] <mattg> where should i mail to?
[16:07:00] <mru> upload as per the bugreports page
[16:07:15] <mattg> ok sure
[16:08:10] <jez9999> BBB: what're some examples of other protocol-specific options passed via a query string?
[16:08:15] <mattg> mru: thankyou
[16:11:00] <BBB> jez9999, rtsp://bla?tcp is one
[16:11:12] <BBB> to force rtsp/tcp instead of the default rtsp/udp
[16:11:21] <BBB> I might've broken that
[16:11:26] <BBB> but that's the general idea of how to make it work
[16:13:03] <jez9999> lol
[16:13:21] <jez9999> how long until ffmpeg accepts passing options separately from the URI?
[16:13:27] <jez9999> that would render this hack obsolete
[16:13:32] <BBB> whenever I have time?
[16:13:38] <BBB> you can fund me </hint>
[16:13:51] <BBB> nobody else but me has volunteered to do that one, so far at least
[16:14:13] <CIA-17> ffmpeg: mru * r21696 /trunk/libavcodec/arm/ (dsputil_init_armv6.c dsputil_armv6.S): ARMv6 optimised put_pixels functions except xy2 variants
[16:14:13] <CIA-17> ffmpeg: mru * r21697 /trunk/libavcodec/arm/ (dsputil_init_armv6.c dsputil_armv6.S): ARMv6 optimised pix_abs16
[16:14:14] <CIA-17> ffmpeg: mru * r21698 /trunk/libavcodec/arm/ (dsputil_init_armv6.c dsputil_armv6.S): ARMv6 optimised pix_abs16_x2
[16:14:15] <CIA-17> ffmpeg: mru * r21699 /trunk/libavcodec/arm/ (dsputil_init_armv6.c dsputil_armv6.S): ARMv6 optimised pix_abs16_y2
[16:14:15] <CIA-17> ffmpeg: mru * r21700 /trunk/libavcodec/arm/ (dsputil_init_armv6.c dsputil_armv6.S): ARMv6 optimised pix_abs8
[16:14:15] <CIA-17> ffmpeg: mru * r21701 /trunk/libavcodec/arm/ (dsputil_init_armv6.c dsputil_armv6.S): ARMv6 optimised get_pixels
[16:14:16] <CIA-17> ffmpeg: mru * r21702 /trunk/libavcodec/arm/ (dsputil_init_armv6.c dsputil_armv6.S): ARMv6 optimised diff_pixels
[16:14:16] <CIA-17> ffmpeg: mru * r21703 /trunk/libavcodec/arm/ (dsputil_init_armv6.c dsputil_armv6.S): ARMv6 optimised sse16
[16:14:17] <BBB> at least I didn't add a rtsp_lower_transport option to avformatcontext
[16:14:17] <CIA-17> ffmpeg: mru * r21704 /trunk/libavcodec/arm/ (dsputil_init_armv6.c dsputil_armv6.S): ARMv6 optimised pix_norm1
[16:14:18] <CIA-17> ffmpeg: mru * r21705 /trunk/libavcodec/arm/ (dsputil_init_armv6.c dsputil_armv6.S): ARMv6 optimised pix_sum
[16:14:30] <elenril> m-m-monster kill
[16:14:43] <BBB> in fact, I think I removed that option, which was a global constant before
[16:14:52] <BBB> ugly as hell
[16:15:12] <jez9999> global constant?  how does that work with calling code?
[16:15:33] <BBB> it wasn't exported in a header
[16:15:46] <mattg> mru: it's in /MPlayer/incoming/mattg_neon_green/
[16:15:53] <BBB> so they'd declare it themselves as "extern int rtsp_lower_transport;"
[16:16:08] <BBB> and then set it to 1, 2 or 4 depending on whether they wanted tcp or udp
[16:16:25] <BBB> I removed that for obvious reasons
[16:17:56] <BBB> anyway, codec-specific options, format-specific options
[16:17:59] <BBB> all of this is ugly as hell
[16:18:06] <BBB> someone needs to step up and do it :)
[16:20:07] <jez9999> that's a pretty massive job
[16:20:17] <jez9999> at least, for someone who isn't a regular ffmpeg coder
[16:20:43] <BBB> it's massive for us also
[16:21:03] <jez9999> so theoretically if you were funded to start now, how long would it take you?
[16:22:21] <DonDiego> anybody seen yuvi around?
[16:22:35] <kshishkov> he was here yesterday or so
[16:22:53] <DonDiego> k, let's see if he shows up..
[16:26:20] <jez9999> BBB: you see that?
[16:28:50] <BBB> yes
[16:29:06] <BBB> your question is: how long would I spend on it?
[16:29:10] <jez9999> no
[16:29:12] <BBB> probably 2-4 weeks
[16:29:21] <jez9999> well ok you rephrased it i guess lol
[16:29:32] <BBB> :)
[16:30:03] <jez9999> and that would just be on being able to pass another argument in the av_open* functions?
[16:31:05] <BBB> jez9999, two variants have been proposed
[16:31:10] <BBB> jez9999, one is what you're saying
[16:31:41] <BBB> jez9999, the second is that another call before that is necessary to initialize default "private options", and then you can change those in the application, and call the open() function just as regularly
[16:31:55] <BBB> i.e. they're semantically slightly different but do exactly the same thing
[16:33:03] <BBB> stefano has been working on that for longer than me, if you want to fund actively
[16:33:12] <BBB> dark_shikari also wants it, but for x264
[16:33:20] <BBB> I want it for rtsp, as said before
[16:36:23] <jez9999> these guys work for other companies?
[16:36:33] <jez9999> or is it purely for personal use?
[16:36:42] <BBB> Dark_Shikari is consulting
[16:36:48] <BBB> I don't know about stefano
[16:37:09] <jez9999> does part of the consulting fee comprise ffmpeg development?
[16:37:19] <BBB> ?
[16:37:31] <BBB> he does whatever people want that he has contracts with
[16:37:38] <BBB> that could be ffmpeg developer, or anything
[16:38:11] <BBB> you could ask him to sign a contract to do codec/format-specific implementation of two options: "log_level" in x264 and "source" in sdp
[16:38:16] <BBB> that would be sufficient to get the whole system in
[16:39:35] <jez9999> well the large bulk of the work would be the format-specific options implementation
[16:39:51] <jez9999> the 'source' bit would be easy in comparison
[16:41:44] <BBB> correct
[16:44:56] <jez9999> hang on.......
[16:45:00] <jez9999> what is AVFormatParameters?
[16:46:31] <BBB> jez9999, it's deprecated, don't even start touching it :)
[16:46:49] <jez9999> oh... that would seem to be one of the proposed solutions
[16:46:55] <jez9999> or would the proposed solution be a string
[16:47:04] <BBB> yes
[16:47:16] * elenril wonders why it isn't marked as deprecated
[16:47:28] <BBB> avformatparameters suffers from the same problem as putting it in avformatcontext: it's not codec-specific, since it's there for all codecs
[16:47:32] <BBB> except only one uses it
[16:47:45] <BBB> "introspectibility" of that is missing
[16:48:15] <BBB> the proposed solution would ideally be introspectable, but at the very least it shouldn't increase the binary size of formats it does not apply to
[16:48:27] <BBB> avformatparameters fails that last condition
[16:48:33] <BBB> so does avformatcontext
[17:22:14] <mattg> mru: have you had any luck with my sample file?
[17:24:31] <mru> mattg: sorry, haven't had time to look at it yet
[17:25:19] <mattg> absolutely no problem
[17:25:34] <mru> I'll get to it eventually
[17:25:48] <mru> keep poking every 24h or so until I do
[17:25:59] <mru> hopefully it's an easy one
[17:28:04] <mattg> ok, will do. yeh it's hopefully easy. i had a quick look myself but got stuck. i had issues with libx264 arm asm as well which was alignment related, so i've been hunting to see if that's the case here.
[17:35:26] <Dark_Shikari> mru: did you ever get any of my messages about Green Hills Software?
[17:35:34] <Dark_Shikari> if I pick them for this summer's internship, I'll have to test their compiler on ffmpeg
[17:35:39] <Dark_Shikari> and see how much it beats armcc
[17:36:27] <mru> messages from you about green hills?
[17:36:31] <siretart_> ramiro: pong
[17:37:15] <jez9999> BBB: what's required for a patch to ffmpeg to be accepted, some kind of test scripts?
[17:37:25] <CIA-17> ffmpeg: siretart * r21706 /branches/ (0.5 0.5/libavcodec/aac.c 0.5/libavcodec/aac.h):
[17:37:25] <CIA-17> ffmpeg: fix aac playback regression
[17:37:25] <CIA-17> ffmpeg: Discussed at http://comments.gmane.org/gmane.comp.video.ffmpeg.devel/103768
[17:37:25] <CIA-17> ffmpeg: related reports:
[17:37:25] <CIA-17> ffmpeg:  - http://bugs.debian.org/540729
[17:37:26] <CIA-17> ffmpeg:  - https://roundup.ffmpeg.org/roundup/ffmpeg/issue800
[17:37:27] <mru> Dark_Shikari: messages where?
[17:37:37] <ramiro> siretart: I replied to your commit to gsm
[17:37:41] <jez9999> say one that allowed the file: protocol handler to accept a query string with format-specific custom args?
[17:38:18] <Dark_Shikari> mru: oh, it was a few days ago
[17:38:24] <Dark_Shikari> when I was up in santa barbera interviewing for them
[17:38:25] <siretart_> ramiro: oh, yes, now I remember, I'm looking at the issue right now
[17:38:28] <Dark_Shikari> they have some pretty awesome software
[17:38:39] <mru> awesomely buggy, yes
[17:38:42] <siretart_> ramiro: it was basically diego who committed it, I did lend him my laptop
[17:38:58] <mru> it was their compiler that accessed data below the stack pointer
[17:39:11] <_av500_> siretart_: that messes up the svn history, no? :)
[17:39:51] <ramiro> siretart_: well then let's ping diego =)
[17:39:55] <ramiro> DonDiego: ping
[17:40:04] * Honoome looks up
[17:40:06] <Honoome> ah not me…
[17:40:53] <siretart_> ramiro: it seems that the libgsm upstream makefile does not come with *any* proper installation rules
[17:41:11] <ramiro> I know...
[17:41:15] <siretart_> ramiro: the installation is defined by debian/rules
[17:41:23] <mru> siretart_: then go with plain <gsm.h> and have the user supply -I flags as necessary
[17:42:30] <siretart_> mru: that sounds reasonable to me
[17:42:53] <siretart_> oh, wait, that would break the build on debian
[17:43:01] <ramiro> how?
[17:43:11] <siretart_> sorry, my bad, it doesn't
[17:43:31] <siretart_> /usr/include/gsm.h -> gsm/gsm.h
[17:43:52] <ramiro> yeah, that's weird... I just apt-got the source to see if there was any comment in debian/rules about that...
[17:44:21] <DonDiego> ramiro: pong
[17:44:39] <siretart_> DonDiego: it's about our gsm.h change at fosdem
[17:44:41] <ramiro> DonDiego: we're talking about the gsm commit
[17:45:02] <DonDiego> weren't there two different rules in the package?
[17:45:32] <siretart_> the package ships a symlink that 'makes things work'
[17:46:01] <siretart_> I wonder what the situation in other distro packages is
[17:46:52] <siretart_> opensuse: http://www.novell.com/products/linuxpackages/opensuse/libgsm-devel.html
[17:47:21] <DonDiego> hrmpf
[17:47:33] <DonDiego> peloverde_: yo
[17:47:41] <DonDiego> peloverde_: back in the states?
[17:47:43] <peloverde_> yeah
[17:48:08] <DonDiego> hope you had a good flight and enjoyed old europe :)
[17:48:17] <peloverde> I did
[17:48:41] <mru> next time we need to show him some of the shadier parts
[17:48:43] <mru> it's tradition...
[17:48:49] <siretart_> hmrpfs about rathan not being around. he seems to be maintaining libgsm in fedora
[17:49:06] <mru> hmrpfs, is that a new filesystem?
[17:49:09] <kshishkov> mru: shadier? welcome here!
[17:49:58] <siretart_> ah, here we go for fedora: http://koji.fedoraproject.org/koji/rpminfo?rpmID=1450127
[17:50:31] <siretart_> can someone check if there is such a compat symlink /usr/include/gsm.h -> gsm/gsm.h in gentoo as well?
[17:50:35] <DonDiego> haha
[17:50:50] <DonDiego> yes, we shall show our us friends the shadier parts of the continent :)
[17:50:56] <siretart_> hi peloverde!
[17:50:58] <BBB> jez9999, well, that's a workaround for lack of format-specific options... I'm not sure that'd be accepted anyway
[17:51:02] <BBB> jez9999, but you could try...
[17:51:52] <jez9999> heh
[17:51:55] <mru> hmm, gentoo does dosym ../gsm/gsm.h /usr/include/libgsm/gsm.h
[17:52:14] <jez9999> so basically the best use of my time is to complete my patch to add to avformatcontext.
[17:52:34] <BBB> ?
[17:52:37] <siretart_> mru: does this mean that there is no /usr/include/gsm.h in gentoo at all?
[17:52:39] <BBB> no, make it a format-specific option
[17:52:45] <BBB> you'll make a lot of people happy
[17:52:50] <mru> siretart_: it would appear so
[17:52:51] <jez9999> why?  you probably wont accept it anyway and i need to get it done in 2 weeks
[17:52:53] <ramiro> why does suse install private.h? that seems wrong.
[17:52:55] <mru> it's not installed on my machine
[17:53:03] <BBB> if you want something xuggler-specific, you could just use the patch you have already
[17:53:06] <mru> ramiro: suse is wrong, that's why
[17:53:17] <BBB> I'll accept the format-specific option patch
[17:53:26] <BBB> (assuming done correctly)
[17:53:31] <siretart_> mru: that's interesting, given that opensuse, debian and fedora all seem to include that
[17:53:33] <BBB> (i.e. AVOption-based, etc.)
[17:53:33] <jez9999> oh you mean the massive amount of work one? :-)
[17:53:37] <jez9999> lol
[17:53:42] <jez9999> yeah, no time to do that
[17:53:53] <Dark_Shikari> mru: did you get the bug fixed?
[17:53:56] <Dark_Shikari> and do you have the compiler?
[17:53:56] <BBB> dude, RDT (a simple variation of RTP) took me two years because of massive restructuring in rtsp to get it in "nicely"
[17:54:04] <mru> Dark_Shikari: that was at the old job
[17:54:09] <BBB> I know what shitload-of-work is :)
[17:54:14] <Dark_Shikari> ah.
[17:54:14] <BBB> but sometimes it's best in the longer term
[17:54:34] <mru> they had some kind of policy against ever updating a compiler
[17:54:38] <mru> so a bugfix would be useless anyway
[17:55:01] <jez9999> BBB: how nice that you have an employer that can fund you for 2 years on that :-)
[17:55:05] <jez9999> or the spare time...
[17:55:37] <Dark_Shikari> mru: lol
[17:55:38] <Dark_Shikari> idiots.
[17:55:48] <ramiro> so we have 3 in include/gsm/, 1 in include/libgsm/, and 2 in include/, the official says nothing about it.
[17:56:04] <mru> Dark_Shikari: that's what I told them, then I quit
[17:56:09] <Dark_Shikari> lol
[17:56:24] <Dark_Shikari> apparently the guys at green hills have a similar attitude--they have customers that use some ANCIENT versions
[17:56:27] <Dark_Shikari> and they hate it
[17:56:32] <Dark_Shikari> because that means they have to _support_ them
[17:57:14] <ohsix> they keep old projects and toolchains in a nice old bundle so someone can still do maintenance if they have to
[17:57:32] <mru> end result was one week of my time wasted hunting that damn bug
[17:57:48] <ohsix> high-rel stuff sometimes has to rely on a known bad than an unknown "better"
[17:58:00] <mru> this was TV set top boxes
[17:58:06] <mru> about as flaky as it gets
[17:58:22] <ohsix> nice
[17:58:58] <BBB> jez9999, spare time :)
[17:59:00] <kierank> zero nines
[17:59:09] <BBB> jez9999, if I were my own employer, I'd have fired myself, most likely
[17:59:14] <BBB> anyway, this won't take 2 years
[18:00:39] <siretart_> ramiro: replied
[18:01:03] <ramiro> siretart_: thanks
[18:01:12] <ramiro> but it seems gentoo does a symlink, doesn't it?
[18:01:46] <ramiro> ah, but not to include/ . ok...
[18:10:55] <CIA-17> ffmpeg: siretart * r21707 /branches/ (0.5/libavformat/avformat.h 0.5 0.5/libavformat/utils.c):
[18:10:55] <CIA-17> ffmpeg: Make arguments of av_set_pts_info() unsigned.
[18:10:55] <CIA-17> ffmpeg: Fixes issue1240/mpeg1/smclockmpeg1.avi.3.1
[18:15:25] <peloverde> I noticed someone added LATM to the 0.6 wiki entry? Is anyone actively still working on LATM?
[18:15:46] <Honoome> we just got LATM support requested on libnemesi the other day o_O
[18:17:03] <peloverde> I know a lot of people want LATM but does it make sense as a release goal if no one is working on it?
[18:19:13] <kshishkov> DonDiego: ^
[18:20:11] <siretart_> DonDiego: you rejected http://git.debian.org/?p=pkg-multimedia/ffmpeg.git;a=blob;f=debian/patches/security/libavformat/mov/0000-MOV-Support-stz2-Compact-Sample-Size-Box.patch;h=0eff8ac51f20def1164b379fdbb1d5a4670bc02b;hb=HEAD on the basis that it was a feature backport that we don't want. now I remember why I included it in the package:
[18:20:30] <siretart_> DonDiego: reason is: it introduces a variable 'field_size', which is used in later patches
[18:20:58] <siretart_> DonDiego: on that basis, do you still object to that patch?
[18:21:23] <peloverde> siretart_, I haven't looked at that recently but IIRC the vulnerability was caused by the addition of field_size
[18:23:59] <siretart_> peloverde: oh. could you perhaps invest some minutes? if you're right, then all patches from here should be dropped: http://git.debian.org/?p=pkg-multimedia/ffmpeg.git;a=tree;f=debian/patches/security/libavformat/mov;hb=HEAD
[18:25:23] <CIA-17> ffmpeg: siretart * r21708 /branches/ (0.5/libavformat/oggdec.c 0.5):
[18:25:23] <CIA-17> ffmpeg: Disable parsing for ogg streams where no ogg header was found,
[18:25:23] <CIA-17> ffmpeg: if no header was found the parser was not initialized and thus will
[18:25:23] <CIA-17> ffmpeg: crash when trying to use it.
[18:33:40] <peloverde> siretart, http://roundup.ffmpeg.org/roundup/ffmpeg/file469/smclockmp4aac_1_0.mp4 is not crashing on the 0.5 branch for me
[18:34:22] <peloverde> That was the file attached to the bug referenced in: 0001-check-entries-against-field_size-potential-malloc-ov.patch
[18:35:16] <peloverde> 0002-add-one-missing-check-for-stream-existence-in-read_e.patch has no dependency on 0000 or 0001
[18:35:43] <peloverde> In 0003-check-stream-existence-before-assignment-fix-1222.patch field_size only appears in the context lines
[18:37:27] <siretart_> peloverde: excellent analysis. working on that now
[18:42:08] <CIA-17> ffmpeg: siretart * r21709 /branches/ (0.5 0.5/libavformat/mov.c):
[18:42:08] <CIA-17> ffmpeg: add one missing check for stream existence in read_elst, fix #1364
[18:42:08] <CIA-17> ffmpeg: backported patch r19792 by bcoudurier
[18:45:41] <CIA-17> ffmpeg: siretart * r21710 /branches/ (0.5 0.5/libavformat/mov.c):
[18:45:41] <CIA-17> ffmpeg: check stream existence before assignment, fix #1222
[18:45:41] <CIA-17> ffmpeg: backported r19259 by bcoudurier
[18:51:49] <DonDiego> ok, nice to see some 0.5 branch activity :)
[18:51:55] <DonDiego> thx everybody for helping out..
[18:52:03] <CIA-17> ffmpeg: siretart * r21711 /branches/ (0.5 0.5/libavformat/oggparsevorbis.c):
[18:52:03] <CIA-17> ffmpeg: Fix possible buffer over-read in vorbis_comment, fix it double to be sure.
[18:52:03] <CIA-17> ffmpeg: First, make s signed, so that comparisons against end - p will not be made as
[18:52:03] <CIA-17> ffmpeg: unsigned, making the check incorrectly pass if p is beyond end.
[18:52:03] <CIA-17> ffmpeg: Also ensure that p will never be > end, so the code is correct also if
[18:52:04] <CIA-17> ffmpeg: buf is not padded.
[18:52:05] <CIA-17> ffmpeg: backported r20014 by reimar
[18:52:09] <DonDiego> some people highlighted me, what's up?
[18:52:26] <DonDiego> i'm supposed to be at work and cannot read all the backlog now ;)
[18:52:39] <kshishkov> somebody with nick "Yuvi" has logged in
[18:53:05] <siretart_> DonDiego: peloverde already cleared the issue and my mov patches are already comitted
[18:53:20] <siretart_> so, I'm done for libavformat, now attacking avcodec
[18:53:31] <BBB> woohoo, I think google will pay ius for 2008 also
[18:53:53] <BBB> we should all buy mike a drink and then maybe suggest I take over gsoc admin for 2010
[18:53:58] <siretart_> BBB: great news! :-)
[18:54:35] <jez9999> pay who?:
[18:54:50] <mru> BBB: mike doesn't drink
[18:55:16] <kshishkov> mru: water? cola?
[18:55:31] <mru> "buy someone a drink" implies beer or better
[18:56:31] <CIA-17> ffmpeg: siretart * r21712 /branches/ (0.5/libavcodec/ffv1.c 0.5):
[18:56:31] <CIA-17> ffmpeg: Fix a possibly exploitable buffer overflow.
[18:56:31] <CIA-17> ffmpeg: backported r18640 by michael
[18:57:36] <kshishkov> mru: for me water is better. Or Trocadero
[18:58:02] <DonDiego> kshishkov: thx for the hint
[18:58:23] <DonDiego> Yuvi: you around now?
[18:58:51] <CIA-17> ffmpeg: stefano * r21713 /trunk/doc/APIchanges: Add an entry for the recently added av_compare_ts() function.
[18:59:19] <BBB> mru: I'll buy him a virgin mojito
[18:59:29] <BBB> or a hot chocolate, if he insists
[18:59:47] <BBB> jez9999, mike melanson, ffmpeg's google summer of code admin of the past few years
[19:00:11] <Yuvi> DonDiego: yo
[19:00:18] <BBB> koth: did we agree on dns already?
[19:00:19] <DonDiego> Yuvi: i wanted to inquire about the status of your theora speedup branch
[19:00:24] <CIA-17> ffmpeg: stefano * r21714 /trunk/libavformat/avio.h: Doxument url_fopen().
[19:00:27] <BBB> koth: or someway I can get access to the website?
[19:00:33] <DonDiego> as you know we were at fosdem this weekend
[19:00:44] <DonDiego> and the release name for 0.6 is going to be..
[19:00:51] <DonDiego> ... * drumroll * ...
[19:01:03] <DonDiego> " works with HTML 5 "
[19:01:04] <kshishkov> nonexistent
[19:01:13] <Dark_Shikari> DonDiego: do it
[19:01:13] <Dark_Shikari> lol
[19:01:19] <Yuvi> chroma's broken, but once that's fixed I can start merging
[19:01:29] <DonDiego> it's what mans put on our ffmpeg t-shirts
[19:01:29] <Yuvi> it's at 20-27% faster
[19:01:33] <DonDiego> anyway
[19:01:44] <DonDiego> the point, the point, back to the point :)
[19:01:50] <DonDiego> html 5 is the hotness right now
[19:01:59] <DonDiego> and ffmpeg is being scorned for its handling of theora
[19:02:00] <Dark_Shikari> Yuvi: get that done =p
[19:02:10] <BBB> I love it
[19:02:11] <BBB> do it
[19:02:21] <DonDiego> so let's have world-class theora support in 0.6
[19:02:22] <BBB> and send out more t-shirts :-p
[19:02:54] <DonDiego> if we can write that apart from the fastest vorbis decoder we now also have the fastest theora decoder
[19:03:10] <DonDiego> then we will rock and make a lot of people shut up :)
[19:03:30] <peloverde> DonDiego, they will still flame us for supporting H.264
[19:03:32] <CIA-17> ffmpeg: siretart * r21715 /branches/ (0.5/libavcodec/h264.c 0.5):
[19:03:32] <CIA-17> ffmpeg: Check num_units_in_tick/time_scale to be valid and within the range we support.
[19:03:32] <CIA-17> ffmpeg: based on a patch by chrome
[19:03:32] <CIA-17> ffmpeg: backported r19979 by michael
[19:03:55] <Yuvi> ofc, they also want 4:2:2, 4:4:4 and that stupid left/top cropping
[19:04:08] <DonDiego> Yuvi: so if you could prioritize your work on the theora branch a bit, that would be awesome
[19:04:12] <kshishkov> DonDiego: but not the fastest Bink decoder :P
[19:04:35] <DonDiego> Yuvi: yes, implementing missing features would of course also be welcome
[19:04:50] <DonDiego> as well as fixing that annoyance with keyframes while seeking
[19:04:54] <peloverde_> Not the fastest HE-AAC decoder
[19:05:22] <Yuvi> DonDiego: certainly, I was planning on 4:2:2/4:4:4 after the speedup; it needed keeping a few things in mind
[19:05:33] <DonDiego> i.e. artifacts after seeking
[19:05:42] <DonDiego> peloverde_: which is the fastest?
[19:06:13] <DonDiego> peloverde_: we cannot shut up everybody about everything, but we certainly can shut up certain people about certain things
[19:06:29] <peloverde_> DonDiego, Probably nero for among those available to the general public
[19:06:32] <DonDiego> and let's face it: theora *will* become more widespread now
[19:06:40] <mru> coreaac is pretty fast too
[19:06:45] <DonDiego> peloverde_: private aac decoders exist?
[19:06:46] <peloverde_> I'm still hoping for IE9 with H.264
[19:07:03] <DonDiego> we shall see
[19:07:17] <DonDiego> Yuvi: anyway, great that you have all that in the queue..
[19:07:17] <peloverde_> DonDiego, yeah AAC is very important in embedded space
[19:07:24] <DonDiego> k
[19:07:42] <DonDiego> while we're at it, does anybody have that seeking in ogg/theora bug covered?
[19:08:18] <peloverde_> What about broken continuation oggs?
[19:08:38] <BBB> that is hell :)
[19:08:38] <mru> that has got to be one of the worst misfeatures ever
[19:08:54] <BBB> you can add or remove streams after a continuation (you mean catted ogg files, right?)
[19:08:57] <Yuvi> peloverde_: fixed yesterday or the day before
[19:09:03] <BBB> s/can/mean/
[19:09:13] <DonDiego> all hail Yuvi :-)
[19:09:17] <peloverde_> Yuvi, ahh I've been out of the loop since FOSDEM
[19:09:40] <peloverde_> kind of funny how that works out
[19:09:53] <DonDiego> ok, i'll pretend to work again
[19:10:03] <CIA-17> ffmpeg: siretart * r21716 /branches/ (0.5 0.5/libavcodec/mpegaudiodec.c):
[19:10:03] <CIA-17> ffmpeg: check data_size in decode_frame()
[19:10:03] <CIA-17> ffmpeg: backported r19986 by michael
[19:10:05] <DonDiego> there's an autobuilder in need of fixing :)
[19:21:18] <CIA-17> ffmpeg: siretart * r21717 /branches/ (0.5 0.5/libavcodec/mpegaudiodec.c):
[19:21:18] <CIA-17> ffmpeg: Check data_size in decode_frame_mp3on4().
[19:21:18] <CIA-17> ffmpeg: backported r19987 by michael
[19:23:11] <CIA-17> ffmpeg: siretart * r21718 /branches/ (0.5 0.5/libavcodec/mpegaudiodec.c):
[19:23:11] <CIA-17> ffmpeg: Set data_size to 0 to avoid having it uninitialized.
[19:23:11] <CIA-17> ffmpeg: based on 31_mp3_outlen.patch by chrome.
[19:23:11] <CIA-17> ffmpeg: backported r19988 by michael
[19:25:56] <DonDiego> does anybody how 0.5 was faring wrt fate?
[19:26:11] <DonDiego> and yes, the autobuilder is fixed ;)
[19:27:35] <CIA-17> ffmpeg: siretart * r21719 /branches/ (0.5 0.5/libavcodec/vp3.c):
[19:27:35] <CIA-17> ffmpeg: Fix init_get_bits() buffer size.
[19:27:35] <CIA-17> ffmpeg: 18_fix_theora_header_bit_len.patch by chrome
[19:27:35] <CIA-17> ffmpeg: backport r19993 by michael
[19:31:59] <CIA-17> ffmpeg: siretart * r21720 /branches/ (0.5 0.5/libavcodec/vp3.c):
[19:31:59] <CIA-17> ffmpeg: Make sure that all memory allocations succeed.
[19:31:59] <CIA-17> ffmpeg: Based on 28_theora_malloc_checks.patch from the Google Chrome team.
[19:31:59] <CIA-17> ffmpeg: backport r20008 by melanson
[19:37:49] <DonDiego> siretart_: have you looked at the patch benjamin from geexbox sent us?
[19:38:23] <DonDiego> Dark_Shikari: while we're at it, did you look at patching the x264 glue code for the 0.5 branch?
[19:39:20] <siretart_> DonDiego: yes, it basically just adds some callbacks in ffmpeg, so that the application can do proper locking
[19:39:22] <Dark_Shikari> DonDiego: yes, I'll do that later today
[19:39:32] <Dark_Shikari> I'm working on a paper peer review that I've been putting off atm
[19:39:42] <siretart_> DonDiego: it doesn't look too unreasonable to me
[19:39:48] <DonDiego> Dark_Shikari: cool, thx
[19:40:19] <DonDiego> siretart_: i have the same impression, so it should be good to go
[19:40:31] <DonDiego> that's settled then
[19:41:16] <siretart_> DonDiego: :-)
[19:43:28] <CIA-17> ffmpeg: siretart * r21721 /branches/ (0.5/libavcodec/vorbis_dec.c 0.5):
[19:43:28] <CIA-17> ffmpeg: Check dimensions against 0 too.
[19:43:28] <CIA-17> ffmpeg: 39_vorbis_zero_dims.patch from chrome
[19:43:28] <CIA-17> ffmpeg: backport r19976 by michael
[19:44:55] <CIA-17> ffmpeg: siretart * r21722 /branches/ (0.5/libavcodec/vorbis_dec.c 0.5):
[19:44:55] <CIA-17> ffmpeg: = -> == typo.
[19:44:55] <CIA-17> ffmpeg: 27_vorbis_residue_loop_error.patch by chrome
[19:44:55] <CIA-17> ffmpeg: backport r19982 by michael
[19:46:06] <CIA-17> ffmpeg: siretart * r21723 /branches/ (0.5/libavcodec/vorbis_dec.c 0.5):
[19:46:06] <CIA-17> ffmpeg: Sanity checks for magnitude and angle.
[19:46:06] <CIA-17> ffmpeg: 26_vorbis_mag_angle_index.patch by chrome
[19:46:06] <CIA-17> ffmpeg: backport r19983 by michael
[19:47:10] <CIA-17> ffmpeg: siretart * r21724 /branches/ (0.5/libavcodec/vorbis_dec.c 0.5):
[19:47:10] <CIA-17> ffmpeg: Fix book_idx check.
[19:47:10] <CIA-17> ffmpeg: 25_vorbis_floor0_index.patch by chrome.
[19:47:10] <CIA-17> ffmpeg: backport r19984 by michael
[19:48:30] <CIA-17> ffmpeg: siretart * r21725 /branches/ (0.5/libavcodec/vorbis_dec.c 0.5):
[19:48:30] <CIA-17> ffmpeg: Check classbook value.
[19:48:30] <CIA-17> ffmpeg: 11_vorbis_residue_book_index.patch by chrome.
[19:48:30] <CIA-17> ffmpeg: r19989 by michael
[19:50:11] <Dark_Shikari> heh, cia spam
[19:50:18] <CIA-17> ffmpeg: siretart * r21726 /branches/ (0.5/libavcodec/vorbis_dec.c 0.5):
[19:50:18] <CIA-17> ffmpeg: Add checks for per-packet mode indexes and per-header mode mapping indexes.
[19:50:18] <CIA-17> ffmpeg: 12_vorbis_mode_indexes.patch by chrome
[19:50:18] <CIA-17> ffmpeg: maybe exploitable
[19:50:18] <CIA-17> ffmpeg: r19990 by michael
[19:51:45] <CIA-17> ffmpeg: siretart * r21727 /branches/ (0.5/libavcodec/vorbis_dec.c 0.5):
[19:51:45] <CIA-17> ffmpeg: Check masterbook index and subclass book index.
[19:51:45] <CIA-17> ffmpeg: 14_floor_masterbook_index.patch by chrome
[19:51:45] <CIA-17> ffmpeg: r19991 by michael
[19:53:17] <CIA-17> ffmpeg: siretart * r21728 /branches/ (0.5/libavcodec/vorbis_dec.c 0.5):
[19:53:17] <CIA-17> ffmpeg: Check res_setup->books.
[19:53:17] <CIA-17> ffmpeg: 15_more_residue_book_indexes.patch by chrome.
[19:53:17] <CIA-17> ffmpeg: r19992 by michael
[19:55:34] <CIA-17> ffmpeg: siretart * r21729 /branches/ (0.5/libavcodec/vorbis_dec.c 0.5):
[19:55:34] <CIA-17> ffmpeg: Check begin/end/partition_size.
[19:55:34] <CIA-17> ffmpeg: 23_vorbis_sane_partition.patch by chrome.
[19:55:34] <CIA-17> ffmpeg: Also this should be better documented but i prefer not to leave potential
[19:55:34] <CIA-17> ffmpeg: security issues open due to missing documentation.
[19:55:34] <CIA-17> ffmpeg: r19996 by michael
[20:00:05] <CIA-17> ffmpeg: siretart * r21730 /branches/ (0.5/libavcodec/vorbis_dec.c 0.5):
[20:00:05] <CIA-17> ffmpeg: Check submap indexes.
[20:00:05] <CIA-17> ffmpeg: 10_vorbis_submap_indexes.patch by chrome.
[20:00:05] <CIA-17> ffmpeg: I am applying this even though Reimar had some comments to improve it as it fixes
[20:00:05] <CIA-17> ffmpeg: a serious security issue and I do not want to leave such things unfixed.
[20:00:06] <CIA-17> ffmpeg: backport r20001 by michael
[20:29:34] <CIA-17> ffmpeg: siretart * r21731 /branches/ (5 files in 4 dirs): (log message trimmed)
[20:29:34] <CIA-17> ffmpeg: Add a lock manager API to libavcodec.
[20:29:34] <CIA-17> ffmpeg: Allows an application to register a callback that manages mutexes
[20:29:34] <CIA-17> ffmpeg: on behalf of FFmpeg.
[20:29:34] <CIA-17> ffmpeg: With this callback registered FFmpeg is fully thread safe.
[20:29:35] <CIA-17> ffmpeg: backport r19025 by andoma
[20:29:36] <CIA-17> ffmpeg: NB: This is a feature backport with little regression potential. It was
[20:32:17] <DonDiego> bye
[20:32:46] <andoma> bye
[20:33:11] <siretart_> byebye
[20:33:16] <mru> byebyebye
[20:34:53] <aclarke> int i;for(i=0;i<4;i++) printf("bye");
[20:35:42] <mru> ah, that did it
[20:37:00] <ohsix> int i=5;while(i--) puts("bye");
[21:27:09] <astrange> Yuvi: you should put a blank line after the first line in git commit messages
[21:27:55] <astrange> Yuvi: also re http://github.com/yuvi/ffmpeg/commit/ad4d07e8f3bacce1096f50db00fb1ccfe080cb5a, the xvid idct has no transpose so it was much easier to add complicated skipping
[21:51:58] <Yuvi> astrange: yeah.. I noticed the obscenely long subject after the emails were sent
[21:52:29] <Yuvi> and that makes sense, I was trying to figure how to add the skipping without branching on zzi
[21:53:08] <Yuvi> but probably using zzi is the only way that makes sense for theora
[21:53:19] <Dark_Shikari> zzi?
[21:53:33] <Dark_Shikari> oh yeah, we still need a dc-only idct for theora.
[21:53:40] <Yuvi> last coeff index in zigzag order, forget what other codecs call it
[21:53:48] <Dark_Shikari> which makes extra sense because the encoder refuses to decimate dc coeffs
[21:54:46] <Yuvi> actually, I noticed a fair number of dc-only blocks with 0, due to the stupid restriction of uncoded blocks having no MV
[21:55:19] <Dark_Shikari> oh you mean a dc only block with no real coefficients?
[21:55:24] <Yuvi> yep
[21:55:47] <Dark_Shikari> ah, theora allows that in the entrop coder?
[21:55:51] <Dark_Shikari> *entropy
[21:56:01] <Dark_Shikari> that's a pretty obnoxious inefficiency
[21:56:16] <Dark_Shikari> I mean it makes sense in that case given the whole uncoded blocks restriction
[21:56:22] <Yuvi> yeah, mark the block as coded in the first section then EOB it immediately when decoding coefficients
[21:56:24] <Dark_Shikari> but in all other cases it's horribly inefficient
[21:56:34] <Dark_Shikari> forces redundant eobs
[21:57:31] <Dark_Shikari> so basically I think there are three things needed:
[21:57:36] <Dark_Shikari> 1) don't call idct on empty blocks that are coded
[21:57:42] <Dark_Shikari> i.e. mark uncoded coded blocks as uncoded
[21:57:45] <Dark_Shikari> 2) dc-only idct
[21:57:49] <Dark_Shikari> 3) "idct small", if it's useful
[21:58:00] <Dark_Shikari> the fact that we have the last nnz values "for free" should help
[21:58:22] <Dark_Shikari> also, maybe some statistics of inter/intra dct coeffs
[21:58:47] <Dark_Shikari> could even swap code paths based on frame quantizer
[21:59:12] <Yuvi> http://pastebin.com/m4f43dbed some stats, I didn't separate empty from DC-only or inter/intra
[21:59:35] <Dark_Shikari> 10e?
[21:59:58] <Yuvi> last nnz is < 10
[22:00:04] <Dark_Shikari> ah k
[22:00:05] <Yuvi> i.e. right and bottom halves of the block are 0
[22:48:02] <KotH> night boys and girls
[22:51:28] <_av500_> nighty nighty
[22:55:59] <CIA-17> ffmpeg: mru * r21732 /trunk/configure: configure: allow 'none' as target OS
[22:56:00] <CIA-17> ffmpeg: mru * r21733 /trunk/ (configure cmdutils.c): Check for setrlimit()
[22:56:01] <CIA-17> ffmpeg: mru * r21734 /trunk/configure:
[22:56:01] <CIA-17> ffmpeg: Special check for math.h functions
[22:56:01] <CIA-17> ffmpeg: These are often, contrary to standards, implemented only as macros
[22:56:01] <CIA-17> ffmpeg: or compiler-builtin functions without an actual symbol definition.
[22:56:02] <CIA-17> ffmpeg: mru * r21735 /trunk/libavutil/internal.h:
[22:56:02] <CIA-17> ffmpeg: Define missing llrint() as macro instead of inline function
[22:56:03] <CIA-17> ffmpeg: This fixes building on some broken systems.
[22:56:32] <_av500_> mru: do I smell dsp?
[22:56:52] <mru> yes and no
[22:57:14] <mru> this fixes both dsp and something else I'm being paid for
[22:57:14] <_av500_> yes and no os :)
[22:58:43] <Dark_Shikari> that may help cygwin
[22:58:49] <Dark_Shikari> lrintf that is
[22:59:23] <mru> quite possible
[22:59:27] <mru> it uses newlib, right?
[22:59:46] <Dark_Shikari> dunno
[22:59:48] <Dark_Shikari> it just warns all over about lrintf
[22:59:54] <Dark_Shikari> no errors just warnings
[23:00:41] <_av500_> gcc: warning: line of C code encountered
[23:00:51] <mru> _av500_: no, that's lint
[23:00:56] <andoma> :)
[23:00:56] <_av500_> ah
[23:01:12] <Dark_Shikari> lol
[23:29:59] <mru> hey guys, check out linuxtag.org
[23:30:07] <mru> watch the banner photo for a while
[23:31:31] * Kovensky sees a bunch of heads, some orange thing and jpeg artifacts
[23:31:53] <mru> one of the photos has the ffmpeg/ogp crew
[23:33:25] <kierank> the one sitting at the table?
[23:33:40] <mru> yeah
[23:33:43] <mru> at the party
[23:34:06] <mru> that's from 2008
[23:34:49] <Kovensky> thought it was that one
[23:34:56] <Kovensky> and I had to enable scripts ._.
[23:35:47] <Dark_Shikari> Yuvi: btw, any rough eta on when the theora optimizations you're working on will go in?
[23:35:59] <Dark_Shikari> I'd like to do a bit of work as well but I don't want to touch it until you've committed your trees
[23:36:02] <Kovensky> http://images.4chan.org/g/src/1265753532999.jpg <-- lol japan
[23:36:04] <Kovensky> er, wrong channel
[23:36:29] <Dark_Shikari> Kovensky: toradora: it sells graphics cards.
[23:36:47] <Kovensky> but that's k-on...
[23:37:00] <Dark_Shikari> oh wait, your'e right
[23:37:01] <Dark_Shikari> shit
[23:37:06] <Dark_Shikari> I confused my generic moeshit again
[23:37:18] <Kovensky> lol
[23:37:25] <Kovensky> toradora wasn't generic moeshit
[23:37:26] <Dark_Shikari> and toradora has a meme associated with it and AMD
[23:37:28] <Dark_Shikari> for some weird reason
[23:37:28] <Kovensky> it was tsundereshit though
[23:37:28] <Kovensky> :P
[23:37:35] <Kovensky> oh, didn't know about that meme
[23:37:36] <Dark_Shikari> all the /g/ tards photoshoppsed images of AMD and whatever her name was
[23:38:19] <Kovensky> what hair color
[23:38:29] <Dark_Shikari> the main tsundora
[23:38:40] <Kovensky> taiga