[FFmpeg-devel-irc] IRC log for 2010-03-08

[irc at mansr.com]

[00:00:13] <saste> and you need of course to escape as '|' is special for the shell
[00:00:47] <saste> whois janneg
[00:00:53] <saste> ops..
[00:01:08] <mru> janneg: careful, he's stalking you
[00:01:27] <saste> ehe :-)
[00:01:40] <CIA-92> ffmpeg: alexc * r22301 /trunk/libavformat/ (utils.c avformat.h):
[00:01:40] <CIA-92> ffmpeg: av_find_stream_info(): Add a workaround for backwards compatible HE-AAC signaling.
[00:01:40] <CIA-92> ffmpeg: The sample rate, frame size, and channel count from the container are
[00:01:40] <CIA-92> ffmpeg: not reliable when backwards compatible signaling is used.
[00:06:00] <janneg> saste: of course I'm doing that. ffmpeg wouldn't see the | in the filename otherwise. the complete command is "ffmpeg -i 'concat:file.avi|file2.avi' -vcodec copy -acodec copy file.mkv
[00:06:04] <janneg> "
[00:06:54] <saste> i suppose you checked that "concat" is compiled in
[00:07:00] <saste> with ffmpeg -protocols
[00:09:31] <janneg> yes, it is. does it make sense to include the frame size and rate abbreviations under -protocols?
[00:09:52] <relaxed> janneg: \| works
[00:10:37] <saste> janneg: no it doesn't make sense to have them listed there
[00:12:25] <janneg> relaxed: no, the same error
[00:13:02] <saste> janneg: what you see is what i'd expect if concat: wouldn't be compiled into ffmpeg
[00:13:18] <saste> for example is what i get with 'foo:xaa|xab|xac|xad|xae|xaf|xag|xah' which I'm using for testing
[00:13:36] <saste> try with concat:file.avi
[00:14:28] <saste> maybe you're not invoking the right ffmpeg
[00:22:53] <CIA-92> ffmpeg: stefano * r22302 /trunk/libavformat/concat.c:
[00:22:53] <CIA-92> ffmpeg: Fix concat seek result.
[00:22:53] <CIA-92> ffmpeg: Patch by Wolfram Gloger wmglo AT-SIGN dent.med.uni-muenchen DOT de.
[00:25:25] <janneg> saste: argh, it's working now. my real command line was concat:dir1/file.avi\|dir2/file.avi
[00:27:31] <saste> janneg: good
[00:27:44] <saste> as for the docs patches are welcome:-)
[00:27:46] <CIA-92> ffmpeg: mru * r22303 /trunk/ffserver.c: ffserver: remove bogus comment
[00:27:47] <CIA-92> ffmpeg: mru * r22304 /trunk/tests/ (md5.sh regression-funcs.sh ffserver-regression.sh):
[00:27:47] <CIA-92> ffmpeg: regtest: move md5sum wrappers into separate file
[00:27:47] <CIA-92> ffmpeg: ffserver-regression.sh doesn't need anything else from
[00:27:47] <CIA-92> ffmpeg: regression-funcs.sh, and sourcing the entire file there
[00:27:48] <CIA-92> ffmpeg: breaks things.
[00:27:48] <CIA-92> ffmpeg: mru * r22305 /trunk/tests/ffserver-regression.sh: Make ffserver regression test run (still fails)
[00:29:20] <janneg> saste: well, I think it should work with any pathnames
[00:33:05] <mru> now, will someone fix the damn thing so actually works too?
[00:36:47] <saste> mru: no that's for the 1.0 release
[00:41:39] <CIA-92> ffmpeg: stefano * r22306 /trunk/libavformat/concat.c:
[00:41:39] <CIA-92> ffmpeg: Fix concat seeking SEEK_END case.
[00:41:39] <CIA-92> ffmpeg: Patch by Wolfram Gloger wmglo ^ dent.med.uni-muenchen.de.
[00:42:43] <mru> pross-au: ping
[00:46:11] * BBB isn't happy about that shout-path yet
[00:46:20] <BBB> I still think it does the wrong thing
[00:52:28] <pross-au> Hello
[00:52:52] <mru> pross-au: I'm looking at iff.c (both of them)
[00:53:06] <mru> can you explain why the demuxer needs ff_cmap_read_palette()
[00:53:27] <pross-au> Yes
[00:53:36] <mru> or alternatively, why the decoder needs it
[00:53:59] <pross-au> iff can contain RAWVIDEO or IFF_BYTERUN1 or IFF_ILBM codecs
[00:54:41] <pross-au> for RAWVIDEO, we 'tack' the palette at the end of the frame
[00:55:21] <pross-au> for IFF_BYTERUN1 and IFF_ILBM, the palette is passed in the extradata
[00:56:07] <pross-au> the palette needs to be decoded, hence the cmap_read_palette function
[00:56:44] <pross-au> i could have createed an IFF_RAWVIDEO codec, but it seemed like a waste when we already have RAWVIDEO
[00:57:04] <mru> ok, I see
[00:57:21] <mru> you've been naughty with prototypes, you know
[00:57:28] <pross-au> Oh!?
[00:57:49] <mru> lavf/iff.c has a prototype for ff_cmap_read_palette
[00:58:00] <mru> it should be in a header file
[00:58:55] <pross-au> which one?
[00:59:13] <mru> there isn't really a good one
[00:59:16] <pross-au> creating an iff.h with ONE prototype seems overkill.
[00:59:18] <mru> so I'm making a new one
[00:59:42] <mru> files are cheap
[01:00:11] <pross-au> you're gonna set a precedent now
[01:04:03] <mru> with this change I can add -Werror=missing-prototypes
[01:05:39] <pross-au> nice
[01:07:13] <mru> just doing a quick build test on 12 arches, then I'll commit
[01:07:49] <pross-au> only 12
[01:08:23] <mru> ah, caught an error
[01:15:32] <pross-au> with the new 'beautified' makefile, warnings are much more visible...
[01:30:54] <mfg> so, this might seem like a silly question, but what is ea-cdata and what is FATE?  Apparantly, I broke it.
[01:31:24] <mru> fate is the thing you cannot escape
[01:31:29] <mfg> heh, tell me about it
[01:31:33] <mru> http://fate.multimedia.cx/index-v3.php
[01:31:48] <mfg> ty
[01:31:55] <mru> green is good, yellow is bad, red is terrible
[01:33:58] <mfg> links to revision are dead.
[01:34:14] <mru> yes, but I know it was that change
[01:34:17] <mru> I verified it
[01:34:23] <mfg> oh, i'm not disputing
[01:34:31] <mfg> i just cant see what is wrong
[01:35:27] <mfg> is this the dos build?
[01:35:37] <mru> all builds
[01:35:47] <mru> http://fate.multimedia.cx/index.php?test_result=48722030
[01:36:30] <astrange> dos and sparc failures are different
[01:42:55] <mfg> ok, how long can this stay broken before you send people to kill me?
[01:43:15] <mfg> I cant really get away to look until tuesday :(
[01:43:38] <mru> then I might revert in the meantime
[01:43:43] <mfg> ok, thats fair
[01:43:48] <mfg> sorry
[01:43:51] <mru> failing tests are bad
[01:43:53] <mfg> no doubt
[01:44:07] <mru> we built fate to catch weird stuff like this
[01:44:17] <mru> nobody expects you test a patch on all that stuff
[01:44:22] <mfg> :) phew
[01:44:25] <mfg> I feel better now
[01:44:48] <mfg> but I've bookmarked the test case, so I'll fix it soon
[01:46:36] <mfg> k, bbl with a fix (again, I apologize for breaking everything)
[02:36:55] <CIA-92> ffmpeg: mru * r22307 /trunk/ (libavcodec/iff.c libavcodec/iff.h libavformat/iff.c): IFF: move ff_cmap_read_palette() prototype to a header file
[02:36:56] <CIA-92> ffmpeg: mru * r22308 /trunk/libavcodec/alpha/ (4 files): Alpha: move dsputil prototypes to a header file
[02:36:56] <CIA-92> ffmpeg: mru * r22309 /trunk/libavcodec/arm/ (4 files): ARM: move mpegvideo prototypes to a header file
[02:36:58] <CIA-92> ffmpeg: mru * r22310 /trunk/libavcodec/ (4 files in 2 dirs):
[02:36:58] <CIA-92> ffmpeg: bfin: fix function prototypes
[02:36:58] <CIA-92> ffmpeg: Move prototypes to header files, add missing prototypes,
[02:36:58] <CIA-92> ffmpeg: make some functions static.
[02:36:59] <CIA-92> ffmpeg: mru * r22311 /trunk/libavcodec/sh4/ (dsputil_align.c qpel.c): sh4: fix about 1000 warnings
[02:36:59] <CIA-92> ffmpeg: mru * r22312 /trunk/libavcodec/sh4/ (dsputil_sh4.h dsputil_align.c idct_sh4.c dsputil_sh4.c): sh4: move dsputil prototypes to header file
[02:37:00] <CIA-92> ffmpeg: mru * r22313 /trunk/configure:
[02:37:00] <CIA-92> ffmpeg: Error on missing function prototypes with gcc
[02:37:01] <CIA-92> ffmpeg: This makes it an error to not have a prototype in scope for
[02:37:01] <CIA-92> ffmpeg: a function with external linkage. The flag is only enabled
[02:37:02] <CIA-92> ffmpeg: for gcc due to -Werror=type not working with all compilers.
[03:05:26] <peloverde> Does somebody who agrees with mans's legal opinion about variable names want to second it in the HE-AAC try 5 thread?
[03:06:38] <Dark_Shikari> done.
[03:07:46] <Kovensky> you can patent variable names? o_O
[03:07:58] <Dark_Shikari> in stupid-land, I guess
[03:10:14] <peloverde> thanks
[03:10:52] <peloverde> I think this means I'm ready to commit
[03:26:07] <MrNaz_yma> wtf
[03:26:12] <MrNaz_yma> patented variable names?
[03:26:18] * MrNaz_yma patents $i
[03:26:37] <ShadowJK> noooo, I'm using that one
[03:26:51] <MrNaz_yma> that's fine... now pay up
[03:31:01] <Dark_Shikari> I patent n.
[03:32:39] <mru> http://to./32ha
[03:32:46] <mru> best patent (application) ever
[03:32:56] <mru> "Patent Acquisition and Assertion by a (Non-Inventor) First Party Against a Second Party "
[03:32:59] <mru> aka trolling
[03:34:00] <ohsix> that'd be a sneaky way to stop patent trolling
[03:34:23] <Dark_Shikari> patent troll the patent trolls
[03:34:26] <ShadowJK> that's a strange url
[03:34:27] <Dark_Shikari> you can start an infinite recursion
[03:34:34] <Dark_Shikari> ShadowJK: to. is the best url shortener ever
[03:34:39] <ohsix> the people that do it disclaim that they are, someone had to have invented it!
[03:42:07] <CIA-92> ffmpeg: mru * r22314 /trunk/libavfilter/defaults.c:
[03:42:07] <CIA-92> ffmpeg: avfilter: make avfilter_default_free_video_buffer() static
[03:42:07] <CIA-92> ffmpeg: This function is not referenced outside this file and has no
[03:42:07] <CIA-92> ffmpeg: prototype. Feel free to flame if this is wrong.
[03:43:09] <mru> there, that's the last of them
[03:47:26] <CIA-92> ffmpeg: mru * r22315 /trunk/libavformat/ (utils.c internal.h):
[03:47:26] <CIA-92> ffmpeg: Revert "Move the probe loop from av_open_input_file() into its own method"
[03:47:26] <CIA-92> ffmpeg: This reverts r22296. This change made some files to fail to open.
[03:47:26] <CIA-92> ffmpeg: The patch submitter has promised to investigate next week.
[04:09:31] <mru> http://www.zeropaid.com/news/88284/how-will-you-get-your-internet-video-in-the-future/
[04:24:21] <peloverde> I threw up a little in my mouth when I saw the theora logo
[04:34:00] <CIA-92> ffmpeg: alexc * r22316 /trunk/ (10 files in 2 dirs):
[04:34:00] <CIA-92> ffmpeg: Add an HE-AAC v1 decoder.
[04:34:00] <CIA-92> ffmpeg: A large portion of this code was orignally authored by Robert Swain. The rest
[04:34:00] <CIA-92> ffmpeg: was written by me. Full history is available at:
[04:34:00] <CIA-92> ffmpeg: svn://svn.ffmpeg.org/soc/aac-sbr
[04:34:01] <CIA-92> ffmpeg: http://github.com/aconverse/ffmpeg-heaac/tree/sbr_pub
[04:35:45] <elenril> \o/
[04:59:35] <pross-au> Originality, eh: http://upload.wikimedia.org/wikipedia/en/3/32/CDlogo.svg
[05:05:19] <CIA-92> ffmpeg: alexc * r22317 /trunk/CREDITS: Add myself to CREDITS
[05:59:54] <aaronl> woo, he-aac
[06:03:59] <elenril> next step in world domination: -mt?
[06:50:05] <CIA-92> ffmpeg: kostya * r22318 /trunk/libavcodec/ivi_common.c:
[06:50:05] <CIA-92> ffmpeg: Scale tile dimensions in case both local decoding and scalability mode
[06:50:05] <CIA-92> ffmpeg: are used in Indeo 5 stream.
[06:50:05] <CIA-92> ffmpeg: Patch by Maxim ($indeo5dec_author)
[06:50:10] <astrange> git blame --reverse is nice...
[06:51:45] <astrange> well, maybe it is
[06:51:45] <astrange> c72f2294 (michael 2010-02-23 23:41:11 +0000 242)     int got_avcC; ///< flag used to parse avcC data only once
[06:52:06] <astrange> c72f2294 doesn't touch h264.h
[06:53:07] <astrange> ah, the one newer than that
[06:53:21] <CIA-92> ffmpeg: kostya * r22319 /trunk/libavcodec/indeo5.c:
[06:53:21] <CIA-92> ffmpeg: Make Indeo 5 decoder more robust on bitstream errors.
[06:53:21] <CIA-92> ffmpeg: Patch by Maxim ($indeo5dec_author)
[07:04:17] <astrange> enable-pthreads compile is broken :(
[07:09:50] <Dark_Shikari> siretart or siretart` : ping
[07:32:58] <superdump> peloverde: whoop!
[07:33:07] <superdump> let's see how loudly michael complains....
[07:33:17] <peloverde> you did much of the work
[07:33:27] <superdump> the monkey work maybe
[07:33:38] <superdump> read spec a bit, write what i read, rinse and repeat
[07:33:39] <peloverde> he agreed except for license conerns and "l"
[07:33:42] <superdump> and get stuff wrong
[07:33:46] <superdump> mmm
[07:33:50] <peloverde> license concerns were debunked, and "l" was fixed
[07:33:56] <superdump> license concerns? you mean about the names of variables?
[07:33:59] <peloverde> yeah
[07:34:03] <superdump> :)
[07:34:18] <superdump> (i have been following every message in the thread, i just haven't commented)
[07:34:34] <superdump> if i'd had something worth saying i'd have said it
[07:34:47] <peloverde> if you know about the msb/usb stuff feel free to chime in
[07:34:49] <Dark_Shikari> the variable names thing made me lol
[07:35:18] <superdump> peloverde: i think i did before, i remember suggesting somewhere that it was upper subband and master subband or something
[07:35:22] <superdump> and at that time you agreed
[07:35:51] <superdump> but indeed there is no description in the spec, hence why i kept the names in case we figured out what they meant at some point
[07:36:16] <superdump> i'm a little torn with the 'useful semantically obvious name' versus 'the variable name in the spec'
[07:36:48] <peloverde> I added comments to about half the context variables but kept the names
[07:36:49] <superdump> i found myself looking up in the 'glossary' wtf some things were
[07:36:52] <Dark_Shikari> you can do both
[07:36:53] <superdump> in the spec
[07:36:54] <Dark_Shikari> i.e.
[07:37:00] <Dark_Shikari> int useful_name; //stupid_spec_name
[07:37:12] <superdump> or vice versa
[07:37:27] <superdump> though useful_name is probably better to see in the code to be fair
[07:37:34] <peloverde> also, the spec has certain naming conventions that once you learn allow things to make more sense
[07:37:35] <superdump> well, i dunno
[07:37:38] <superdump> it's difficult :)
[07:37:48] <peloverde> like q_ means noise, e_ means enveleope
[07:37:48] <superdump> on one hand there's ease of comprehension
[07:38:07] <superdump> on the other there's quick referencing in the spec
[07:38:51] <peloverde> for an encoder, I'd certainly want meaningful names
[07:39:53] <astrange> is there an aac-experts?
[07:40:25] <peloverde> there is mpam and there is mp4-tech
[07:41:20] <peloverde> mpam is the official MPEG AHG on Audio Standards Maintenance reflector
[07:41:38] <peloverde> mp4-tech is the mpeg4if techincal list
[07:42:09] <peloverde> there used to be a bunch of super helpful CT people on mp4-tech, but they seem to have disappeared
[07:42:31] <superdump> mmm
[07:42:39] <superdump> maybe they consider AAC as being 'done' now
[07:43:44] <peloverde> CT needed the HE-AAC licensing money much more than dolby does
[07:54:06] <astrange> http://llvm.org/bugs/show_bug.cgi?id=6539
[07:59:32] <siretart`> Dark_Shikari: yes?
[08:00:32] <Dark_Shikari> in the interests of making the gstreamer devs pick their arses off their chairs
[08:00:36] <Dark_Shikari> I'm committing this http://pastebin.org/104787
[08:00:49] <Dark_Shikari> so, how much will this piss off the ubuntu maintainers? ;)
[08:01:23] <ohsix> "patches welcome ;)" goes both ways
[08:04:25] <siretart`> Dark_Shikari: have you tried talking to the gstreamer guys? at least bilboed was responsive to me.
[08:05:01] <Dark_Shikari> the bug report has sat still for about a month now after I committed what they asked for (the preset api)
[08:05:02] <siretart`> Dark_Shikari: in what ways are the gstreamer settings 'broken'. as in 'it doesn't work at all' or in 'the results are suboptimal'?
[08:05:10] <Dark_Shikari> they haven't been updated in 5 years
[08:05:14] <Dark_Shikari> we can't fix them because it would "break api"
[08:05:19] <Dark_Shikari> they override x264's defaults with, by and large, nonsense
[08:05:29] <Dark_Shikari> same status ffmpeg had
[08:05:36] <siretart`> and you think this change would make them act?
[08:05:45] <superdump> Dark_Shikari: blah blah
[08:05:48] <Dark_Shikari> well, and it would prevent people from accidentally using crappy settings.
[08:05:51] <Dark_Shikari> same as with ffmpeg.
[08:06:04] <superdump> i spoke to some of the gst devs and they said changing the bools to ints should be ok
[08:06:06] <Dark_Shikari> on an unrelated note, the latest email to ffmpeg-devel is hilarious.
[08:06:12] <Dark_Shikari> superdump: I'm talking about changing the defaults
[08:06:12] <siretart`> anyway, right now seems a good time to make such a change, as it won't get into lucid anywyas..
[08:06:22] <Dark_Shikari> bools->ints is minor
[08:06:23] <superdump> changing defaults to improve quality has precedent
[08:06:25] <superdump> i said that
[08:06:34] <Dark_Shikari> even if it changes the default compatibility?
[08:06:39] <Dark_Shikari> i.e. to high profile instead of baseline+cabac
[08:06:51] <superdump> baseline + cabac -> main
[08:06:59] <superdump> we can discuss that
[08:07:14] <Dark_Shikari> then let's do it.
[08:07:24] <superdump> we can at least make it output decent quality by default even if the defaults don't match x264
[08:07:34] <Dark_Shikari> Let's make them match x264's.
[08:08:04] <superdump> we can try to do that, but maybe some will be objectionable
[08:08:06] <superdump> we'll see
[08:08:06] <Dark_Shikari> making 5% of users update their settings is justified by improving it for the other 95%.
[08:08:18] <superdump> if you can make a patch, it would be appreciated
[08:08:32] <Dark_Shikari> I don't even have a system to test gstreamer on
[08:08:38] <Dark_Shikari> I don't have gui access to any linux box
[08:08:57] <ohsix> vmware?
[08:09:04] <siretart`> why do you argue then so strongly about gstreamer at all then?
[08:09:07] <Dark_Shikari> linux ran bad enough on my laptop outside of a VM
[08:09:17] <Dark_Shikari> siretart`: because we are in part responsible for the major programs that use x264
[08:09:21] <Dark_Shikari> if they make x264 suck, it damages us
[08:09:52] <ohsix> heh is that supposed to be some sort of final statement on linux? vmware will run completely different in any regard to your laptop
[08:10:02] <Dark_Shikari> ohsix: no, I'm saying I have an ATI graphics card
[08:10:16] <siretart`> bitching very vocally against an downstream or upstream is not going to improve the relationship
[08:10:17] <Dark_Shikari> I have ubuntu installed, it just doesn't work with my LAN, my wireless, or graphics
[08:10:26] <Dark_Shikari> siretart`: it worked with ffmpeg.
[08:10:32] <siretart`> ffmpeg is special
[08:10:36] <Dark_Shikari> troll-driven development
[08:10:43] <ohsix> vmware has a "VMWare II VGA" card; linux likes it
[08:10:57] <Dark_Shikari> hmm, I actually should try vmware, it would be nice to have a linux gui handy.
[08:11:05] <ohsix> its really nice
[08:11:20] <ohsix> for keeping different versions of windows too; and snapshots to unfuck stuff
[08:11:34] <superdump> Dark_Shikari: then code blindly, spam me the changes and i'll try it when i get time
[08:11:54] <superdump> even if you do that i can see better what is _wrong_ with respect to x264
[08:11:55] <Dark_Shikari> superdump: ok, but let's pick a soultion first
[08:12:00] <superdump> it's a starting point
[08:12:07] <Dark_Shikari> the solutions I can see:
[08:12:16] <Dark_Shikari> 1) least preferable: sync the gstreamer defaults up to x264
[08:12:29] <Dark_Shikari> 2) preferable option 1: have a DEFAULT option which doesn't set the parameter.
[08:12:40] <Dark_Shikari> 3) preferable option 2: use strings and param_parse
[08:13:06] <superdump> mmm
[08:13:27] <ohsix> you have the most cred in your name with relation to x264, you could have just sent a patch to remove a bunch of stuff and it probably would have got applied; i dunno how gstreamers freezes work though, you might just be tilting at windmills until post release (and its been frozen for quite a while)
[08:13:39] <Dark_Shikari> freeze ends very soon.
[08:14:08] <ohsix> that was more in reference to the "ignored for weeks" relating to the bug
[08:14:16] <Dark_Shikari> Ahh, ok
[08:14:19] <superdump> not really ignored
[08:14:31] <superdump> just neglected due to other shit being more important for the people involved i guess
[08:14:35] <ohsix> yea
[08:14:50] <superdump> i'm not actively not looking at it
[08:14:52] <siretart`> I guess a bug with proper impact analysis and thorough explanation of the proposed change would help as well. - it's work to do that, though.
[08:14:53] <superdump> i just have to work
[08:15:10] <ohsix> it sucks, i want my bugs fixed too D:
[08:15:14] <Dark_Shikari> meh.  maybe once we get money we can offer bounties for these things.
[08:15:25] <ohsix> the ones i've had are work i cant hope to do though
[08:15:36] <KotH> moin boys and girls
[08:15:41] <Dark_Shikari> you know, what I think we need is a trade system.
[08:15:49] <Dark_Shikari> project A needs things fixed/added in Project B
[08:15:55] <Dark_Shikari> project B needs things fixed/added in project A
[08:16:09] <Dark_Shikari> trade fixes.  a bug for a bug.  a feature for a feature.
[08:16:18] <superdump> that's just called collaboration
[08:16:25] <Dark_Shikari> Yeah, but that's ignored so often :/
[08:16:26] <ohsix> theres no comparative value and rarely comparative time and effort for little things
[08:16:54] <ohsix> you just need to do it and get some cred; and next time someone recognizes your name and can help with what you're asking about they'll do it
[08:16:56] <superdump> if people put their egos in the drawer and try to work together constructively rather than be rigid and stubborn...
[08:17:08] * ShadowJK wonders if libmp3lame and ffmpeg are still in stalemate
[08:17:27] <superdump> anyway
[08:17:30] * superdump works
[08:17:51] <astrange> ffmpeg lame encoder hasn't been touched in my memory
[08:18:09] <astrange> i wish it used the vbr presets, but i think those might be in the lame frontend
[08:18:32] <ShadowJK> iirc you need to downgrade lame now?
[08:19:01] <Dark_Shikari> buffer too small, etc, etc
[08:19:35] <ShadowJK> yes
[08:23:03] <peloverde> superdump: I explained exactly what needs to be done for AAC in constructive terms and gstreamer still calls our aac decoder broken
[08:23:23] <superdump> :/
[08:23:55] <superdump> i don't remember the bugzilla ticket
[08:24:16] <superdump> do you have it?
[08:24:43] <Dark_Shikari> it's much easier to just call an upstream library "broken" as opposed to telling them what they need to do to fix it.
[08:25:12] <Yuvi> I asked about lavf api and just got "lavf demuxers are poor quality"
[08:25:20] <Yuvi> so eh
[08:25:47] <Dark_Shikari> which is ironic because their demuxing/muxing libraries are quite often much worse...
[08:26:10] <Dark_Shikari> but hey, it's easier to just call things broken instead of saying how to fix them.
[08:26:34] <ohsix> is there an objective measure of this stuff somewhere
[08:26:56] <Dark_Shikari> ohsix: cat /dev/urandom | head --bytes=1
[08:27:00] <Dark_Shikari> that's a measure of quality for a demuxer ;)
[08:28:10] <Yuvi> Dark_Shikari: worse and 3x the LoC ;)
[08:28:26] <Dark_Shikari> but more loc is better duh
[08:28:58] <peloverde> superdump: https://bugzilla.gnome.org/show_bug.cgi?id=566250
[08:32:01] <ohsix> who's mike in there?
[08:32:12] <astrange> well that is kinda pushing codec knowledge into the client
[08:32:22] <astrange> maybe the parser should die if there's extradata?
[08:32:28] <peloverde> "The ffmpeg AAC decoder isn't complete, and there's no way to figure out before decoding whether it will support the given stream or not. We therefore set it to NONE until it can handle the full specs."
[08:33:29] <ohsix> kind of a tangent, but i've found that people generally cant reproduce things as they are on someone elses gentoo machine; so it makes things harder to test, and some people ignore it outright, not that this problem has anything to do with it
[08:34:31] <peloverde> of course they conveniently don't mention in that comment that they choose to mangle the AAC frames by running the parser of them unnecessarily, and then wind up with bitstreams that signal features from profiles that no one uses
[08:34:52] <Dark_Shikari> ohsix: well, that's what gentoo does
[08:35:16] <ohsix> some stuff can be more insidious though; and having the software you're not testing "stable" for some definition of stable, while the bug is being looked at can help at least more quick checks and "this happens here" stuff that can help move it along
[08:36:00] <ohsix> i know what gentoo does, you just cant give an up or down if you dont know if you've reproduced the environment in where the failure is exhibited with any confidence
[08:36:56] <Dark_Shikari> I know, I've had the experience myself
[08:37:13] <ohsix> debootstrap can give you debian/ubuntu stable/unstable on any lunix though; so its easy enough, at least for this junk; ui stuff canbe really confusing in a chroot
[08:43:02] <superdump> peloverde: i pinged it at least
[08:43:06] <peloverde> thanks
[08:43:10] <peloverde> Has anyone looked into smart fuzzers at all?
[08:43:11] <superdump> i'll nudge bilboed in a bit
[08:43:16] <superdump> aha
[08:43:20] <superdump> bilboed: hello :)
[08:43:22] <Dark_Shikari> peloverde: I know a guy who wrote a very smart fuzzer
[08:43:28] <Dark_Shikari> he's using it on quicktime to create exploits
[08:43:41] <Dark_Shikari> it can automatically find bugs, and then modify the input file to create a minimal test case
[08:43:48] <peloverde> I've looked at catchconv but it's brittle an unmaintained
[08:44:01] <Dark_Shikari> he's already found multiple zerodays
[08:44:05] <ohsix> hocevar has zzuf and that other guy (name forthcoming)  has one too
[08:44:08] <CIA-92> ffmpeg: benoit * r22320 /trunk/libavcodec/targaenc.c:
[08:44:08] <CIA-92> ffmpeg: targeenc: fix rgb555 encoding on big endian systems.
[08:44:08] <CIA-92> ffmpeg: Patch by Alexis Ballier gmail_address(name, surname)
[08:44:11] <peloverde> now that the AAC decoder seems immune to zzuf, smart fuzzing seems to be the next step
[08:44:24] <Dark_Shikari> I can harass him to try his smart fuzzer on ffmpeg at some point
[08:44:38] <Dark_Shikari> he's apparently going to try to add a feature to automatically attempt creation of exploits
[08:44:53] <KotH> peloverde: what's smart fuzzing?
[08:45:43] <peloverde> KotH, a smart fuzzer observes a programs control flow and then specifically fuzzes a stream to fuck with it
[08:46:27] <bilboed> Dark_Shikari, is that fuzzer available somewhere ?
[08:46:34] <Dark_Shikari> bilboed: he hasn't open sourced it, but I could ask him for it
[08:46:42] <Dark_Shikari> he probably won't give it away publicly but who knows
[08:46:49] <Dark_Shikari> he found an utterly hysterical exploit in quicktime
[08:46:49] <peloverde> So if the program takes branch A, the smart fuzzer would adjust the input to make it take B
[08:46:53] <Dark_Shikari> that requires only 3 bytes of data
[08:46:58] <ohsix> http://lcamtuf.coredump.cx/ tmin + bunny for fuzzing from this guy
[08:48:21] <ohsix> heh, blurb for bunny: Uses compiler-level integration to seamlessly inject precise and reliable instrumentation hooks into the traced program. These hooks enable the fuzzer to receive real-time feedback on changes to the function call path, call parameters, and return values in response to variations in input data.
[08:48:34] <astrange> quicktime runs jailed in most situations on 10.6
[08:48:48] <astrange> probably not protected (besides stack guards) on windows which has much more marketshare, of course
[08:48:53] <Dark_Shikari> astrange: exactly
[08:49:01] <Dark_Shikari> don't need to crack open OS X, just go for windows
[08:49:11] <KotH> peloverde: hmm.. interesting
[08:49:13] <KotH> peloverde: thanks
[08:49:22] <Dark_Shikari> the primary target is really really old qt codecs
[08:49:24] <Dark_Shikari> like QTVR
[08:49:33] <Dark_Shikari> that haven't been updated in 20 years and are probably filled with holes
[08:49:37] <astrange> i think those are actually turned off now
[08:49:44] <astrange> the encoders are at least
[08:49:48] <astrange> (on os x again)
[08:49:49] <Dark_Shikari> encoders, sure
[08:49:54] <Dark_Shikari> but decoders is all that matters
[08:50:07] <superdump> peloverde: in the ticket, only mkv, mp4 and adts are discussed
[08:50:27] <superdump> does the statement about adts frames stuffed into another container hold for other containers?
[08:50:32] <superdump> e.g. ts and so on?
[08:50:41] <superdump> if it's possible to put adts into ts
[08:50:46] <peloverde> it should as long as the demuxer can chunk things into single frames
[08:51:22] <superdump> so the demuxer has to strip adts headers or so?
[08:51:29] <peloverde> no it doesn't need to
[08:51:48] <peloverde> we always check for an ADTS header at the start of every frame
[08:52:08] <superdump> what about multiple rdb per frame with all rdbs sent in one buffer?
[08:52:30] <superdump> but with those buffers/chunks being contained in mkv or so
[08:53:01] <peloverde> multiple RDBs depends on how the calling app works
[08:53:09] <peloverde> we return the number of bytes read
[08:53:24] <peloverde> so if CRC is off with multiple RDBs i think it should work
[08:53:30] <peloverde> if not it's a trivial hack
[08:53:47] <peloverde> I could code something up in 15 minutes
[08:54:14] <peloverde> That said, I don't really multiple RDBs in the wild
[08:54:22] <peloverde> I haven't gotten any complaints anyway
[08:56:33] <pross-au> what is an RDB?
[08:56:50] <peloverde> I saw some crazy header stuff in gstreamer that I think is for aac on openmax, I imagine if you can do that, ffmpeg's should be trivial
[08:57:18] <peloverde> pross-au: Raw Data Block, it's basically one AAC frame, up to 4 RDBs can go in one ADTS frame
[08:57:26] <peloverde> but most people stick with 1:1
[08:57:34] <pross-au> wilco
[09:04:16] <CIA-92> ffmpeg: mstorsjo * r22321 /trunk/ (11 files in 2 dirs):
[09:04:16] <CIA-92> ffmpeg: Rename url_split to ff_url_split
[09:04:16] <CIA-92> ffmpeg: Since this function isn't in the public API, it should have an ff_ prefix.
[09:05:51] <CIA-92> ffmpeg: mstorsjo * r22322 /trunk/libavformat/ (7 files): Reindent
[09:08:29] <CIA-92> ffmpeg: mstorsjo * r22323 /trunk/libavformat/avformat.h: Add doxygen documentation for ff_url_split
[11:38:01] <elenril> av500: that's your patch with asf chapters?
[11:39:46] <av500> elenril: yup
[11:40:42] <elenril> nice
[11:40:55] * elenril should write chapters muxing for asfenc
[11:41:29] <elenril> btw why don't you just use url_fskip?
[11:41:44] <av500> because I am a novice ffmpeg hacker :)
[11:42:02] <av500> so I just c6p code I find at other places ...
[11:42:05] <av500> c&p
[12:56:44] <CIA-92> ffmpeg: andoma * r22324 /trunk/libavcodec/pthread.c: Make avcodec_thread_execute2() static
[12:59:01] <CIA-92> ffmpeg: andoma * r22325 /trunk/libavcodec/w32thread.c: w32thread: Make avcodec_thread_execute2() static here as well
[13:14:07] <CIA-92> ffmpeg: benoit * r22326 /trunk/libavformat/ (asf.c asf.h asfdec.c):
[13:14:07] <CIA-92> ffmpeg: Use ASF supports "markers" which are a name and a time stamp to create
[13:14:07] <CIA-92> ffmpeg: lavf chapters.
[13:14:07] <CIA-92> ffmpeg: Patch by Vladimir Pantelic pan (arobase) nt tu (dash) darmstadt de
[13:50:47] <superdump> we probably need to clean up our soc stuff on the wiki
[13:50:54] <superdump> i think applications opened today
[13:51:04] <av500> benoit-: thx!
[13:53:21] <av500> elenril: I can also take a shot at writing asf chapters...
[13:54:46] <benoit-> av500: what for ?
[13:59:07] <av500> [14:14] <CIA-92> ffmpeg: benoit * https://subversion/trac/avx/changeset/22326 /trunk/libavformat/ (asf.c asf.h asfdec.c):
[14:04:37] <KotH> does ffmpeg support wma losless?
[14:04:44] * KotH cannot find anyrefernece
[14:06:55] <av500> dont think so
[14:08:43] <elenril> av500: sure, go ahead
[14:08:48] <elenril> should be easy
[14:08:53] <av500> yes
[14:22:42] <superdump> we don't have an ffmpeg page on the gsoc site for 2010 either
[14:23:03] <superdump> oh
[14:23:08] <superdump> maybe i was looking in the wrong place
[14:45:49] <pJok> mornings
[14:46:05] <KotH> afternoons
[14:46:13] <kshishkov> god kväll, tror jag
[14:46:44] <wbs> kshishkov: det är väl nog bara eftermiddag ännu :-)
[14:48:24] <kshishkov> wbs: ja, vi har samma tiden som FInland men det är inte så rolig
[14:48:53] <pJok> ;)
[14:49:46] * pJok grmbls about wmv3 in mov containers
[14:50:04] <pJok> and swscalar complaining about it
[14:50:12] <pJok> swscaler*
[14:50:14] <kshishkov> jar, wmv3 i mov är högsta kvälitat dynga
[14:50:19] <mru> swscalar and swvector?
[14:50:37] <mru> kshishkov: kvalitet
[14:50:39] <kshishkov> swmatrix and swtensor too
[14:50:46] <pJok> kshishkov, gotta love flip4mac ;)
[14:51:00] <mru> matrixes and tensors are just generalised vectors
[14:51:01] * pJok blames that piece of software for the wmv3 in a mov
[14:51:18] <kshishkov> mru: thanks, I don't have occasions to practice my Swedish though :(
[14:51:19] * mru doesn't use software with a 4 in the name
[14:51:27] <pJok> just wondering why it complains about the input pixel format
[14:51:39] <kshishkov> because of wrong format
[14:51:54] <kshishkov> F4M actually writes WMV3-in-ASF-in-MOV
[14:52:01] <kshishkov> we had a roundup issue for it
[14:52:02] <mru> eew
[14:52:03] <pJok> can i kick it in the shins with something?
[14:52:39] <KotH> pJok: use an ICBM
[14:52:45] <KotH> pJok: anything less isnt apropriate
[14:53:05] <av500> kshishkov: http://www.youtube.com/view_play_list?p=1C0729201AA0A91A&search_query=collorados
[14:53:17] <kshishkov> pJok: https://roundup.ffmpeg.org/issue875
[14:54:23] <kshishkov> av500: so you're finally try to learn Ukrainian?
[14:54:40] <av500> :)
[14:54:51] <pJok> kshishkov, i see noone bothered doing more about it, so i just need to shoot F4M then
[14:54:59] <av500> no, I had to en[joy|dure] that for a week
[14:55:23] <mru> enjure
[14:55:27] <kshishkov> av500: and if you wonder, it's the way people speak English here (if they dare to speak it at all)
[14:55:44] <av500> mru: luckily, nobody got enjured...
[14:55:53] <kshishkov> pJok: either add demuxer chaining to FFmpeg or shoot F4M. Preferably both
[14:56:04] <av500> kshishkov: so if I replace some words with codec speak, I can hear you?
[14:56:11] <mru> injure: what sadists do
[14:56:34] * pJok takes some of KotHs ICBMs and uses them on F4M
[14:56:59] <kshishkov> av500: yes, just make sure it pronounces all three letters in word "the" separately ;)
[14:57:17] <kshishkov> av500: or you can ask mru, I've speaked to him twice
[14:57:29] <av500> he survived
[14:57:47] <kshishkov> pJok: don't forget to make a collateral damage to Redmond
[14:58:02] <av500> kshishkov: btw, are they popular in .ua?
[14:58:45] <kshishkov> probably not, I try to avoid "popular" stuff here in order to not commit suicide
[14:59:45] <pJok> kshishkov, i have special "packets" for them in store...
[15:13:26] <CIA-92> ffmpeg: mstorsjo * r22327 /trunk/libavcodec/ppc/check_altivec.c:
[15:13:26] <CIA-92> ffmpeg: Move the local includes below the system includes
[15:13:26] <CIA-92> ffmpeg: This fixes a compilation issue on OS X 10.4, where some system headers were
[15:13:26] <CIA-92> ffmpeg: included implicitly through dsputil_altivec.h (with _POSIX_C_SOURCE defined),
[15:13:26] <CIA-92> ffmpeg: and other system headers included later, with _POSIX_C_SOURCE undefined at
[15:13:27] <CIA-92> ffmpeg: that time.
[15:13:36] <kshishkov> yay
[15:13:46] <wbs> kshishkov: varsågod :-)
[15:14:01] <wbs> and thanks to mru for pointing out the obvious fix ;P
[15:14:03] <kshishkov> tack så mycket
[15:14:31] * mru wonders who might look at his ffserver patch
[15:15:34] <wbs> mru: I'll add my thoughts on it
[15:16:04] <mru> it's practically untested btw
[15:16:28] <mru> it builds and the (broken) regression test does something
[15:16:31] <kshishkov> so is FFserver itself ;)
[15:41:32] <superdump> mru: in response to your HE AAC thread message - maybe we should ask the Xiph guys to rewrite that hunk of code to avoid any legal problems? </blatant troll>
[15:42:16] <kshishkov> or file a patent on using variables named "i" and "j" in loops
[15:42:59] <BBB___> filing patent seems better
[15:43:06] <superdump> :)
[15:43:33] <mru> claims:
[15:43:36] <mru> 1. a loop
[15:43:55] <mru> 2. a loop as in (1) also comprising usage of a variable designated "i"
[15:44:07] <mru> 3. a loop as in (2) containing an inner loop
[15:44:14] <av500> 4. profit
[15:44:16] <mru> 4. a loop as in (3) also comprising usage of a variable designated "j"
[15:45:54] <kshishkov> then sue Ateme, subpoena their source code and improve x264 with it ;)
[15:47:13] <kierank> subpoena dolby as well kshishkov kthx
[15:48:29] * kshishkov is rather proud there's no direct translation of term "subpoena" into Ukrainian
[15:50:32] <mru> kshishkov: I think the ukrainian translation involves use of a shovel
[15:51:50] <kshishkov> mru: no, it expands to a longish phrase in local equivalent of Legalese
[15:52:09] <av500> kshishkov: how boring
[15:52:36] <kshishkov> av500: yes, this country copied German bureaucracy back in XIX century
[15:54:29] <kshishkov> well, for example Ukrainian word for "central post office" is "poshtamt". Guess why even one-man queues here take at least 30 minutes to serve
[15:57:27] <av500> kshishkov: here they got rid of most of the poshtamts :)
[15:57:58] <kshishkov> what about the legendary job title "beamter"?
[15:58:07] <av500> still to many of them ....
[15:58:23] <kshishkov> effective as ever?
[16:00:30] <av500> sure
[16:01:13] <kshishkov> now imagine it and multiply on local ability to do everything via /dev/ass
[16:03:52] * kshishkov forgot to add "happy nightmares"
[16:34:11] <kierank> does latm go in anything else apart from transport streams?
[16:34:49] <mru> what spec defines latm?
[16:34:56] <jez9999> BBB: Hi.  So, you think there's any chance of the patch for issue 1740 getting checked in?
[16:36:27] <kierank> mru: 14496-3  apparently
[16:36:50] <janneg> MPEG-4 Part 3
[16:37:09] <mru> then it's not tied to TS as such
[16:37:36] <mru> being the obnoxious crap it is, I doubt it's used a lot though
[16:37:46] <mru> aside from the few broadcasters who use it only to annoy
[16:41:57] <BBB> jez9999: it fell off my radar, I replied
[16:43:43] <j0sh> im having trouble with the theora depayloader
[16:45:46] <j0sh> i get a lot of this http://pastie.org/859776
[16:47:06] <j0sh> theora is supposed to get most of its config info through the sdp/ftmp, but the decoder isn't making use of that, and its getting its info somewhere else (prob the rtp itself)
[16:48:07] <j0sh> what i think is interesting is that even feng will print out this:
[16:48:09] <j0sh> [theora @ 0x9685530]7 bits left in packet 82
[16:48:45] <j0sh> is it possible that there's a bug in the feng packetizer?
[16:50:14] <j0sh> the video will play OK after a few seconds, but the first few are lost
[16:52:25] <BBB> is it a live stream?
[16:52:32] <BBB> it could just be you're getting incomplete packets in the beginning
[16:53:09] <j0sh> not live, feng should be serving up a local file
[16:53:26] <BBB> try another packetizer
[16:53:28] <BBB> e.g. gstreamer
[16:55:11] <j0sh> alright
[16:59:05] <BBB> mru: is resolve_host() part of our public API?
[16:59:11] <mru> no
[16:59:12] <BBB> mru: I think not, but just checking
[16:59:18] <BBB> mru: otherwise patch ok for me
[16:59:22] <mru> it's under ifdef HAVE_AV_CONFIG_H
[16:59:29] <BBB> (since there's no ffserver.c maintainer)
[16:59:50] <BBB> and thanks for cleaning up that cruft
[17:01:10] <CIA-92> ffmpeg: diego * r22328 /trunk/tools/trasher.c:
[17:01:10] <CIA-92> ffmpeg: Add missing stdlib.h #include, fixes the warnings:
[17:01:10] <CIA-92> ffmpeg: tools/trasher.c:44: warning: implicit declaration of function ?atoi?
[17:01:10] <CIA-92> ffmpeg: tools/trasher.c:53: warning: implicit declaration of function ?abs?
[17:32:59] <kierank> lol mpeg-la say they probably have patents on ogg
[17:33:07] <mru> :-)
[17:33:08] <kshishkov> container?
[17:33:11] <mru> you asked them?
[17:33:14] <kshishkov> good riddance!
[17:33:16] <kierank> http://www.streamingmedia.com/article.asp?id=11746
[17:34:49] <mru> that seems to be about theora
[17:35:42] <kierank> hmm yes he seems to be calling theora ogg
[17:35:58] * mru nukes xiph from orbit
[17:35:59] <kshishkov> what do you expect from lawyers?
[17:36:05] <mru> it's xiph's fault
[17:36:14] <mru> they use ogg and theora/vorbis interchangably
[17:37:12] <kshishkov> and Vorbis is not that bad unlike the rest
[17:37:53] <mru> vorbis could easily be made sane
[17:38:11] <mru> just define a few arbitrary limits on certain elements
[17:38:53] <kshishkov> BTW, how's Ghost?
[17:39:03] <mru> what is ghost?
[17:39:09] <kshishkov> Vorbis II
[17:39:10] <mru> I've heard it mentioned a few times recently
[17:39:25] <kshishkov> (quite a descriptive name, ain't it?)
[17:39:36] <twnqx> no he didn't, at some point he even says "theora, the lossy video codec in the ogg..."
[17:40:06] <mru> twnqx: whatever the exact wording, that article is about theora and only theora
[17:40:25] <twnqx> which they consider part of the "ogg universe", which is fine with me
[17:40:45] <twnqx> but yeah, i thought for a moment they really mean parts of the container could be patented
[17:41:05] * twnqx wonders if indexes are patented and hence missing in ogg
[17:42:42] <kshishkov> twnqx: maybe it's sanity that is patented?
[18:34:19] <BBB> guys, we need a list of people willing to do consulting work on FFmpeg
[18:35:50] <Compn> a list of ffmpeg mercenaries?
[18:35:52] <Compn> hehe
[18:35:58] <Compn> soldiers of fortune
[18:37:00] <kshishkov> isn't mru enough?
[18:37:13] <Compn> he only takes highest paying jobs
[18:37:25] <BBB> kshishkov: do you want to do consulting?
[18:37:47] <mru> BBB: it's not the first time that idea comes up
[18:37:48] <kshishkov> nah, it's a hell to do any official work here
[18:37:57] <BBB> mru: I know
[18:38:01] <BBB> mru: hence my suggestion
[18:38:21] <mru> and we shouldn't restrict it to ffmpeg development
[18:39:10] <BBB> true
[18:39:30] <BBB> do you want to post hourly rates?
[18:39:43] * BBB is quite sure that there's huge differences
[18:39:52] <mru> no, that's better to negotiate directly with clients
[18:40:20] <BBB> shall I send out an email to the list so people can say "I want on this list"?
[18:40:25] <mru> besides, if you need to ask about my rates, you can't afford them
[18:43:40] <mru> time for another commit flood
[18:43:44] <kshishkov> well, one can hire a lot of Chinese/Indian/Ukrainian workers instead ;)
[18:44:05] <mru> no, that doesn't work
[18:44:11] <kshishkov> and one will be extremely lucky to get desired result from them too
[18:44:19] <CIA-92> ffmpeg: mru * r22329 /trunk/ (ffserver.c libavformat/os_support.c libavformat/avformat.h):
[18:44:19] <CIA-92> ffmpeg: Move resolve_host() to ffserver.c
[18:44:19] <CIA-92> ffmpeg: This deprecated function is only used by ffserver, yet does not have
[18:44:19] <CIA-92> ffmpeg: a prototype visible there.
[18:44:19] <CIA-92> ffmpeg: In the long term, ffserver should be made IPv6-aware. In the meantime,
[18:44:19] <mru> parallel intelligence works like resistors
[18:44:20] <CIA-92> ffmpeg: this change removes cruft from lavf and fixes some warnings in ffserver.
[18:44:21] <CIA-92> ffmpeg: mru * r22330 /trunk/subdir.mak: Define HAVE_AV_CONFIG_H when building test apps
[18:44:21] <CIA-92> ffmpeg: mru * r22331 /trunk/libavcodec/ (dct-test.c dctref.c dctref.h): Move dctref prototypes to a header file
[18:44:22] <CIA-92> ffmpeg: mru * r22332 /trunk/subdir.mak: Define HAVE_AV_CONFIG_H for checkheaders in libs
[18:44:23] <CIA-92> ffmpeg: mru * r22333 /trunk/ (Makefile common.mak): Skip cmdutils_common_opts.h fragment in checkheaders
[18:44:23] <CIA-92> ffmpeg: mru * r22334 /trunk/libavcodec/dct-test.c: Remove unused fast_memcpy() function in dct-test
[18:44:24] <CIA-92> ffmpeg: mru * r22335 /trunk/ (Makefile common.mak subdir.mak libavcodec/Makefile): Add TESTOBJS make variable for extra objects used by test apps
[18:44:24] <CIA-92> ffmpeg: mru * r22336 /trunk/libavcodec/Makefile: Skip the tablegen fragments in checkheaders
[18:44:25] <CIA-92> ffmpeg: mru * r22337 /trunk/ (8 files in 2 dirs): Add lots of missing includes
[18:44:42] <kshishkov> you mean IQ of a crowd?
[18:45:28] <mru> 1/IQ_group = 1/sum(IQ_individual)
[18:45:39] <mru> and that's optimistic
[18:45:50] <kshishkov> no, it's = 1 /min(IQ_individual)
[18:45:53] <mru> often it's closer to IQ_group = IQ_min/group_size
[18:46:16] <kshishkov> yes, that's true
[18:46:30] <mru> adding people to a group cannot make the group as a whole smarter
[18:46:53] <BBB> people, people
[18:46:58] <kshishkov> but it can make it slower
[18:47:14] <BBB> I wanted to suggest setting up a list of consultants for FFmpeg on the website
[18:47:25] <mru> two equally smart people are certainly more productive than one
[18:47:38] <mru> but they won't be able to solve problems too difficult for either of them alone
[18:47:46] <mru> BBB: agree
[18:48:21] <kshishkov> mru: a Russian equivalent of "great minds think alike" is "fools have the same thoughts"
[18:48:46] <kshishkov> BBB: ok, now go finds consulting wannabees
[18:49:12] <mru> german: zwei dumme, ein gedanke
[18:50:04] <kshishkov> yes, quite the same
[18:52:14] <Dark_Shikari> Yuvi: not to harass you or anything, but just curious if you've found any of those crashes or infiniteloops
[18:55:30] <CIA-92> ffmpeg: mru * r22338 /trunk/libavcodec/Makefile:
[18:55:30] <CIA-92> ffmpeg: Skip mpegaudio3.h in checkheaders
[18:55:30] <CIA-92> ffmpeg: This unused header is a placeholder for work in progress(?).
[18:55:30] <CIA-92> ffmpeg: This makes checkheaders pass again.
[19:00:57] <CIA-92> ffmpeg: mru * r22339 /trunk/libavcodec/dct-test.c: ARM: fix dct-test
[19:34:47] <wbs> BBB: found the rtsp control_uri case, it's 1697.. but the test urls there aren't available anymore
[19:39:51] <BBB> let me see what I can find
[19:55:02] <CIA-92> libswscale: reimar * r30863 /trunk/libswscale/utils.c: Fix memleak due to incorrect VirtualFree arguments: size must be 0 for MEM_RELEASE.
[19:55:03] <CIA-92> libswscale: reimar * r30864 /trunk/libswscale/utils.c: Check for allocation failure for c->lumMmx2FilterCode and c->chrMmx2FilterCode.
[20:00:48] <CIA-92> ffmpeg: mru * r22340 /trunk/ (3 files in 2 dirs): ARM: add some missing includes
[20:18:38] <CIA-92> ffmpeg: mru * r22341 /trunk/ (Makefile common.mak libavutil/Makefile):
[20:18:38] <CIA-92> ffmpeg: checkheaders: skip per-arch headers not meant for direct inclusion
[20:18:38] <CIA-92> ffmpeg: Some of the per-arch headers are only meant to be used through
[20:18:38] <CIA-92> ffmpeg: the parent header of the same name. Testing these standalone
[20:18:38] <CIA-92> ffmpeg: does not make sense.
[20:18:39] <CIA-92> ffmpeg: mru * r22342 /trunk/libavcodec/ (bfin/dsputil_bfin.h sh4/dsputil_sh4.h): Add missing includes in bfin and sh4 files
[20:45:02] <BBB> peloverde: do you (want to) do contracting work?
[20:45:17] <peloverde> BBB: yes
[20:45:50] <BBB> ok, b/c I just recommended you and wanted to make sure I wasn't mistaken ;)
[20:45:58] <BBB> add yourself to the list also
[20:47:19] <peloverde> I will add myself, I was going to wait a few hours so I didn't stab others in the face with SVN merge conflicts
[20:58:31] <CIA-92> ffmpeg: bcoudurier * r22343 /trunk/ (libavformat/mpegtsenc.c tests/ref/lavf/ts): 10l typo, fix ts total bit rate computation
[20:59:49] <CIA-92> ffmpeg: bcoudurier * r22344 /trunk/ (libavformat/mpegtsenc.c tests/ref/lavf/ts): Start continuity counter at 0 for streams
[21:01:38] <BBB> I haven't seen him on IRC for a while...
[21:04:20] <Kovensky> we all miss his onjoin script don't we
[21:20:44] <CIA-92> ffmpeg: mru * r22345 /trunk/ (9 files in 2 dirs): Move ff_sqrt() to libavutil/intmath.h
[21:24:49] <Yuvi> Dark_Shikari: haven't fixed any yet (one appears to be a buffer overrun in mpeg4enc?)
[21:27:51] <Dark_Shikari> o.0
[21:27:58] <Dark_Shikari> that's interesting, because it didn't crash in other tests
[21:28:03] <Yuvi> seed 6 and 12 at least
[21:28:06] <Yuvi> 9 and 12
[21:28:14] <Yuvi> 6 didn't crash for me
[21:28:26] <Dark_Shikari> well I have so many seeds that are crashing that it doesn't matter if a few are missed =p
[21:29:46] <CIA-92> ffmpeg: mru * r22346 /trunk/libavutil/ (attributes.h Makefile common.h): Move gcc attribute macros to new header libavutil/attributes.h
[21:29:47] <CIA-92> ffmpeg: mru * r22347 /trunk/libavutil/common.h: Merge two adjacent ifdef blocks
[21:29:47] <CIA-92> ffmpeg: mru * r22348 /trunk/libavutil/common.h: cosmetics: indent
[21:30:41] <Yuvi> j0sh: you're writing the extradata the same way as rtpdec_vorbis ?
[21:32:52] <Yuvi> Dark_Shikari: maybe it gets exposed because of how vp3.c leaks AVFrame on errors?
[21:33:26] <Dark_Shikari> ahhh
[21:33:29] <Dark_Shikari> yeah in fact that could be the problem
[21:33:33] <Dark_Shikari> we need to fix that
[21:33:38] <Dark_Shikari> it's flooding the logs with errors
[21:33:45] <Dark_Shikari> and probably hiding real problems
[22:08:24] <BBB> wbs: so to get the rtsp uri, you need to get a fresh session key first, did you run the command in his top post?
[22:09:54] <BBB> oh wait I see it's dead
[22:09:56] <BBB> let me get another uri
[22:11:20] <BBB> wbs: try "rtsp://s53wm.castup.net/990310001-52.wmv?ct=US&rg=US&aid=31&st=0&ts=0&cu=B7A1F7D1-1218-41D8-ACF5-4B01313D3528"
[22:16:56] <CIA-92> ffmpeg: mru * r22349 /trunk/libavutil/avstring.h: More descriptive names for av_stristr() parameters
[22:44:56] <CIA-92> ffmpeg: bcoudurier * r22350 /trunk/ (libavformat/mpegtsenc.c tests/ref/lavf/ts): Start continuity counter at 0 for pmt as well
[23:12:12] <`md> lol bcoudurier knows about 10l? amazing
[23:12:41] <mru> how so?
[23:12:46] <mru> he's been around long enough
[23:14:47] <`md> i guess so
[23:34:40] <Dark_Shikari> ramiro: ping
[23:38:29] <ramiro> Dark_Shikari: pong
[23:38:55] <Dark_Shikari> ramiro: I have someone (a company) that wants help with building on windows
[23:39:04] <Dark_Shikari> they want your email or some other way to contact you
[23:40:13] <ramiro> hmm, if they failed to find my e-mail themselves that's bad (for me)... I should make it clearer on the website.
[23:40:38] <Dark_Shikari> they might be being lazy.  but you should do that anyways
[23:40:44] <Dark_Shikari> also, they're a major partner of x264, so we care
[23:40:57] <Dark_Shikari> (and a major user of ffmpeg, esp. on windows)
[23:41:01] <Dark_Shikari> in client-side applications
[23:42:49] <ramiro> I'm kind of paranoid about giving out my e-mail address so easily. it can be easily found, but I've had a personal e-mail account (msn messenger too) made unusable because I shipped the address along with ml20rc.msnfanatic.com
[23:43:06] <ramiro> and that brought a horde of annoying people towards me...
[23:43:15] <Dark_Shikari> makes sense
[23:44:07] <ramiro> worse yet it was released prominently in a spanish language forum...
[23:44:20] <Dark_Shikari> :/
[23:44:37] <ramiro> I don't even speak spanish =)
[23:45:35] <mru> you speak portuguese, close enough
[23:45:47] <mru> there's a simple mapping between the two
[23:46:55] <CIA-92> ffmpeg: stefano * r22351 /trunk/libavformat/mpegts.c:
[23:46:56] <CIA-92> ffmpeg: Replace last occurrence of the deprecated match_ext() with
[23:46:56] <CIA-92> ffmpeg: av_match_ext().
[23:46:56] <CIA-92> ffmpeg: bcoudurier * r22352 /trunk/ (3 files in 3 dirs):
[23:46:56] <CIA-92> ffmpeg: mpegts vbr muxing, activated when muxing rate is not supplied by the
[23:46:56] <CIA-92> ffmpeg: user.
[23:52:43] <CIA-92> ffmpeg: stefano * r22353 /trunk/libavformat/ (utils.c avformat.h):
[23:52:43] <CIA-92> ffmpeg: Remove definition of match_ext(), which is declared under #ifdef
[23:52:43] <CIA-92> ffmpeg: AV_HAVE_AVCONFIG and so not publicly declared, and currently unused.
[23:59:57] <CIA-92> ffmpeg: bcoudurier * r22354 /trunk/libavformat/mpegtsenc.c:
[23:59:57] <CIA-92> ffmpeg: In mpegts muxer, search for h264 aud nal, it might not be the first nal.
[23:59:57] <CIA-92> ffmpeg: Improve ther error message when bitstream is malformated and tell user to use
[23:59:57] <CIA-92> ffmpeg: the bitstream filter.