Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

March 2010

1 participants
31 discussions

IRC log for 2010-03-30
by irc＠mansr.com 31 Mar '10

31 Mar '10

[00:03:46] <DonDiego> gnite [00:44:18] <Dark_Shikari> is there an easy way to loop over random numbers in a shell script? [00:44:24] <Dark_Shikari> e.g. for a in $(seq 1000) [00:44:27] <Dark_Shikari> except randomely distributed? [00:45:24] <Kovensky> $RANDOM? [00:45:40] <Dark_Shikari> yeah, but I need it in a specific range [00:46:40] <J_Darnley> scale it with some math? [00:46:49] <Dark_Shikari> guess that works [00:46:50] <Dark_Shikari> echo to bc [00:47:26] <J_Darnley> does bc not have a random generator? [00:47:47] <Dark_Shikari> no idea [00:49:33] <J_Darnley> I can't find it in the man page with grep... [00:50:04] <Dark_Shikari> well $RANDOM seems to be fine [00:51:25] <Dark_Shikari> yay, I have a script to make about 16 gigabytes of randomely fragmented data [00:55:49] <J_Darnley> "yay" is definitely the right word! [01:13:03] <mru> Dark_Shikari: $RANDOM is bash only [01:13:30] <Dark_Shikari> works for me. [01:13:35] <mru> you could conjure an lcg in standard sh easily enough [01:14:24] <Dark_Shikari> effort [01:14:31] <Dark_Shikari> 550 megs of random fragmented data created [01:15:03] <mru> what does that even mean? [01:15:29] <Dark_Shikari> writing random files of random size into random folders [01:15:35] <Dark_Shikari> once it's all done, I'll perform a linear read [01:15:41] <Dark_Shikari> thus, from the perspective of the linear read, the files will be fragmented [01:16:28] <mru> what's the purpose of this? [01:17:03] <ohsix> theres a fuse filesystem that does that sort of thing (creating huge files, random files, random filenames) [01:17:12] <Dark_Shikari> mru: benchmarking a stupid idea of mine [01:17:21] <Dark_Shikari> a grep that performs prefetch using madvise [01:17:36] <mru> ohsix: I suppose he wants to benchmark real filesystems [01:17:48] <Dark_Shikari> yes [01:18:06] <mru> doesn't linux have readahead anyway? [01:18:13] <ohsix> heh, then you're just benchmarking the filesystem [01:18:21] <Dark_Shikari> mru: how do you know what the program is going to access next? [01:18:25] <Dark_Shikari> it has readahead within a file, sure [01:18:33] <Dark_Shikari> but predicting the next access of a program is an area of decades of research [01:18:42] <mru> across files it'll be hard, true [01:18:44] <Dark_Shikari> including a great deal of stupid things like context-modelling filesystems [01:18:53] <Dark_Shikari> (that idea actually worked pretty well) [01:18:57] <mru> simple is almost always better [01:19:11] <mru> like they finally ditched the silly anticipatory io scheduler in linux [01:19:19] <mru> everybody was using cfq or deadline anyway [01:20:27] <Dark_Shikari> well basically the idea of the prefetching is that the filesystem internally reorders disk reads [01:20:30] <Dark_Shikari> i.e. on the millisecond-level [01:20:35] <Dark_Shikari> in order to better schedule disk head moves, etc [01:20:40] <Dark_Shikari> the disk does some of it as well [01:20:50] <Dark_Shikari> so, if you prefetch a ton of stuff ahead of time, instead of using blocking reads, you'll get better speed. [01:21:22] <Dark_Shikari> (actually I'm doing both: I'm keeping the blocking reads, with the assumption that they'll be faster if we're using prefetching) [01:21:28] <mru> yeah, if you maintain a queue of stuff to read, the fs or block layer has a chance of reordering it optimally [01:21:40] <Dark_Shikari> basically I'm spawning a shitton of threads, one for every file [01:21:44] <Dark_Shikari> open, mmap, madvise [01:21:47] <Dark_Shikari> wait a few milliseconds, close [01:21:47] <mru> have you looked at aio? [01:21:50] <Dark_Shikari> aio? [01:21:53] <mru> async i/o [01:21:57] <Dark_Shikari> how's that work? [01:22:21] <mru> kind of like a read that returns immediately [01:22:30] <mru> then the actual read happens in the background [01:22:33] <Dark_Shikari> and then tells you later [01:22:34] <Dark_Shikari> ? [01:22:37] <mru> yeah [01:22:40] <astrange> http://www.opengroup.org/onlinepubs/009695399/functions/aio_read.html [01:22:55] <astrange> if you're starting new threads to fake async io definitely look at that [01:23:10] <mru> also check all the various extended syscalls linux has [01:23:17] <mru> it has quite a few things to improve io [01:23:22] <astrange> ...or reimplement a c10k web server and do 10000 non-blocking read() calls + kqueue [01:23:30] <Dark_Shikari> lol [01:23:43] <mru> c10k? [01:23:59] <Dark_Shikari> http://en.wikipedia.org/wiki/C10k_problem ? [01:24:11] <mru> I've heard of the y10k problem [01:24:27] <astrange> http://www.kegel.com/c10k.html [01:26:37] <mru> that's 4 years old [01:26:42] <mru> a lot has happened since [01:27:20] <astrange> i'm watching nginx serve 20k connections right now using basically what it recommends for freebsd [01:27:26] <astrange> but it doesn't quite apply to disk io [01:35:56] <mru> bsd probably hasn't changed much in the last 4 years [01:36:05] <mru> or 24 years for that matter [01:50:25] <mru> “C++ is a language strongly optimized for liars and people who go by guesswork and ignorance.” [05:25:33] <pJok> god morgon kshishkov :) [05:26:55] <wbs> lu_zero/mru: yes, the patches were done with git show... should've used format-patch instead to ease application with am, yes [05:48:02] <thresh> moroning [05:48:39] <kshishkov> as you say [06:03:56] <pJok> god morgon kshishkov :) [06:04:20] <kshishkov> goda morgnar [06:05:17] <av500> kshishkov: "guten morgen" :) [06:05:52] <kshishkov> av500: that's in German [06:06:26] <kshishkov> and it has nothing to do with either my homeland or country where I live [06:19:40] <merbzt> god morgon [06:20:54] <superdump> gomorron merbzt [06:21:06] <wbs> morgon [06:23:50] * kshishkov renames channel to #ffmpeg-devel-se [06:30:38] <pJok> its getting there [06:40:13] <peloverde> Anyone know what "aacaot" means in FLV, is it really the profile ID, the docs seem a little off: http://www.adobe.com/devnet/flash/articles/flvplayback_fplayer9u3_04.html [06:41:54] <av500> http://en.wikipedia.org/wiki/MPEG-4_Part_3#MPEG-4_Audio_Object_Types maybe? [06:42:09] <astrange> 0 is not a valid object type [06:42:13] <astrange> and 1 doesn't exist in the wild [06:42:14] <peloverde> indeed [06:42:30] <peloverde> adobe's docs say "AAC audio object type; 0, 1 or 2 are supported" [06:42:38] <av500> its adobe [06:43:16] <peloverde> Also I know flash does support AOT_MAIN, even though no one uses it [06:43:19] <av500> and anyway, what in FLV would depend on the object type? [06:44:02] <peloverde> If it finds a predictor bit in the stream it needs to know what kind of predictor follows? [06:45:27] <av500> so that is out of band info to be given to the decoder? [06:45:48] <peloverde> indeed, it is sent out of band [06:46:18] <peloverde> in mp4 it's in the extradata it's called the AudioSpecficConfig or m4ac [06:46:37] <av500> I just checked my flv demuxer, it gets 2 bytes to be used for that [06:46:47] <peloverde> In ADTS it's offset by 1, which is the usual source of mismatches in the wild [06:49:20] <peloverde> makes sense, for normal channel counts and normal sample rates for common aac variants the full AudioSpecficConfig is two bytes [06:50:04] <av500> and these 2 bytes are part of the flv file [06:50:31] <peloverde> makes sense, I'm getting that format extradata passed to the decoder [06:50:34] <av500> same code in lavf/flvdec [06:50:35] <astrange> always 2 bytes? because it's 5 for sbr-in-lc [06:50:57] <peloverde> astrange, forward configured SBR is a fancier variant [06:51:02] <peloverde> for ALS it's soemthing like 6 bytes [06:51:24] <peloverde> 9 bits just to get the object type [06:51:33] <av500> astrange: sorry, misread, no it is not fixed size 2 [06:51:41] <av500> it is whatever flv provides [06:51:44] <peloverde> 2 is the minimum size though [06:52:48] <av500> so, looks to me like this aacaot can be ignored [06:53:02] <av500> as AudioSpecficConfig is included anyway [06:53:19] <peloverde> wow, this file was correct! [06:53:32] <peloverde> aacaot was 1, the AOT in the AudioSpecficConfig was 1 [06:53:42] <peloverde> and predictor present is true! [06:53:49] <peloverde> AAC main in the wild! [06:54:02] <saintdev> main, OMG! [06:54:06] <astrange> where's that file? it probably doesn't work in perian [06:54:21] <astrange> although 10.6.3 fixed 96khz sbr just today [06:54:28] <peloverde> I will upload a sample soonish [06:55:04] <peloverde> Also it's hulu stream if people are curious [06:55:16] <saintdev> hulu is using main? [06:55:29] <peloverde> for some programs [06:55:51] * saintdev wishes hulu still worked with 64-bit flash in linux :( [06:55:58] <peloverde> I always assumed if someone were to use main in flash it would be for relaxed TNS not for the main profile predictor [06:56:19] <peloverde> saintdev, if it did I would not have discovered this remarkable stream [06:56:29] <saintdev> lol [06:56:34] <ohsix> saintdev: it doesn't? are you using nspluginwrapper? [06:56:54] <saintdev> ohsix: true 64-bit flash is broken, has been since around january [06:57:04] <saintdev> ohsix: 32-bit with nspluginwrapper will work [06:57:14] <ohsix> hrm i've been watching it on my laptop fine [06:57:33] <saintdev> probably 32-bit with wrapper then [06:58:19] <ohsix> nah its the real thing, is it only some streams or shows? [06:58:25] <saintdev> all of them [06:59:08] <saintdev> you will get a message that says "We're sorry but we're unable to stream videos to your system. This may be due to an Adobe software limitation on 64-bit Linux systems." [06:59:14] <ohsix> hah wtf, shows a warning too; i was playing video on it fine a while ago [06:59:35] <ohsix> is it because the ads weren't working or something? cuz those seemed broke [06:59:40] <peloverde> I guess it's time to optimize AAC-Main, 45% in apply prediction is less than ideal [07:00:26] <saintdev> ohsix: somebody suspected that's why, but it's been broken since january (they just put up the message about it being an adobe limitation this month) [07:00:37] <saintdev> and ads have worked for me for quite a while [07:00:39] <ohsix> ic [07:01:13] <saintdev> you must have somehow been using 32-bit flash :/ [07:01:16] <ohsix> the ads were acting funky but i never bothered to look, cuz it would skip them when they malfunction :> [07:01:27] <ohsix> nah; its just been longer than i thought [07:01:35] <saintdev> hah [07:02:11] <ohsix> i did watch it a bunch on this thing though; that sucks [07:02:14] <saintdev> thankfully the non-hulu backed videos on fancast still work :D [07:03:59] <peloverde> astrange, http://samples.mplayerhq.hu/A-codecs/AAC/hulu-aac-main.flv [07:04:47] <saintdev> peloverde: so were you trying to figure out what was going wrong between hulu and flash? [07:05:22] <peloverde> saintdev, I was sick of rebooting to watch hulu and decided to test out rtmpdump [07:05:53] <peloverde> and I noticed the aacaot = 1 in the metadata which seemed funny [07:06:01] <saintdev> haha [07:07:09] <peloverde> It kind of makes me glad I bothered with AAC Main a few months ago, otherwise I'd have to use that other decoder [07:07:40] <kshishkov> yes, it's more funny if *you* have to use faad2 for AAC decoding [07:08:05] <peloverde> See, my motivation to work on ffaac is purely selfish [07:08:16] <av500> itch -> scratch [07:08:40] <kshishkov> well, I have some codecs I did neither for fame nor money [07:09:56] <peloverde> Actually I saw that flash supported AOT_MAIN and foresaw something like this happening, or at least someone refusing to use ffaac because it didn't support all the features flash does [07:10:56] <kshishkov> kick drv for not having Flash Screen Video 2 decoder so someone can blame FFmpeg for not supporting all flash codecs [07:53:40] <CIA-1> ffmpeg: cehoyos * r22727 /trunk/libavcodec/vdpau.c: [07:53:40] <CIA-1> ffmpeg: Fix VDPAU for H.264 streams with long reference frames. [07:53:40] <CIA-1> ffmpeg: Patch by Stephen Warren. [08:11:18] <CIA-1> ffmpeg: cehoyos * r22728 /trunk/libavcodec/ (h264.c vdpau.c vdpau_internal.h): [08:11:18] <CIA-1> ffmpeg: Set VDPAU H264 picture parameter field_order_cnt and frame_num at the [08:11:18] <CIA-1> ffmpeg: start of decoding a picture instead of at the end. [08:11:18] <CIA-1> ffmpeg: Fixes mmco01.264 [08:11:18] <CIA-1> ffmpeg: Patch by Stephen Warren [08:42:02] <thresh> hyc: any plans on making librtmp shared? [08:43:58] <bilboed-pi> shared as in shared library usable by many projects ? [08:44:09] <thresh> exactly [08:44:15] <bilboed-pi> that would totally rock [09:23:11] <merbzt> http://www.boingboing.net/2010/03/29/philip-pullman-on-ce.html [09:28:56] <superdump> does anyone have 14496-15? [09:29:44] <kshishkov> ISO store has for sure :P [09:30:00] <superdump> :p [09:32:30] <kshishkov> I once suggested that FFmtech should provide FFmepg devs with all standards [09:32:33] <kshishkov> *FFmpeg [09:37:56] <av500> kshishkov: thats a sh*tload of money to be paid [09:38:59] <Dark_Shikari> especially with specs like blu-ray [09:39:01] <Dark_Shikari> that cost $5k+ [09:39:07] <Dark_Shikari> of course, given the size of the spec that might be a distribution fee [09:39:16] <KotH> well... [09:39:27] <kshishkov> av500: that's why I also suggested that KotH is to pay for them [09:39:34] <KotH> heh? [09:39:36] <KotH> what? [09:39:38] <KotH> why me? [09:39:41] * KotH is poor [09:39:45] <kshishkov> you' [09:39:55] <kshishkov> re the only one with Swiss Francs [09:41:19] <KotH> i'm still poor [09:42:01] <kshishkov> so am I [09:42:08] <kshishkov> still better you than me [09:42:32] * kshishkov is poor and in Ukraine [09:43:23] <av500> poorkraine [09:43:46] <KotH> ok.. you winn [09:46:04] <av500> superdump: online version: http://www.docin.com/p-26314574.html :) [09:48:53] <av500> KotH: surely you can spare 77HK$, no? http://cgi.ebay.com.hk/ws/eBayISAPI.dll?ViewItem&item=190383357607 [09:49:52] <superdump> are specs resellable? :) [09:50:21] <av500> why not? [09:51:15] <KotH> depends on the jurisdiction you live in [09:51:24] <KotH> but... this actually sounds quite interesting [09:53:13] <av500> of course it is not legal [09:53:29] <KotH> actually, for me it doesnt matter whether it is legal or not [09:53:35] <KotH> i'm not the one making the copies :) [09:53:40] * KotH likes to live in .ch ;-) [09:54:12] * thresh would like to live anywhere but former USSR [09:54:36] * KotH wonders why people dont leave if they hate it where they live [09:55:33] <iive> av500: it may be legal in china. [09:55:54] <thresh> KotH: not really easy to find a job [09:55:59] <thresh> i'm no programmer [09:56:19] <KotH> what's the prob with that? [09:56:41] <KotH> we've thousands of turkish and ex-yugoslavian here in .ch that barely know how to read and write [09:56:51] <thresh> they probably don't need a visa [09:56:55] <KotH> lol [09:56:57] <KotH> yeah.. right [09:58:45] <thresh> and i don't have an academic degree, too [09:59:04] <thresh> so the best way for me to move out is to find a bride somewhere in .eu ;-) [09:59:30] <av500> gee, now I registered at that chinese site, now they want money to download the pdf... I give up [10:00:38] <KotH> nah.. just claim that you are a political refugee and all countries in the .eu will take you in.. if you come to .ch, the leftists here will even greet you at the airport and kiss your feet [10:00:59] <KotH> av500: what site? [10:01:02] <KotH> av500: what pdf? [10:01:06] <av500> http://www.docin.com/p-26314574.html [10:01:23] <av500> it has a download button, but you need to reg and upload money [10:01:48] <KotH> upload virtual money [10:01:55] <av500> maybe I get upload credit if I make a pdf out of ff source code [10:03:03] <av500> ah, no, I cant: "....3. Prohibits the publication of terror, murder...." [10:03:28] <nfl> superdump: hi i've completed the g723.1 frame parser but have a few doubts [10:03:40] <superdump> ... that was quick [10:03:48] <superdump> did you do it from the spec? [10:03:49] <thresh> KotH: that has a downside of a chance being poisoned with polonium [10:03:55] <superdump> if there is a spec available [10:04:06] <nfl> spec + reference decoder [10:04:22] <superdump> did you copy code from the reference decoder? [10:04:47] <merbzt> the g723.1 spec sux [10:04:59] <merbzt> one must look at the ref code :/ [10:05:28] <KotH> thresh: just dont let you get caught! [10:05:55] <thresh> and don't drink tea with KGB agents, check [10:07:00] <superdump> merbzt: oh, it's like that again eh? [10:07:06] <merbzt> yupp ;) [10:07:07] <superdump> merbzt: what is g.723.1 like? [10:07:19] <merbzt> like one mode of amr [10:07:25] <superdump> hmm [10:07:26] <merbzt> or 2 I think [10:07:35] <superdump> does it go by some other name? [10:07:36] <merbzt> with somewhat less features [10:07:40] <merbzt> no [10:07:50] <merbzt> it is one voip codec [10:07:55] <merbzt> a common one [10:08:16] <merbzt> my voip box can use g723.1 [10:08:21] <merbzt> or g729 [10:08:29] <merbzt> or g711 [10:08:45] <superdump> why did they make so many so very similar but slightly different celp codecs? [10:08:49] <superdump> it's STUPID! [10:09:04] <superdump> they only needed 1 sane one [10:09:05] <wbs> couldn't they use names using letters instead of just numbers? ;P [10:09:15] <merbzt> no challenge in that [10:09:21] <superdump> :) [10:09:24] <merbzt> the funny part is that there is a g723 also [10:09:40] <merbzt> totally different from g723.1 (adpcm vs celp IIRC) [10:09:57] <merbzt> though g723 is deprecated or something [10:09:57] <superdump> aaaargh [10:10:04] <superdump> There are two bit rates at which G.723.1 can operate: [10:10:07] <superdump> 6.3 kbit/s (using 24 byte frames) using a MPC-MLQ algorithm (MOS 3.9) [10:10:09] <superdump> 5.3 kbit/s (using 20 byte frames) using an ACELP algorithm (MOS 3.62) [10:10:17] <merbzt> yes, that was it [10:19:43] <av500> superdump: got it [10:25:42] <nfl> sorry abt that. ive got a really crappy connection [10:26:15] <nfl> superdump: as i was saying, am i supposed to write an rtp depacketizer as well? [10:33:12] <nfl> superdump: are you there? [10:38:26] <merbzt> we are always here [10:38:44] <merbzt> write a rtp depaketizer also if you feel like [10:38:52] <merbzt> I doubt it will be to hard [10:39:00] <nfl> ;) [10:39:20] <nfl> merbzt: what i wanted to know was that if g.723.1 has a storage format? [10:39:29] <twnqx> heh... from an company internal document on IPTV deployments [10:39:33] <twnqx> Remember, in case you had forgotten, STAY WAY FROM MICROSOFT MEDIAROOM IPTV AS IT IS A CLOSED WORLD. HERE BE DRAGONS !! [10:40:00] <nfl> merbzt: and if not, i will need a depacketizer right? [10:40:22] <merbzt> nfl: I now there are some g723.1 sample files in wav [10:40:35] <nfl> merbzt: ok [10:40:39] <merbzt> but nothing more then that and from the ref suit [10:42:44] <merbzt> http://tranquillity.ath.cx/files/G7231QN.wav [10:42:47] <merbzt> like magic [10:43:19] <nfl> merbzt: thank you [10:43:31] <merbzt> I have no idea if that is a real working sample [10:44:18] <nfl> btw how careful should i be when writing a frame parser based on the reference decoder? [10:44:32] <nfl> there are only so many ways one can parse frames [10:44:42] <merbzt> w8 [10:46:19] <merbzt> base it of this first http://tranquillity.ath.cx/files/G723dot1.c [10:46:46] <merbzt> http://tranquillity.ath.cx/files/G723dot1.h [10:46:52] <merbzt> forgot I had those files [10:47:31] <merbzt> vivog723 might be g723.1 [10:49:01] <nfl> lemme get this straight, by a frame parser i am supposed to write code similar to that in g723dot1_get_bitstream_parameters() in ur code, rite? [10:49:33] <merbzt> yes [10:49:59] <nfl> i've already done that. but why is not your code committed? [10:50:41] <merbzt> I is committed [10:50:50] <merbzt> in my own repo :) [10:51:23] <merbzt> yeah, I suck it should have been in the soc repo [10:51:48] <nfl> so g.723.1 soc task is off :( ? [10:53:26] <nfl> superdump: are you back? [10:53:44] <nfl> +yet? [10:53:59] <superdump> i'm having lunch at the moment [10:54:11] <superdump> but you don't need to speak to me particularly, anyone here is ifne [10:54:12] <nfl> ok i'll wait [10:54:14] <superdump> fine* [10:54:28] <superdump> i can catch up from merbzt later or so [10:55:26] <nfl> merbzt: ? [10:57:29] <DonDiego> superdump: Rathann was having some trouble with an aac sample yesterday [10:59:05] <DonDiego> http://www1.mplayerhq.hu/~diego/ [10:59:12] <DonDiego> the [Frostii] files [11:06:46] <merbzt> nfl: nono, the decoder is far from complete, and we need an encoder also [11:07:06] <nfl> so do i just post my parser.c to the soc ml? [11:07:14] <merbzt> you do that [11:56:41] <superdump> hmm, diego's not here any more [11:56:52] <superdump> sync -> timestamps -> container [11:57:21] <superdump> unless it works with faad [11:58:45] <mru> superdump: well, he said the sound was badly distorted [11:58:50] <mru> forget sync [11:59:01] <superdump> oh [11:59:04] <superdump> ok [11:59:41] <kshishkov> bad sync to ears then :) [12:00:06] <mru> whatever problem he had, any sync issues were secondary [12:00:19] <mru> it plays fine here [12:00:40] <superdump> mru: it plays fine there with ffplay? [12:00:46] <mru> yes [12:00:48] <superdump> ok [12:01:15] <kshishkov> mru: don't forget about his cutting edge AMD CPU. Might be a problem with SIMD func somewhere [12:01:46] <mru> what cpu does he use? [12:01:54] <superdump> k6-300? [12:02:50] * kshishkov uses Loongson 2F too but it also has shitty DSP [12:03:59] <Compn> ehe [12:04:08] <Compn> i think i have a k6 collecting dust somewhere [12:05:38] <pross-au> i have two [12:06:05] <superdump> works for me as well [12:06:16] <superdump> although the speech sort of overlaps itself [12:07:42] <iive> k6 have mmx1 and the 300mhz may have 3dnow1 too. [12:09:08] <pross-au> I have K6-II and III btw [12:09:25] <pross-au> The III+ had extended 3dnow iirc [12:10:23] <KotH> yes, it had [12:15:17] * kshishkov still has PII-266 not buried [12:18:21] <pross-au> Meh, there is an 8088 here [12:18:26] <pross-au> EGA :D [12:19:09] <nfl> ok, ive posted the code to the soc ml. [12:20:33] <kshishkov> pross-au: IIRC it was only around dawn of Pentiums when rich people here could afford to buy a computer [12:21:49] <KotH> kshishkov: i can beat that [12:22:15] <KotH> kshishkov: i have a dual P-II 266 with 154MB ram! [12:22:34] <kshishkov> mine is single but with 192MB (and 4GB HDD) [12:24:32] <av500> mru: didnt we have that issue before with ffplay [12:24:42] <av500> that is played ok for some people and not for others [12:25:24] <av500> but that was related to 6ch... [12:27:52] <av500> and this file is 6ch as well [12:28:09] <kshishkov> maybe crappy libSDL version [12:28:47] <kshishkov> for example Diego had FFplay crashing on MacOSX/PPC with SDL 1.3 [12:29:07] <mru> I'll gladly blame sdl for anything [12:29:08] <av500> yep, same distorted sound here [12:29:18] <nfl> superdump, merbzt pl take a look at my code [12:29:21] <av500> as was the case last time for me as well [12:29:36] <av500> still SDL accepting 6ch but playing it over 2 [12:29:43] <av500> (I assume) [12:30:15] <av500> since we ask all decoder for 2ch downmix, why dont we limit SDL to 2ch as well? [12:30:38] <kshishkov> someone may have 6ch working (theoretically) [12:30:53] <av500> yes, but they will not get 6ch DTS or AC3 [12:31:04] <kshishkov> may be the same reason why nobody has fixed swapped colours output on MacOSX/PPC [12:31:05] <av500> as those decoders are able to downmix, and we ask for 2ch [12:31:09] <mru> ok, this is messed up... _now_ it's distorted here with ffplay [12:31:51] * janneg blames the cern [12:32:50] <kshishkov> janneg: in his case it may be Stonehenge restarted ;) [12:33:14] <mru> ah, that's what it is [12:33:24] <mru> stonehenge is an ancient particle accelerator [12:33:28] <janneg> ah finaly, they fixed the echo in the webcast [12:33:48] <iive> does somebody know good dvb parser? it's better if it is free (in any meaning). [12:33:52] <av500> cern did that too? [12:34:24] <mru> iive: parser how? [12:34:32] <av500> psu? [12:34:34] <av500> psi? [12:34:48] <iive> to parse the tables and descriptors from the dvb standard. [12:35:09] <mru> I don't think anyone has ever written a complete one [12:35:13] <iive> and preset them in human understandable form. [12:35:21] <janneg> iive: dvbsnoop [12:35:57] <merbzt> iive: tvheadend has a parser also [12:36:01] <iive> janneg: somehow it can't parse anything if i give him captured file. [12:36:17] <merbzt> not so user friendly though [12:36:23] <janneg> iive: are you using -tssubdecode? [12:38:32] <iive> merbzt: i'll give it a try. [12:41:13] <iive> janneg: i think i've tried all options, but when i get the dvbsnoop command line as part of the parsed bitstream, i get doubts.... [12:46:04] <janneg> iive dvbsnoop -s ts -tssubdecode -if FILE -n 300 0x0 produces a parsed PAT if there is one in the first 299 TS packets [12:51:10] <iive> janneg: i'll try it again. [12:53:09] <nfl> merbzt, superdump what do you think of the code? [12:53:26] <superdump> i'm afraid i'm at work at the moment so i don't have time to look at it [12:53:37] <nfl> ok [12:53:45] <kshishkov> nfl, just wait until you get a reply by mail [12:54:08] <iive> janneg: seems to work. thanks a lot. [12:54:25] <kshishkov> and in the future please send code as attach, otherwise formatting may be screwed [12:54:44] <nfl> ok [13:34:47] <Ryen> Hi [14:18:54] <nfl> merbzt: ffmpeg says the sample is Audio: pcm_s16le, 22050 Hz, 1 channels, s16, 352 kb/s. what changes do i need to make for it to be detected as g723.1 (if it _is_ g723.1)? [14:26:30] <merbzt> hmm, ok then it was just a wav file with the decoded sound [14:26:34] <merbzt> nm then [14:28:34] <nfl> merbzt: so will i need an rtp depacketizer? [14:28:41] <merbzt> yupp [14:29:11] <nfl> but the prob is that i can't find the documentation for it anywhere [14:29:46] <nfl> there are rfcs for payload formats for most of the g_ formats, but not for g723.1 [14:30:02] <merbzt> http://tools.ietf.org/html/rfc3551#section-4.5.3 [14:33:05] <nfl> i did see that document, but is it exactly a payload spec? [14:33:24] <merbzt> yes it is :) [14:33:41] <merbzt> one byte prefixed [14:34:00] <nfl> fine then [14:34:59] <merbzt> umm, can you check if the truespeechcode in ffmpeg matches g723.1 ? [14:35:24] <kshishkov> unlikely [14:36:04] <kshishkov> it's very old and quite simple - even I could RE it [14:43:39] * nfl kicks himself btw [14:44:04] <kshishkov> we don't mind, do continue [14:46:20] <nfl> so is the depacketizer part of the qual task too? ;) [14:46:32] <nfl> or am i qualified now? [14:46:49] <merbzt> kshishkov: pendel :) [14:47:05] <merbzt> nfl: depacketizer would be nice [14:47:11] <kshishkov> merbzt: don't remind me of X60 [14:47:23] <merbzt> X60 ? [14:47:39] <kshishkov> http://sv.wikipedia.org/wiki/X60 [14:48:00] <merbzt> kshishkov: http://attuworld.nl/wp-content/uploads/2010/03/0733_7da4.gif [14:49:06] <kshishkov> it's hard to make a smiley out of that though [14:49:14] <nfl> merbzt: you didnt exactly answer my question ;) [14:49:30] <kshishkov> nfl: there's no such thing as overqualification [14:49:30] <merbzt> we need to see the depacketizer [14:49:44] <nfl> on it :) [15:01:11] <superdump> BBB: what the fudge is going on with the postfilter stuff? [15:01:39] <kshishkov> makes sounds tastier? [15:01:42] <superdump> the test results you posted are somewhat confusing [15:01:58] <BBB> huh? [15:02:01] <BBB> what's confusing [15:02:14] <BBB> I'm trying to test and see if this conforms to the spec [15:02:21] <BBB> I implemented it from a PDF spec I found online [15:02:28] <BBB> vitor wants me to confirm with the ref decoder [15:02:31] <BBB> and that was a bit confusing [15:02:41] <BBB> I think it does, at least it's very close [15:02:45] <superdump> the numeric data is a bit confusing [15:02:46] <merbzt> the ref doesn't post filter IIRC [15:02:50] <BBB> merbzt: I made it [15:02:54] <BBB> merbzt: it's a flag [15:02:54] <merbzt> ok [15:03:02] <BBB> that's why my first check was wrong [15:03:10] <BBB> I didn't know it didn't postfilter at that point [15:03:26] <BBB> superdump: how is it confusing? [15:03:33] <BBB> superdump: I can explain, I have all data here ;) [15:03:40] <superdump> one moment [15:04:09] <kshishkov> BBB: damn lies, statistics and benchmarks? [15:04:14] <BBB> yes [15:04:18] <BBB> ;) [15:05:10] <superdump> bash-3.2$ tests/tiny_psnr ~/Desktop/out-{us,ref-nopf}.wav 2 0 44 [15:05:11] <superdump> stddev: 447.74 PSNR: 43.31 bytes: 8820800/ 8820800 [15:05:20] <superdump> bash-3.2$ tests/tiny_psnr ~/Desktop/out-{nopf,ref-pf}.wav 2 0 44 [15:05:22] <superdump> stddev: 405.09 PSNR: 44.18 bytes: 8820800/ 8820800 [15:05:29] <superdump> what's the difference between these two comparisons? [15:05:34] <superdump> oh [15:05:43] <superdump> now i pasted them and they're side by side, it's clearer [15:05:44] <superdump> hehe [15:05:51] <superdump> i'm just misparsing the filenames [15:05:53] <kshishkov> it's better with postfilter, sorry to improve your sound [15:05:56] <superdump> you could have made that simpler... [15:06:12] <BBB> superdump: I'm lazy :( [15:06:38] <superdump> so 'us' is with ffmpeg with pf [15:06:40] <BBB> if I could use html or excel I'd have made a nice cross-check--list [15:06:42] <BBB> yes [15:06:45] <superdump> and nopf is ffmpeg without pf [15:06:48] <BBB> yes [15:06:57] <BBB> ref-nopf/pf is reference without or with pf [15:07:10] <kshishkov> BBB: can you look at msms01.vwp? Even my lazier eye have found a lot of known data (and FFT function in separate segment) [15:07:32] <BBB> kshishkov: ? [15:07:36] <superdump> weird that ffpf vs refnopf has the highest db [15:08:00] <BBB> db? [15:08:04] <superdump> psnr [15:08:14] <BBB> stddev [15:08:27] <superdump> lol [15:08:29] <kshishkov> BBB: that's actual decoder for VoxWare MetaS..., one of the important codecs we don't have yet :( [15:08:30] <superdump> ok [15:08:33] <superdump> i'm going to be quiet now [15:08:35] <superdump> apologies [15:08:41] <BBB> no, I was confused ;) [15:08:52] <superdump> that turns everything on its head ;) [15:08:58] <BBB> so yes, highest difference is between us without pf versus ref with pf, or us with pf versus ref without pf [15:09:07] <BBB> which you'd expect if my patch is anywhere near correct [15:09:19] <BBB> and lowest difference is for the other tywo [15:11:03] <superdump> BBB: right, though "a [15:11:04] <superdump> quick look at the code (postfilt() in code/postfilt.c) confirms that [15:11:11] <superdump> we're doing mostly the same thing" doesn't instill a lot of confidence :) [15:11:15] <superdump> 'mostly'? [15:11:20] <superdump> is that just the clipping difference? [15:11:27] <BBB> don't think so [15:11:41] <BBB> don't forget that current code versus reference without postfilter is highly different already [15:13:26] <superdump> i'm not sure how good 46dB is in psnr terms for audio [15:14:05] <BBB> for voice, it's quite good, according to kostya [15:14:10] <BBB> but this isn't source versus decoder output [15:14:12] <BBB> unfortunately [15:14:16] <BBB> so it's hard to say what it means [15:14:39] <BBB> all I can say is that difference of ref vs. us without postfilter ==~ difference of ref vs. us with postfilter [15:14:44] <BBB> which is all I tried to proove [15:14:44] <BBB> :) [15:14:52] <kshishkov> BBB: don't trust claims about sound quality from original ffaacenc author ;) [15:15:01] <BBB> lol [15:25:40] <superdump> BBB: does it sound any better with the postfilter versus without? [15:28:26] <superdump> well, i'm off anyway [15:28:29] <superdump> have fun [15:33:19] <BBB> hm, he left [15:33:34] <BBB> well that's hard to say, input sounds quite good already without postfilter so I can't hear any clear differences, unfortunately [15:33:40] <BBB> I'd need imperfect source for that [15:34:53] <kshishkov> no, you need perfect source [15:35:50] <kshishkov> like complex music with high notes so you can actually spot the difference instead of guessing which pile of crap is better - smoothed or not [15:51:49] <CIA-1> ffmpeg: benoit * r22729 /trunk/ (15 files in 3 dirs): Replace @returns by @return. [16:28:50] <CIA-1> ffmpeg: astrange * r22730 /trunk/configure: [16:28:50] <CIA-1> ffmpeg: configure: restore -mdynamic-no-pic on darwin (missing since r20497) [16:28:50] <CIA-1> ffmpeg: Darwin compilers default to PIC on, so -mdynamic-no-pic (which disables it [16:28:50] <CIA-1> ffmpeg: again) needs to be added to cflags before enable pic is checked. [16:28:50] <CIA-1> ffmpeg: Fixes compilation without --enable-shared at least the 10.6 system compiler [16:28:51] <CIA-1> ffmpeg: for x86-32. [16:28:52] <CIA-1> ffmpeg: Fixes speed regression on all darwin arches except x86-64. [16:32:33] <astrange> "Fixes compilation without --enable-shared" <- not sure about this wording [16:32:58] <astrange> it's fixed without --enable-shared, but probably still broken with --enable-shared, because that's still pic. didn't try it yet [16:43:06] <Vitor1001> BBB: BTW, I forgot to tell: besides what I said in my last email to the list, patch ok. [16:52:32] <BBB> Vitor1001: thanks, I'll add a comment, I wasn't quite sure how to share it since all actual factors are differeny [16:52:44] <BBB> I figured this is why the actual individual filters are separate functions [16:55:13] <Vitor1001> BBB: Probably it would be nice also to have a way to disable it in the command line... [16:56:19] <BBB> that's a more generic thing that would be nice for all decoders [16:56:30] <BBB> I've wanted to implement something like that for a while now [16:57:18] <BBB> anyway, I got a lot of patches in my tree so it's time I merge some of 'em first [16:57:26] <BBB> related [16:57:30] <BBB> Vitor1001: how good are you with matlab? [16:57:39] <Vitor1001> never used [16:57:44] <BBB> oh [16:57:45] <BBB> hm... [16:57:50] <BBB> anyone here using matlab? [16:57:51] <Vitor1001> I can do some tricks with mathematica... [16:57:53] <jai> Vitor1001: btw, if someone is taking up libavfilter audio support, a volume filter would be nice :) [16:57:57] * mru used to be half-decent with matlab [16:58:09] <mru> haven't used it since ~2003 though [16:58:24] <jai> BBB: poor students prefer octave ;) [16:58:36] <mru> we had free matlab licences at uni [16:58:41] <Vitor1001> jai: I won't have any time to work on lavfi this year :( [16:58:45] <mru> for home use as well [16:58:47] <BBB> a friend of mine is looking for a matlab expert for consulting [16:58:54] <BBB> mru: shall I forward it to you? [16:59:36] <jai> Vitor1001: oh :| [17:00:30] <mru> BBB: no [17:00:53] <mru> I haven't used matlab for 7 years, I wouldn't even know where to begin [17:01:12] <mru> well, I assume the basic ideas remain the same [17:01:29] <jai> yeah, its still a memory hog [17:01:35] <mru> heh [17:01:40] <BBB> ok, will find someone else then [17:01:44] <BBB> peloverde: what abouy you ? ;) [17:01:50] <mru> matlab5 was much less of a hog than v6 [17:01:55] <mru> what version are they at now? [17:02:23] <jai> mru: 7.xx [17:02:42] <jai> .10 actually [17:02:56] <mru> I remember v6 came with a fuckload of java crap [17:03:18] <peloverde> 6 and 7 both do [17:03:55] <mru> which version did they add the jit compiler? [17:04:04] * j0sh wrote a matlab wrapper for ffmpeg [17:04:16] <j0sh> 'twas not pretty [17:04:19] <jai> whoa [17:04:21] <peloverde> BBB, Thanks for the offer but I don't really know most of the fancy toolboxes, etc [17:04:35] * mru glued matlab and spice together with ugly scripts [17:04:56] <mru> matlab had much better graphing capabilities than spice [17:09:56] <kshishkov> we used to implement sorting algorithms in matlab [17:10:10] <mru> that's silly [17:10:17] <mru> matlab has builtin sorting functions [17:10:19] <peloverde> matlab has some very nice filter design / analysis tools [17:10:24] <kshishkov> not as silly as AI labs in Excel [17:11:01] <kshishkov> army rule "to gain experience you need to roll flat objects and push round objects" [17:11:20] * mru was never in the army [17:13:12] <kshishkov> same here but you pick some things up, especially army way of thinking [17:13:53] <kshishkov> IIRC on neighbouring department there were only two people from the whole staff who weren't officers [17:14:15] <kshishkov> and that was "intellectual decision-making systems" speciality [17:20:47] <kierank> everything has to be done quickly in spite of the fact that a little bit of time could be taken and it could be done right [17:21:57] <kshishkov> especially the latter [17:22:03] <kshishkov> right != properly [17:22:19] <kierank> that too [17:23:13] <mru> military decision-making is very special [17:23:42] <mru> the troops on the ground, or in the planes, simply don't have enough information to make an informed decision on their own [17:23:47] <kshishkov> actually it was civilian speciality there but yet... [17:24:02] <mru> so decisions _must_ be made by someone higher up in command [17:24:10] <mru> who has access to the bigger picture [17:24:39] <mru> and once he makes a decision, those under him must follow orders, or there will be disaster [17:25:06] <kshishkov> in theory yes but you don't know how creatively they tend to follow orders [17:25:45] <mru> and of course the competence of the generals and whatnot might not be what it ought [17:25:59] * kshishkov remembers what during local trainings they managed to launch rocket into house near Kiev and Russian plane [17:26:50] <mru> unfortunately, in a combat situation there is no time for questioning orders [17:27:12] <mru> even if they were to be found bad [17:27:44] <mru> doing something is often better than doing nothing [17:27:51] <mru> even when doing something else might have been even better [17:28:16] <mru> but if you're dead by the time you've figured it out, that matters little [17:28:51] <_av500_> u can come back as aghost saying - i told you so [17:29:08] <kshishkov> okay, you get your promotion at the headquarters [17:35:03] <BBB> mru: do you want to write interleaving DSP functions? [17:36:53] <mru> I'd prefer if the existing ones could be used [17:37:25] <mru> I spent a crazy amount of time on the neon one [17:37:45] <mru> and it can't be done as efficiently if the range is altered [17:38:23] <BBB> oh, we already have? [17:38:25] * BBB looks [17:38:31] <BBB> what should I grpe for? [17:38:40] <mru> float_to_int16_interleave [17:38:59] <BBB> float_to_float_interleave? [17:39:28] <mru> easy to write but won't be as efficient [17:39:38] <BBB> that's ok [17:39:43] <mru> no, that's not ok [17:39:47] <BBB> uhm... [17:40:36] <mru> if a float decoder can be coerced into outputting -32k..32k that should be done [17:40:38] <BBB> look, most audio decoders that we write now, output float [17:40:47] <mru> AND THAT IS A HUGE MISTAKE [17:40:52] <mru> not outputting floats per se [17:41:00] <mru> but not allowing the range to be chosen [17:41:07] <BBB> then do something about it [17:41:20] <mru> oh fuck off with that attitude [17:41:44] <BBB> what do you expect me to do about it if I don't even know this stuff? [17:41:47] <mru> that I know _how_ something should be done, doesn't imply I have _time_ to do it [17:41:47] <BBB> you never told me [17:41:59] <BBB> I ask "what should my decoder output", people tell me "float" [17:42:02] <BBB> I write a float decoder [17:42:03] <mru> I've mentioned it in every discussion on the topic [17:42:05] <BBB> (and we all did) [17:42:12] <BBB> and now suddenly you want float with choosable ranges? [17:42:25] <mru> I've been saying that since long before you joined ffmpeg [17:42:44] <mru> and I'm getting weary of it [17:43:05] <iive> write it in your blog and then just paste the url. [17:43:08] <mru> the way many codecs are designed, you can apply a scaling FOR FREE [17:43:25] <mru> simply by prescaling mdct coeffs or similar [17:43:48] <mru> that saves you a multiplication later [17:44:01] <mru> which should speed up the conversion to int16 by 20% or so [17:44:08] <BBB> that is great [17:44:14] <mru> depending on the complexity of the codec of course [17:44:14] <BBB> but so output would still be (scaled) float [17:44:19] <mru> yes [17:44:21] <BBB> so could we use a float_to_float_interleave? [17:44:25] <mru> no [17:44:38] <mru> well, we'll need that too for completeness [17:45:00] <mru> to do the right thing you need to look all the way to the end of the pipeline [17:45:44] <mru> if you want to end up with interleaved int16, the most efficient way is to scale inside the codec and combine int conversion with interleaving [17:45:47] <_av500_> russia? [17:46:02] * mru looks a thresh [17:46:07] <mru> *at [17:46:40] <_av500_> russians are good at interleaving gas with no gas [17:46:53] * kshishkov waves [17:46:59] <iive> lol [17:47:27] <thresh> you're not russian, dont try to kid us [17:47:54] <iive> i'm next on the pipe after kostya. [17:47:58] <mru> now if you want interleaved float samples, then a simple float interleave function will be needed [17:48:09] <mru> and that will surely be needed at some point too [17:48:11] <BBB> mru: ok, so you're saying (correct me if I'm wrong), decoders should allow selecting flt vs. int16, and then the caller should be intelligent enough to know which to choose, and then decoders should use dsp.float_interleave vs. dsp.float_to_int16_interleave() based on that? [17:48:23] <BBB> is that "most optimal"? [17:48:40] <kshishkov> we have downmixing [17:48:50] <mru> that would be one way, but it would duplicate some code [17:48:54] <kshishkov> why not adaptive sample output? [17:48:58] <mru> better to choose the range instead [17:49:05] <mru> and provide planar output [17:49:16] <_av500_> why planar? [17:49:17] <mru> and convert/interleave outside the decoder [17:49:25] <_av500_> ok [17:49:39] <kshishkov> easier to output too [17:49:44] <mru> my neon convert/interleave is as fast as doing either of them alone [17:49:47] <iive> btw, i thought that we already have implemented working scale of floats. [17:49:48] <_av500_> makes things like resampling easier [17:49:57] <BBB> iive: it's a hack, so no [17:50:02] <BBB> (imo) [17:50:07] <mru> it's a big, fat hack [17:50:24] <mru> downmixing can often be done more efficiently before the imdct [17:50:26] <mru> like in ac3 [17:50:53] <mru> we'll of course need post-decode downmixing functions too [17:50:58] <peloverde> Doesn't that only work if the windowing across the channels is the same? [17:50:59] <mru> for the codecs that can't downmix internally [17:51:09] <_av500_> aac e.g. [17:51:11] <mru> it works only if the codec was designed for it [17:51:15] <kshishkov> ac3 has two transforms [17:51:16] <mru> ac3 was designed for it [17:51:23] <mru> and dts too iirc [17:52:02] <jai> mlp too [17:52:17] <kshishkov> pcm too [17:52:32] <mru> so just like we have request_channels we need a request_format [17:53:41] * BBB will go with Michael's suggestion of just adding a FIXME for now [17:53:56] <mru> fixme for what? [17:54:05] <BBB> optimized interleaving [17:54:06] <mru> you know as well as I that fixmes never happen [17:54:16] <kshishkov> indeed, a little fixme saves the real trouble of fixing ;) [17:54:19] <BBB> I want my clipping patch applies [17:54:25] <BBB> applied* [17:54:35] <mru> I don't mind that [17:54:44] <mru> it's just a fix for an obvious bug [17:54:50] <BBB> I fixed all issues in the speech decoders related to overactive memcpy()ing [17:54:53] <mru> quite separate from a proper redesign [17:55:01] <BBB> the one remaining performance thing that can be improved is interleaving in wmaprodec/atrac1 [17:56:13] <BBB> btw what does aacdec and ac3dec output? [17:56:22] <BBB> do they really output int16? and what do they use internally? [17:56:31] <_av500_> aac is int16 [17:56:41] <_av500_> ac3 as well [17:56:52] <peloverde> aac uses float internally [17:57:11] <kshishkov> ac3 too [17:57:36] * BBB wonders whether mru would take away his svn write access if he converted ac3/aac to output float [17:57:37] <kshishkov> even many speech codecs use floats [17:58:55] <mru> I might [17:59:05] <mru> it would make them 3x slower [17:59:23] <mru> or maybe only 2x [17:59:35] <jai> wmapro outputs float right? [17:59:37] <mru> yes [17:59:44] <mru> and it spends >50% time in post-conversion [17:59:49] <jai> :S [18:00:11] <mru> and I can easily speed up the decoder core by 30-50% [18:00:33] <mru> hence the 3x figure [18:00:52] <mru> I've exhausted my tricks on aac [18:01:00] <mru> need to tackle sbr [18:01:11] <kshishkov> or Bink audio [18:01:13] <mru> should be easy to double the speed of that on arm [18:01:21] <mru> sbr, that is [18:01:25] <mru> haven't looked at bink [18:01:33] <mru> nor do I have a lot of motivation to do so [18:02:24] <mru> what transforms does it use? [18:02:47] <kshishkov> some DCT or RDFT [18:02:51] <Dark_Shikari> What the fuckety fuck, some guy has a fork of x264 on github... where's he's converting it to use autotools [18:02:55] <Dark_Shikari> WHYYYYYYYYYYYYYYYYYYYYYYY [18:02:57] <Dark_Shikari> WHY [18:03:01] <BBB> lol :) [18:03:11] * mru loads shotgun [18:03:13] <BBB> because we can! [18:03:20] <kshishkov> where is fork for MSVC? [18:03:30] <jai> lol BBB [18:03:52] <BBB> hmm... I always get confused in this chat client and end up closing the wrong channel [18:03:52] <jai> BBB: heh [18:03:57] <mru> Dark_Shikari: whose fork is that? [18:04:07] <Dark_Shikari> "nevali" [18:04:11] <Dark_Shikari> I have no idea, but seriously the fuck [18:04:19] <mru> oh, fuck indeed [18:04:30] <kshishkov> mru: you still have ffavs to ... TAKE CARE OF [18:04:41] <mru> is it still around? [18:04:53] <kshishkov> dunno [18:04:57] <BBB> " Mo McRoberts" [18:05:26] <Dark_Shikari> http://github.com/nexgenta/x264 [18:05:42] <mru> well, let's make it hard for them, shall we? [18:06:29] <kshishkov> still, where's x264 with intrinsics and MSVS support? [18:06:39] <kshishkov> that would be more fun [18:06:51] <mru> Dark_Shikari: you should borrow more from ffmpeg's configure [18:07:08] <mru> yours is broken in some ways now [18:07:10] <Dark_Shikari> kshishkov: we intentionally dropped the latter [18:07:12] <mru> or at least not as capable [18:07:13] <Dark_Shikari> mru: patches welcome [18:09:51] <Dark_Shikari> (seriously) [18:35:50] <ramiro> mru: ping "[PATCH] Use cross-prefix for strip in darwin." [18:36:35] <mru> ramiro: I saw, I had doubts, I forgot about it [18:36:45] <mru> will look at it after dinner [18:36:50] <ramiro> thanks [18:36:51] * mru is hungry [19:15:13] <jai> mru: pk__ is the guy you kb'd (or/kick'd i dont recall fully) once [19:15:16] <jai> :) [19:16:04] <mru> I've kicked more than one person [19:16:26] <jai> oh, i thought you'd remember him [19:16:44] <jai> he was going on about a symbian port of ffmpeg or something in that vein [19:17:44] <mru> my logs don't have that nick [19:17:54] <jai> mru: try "pankaj" [19:17:57] <jai> or sth like that [19:18:36] <mru> yep, I kicked him several times [19:18:39] <mru> and pk2010 [19:18:43] <jai> heh [19:18:53] <mru> that was last june [19:19:02] <jai> he has begun a new life as a vlc dev since then [19:27:02] <astrange> http://twitter.com/rickt/status/11063159819 wonder what that means [19:27:50] <mru> isn't that bg from 2001? [19:27:53] <Dark_Shikari> it means someone is somewhat retarded [19:38:03] <CIA-1> ffmpeg: rbultje * r22731 /trunk/ffmpeg.c: [19:38:03] <CIA-1> ffmpeg: Split out code that auto-chooses a default pix_fmt/sample_fmt in their own [19:38:03] <CIA-1> ffmpeg: functions. [20:42:22] <BMintern1> hello again Vitor1001... i'm really stuck this time [20:47:39] <CIA-1> ffmpeg: michael * r22732 /trunk/libavcodec/error_resilience.c: [20:47:39] <CIA-1> ffmpeg: Make sure the EC code does not attempt to use inter based concealment if there [20:47:39] <CIA-1> ffmpeg: is no reference frame available. (this can happen because the EC code will attempt [20:47:39] <CIA-1> ffmpeg: to use reference frames even for I/IDR frames) [21:06:02] <CIA-1> ffmpeg: michael * r22733 /trunk/libavcodec/ (h264_refs.c h264.c h264.h): Fix implicit weight for b frames in mbaff. [21:45:15] <hyc> interesting. Hulu's streams used to list ffmpeg in their metadata [21:45:21] <hyc> now they show "Hulu 1.0" [21:45:41] <hyc> I wonder if they've actually written their own transcoders (doubtful) [21:45:50] <hyc> or if they're just slapping their own name on top of ffmpeg [21:46:15] <kierank> ask baptiste [21:46:31] <kierank> he works there iirc [21:47:13] <Dark_Shikari> hyc: they use x264 [21:48:00] <hyc> Dark_Shikari: ah right. I remember seeing x264 in their metadata before [21:48:05] <hyc> but not any more [21:48:24] <hyc> now their tag is Hulu v1.0 [21:49:29] <peloverde> I also noticed last night that some streams use aac main profile [21:50:53] <hyc> yeah I've seen a few of those, didn't strike me as odd at the time [21:51:05] <kierank> maybe they did the impossible and mangaged to get a nero licence [21:51:12] <kierank> managed* [21:52:35] <Dark_Shikari> kierank: I bitched at nero about that [21:52:39] <Dark_Shikari> and they are now more open to licensing [21:52:56] <peloverde> Nero's freeware encoder doesn't do main [21:54:49] <peloverde> An encoder that supports main is most likely based on an old codebase [21:57:08] <BBB> faac? [21:57:23] <BBB> if you're using ffmpeg to convert, you're more than likely using faac for aac encoding [21:57:40] <BBB> changing metadata isn't so difficult [21:57:52] <Dark_Shikari> it's trivial to see if it's flac [21:57:56] <Dark_Shikari> does it sound like shit at 128kbps? [21:57:58] <Dark_Shikari> then it's faac [21:59:40] <BBB> how do I count characters in a line using bash tools? [21:59:48] <BBB> wc -c counts total characters [21:59:59] <hyc> BBB: man expr [22:00:22] <BBB> cat file | grep CONV | man expr returned an error [22:00:47] <hyc> .... [22:00:51] <hyc> read the expr manpage [22:01:00] <peloverde> faac at 128 doesn't sound all that bad to me [22:02:18] <drv> i haven't done any scientific tests, but faac at 128kbps on music sounds ok to me too usually [22:02:30] <BBB> man expr is like 20 lines on macosx [22:02:34] <BBB> probably different on unix [22:03:17] <peloverde> Contact your UNIX vendor and ask for better man pages ;) [22:03:33] <hyc> Apple has always been one to lobotomize technology... [22:03:35] <drv> maybe they'll send you a nice stack of dead trees [22:03:41] <peloverde> (or google it) [22:03:54] <hyc> expr length "STRING" [22:04:37] <BBB> expr: syntax error :) [22:04:52] <BBB> I think apple intoxicated it [22:05:32] <hyc> sad. you could probably use awk for the job, but that's overkill [22:05:43] <drv> the gnu coreutils expr has a lot more operators than the BSD one that apple uses [22:06:40] <mru> http://www.opengroup.org/onlinepubs/009695399/utilities/expr.html [22:07:12] <mru> I don't see how that would give you the length of a line [22:07:36] <hyc> you can use also use expr string : . [22:07:49] <drv> well, probably GNU stuff having the kitchen sink included in every tool [22:08:02] <hyc> it matches a stirng to a regexp and returns the number of matching characters [22:08:14] <hyc> so using "." will give you length of the string [22:08:25] <mru> hyc: that will return 1 [22:08:32] <mru> or 0 for empty lines [22:09:15] <hyc> mru: ah right. use .* [22:09:15] <drv> .* or something? [22:09:25] <drv> with proper quoting [22:10:06] <CIA-1> ffmpeg: cehoyos * r22734 /trunk/ (9 files in 2 dirs): [22:10:06] <CIA-1> ffmpeg: Add spectral extension to the E-AC-3 decoder. [22:10:06] <CIA-1> ffmpeg: Original patch by Justin, updated and resubmitted by [22:10:06] <CIA-1> ffmpeg: Christophe Gisquet, christophe D gisquet A gmail [22:10:12] <mru> that would work [22:10:19] <j-b> \o/ [22:10:20] <j-b> Finaly [22:12:18] <kierank> j-b: that's for french dvb-t right? [22:12:43] <j-b> yes [22:12:55] <j-b> kierank: I patch vlc since almost 8 month for that on Win32 and Mac [22:13:07] <j-b> well, I patch avcodec in vlc [22:13:21] <j-b> and I have to say that I hate maintaining non-official patches [22:13:48] <j-b> because I don't trust /me [22:14:19] <BBB> gr... expr kills starting spaces [22:14:39] <mru> you're not quoting properly [22:14:59] * BBB adds a s/ /x/g hack [22:16:11] <BBB> hm, I guess I wasn't too far off in my email [22:16:14] * BBB leaves as-is [22:27:42] * hyc grumbles again about stupud GNU extensions to standard shell tools... [22:30:14] <mru> well, sometimes they are useful [22:30:27] <mru> but all too often they conflict with standards [22:30:41] <mru> and even when they don't, they're not clearly marked as extensions in the manuals [22:31:59] <hyc> yeah, that's the worst part [22:32:23] <hyc> but so many are just gratuitous - a new "user-friendly" way to do what the command already does [23:32:12] <CIA-1> ffmpeg: stefano * r22735 /trunk/ (383 files in 5 dirs): [23:32:12] <CIA-1> ffmpeg: Define AVMediaType enum, and use it instead of enum CodecType, which [23:32:12] <CIA-1> ffmpeg: is deprecated and will be dropped at the next major bump. [23:32:12] <CIA-1> ffmpeg: stefano * r22736 /trunk/ (libavcodec/avcodec.h libavutil/avutil.h): [23:32:12] <CIA-1> ffmpeg: Move AVMediaType from libavcodec to libavutil. [23:32:13] <CIA-1> ffmpeg: This allows applications/libraries which require that symbol [23:32:14] <CIA-1> ffmpeg: (e.g. libavfilter) to be compiled without to depend on the presence of [23:32:14] <CIA-1> ffmpeg: libavcodec/avcodec.h, which may not be installed. [23:43:01] <CIA-1> ffmpeg: stefano * r22737 /trunk/doc/APIchanges: [23:43:02] <CIA-1> ffmpeg: Update APIchanges after the enum CodecType -> enum AVMediaType [23:43:02] <CIA-1> ffmpeg: transition. [23:47:21] <CIA-1> ffmpeg: stefano * r22738 /trunk/cmdutils.c: [23:47:21] <CIA-1> ffmpeg: Issue a more general message when the function which sets an option [23:47:21] <CIA-1> ffmpeg: fails. [23:47:21] <CIA-1> ffmpeg: It may fail not only because of an invalid value for the option, but [23:47:21] <CIA-1> ffmpeg: also for other reasons, e.g. memory problems etc.

1 0

IRC log for 2010-03-29
by irc＠mansr.com 30 Mar '10

30 Mar '10

[00:25:59] <DonDiego> what kind of machine is that where libmpeg2 is faster? [00:32:57] <astrange> core 2 x86-64 (http://lowendmac.com/macbookpro/15in-macbook-pro-june-2007.html) [00:35:32] * peloverde is excited that a student is interested in BSAC [00:35:54] <DonDiego> what was bsac again? [00:36:41] <DonDiego> and what are you working on these days? parametric stereo in aac? [00:37:56] <peloverde> BSAC is AAC with an alternate entropy/quantization scheme [00:38:09] <peloverde> And yes I'm working on PS decoding ATM [00:39:36] <peloverde> BSAC is mainly used in T-DMB IIRC [00:39:44] * Kovensky notices that faac can't do sbr or ps [00:40:53] * Dark_Shikari notes that ff aac is worse than adpcm [00:41:14] <Dark_Shikari> and thus we shouldn't be talking much about faac. [00:41:48] <peloverde> faac isn't distributable [00:41:57] * Kovensky also notices that flv supports ADPCM but the spec doesn't bother saying which ADPCM [00:42:22] <astrange> read the lavf demuxer to find out which one [00:42:34] <Dark_Shikari> adpcm_swf [00:49:10] <peloverde> Also for no purposes should ffaacenc be considered a useful AAC encoder, it got merged as an artifact of the retarded way our source repositories are set up [00:49:53] <Dark_Shikari> then disable it [00:50:13] <Dark_Shikari> by the way, if I, say, got a $20k bounty to make it useful [00:50:16] <astrange> ffdca is 3x faster than libdta on a random file [00:50:20] <Dark_Shikari> would you be able to make it happen? [00:51:09] <Dark_Shikari> or kostya [00:53:06] <peloverde> Dark_Shikari, I could make something happen, it largely depends on if changes actually needed to be merged or howmuch I could get away with under the general doctrine of maintainer's prerogative [00:53:36] <Dark_Shikari> suppose it was "do whatever you want, I don't care, as long it gets into ffmpeg" [00:55:41] <peloverde> hmmm [00:55:55] <DonDiego> astrange: quick tests with http://samples.ffmpeg.org/MPEG2/dothack2.mpg indicate that ffmpeg2 is faster than libmpeg2 on my g4 [00:55:59] <Dark_Shikari> Not saying I can get this for you, but I suspect there are those who would want it. [00:56:09] <Dark_Shikari> and I may or may not end up talking to one throughout the course of my other business. [00:56:20] <Dark_Shikari> so I'd like to know what the situation is, so I could tell them [00:57:14] <DonDiego> gnite [00:59:48] <peloverde> I have too many doubts about my ability to complete such a project [01:00:03] <Dark_Shikari> what about kostya? [01:00:10] <Dark_Shikari> also, I just found a noncompliance issue in ffmpeg h264 [01:00:25] <peloverde> I don't know, you would have to talk to him yourself [01:00:39] <Dark_Shikari> yeah, I'll ping him when he's on [01:01:36] <mru> Dark_Shikari: another one? [01:02:55] <Dark_Shikari> another? what other [01:03:15] <mru> one of the conformance tests has been failing forever [01:03:21] <mru> never looked into why [01:03:39] <Dark_Shikari> this one is made with x264 [01:03:41] <iive> peloverde: even the longest trip starts with one small step. If you know what should be done, then ... [01:03:42] <Dark_Shikari> so it cannot possibly be that evil [01:04:06] <Dark_Shikari> also, is abs(td) >> 1 equal to abs(td/2)? [01:04:27] <iive> td=-1? [01:04:35] <Dark_Shikari> if not, ffh264 and x264 are both wrong [01:04:38] <Dark_Shikari> (unrelated issue) [01:04:51] <Dark_Shikari> abs(-1) >> 1 = 0 [01:05:00] <Dark_Shikari> abs( -1 / 2 ) = 0 [01:05:14] <iive> are you sure -1/2=-1 ? [01:05:18] <mru> yes [01:05:34] <iive> hum, no -1>>==-1 [01:05:44] <mru> yes [01:05:58] <mru> >> is not equivalent to / for negative numbers [01:05:59] <Dark_Shikari> also, I think implicit weightb is wrong for mbaff. [01:07:02] <iive> (-1>>1)==-1 [01:07:06] <mru> yes [01:07:12] <astrange> abs(x)>>1 == abs(x/2) except for INT_MIN [01:07:32] * mru should have said no a while ago [01:07:41] <mru> -1/2 == 0 [01:07:53] <Dark_Shikari> ok, INT_MIN will never occur in this case. [01:08:01] <mru> INT_MIN is evil [01:08:12] <Dark_Shikari> we're having this really really really weird issue in x264 [01:08:20] <Dark_Shikari> slices + weightb + interlaced generates non-compliant output [01:08:32] <Dark_Shikari> remove any one of the three, and it works [01:08:39] <Dark_Shikari> I cannot imagine wtf is going [01:08:41] <Dark_Shikari> *going on [01:08:43] <mru> did you verify the stream with JM? [01:08:48] <Dark_Shikari> That's what I'm using. [01:08:59] <mru> oh, sorry [01:09:05] <Dark_Shikari> I wouldn't imagine testing with anything else [01:09:06] <mru> I thought you were still talking about ffh264 [01:09:14] <iive> in what sense it is non-compliant? [01:09:24] <Dark_Shikari> iive: cmp x264_output.yuv jm_output.yuv fails [01:10:06] <iive> x264 have yuv output :O [01:10:23] <Dark_Shikari> --dump-yuv [01:10:40] <iive> these are the reference frames, i guess. [01:10:43] <Dark_Shikari> yes. [01:10:50] <Dark_Shikari> used for exactly this purpose. [01:11:26] <iive> is ffh264 decode output closer to jm, to x264 or neither? [01:11:59] <Dark_Shikari> ffh264's problem is separate and much worse [01:12:06] <Dark_Shikari> I just decided to test it while I was at it [01:13:07] <iive> Dark_Shikari: test x264 without asm, too. [01:14:35] <Dark_Shikari> asm doesn't fix it. but you know what does? using 1 slice in B-frames only, and using slices in all other frames. [01:15:16] <iive> Dark_Shikari: have you compared frames, to see where the error appears in the picture? [01:15:42] <Dark_Shikari> well I _know_ basically where the problem is [01:15:44] <Dark_Shikari> it's in bipred blocks [01:15:56] <Dark_Shikari> because, somehow, slicing is having an effect on weightb [01:16:01] <Dark_Shikari> when it obviously shouldn't. [01:16:10] <Dark_Shikari> (or, equally, slicing is somehow having no effect on weightb, when it should) [01:16:49] <iive> btw, have h264 got spacial scalability in the standard? [01:17:04] <iive> last time i checked there was no such thing. [01:17:17] <Dark_Shikari> yes. svc [01:17:24] <Dark_Shikari> went in 3 years ago [01:19:50] <iive> have it been used somewhere? [01:20:15] <iive> broadcast, bd, x264? [01:20:22] <Dark_Shikari> google chat [01:21:05] <osaft> svc was one of the questions in my exam, a few weeks ago [01:21:43] <astrange> oh, the google chat installer for os x creates ~/Library/QuickTime owned by root and breaks anything that tries to install afterwards [01:26:01] <kierank> iive: before 3d came along there were plans to do 1080p50 with dvb using svc [01:26:32] <iive> kierank: they should have gone with the 50fps [01:28:15] <kierank> 50fps won't sell new tv subscriptions though; 3d will [01:28:23] <kierank> oh and physical tvs as well [01:30:09] <BBB___> hi spyfeng [01:33:20] <iive> kierank: you mean existing hdtv can play 50fps? they'd better do. [01:33:44] <kierank> the "HD ready 1080p" sticker iirc has 1080p50/60 support [01:33:49] <iive> but I have really big doubts about stereoscopic tv. [01:34:12] <kierank> sky people say sport looks v. good in 3d but i've never seen that before so i can't comment [01:35:36] <CIA-1> ffmpeg: darkshikari * r22714 /trunk/ffpresets/ (6 files): [01:35:36] <CIA-1> ffmpeg: Update x264 presets in line with latest x264 changes. [01:35:36] <CIA-1> ffmpeg: Patch by Lou Logan. [01:43:01] <iive> kierank: there are too many people who complain by the glasses. and other alternatives are no better. [01:43:21] <pasteeater> Dark_Shikari: thanks for applying. [01:43:25] <kierank> the polarised glasses aren't too bad iive [01:43:46] <kierank> and the 1080i side by side standard isn't nice either [01:44:48] <iive> if you are lucky enough to get polarised one :) still you should be careful what you use for lightning in the room. [01:45:21] <kierank> the tv manufacturers who are selling shutter glasses at $200 each are smoking crack [01:47:23] <iive> i have no ground to deny that fact. [01:49:36] <iive> n8 ppl. [02:51:13] <CIA-1> ffmpeg: lorenm * r22715 /trunk/libavcodec/bitstream.c: [02:51:13] <CIA-1> ffmpeg: optimize init_vlc(). [02:51:13] <CIA-1> ffmpeg: Reduce worst case time from O(N^2) to O(N*log(N)). [02:51:13] <CIA-1> ffmpeg: Speedup average case by a factor of 10 in ffv2 (total decoding speed +4-25%), [02:51:13] <CIA-1> ffmpeg: factor of 1.3 in ffvhuff (total +0.5%), [02:51:14] <CIA-1> ffmpeg: factor of 1.8 in indeo5 (total +1%), [02:51:14] <CIA-1> ffmpeg: factor of 1.1 in mjpeg (total +0.1%). [02:51:15] <CIA-1> ffmpeg: lorenm * r22716 /trunk/libavcodec/bitstream.c: indent [03:34:28] <Compn> oooo [03:34:33] <Compn> optimizing [03:42:30] <peloverde> Does anyone have any advice on how to section off part of a project as a qual task? [03:42:41] <Dark_Shikari> what project? [03:42:42] <Dark_Shikari> bsac? [03:43:07] <peloverde> yeah, bsac [03:43:28] <Dark_Shikari> ideas, knowing NOTHING about bsac: [03:43:33] <Dark_Shikari> 1) write the arithmetic coder [03:44:07] <Dark_Shikari> 2) write whatever the core residual coder is (the eqivalent of decode_residual in h264) [03:44:40] <Compn> is the bsac spec all there ? [03:44:45] <Compn> i mean, nothing to reverse engineer ? [03:44:58] <Compn> and the spec is mostly readable ? [03:45:31] <peloverde> it's all there and mostly readable (it's mixed with a lot of irrelvent crap, kind of like ASP) [03:46:11] <Compn> i'd say splitting the spec up would be a good half-qual task [03:46:21] <Compn> at least it would prove if said student can read a spec ;) [03:46:54] <Compn> i guess one cant really code a postfilter before the decoder is created [03:47:19] <Compn> maybe a qual task would be to implement another aac subtype ? [03:47:28] <Compn> which maybe simpler than bsac or whatnot [03:48:47] <Compn> optimize some part of the aac decoder ? [03:57:44] <Dark_Shikari> Compn: imo the qual task should represent part of the final task [03:57:49] <Dark_Shikari> so the student feels he has accomplished part of his goal [03:58:47] <peloverde> agreed [03:59:03] <Dark_Shikari> also, IMO a qual task should be 1-3 days' work [03:59:25] <Dark_Shikari> with the expectation that if the student completes it to a reasonable level of satisfaction, he is almost guaranteed the spot. [04:05:14] <Compn> thats a good idea [04:05:28] <Compn> whos going to split all those slots into qual tasks? :) [04:05:44] <Dark_Shikari> the people responsible for each project [04:20:56] <peloverde> Does arithmetic scalefactor/noise/intensity decoding seem reasonable? [04:23:55] <Dark_Shikari> could you do it in 5 hours? [04:27:11] <peloverde> If we said for the base layer, then yeah I think so [04:28:06] <Dark_Shikari> then make that a task. [04:28:13] <Dark_Shikari> and do it fast, deadline is approaching [04:31:48] <peloverde> ok [05:25:29] <thresh> mourning [06:09:37] <_av500_> moaning [06:09:57] <kshishkov> keinen guten morgen? [06:10:33] <_av500_> i try to stick with the channel spirit [06:10:55] <kshishkov> exorcise it instead [06:13:38] <kshishkov> and for rants I do something like http://codecs.multimedia.cx/?p=272 [06:25:40] <superdump> morning [06:30:51] <kshishkov> morrow [07:47:24] <KotH> grüezi [07:47:57] * elenril throws EENCODING at KotH [07:49:15] * KotH catches it and calls ~elenril() [07:49:46] <astrange> http://pastebin.com/us39NDTJ per-codec defaults proposal [07:50:09] <elenril> KotH: have you been writing in forbidden languages? [07:50:44] <Dark_Shikari> astrange: the good: it fixes [07:50:46] <Dark_Shikari> *fixes ffmpeg [07:50:50] <Dark_Shikari> the bad: it doesn't fix other lavc apps [07:50:55] <astrange> yeah [07:51:11] <Dark_Shikari> But it's a possible solution for now. [08:02:35] <KotH> elenril: i've been investigating new languages [08:05:03] <superdump> astrange: what about -fpre? [08:07:12] <astrange> hmm [08:07:19] <Dark_Shikari> and what about windows? [08:07:21] <astrange> fpre needs to be read after the defaults [08:08:00] <astrange> what about windows? [08:08:09] <Dark_Shikari> the fact that it doesn't have a /usr/share [08:08:14] <Dark_Shikari> and thus won't load defaults automatically [08:10:37] <astrange> if you just distribute an ffmpeg.exe it won't work, yeah [08:10:44] <Dark_Shikari> not just that [08:10:47] <Dark_Shikari> there is no way to autoload on windows [08:10:59] <Dark_Shikari> afaik. [08:11:22] <astrange> you can search argv[0]+/ffpresets/ [08:11:35] <Dark_Shikari> does it do that? [08:14:01] <astrange> no [08:14:18] <astrange> the distributor could also set --datadir in configure and it'll look there, if that's possible [08:20:43] <pengvado> argv[0] is a path on windows? [08:21:13] <astrange> it would be nice if it was [08:21:26] <kshishkov> argv[0] is program name as it was executed [08:22:04] <astrange> pretend that was dirname(argv[0]) [08:24:03] <pengvado> not the point. argv[0] is whatever the user typed. if the program was invoked by the name of "ffmpeg", letting the shell search through $PATH, then argv[0] will contain "ffmpeg" and no directories. [08:30:33] <astrange> problems: there should be defaults for muxers too, something wrong will happen if you put vcodec= in a video codec default [08:31:16] <kshishkov> why? that would mean "you really don't want to use that codec" [08:35:26] <Dark_Shikari> we have muxer defaults [08:35:38] <Dark_Shikari> flv is mp3 for example [08:35:46] <Dark_Shikari> or adpcm if no lame [08:44:01] <saintd3v> ffaac 8-) [08:44:53] <jai> if you are compressing pink noise, then yeah ;) [08:45:16] <saintd3v> even then i would think it would fail horribly :P [08:46:08] <kshishkov> no, that reminds me of a joke - "haircut machine for everybody! But all heads are different. Only before the first shave with it" [08:47:05] <kshishkov> so you can reliably encode everything into pink noise with ffaacenc ;) [08:48:48] <astrange> the default for mp4 is ffaac [08:48:52] <astrange> it has valgrind warnings :/ [08:49:21] <saintd3v> why not mp3? [08:50:05] <jai> the policy is native > external lib iirc [08:51:14] <astrange> quicktime can't play mp3-in-mp4 [08:51:22] <astrange> and there isn't an mp3 encoder by default [08:51:52] <kshishkov> can someone integrate Lame into FFmpeg? It's about right time [08:52:11] <jai> seriously? [08:52:15] <kshishkov> yes [08:52:56] <superdump> i very much doubt that will happen [08:53:02] <jai> if at all possible, that would still require trimming of the code [08:53:09] <superdump> we could do it, but why bother [08:53:23] <jai> converting the existing lame codebase to use fflibs [08:54:31] <astrange> iirc helix is competitive with lame and much smaller [08:55:13] <kshishkov> helix as "opensourcey project from Buffering Inc."? [08:55:31] <astrange> yes [08:55:47] <astrange> that doesn't mean integrate helix, but it means you can write a competitive encoder if you really feel like it [08:57:48] <saintd3v> how about we all just work on making ffaac not suck? [08:57:53] <jai> of course, but with lame around the motivation to do that is really low :) [08:58:22] <saintd3v> rm -rf /lamedir [08:58:32] <saintd3v> oops, well, onto ffaac [08:58:38] <jai> alex is working on ffaacenc [08:58:49] <saintd3v> yes i know [08:59:30] <jai> also, other than "output sucks" are there any known bugs ? [08:59:52] <jai> it does write a valid bitstream right? [09:01:28] <kshishkov> it should [11:40:42] <KotH> twnqx: ? [12:54:08] <DonDiego> hrm [12:54:15] <DonDiego> yuvi hasn't been online in ages.. [12:54:26] <CIA-1> ffmpeg: jai_menon * r22717 /trunk/libavcodec/tta.c: Cosmetics : add a space after ",". [12:54:59] <kshishkov> last time you said that he shourly appeared and went offline again [12:55:33] <kshishkov> *shortly [12:59:31] * DonDiego conjures up yuvi again [13:03:09] * KotH always knew that DonDiego is into black magic [13:04:27] <justlooking_> argv[0] is a path on windows ? http://msdn.microsoft.com/en-us/library/aa364963(VS.85).aspx http://www.google.co.uk/search?rlz=1C1CHMZ_en-GBGB340GB355&sourceid=chrome&… [14:26:20] <nfl> Hi, could someone please apply my YOP patch? [14:33:29] <nfl> superdump: well, could you recommend a qual task for me? [14:33:54] <superdump> did you write a decoder for YOP? [14:33:59] <superdump> what is that format like? [14:34:18] <nfl> yes, decoder + demuxer [14:35:48] <nfl> I didn't exactly write it though, modified an existing patch [14:36:47] <superdump> ah, ok [14:36:55] <superdump> what modifications did you have to make? [14:37:41] <nfl> implemented seeking, changed o/p format from rgb24 to pal8, other minor corrections [14:38:27] <merbzt> superdump: we could add g729 and g723.1 soc tasks also [14:38:52] <superdump> merbzt: yup, sure [14:39:40] <superdump> if we add those, nfl could maybe write a frame parser for one of those instead of amr-wb [14:39:53] <merbzt> yes [14:40:02] <merbzt> there is a g729 patch though [14:40:12] <merbzt> and samples are scarse for g723.1 [14:40:43] <superdump> mmm [14:40:53] <superdump> any reference code for g723.1? [14:40:58] <merbzt> I have [14:41:11] <merbzt> the IPP should be better though [14:41:19] <merbzt> it has encoder for it [14:41:23] <merbzt> me thinks [14:55:08] <nfl> sorry abt that, i got cut off [14:55:25] <nfl> merbzt: so can i have a look at the reference code? [14:55:38] <merbzt> nfl: look at the IPP code [14:55:48] <merbzt> I don't have the ref code at hand [14:56:13] <nfl> IPP? [14:56:34] <merbzt> http://software.intel.com/en-us/intel-ipp/ [14:57:08] <nfl> merbzt: thanks [15:10:37] <BBB> you guys will write more speech decoders? [15:10:40] <BBB> that's a good idea [15:11:10] <merbzt> actually we need g723.1 and g729 encoders also [15:11:18] <merbzt> to be feture complete [15:11:26] <merbzt> *feature [15:11:37] <pJok> how about a better ffaacenc? ;) [15:11:39] <BBB> let's start with decoders :) [15:12:02] <mru> aacenc is much more useful that speech decoders imo [15:15:15] <BBB> then someone needs to add aacenc-related tasks to the wiki for gsoc [15:15:16] <BBB> nobody did [15:15:37] <mru> there's one problem: aacenc is way too big for gsoc [15:20:49] <kshishkov> mru: you could've said that _two_ years ago [15:21:31] <mru> I didn't know that then [15:22:50] <kshishkov> well, three years ago some people didn't suspect that REing RV40 would take more time than till GSoC start [15:23:24] <merbzt> hahaha, you are so gullible kostya :) [15:24:12] <kshishkov> indeed [15:24:18] <kshishkov> yet sometimes it works [15:24:34] * kshishkov is not going to say anything about WVP2 [15:24:47] <merbzt> huhuhu [15:24:57] * pJok coughs [15:25:03] <pJok> D*CK [15:26:31] <pJok> worth a shot [15:26:39] <kshishkov> en and? [15:26:43] <pJok> jau [15:26:49] <kshishkov> eller gammel On2? [15:27:08] <pJok> my first duck was TM2 afair [15:27:15] <pJok> from FFVII [15:27:51] <merbzt> gammal [15:27:55] <pJok> i also made my first proper RE of a format and my first c++ program in borland c++ builder [15:28:08] <pJok> the format i RE'd was the packed files [15:28:17] <pJok> and i made a winzip like unpacker for it [15:28:24] <kshishkov> merbzt: sounds like some cryptographer's name [15:29:38] <merbzt> that's gamal [15:29:56] <kshishkov> pJok: my blog started with an attempt to understand On2 TM2 decoder source [15:30:48] <kierank> was the source code that bad? [15:30:53] <pJok> kshishkov, i wasn't that advanced back then [15:31:05] <pJok> now i just read source and puke if its unreadable ;) [15:31:06] <kshishkov> kierank: of course [15:33:26] <pJok> funny that i didn't turn out to be a programmer [15:34:50] <kshishkov> I was not that advanced when C++ Builder was released [15:35:03] <pJok> i was doing most my things in visual basic [15:35:06] <pJok> and quickbasic [15:35:19] <pJok> in fact, i started out doing my concept code in quickbasic and ported it to c++ [15:35:28] <kshishkov> that's the reason you've not turned into programmer [15:35:34] <pJok> well [15:35:42] <pJok> probably [15:35:54] <pJok> that and i couldn't be bothered with actually doing useful stuff [15:38:35] * kshishkov has not written any useful decoder so far [16:16:38] <nfl> merbzt: by g729, you meant the existing g729 decoder is to be extended for the unimplemented extensions? [16:17:31] <jai> first it should be reviewed and committed [16:19:02] <nfl> then what is lavc/g729dec.c ? [16:24:17] <jai> parts which were reviewed and committed [16:25:17] <kshishkov> yes, we happen to have some of unfinished stuff in lav* [16:27:12] <jai> also, for future reference, we support `ffmpeg -codecs` :) [16:27:13] <av500> unffinished [16:27:18] <nfl> ah, i see that it's not compiled [16:29:01] <jai> av500: lavc/h264enc.c comes to mind [16:29:12] <av500> x264? [16:29:47] <jai> no, the the sucky one [16:30:10] <av500> jai: no, i mean why do h264enc when there is x264? [16:30:39] <jai> av500: i don't see the point, but that doesn't stop people from posting patches :) [16:31:00] <av500> it is a patch magnet :) [16:39:59] <BBB> av500: license? [16:40:09] <BBB> x264 is gpl [16:40:10] <mru> isn't open source great? [16:40:13] <BBB> some people dislike license [16:40:23] <BBB> it's like catholics and protestants killing each other in ireland [16:40:26] <BBB> they did it for years [16:40:28] <j0sh> BBB, did you want me to combine the theora->xiph renaming and vorbis import? [16:40:45] <BBB> j0sh: I want you to start with svn cp fileold filenew [16:40:52] <BBB> j0sh: from then on, small patches is good [16:41:24] <BBB> you could separate the renaming and vorbis import [16:41:31] <BBB> whichever you think is better [16:41:36] <j0sh> BBB, lol ok... the changes overlap a bit so it's kind of tricky, i have to play with the diffs manually [16:42:05] <av500> mru: btw, brookie turned out as expected :) [16:42:06] <j0sh> i learned git for this, but didnt realize the huge patches from it were a problem [16:42:27] <twnqx> it's a review issue [16:43:26] <BBB> OH [16:43:30] <BBB> it's public [16:43:33] <BBB> guys, check mozilla [16:43:38] <BBB> they did something cool for a change [16:43:43] <mru> "never experienced a halting problem" .... rotfl [16:43:48] <BBB> http://www.0xdeadbeef.com/weblog/wp-content/uploads/2010/03/mcscreen.png [16:44:14] <mru> BBB: they can't even spell ffmpeg [16:44:22] <astrange> what's with the completely wrong window size? [16:44:23] <BBB> who gives a damn? [16:44:25] <BBB> they attribute? [16:44:31] <BBB> that's better than anything they've done so far [16:45:33] <av500> mru: right, that made my morning [16:47:13] <mru> what about a meta-halting problem? is it possible to determine if it's possible to determine if a given program will halt? [16:47:41] <kshishkov> now how can we convince certain video hosting site to acknowledge using of FFmpeg? [16:47:57] <mru> we could troll them like we did mediacoder :-) [16:47:58] <kshishkov> mru: M$ Windows 95 is the solution - it will [16:48:12] <mru> randomly insert a watermark if we detect, somehow, that we're running on their systems [16:48:37] <av500> mru: make lav* phone home for a start [16:48:57] <av500> s /home/china( [16:49:17] <mru> of course the yt people might be competent enough to remove any such nasties [16:49:37] <av500> I trust you to make it totally unobvious :) [16:49:50] <av500> e.g. write tcp stack in neon [16:50:01] <av500> err, sse2 [16:50:39] <mru> some people say I did a good job making intreadwrite.h impenetrable... [16:50:54] <mru> that file is a bit of a macro hell [16:51:11] <elenril> http://tvtropes.org/pmwiki/pmwiki.php/Main/NiceJobBreakingItHero [16:51:30] <superdump> BBB: what's public? [16:52:37] <kshishkov> mru: that's because they haven't tries understanding IOCCC winning programs [16:52:40] <kshishkov> suckers! [16:52:42] <BBB> superdump: http://www.0xdeadbeef.com/weblog/wp-content/uploads/2010/03/mcscreen.png [16:53:00] <superdump> what's that got to do with mozilla? is miro a mozilla project? [16:53:08] <BBB> mozilla paid for it [16:53:12] <BBB> I don't know if they own it [16:53:13] <mru> I like the #include </dev/console> one [16:53:26] <BBB> and mozilla is heavily promoting it now [16:53:47] <astrange> miro ships perian on os x [16:53:54] <astrange> they were their own project, though [16:54:00] <astrange> with some silly name like "democracy" [16:56:53] <superdump> yes [16:56:57] <superdump> democracyplayer [16:57:32] <kshishkov> idiotic name [16:57:54] <superdump> democratic name [16:58:03] <superdump> i think they ended up thinking it was idiotic too [16:58:06] <superdump> so they changed it [16:58:07] <superdump> or blah [16:58:22] <kshishkov> you know, here "democratizer" is a semi-official name for truncheon [16:58:53] <superdump> heh [16:58:57] * superdump -> out [16:59:05] <superdump> hej dÃ¥ [16:59:10] <kshishkov> hej hej [17:34:28] <nfl> jai: can i pm you? [17:36:57] <CIA-1> ffmpeg: rbultje * r22718 /trunk/libavformat/rtsp.c: [17:36:57] <CIA-1> ffmpeg: Add a timeout to the select() call. Patch by Sam Gerstein <sgerstein bluefinlab [17:36:57] <CIA-1> ffmpeg: com>. [17:37:54] <CIA-1> ffmpeg: rbultje * r22719 /trunk/libavcodec/wmaprodec.c: Simplify interleaving code. [17:45:04] <bofh__> I was reading over the list of Google SoC projects and one thing jumped out at me: both lavf audio work and rewriting the audio conversion code require the rewriting of a resampling layer. Why not use libsamplerate/Secret Rabbit Code? License issues? Writing a resampling layer is *hard*, as long as all you want is something that does basic conversion then a simple interpolation algorithm using a bandlimited Kaiser window will work ... [17:45:11] <bofh__> ... quite well, aliasing is minimal even when doing nasty conversions like 44.1kHz<->48kHz, etc. However, if you want to get rid of the small amount of ringing/aliasing from this, this is *hard*. Various methods exist, anything from complex wavelet analysis to using digital forms of analog polyphase filter banks (aka the Julius O. Smith III method), these are hard to implement, even harder to get perfectly, right, and hence given ... [17:45:17] <bofh__> ... the existence of a library that already does so and does so quite well, I wonder why this isn't being used. [17:46:27] <Compn> what license and language is libsamplerate ? [17:46:30] <kshishkov> we don't like external dependencies, especially on not so standard libraries [17:48:29] <Dark_Shikari> aka NIH [17:48:33] <Dark_Shikari> NIH syndrome [17:48:50] * bofh__ snickers [17:48:59] <bofh__> Compn: 1 sec. [17:49:27] <mru> afaik libsamplerate lets you choose either fast and crap or slow and crap [17:50:43] <Compn> lol [17:51:30] <av500> mru: crappyness should be determined easily [17:52:51] <astrange> lavc has a resampler already [17:53:00] <astrange> ...two actually, i forget which one is actually used [17:53:22] <astrange> it's not as good as ssrc but probably is as good as anything else [17:53:49] <bofh__> sigh, FSF syndrome. It's GPL, and thus probably will cause issues. [17:53:54] <bofh__> astrange: that's the other thing I noted :V [17:54:11] <bofh__> I'm willing to bet it's just bandlimited Kaiser interpolation, that's very simple and quite good. [17:54:22] <Dark_Shikari> I love the ffmpeg resampler for one reason [17:54:27] <Dark_Shikari> it has CONFIG_AUDIOPHILE_KIDDY_MODE [17:54:31] <mru> I remember michael improving the resampler massively a couple of years ago [17:54:32] <bofh__> ROFL. [17:54:35] <bofh__> What does that do? [17:54:42] <bofh__> I must know. [17:54:44] <Dark_Shikari> uses a ridiculous amount of extra precision internally at the cost of speed [17:55:05] <bofh__> That is hilarious. [17:55:12] <bofh__> Whoever did that deserves an award. [17:55:28] <Dark_Shikari> michael iirc ;)_ [17:55:31] <mru> of course [17:56:04] <mru> someone complained it was bad, slow, or both [17:56:08] <mru> so michael rewrote it [17:56:12] <Dark_Shikari> and he added a KIDDY_MODE [17:56:15] <mru> yep [17:56:21] <Dark_Shikari> it only took a couple of lines of ifdefs [17:56:40] <BBB> bofh__: why would we use an external resampler if we already have one? [17:56:50] <bofh__> Anyway, now that rambling is done, more interesting things can be talked about, like implementing DTS or BSAC AAC. DTS, specifically. [17:56:52] <Dark_Shikari> 'cause it's better [17:57:01] <BBB> Dark_Shikari: prove it [17:57:06] <bofh__> BBB: it was just a thought based off reading their wikipedia page. [17:57:12] <bofh__> s/their/your/ [17:57:16] <Compn> bofh__ : mplayer had its own old resample code, but it was ditched for the lavc resampler [17:57:20] <Dark_Shikari> it's the same issue with the RTMPE issue [17:57:23] <Compn> i wonder if vlc / xine have resampler either [17:57:28] <Dark_Shikari> BBB: I'm not saying it is, I'm saying that would be the reason to ditch it [17:57:34] <BBB> ah, ok [17:57:35] <Dark_Shikari> like the whole thing with librtmp [17:57:37] <BBB> well yeah [17:57:42] <BBB> I thought that was shit [17:57:46] <bofh__> What exactly happened with librtmp? [17:57:53] <BBB> 5 yrs from now I have to get a student to integrate librtmp into ffmpeg [17:58:08] <Compn> 5 years from now we hope rtmp will be gone [17:58:14] <BBB> because the maintainer is too god damn stupid to see that 5 years from now, he won't work on it anymore and nobody else will either [17:58:16] <Compn> and adobe with them [17:58:25] <BBB> Compn: we want to keep supporting old formats [17:58:31] <BBB> why else do we have support for game formats? [17:58:34] <Dark_Shikari> Compn: hahahahahha you wish [17:58:43] <kshishkov> BBB: the maintainer hears ;) [17:58:45] <Compn> old formats yes, but not old streaming servers ? [17:58:55] <mru> vlc definitely has a resampler [17:58:58] <Compn> e.g. there is no vdo:// support :P [17:58:59] <BBB> kshishkov: not you, hyc [17:59:07] <mru> and it uses it even when it shouldn't [17:59:25] <Compn> mru : at least it doesnt get stuck in some infinite resample loop :) [17:59:27] <av500> now where did I see that before... [17:59:39] * av500 says arts and hides [18:00:21] <bofh__> Speaking of useless formats, who the fuck uses Realaudio Lossless? [18:00:32] <bofh__> Let me rephrase that. Who the fuck still uses Realaudio. [18:00:33] <Compn> Dark_Shikari : btw some website auto-downloaded a pdf to me yesterday, i'm guessing its a virus :D [18:00:55] <Compn> javascript + pdf + adobe = fail [18:00:57] <bofh__> No, let me rephrase that again. Realnetworks hasn't gone bankrupt yet with everyone stopping the use of their shit formats yet? [18:01:11] <av500> bofh__: realvideo and audio has several hundred million users [18:01:14] <kshishkov> unfortunately, no [18:01:17] <Compn> bofh__ : they signed contracts with mlb and some other big sites to host videos [18:01:29] <Compn> they arent going anywhere anytime soon [18:01:41] <bofh__> wait, they haven't gone bankrupt as a company yet? could have sworn. [18:01:52] <bofh__> Disappointing. [18:02:07] <av500> bofh__: 90% of chinese p2p content is rv/ra [18:02:38] <Compn> anyone know where the chinese bit torrent sites went? bt.ydy left me and now i'm a bit lost ... [18:02:40] <kshishkov> av500: do they pay for it? [18:02:47] <av500> kshishkov: for p2p? [18:03:00] <av500> as in pay2play? [18:03:13] <Compn> chinese vod sites might pay real for an encoder license [18:03:20] <Dark_Shikari> doubt it [18:03:24] <av500> Compn: they dont use real [18:03:34] <Compn> most use wmv... [18:03:45] <av500> yes, commercial use of rv in china is none [18:03:47] <bofh__> Poked through resample2.c, it's a Kaiser window dealie with some filter bank stuff tacked on loosely, which is what I expected. [18:03:55] <bofh__> Also, audiophile_kiddy_mode is hilarious. [18:03:57] <av500> I saw a survey, it was really only p2p [18:04:31] <BBB> bofh__: please do something useful or go away [18:04:32] <janneg> libsamplerate is almost as large as libavcodec [18:04:36] <BBB> you're annoying me [18:04:53] <Compn> BBB : hehe, you seem on edge about stuff... [18:05:01] <janneg> it ships a 8.8M large table [18:05:03] <kshishkov> BBB: and lame nickname too ;) [18:05:23] <BBB> Compn: nah, I get annoyed when my window keeps blinking for no apparent good reason [18:05:55] * av500 must not ask janneg how BBB is doing [18:06:49] <av500> lol, from the rv survey in china: "RM is dominant for user shared content Efficiency of format is clearly recognized" [18:06:56] <mru> tables bigger than 1/2 L1$ are usually a very bad idea [18:07:26] <janneg> av500: no reason to ask. there is a nice status page update regularly [18:07:48] <kshishkov> mru: L1 on ARM or on Intel chips? [18:07:57] <bofh__> BBB: alright, I could understand making that comment if I was spamming up the channel, but apparently conversation is forbidden here? Anyway, if you want me to be on-topic, I was asking about the task of implementing the DTS Encoder and if there is anything specific about it I should know before I apply, etc. [18:08:09] <mru> kshishkov: whatever you're running on [18:08:15] <mru> L1 doesn't actually differ that much [18:08:18] <bofh__> And got no reply above. So. Yeah. [18:08:36] <kshishkov> you've not asked it clearly [18:08:46] <BBB> bofh__: then wait for someone to reply, don't bullshit on about libsamplerate or how your personal dislike for real or other shit like that [18:09:02] <BBB> that has nothing to do with ffmpeg development [18:09:10] <kshishkov> merbzt cares most about DTS encoder [18:09:26] <bofh__> BBB: see comment about conversation being forbidden/etc (I am going to assume the answer is "yes", fwiw) [18:09:27] <kshishkov> he also has some working version for it [18:09:34] <BBB> bofh__: for you, yes [18:09:52] <bofh__> BBB: noted. [18:10:07] <Compn> bofh__ : mostly its a 'familiarize yourself with the code (decoder)' and read the specs, submit an application, ask the mentor which qualification task you should work on, and get starterd... [18:10:25] <Compn> any other question? [18:10:38] <janneg> mru: it's only 1.3M compiled. 340.000 floats [18:10:56] <mru> that's still several times bigger than many an L2 [18:11:06] <Dark_Shikari> BBB: we are quite allowed to bitch about real [18:11:12] <Dark_Shikari> that is a long-loved pasttime of ffmpeg developers [18:11:28] <bofh__> Compn: was wondering if there were any qualification tasks (for instance, the comment about RTSP/RSP mentions one) [18:11:32] <Dark_Shikari> in fact, so is bitching about _everything_, up to and including our own code [18:11:42] <kshishkov> mru: any good solution to reduce/move space needed for static VLCs? [18:11:56] <Dark_Shikari> "static VLCs"? [18:12:00] <Dark_Shikari> you mean binary space, or runtime space? [18:12:10] <kshishkov> runtime [18:12:21] <kshishkov> for binary it's all bss or something [18:12:23] <mru> INIT_VLC_STATIC? [18:12:27] <Dark_Shikari> ok, no better way then [18:12:41] <Dark_Shikari> if you meant binary space, you can use gradient prediction/etc to compress huffman tables [18:12:51] <kshishkov> mru: INIT_VLC_NEW_STATIC [18:12:52] <Compn> bofh__ : i think ffmpeg is trying a new approach this year, we are trying to make the qual task a small part from the SoC project, or at least related... so if you want to work on DTS encoder, the qual task would be to implement some small part of the encoder , you'd have to ask the mentor for that what he thinks the best qual task is [18:13:03] <Dark_Shikari> yeah, what Compn said [18:13:05] <mru> Dark_Shikari: or like zlib, huffman compress the huffman tables [18:13:06] <Dark_Shikari> ffmpeg is copying x264 ;) [18:13:32] <bofh__> Gotcha, and I assume for that it's a case of wait around for merbzt most likely. [18:13:37] <Compn> yes [18:13:45] <kshishkov> Dark_Shikari: usually before x264 gets there :P [18:13:50] <av500> bofh__: feel free to look at the code in the meantime :) [18:13:58] <bofh__> Okay, that is everything, will do. [18:14:04] <Compn> Dark_Shikari : have you put h264 in rm yet? :P [18:14:18] <bofh__> BBB: is idling forbidden as well? or can I do that without being bitched at? :P [18:14:37] <kshishkov> Compn: he can do that only as RV5 ;) [18:14:44] <Compn> bofh__ : BBB is an active devel, so you probably shouldnt bug him too much... [18:15:08] <kshishkov> bofh__: yes, contribute and earn some respect and then you can have all idle talk you like [18:15:24] <Dark_Shikari> bofh__: ignore BBB [18:15:31] <Dark_Shikari> he's in a bad mood obviously [18:15:34] <kshishkov> Compn: for some reason RM{VB} accepts only RealVideo for video codecs [18:15:39] <Dark_Shikari> but yes, contribute some [18:15:50] * BBB is a bit moody today, yes [18:15:53] <Dark_Shikari> kshishkov: yeah, I can't possibly figure out why [18:15:56] <Dark_Shikari> ;) [18:15:58] * jai hands BBB a beer [18:16:03] * BBB gets runk [18:16:08] <BBB> nope, still moody [18:16:10] * av500 hands BBB a real beer [18:16:13] <Compn> kshishkov : i'm still trying to locate more old samples , i thought there was some other things that fit into rm [18:16:18] <bofh__> Compn/Dark_Shishkov: I'm just teasing, my apologies to BBB if it got aggravating. kshishkov: that is the plan. [18:16:21] <Compn> at least there was BHIV , which was rv20 ? [18:16:22] * mru laughs in swedish at BBB's typo [18:16:31] <kshishkov> av500: give him a glass of pot vodka [18:16:39] <av500> I leave that to you [18:17:04] <kshishkov> av500: I don't even touch alcoholic drinks let alone drugs [18:17:43] <mru> most drugs are quite harmless to touch [18:17:52] <mru> you have to smoke them or so before they have an effect [18:18:44] <kshishkov> same for corked beer bottles yet I still won't touch them [18:23:09] <jai> bofh__: for dtsenc, the qual task was to port the float qmf and fix lfe generation iirc [18:23:20] <jai> bofh__: check the wiki, details should be there [18:24:23] <Dark_Shikari> mru: you will love this [18:24:25] <Dark_Shikari> http://theory.cs.uni-bonn.de/~ignatios/white%20space%2098.pdf [18:24:36] <Dark_Shikari> Stroustrup on adding the feature to the next C++ standard to allow overloading of the whitespace operator [18:24:53] <kshishkov> there is whitespace operator? [18:24:57] <Dark_Shikari> the space. [18:25:06] <Dark_Shikari> this lets you write Haskell in C++ ;) [18:25:14] <kshishkov> or Python? [18:25:20] <Dark_Shikari> myfunc a b c + yourfunc d e [18:25:43] <av500> Dark_Shikari: hint: April 1,1998 [18:25:46] <jai> ugh [18:25:54] <Dark_Shikari> av500: oh I know [18:26:10] <kshishkov> I knew Danes were crazy [18:26:20] <mru> he's norwegian [18:26:31] <kshishkov> nope [18:26:40] <kshishkov> born in Continental Denmark [18:27:08] <pJok> kshishkov, they are crazy... just look at me [18:27:15] * pJok is born in continental denmark [18:27:25] <av500> that crazy norwegian dane! [18:27:26] <kshishkov> BTW, do you know that some French architect is responsible for panel buildings (like in Miljonprogrammet)? [18:27:45] <kshishkov> pJok: he is from Aarhus IIRC [18:28:05] <pJok> i grew up at the border, so im about as danish as i am german [18:28:08] <mru> hmm, don't know where I got the idea he was norwegian [18:28:19] <kshishkov> and remember your guy from Odense? Who wrote _very_ creepy fairy tales? [18:28:30] <pJok> hehe [18:28:35] <kshishkov> or Danish philosophers? [18:28:42] <pJok> Niels Bohr [18:28:52] <pJok> H.C. Ørsted [18:29:00] <kshishkov> that one was good [18:29:19] <kshishkov> could not keep his wires straight though [18:34:15] <ramiro> how do I make gdb break whenever a certain memory address is written to? [18:34:32] <BBB> watch [18:34:43] <mru> and pray [18:34:43] <BBB> watch 0x1345 or watch struct->member [18:35:25] <ramiro> hmm, will that work with rip stuff too? [18:47:19] <Dark_Shikari> hmm. [18:47:44] <Dark_Shikari> I have a static array that's used in a given c file all over--but only with constant indices [18:47:50] <Dark_Shikari> however, i'ts still present in the output .o file [18:47:55] <Dark_Shikari> 1) will the linker remove it since it isn't referenced? [18:48:01] <Dark_Shikari> 2) why is it still there? [18:48:14] <av500> er, used or not? [18:48:26] <Dark_Shikari> it's not used because it's only accessed via constant indicex [18:48:28] <Dark_Shikari> *indices [18:48:31] <av500> "that's used" or "isn't referenced" [18:48:45] <Dark_Shikari> thus every access will be simplified to no longer be a reference [18:49:37] <janneg> pJok: TÃžnder, Tinglev, Bov or SÃžnderborg? [18:50:47] * janneg grew up around NibÃžl and went to a dansk bÃžrnehave [18:53:20] <mru> Dark_Shikari: did you verify that there really are no references left? [18:54:04] <Dark_Shikari> I grepped every reference to the array in the code [18:54:51] <Dark_Shikari> it's static const too [18:54:55] <mru> you could put the table in a separate section and link with --gc-sections [18:54:56] <pJok> janneg, bov [18:54:57] <Dark_Shikari> then again this is gcc 3.4, who knows [18:55:05] <mru> if gcc is too stupid to remove it by itself [18:55:11] <pJok> i went to the german kindergarten in padborg [18:55:26] <Dark_Shikari> btw, I'm using nm to check for it [18:55:29] <Dark_Shikari> I assume that's the right way [18:55:45] <mru> "german kindergarten" sounds like it should be a euphemism for something nasty... don't know why [18:55:56] <mru> at least it wasn't a catholic kindergarten [18:56:30] <mru> Dark_Shikari: no, nm won't tell you about references within the same object file [18:56:39] <mru> nm only prints the symbol table [18:56:58] * av500 survived german kindergarten [18:57:07] <Dark_Shikari> mru: but if it's not referenced and optimized away [18:57:11] <Dark_Shikari> it shouldn't be in the symbol table, right? [18:57:14] <mru> right [18:57:21] <Dark_Shikari> so obviously we know it wasn't optimized away [18:57:22] <janneg> kindergarten of the german minority in sÃžnderjylland [18:57:46] <mru> Dark_Shikari: yes, but you can't use nm to look for actual references to it [18:58:02] <Dark_Shikari> of course [18:58:06] <Dark_Shikari> I used grep for that [18:59:03] <mru> grep for what in what? [18:59:14] <Dark_Shikari> references to the table in the C code [18:59:39] <mru> yeah, but how did you check that gcc optimises them into constant expressions? [18:59:51] <Dark_Shikari> it's array[VALUE], where VALUE is a fucking enum [18:59:57] <Dark_Shikari> every single instance is that. [18:59:58] <mru> I get that [19:00:04] <Dark_Shikari> if it cannot optimize that into constant expressions it fails even worse [19:00:15] <mru> so did you check that? [19:00:23] <Dark_Shikari> how am I supposed to check that, psychic powers? [19:00:24] <mru> this is gcc ffs [19:00:29] <mru> gcc -S [19:00:32] <av500> objdump? [19:00:39] <mru> or check the relocation table [19:00:51] <mru> or forcibly remove it and see if it still links [19:01:04] <mru> objcopy can help with that [19:01:30] <Dark_Shikari> mru: it optimizes all references away [19:01:33] <Dark_Shikari> but doesn't remove the table [19:01:35] <Dark_Shikari> according to -s [19:01:48] * av500 is not surprised [19:01:53] <Dark_Shikari> also, it aligns a table of bytes to a 32-byte boundary [19:01:58] <Dark_Shikari> for no fucking reason [19:02:28] <mru> gcc aligns everything bigger than some undocumented size to an arbitrary, undocumented alignment [19:02:37] <mru> and it varies by architecture [19:03:01] <mru> the threshold is usually ~32 bytes [19:03:08] <Dark_Shikari> this is a 17-byte array [19:03:09] <Dark_Shikari> it aligns it to 32 [19:03:18] <Dark_Shikari> oh it gets worse [19:03:20] <Dark_Shikari> I reduced the array to 9 bytes [19:03:22] <Dark_Shikari> it STILL ALIGNS TO 32 [19:03:37] <mru> what type is the array? [19:03:40] <Dark_Shikari> uint8_t [19:03:57] <mru> maybe the threshold is as low as 8 bytes... [19:04:58] <Dark_Shikari> nope [19:05:01] <Dark_Shikari> at 7 bytes it still aligns to 32. [19:05:29] <Dark_Shikari> hmm. better stated, it doesn't align it to 32, it aligns the end of it to 32 [19:05:32] <Dark_Shikari> i.e. padding before the next array [19:05:57] <Dark_Shikari> still stupid. ugh. [19:05:58] <mru> so it's aligning whatever comes after [19:06:07] <mru> what comes after it? [19:06:13] <Dark_Shikari> which is also a small array of uint16_ts [19:06:50] <Dark_Shikari> gcc obviously isn't even trying to pack the arrays in an efficient way [19:18:40] <CIA-1> ffmpeg: reimar * r22720 /trunk/libavformat/rtsp.c: Some spelling fixes. [19:26:16] <BBB> j0sh: thanks for the patch, looks a lot better, will review in a bit if nobody beats me to it [19:27:49] <j0sh> BBB, np [19:28:30] <BBB> btw google student thing is open, it seems [19:29:06] <j0sh> yep, first day is today... need to do my application [19:29:51] <j0sh> is there any student interest in playlist support? i was looking at adaptive http streaming from apple, i think that'd be a cool feature to have clientside but needs playlist support [19:30:08] <jai> smooth streaming? [19:30:27] <BBB> I think there was a sudent doing it last year [19:30:30] <BBB> didn't really go great [19:30:32] <elenril> there was a playlist patch last summer [19:30:40] <BBB> there was a lot of discussion on how to do playlists [19:30:48] <BBB> which sort of blinded the actual hacking [19:30:48] <elenril> anybody knows why it wasn't applied? [19:31:00] <j0sh> jai, im not sure, its used on the iphone: http://tools.ietf.org/id/draft-pantos-http-live-streaming-01.txt [19:31:03] <BBB> elenril: disagreement on how i ought to be done :( [19:31:44] <j0sh> apparently apple is demanding large iphone app vendors to implement it [19:31:48] <jai> j0sh: right [19:31:51] <elenril> iirc the thread ended with the student sending patch that was supposed to fix all the issues [19:31:54] <elenril> and then silence [19:32:03] <jai> thats unfortunate :/ [19:32:17] <jai> whatever happened to the student? [19:59:07] <BBB> j0sh: silly question, but you tested it right? [19:59:17] <BBB> j0sh: if so, all patches ok, I'll apply in a bit unless someone beats me to it [19:59:33] <BBB> don't forget svn rm rtpdec_vorbis.[ch] [20:01:56] <j0sh> BBB, tested it with video, yeah [20:02:00] <BBB> audio also? [20:02:02] <BBB> :) [20:02:35] <j0sh> audio, kinda -- the samples that work, seem to encode fine [20:02:43] <j0sh> but a larger issue is, i am stone deaf :) [20:03:46] <BBB> oh right, that makes audio testing problematic... [20:03:51] <BBB> hmm... need to find a solution to that [20:03:55] <BBB> I guess I could test it [20:03:55] <j0sh> heh yeah [20:04:14] <j0sh> does ffplay produce a spectrograph [20:04:19] <BBB> if you use -an [20:04:25] <BBB> er... [20:04:25] <BBB> -vn [20:05:56] <j0sh> i did crcs, md5sum for audio, they match before-and-after the patch, but i dont know if it works in the first place [20:07:22] <j0sh> as of now i cant ffplay audio-only tracks, my system's sound is busted (realized it yesterday; but thats probably been the case for years now) [20:07:40] <j0sh> tried fixing it yesterday, no luck so far, but i'll keep working on it [20:11:44] <BBB> if md5s match, you're fine [20:11:47] <BBB> I'll commit in a bit [20:11:51] <BBB> taking a phone call first... [20:11:53] <BBB> brb [20:25:26] <j0sh> BBB, gotta go to class. lmk if there are problems with the patches [20:27:43] <BBB> ok [20:59:08] <CIA-1> ffmpeg: reimar * r22721 /trunk/libavcodec/dv.c: Fix indentation. [21:02:39] <CIA-1> ffmpeg: reimar * r22722 /trunk/doc/tablegen.txt: Add some documentation about the table generation code. [21:17:54] <lu_zero> wbs: the lscube bugzilla is rejecting your attachments? [21:18:28] <wbs> lu_zero: hmmmm, either that, or I'm missing something :-) [21:19:09] <wbs> ah, I have to add descriptions to the attachments, otherwise it will drop them silently ; [21:19:12] <wbs> ;P [21:19:27] <wbs> if attaching them separately later, it actually says so [21:19:36] <lu_zero> uhm... [21:19:40] <lu_zero> annoying =_= [21:20:41] <lu_zero> let me look at the patches before I'm going to sleep... [21:21:19] * jai tried that yesterday, didn't work out so well :) [21:21:45] <wbs> lu_zero: there you go, now the attachments should be there [21:21:50] <lu_zero> found them [21:22:11] <wbs> #3 and #6 should be straightforward, #5 is an ugly proof of concept that I don't suggest you apply as is [21:22:18] <wbs> and #7 is a slightly bigger one [21:28:41] * Rathann hunts for peloverde or superdump [21:33:22] <pasteeater> Dark_Shikari: should I make the psy tuning just like a preset? libx264-tune_animation.ffpreset? [21:33:29] <CIA-1> ffmpeg: reimar * r22723 /trunk/libavcodec/ (4 files): [21:33:30] <CIA-1> ffmpeg: Include appropriate header in table generators instead of using a dummy [21:33:30] <CIA-1> ffmpeg: av_cold define. [21:33:37] * BBB decides he really hates qcelp [21:34:33] <Rathann> [Frostii]_Summer_Wars_[720p][9B12BBFA]-ffplay-desync-clip.mkv in mphq/incoming can someone confirm the desync? [21:34:37] <BBB> did anyone ever get that reference code to run/work? [21:37:48] <mru> Rathann: there's nothing to reference sync to in that clip [21:38:25] * lu_zero is still reading [21:38:32] <Rathann> mru: meaning? [21:38:46] <Rathann> mplayer plays it fine... [21:38:52] <mru> as does ffplay [21:39:06] <mru> there's nothing in the video I can tie to any particular sounds [21:39:21] <mru> it could be a second off and I wouldn't notice [21:39:56] <Rathann> there's speech and subtitles [21:40:14] <Rathann> though I guess ffplay doesn't render them [21:40:29] <mru> and how would you tell if subtitles are out of sync? [21:40:56] <mru> a few hundred ms this way or that is impossible to tell whether it's an error or intentional [21:41:17] <Rathann> well, the problem is that in ffplay the audio plays as if in slow motion [21:41:49] <Rathann> and speech is distorted beyond recognition because of that [21:42:22] <mru> not here [21:42:33] <mru> I don't speak japanese [21:42:45] <mru> but if I did, I'd have no trouble listening to that [21:43:00] <mru> and the rate sounds correct for a woman's voice [21:43:17] <Rathann> hmm so maybe it's not distorted for you, strange [21:43:30] <mru> sbr? [21:43:38] <Rathann> dunno, checking [21:44:20] <Kovensky> o, a Rathann [21:45:44] <Rathann> how can I tell if it's sbr? [21:48:24] <Rathann> if I extract it with mkvextract it says ADTS [21:48:56] <Rathann> $ file audio.aac [21:48:57] <Rathann> audio.aac: MPEG ADTS, AAC, v4 LC, 48 kHz, surround + LFE [21:49:10] <mru> sbr is insidious like that [21:49:30] <mru> it lurks unseen until it suddenly jumps out and doubles the sampling rate [21:49:50] <mru> but if the adts header says 48kHz it's probably not using sbr [21:49:56] <Dark_Shikari> pasteeater: just call it "animation" [21:51:12] <Rathann> mru: mkvinfo says the video stream is almost twice as long as audio stream, maybe ffplay trips over that? but still if it doesn't for you then I'm a bit confused [21:52:09] <Rathann> ffmpeg says: Seems stream 0 codec frame rate differs from container frame rate: 47.95 (48000/1001) -> 23.98 (24000/1001) [21:52:19] <pasteeater> Dark_Shikari: not sure how to implement: --ref {Double if >1 else 1} [21:52:50] <Dark_Shikari> oh. that's a problem [21:52:53] <Dark_Shikari> you can't implement that [21:53:06] <Dark_Shikari> not without multiplying presets * tunes [21:53:21] <pasteeater> same goes for --bframes {+2} [21:53:40] <pasteeater> everything else looks fine [21:53:48] <Dark_Shikari> yeah [21:54:05] <pasteeater> maybe animation will have to wait for now [21:55:42] <pasteeater> you mean to just name the tune as "animation"? no .ffpreset or anything? duh... [21:58:18] <Dark_Shikari> well no [21:58:22] <Dark_Shikari> I mean libx264-animation.ffpreset [21:58:26] <Dark_Shikari> not tune_animation [22:04:28] <pasteeater> hmm...i think new users might confuse that with a preset if it isn't labeled differently somehow. [22:05:11] <Dark_Shikari> dunno then [22:06:17] <pasteeater> But if there can be no arrangement, then we are at an impasse. [22:06:22] <pasteeater> I'm afraid so -- I can't compete with you physically. And you're no match for my brains. [22:06:45] * Dark_Shikari detects princess bride [22:08:26] <lu_zero> wbs: how did you produce those patches? [22:08:40] <lu_zero> git-am is complaining about lacking a field [22:10:06] <mru> git-am needs more than a plain diff [22:10:11] <mru> try git apply [22:10:40] <Kovensky> git am eats git format-patch output IIRC [22:14:45] <lu_zero> mru: it isn't a plain diff [22:15:17] <lu_zero> http://bugs.lscube.org/attachment.cgi?id=1 [22:15:41] * lu_zero wanted to spare time and avoid rewriting =_= [22:16:31] <mru> that looks like "git show" output [22:16:34] <mru> not git format-patch [22:17:05] <janneg> git am is short for git apply mailbox [22:17:11] <mru> git git apply also fail? [22:17:18] <mru> *does [22:17:49] <CIA-1> ffmpeg: stefano * r22724 /trunk/ (9 files in 3 dirs): [22:17:50] <CIA-1> ffmpeg: Implement YOP demuxer and video decoder. [22:17:50] <CIA-1> ffmpeg: Patch by Mohamed Naufal gmailify(naufal11). [22:18:50] <lu_zero> git am would parse it correctly splitting the msg and such [22:19:10] <lu_zero> but it complains about them lacking a Email: line [22:19:12] <mru> yes, but it's missing some fields for that [22:19:31] * lu_zero is tempted to hack git am and live happy =_= [22:24:34] <DonDiego> http://git.videolan.org/?p=vlc.git;a=commit;h=c26c8d737f83c80493541627abf6c… [22:24:53] <DonDiego> " [22:24:55] <DonDiego> Workarounded SSA payload modifications done by mkv avformat demuxer." [22:30:07] <CIA-1> ffmpeg: stefano * r22725 /trunk/libavformat/avio.h: Document url_exist(). [22:40:07] <Dark_Shikari> is there a standardized linux way of getting the page size? [22:41:07] <Rathann> sysconf(SOMETHING), maybe? [22:41:27] <Rathann> yup [22:41:37] <Rathann> sysconf(_SC_PAGESIZE) [22:41:49] <Rathann> and I think it's even POSIX [22:41:54] <Dark_Shikari> yeah [22:49:04] <Dark_Shikari> sleep() makes the calling process sleep until seconds seconds have [22:49:08] <Dark_Shikari> elapsed or a signal arrives which is not ignored. [22:49:10] <Dark_Shikari> Does this mean "calling process" or "calling thread"? [22:52:47] <astrange> thread [22:53:38] <mru> why do you need to know the page size? [22:54:11] <Dark_Shikari> nvm, turned out I didn't [22:54:18] <mru> yeah, you rarely do [22:54:18] <Dark_Shikari> madvise takes a length, not a number of pages or whatever [22:57:17] <Dark_Shikari> random question: suppose I am spawning threads which I know will exit on their own [22:57:21] <Dark_Shikari> can I overwrite their handle while they're still running? [22:57:26] <Dark_Shikari> i.e. the handle only used for my own access of the thread? [22:57:31] <Dark_Shikari> or does it contain other important data I shouldn't mess with [22:57:40] <Dark_Shikari> *is the handle [23:01:09] <mru> are these "detached" threads? [23:01:50] <mru> all threads must be either explicitly pthread_join()'d or detached [23:01:54] <mru> otherwise you leak memory [23:02:04] <mru> and if you detach them, how do you know when they're done? [23:02:14] <Dark_Shikari> when they return [23:02:21] <mru> return? [23:02:24] <mru> threads don't return [23:02:28] <Dark_Shikari> pthread_create spawns a single function [23:02:33] <Dark_Shikari> the function does something, then hits a return statement [23:02:33] <mru> yes [23:02:34] <Dark_Shikari> what happens then? [23:02:40] <mru> then the thread dies [23:02:47] <Dark_Shikari> then we're fine then, right? [23:02:54] <mru> and if it wasn't detached you can call pthread_join and fetch the return value [23:03:00] <Dark_Shikari> But what if I don't? [23:03:11] <mru> if you don't call pthread_join you leak memory [23:03:29] <mru> or detach [23:03:56] <mru> so back to the question, if you don't pthread_join, how do you know when the thread has finished? [23:04:09] <Dark_Shikari> I don't care when it finished [23:04:18] <Dark_Shikari> all I care is that I spawned threads and they did things [23:04:24] <mru> what's to stop you creating more threads than the system can handle? [23:04:32] <Dark_Shikari> zombies don't get cleaned up automatically? [23:04:40] <mru> of course not [23:04:50] <mru> you couldn't fetch the return value if they did [23:04:56] <mru> but you can detach them [23:04:58] <Dark_Shikari> You can fetch the return value of processes with waitpid [23:05:00] <mru> then they'll auto-clean [23:05:02] <Dark_Shikari> And they get cleaned up automatically [23:05:13] <mru> yes, processes are zombies until you wait() for them [23:05:24] <Dark_Shikari> But the OS will clean them up automatically [23:05:26] <Dark_Shikari> Just a while later. [23:05:34] <mru> pthread_join() is to threads what waitpid() is to processes [23:05:44] <Dark_Shikari> So in other words, you don't have to join them. [23:05:45] <mru> the OS never cleans up zombies [23:05:47] <Dark_Shikari> Yes it does [23:05:59] <Dark_Shikari> even the bloody toy OS we're working with in OSs class does [23:06:05] <mru> when a process dies, any zombie children are reparented to init, which will reap them after a while [23:06:20] <mru> the kernel doesn't do anything [23:06:46] <Dark_Shikari> I'm pretty sure if the kernel runs into resource issues it will reap zombies. [23:06:51] <mru> nope [23:06:54] <mru> it's not allowed ot [23:06:54] <mru> to [23:07:05] <mru> it can't know you're not about to call wait() [23:07:43] <mru> it has to hold on to the exit status until something asks for it [23:07:45] <Dark_Shikari> waitpid isn't required to keep the return values around forever [23:07:52] <mru> yes it is [23:07:58] <Dark_Shikari> not beyond when the pid is reused [23:08:00] <mru> the OS has to keep it around until wait() is called [23:08:17] <mru> the pid isn't reused until the zombie is reaped [23:08:28] <mru> try running ps [23:08:36] <mru> after creating some zombies [23:08:46] <mru> zombies have a pid just like any other process [23:09:08] <Dark_Shikari> so how does one detach a thread then? [23:09:12] <mru> pthread_detach() [23:09:23] <mru> but using that is usually sign that you're doing something wrong [23:09:26] <Dark_Shikari> can I call it right after a pthread_create? [23:09:38] <mru> after you check the return value yes [23:09:45] <mru> you can also do it from the new thread [23:09:50] <mru> pthread_detach(pthread_self()) [23:10:01] <Dark_Shikari> oh, you can call it on yourself? hah [23:10:33] <mru> of course a detached thread can't be joined [23:17:26] <mru> http://www.betanews.com/article/MPEG-LA-wins-major-MPEG2-settlement-from-Al… [23:17:36] <Dark_Shikari> already? [23:17:55] <mru> looks like mpeg-la are the good guys this time [23:18:11] <Dark_Shikari> ? [23:19:14] <mru> A-L were suing left, right, and centre over patents that mpeg-la, apparently, are now forcing into the mpeg2 pool [23:19:59] <mru> although both sides seem to be claiming they're close to winning there [23:20:08] <mru> as usual in such lawsuits [23:20:51] <Dark_Shikari> ah [23:21:35] <mru> if the patents are forced into the pool, they can't charge extra for them [23:22:08] <mru> now substitute theora for mpeg2 [23:22:13] <mru> who's gonna help you now? [23:22:24] <kierank> doesn't that mean the mpeg-2 licensing price will increase? otherwise existing holders would get less [23:22:35] <mru> maybe [23:22:51] <mru> but almost certainly much less than what AL were suing for [23:26:02] <nfl> saste: the changelog hasn't been updated for YOP [23:27:39] <saste> nfl: true I forgot that [23:28:05] <saste> nfl: give me some time and i'll do [23:30:10] <nfl> saste: sure ;) [23:34:58] <CIA-1> ffmpeg: stefano * r22726 /trunk/Changelog: Add missing entry for the YOP demuxer and video decoder addition.

1 0

IRC log for 2010-03-28
by irc＠mansr.com 29 Mar '10

29 Mar '10

[01:15:56] <CIA-24> ffmpeg: aurel * r22705 /trunk/libavformat/oggparseskeleton.c: correct first pts for ogg skeleton [03:51:47] <Emess> anyone able to tell me what order libavcodec does 5.1 and 6.1 flac in? [05:09:30] <Dark_Shikari> pentanol: so, want to write our own qsort? ;) [05:10:18] <pengvado> problem is, it's not just writing our own. it has to have a hardcoded comparison function. [05:10:48] <pengvado> I suppose the entire qsort could be a macro... [05:12:39] <Dark_Shikari> sure, that'd work [05:12:41] <Dark_Shikari> or make it a template [05:13:37] <pentanol> Dark_Shikari hi our and own are wrong unites ;) [05:14:27] <Dark_Shikari> ? [05:16:02] <pentanol> you first asks me about qsort [05:16:17] <Dark_Shikari> lol [05:16:23] <Dark_Shikari> autocomplete, lol [05:16:26] <Dark_Shikari> pengvado: ;) [05:16:51] <Dark_Shikari> but yeah, pengvado, I would think qsort should naturally be a macro [05:16:56] <Dark_Shikari> the fact that it isn't is an artifact of C [05:18:50] <astrange> qsort is typically recursive too [05:19:29] <pengvado> glibc's isn't recursive. or rather, they implemented their own stack, rather than using C function calls. [05:19:40] <Dark_Shikari> lol [05:20:34] <pengvado> I would think qsort should naturally take a closure. the fact that it's a function pointer instead is an artifact of C. [05:21:02] <Dark_Shikari> exactly [05:28:57] <pengvado> oh wow, just excluding short vlc codes from the sort helps a bunch [05:30:28] <Dark_Shikari> why would that help that much? [05:30:33] <Dark_Shikari> short ones should make up only a small portion [05:31:05] <pengvado> when you have 1300 codes, and "short" is <=11 bits, it doesn't have to be a small fraction [05:32:58] <Dark_Shikari> how can you get away with not sorting them then [05:33:49] <pengvado> @param codes [05:33:49] <pengvado> descriptions of the vlc codes [05:33:49] <pengvado> These must be ordered such that codes going into the same subtable are contiguous. [05:33:53] <pengvado> Sorting by VLCcode.code is sufficient, though not necessary. [05:34:16] <Dark_Shikari> ahhhh [06:42:19] <Dark_Shikari> mru: ok, it isn't flv [06:42:24] <Dark_Shikari> both mp4 and flv desync due to the bitstream errors [06:42:25] <Dark_Shikari> this is bad. [06:48:00] <Dark_Shikari> -vsync 1 fixes it. [07:18:57] <mru> Dark_Shikari: well, blame michael [07:19:19] <Dark_Shikari> the vsync options seem to be impenetrable [07:19:20] <Dark_Shikari> even code-wise [07:19:30] <kshishkov> is no sync done when none is requested a bad thing? [07:19:40] <mru> I've always been against that tampering with timestamps [07:19:48] <Dark_Shikari> kshishkov: by default it should sync [07:19:52] <mru> kshishkov: ffmpeg by default does insane things [07:19:55] <Dark_Shikari> vsync just adjusts the method used [07:20:05] <Dark_Shikari> the thing is: the input file is _CBR_ [07:20:10] <Dark_Shikari> it's bloody EASY [07:20:12] <mru> -vsync is entirely undocumented [07:20:19] <kshishkov> -async then? [07:20:27] <mru> also undocumented [07:20:28] <Dark_Shikari> async didn't fix it [07:20:41] <mru> and the defaults are horribly broken [07:21:00] <mru> usually you get crazy frame duplication or dropping [07:21:03] <kshishkov> next thing is someone may dislike default settings for encoders used in FFmpeg. Oh wait, x264 have done that [07:21:24] <Dark_Shikari> mru: well, Kovensky is writing audio + sync support for x264 for gsoc [07:21:32] <mru> nice [07:21:36] <mru> replace the shit [07:21:36] <Dark_Shikari> so maybe we can do it better. [07:21:44] <elenril> Kovensky is in gsoc? [07:21:48] <mru> teach michael a lesson [07:21:48] <Dark_Shikari> he's applying [07:21:55] <kshishkov> wanna borrow synchronization from default Theora player? [07:22:09] <Dark_Shikari> he's currently wrangling with the hilarity of variable audio frame size [07:22:12] <Dark_Shikari> i.e. input and output not matching [07:22:18] <Dark_Shikari> one of those fun issues that never comes up in video [07:23:31] <mru> it's not a problem in audio either with a good design [07:23:39] <Dark_Shikari> of course not [07:23:48] <Dark_Shikari> But it's still something the design has to deal with [07:24:04] <mru> of course [07:24:14] <mru> but it's fairly trivial [07:24:39] <kshishkov> video frames have variable duration though defined by external means [07:29:40] <pentanol> anyone? which demuxer will be enough for receaving rtsp h264 acc ? [08:49:34] <CIA-24> ffmpeg: mstorsjo * r22706 /trunk/libavformat/rtpenc.c: Initialize ssrc and base_timestamp using ff_random_get_seed() [08:51:36] <astrange> i've got an h264/mp4 file using PAFF with slices for two fields in each packet [08:51:47] <astrange> can you do that? ffmpeg writes one packet per field instead of one per frame [08:52:18] <Dark_Shikari> I didn't know you could do the latter [08:53:31] <astrange> it's also bottom field first which is the first time i've seen that [08:54:09] <mru> bottom field first is _very_ common in dvb/mpeg2 [08:54:32] <Dark_Shikari> he meant ordering of packets [08:54:34] <Dark_Shikari> I think [08:54:38] <astrange> yeah, but i hadn't seen it in h264 [08:54:46] <Dark_Shikari> that's because bff is basically SD-only [08:54:51] <Dark_Shikari> and h264 is mostly hd for DVB [08:55:16] <astrange> i can't find the copy of 14496-15 i had, but i'm pretty sure it didn't mention fields at all [08:56:06] <astrange> anyway, it's a pain because i can't support it in -mt without something like packed b-frame support [08:56:22] <mru> if it's proper non-interlaced HD there's of course no bff [08:56:32] <mru> I haven't looked at 1080i crap [10:00:57] <CIA-24> ffmpeg: vitor * r22707 /trunk/libavformat/ (nut.c nut.h nutenc.c nutdec.c): (log message trimmed) [10:00:57] <CIA-24> ffmpeg: Fix NUT (de)muxer warnings: [10:00:57] <CIA-24> ffmpeg: CC libavformat/nutdec.o [10:00:57] <CIA-24> ffmpeg: libavformat/nutdec.c: In function ?read_seek?: [10:00:57] <CIA-24> ffmpeg: libavformat/nutdec.c:862: warning: passing argument 3 of ?av_tree_find? from incompatible pointer type [10:00:57] <CIA-24> ffmpeg: ./libavutil/tree.h:44: note: expected ?int (*)(void *, const void *)? but argument is of type ?int (*)(struct Syncpoint *, struct Syncpoint *)? [10:00:58] <CIA-24> ffmpeg: libavformat/nutdec.c:871: warning: passing argument 3 of ?av_tree_find? from incompatible pointer type [10:05:03] <CIA-24> ffmpeg: stefano * r22708 /trunk/ (doc/ffprobe-doc.texi ffprobe.c): [10:05:03] <CIA-24> ffmpeg: Implement -convert_tags option, which converts showed tag names to the [10:05:03] <CIA-24> ffmpeg: FFmpeg generic tag names. [10:32:10] <CIA-24> ffmpeg: stefano * r22709 /trunk/libavformat/avio.h: Document url_seek(). [10:42:32] <saste> kshiskov: if you're ok with the librtmp patch i'll commit it [10:44:01] <kshishkov> ok, just don't forget to bump lavf version and update documentation ;) [10:45:03] <saste> good :) [10:45:35] <kshishkov> unlike RTMP itself :P [10:46:04] <saste> ehe... [10:48:57] <kshishkov> at least all gross stuff is now swept under librtmp [12:49:37] <enkidu> hi there. What about adding template support for FFServer status page? It might be nice addition. [12:49:56] <kshishkov> patchiswelcome [12:50:41] <enkidu> Ill try making it, but need some skill-up in C coding, and FFServer sources are not so Qt ;) [12:51:19] <kshishkov> you're lucky I can't hit you with a stick [12:51:25] <jai> heh [12:51:31] <jai> we are glad it isn't like Qt [12:52:16] <kshishkov> not to mention that C is sipler than C++ [12:52:26] <jai> mandatory bash.org reference : http://www.bash.org/?4281 [12:53:43] <Kovensky> <@mru> but it's fairly trivial <-- well, I am writing all the samples, but the audio still sounds broken and plays too fast ._. [12:53:51] <Kovensky> I guess I need to interpolate the pts [12:54:04] <kshishkov> what pts? [12:54:08] <Kovensky> audio pts [12:54:09] <enkidu> :} anyways, Ill try writing that support [12:54:27] <kshishkov> Kovensky: num of samples divided by sampling rate [12:54:40] <kshishkov> there are no audio codecs with B-frames [12:55:11] <kshishkov> and if it plays too fast you either screwed sampling rate or dropping parts of audio packets [12:55:43] <kshishkov> enkidu: it's not that hard - and you can find those pieces where HTML is written anyway [12:56:53] <Kovensky> <@kshishkov> and if it plays too fast you either screwed sampling rate or dropping parts of audio packets <-- it sounds like dropped samples [12:57:09] <twnqx> KotH? [12:57:18] <kshishkov> yes, that's called "very poor man resampler" [12:57:46] <enkidu> kshishkov: I have found them already :) things I have to do: 1) reading template file; 2) replacing tags with strings; 3) return stream to sockeh [12:57:48] <Kovensky> http://pastebin.org/126594 <-- current code (input.decode_audio is a avcodec_decode_audio wrapper (reads packets from an AVPacketList), input.encode_audio is an avcodec_encode_audio wrapper) [12:59:18] <kshishkov> it will fail when encoding pcm16->pcm24 for sure [12:59:36] <Kovensky> well, for now I'm just doing 44100 s16le to mp3 and aac [12:59:41] <Kovensky> it works with mp3, fails with aac [13:00:16] <Kovensky> the decode_audio call gives me 4608 samples, the mp3 encoder consumes 4608 samples, but the aac encoder only consumes 4096 [13:00:40] <kshishkov> and? [13:01:09] <Kovensky> and I don't know what to do in that case :P [13:01:23] <kshishkov> you do memmove() and that's correct [13:01:25] <Kovensky> I tried making a circular buffer as you can see [13:01:50] <Kovensky> so at least in aud_samples all samples are preserved [13:02:29] <kshishkov> you also need to check for needed input size and refill buffer in that case too [13:02:53] <jai> essentially, you need to replicate most of ffmpeg.c ;) [13:03:31] <Kovensky> <@kshishkov> you also need to check for needed input size <-- haud->framesize (the wrapper sets it to ctx->frame_size * ctx->channels * the sample size) [13:04:50] <Kovensky> and what would be "refill buffer" [13:06:17] <kshishkov> why "pos = inlen;" is unconditional? [13:08:22] <kshishkov> also I'd suggest you to add some printf()s to trace what it really does with both input and output [13:08:31] <Kovensky> to make decode_audio always write past the last preserved byte [13:27:29] <enkidu> after some investigation I decided to make CSS styling by now, template may wait few days, Ill commit patch when I check code [13:40:27] <CIA-24> ffmpeg: stefano * r22710 /trunk/ (6 files in 2 dirs): [13:40:27] <CIA-24> ffmpeg: Implement support to RTMP, RTMPT, RTMPE, RTMPTE, RTMPS protocols via [13:40:27] <CIA-24> ffmpeg: librtmp. [13:40:27] <CIA-24> ffmpeg: Patch by Howard Chu <hyc * highlandsun * com>. [13:45:12] <enkidu> strange... code compiled without errors [13:45:37] <kshishkov> it's not Qt after all [13:46:15] * enkidu <3 fairy tales ;) [13:46:43] * kshishkov prefers fractured fairy tales [13:47:35] * Kovensky <3 fairy tail's OST [13:49:14] <enkidu> time to check it :} [13:53:55] <enkidu> where can I send patch for css-styling? [13:54:21] <Kovensky> ffmpeg-devel mailing list [13:54:29] <Kovensky> though I prefer IRC patch reviewing :> [13:54:43] <enkidu> ok, so pastebin first :) [14:03:43] <enkidu> http://pastebin.org/126617 [14:03:59] * enkidu notes to self: never use pastebinit [14:11:55] <Kovensky> enkidu: pastebin it as diff, not as C [14:12:06] <enkidu> Kovensky: sorry :x [14:12:54] <Kovensky> http://pastebin.org/126621 <-- fixed version :> [14:13:33] <enkidu> Kovensky: ok :) [14:13:44] <Kovensky> shouldn't you use stylesheet instead of template_file? [14:13:56] <Kovensky> it is a stylesheet after all, not a template =p [14:14:42] <enkidu> its just keyword name, but for sure - I should change it :) [14:14:57] <Kovensky> the TemplateFile command too [14:15:04] <Kovensky> hey, variable naming is important :P [14:15:12] <enkidu> I know it ;) [14:15:26] <Kovensky> as master pengvado said, it's actually better to be vague than wrong :P [14:16:33] <enkidu> ok, ill upload changed patch [14:17:30] <enkidu> http://pastebin.org/126623 check it [14:19:31] <enkidu> what about V4L device unmute on startup? [14:22:44] <enkidu> frequency setting could be nice too [14:27:56] <Kovensky> <@kshishkov> there are no audio codecs with B-frames <-- re: this, btw; I'm ATM muxing to flv and it requires a dts on every packet, and at least some players respect audio dts [14:28:24] <Kovensky> I'll try to use the dts of the first audio packet as the initial dts, and then just increment it as I encode ._. [16:03:17] <j0sh> lu_zero, vorbis stream copy from feng rtp is identical to the old code... if it's broken, it always was [16:04:02] <j0sh> i should note that "-vcodec copy" for theora makes ffmpeg hang, it has to re-encode through libtheora, will file a bug [16:07:05] <DonDiego> j0sh: assign it to david conrad [16:07:53] <j0sh> DonDiego, ok [16:23:15] <ramiro> astrange: so it's safe to compile for 32-bit mac os x with --extra-cflags=-mdynamic-no-pic? [17:02:03] <enkidu> nice lag [17:18:40] <CIA-1> ffmpeg: jai_menon * r22711 /trunk/libavcodec/tta.c: TTA : Check if the output buffer size is within bounds. [17:21:50] <CIA-1> ffmpeg: jai_menon * r22712 /trunk/MAINTAINERS: Add myself as co-maintainer of tta.c [17:39:42] <Dark_Shikari> http://akuvian.org/src/x264/ffv2.94.diff cool beans [18:01:57] <j0sh> can someone see if they can play a normal ogg vorbis file through ffplay? [18:02:11] <j0sh> mine keeps complaining about not being able to find codecs; i want to be sure im not crazy before i file a bug [18:02:29] <ramiro> mru: is there a way to tell make test to create all files on the target filesystem? (not through nfs) [18:02:57] <saintdev_> Dark_Shikari: Johnny Chimpo? [18:03:14] <j0sh> the samples on mplayerhq don't seem to be working... [18:04:18] <mru> ramiro: that won't work [18:04:35] <mru> because then the host can't check them [18:06:36] <ramiro> then can the mount be the other way around? the host mounts some dir from target [18:06:51] <ramiro> because target_path is being used both for output files and the ffmpeg executable [18:07:06] <mru> why is this a problem for you? [18:07:31] <ramiro> nfs too slow and some files aren't being created properly [18:07:35] <jai> j0sh: any specific sample you had in mind? [18:08:02] <j0sh> jai, ive tried lumme.ogg and the o1_duran_duran sample [18:08:03] <jai> you might find this weird, but i really dont have any ogg files around :| [18:08:03] <ramiro> such as: encode to file X, decode (file X not there yet). [18:08:43] <j0sh> jai, it also doesnt seem to be playing audio that i've extracted from, eg, theora samples [18:09:01] <j0sh> jai, basically nothing works for vorbis [18:09:06] <jai> j0sh: could you link to the sample you are having troubles with? [18:09:58] <ramiro> mru: but I think make fate is good enough for me, and it's working fast&fine. I remember you mentioned some way to run only some tests (for example h264-*), how does that work? [18:10:25] <j0sh> jai, try this: (http://samples.mplayerhq.hu/A-codecs/vorbis/floor_type_0/01_Duran_Duran_Pla…) [18:10:35] <mru> you can run individual fate tests with make fate-$testname [18:12:31] <jai> j0sh: works fine here [18:12:54] <j0sh> jai, just using ffplay? no other options? [18:13:25] <jai> j0sh: ffplay vanilla trunk build [18:13:42] <j0sh> hmmm thats weird, thanks [18:13:58] <jai> j0sh: did you try with a clean build with a fresh checkout? [18:15:57] <j0sh> jai, i have a few patches but they should be unrelated... let me try it clean [19:12:21] <j0sh> jai, i think the problem is my sound system is completely broken. wonder how long it's been going on... thanks anyway [20:11:13] <astrange> ramiro: --enable-shared might not compile, otherwise it's safe [20:16:59] <CIA-1> ffmpeg: diego * r22713 /trunk/doc/general.texi: [20:16:59] <CIA-1> ffmpeg: Clarify (Open)Solaris section of the documentation. [20:16:59] <CIA-1> ffmpeg: patch by Michael Kostylev, michael.kostylev gmail com [22:14:31] <KingofCamelot> Anyone know how to contact Alex Converse in regards to a GSoC project? [22:15:22] <kierank> he goes by the nick peloverde [22:15:32] <astrange> email ffmpeg-soc if you haven't already [22:17:03] <KingofCamelot> Ok. Thanks guys. [23:11:02] <astrange> output_example has lines from 2003 that "will be removed ASAP" [23:12:05] <Dark_Shikari> lol [23:16:27] <DonDiego> nothing lasts as long as a temporary solution, *sigh* [23:16:58] <DonDiego> astrange: btw, you mentioned speeding up mpeg2.. - anything new? [23:50:43] <astrange> i need to get better ideas first [23:51:46] <Dark_Shikari> debug mode/verbose [23:51:47] <Dark_Shikari> er [23:51:49] <Dark_Shikari> wrong channel. [23:51:59] <Dark_Shikari> what I meant to say: write it in fortran ;) [23:53:16] <astrange> http://pastebin.com/CrYend33 [23:53:25] <astrange> idct=14 is xvid sse2

1 0

IRC log for 2010-03-27
by irc＠mansr.com 28 Mar '10

28 Mar '10

[01:30:47] <astrange> mru: i used cortex-a8 [01:30:59] <astrange> gcc 4.5 can generate rev but not rev16... bug filed in a sec [01:46:28] <mru> can it also do unaligned loads properly? [02:28:48] <ramiro> mru: what odcctools must be used to compile ffmpeg for the iPhone? [02:53:21] <mru> ramiro: what what must be used? [02:57:36] <spyfeng> Hi~ if a code line exceed 80 characters in FFmpeg, how to spllit it into two more lines? [02:57:53] <spyfeng> any rules? [02:58:39] <spyfeng> for example: memcpy(mms->asf_header + mms->asf_header_size, mms->pkt_read_ptr, mms->pkt_buf_len); [02:59:44] <ramiro> mru: isn't odcctools the equivalent of binutils from apple? [03:01:25] <ramiro> or, more simply, what toolchain must be used to compile FFmpeg for the iPhone? [03:02:59] <mru> I've never heard of odcctools before [03:03:12] <mru> use whatever the latest iphone sdk comes with [03:03:33] <mru> it probably won't work, but it's silly to attempt making things work with an old version [03:03:48] <ramiro> hm, I had thought the apple tools were buggy and we were supposed to use some "community" tools [03:04:04] <mru> oh, the apple tools are beyond buggy [03:04:12] <mru> but there are no alternatives [03:04:42] <mru> you have to use yuvi's asm preprocessor though [03:19:52] <astrange> odcctools is just a more portable packaging of the apple cctools [03:19:56] <astrange> but it's not updated that often [03:20:32] <ramiro> what's not updated that often? the cctools or the odcctools? [03:44:26] <Dark_Shikari> astrange: does gcc automatically merge constants in the same file? [03:44:30] <Dark_Shikari> i.e. multiple identical const strings [03:44:42] <Dark_Shikari> e.g. a = "apple"; b = "apple", will it store only one "apple"? [03:45:35] <peloverde> Dark_Shikari, I was under the impression it does [03:46:12] <astrange> it's supposed to [03:46:16] <Dark_Shikari> k [03:48:50] <saintdev> but, we all know gcc... [03:49:17] <drv> from what i've heard (not actually tested), it's even smart enough to merge things like "abcdef" and "def" [03:50:49] <mru> it's allowed to do that [03:51:08] <mru> there is no promise [04:02:20] <Dark_Shikari> oh god. [04:02:21] <Dark_Shikari> oh god. [04:02:21] <Dark_Shikari> oh god. [04:02:28] <Dark_Shikari> saintdev: thanks for making me lol hard [04:02:31] <Dark_Shikari> peloverde: http://saintdevelopment.com/fies/tests.zip [04:02:45] <Dark_Shikari> One is FAAC at 160kbps, one is FFAAC at 160kbps, one is source. [04:02:47] <saintdev> Dark_Shikari: you didn't see that the other day? [04:02:51] <Dark_Shikari> nope [04:03:03] <Dark_Shikari> I didn't think it was possible for an encoder to be this bad [04:03:20] <Dark_Shikari> Oh hey, I'll go try celt on these. [04:03:29] <saintdev> I told you about it in #handbrake, thought you would find it humorous. [04:03:40] <Dark_Shikari> oh yeah, I never looked at it. now you can see I did =p [04:03:46] <astrange> /fies/? [04:03:50] <saintdev> peloverde: correct URL is http://saintdevelopment.com/files/tests.zip [04:04:00] <Dark_Shikari> er, how did that happen [04:04:10] <Dark_Shikari> /fies/ works here [04:04:15] <saintdev> astrange: should be /files/ [04:04:29] <saintdev> 1and1 name adjustment ftw [04:04:53] <saintdev> if you type in a name that's a letter off it'll still work [04:04:55] <Dark_Shikari> btw, the "good" 160kbps is definitely transparent on that sample. [04:05:44] <saintdev> what's funny, is quite a few people have picked the "good" sample as the original :P [04:05:51] <saintdev> ...and that's with faac [04:06:03] <Dark_Shikari> at 160kbps I would expect transparency [04:06:19] <saintdev> fixed url in the post [04:06:22] <peloverde> There is a lowpass that's applied in a stupid manner [04:08:04] <Dark_Shikari> it lowpasses that much at 160kbps? [04:08:10] <Dark_Shikari> would be nice to fix that... [04:08:18] <peloverde> Also perhaps you remember the e-mail where I questioned working on this codebase at all and going and replacing the bad code in faac instead [04:08:27] <Dark_Shikari> "bad code"? [04:08:36] <saintdev> might actually be usable without that lowpass, if that's the case. [04:08:37] <peloverde> Not (L)GPL compatible [04:08:41] <Dark_Shikari> getting rid of the badly licensed code in faac doesn't make it not shit [04:08:54] <mru> rotfl, that is AWFUL [04:08:57] <peloverde> It makes it a better jumping off point [04:09:15] <Dark_Shikari> mru: the part around 1.5-2.5 seconds is particularly bad [04:09:25] <Dark_Shikari> er, 0.5-1.5 [04:09:28] <mru> one of the samples is just disgusting [04:09:34] <Dark_Shikari> mru: that's ffaac [04:09:38] <mru> I won't say which in case people want to try [04:09:44] <Dark_Shikari> It's kinda obvious. [04:09:48] <mru> well, yeah [04:09:58] <mru> the other two are hard to tell apart [04:10:02] <mru> I'll have to listen again [04:10:07] <Dark_Shikari> I can't tell them apart after 10 listens [04:10:11] <peloverde> Though I'm curious as to the cause of the big spectral holes at the end [04:10:15] <mru> tomorrow, without waking neighbours [04:10:18] <Dark_Shikari> spectral holes? [04:10:21] <Dark_Shikari> mru: headphones? [04:10:24] <mru> no good ones [04:11:00] <Dark_Shikari> in some sense, the more complex the music, the harder it is to hear artifacts [04:11:03] <Dark_Shikari> just like in video [04:11:07] <Dark_Shikari> complexity hides error [04:11:09] <peloverde> big holes in the spectrum [04:11:14] <Dark_Shikari> peloverde: where in the spectrum? [04:11:21] <Dark_Shikari> (you ran it through a spectrum analyzer?) [04:11:26] <saintdev> all over, it's swiss cheese at this point. [04:11:34] <peloverde> between 20 and 24.5 [04:11:38] <Dark_Shikari> khz? [04:11:41] <Dark_Shikari> or hz [04:11:47] <saintdev> seconds? [04:11:50] <Dark_Shikari> oh [04:11:57] <peloverde> seconds [04:11:58] <Dark_Shikari> oh holy shit [04:12:03] <Dark_Shikari> Wow [04:12:28] <saintdev> once again touhou comes in handy :D [04:12:45] <astrange> you probably can't tell faac at 160 from the original [04:13:19] <astrange> if you can, bad headphones might help because of the unexpected response levels [04:14:52] <peloverde> Also is that using TLS? [04:15:05] <saintdev> TLS? [04:15:15] <peloverde> Two Loop Search? [04:15:33] <peloverde> There are 3 coefficient coders in the aac "encoder" [04:15:48] <saintdev> dunno, whatever the defaults are. [04:16:00] <peloverde> The defaults are insanely bad [04:16:47] <saintdev> so why are the the defaults then? [04:17:06] <saintdev> tell me what I should be using and I'll do another test. [04:18:05] <peloverde> The cascaded trellis is supposed to be the best but I'm not sure of the sate of the code that's actually checked in [04:19:46] <peloverde> how does ffwma do? [04:23:07] <saintdev> gotta rebuild for that. v2? [04:24:14] <peloverde> I think v2 is the only version supported [04:24:28] <saintdev> --list-encoders shows v1 and v2 [04:31:27] <saintdev> it does decent. [04:35:01] <saintdev> ffwmav2 @ 184kbps (160kbps was what I requested) http://saintdevelopment.com/files/test_4.wav [04:35:28] <Dark_Shikari> btw, I teseted other encoders for you [04:35:43] <Dark_Shikari> vorbis sounds amazing down to 64kbps [04:35:46] <Dark_Shikari> and still quite good at 48kbps (with aotuv) [04:35:56] <Dark_Shikari> it completely falls apart at 32. [04:36:15] <Dark_Shikari> nero sounds slightly worse than vorbis at 48, but performs admirably all the way down to 24 [04:36:35] <saintdev> Dark_Shikari: he-aac or just lc? [04:37:28] <Dark_Shikari> whatever it used. probably he-aacv2 [04:38:05] <saintdev> ok, just checking if you forced it to use lc [04:44:12] <peloverde> makes me want to just adapt the WMA encoder to do AAC [04:47:35] <Dark_Shikari> lol [04:47:38] <peloverde> Here is the ABR cutoff equation "cutoff_coeff = avctx->bit_rate / (4.0f * avctx->sample_rate * avctx->channels)" lol [04:47:45] <Dark_Shikari> for wma? [04:48:09] <peloverde> for AAC [04:48:21] <Dark_Shikari> ah [04:50:46] <astrange> the wma encoder is only 400 lines, i'm surprised it sounds good at 128kbit [04:51:09] <astrange> well, requesting 128kbit gets 140kbit [04:51:27] <saintdev> astrange: yeah like my requested 160kbit = 184kbit [04:52:00] <saintdev> peloverde: how does cutoff_coeff relate to the actual cutoff frequency? [04:54:18] <aaronl> holy shit [04:54:18] <peloverde> The actual cutoff frequency should be the sample rate * cutoff_ratio / 2, I think [04:54:21] <aaronl> this is pretty far from transparent [04:54:28] <peloverde> iirfilter.c is not documented at all [04:56:10] <saintdev> so that gives a cutoff of 10kHz? lol [04:56:39] <saintdev> no wonder it sounds like crap [04:59:38] <peloverde> Sadly I'm getting segfaults if I turn the filter off [04:59:59] <Dark_Shikari> >_> [05:00:42] <peloverde> nevermind it's not related to the filter [05:03:27] <peloverde> There IIRC were some issues with the way ff_aac_pow2sf_tab was structured and my first proposed fix was rejected and I never got around to a second attempt [11:31:54] <CIA-24> ffmpeg: diego * r22697 /trunk/LICENSE: Clarify which parts of libswscale remain GPL. [12:36:28] <CIA-24> ffmpeg: stefano * r22698 /trunk/ffprobe.c: [12:36:29] <CIA-24> ffmpeg: 10l: Initialize tag to NULL in show_stream, fix metadata showing in [12:36:29] <CIA-24> ffmpeg: streams. [12:39:52] <pengvado> wow, my optimized init_vlc() managed to break vorbis in such a way that it adds noticeable distortion but doesn't completely desync nor even register any decoding errors. [12:44:54] <kshishkov> something wrong with symbols? [12:46:15] <pengvado> could be [12:46:36] <kshishkov> and I remember that init_vlc() calls in lavc/mpc8.c triggered internal compiler error on some platforms [12:48:15] <CIA-24> libswscale: diego * r30965 /trunk/libswscale/ (5 files): [12:48:15] <CIA-24> libswscale: libswscale: Relicense almost all x86 assembler optimizations as LGPL. [12:48:15] <CIA-24> libswscale: This is of course done with permissions from the authors. The only GPL [12:48:15] <CIA-24> libswscale: component left are MMX optimizations for YUV to RGB conversion. [13:18:44] <CIA-24> ffmpeg: diego * r22699 /trunk/doc/developer.texi: Clarify where the list of supported formats is. [13:20:57] <elenril> name = "avi", name_long = "AVI format" << what's the point of this [13:21:34] <ramiro> elenril: for ffmpeg - formats [13:21:40] <ramiro> oops, ffmpeg -formats [13:22:06] <elenril> i mean name_long contains exactly the same information as name [13:22:21] <ramiro> elenril: not in all cases [13:22:58] <CIA-24> ffmpeg: reimar * r22700 /trunk/libavcodec/avcodec.h: Clearer CODEC_CAP_DR1 documentation. [13:23:06] <elenril> yeah, but in this case (and many other) name_long is redundant [13:23:34] <ramiro> if it bothers you so much, use --enable-small [13:23:39] <ramiro> or whatever the configure flag is [13:24:46] <elenril> no, i just thought it's weird [13:29:29] <kshishkov> elenril: isn't that a bit idiotic translation here? http://cs.wikipedia.org/wiki/Soubor:Skoda_tabl_%D0%A7%D0%A12.jpg [13:31:11] <CIA-24> ffmpeg: diego * r22701 /trunk/doc/APIchanges: misc wording and grammar fixes [13:31:34] <elenril> not really [13:31:40] <elenril> sounds only a little weird to me [13:32:27] <elenril> then agains my russian is a bit rusty [13:34:32] <kshishkov> still, translating "Skoda" as "Mechanical works named after Lenin" is a bit idiotic [13:54:04] <DonDiego> ramiro, Kovensky: what's the yearly income for a beginner software engineer in brazil? (just a ballpark figure) [13:54:21] * Kovensky has no idea [13:54:33] <Kovensky> ramiro would know, probably [13:55:10] <iive> kshishkov: are you sure it doesn't say that the factory name is called lenin? [13:58:12] <kshishkov> iive: look closely at small print word ;) [14:01:24] <kshishkov> DonDiego: some googling suggests it may be <= 24000 USD [14:01:57] <iive> i don't see any small print. and my cz is nonexistent. [14:02:12] <kshishkov> it has only one word in Chezh - logo [14:03:50] <ramiro> DonDiego: yes, certainly below 24000 usd [14:05:17] <ramiro> I'm not sure since the incomes vary a lot and I don't go around asking (and I'm still far from graduating =), but something around 2k reais per month... [14:05:54] <kshishkov> some page said it's ~4600 brazil tokens per month for IBM software dev, googling for exchange rate helped me estimate that threshold [14:06:20] <DonDiego> so something like 20.000 EUR as ballpark? [14:07:02] <ramiro> ah, ibm... they certainly pay a reasonable income. 4600 seems about right. [14:07:28] <DonDiego> what's the exchange rate to euro? [14:07:57] <ramiro> DonDiego: are you thinking big companies or just the regular neighborhood software houses? [14:08:11] <DonDiego> both [14:08:21] <kshishkov> 0.41 EUR per king [14:08:31] <DonDiego> i'm thinking about a very rough average figure [14:09:17] <DonDiego> for example in germany it's roundabout 40k eur per year at entry level, ronald tells me it's 100k$ in usa [14:10:08] <kshishkov> here it's probably all food you can steal [14:10:35] <ramiro> DonDiego: from 10keur for smaller companies and up to some 25keur... [14:11:11] <DonDiego> so roughly 20k eur [14:11:16] <mru> DonDiego: 40k eur for a graduate??? [14:11:26] <mru> since when? [14:11:31] <kshishkov> several years ago I was offered a job at the most notorious sweatshop here for ~4000 USD a year [14:11:46] <ramiro> but people don't bother working as software engineers here. everyone wants to become manager so they can earn at least double. it is the interns that do all the work (hence poor quality software) [14:11:51] <DonDiego> mru: that's the average number i hear, 37k - 42k being the standard i think [14:11:56] <DonDiego> mru: what did you expect? [14:12:18] <kshishkov> ramiro: also you need to train only your tongue as a manager, not brains [14:12:52] <ramiro> kshishkov: indeed =) [14:14:39] <mru> I don't believe those numbers [14:14:57] <mru> I wouldn't expect a cent above 35 [14:16:12] <ramiro> DonDiego: it also depends on the city you live. in sao paulo you can easily get some 30k or more, but you spend most of it on housing, transportation, and eating. [14:16:40] <jai> kshishkov: $4k/yr is common here as well [14:18:01] <DonDiego> i have credible sources, i.e. people i know, but since i'm just looking for ballpark figures, 20% error is ok [14:18:31] <ramiro> DonDiego: just curious, are you planning to move here? =) [14:19:22] <DonDiego> haha :) [14:19:26] <DonDiego> no, not yet.. [14:24:55] <kshishkov> jai: I told you that Ukraine =~ European India, didn't I? [14:25:15] <kshishkov> ramiro: he's from Argentina anyway [14:25:51] <janneg> DonDiego: öffentlicher dienst is around 33k [14:26:27] <ramiro> kshishkov: I know, but argentinians and brazilians hate each other =) [14:26:40] <DonDiego> only in football :) [14:27:16] <kshishkov> ramiro: I've heard that argentinians are viewed like people with superiority complex in the rest of South America [14:27:33] <DonDiego> do we have soc candidates for vc-1 interlaced and dts encoder? [14:27:38] <ramiro> DonDiego: ha, that's because you don't live in a tourist city... during the summer the city is clogged with rich and filthy argentinians and uruguayians... [14:28:21] <ramiro> there's one beach here where people won't understand if you speak portuguese during the summer! the whole commerce is in spanish. [14:28:44] * mru doesn't speak either [14:28:49] <kshishkov> ramiro: here people won't understand official language too [14:29:10] <kshishkov> mru: same here but unlike you I also don't speak Swedish and German [14:29:32] <ramiro> kshishkov: yes, argentinians think of themselves as europeans... [14:29:52] <mru> yeah, look at DonDiego, he even _lives_ in europe [14:30:01] <ramiro> kshishkov: hmm I thought you would have learned swedish by now [14:30:03] <kshishkov> ramiro: here we use term "Moscow denizens" [14:30:09] <DonDiego> there's hardly an argentinian without a european grand{dad,ma} [14:30:32] <kshishkov> of German origin? [14:30:41] <mru> iirc ramiro is some kind of italian... [14:30:57] <kshishkov> ramiro: yes and I can say some words too but it's too far from claiming that I know it [14:31:03] <DonDiego> i'm of spanish/basque origin [14:31:16] <kshishkov> mru: Italian and Spanish are closely related [14:31:39] <kshishkov> that's kinda feuding origin [14:31:56] <mru> kshishkov: yes, I understand them about equally well [14:32:07] <DonDiego> ramiro: you live in florianopolis, right? [14:32:11] <ramiro> DonDiego: yes [14:32:28] <kshishkov> mru: same here, I understand most languages equally anyway [14:32:35] <DonDiego> your city lives off of tourism, so don't complain :) [14:32:46] <mru> I understand spanish and italian much better than most languages [14:32:47] <ramiro> kshishkov: me too. I don't understand them =) [14:32:52] <mru> most languages I don't understand at all [14:33:07] <mru> spanish I can usually pick out a few % [14:33:26] <ramiro> DonDiego: well, it's not "my city". I'm only studying here because the university is good. I'm getting out of here as soon as possible. [14:33:49] <kshishkov> mru: you can always try Lithuanian, Hungarian or Finnish [14:34:33] <jai> ramiro: when do you finish? [14:34:56] <mru> kshishkov: I know maybe 5 words in finnish [14:35:08] <mru> and I can usually recognise hungarian, but not more [14:35:20] <kshishkov> same here [14:35:41] <kshishkov> for Finnish because some words are finished Swedish [14:35:42] <ramiro> jai: good question. I was supposed to graduate last year, but it will probably be in 2012. [14:36:28] <kshishkov> mru: it was funny when Google translate (sv->en) translated two instances of Hamngatan as "Port street" and once as "Satamakatu" [14:36:37] <jai> ramiro: oh :| [14:36:56] <mru> kshishkov: wtf [14:39:45] <kshishkov> mru: translate.google.com, word "Styrmansgatan" [14:40:20] <mru> that's finnish, not english [14:40:23] <mru> wtf is going on [14:41:32] <kshishkov> dunno but it was funny [14:42:22] <kshishkov> maybe dictionary compilator walked at Helsingfors and thought that top name on street plaques are in English... [14:42:34] <mru> hehe [14:46:40] <kshishkov> I remember that once Google Translate when using en -> ru replaced "Peter Norton" with some Russian antivirus maker name [14:46:55] <mru> :-) [14:48:51] <kshishkov> BTW, your nickname is a bit funny after learning PowerPC assembly [14:50:07] <thresh> Kaspersky, probably? [14:50:39] <kshishkov> could be [15:13:23] <kshishkov> BBB: would you believe that I'd been offered to smoke something suspicious by complete stanger. Around noon and on main street. This place is going downhill. [15:13:40] <BBB> what did he offer? [15:13:51] <BBB> if it's a cigarette, I'd worry... [15:13:57] <BBB> if it's anything good, you'd be an idiot not to [15:13:58] <kshishkov> is was [15:14:06] <BBB> just a smoke cigarette? [15:14:10] <BBB> that's it? [15:14:15] <BBB> yeah, place is going downhill [15:14:21] <kshishkov> half-smoked [15:14:21] <DonDiego> haha "just a cigarette" :) [15:14:29] <DonDiego> dutch people .. ;) [15:14:30] * kshishkov does not smoke in any case [15:14:52] <BBB> nothing wrong with a good joint [15:14:55] <kshishkov> blabbering something about "new pleasure" too [15:15:24] * BBB wishes there was an easy way to split patches in quilt [15:15:30] <BBB> my audio clipping patch got so huge [15:15:39] <BBB> I accidently wrote a qcelp postfilter in that patch [15:15:50] * kshishkov usually does that with text editor and diff [15:15:53] <BBB> which was dropdead easy by the way [15:16:10] <BBB> qcelp is almost a litteral copy of amrnb [15:16:16] <BBB> just slightly different values [15:47:52] <wbs> BBB: splitting patches is relatively easy with git ;P [15:57:37] <BBB> git is one of those things I just don't understand yet :) [15:57:42] <BBB> will get there, eventually [15:57:45] * BBB splits patches in 6 or so [15:58:30] <wbs> hope you don't get scared away by the learning curve, once you get it, it's better than sliced bread :-) [16:14:51] <pentanol> hi guys, I testing ffmpeg for reading rtsp stream and got weird behaviour. actually It stop streaming after reaching frame= 1774 on around it 1784 1772... why it can be happening? [16:15:41] <wbs> pentanol: I've seen something similar with some rtsp servers, when running over tcp - not sure why it happens [16:17:54] <ramiro> BBB: "Apply an order 2 rational transfer function in-place." with in and out it's no longer in-place, right? [16:20:18] <BBB> oh I didn't update comments, but yes you're right [16:20:52] <BBB> pentanol, wbs: sounds like server closes connection because we're not sending keepalive requests [16:21:14] <BBB> pentanol, wbs: try sending dummy OPTIONS requests, rtsp.c has some code for that but it's only enabled for Windows/Real servers right now [16:21:20] <BBB> feel free to make that more general [16:51:29] <mru> saintdev, Dark_Shikari, peloverde: I did some careful listening to those files [16:51:46] <mru> it's _really_ hard to hear any difference between two of them [16:56:57] <mru> but that sample is very hard to evaluate [16:57:10] <mru> dozens of voices [16:57:25] <kshishkov> go train at NSA [16:57:37] <kierank> I think there's a very slight difference between the two [16:57:45] <mru> there's a difference for sure [16:57:52] <mru> especially in the quieter voices [16:58:07] <mru> but they're something like 10 dB below the loud ones [16:58:11] <mru> makes it very hard to hear [16:59:02] <mru> certain types of classical music are much harder to encode transparently [16:59:30] <ramiro> and that's why kostya re'd ape =) [16:59:30] <kshishkov> I've heard that Chinese instrumental music is especially hard to code [16:59:48] <kshishkov> ramiro: I have done nothing like that [17:00:07] <ramiro> kshishkov: hmm, I might be mistaken. I remember you talking about some lossless codec to listen to classical music [17:00:50] <kshishkov> APE yes but source was available [17:01:05] <kshishkov> and some Rockbox guy made it easy to use [17:01:14] <kshishkov> and some XBMC guy adapted it for lavc [17:01:19] <ramiro> ah, ok. this is where: http://codecs.multimedia.cx/?p=50 [17:01:23] <kshishkov> I just picked it up and polished a bit [17:02:38] <jai> hmm, i always thought it was because more classical music rips were in ape ;) [17:02:58] <mru> ape is pointless [17:03:10] <mru> it compresses only marginally better than flac or alac [17:03:19] <mru> at 1000x or more cpu load [17:03:24] <mru> and an insane design [17:03:25] <jai> exactly [17:03:34] <kshishkov> but people use it [17:03:38] <ramiro> kshishkov: btw you mentioned a philharmonic here http://codecs.multimedia.cx/?p=71 . do you also play something? [17:03:53] <kshishkov> ramiro: no, I'm a mere listener [17:06:01] <kshishkov> this world is already suffers from too many people thinking they have a talent [17:24:28] <siretart> DonDiego: aloha [17:37:29] <Kovensky> does avcodec_encode_audio always consume the whole input? [17:37:42] <Kovensky> nvm [17:58:11] <Dark_Shikari> hmm, question related to a/v sync [17:58:28] <Dark_Shikari> I have a customer who is streaming using ffmpeg and the a/v sync gets worse over time--and it gets worse every time there's corruption in the input [17:58:34] <Dark_Shikari> (it's satellite feed or whatever and periodically has some loss) [17:58:39] <Dark_Shikari> any idea what would cause this? [18:12:11] <DonDiego> anybody seen yuvi around lately? [18:17:10] <kshishkov> DonDiego: this channel is publicly logged and you know where logs are [18:36:41] <Compn> Dark_Shikari : what filetype? [18:37:09] <Compn> Dark_Shikari : could be that hes playing 29.97 (or vfps) at 30.00 constant framerate :P [18:39:33] <Dark_Shikari> it's an MPEG-2 transport stream [18:39:38] <Dark_Shikari> standard TV stuff [18:44:44] <mru> packet loss causing desync usually indicates someone is ignoring pts [18:44:52] <mru> and merely counting frames [18:47:40] <Dark_Shikari> well, this is ffmpeg. [18:47:59] <mru> no, it's not [18:48:03] <mru> ffmpeg doesn't do display [18:48:04] <kshishkov> go humour Baptiste [18:48:15] <mru> something else has to be involved [18:48:24] <mru> and it's well-known that ffmpeg.c butchers pts [18:48:45] <Dark_Shikari> oh I think I know the issue maybe [18:48:49] <Dark_Shikari> ffmpeg is outputting to FLV [18:48:57] <Dark_Shikari> the ffmpeg FLV muxer is COMPLETELY BROKEN and forces CFR [18:49:05] <mru> does flv have timestamps? [18:49:06] <Dark_Shikari> it does not pass through pts despite being a pure-VFR format [18:49:07] <Dark_Shikari> Yes [18:49:10] <Dark_Shikari> FLV has no fps field [18:49:12] <Dark_Shikari> it only has timestamps [18:49:58] <Dark_Shikari> But last time I encoded a VFR file with ffmpeg, it changed the pts [18:50:00] <Dark_Shikari> But only with flv [18:50:05] <Dark_Shikari> with mp4 it passed them through [18:53:01] <mru> sound like you found the culprit [18:53:14] <mru> as I said, something is screwing with timestamps [18:54:58] <Dark_Shikari> But the writer seems to be writing pts [18:55:08] <Dark_Shikari> *properly [18:55:09] <Dark_Shikari> it even has AVFMT_VARIABLE_FPS [19:10:40] <CIA-24> ffmpeg: reimar * r22702 /trunk/libavformat/eacdata.c: eacdata: fix a memleak, return partial packets and use proper return values. [19:11:16] <CIA-24> ffmpeg: reimar * r22703 /trunk/libavformat/txd.c: Use more appropriate return values in txd demuxer. [21:15:09] <CIA-24> ffmpeg: stefano * r22704 /trunk/libavformat/avformat.h: [21:15:09] <CIA-24> ffmpeg: Document the behavior of av_metadata_get() if the prev parameter is [21:15:09] <CIA-24> ffmpeg: NULL. [21:47:39] <hyc> I guess I should use more context lines when posting svn diffs [21:48:23] <hyc> but also you guys ought to read the actual code in question before questioning the point of a patch [22:10:03] <Compn> hyc : this is just the way of the open source project with many heads... we berate patch authors to make sure they will stil around thru our rings of fire and maintain such code :P [22:10:29] <Compn> well , something about that sentence got broken [22:11:31] <hyc> heh [22:12:07] <hyc> once again, the focus should be on the actual code, not who the submitter is [22:12:20] <hyc> and anyone who looks at the actual code will see that there's an inconsistency [22:13:04] <hyc> and I certainly can't explain why the original code is the way it is [22:13:48] <hyc> I didn't write it. if they want to put someone thru a ring of fire, it should be the original author who wrote such an inconsistency... [23:26:06] <ramiro> mru: I'm confused as to what target-path must be. I mounted an nfs share at target-machine to where ffmpeg is being built on host, and point to there. but then the tests take long and the decoding tests fail. I assume the file is not being entirely sent back before the 2nd test starts and therefore it fails. I thought all the generated files would reside in target, is that not so? [23:51:17] <Kovensky> http://cekirdek.pardus.org.tr/~ismail/ffmpeg-docs/avcodec_8h.html#c41ab8ea9… [23:51:33] <Kovensky> [in] samples the input buffer containing the samples The number of samples read from this buffer is frame_size*channels <-- the wording is a bit confusing [23:51:54] <Kovensky> I keep mixing up what is counted in samples and what is counted in bytes :S

1 0

IRC log for 2010-03-26
by irc＠mansr.com 27 Mar '10

27 Mar '10

[00:38:21] <CIA-24> ffmpeg: diego * r22686 /trunk/doc/general.texi: Add FreeBSD subsection with compilation instructions. [00:39:45] <CIA-24> ffmpeg: diego * r22687 /trunk/doc/general.texi: Reorder platform sections alphabetically. [00:58:20] <mfg> Does anyone want to checkin my patch (proe_buffer11.diff from tuesday)? [01:03:42] <mru> http://thenewsh.blogspot.com/2010/03/three-cats.html [01:05:25] <hyc> sad, very sad... [01:05:32] <mfg> LOL [01:06:21] <hyc> I seem to recall an email thread on the linux-standard-base mailing list about how /bin/true didn't conform to the LSB [01:06:29] <hyc> because it lacked a --version option or something [01:07:41] <mru> if it did, it wouldn't conform to the real standards [01:08:25] <mru> I usually use : though [01:08:28] <mru> less typing [01:08:40] <hyc> yep [01:09:26] <hyc> http://lists.mplayerhq.hu/pipermail/rtmpdump/2010-March/000697.html [01:10:48] <mru> hmm, let's write something where -help, -version, -verbose etc trigger some catastrophic action like deleting everything [01:11:24] <mru> make -e -r -o combine to do that of course [01:13:04] <CIA-24> ffmpeg: stefano * r22688 /trunk/libavformat/utils.c: [01:13:04] <CIA-24> ffmpeg: Fix updating condition for the probe_size variable in the internal [01:13:04] <CIA-24> ffmpeg: loop of ff_probe_input_buffer(), making sure that probe_size is always [01:13:04] <CIA-24> ffmpeg: set to probe_max_size in the last iteration. [01:13:04] <CIA-24> ffmpeg: Also make the function return an error if we get to the max probe [01:13:05] <CIA-24> ffmpeg: length and still cannot figure out what the format is. [01:13:06] <CIA-24> ffmpeg: Patch by Micah Galizia micahgalizia A gmail D com. [01:13:44] <hyc> life used to be so simple, you type an invalid option, the program prints its usage [01:13:48] <mfg> sweet!!! [01:13:52] <hyc> then you get it right and move on [01:14:14] <mfg> TY! [01:14:20] <hyc> I would just use "-," for any program I needed help with [01:14:33] <mfg> who is Stefano (I mean, IRC handle) [01:14:39] <mru> saste [01:14:40] <hyc> now GNU tools unhelpfully say "use --help" ... bleah [01:14:50] <mfg> saste: ty! [01:15:00] <mru> gnu is getting more bloated by the hour [01:15:06] <DonDiego> mru: i committed a docs update for freebsd [01:15:12] <mru> DonDiego: I noticed [01:15:59] <mru> I'm still curious as to whether anyone has contacted any bsd devs [01:16:15] <DonDiego> it would be interesting to know [01:16:19] <hyc> mru: regarding librtmp into libavformat - we had length discussion of that here in irc last week [01:16:26] <DonDiego> we can talk to them at the next conference [01:16:28] <mru> I don't personally know the spell to summon them [01:16:31] <hyc> I don't have the energy to summarize it back to email at the moment [01:16:45] <mru> must have missed it [01:17:05] <DonDiego> they are at all the fosdem, linuxtag, froscon and whatnot events.. [01:17:14] <mru> no [01:17:17] <mru> they have people there [01:17:21] <mru> clueless people [01:17:28] <DonDiego> not all of them [01:17:36] <mru> people who will only tell you they're not responsible for _that_ particular mess [01:17:48] <DonDiego> ever tried talking to them? [01:17:52] <mru> yes [01:17:57] <mru> always got that reply [01:19:58] <saste> mfg: np [01:22:31] <Compn> mru : should print up some tshirts for them [01:22:35] <Compn> 'not my department' [01:23:10] <mru> soon it'll be "not my bsd" [01:23:23] <mru> they could rename all of them MyBSD [01:27:16] <hyc> well, one nice thing about gnu, it makes it harder to accidentally type "rm --recursive --force /" [01:27:52] <mru> it still supports -rf [01:27:56] <mru> thank goodness [01:27:59] <hyc> yeah, was just joking [01:28:17] <mru> it is kinda nice that you can put flags after filename arguments [01:28:29] <mru> I always type rm /some/path -rf [01:28:44] <mru> just to make sure I don't accidentally hit enter after rm -rf / [01:35:01] <Compn> shouldnt there be a block anyways? [01:35:08] <Compn> really how many times do people NEED rm -rf / ? [01:35:22] <Compn> rm -rf / --yes-i-mean-it [01:35:23] <Compn> ... [01:35:30] <hyc> lol [01:35:40] <mru> that's windows-think [01:35:41] <hyc> "-f" *is* "yes i mean it" [01:35:49] <mru> protecting the users from themselves [01:35:55] <mru> redhat does it to [01:35:58] <Compn> -f is yes i want to remove a directory [01:36:02] <mru> aliasing rm to rm -i by default [01:36:07] <Compn> but sure, its used twice, which is stupid [01:36:36] <mru> -f has nothing to do with directories [01:36:54] <Compn> oop [01:37:23] <mru> -f does two things [01:37:56] <mru> if not specified, rm will ask before deleting non-writable files [01:38:26] <mru> it also suppresses error messages and exit status when files don't exist [01:41:24] <ohsix> hurr cat -e is handy [01:42:09] <mru> I agree with whoever said unix bloat started the day cat started taking options [01:48:06] <DonDiego> gnite [01:55:18] <hyc> has anyobody played with gource? [01:55:31] <hyc> it can output a stream of pnm's to be assembled into a movie [01:55:46] <hyc> sometimes it appears to output an incomplete/partial pnm frame [01:56:26] <hyc> and that can sometimes cause a crash [01:56:52] <hyc> I had this patch sitting in my tree for a few months, just remembered it [01:57:28] <hyc> http://hyc.pastebin.com/DUpLuZe0 [02:00:19] <Kovensky> how does one use avcodec_decode_audio3? [03:05:35] <pengvado> is there an ffmpeg option to not mess with the terminal state? [03:06:30] <pengvado> I'm trying to run `valgrind --db-attach=yes ffmpeg`, and I can't do anything in gdb once it's attached because the terminal is in raw mode or something [03:07:14] <Dark_Shikari> ./ffmpeg 2>&1 | cat - ? ;) [03:07:36] <pengvado> that kills valgrind's and gdb's output too [03:08:40] <Dark_Shikari> why do you need db-attach? [03:08:48] <Dark_Shikari> (you could also just comment out any of the relevant stuff in ffmpeg.c) [03:08:53] <pengvado> oh wait, redirecting input through cat works [03:09:38] <pengvado> db-attach to let me debug an invalid but non-crashing memory access [03:11:50] <astrange> i just comment out the curses stuff in ffmpeg.c when i need to [03:16:16] <mru> I'd like to remove that terminal interference entirely [03:16:35] <mru> ctrl-c is as easy to type as q [03:30:21] <CIA-24> ffmpeg: astrange * r22689 /trunk/libavcodec/h264_cabac.c: [03:30:21] <CIA-24> ffmpeg: h264: Simplify decode_cabac_residual() specialization [03:30:21] <CIA-24> ffmpeg: Gives more consistent inlining with some compilers (such as llvm). [03:32:47] <CIA-24> ffmpeg: astrange * r22690 /trunk/libavcodec/h264_cabac.c: h264: Remove unused function argument [04:13:18] <CIA-24> ffmpeg: ramiro * r22691 /trunk/libavcodec/libxvidff.c: [04:13:18] <CIA-24> ffmpeg: libxvid: Clear extradata pointer when freeing it. [04:13:18] <CIA-24> ffmpeg: Fixes crash when avcodec_close() tried freeing it again. [04:13:18] <CIA-24> ffmpeg: Fixes issue 1846. [04:24:37] <ramiro> NSFW bug reports... Sturgeon was wrong: 90% of everything is porn. [04:25:00] <mru> and 90% of porn is crap [04:25:24] <ohsix> and 8% of that is crap porn [04:26:14] <mru> speaking of nsfw bugs, at nds we sometimes had bugs related to pay-per-view stuff... [04:26:51] <mru> most of them could be reproduced on the test systems [04:26:57] <mru> but sometimes the real signal was required [04:28:40] <astrange> the rsync for the fate samples takes a while... [04:29:04] <mru> only the first time [04:29:33] <drv> i think it's mainly the slow connection, not very big [04:29:34] <mru> it's only 300MB [04:29:40] <mru> that's smaller than openoffice [04:29:46] <drv> haha [04:29:52] <ramiro> smaller than xcode [05:04:52] <CIA-24> ffmpeg: astrange * r22692 /trunk/libavcodec/h264_cabac.c: [05:04:52] <CIA-24> ffmpeg: h264: Use + instead of | in some places [05:04:52] <CIA-24> ffmpeg: 6 insns less on x86-64/gcc 4.2. [05:16:00] <elenril> are those -mt backports? [05:36:49] <astrange> no, just local patches [07:09:23] <superdump> has that marcelo guy been in at all? [07:10:25] <superdump> it seems that he, as i was, is not familiar with fixed point math [07:10:46] <superdump> so i think a floating point amr-wb decoder is a good option [07:53:57] <hyc> fixed point is a lot faster [07:56:13] <merbzt1> hyc: not on modern cpu's [07:57:20] <superdump> merbzt1: that's what i was thinking, but how about arm/mips/whatever? [07:57:32] <superdump> or snapdragon, whatever arch that is [07:57:49] <superdump> i guess such devices have dsps if they need them [07:58:00] <merbzt1> neon for the win [07:58:08] <hyc> yes, but getting your generic code to run on the dsp is another trick [07:58:50] <hyc> merbzt1: most integer ops are single cycle. you're claiming that most floating point ops are equally fast? [07:59:09] <hyc> seems pretty unlikely [08:00:02] <wbs> but fixed-point code needs more operations to achieve the same (e.g. multiplication + shifts, instead of simply doing the multiplication in floating point) [08:00:09] <hyc> and how hard is it to teach someone the principles of fixed-point math? [08:00:46] <merbzt1> hyc: no, but you can't compare ops 1 to 1 as the usage would be different [08:00:49] <hyc> most DSPs are still faster as fixed point... [08:00:51] <superdump> not hard, but it's more confusion on top of learning how to work with ffmpeg, how to decipher a spec and how to make an implementation [08:01:18] <hyc> well, it's more intensive education, at least [08:01:30] <merbzt1> if you take a mul for example, a float one is just a mul, but for a fixed point implementation mul you might need to shift the result [08:01:32] <wbs> hyc: nevertheless, there's for example a suggested task with an floating point mpeg audio decoder: http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_Of_Code_2010#Floati… [08:01:36] <superdump> plus as other CELP codecs have been implemented in floating point, we can reuse stuff [08:01:41] <hyc> do you want to train a codemonkey, or someone who understandshow things really work... [08:02:57] <hyc> ah well, never mind [08:03:03] <hyc> at least ffmpeg is still written in C [08:03:25] <merbzt1> hyc: that said, fixedpoint stuff is nicer in alot of other ways [08:03:30] <merbzt1> hyc: :) [08:04:11] <astrange> probably more people care about amr in fixedpoint than in floating point [08:04:39] <superdump> i'm sure [08:04:44] <merbzt1> those who care have opencore [08:04:45] <astrange> actually, what do you even use amr for? is it the codec in .3gp? [08:04:51] <hyc> yes [08:04:54] <superdump> yes [08:05:15] <hyc> so phones, embedded devices with limtied resources [08:05:23] <hyc> of course, these days even phones are pretty beefy [08:05:28] <superdump> indeed [08:05:31] <wbs> does anybody know about how widespread amr-wb is in practice? [08:05:34] <astrange> iirc those get uploaded to video sites a lot [08:05:41] <astrange> and of course fp is fine there [08:05:46] <superdump> mmm [08:06:13] <wbs> symbian phones have managed to decode such files well (e.g. over rtp), but I really don't know about any of them producing it themselves [08:06:17] <merbzt1> wbs: not so much [08:07:09] <merbzt1> maybe I should add g723.1 and g729 [08:07:14] <merbzt1> for SoC [08:12:51] <superdump> probably speech codecs are pretty easy now we have a pool of code [08:13:56] <wbs> superdump: how much do they share in the actual design? what i've wikipediad about -nb vs -wb, i've gathered that they don't share much except for the name [08:13:59] <CIA-24> libswscale: diego * r30961 /trunk/libswscale/yuv2rgb.c: HAVE_MMX2 implies HAVE_MMX, so checking the latter is enough. [08:14:32] <superdump> from what i saw a while ago, they looked pretty similar in a lot of the functions [08:14:42] <superdump> the big difference was LSP versus ISP [08:14:55] <superdump> aside from the sample rate and whatnot [08:15:00] <merbzt1> and they are sooo different [08:15:15] <superdump> if you have functions supporting variable numbers of samples, you should be fine [08:15:38] <superdump> heh [08:47:15] <twnqx> wow, fedex won the race [08:47:41] <twnqx> yesterday UPS was ahead, first to arrive in germany from Thief River Falls [08:47:50] <twnqx> now fedex already delivered :X [08:47:58] <superdump> anything shiny? [08:48:12] <twnqx> integrated circuits! [08:48:32] <superdump> mmmm, chips [08:48:51] <twnqx> gah [08:48:56] <twnqx> i'm craving chips atm [08:49:06] <twnqx> dieting causes such annoying side effects... [09:49:03] <KotH> anyone here who knows someone doing QNX contractor work? [09:49:18] <kshishkov> what does that mean? [09:49:45] <KotH> we've a customer who wants to have something what we do not provide [09:49:46] * kshishkov knows few people employing QNX in nuclear power plant control systems [09:49:58] <kshishkov> I don't think that will help though [09:50:00] <KotH> err... [09:50:07] <KotH> no thanks.. i still remember 1986 [09:50:58] * kshishkov also remembers how his company searched for VxWorks developer [09:51:20] <KotH> anyways, we'd like to pass that customer to someone else [09:52:11] <kshishkov> the funniest thing is that only I knew what requirements (s)he should have [09:52:24] <twnqx> your insurance doesn't cover nuclear fallout? [09:53:47] <superdump> i don't think insurance would help much [09:54:24] <kshishkov> insurance = 20m thick lead sheets [09:54:42] <merbzt1> that sounds cozy to have in bed [09:57:47] <CIA-24> ffmpeg: diego * r22693 /trunk/doc/general.texi: Add (Open)Solaris section to platform documentation. [10:02:27] <lu_zero> wbs: you around? [10:02:33] <wbs> lu_zero: yeah [10:02:54] <lu_zero> got the time to discuss a bit about dss and your usage of it? [10:03:02] <wbs> absolutely [10:03:12] * lu_zero today has some time spared [10:03:37] <lu_zero> first: how ANNOUNCE/RECORD is supported there? [10:04:12] <lu_zero> I have javanx there that is looking at the dss docs and he just found stuff about reflectors and .sdp files [10:04:22] <lu_zero> (that's pretty much the same as in feng) [10:05:49] <wbs> yeah, I think the concept is called reflection [10:06:06] <Dark_Shikari> kshishkov: ping [10:06:14] <wbs> the client does an ANNOUNCE with any path that doesn't exist currently, (normally a .sdp filename), then setup and RECORD instead of PLAY [10:06:43] <wbs> as long as that session is active, the URL that was used in the ANNOUNCE is available for normal DESCRIBE/PLAY [10:06:58] <wbs> and after teardown, the URL gives 404 again [10:07:32] <wbs> I guess the server could store the packets somewhere to replay them on demand later, too, but DSS doesn't do that afaik (or I haven't seen such a configure option at least) [10:07:34] <lu_zero> uhm, that's something not in the documentation picked up so far [10:08:07] <Dark_Shikari> kshishkov or anyone else who knows--can ffmpeg output to rtmp now? [10:08:12] <Dark_Shikari> i.e. send video to an rtmp server via rtmp [10:08:17] <Dark_Shikari> ffmpeg -i blah blah blah rtmp://blah blah/ [10:08:21] <wbs> Dark_Shikari: yes [10:08:26] <wbs> you need to add -f flv though [10:08:35] <Dark_Shikari> thx. [10:13:24] <lu_zero> storing would be useful? [10:13:43] <lu_zero> I mean you have the network in between and your channel isn't as reliable as a local storage [10:14:10] <wbs> nah, not that useful to me, only theoretically [10:14:20] <lu_zero> (our suggested workflow is to have ffmpeg do the recording locally and then upload later [10:14:23] <lu_zero> ) [10:14:37] <wbs> how does feng serve static files btw, do they have to be rtp-hinted, or does it handle that itself? [10:14:50] <lu_zero> it does handle that itself [10:15:07] <wbs> ah, nice. dss requiring hinting feels stupid. :-) [10:15:45] <lu_zero> basically it just use what ffmpeg tells [10:18:24] <wbs> so in practice, it has rtp packetizers for a bunch of formats internally [10:18:56] <lu_zero> yes [10:21:09] <lu_zero> possibly I'll replace them with ffmpeg ones [10:21:30] <lu_zero> (since would be pointless keeping them there if they work the same way) [10:23:33] <wbs> probably yes, if lavf would happen to support more formats [10:33:29] * lu_zero notices that seeking is broken in ffmpeg in the end =P [10:33:39] <lu_zero> I eventually built and installed a local dss [10:33:41] <lu_zero> ^^ [10:33:50] <wbs> ah. :-) [10:34:14] <lu_zero> you can seem correctly by percent but not by offset [10:34:46] <wbs> yes, dss sucks quite a bit. i've polished it up and gathered some fixes for running it on 64bit, and made some shellscripts for running it installed for a local user, not requiring root, not requiring to spread things around /usr/local :-) [10:34:52] <wbs> I guess I should put it up somewhere sometime [10:39:12] <lu_zero> wbs: since you have lots experience with it I would be delighted to get some feedbacks on how to make feng a nicer toy to play with ^^ [10:40:10] <wbs> lu_zero: I'm starting to look at feng now actually - I've been put off by the amount of dependencies (of which I noticed that most are available on debian or debian-multimedia.org anyway, so it's a moot point), I'll get back to you with comments later when I've used it a bit more :-) [10:40:45] <lu_zero> uhmm [10:41:22] <justlooking> KotH, the only active outlet for QNX people these is the http://www.openqnx.com/index.php?name=PNphpBB2 but on a quick look i dont see any old time QNXRTP 6 devs/contractors posting ,but werth a shot i guess as even the main IRC channels they used are no more, shame. [10:41:30] <lu_zero> flameeyes had a bundle-script that should fetch and build feng+deps [10:41:45] <lu_zero> I'll ask him to publish it [10:41:53] <lu_zero> Honoome: around? [10:43:27] <wbs> lu_zero: so, feng doesn't support announce/streaming at the moment, right? [10:45:17] <lu_zero> wbs: nope [10:45:34] <wbs> what's "live streaming supported...... : yes" that configure mentioned? [10:45:49] <lu_zero> we have an rtp mixer that uses posix queues right now [10:46:09] <lu_zero> so if you are on systems not supporting them that part won't be built [10:46:22] <wbs> I see - what apps do you use to push content into that then? [10:48:04] <lu_zero> the chain is [10:48:17] <lu_zero> any rtp producer (vlc, ffmpeg had been used a lot) [10:48:39] <lu_zero> a flux that picks the rtp streams and tunnels them to the remote server [10:48:45] <KotH> justlooking: thanks [10:48:59] <lu_zero> a flux in the remote server picking them and feeding feng [10:49:11] <lu_zero> feng delivers them to the end user [10:49:46] <wbs> ah, ok [10:50:37] <wbs> if you'd have rtsp announce support, I guess the flux steps inbetween could be removed and the rtp producer could talk straight to the rtsp server [10:50:57] <lu_zero> if you like that way yes [10:52:17] <lu_zero> flux has some features you might like [10:53:26] <wbs> hmm, interesting [10:54:42] <lu_zero> it is a mixer so you can do some processing there [10:55:05] <lu_zero> like use it to splice the rtp streams between different servers [10:55:18] <lu_zero> or do on the fly conversions [10:57:49] <wbs> btw, if using feng, what stats interfaces are available? i.e., if I'd like to know which streams are being served at the moment, with how many active viewers at each stream? [10:58:28] <lu_zero> wbs: I already had this request [10:58:50] <lu_zero> I'm writing it more or less now so tell me what you'd expect to get and you'll have it =) [10:59:24] <lu_zero> right now feng has a sort of accesslog that is like the apache one [11:00:01] <wbs> that's probably quite ok for checking how many total views different streams have had, but it'd be good with some kind of interface where one could poll the amount of current streams [11:00:06] <lu_zero> and a server log in which it states how many clients are connected [11:01:13] <lu_zero> Honoome: was thinking about providing a way to issue a get to a specific path [11:14:30] <justlooking> well lu_zero it appears that serching oin win32 feng wants to give you lots of fang virus link info so i take it ,its not a good app for small self contained cross platform streamign then ?, and this included 'flux tunnel' isnt a multicast capable one to many tunnel? [11:14:52] <justlooking> searching on... [11:15:41] <lu_zero> justlooking: ? [11:16:52] <justlooking> feng is not written to be compiled and run on win32 so its useage is limited to unix like systems only? [11:17:13] <lu_zero> so far nobody requested win32 support [11:18:03] <lu_zero> probably you would be able to build it in cygwin [11:18:36] <lu_zero> the only annoying thing it uses is the posix queue facility that is a bit too recent... [11:20:02] <justlooking> i gather that, but whats your core usage, you came from amiga/QNX type small and self contained simple apps is good mindset if i understand ? and so im suprised you didnt make/patch it be cross platform and self contained. [11:22:22] <lu_zero> justlooking: feng build deps like ragel aren't require for usage [11:22:43] <lu_zero> beside that feng needs just glib, netembryo and ffmpeg [11:22:59] <lu_zero> netembryo being a thin network abstraction [11:23:19] <lu_zero> all of them being fairly portable [11:29:39] <lu_zero> [Fri Mar 26 12:29:27 2010] Range header: npt=-816375531.124- [11:29:44] <lu_zero> interesting =_= [11:35:44] <lu_zero> wonderful [11:36:08] <lu_zero> ffmpeg tries to send an npt range as negative? [11:36:15] <lu_zero> (invalid range) [11:39:43] <justlooking> ffmpeg OR DSS? http://lists.apple.com/archives/streaming-server-dev/2003/May/msg00019.html "...We thoroughly tested the version 4.1.3 and found that, as we previously [11:39:43] <justlooking> noted, DSS: [11:39:44] <justlooking> - never returns a range header in the response [11:39:44] <justlooking> - responds OK to an invalid range but does not stream any packets. [11:39:44] <justlooking> The proper handling of the Range header is extremely important for [11:39:45] <justlooking> precise media synchronisation and more generally for finding out the [11:39:47] <justlooking> exact media time that corresponds to the timestamp of the first RTP [11:39:49] <justlooking> packet...." [11:40:55] <lu_zero> ... [11:41:15] <lu_zero> sigh [11:41:36] <lu_zero> I'm playing with dss default files to see the different behaviour [11:41:49] * justlooking Ok, AFK sorry Lu... [11:42:51] <lu_zero> np [11:44:00] * justlooking just trying to learn how it fits together you understand, afk for real . [11:54:06] <lu_zero> Duration: 00:01:10.01, start: -816374104.-875422, bitrate: N/A [11:54:09] <lu_zero> hum... [12:22:35] <lu_zero> nobody used valgrind on ffmpeg lately.... [12:25:40] <wbs> lu_zero: I use it quite regularly and don't see any leaks nor memory errors, for the things I run [12:27:26] <ramiro> lu_zero: there's a fate box running it under valgrind [13:09:35] <BMintern> hello. i was wondering if there's anyone here who could take a few minutes to get me up to speed on libavfilter. i'm interested in developing a filter to fade in/fade out, but i have never worked on ffmpeg at all before [13:15:09] <BMintern> ahh... i see http://wiki.multimedia.cx/index.php?title=FFmpeg_filter_howto [13:15:17] <BMintern> hopefully that will be enough to get me started [13:30:42] <merbzt1> BMintern: you can ask vitor if you get stuck [13:34:55] <BMintern> thanks merbzt1 [13:38:15] <Vitor1001> lu_zero: nobody used valgrind on ffmpeg lately.... [13:38:29] <Vitor1001> lately == less than 6 hours? http://fate.multimedia.cx/index.php?build_record=206164 [14:05:39] <BMintern> Vitor1001: would it be sensible to have a filter that produces frames? i'm thinking along the lines of something that would replace the usage of -vframes in conjunction with -ss [14:06:36] <Vitor1001> Looks reasonable at a first glance. [14:07:09] <Vitor1001> You mean, a simple pass-throught filter that would send an end-of-stream when some condition is met? [14:08:06] <BMintern> not exactly. right now i'm using ffmpeg -vframes 1 -ss $duration -i $video $image_name in order to grab the last frame of a video [14:08:55] <BMintern> what i would like to be able to do is to do this inside the filter chain on the output of a filter [14:09:08] <Vitor1001> Ok, so it would drop all the frames but the last? [14:09:23] <BMintern> pretty much. i think it would probably be more useful if it was more flexible [14:09:27] <Vitor1001> Sounds reasonable too, if it has a flexible syntax [14:09:50] <Vitor1001> Note that having a very powerful syntax is not completely possible [14:10:12] <Vitor1001> For ex., there is no easy way to know how many frames a file contains [14:10:36] <Vitor1001> But accepting things like "one frame every 100" should be doable [14:11:12] <BMintern> ok, one more thing... i was wondering if it would be sensible to have a filter that only accepts a single frame (an image) as input [14:11:38] <Vitor1001> what is the point? [14:11:39] <BMintern> specifically i would like to take an image and fade it to/from black over a specified duration [14:11:52] <Vitor1001> hmmm [14:12:01] <BMintern> in order to produce an output stream [14:12:24] <Vitor1001> it would be better to implement it chaining a frame duplicating filter + a fade-to-black one. [14:12:55] <BMintern> i like that idea [14:13:20] <BMintern> so my frame filter could replicate a requested frame a given number of times [14:13:37] <BMintern> and then a fade to black frame could take that and fade it [14:13:39] <Vitor1001> the frame duplicating one should be very similar to the timestamp modification filter [14:14:21] <Vitor1001> yes [14:15:35] <BMintern> one last question... for a fade filter like that, you'd have to manually specify the total number of frames in the stream because there is no knowledge of the number of frames until you read the entire input? [14:16:40] <BMintern> or at least, specify begin-fade, end-fade parametrs [14:16:49] <BMintern> where the parameters are frame numbers [14:17:27] <Vitor1001> looks a good idea [14:17:46] <Vitor1001> anyway, most uses of a fade filter will not be for a whole video anyway. [14:18:00] <BMintern> right, that's what i was thinking [14:18:14] <Vitor1001> The most common one would be fading the last n frames, but this is not possible :p [14:18:28] <BMintern> i was thinking something like fade=in:0:30 would fade in the first 30 frames [14:18:50] <BMintern> and fade=out:1000 would fade out from the 1000th frame to the end of the video [14:19:00] <BMintern> oh, whoops that wouldn't work [14:19:31] <Vitor1001> exactly :p [14:19:33] <BMintern> i guess you'd have to know the video is 1030 frames and fade=out:1000:1030 [14:19:38] <Vitor1001> And the most useful case [14:19:45] <Vitor1001> fate=out:-10 [14:19:51] <BMintern> right [14:19:51] <Vitor1001> to fade the last 10 frames [14:20:05] <Vitor1001> is not very doable with current way it works [14:20:23] <BMintern> it seems trivial to write a frame-counting filter [14:20:30] <Vitor1001> and them? [14:20:37] <Vitor1001> to cache in ram the whole movie? [14:20:44] <Vitor1001> to write raw data to a random file? [14:20:52] <Vitor1001> or doing two pass... [14:20:58] <BMintern> sorry, i was just thinking out loud [14:21:29] <Vitor1001> Its sad, but some things does not play well with a filtering lib concept [14:21:43] <Vitor1001> like a play-backward filter. [14:21:44] <BMintern> well, i was thinking of hacking around some of the limitations [14:22:12] <Vitor1001> But yes, a bash script that first count frames and them do the fading should work [14:22:30] <BMintern> so a certain filter could produce a stream that is not actually a stream but just a dummy stream where a certain struct field is used to give some information [14:22:32] <Vitor1001> but is inefficient in the sense it will decode the video twice [14:22:36] <BMintern> such as number of frames [14:22:46] <Vitor1001> no need a filter for that [14:23:12] <Vitor1001> ffmpeg -i file.avi -f framecrc - | grep -c "$1" [14:23:18] <BMintern> except that sometimes you might want to count the number of frames in a filter stream without having to first write out the file [14:24:03] <BMintern> but i guess i'm probably getting into less-useful territory now [14:24:12] <Vitor1001> you can avoid writing the file, but not decoding it twice, unless you store the decoded data somewhere [14:24:22] <BMintern> ahh [14:24:26] <BMintern> i didn't realize that [14:24:26] <Vitor1001> outlandish brainstorming is fun ;) [14:25:01] <BMintern> so the streams that are handled by vfilters are being decoded and re-encoded along the way? [14:25:48] <Vitor1001> Yes, it is just not possible to cache a whole decoded movie [14:25:58] <Vitor1001> and inefficient to store it in the disk [14:26:11] <BMintern> right, that makes sense. it just seems that if you had too many filters you would start to see degradation [14:26:33] <Vitor1001> A single filter would be enough [14:26:49] <Vitor1001> imagine resizing a DVD while storing all the frames in RAM [14:27:01] <Vitor1001> better have hundreds of GB of it. [14:27:06] <BMintern> yeah, i gotcha [14:27:21] <BMintern> well, thanks for the help. i'm going to see about implementing a "frame" and a "fade" filter [14:27:28] <Vitor1001> ok, good luck [14:27:45] <Vitor1001> don't forget to give a look at our developer doc before posting your patch [14:28:04] <BMintern> i took a look at http://wiki.multimedia.cx/index.php?title=FFmpeg_filter_howto if that's what you mean [14:28:09] <ramiro> what fate id is the valgrind box? [14:28:16] <Vitor1001> ramiro:183 [14:28:16] <BMintern> and also the stuff in ffmpeg about proper code formatting [14:28:29] <BMintern> anything else i need to look at [14:28:36] <Vitor1001> yes, the formatting before sending your patch [14:28:48] <Vitor1001> just because is silly to lose time with such thing ;) [14:29:03] <BMintern> i've never worked with an open source project like this before, so i don't know much about patching [14:29:37] <BMintern> is there a good guide for me to follow? [14:29:38] <Vitor1001> Use "svn diff" and you can't go wrong. [14:29:40] <BMintern> ok [14:29:48] <BMintern> thanks a lot [14:29:51] <Vitor1001> and read its output before expecting people to do it. [14:30:04] <BMintern> will do [14:30:13] <Kovensky> anyone has any samples on how to use avcodec_decode_audio3 + libavformat? [14:30:15] <Vitor1001> for example, if you reindent a big block of code it is almost impossible to tell apart what changed and what was just reindented [14:30:22] <ramiro> Kovensky: ffmpeg.c? [14:30:31] <Kovensky> ramiro: scary code there :S [14:30:42] <BMintern> well i wouldn't be expecting to change many existing source files (hopefully!) :) [14:31:06] <ramiro> BMintern: you'll have to svn add your files before doing svn diff... [14:31:08] <Vitor1001> Yes, very likely you will be just adding a single file [14:31:17] <Kovensky> well, the problem I'm having is that av_free_packet crashes if I modify .data or .size; and the decoded audio sounds horrible =p [14:31:46] <BMintern> i would just write vf_fade.c, vsrc_frame.c, and add the two to allfilters.c [14:32:10] <BMintern> well, i should probably do those as two separate patches :) [14:32:37] <Vitor1001> instead of vsrc_frame, maybe it is better a vf_duplicate [14:32:53] <BMintern> ahh, ok [14:33:05] <Vitor1001> that may duplicate the first frame 100 times then EOF, or just duplicate every one, or whatever... [14:33:33] <Vitor1001> maybe a better name would be vf_clone... [14:33:57] <Kovensky> ramiro: http://pastebin.org/124789 <-- current code [14:34:29] <BMintern> it should probably be made to duplicate a sequence of frames, correct? [14:34:48] <BMintern> just in my case, it would only duplicate a sequence of length 1 [14:34:59] <Kovensky> ramiro: can you spot any obvious mistakes?\ [14:35:03] <Kovensky> s/\\// [14:35:11] <BMintern> a sequence of frames for a specified number of repetitions [14:35:41] <ramiro> Kovensky: where does it crash? [14:36:31] <Kovensky> ramiro: av_free_packet [14:36:37] <Kovensky> (and the decoded audio sounds horrible) [14:36:47] <Kovensky> http://kovensky.project357.com/files/audio.dump (lol eroge op) [14:38:13] <ramiro> Kovensky: is that thread-safe? [14:38:34] <Kovensky> ramiro: no, but it's not multithreaded code [14:38:36] <ramiro> Kovensky: also look at ffplay.c for queue and such [14:39:03] <Vitor1001> Maybe giving as parameters first_frame:last_frame:number_of_times_duplicated [14:40:10] <BMintern> i was thinking that [14:40:27] <BMintern> the only problem i run into is that it would be nice to be able to say clone:-1:30 [14:40:33] <BMintern> to clone the last frame 30 times [14:40:45] <BMintern> oops clone= [14:40:59] <BMintern> but perhaps the 2nd parameter could be optional? [14:41:20] <BMintern> first_frame:[last_frame:]number_of_times_duplicated [14:42:03] <BMintern> and if first_frame is -1 then number_of_times_duplicated (assuming last_frame is given) would be ignored (as last_frame would be used instead) [14:42:07] <Kovensky> ramiro: my enqueue_packet / dequeue_packet are almost identical to ffplay's code, except without SDL code [14:42:29] <Kovensky> (comparing to packet_queue_get and packet_queue_put) [14:43:30] <BMintern> Vitor1001: should be take some of this discussion about specifics out of #ffmpeg-devel? [14:44:02] <ramiro> Kovensky: hmm. if you pkt.data += something, how do you expect free to find the start of the buffer to free it? [14:45:09] <BMintern> also, is there yet a filter to just take a bunch of inputs and concatenate them? [14:46:43] <Kovensky> <@ramiro> Kovensky: hmm. if you pkt.data += something, how do you expect free to find the start of the buffer to free it? <-- that's why I'm looking for better sample code than http://dranger.com/ffmpeg/tutorial03.html (which uses decode_audio2) [14:48:34] <Vitor1001> BMintern: Yes, maybe before you start coding, you should send a RFC to ffmpeg-devel [14:49:03] <Vitor1001> So if someone think about a better design, you can implement it at first. [14:49:22] <BMintern> well i need this like yesterday, so i'm going to go ahead and write it to do what i need and worry about changing it later [14:50:44] <BBB___> KotH: help! [14:51:09] <ramiro> the underline count has grown to 3 [14:51:12] <ramiro> ah, too late =) [14:54:17] <BBB> does anyone here know mailman? [14:54:18] <BBB> a [14:54:49] <kshishkov> look at KotH/mru again [14:56:17] <BBB> hm, I think I found iot [14:58:02] <KotH> BBB: what do you want? [14:58:09] <BBB> nothing [14:58:14] <BBB> I figured it out myself [14:58:16] <BBB> thanks [14:58:24] <KotH> good [14:58:39] <kshishkov> if all users were like that... [14:59:05] <scaphilo> does anyone know if a decoded picture AVFrame still has its qscale_tab filled so that i can use this values in the encoder? same for motion_val [15:03:58] <kshishkov> IIRC, all of that is stored in MPEG decoder pictures which are AVFrame extensions [15:04:45] <kshishkov> I don't remember but it may be either copy full picture reference or only buffer pointers, so I'd not bet on it [15:05:16] <scaphilo> thx, ill better try to copy the values than just the pointer [15:05:38] <scaphilo> seems to happen here static void copy_picture_attributes(MpegEncContext *s, AVFrame *dst, AVFrame *src) [15:17:58] <BBB> Vitor1001: do you mind if I change ff_acelp_apply_order_2_transfer_function() to take a const float *in and a float *out, so I don't have to memcpy() from synthesis buffer to the output buffer afterwards? [15:18:10] <BBB> Vitor1001: that'd make it a *lot* easier to address Michael's concerns in the clipping patch [16:02:29] <BMintern> is there a standard type to use in ffmpeg development for frame count or frame number? [16:02:40] <wbs> uint64_t? :-) [16:02:45] <BMintern> ok, thx [16:02:53] <BMintern> i've never done ffmpeg development [16:05:28] <CIA-24> ffmpeg: mstorsjo * r22694 /trunk/libavformat/ (tcp.c udp.c rtpproto.c): Don't report EINTR from select as an error, retry select instead [16:07:12] <wbs> BBB: thanks, that was the last outstanding patch I had :-) [16:07:39] <kshishkov> wbs, how many less great patchs do you have? [16:07:45] <kshishkov> *patches [16:08:25] <wbs> kshishkov: haven't any left locally that I'm aiming to submit, at the moment [16:09:04] <wbs> but I've got a small list of stuff that I might do if I gather time again... but perhaps I should let BBB rest for a while :-) [16:09:11] <kshishkov> well, you've said "outstanding" which means you may have patches of different quality [16:09:40] <BBB> outstanding = unfinished work [16:09:55] <BBB> at least in dutch ;) [16:09:59] <BBB> not sure if it translates literally [16:10:01] <wbs> yeah, that was the version I meant [16:10:23] <DonDiego> ik spreek geen nederlands [16:10:32] <wbs> as in, "number of patches submitted, with hopes of getting approval" == 0 [16:10:33] <kshishkov> BBB: I use MacOSX dictionary.app to verify, and there it's the second meaning [16:10:51] <wbs> (which also can be achieved by outright rejecting all suggestions) ;P [16:11:04] <BBB> DonDiego: \o/ [16:11:47] * kshishkov wonders is unfinished work _supposed_ to be extremely good since it can be described with the same word [16:14:01] <kshishkov> BBB: Diego lives in a couple of kilometers from Netherlands, so he should be able to speak Dutch anyway [16:15:00] <BBB> oh really [16:15:19] <wbs> kshishkov: http://dictionary.reference.com/browse/outstanding has my meaning of the word, #3 ;P [16:15:32] <BBB> DonDiego: http://www.dumpert.nl/mediabase/827601/ef98cc85/stephen_colbert_over_nederl… [16:15:34] <kshishkov> I'm not sure but his street may run straight into German-Dutch border too [16:16:02] <mru> yep, been there [16:16:18] <mru> and for the record, outstanding has two meanings [16:16:48] <mru> it can mean either "to be completed" or "exceptionally good" [16:17:25] <mru> comes in handy when dealing with customers :-) [16:17:32] <kshishkov> still better than Swedish "tack" eller "hej" [16:20:29] <DonDiego> BBB: hilarious :) [16:20:36] <BBB> did you get the dutch parts? [16:20:44] <BBB> boerenkool stampot met wurst [16:21:17] <kshishkov> Dutch sounds like German with a touch of Finnish [16:23:11] <BBB> no, german sounds like dutch with a little bit of something else [16:23:15] <BBB> don't forget german is dutch-derived [16:23:19] <BBB> not the other way around [16:23:21] <BBB> ;) [16:24:28] <kshishkov> well, judging by who owns whom (and rides on colonial roads in caravans)... [16:24:38] <BBB> we always beat htem in soccer games [16:25:46] * kshishkov lives in a country which is hard _not_ to beat in soccer [16:25:57] <wbs> same here ;P [16:26:11] <mru> sweden got the gold once [16:26:14] <mru> in 1952 iirc [16:26:21] <BBB> we in '88 [16:26:27] <mru> the games were hosted in stockholm... [16:26:34] <mru> odd coincidence... [16:26:37] <wbs> finland hasn't even qualified to any kind of higher level championships ;P [16:26:55] <kshishkov> wbs: but you have too much racers though [16:26:59] <mru> the best sweden has done in modern times was the bronze in '94 [16:27:13] <wbs> kshishkov: true [16:27:41] <superdump> why are you talking about medals for football? [16:27:52] <superdump> people win cups in international football competitions [16:27:58] <superdump> cup or no cup [16:28:06] <kshishkov> squashed cups then [16:54:36] <DonDiego> BBB: please, the game is called football, not soccer [16:54:57] <DonDiego> those us-devils have brainwashed you already.. [16:55:03] <kshishkov> depends on locale [16:55:35] <kshishkov> DonDiego: you too. FFmpeg documentation does not have many instances of word "colour" for example [16:55:55] <DonDiego> i fully support american english [16:55:58] * BBB is a us-devil now [16:56:16] <DonDiego> but not the hijacking of the word football for some rugby variant [16:56:59] <kshishkov> at least word "soccer" reminds me of local football player quality [16:58:23] <mru> superdump: let's start a drive for more british spelling in ffmpeg [16:58:33] <superdump> :) [16:58:52] <kshishkov> you have Book of Wisdom to write - all in British spelling [16:58:54] <BBB> FFmpeug? [16:59:23] <kierank> ffmpegh [16:59:57] <kshishkov> DonDiego: do you know that St.Putinsburg is sometimes called "Porebrik-city" because that's their local word for curb not used anywhere else. And that's not the only example. [17:01:16] <mru> kerb, please [17:01:34] <kshishkov> here it's called "bordure" anyway [17:01:47] <kshishkov> and "trottoir" for pavement [17:02:31] <mru> same in swedish [17:02:44] <kshishkov> and better not ask any French [17:02:50] <mru> bloody french, poisoning our language [17:03:00] <kshishkov> could be Germans instead [17:04:07] <mru> or, heaven forbid, russians [17:04:52] <kshishkov> yes, that'd be awful [17:07:36] <kshishkov> mru: would it surprise you that original Ukrainian word for vodka is similar to "akvavit"? [17:08:45] <mru> yes, that would surprise me [17:08:59] <mru> akva is clearly latin-derived [17:09:03] <kshishkov> it is - they have the same origin after all [17:09:21] <kshishkov> yes, something like "water of life" [17:27:42] <BMintern> Vitor1001: looking at vsrc_movie.c, i'm pretty sure there's a bug in the init function -- http://ffmpeg.pastebin.com/bBqGw8j7 [17:28:05] <BMintern> i haven't observed any buggy behavior, but i'm pretty sure that "else" doesn't belong there [17:30:53] <BMintern> i'll just go ahead and e-mail the patch to ffmpeg-soc [19:05:00] <lu_zero> wbs: valgrind tells me quite inane things about memory corruption [19:05:30] <lu_zero> and s->start_time gets corrupted apparently [19:07:02] <wbs> lu_zero: hmm, when doing what? have you made clean and rebuilt to be sure there's no build out of sync? [19:07:09] <lu_zero> yes =| [19:07:24] <lu_zero> pick the dss test streams for 1mbit h264 [19:07:36] <lu_zero> and try to open it [19:07:40] <lu_zero> with ffplay [19:08:01] <lu_zero> you'll get a start time that's quite nonzero [19:08:43] <lu_zero> Duration: 00:01:10.00, start: -816347974.-516000, bitrate: N/A [19:08:58] <lu_zero> in rtsp.c it is set correctly [19:09:55] <lu_zero> does it happen to you as well? [19:12:46] <wbs> hmm, yes, I get this: Duration: 00:01:10.00, start: -816347762.-521000, bitrate: N/A [19:13:01] <lu_zero> it's quite strange [19:13:21] <lu_zero> the ntp-time range is parsed correctly [19:13:42] <BBB> in gdb, put a watch on s->start_time [19:13:49] <BBB> in a top function of ffmpeg.c [19:13:52] <BBB> and see [19:14:03] <BBB> if you give me a uri I'll look at it :) [19:14:22] <lu_zero> BBB: localhost/any-h264-file.mov [19:14:25] <lu_zero> ^^ [19:14:31] <lu_zero> (pick feng or dss) [19:14:41] <BBB> playback [19:14:41] <BBB> ? [19:14:44] <BBB> or streaming to? [19:15:10] <wbs> doesn't this stem from the fix for syncing multiple rtp streams, from rev 21857? [19:15:20] <lu_zero> ffplay rtsp://media.lscube.org/tests/tc.mov [19:15:24] <lu_zero> just streaming [19:15:41] <lu_zero> let me have a look [19:15:48] * lu_zero had been in a meeting for the whole day [19:16:12] <wbs> that is, this: http://git.ffmpeg.org/?p=ffmpeg;a=commitdiff;h=9e9169fcb48f1fc64bf6f65ec021… [19:16:26] <kshishkov> lu_zero: so if you had some portable PC you could do a lot of useful things [19:16:57] <lu_zero> kshishkov: speaking and discussing and ignoring it mostly ^^; [19:17:24] <lu_zero> or driving and paying attention to the trucks getting next to collide [19:17:26] <kshishkov> lu_zero: the third is more fun [19:17:26] <lu_zero> ^^ [19:17:54] * kshishkov had done a lot of RE at lectures [19:18:09] <lu_zero> wbs: it doesn't change s->start_time [19:18:58] <wbs> lu_zero: no, but it changes pts of returned packets from starting at 0 previously, to starting at any arbitrary time nowadays [19:19:22] <lu_zero> wbs: hmm [19:19:29] <lu_zero> I'll check soon [19:19:31] <lu_zero> now dinner ^^ [19:20:07] <wbs> lu_zero: the reason being, previously, we mapped pts=0 individually in each rtp stream to the first rtcp sender report for that stream [19:20:13] <BBB> seems to me like start_time computation overflowed [19:20:17] <BBB> possibly because it's negative [19:20:23] <BBB> no memory corruption otherwise [19:20:49] <wbs> lu_zero: ... which is fine as long as all the streams get the first rtcp at the same time, but BBB had some case where that wasn't the case, leading to pts=0 mapping to completely different times for each stream [19:23:01] <wbs> the simple solution was to remove the subtraction of the timestamp of the first rtcp packet completely, making pts start at any arbitrary point, but them always being correctly synced [19:23:23] <wbs> the more complex solution would be to map all streams to pts=0 when the first rtcp is received for any stream [19:24:16] <BBB> av_update_stream_timings() changes it [19:24:39] <BBB> -816347045215744 [19:24:41] <BBB> weird value [19:24:52] <kshishkov> looks loke nopts [19:24:53] <BBB> looks like a bug in that function (overflow) [19:24:55] <BBB> no [19:24:57] <BBB> that's -9... [19:25:05] <BBB> -9223372036854775808 [19:25:27] <BBB> so look at that function [19:25:33] <BBB> lu_zero: ^^ [19:27:32] <DonDiego> libavutil/error.c:38:5: warning: "HAVE_STRERROR_R" is not defined [19:27:40] <DonDiego> (from mplayer) [19:27:44] <DonDiego> what's going on? [19:27:50] <DonDiego> ffmpeg is trying to replace libc now? [19:28:03] <kshishkov> it's not in standard [19:28:37] <mru> it's in the standard, but it's optional [19:28:54] <kshishkov> i.e. not so standard [19:29:05] <mru> incorrect [19:29:11] <mru> it's standard, just optional [19:29:19] <mru> _if_ it exists, it's defined what it does [19:29:33] <mru> but there's no promise it'll exist [19:32:05] <BBB> lu_zero, wbs: also [19:32:06] <BBB> (gdb) print ic->streams[0]->start_time [19:32:06] <BBB> $8 = -73471195502672 [19:32:06] <BBB> (gdb) print ic->streams[1]->start_time [19:32:07] <BBB> $9 = -73471195549214 [19:32:10] <BBB> weird... [19:32:22] <kshishkov> printf in hex [19:33:09] <wbs> BBB: like I said, due to rev whateveritwas, the packets pts will start at (whatever random value) depending on the NTP timestamp of the first RTCP [19:33:19] <wbs> and that's what gets stored in those fields, right? [19:33:42] <BBB> probably [19:33:52] <BBB> but the values a are a little wacky [19:34:01] <BBB> might want to check that there's no overflow there already [19:48:40] <Vitor10011> BBB: just saw your message [19:49:51] <Vitor10011> I'm fine with making ff_acelp_apply_order_2_transfer_function() get one input and one output if it does not do any supplementary operations [19:50:05] <Vitor10011> And it works fine for in == out [19:50:28] <Vitor10011> And that in can be equal to out be documented in the doxy [19:50:45] <BBB> I'll document it as such [19:50:57] <BBB> and yes I'm not changing the function, so in==out will work [19:54:35] <Vitor10011> So fine for me [19:54:47] <BBB> thanks [20:24:56] <nfl> join #beagle [20:25:06] <nfl> sorry.. [21:06:49] * lu_zero is back [21:07:55] <lu_zero> hmm [21:14:45] <lu_zero> we might parse the rtpinfo [21:15:01] <lu_zero> (if you didn't find something to solve both issues [21:15:11] <lu_zero> BBB: which were the problematic cases? [21:16:14] <BBB> utils.c does some wacky stuff, possibly because our start_time is random and it overflows when rescaling it [21:17:43] <lu_zero> BBB: our start_time is - [21:17:46] <lu_zero> err [21:17:47] <lu_zero> 0 [21:17:56] <BBB> yes [21:18:01] <BBB> but the rtp stream is non-zero [21:18:03] <lu_zero> but our packet time right now is whatever... [21:18:17] <lu_zero> which was the problem you had? [21:18:17] <BBB> and utils.c then recalculates AVFormatCtx->start_time based on AVStream->start_time [21:18:25] <lu_zero> meh [21:18:30] <BBB> no problem, I was trying to help you why it had a weird value [21:18:32] <lu_zero> understandable [21:18:34] <BBB> that's why ;) [21:18:49] <lu_zero> I mean what cause this patch introduction? ^^ [21:19:00] <BBB> oh [21:19:16] <BBB> a/v sync issues between rtp streas [21:19:26] <lu_zero> do you have a sample of them? [21:19:34] <BBB> not publically :( [21:19:48] <BBB> but luca A had the same experience, and so had some others, I had it with axis cameras serving h264/aac over rtp [21:19:56] <BBB> the patch fixed it [21:19:58] <BBB> so we applied it [21:20:15] <BBB> I sort-of knew it'd set random start-times but decided to not care too much [21:20:17] <BBB> maybe that's bad [21:20:25] <BBB> av_rescale() should better handle this though :( [21:21:35] <lu_zero> well that breaks seeking [21:21:41] <lu_zero> completely ^^; [21:21:54] <lu_zero> before it was just half broken ^^ [21:22:14] <lu_zero> the problem happens on pure rtp or rtsp as well? [21:24:04] <BBB> rtsp [21:24:12] <BBB> sorry I broke seeking :( [21:24:16] <lu_zero> we are ignoring rtp-info [21:24:24] <lu_zero> my fault for not testing it before ^^; [21:24:26] <BBB> I think av_rescale() overflows [21:24:41] <BBB> it's supposed to scale the timestamps rightly for us [21:24:45] <BBB> so that for the app, it starts at zero [21:24:48] <BBB> but it doesn't do that [21:24:49] <BBB> ... [21:25:40] <lu_zero> hmm [21:25:56] <lu_zero> reverting the patch makes us sending something correct [21:26:01] <lu_zero> now [21:26:13] <lu_zero> we do not parse the RTP-Info: field [21:26:17] <lu_zero> I think [21:26:29] <sander> Do anyone know where the ffmpeg mailing lists are hosted? [21:26:49] <lu_zero> mphq [21:26:50] <lu_zero> why? [21:27:54] <sander> Because me and 6 other friends is about to start a new python ffmpeg batch encoding tool also with php web admin interface.. [21:28:13] <sander> ..And we are looking for a mailing list like yours. [21:28:29] <lu_zero> if is python wouldn't make more sense have it made in pylons? [21:28:42] <lu_zero> (or any wsgi compatible framework?) [21:28:58] <sander> We will make it command line. [21:29:06] <lu_zero> http://ffmpeg.org/contact.html [21:29:07] <lu_zero> ah [21:29:17] <lu_zero> so you aren't going to redo the bindings ^^; [21:29:26] <sander> and use that command line in the php web admin interface. [21:29:55] <sander> lu_zero, which bindings? [21:30:10] <lu_zero> python bindings to libav [21:30:32] <sander> I have no idea what that is. [21:30:50] <lu_zero> ffmpeg libraries have bindings in many languages [21:30:55] <sander> Cool. [21:31:12] <sander> Where can I download the python bindings? [21:31:21] <lu_zero> to my knowledge there aren't pure cpython bindings around... [21:31:23] <lu_zero> let me check [21:32:55] <lu_zero> http://fobs.sourceforge.net/index.html should have the python ones among the others... [21:33:41] <lu_zero> BBB: _probably_ parsing and mapping the offset the RTP-Info should provide would fix your issues [21:33:50] <lu_zero> ops, too late =_= [21:34:54] <sander> lu_zero, if I'm going to use this bindings, does ffmpeg needs to be installed from source then? [21:35:19] <sander> ..unless I some how get my package into some distros [21:35:44] <lu_zero> no idea [21:35:58] <lu_zero> I do not develop those bindings [21:36:05] <lu_zero> probably there are other as well [21:36:52] <sander> You dont know how to use the bindings?.. if the bindings only call ffmpeg.. or if they are apart of ffmpeg source? [21:38:54] <sander> I'll find out. [21:40:21] <sander> Too complicated installation process.. [21:40:25] <sander> Cant use it. [21:41:17] <sander> Works good to just call ffmpeg from the command line. [21:42:48] <sander> Anyway.. lu_zero: do you know if its possible that ffmpeg can host our mailing list? [21:44:16] <sander> We can always wait untill we've made the first alpha version tho.. [21:47:02] <lu_zero> sander: I doubt it [21:47:40] <thresh> i do have patches in ffmpeg indeed, weird (i was checking for my CV) [21:53:03] <lu_zero> thresh: ? [21:53:49] <wbs> lu_zero: patch sent that shows my solution suggestion for the start time sync problem - ugly but should work [21:54:06] <wbs> but I guess we'd need BBB to test if it actually still fixes his sync issue [21:54:34] <thresh> lu_zero: well, i could only find patch from 2006. That's why i couldnt remember which one of those i sent actually made it into mainline. [22:31:29] <BMintern> Vitor10011: i'm lost [22:31:39] <BMintern> i have clone finished, but it's clearly not right :-\ [22:33:48] <BMintern> well, i'm going to write up an e-mail (with a link to what i have so far) to ffmeg-soc. hopefully someone there can point me in the right direction [22:42:01] <CIA-24> ffmpeg: darkshikari * r22695 /trunk/ffpresets/ (12 files): [22:42:01] <CIA-24> ffmpeg: Use the newly available x264 parameters in ffmpeg in the x264 preset files. [22:42:01] <CIA-24> ffmpeg: Patch by Lou Logan. [22:47:37] <CIA-24> ffmpeg: stefano * r22696 /trunk/cmdutils.c: Use av_strerror() in print_error(). [23:15:15] <astrange> i introduced a perian bug by being compatible with ffmpeg -i .vob -vcodec copy .mov :/ [23:15:38] <astrange> seems like streamcopy to mov doesn't set DTS properly for lots of things, not just h264 [23:15:43] <ohsix> hur [23:16:23] <ohsix> astrange: my bug got _some_ love; some dupes point at it now (the unreleased unused frames thing)

1 0

IRC log for 2010-03-25
by irc＠mansr.com 26 Mar '10

26 Mar '10

[00:42:46] <CIA-24> ffmpeg: stefano * r22664 /trunk/libavdevice/oss_audio.c: [00:42:46] <CIA-24> ffmpeg: Make audio_read_packet() return AVERROR_EOF rather than AVERROR(EOF) = [00:42:46] <CIA-24> ffmpeg: AVERROR(-1) = 1. [02:40:03] <BMintern> hello. i see someone recently updated libavfilter (changing vf_overlay.c)... [02:40:19] <BMintern> when i try to run "./checkout.sh", the patch is failing [02:41:02] <BMintern> any ideas? [02:45:45] <Dark_Shikari> so, for those here [02:45:58] <Dark_Shikari> I just got a mail from a company offering big $ for anyone who RE'd prores [02:46:01] <Dark_Shikari> Who should I tell them to talk to? [02:48:01] <peloverde> kostya? [02:48:12] <Dark_Shikari> anyone else? [02:48:12] <Dark_Shikari> BBB? [02:48:36] <Dark_Shikari> in their words: "big fat contract" [02:59:13] <Compn> Dark_Shikari : look who wrote on prores page in wiki ? [02:59:40] <Compn> oh nm, no one re'd it yet [03:00:02] <Compn> 'maxpol' ? [03:00:07] <Compn> maxim :) [03:00:21] <Compn> aka indeo 4/5 guy [07:14:11] <CIA-24> ffmpeg: mstorsjo * r22665 /trunk/libavformat/ (sdp.c rdt.c utils.c internal.h): Add a lowercase parameter to ff_data_to_hex [07:15:31] <CIA-24> ffmpeg: mstorsjo * r22666 /trunk/libavformat/utils.c: Reindent [09:26:52] <astrange> do av_crop_uint8 and ff_cropTbl both need to exist? [09:27:05] <kshishkov> yes [09:27:21] <kshishkov> their intended use differs [09:48:23] <DonDiego> http://wurstball.de/static/ircview/pictures/749cd15bf9d0254286148f468567b29… [09:48:25] <DonDiego> rotfl [09:49:48] <andoma> :) [09:50:27] <av500> fefe ftw [09:58:01] <thresh> oh, a new version. [11:06:20] <KotH> do we have any embedded linux developers here (for comercial, customer specific development)? [11:06:44] <merbzt1> ->mru [11:07:19] <KotH> he isnt awake yet ;) [11:07:44] <kshishkov> nevertheless [11:08:18] <KotH> aren't there any other? [11:08:27] * KotH thought we have 3-5 of them around ffmpeg [11:08:32] <av500> depends on the price :) [11:09:13] <kshishkov> maybe a clone of mru [11:09:31] <av500> KotH: is the tender public? [11:09:32] <kshishkov> and that __troll__ guy [11:09:37] <KotH> av500: nope [11:09:40] <av500> ah [11:10:10] <KotH> well... background is, we have a _poential_ customer who wants an embedded linux system and needs it quickly [11:10:29] <KotH> (series production within 9 months, no hardware available yet) [11:10:39] <kshishkov> give him gentoo ;) [11:10:48] <av500> KotH: sounds doable [11:10:52] <KotH> and i'm looking for ways to bootstrap the development as fast as possible [11:11:02] <av500> and the hw is? [11:11:14] <av500> PIC or XEON? [11:11:26] <KotH> av500: it's only doable if 1) we get the contract now, 2) and we have someone who knows how to build a embedded linux system from scratch [11:11:44] <av500> lfs ftw [11:11:53] <av500> KotH: what cpu? [11:11:56] <KotH> av500: atm, the plan goes for an arm9 based system for linux and an arm7 for the realtime stuff [11:12:11] <KotH> (to avoid the need of using a real time linux) [11:12:29] <av500> depending an what you need to realtime, you dont need rt linux [11:12:54] <KotH> sensor input to actuator motion within <10ms [11:13:13] <av500> run it besides the kernel on the same arm [11:13:31] <KotH> what do you mean? [11:14:28] <av500> we did something like that for an IR reciever, linux irq latency was way to long to sample the IR code, so we hooked it to FIQ and linux kernel did not know anything about it [11:14:59] <av500> it only got the decoded IR msg through some mailbox registers [11:15:11] <KotH> you mean, you made a "driver" that hooked into FIQ and provided the kernel with the data? [11:15:19] <av500> yes [11:15:29] <av500> kernel was in IRQ and we were in FIW [11:15:33] <av500> FIQ [11:15:41] <av500> so we had priority [11:15:48] <DonDiego> av500: you saw the article on fefe's blog? hilarious and oh so true... [11:15:53] <av500> yes [11:16:23] <KotH> av500: problem here: high sampling rate measurement -> lots of FIQs -> kills performance on the cpu [11:16:38] <KotH> DonDiego: what article? [11:16:52] <av500> http://blog.fefe.de/?ts=b5546b0c [11:17:23] <KotH> i'd be glad if you just had an interrupt source that tells us when we have to switch, but it's actually based on sensor input with a software/runtime defined limit [11:18:10] <av500> KotH: well, if you cannot preprocess the irq stuff to a more moderate level, then I guess you have to burn another CPU for it... [11:18:27] <KotH> juup [11:18:38] <KotH> well.. i first have to get more accurate specs from the customer [11:18:51] <av500> anybody con do it with accurate specs :) [11:19:10] <KotH> atm we have only "we want something that works within half a year" [11:19:21] <av500> I am sure they will know what they want once you built it... [11:20:15] <KotH> originally it was only about HW (processor board with sensor/actuator interface). but no requirements given but the most basic ones (10 sensors, 20 actuators,...), no exact spec how the sensors look like, no spec what the software should do,... [11:20:16] <av500> for the arm9 side something like oe/angstrom can spare you the "from scratch" part [11:21:20] <av500> maybe you should hire an "oracle" [11:21:29] <KotH> an oracle? [11:22:22] <av500> einen hellseher [11:22:56] <KotH> nah.. i'm currently writing a long mail asking for various things [11:23:10] <KotH> but my knowledge in the area of embedded linux is kind of limited [11:23:17] <av500> it is like linux [11:23:26] <KotH> so, i'm trying to guestimate things from my basic linux knowlege [11:26:24] <av500> if you do all the RT stuff on the arm7, then the arm9 linux can be pretty standard.. [11:26:33] <KotH> yes [11:26:44] <av500> but yes, detailed specs would help: ) [11:26:53] <KotH> though, i'm not worried about user space stuff. as soon as i have a kernel running i know how to handle it [11:27:14] <KotH> the big question is whether we need to write any drivers for the hw and how much time that needs [11:27:14] <av500> running linux on an arm9 is not rocket surgery any more these days [11:27:27] <av500> I guess you need a driver to talk to the arm7 [11:27:41] <av500> unless you connect it with an uart :) [11:27:49] <KotH> not if we can do it as an RS232 or so :) [11:28:03] <av500> I2C :) [11:28:04] <KotH> or i2c or spci... [11:28:08] <KotH> lol [11:28:10] <KotH> gtma :) [11:28:20] <KotH> s/tm/mt/ [11:28:28] <av500> :) [11:32:12] <twnqx> KotH: did you ever design with PCIe? :P [11:33:42] <av500> twnqx: ah, that slow stuff [11:34:05] <twnqx> slow stuff? [11:34:07] <KotH> twnqx: nope [11:34:10] <twnqx> i'm satisfied with it [11:34:15] <twnqx> too bad [11:34:35] <KotH> twnqx: we hardly ever need such fast connections, and if we need them, then pci-e is too slow [11:34:52] <av500> see, slow! :P [11:35:21] <kshishkov> pci-e keyboard? [11:35:30] <twnqx> i'm looking at around ~150MB/s crypto throughput :P [11:36:03] <kshishkov> firewire? [11:36:11] <KotH> atm we are developing a system that uses up to twelve ccd chips and transferes the raw data over wires on an MID substrate -> no chance for pci-e with it's strict requirements [11:36:30] <KotH> twnqx: private or comercial? [11:37:03] <twnqx> first for me [11:37:07] <twnqx> if it works, why not sell it [11:38:45] <KotH> well.. you see... private, i have no time to play with stuff like that... but if you would hire us, i'd have enough time :) [11:39:04] <KotH> but we aren't cheap [11:39:19] <KotH> (in both senses of the word) [11:40:43] <KotH> twnqx: btw: you dont need pci-e for 150-MByte/s [11:40:54] <KotH> twnqx: 64bit PCI should be enough [11:41:02] <av500> usb 3.0 ftw [11:41:02] <twnqx> yeah, but i won't design for obsolete interfaces. [11:41:11] <KotH> twnqx: if it isn't, go to 64bit@66MHz [11:41:17] <KotH> obsolete? [11:41:25] <KotH> you'd be surprised :) [11:41:27] <twnqx> yeah, i consider parallel PCI obsolete [11:41:40] <twnqx> my laptop has only mini-pcie and expresscard left [11:41:42] <kshishkov> next thing somebody will call RS232 obsolete [11:41:45] * KotH was designing stuff for PCMCIA not even two years ago [11:41:47] <twnqx> my htpc only mini-pcie [11:42:00] <twnqx> my desktop has loads of PCIe, but just one PCI [11:42:34] <twnqx> kshishkov: luckily even router vendors realise the death of rs232 [11:42:53] <twnqx> cisco e.g. implements an ACM TTY as usb client these days :P [11:44:06] <KotH> lol [11:44:18] <KotH> w/o rs232, the whole electronics development would be dead [11:44:39] <av500> KotH: they just slap on FTDIs everywhere [11:44:47] <av500> the cpus themselves still have uarts... [11:45:27] <twnqx> no, not FTDIs, but something similar [11:45:35] <twnqx> FTDIs do proper usb serial ports :P [11:45:42] <twnqx> not generic acm tty [11:46:09] <kshishkov> twnqx: usb = universal parallel bus, isn't it? [11:46:33] <KotH> av500: yeah.. [11:46:41] <av500> kshishkov: UnStable Bus [11:46:43] * KotH is glad his olimex programmer has an serial interface [11:46:50] <KotH> av500: stop using windows [11:46:59] <twnqx> KotH: what do you need the serial for, except for communicating with legacy devices? [11:47:00] * av500 needs only to look at his FTDIs to make them lock up [11:47:02] <KotH> av500: usb is working very well on linux [11:47:14] <av500> KotH: I know [11:47:18] <KotH> twnqx: uhm.. developing the software for the devices we build? [11:47:33] <twnqx> and you don't flash via JTAG/SPI? [11:47:37] <kshishkov> av500: I still prefer FireWire [11:47:40] <KotH> twnqx: lol [11:47:50] <twnqx> or use ethernet for communication? [11:47:53] <twnqx> :S [11:48:07] <KotH> twnqx: jtag is good for programming. even proper debuggin is a pain on most systems [11:48:22] <KotH> twnqx: being able to use an rs232 for debug output is a great help [11:48:25] <av500> KotH: you cant ssh into your PIC? [11:48:32] <KotH> nah.. [11:48:44] <KotH> not enough ram to hold the data needed for the tcp connection [11:49:03] <twnqx> which reminds me that i'm still pondering whether to buy that xilinx EDK or not... [11:50:29] <twnqx> *sigh* [11:50:42] <kshishkov> twnqx: may I point out that some interfaces may be slow since interfaced device is slow. Human, for example [11:50:55] <twnqx> this is not about speed [11:51:01] <twnqx> jtag/spi are slow too [11:51:43] <twnqx> it's more about usability, USB is a de-facto standard these days, RS232 is gone. i consider adding one of these "tiny usb" controllers to my designs [11:52:04] <twnqx> basically, an 8pin avr doing a software implementation of 12mbit USB :P [11:52:17] <kshishkov> yuck! [11:52:34] <av500> twnqx: thats were the FTDIs are nice, you have GIOs on usb... [12:25:55] <twnqx> av500: i have an fpga... just looking at usb endpoint implementations :P [12:28:11] <av500> twnqx: trivial, no? :) [12:28:44] <twnqx> almost :P [12:28:57] <twnqx> i think my choice of a 48MHz oscillator wasn't too bad... [12:36:29] <KotH> lol [12:36:43] <KotH> twnqx: how do you want to implement ch9 on the fgpa? [12:37:05] <twnqx> ch9? [12:38:12] <KotH> chapter 9 [12:38:20] <KotH> ie chapter 9 of the usb specs [12:38:49] <KotH> or do you use the fpga only as hw interface to a cpu ? [12:38:56] <twnqx> nah [12:39:09] <twnqx> (unless i buy EDK and go microblaze) [12:39:53] <KotH> so, you want to implement an usb device completely within the fpga? [12:39:58] <twnqx> yeah [12:40:05] <KotH> that'll be fun :-) [12:40:14] <twnqx> uh [12:40:25] <twnqx> opencores.org has usb cores... [12:40:37] <KotH> and what do those usb cores do? [12:41:11] <KotH> or to give you some perspective: i've been working on and off the last 1.5y on an usb framework for teh atmel sam7 uC's [12:41:15] <KotH> and i'm not finished yet [12:42:19] <KotH> if you know usb well, it'll be probably 2-3 man months to implement a usb framework and get a simple class like a com port working [12:42:23] <kshishkov> why "uC's" sounds like "really small capacitors"? [12:42:46] <KotH> kshishkov: that's uF... or rather pF ;) [12:43:19] <kshishkov> capacitors are marked as "C" on circuit schemes here [12:43:38] <kshishkov> and "LC" is not for "low-complexity" either [12:44:12] <twnqx> no, a coil-capacitor-filter :P [12:44:38] <KotH> kshishkov: uC = \mu C in non-ascii writing = micro controller [12:45:00] <kshishkov> I suspected that [12:45:18] <twnqx> hm. [12:45:24] <KotH> kshishkov: maybe you should learn some electronics :) [12:45:49] <kshishkov> oh, I did [12:45:56] <av500> kshishkov: you can RE electronics too :) [12:46:07] <KotH> let me guess, everything was written in kyrilic? [12:46:42] <kshishkov> almost [12:47:10] <kshishkov> we still use Latin letters for electronic part names [12:49:45] <kshishkov> I don't think we've made past op-amps at electronics [12:50:32] <kshishkov> though we also another couse in electronic design and we had to make CPU model for project on that [12:50:57] <KotH> eh.. [12:50:58] <kshishkov> *course [12:51:05] <KotH> you know that you cannot learn electronics design at school? [12:51:13] <KotH> unless you have a very very good school... [12:51:15] <twnqx> depends [12:51:37] <kshishkov> well, even "very good school" does not apply here [12:52:06] <twnqx> but yeah, unless you get your hands on the stuff during school... you're in a bad shape indeed [12:52:16] <KotH> twnqx: even if you do [12:52:19] <twnqx> and few schools have the financial resources to do that [12:52:25] <KotH> twnqx: most schools are just too short to teach you the art [12:52:43] <KotH> twnqx: they can give you the basics, but to become half way decent, you have to teach it yourself [12:53:08] <twnqx> well, if i'd ever need more of those small FPGA boards than i have now, i'd make some changes [12:53:22] * KotH was at a uni that had the financial resources to let students build their own asic, but still didnt learn much about electronics design there [12:53:32] <kshishkov> KotH: in our case it was not intended even for bootstrapping [12:53:49] <KotH> kshishkov: it? bootstrap what? [12:54:00] <kshishkov> more like horrible subject you need to pass to be called real student [12:54:01] <twnqx> what's there to learn? PCB layout for HF, the "black magic"? [12:54:14] <twnqx> layout for analog? [12:54:22] <kshishkov> KotH: yourself. With knowledge obtained at school. [12:54:49] <KotH> twnqx: even basic analog design [12:55:02] <KotH> twnqx: like, how to design a single transistor amplifier [12:55:03] <kshishkov> you should know - "here are basics, there are books, go and learn" [12:55:11] <twnqx> well yeah, i'm currently failing at that :P [12:55:39] <KotH> the furthest we got, was that one prof mentioned a miller capacitor [12:56:15] <twnqx> and i don't even want something like a linear amplifier. i just want a 2.5signal to turn on a 5V signal. [12:56:38] <twnqx> and i feel like that's only possible with a dual inverter setup. [12:56:49] <KotH> huh? [12:56:55] <kshishkov> huh? Schmidt trigger ftw [12:57:03] <KotH> bc548 and be done with it [12:57:18] <twnqx> meh, according to spice that doesn't work [12:57:22] <KotH> possible with a comparator if you need a level detection [12:57:26] <twnqx> nah [12:57:49] <twnqx> hm 548 [12:57:56] <KotH> uhm... if you use spice, you have to know what you simulate [12:58:03] <KotH> otherwise you'll get a lot of crap output [12:58:11] <KotH> spice is a typical GIGO system [12:58:17] <twnqx> true that [12:58:52] <KotH> and even if you used the right input, chances are high that the simulation results are still crap [12:59:54] <twnqx> looking at the first 548 schematic... that's exactly what i used to 547s for >_> [12:59:58] <twnqx> two* [13:00:27] <twnqx> i mean, i know why i failed at the first attempts, once i remembered the operations of transistors :P [13:00:37] <KotH> 547s and 548s are nearly the same transistor anyways :) [13:00:56] * twnqx looks at the spice schematic again [13:00:57] <KotH> and both are debrecated ;) [13:01:05] <twnqx> sure, but still available [13:01:09] <KotH> use 847 and 848 instead :) [13:01:22] <kshishkov> guess what country still produces vacuum lamps ;) [13:01:37] <KotH> ofc, because of all the tinkerers who dont know any better [13:02:49] <twnqx> hm [13:03:04] <twnqx> 847 is not available in leaded... just SMD [13:03:13] <kshishkov> no, there's a special class of idiots who thinks lamps are better and want to pay any sum of money for them [13:04:20] <KotH> twnqx: lol [13:04:32] <KotH> twnqx: nobody uses leaded stuf for small fry like that anymore ;) [13:04:44] <twnqx> if i'd go make a PCB - no [13:05:15] <KotH> kshishkov: actually, there are places where normal lamps are better [13:05:28] <twnqx> like.. everywhere? [13:05:47] * twnqx dislikes the idea of more toxic things to accidently break around him [13:05:49] <KotH> twnqx: making a pcb is cheap these days [13:06:12] <twnqx> it's not the 2€ i pay for a copper strips board unless i make it myself [13:06:13] <kshishkov> KotH: of course, wanna get a delivery? [13:06:29] <twnqx> and there i'm too lazy [13:07:23] <KotH> twnqx: if you have just handfull of discrete components, that's enough [13:07:31] <twnqx> also, i'm still using breadboards :P [13:07:35] <KotH> twnqx: for anything else, i'd make a pcb [13:07:39] <twnqx> yeah [13:07:42] <twnqx> agreed :) [13:07:46] <KotH> breadboards? with fpgas? [13:07:52] <twnqx> lol no [13:08:03] * KotH knows people who'd do that [13:08:03] <twnqx> though my PCB could be used to plug that in :] [13:08:34] <twnqx> it's not for no reason that the 40 I/O pins exactly fit in a standard 2.54mm socket.. [13:11:42] <KotH> http://en.wikipedia.org/wiki/Inversion_of_control <- could someone explain me what's written there? i dont understand anything but "we want an abstraction" [13:12:30] <kshishkov> let me see, I know many buzzwords [13:15:02] <kshishkov> sounds like usual management here - task is simply passed from highest level to lowest worker unchanged who has to make something out of it and comply [13:15:08] <mru> KotH: I see java and patterns mentioned [13:15:11] <mru> ergo, it's rubbish [13:15:20] <mru> and factory [13:17:07] <KotH> for me it sounded like the usual way of defining APIs for lower level stuff [13:17:19] <mru> oh god, they've invented something so abstract they don't even know what it is [13:17:24] <KotH> and layering everything [13:17:25] <kshishkov> someone should ban use of word "patterns" in such cases so those CS theorists will go in search of real work [13:17:29] <mru> "It is still undecided if Inversion of Control is a design pattern, ..." [13:18:01] <kshishkov> KotH: not layering alone but delegating [13:22:10] <KotH> kshishkov: hmm.. for me layering implies delegation [13:22:21] <KotH> if you dont delegate, then layering doesnt make sense [13:22:26] <kshishkov> KotH: http://img-fotki.yandex.ru/get/3309/turboblog.0/0_50c7_99d05bc4_XL.jpg - here's only low layer has any control on everything :) [13:22:29] <KotH> unless i misunderstand what delegation means [13:22:54] <kshishkov> IoC means delegation without decision [13:23:22] <mru> the step from ioc to ioccc ain't big... [13:23:35] <KotH> kshishkov: that pic is originally german ;) [13:23:42] <kshishkov> you just push whole task down and at that level it decides what part of that task was intended for it [13:24:03] <KotH> oh.. [13:24:07] <KotH> now i get it [13:24:09] <KotH> ok... [13:24:14] <kshishkov> KotH: not necessarily. It's quite Russian in spirit [13:24:17] <KotH> mru: you're wrong [13:24:20] <KotH> mru: it's not crap [13:24:25] <KotH> mru: it's _CRAP_ [13:24:29] <kshishkov> ioccc is art [13:25:33] <mru> is ioc that style where you can be searching for a week without finding the code that _actually does anything_ [13:26:04] <kshishkov> but you can be sure that it's not in the first files you see [13:27:21] <kshishkov> reminds me of aspect-oriented programming (aka wishful thinking) [13:28:15] <mru> http://daringfireball.net/2010/03/on_submarine_patents [13:28:19] <mru> kshishkov: isn't that haskell? [13:28:49] <kshishkov> I've heard about that from Java dev [13:29:42] <mru> for all it flaws, there are actually big, working apps written in java [13:29:48] <mru> you can't say that about haskell [13:30:17] <jai> xmonad [13:30:19] * jai hides [13:30:40] * kshishkov remembers his prof saying that programming is not an art anymore because of those development strategies [13:32:50] <kshishkov> I'm glad they have not mentioned patterns at all during CS courses [13:33:21] <twnqx> pattern aren't bad [13:33:31] <kshishkov> they are buzzword [13:33:36] <twnqx> it's like my first algorithm and data structures lessons [13:33:47] <twnqx> "oh, THAT'S the name for what i invented for myself" [13:34:05] <twnqx> it's a neat way to use common names for things [13:34:07] <mru> patterns are good for describing things [13:34:10] <mru> not for designing thing [13:34:11] <mru> s [13:34:23] <KotH> i'd disagree [13:34:28] <twnqx> many things you design folow the same patterns [13:34:32] <mru> yes [13:34:32] <twnqx> follow* [13:34:34] <kshishkov> you'll get philosophy next [13:34:48] <mru> but that doesn't mean you should force every design into one of a few pre-defined patterns [13:34:51] <twnqx> forcing everything into a limited set of pattern obviously fails [13:34:56] <twnqx> :] [13:34:58] <mru> and that's what they do [13:35:00] <KotH> it's good to know a bunch of patterns you can choose from, but not to design by trying to use a certain pattern and make it fit to your prob [13:35:15] <kshishkov> twnqx: no, that depends on your power [13:35:32] <twnqx> heh [13:35:58] <KotH> kshishkov: coding has nothing to do with dragon balls! [13:36:08] <mru> you design using a _strategy_, and a pattern will emerge [13:36:14] <mru> the opposite does not happen [13:36:34] <KotH> knowing patterns help to find your strategy :) [13:36:41] <mru> maybe [13:36:53] <KotH> .o0(when we've finished bow, we should write a book on programming) [13:36:55] <mru> but again, that is not what they teach [13:36:59] <KotH> nope [13:37:10] <KotH> actually, they dont teach programming at all [13:37:25] <KotH> you're in a "good" uni if they teach you patterns [13:37:29] <mru> they did in a few classes I took [13:37:36] <mru> but they were not taught by CS dept [13:37:45] <KotH> YOU'VE BEEN TAINTED!! [13:37:49] <KotH> ;) [13:38:18] <mru> they made us write things like memory allocators and task schedulers [13:38:31] <mru> and pipelined instruction scheduling [13:38:53] <twnqx> KotH: back on the 548... it would invert the single, wouldn't it? [13:39:04] <twnqx> signal* [13:39:19] <twnqx> not that that would be an issue [13:39:47] <twnqx> hm well... on the other hand, it would be... i need 5V or nothing, not 5V or GND [13:40:13] <mru> nothing? [13:40:17] <mru> Z-state? [13:40:23] <kshishkov> KotH: local joke - "military IQ tests (put object of certain shape into a hole with the same shape) have divided soldiers into two groups - very dumb and very strong" [13:40:36] <twnqx> high impedance would be a working term, yes [13:41:22] <kshishkov> so just use threshold cutoff on buffer control port ;) [13:41:22] <twnqx> i need to be able to turn off some pullup resistorsto stop influencing the line [13:41:47] <mru> look for parts with tristate outputs [13:41:56] <mru> what kind of parts are we talking about here? [13:42:09] <twnqx> the output of some level shifters :P [13:42:24] <mru> tristate level shifters... never heard of that [13:42:31] <twnqx> oh, they are [13:42:39] <twnqx> but it's kind of a loopback test [13:43:15] <twnqx> with some lines driving a LCD at the same time - the LCD need 5V, so there are pullups [13:43:25] <twnqx> for the loopback tests the pullups need to be disabled [13:51:55] <BBB> my connection is apparently not that great [13:53:00] <kshishkov> use dialup ;) [13:53:22] <kshishkov> and maybe it was bad idea to go via IPv6 [13:53:42] <BBB> ? [13:53:45] <BBB> I'm on ipv6? [13:53:48] * BBB had no idea [13:53:49] <kshishkov> you was [13:53:58] <kshishkov> 15:41 -!- BBB [~BBB@2002:8cfb:2314:8:216:cbff:fe8d:def0] has joined #ffmpeg-devel [13:54:13] <BBB> awesome! \o/ [13:54:21] <kshishkov> now it shows your usual uni address [13:54:22] <BBB> but it doesn't work, so screw ipv6 [13:54:44] <merbzt1> yeah who needs that [13:54:51] <kshishkov> CISCO? [13:54:54] <merbzt1> ipv4 4tw [13:54:57] <wbs> BBB: well, in 10 years perhaps ipv6 will be mature and ready to be used ;-) [13:54:59] <BBB> superdump: could you reply to marcelo's email on the list? [13:55:33] <BBB> if cisco wants to sell, maybe they should create products that A) do not infringe on everyone's GPL copyrights, and B) products that are actually novel, innovative and high-quality [13:55:46] <BBB> was it cisco that bought kiss? [13:56:09] <BBB> yes it was, linksys and thus cisco [13:56:46] <superdump> which list? [13:56:52] <BBB> ffmpeg-devel@ [13:57:06] <BBB> Marcelo Galvao Povoa [13:57:09] <BBB> wants to do amrwb decoder [13:57:13] <BBB> you're suggested mentor for that [13:57:15] <BBB> I think [13:57:18] <superdump> aha [13:57:22] <superdump> yes, i am [13:57:39] <BBB> he's asking for a qual task [13:57:50] <BBB> he sounds like he might be suited for the job [13:58:58] <superdump> mmm [13:59:01] <superdump> so i see [13:59:19] <CIA-24> ffmpeg: mstorsjo * r22667 /trunk/libavformat/ (httpauth.h httpauth.c): Add support for http digest authentication [13:59:31] <KotH> twnqx: use a 558 and high-side switching [13:59:49] <BBB> wbs: sorry about the method/uri thing, but I dislike the splitting a bit [14:00:23] <BBB> and yay for digest auth [14:00:26] <BBB> I've wanted that for long [14:00:30] <BBB> add a changelog entry please [14:00:39] <wbs> ah, yeah. minor bump, too? [14:00:45] <BBB> don't know [14:00:57] <wbs> BBB: and no problem with the method/uri thing, i agree that it's fugly [14:01:01] <KotH> twnqx: and while you are at it, buy the tietze-schenk [14:01:06] <KotH> twnqx: you need it [14:01:12] <twnqx> nah [14:01:13] <BBB> koth: did you install the cms? [14:01:19] <KotH> BBB: no time yet [14:01:19] <twnqx> i don't do analog deisgn usually :X [14:01:22] <BBB> ok [14:01:31] <superdump> gah tb3 crashed while i was responding [14:01:36] * KotH is fighting against customers and an s6 code he wrote in a hurry [14:01:49] <KotH> BBB: i hope i can do it on sat/sun [14:01:58] <KotH> BBB: no guarranties though [14:02:14] <KotH> BBB: you can try to pester mru or diego too ;-) [14:02:30] <CIA-24> ffmpeg: mstorsjo * r22668 /trunk/Changelog: Add a changelog entry for http digest auth [14:02:33] <wbs> BBB: do you prefer keeping the current approach with specifying a full "cmd" buffer, including the method/uri, or should the method/uri be factored out from the cmd buffer and only provided separately? [14:03:29] <BBB> KotH: ok [14:04:22] <BBB> wbs: I think we already copy into a new buffer in that ff_rtsp_send_cmd_with_content_async() function, so I'd say just provide method/uri separately and have send_cmd_..() construct the full thing [14:04:35] <BBB> it sounds a little more sane also [14:04:52] <wbs> BBB: ok.. will give it a try, but it may take until tomorrow :-) [14:05:13] <BBB> that's ok [14:05:24] <BBB> then I can review some other patches in the mean time ;) [14:05:29] <wbs> exactly ;-) [14:06:10] <BBB> or, god forbid, actually code myself :) [14:11:43] <BBB> wbs: can you confirm that with that patch, the binary does not change md5? [14:12:13] * BBB wonders if the compiler will put a terminating 0 in some random unallocated memory location [14:14:14] <wbs> BBB: it does change here, but I think it should be ok anyway. perhaps with making the length 17 (or just []) would be even safer [14:14:32] <BBB> I'm hoping to prevent wasting that extra byte ;) [14:14:47] <wbs> ah. ;-) [14:14:48] <BBB> I'm wondering how it changes [14:35:09] <CIA-24> ffmpeg: jai_menon * r22669 /trunk/libavformat/matroskaenc.c: Matroska muxer : Don't create audio tracks for unsupported audio codecs. [14:35:52] * KotH curses at customers [14:36:01] <kshishkov> :) [14:36:17] <KotH> why are they silent for most of the year and the resurface all at the same time with something very urgent? [14:36:20] <justlooking> KotH> and what do those usb cores do? < http://www.opencores.org/project,usbhostslave apparently it still needs a little work though... [14:38:38] <KotH> justlooking: that's chapter 7 and part of chapter 8, no chapter 9 [14:38:45] <kshishkov> KotH: in my experience what customers have is either urgent or can be neglected [14:39:18] <KotH> kshishkov: ack [14:39:32] <KotH> justlooking: ie, you still need some controller who controls the endpoings [14:39:38] <KotH> endpoints [14:40:00] <KotH> justlooking: and there is still no class done if you have chapter 9... [14:40:25] <KotH> justlooking: ie, what you call "little work" is quite a bit of work [14:40:52] <twnqx> justlooking: it also has a wishbone interface, so i expect it needs some CPU [14:41:24] <twnqx> but i'd need to actually read chapter 9 to fully judge :] [14:41:51] <KotH> twnqx: reading is no problem, understanding all implication though is one ;) [14:42:09] <twnqx> bah, it can be dirty and limited [14:42:16] <twnqx> it just needs to work somehow ™ [14:42:21] <KotH> twnqx: if you want to do some usb stuff, get yourself a copy of "usb complete" by axelson [14:42:31] <KotH> lol [14:42:55] <KotH> usb isnt rs232, you cannot just make a dirty hack and hope it'll work [14:42:56] <twnqx> right now i'm trying to figure the difference between bc558, bc558a, bc558b and bc558c >_> [14:43:02] <KotH> especially not if you try to interface windows [14:43:09] <twnqx> well, you know the tiny i2c? [14:43:14] <twnqx> ah, winblows [14:43:17] <twnqx> no, i won't [14:43:22] <twnqx> i refuse to program on it [14:43:34] <KotH> interfacing with linux is easier, at least linux tells you what it doesnt like about the device [14:43:44] <KotH> twnqx: you'll need windows anyways... [14:44:00] <KotH> twnqx: download the usb compliance tester code from intel [14:44:02] <twnqx> to jump out after trying to understand the usb spec? [14:44:15] <KotH> twnqx: it runs only on windows, but tells you a lot about your device and what it is doing wrong [14:44:35] <twnqx> hm [14:44:41] <KotH> oh.. and get a beagle 480 too... you'll need it ;) [14:45:10] <twnqx> http://www.harbaum.org/till/i2c_tiny_usb/index.shtml <- run against that [14:45:19] <justlooking> there are others there too, search on "usb" there and you see several. [14:46:28] <KotH> twnqx: looks nice [14:46:39] <KotH> twnqx: if you can use one of those instead of building your own usb device... use that [14:46:57] <KotH> twnqx: even interfacing an ftdi with high speed serial is simpler [14:47:00] <KotH> and prolly cheaper [14:47:09] <KotH> usb is a fucking beast of a protocol [14:47:16] <twnqx> it's based around some GPL usb stack [14:47:19] <twnqx> with no endpoint [14:47:29] <KotH> rotfl [14:47:35] <KotH> every usb device has at least one endpoint [14:47:46] <KotH> otherwise it is no usb device ;) [14:47:47] <twnqx> http://www.obdev.at/products/vusb/index.html [14:47:54] <twnqx> yeah, but this is just the software core :P [14:48:45] <twnqx> as in, you can implement yourself if you want more than just i2c - the i2c one is just an example using it [14:49:23] <KotH> rotfl [14:49:27] <KotH> that device is cool [14:49:35] <jai> on an related note, why isn't the h.264 timestamps related gsoc task not mentioned on the wiki? [14:49:55] * KotH mentions that for proper operation, you have to be able to connect/disconnect the pull up resistor on DM/DP [14:50:34] <KotH> jai: maybe it's waiting for you to write an entry for it? :) [14:51:11] <twnqx> KotH: this is an example of "works mostly" :P [14:52:27] <jai> KotH: meh :) [14:52:32] <DonDiego> maybe you guys wish to move this to #wherever-this-chatter-is-ontopic [14:52:33] <DonDiego> :) [14:53:46] <thresh> there will be no purpose for having this channel then :p [14:55:01] <KotH> DonDiego: do you mean #pathscale? ;) [14:55:22] <jai> thresh: btw, has there been any discussion on the dvd audio support task you guys have on your wiki? [14:55:35] <jai> thresh: is there any reason that cant be done in fflibs/ [14:55:41] <thresh> personally i have no idea [14:55:43] <thresh> sorry [14:55:48] <jai> thresh: k [15:02:29] <kshishkov> jai: there is - they are now aware about lavf or lavd [15:02:36] <kshishkov> *not [15:14:58] <jai> kshishkov: lol [15:42:54] <kshishkov> jai: please translate http://lleo.aha.ru/na/en/ and I'll try to add it there so we have something to refer those potential GSoCers to [15:43:35] <jai> kshishkov: LMAO [15:43:38] <jai> kshishkov++ [15:43:45] <kshishkov> I'm deadly serious [15:47:47] <nfl> pl correct me if im wrong - if pixfmt is pal8 in a decoder, the palette is loaded in frame.data[1] and frame.data[0] is filled with indices to the palette for each pixel, right? [15:48:30] <kshishkov> correct [15:49:02] <nfl> are there any other nitty gritties I need to be aware of? [15:49:31] <kshishkov> palette format [15:49:53] <kshishkov> 256 32-bit entries of (R<<24) | (G << 16) | B [15:49:59] <kshishkov> IIRC [15:50:16] <kshishkov> it's usually stored in different form in files [15:50:51] <nfl> thanks [15:51:02] <kshishkov> np [15:51:57] <jai> i have to say BBB is a _very_ patient man :) [15:52:09] <BBB> huh? [15:52:16] <BBB> oh, regarding that guy? [15:52:26] <jai> :) [15:52:42] <BBB> well look there's a 1% chance that he's a good coder with no social skills whatsoever [15:52:54] <BBB> so maybe let's give him a chance? [15:53:15] <BBB> I mean, look how quickly he udnerstood the suggestion of sending a new email [15:53:18] <BBB> it only took 4 tries [15:53:20] <jai> also a very important skill is being able to scavenge information/rtfs etc :) [15:53:22] <mru> lol [15:53:47] <BBB> imagine how quickly he would pick up the codebase of ffmpeg [15:54:20] <jai> heh [15:55:09] <BBB> spyfeng: pathc is ok, I'll leave it for 2-3 days for others to review [15:55:12] <BBB> spyfeng: then I'll apply [15:55:19] <BBB> spyfeng: consider yourself ok for the SoC, basically [15:58:18] <j0sh> there was some chatter here recently about unix domain sockets [15:58:32] <j0sh> would patches adding in support for that be welcome? [15:59:07] <BBB> ? [15:59:39] <j0sh> for IPC, rather than using pipes (impossible to have multiple readers on the same pipe, whereas you can with sockets) [16:00:19] <j0sh> irc log from feb 8th shows you guys discussed it briefly :) [16:00:20] <j0sh> viva google [16:01:25] <KotH> BBB: correct taht 1% to 0.1%... he is from india after all [16:01:45] <KotH> jai: no offence intended at your side [16:02:35] <jai> KotH: none taken :) [16:02:36] <kshishkov> jai is kinda an exception. I think FFmpeg has more patches from Ukrainian coders [16:02:50] <jai> s/coders/coder [16:02:57] <jai> unless there are more i'm missing? [16:04:54] <KotH> jai: btw: are there any good books that explain the culture of india? especialy how to deal with people from there? [16:05:13] <kshishkov> I can name that Sergiy who did some work on network protocols and Maksym Veremeenko who sent misc patches for minor bugs [16:05:37] <kshishkov> KotH: yes, written in Britain in Victorian times [16:05:50] <jai> KotH: perhaps try "In Spite of the Gods: The Strange Rise of Modern India" [16:06:13] <jai> the author is ed luce [16:07:00] <kshishkov> and something by Kipling [16:09:01] <KotH> jai: hmm.. looks like an interesting book... thanks! [16:11:34] * KotH wonders how much internet-english people from india do understand [16:11:58] <jai> KotH: no problem, i'm pretty sure you'll find some of the stories/incidents interesting :) [16:12:33] <jai> i assume internet-english != memes :) [16:12:55] <kshishkov> no, it's "rtfm lmd!" too [16:13:28] <Dark_Shikari> they better know our memes too [16:14:02] <KotH> jai: internet-english = semi-technical simplified english used on the internet [16:14:32] <KotH> 'cause, i have the feeling that our friend does not understand what "qualification task" means [16:14:35] <kshishkov> "Hi, my name is Kumar, I play Touhou games. Can I have some task for GSoC 2010 in VideoLAN?" [16:15:03] <DonDiego> Yuvi: you around? [16:15:20] <jai> KotH: ah, well a lot of people are pretty well versed with netiquette and english usage, but there are so many of us that it doesnt amount to much :| [16:15:52] <Dark_Shikari> kshishkov: lol [16:16:03] <jai> touhou isn't that popular here btw :) [16:16:04] <Dark_Shikari> you mean "my name is Yakamura" [16:16:10] <jai> lol [16:16:13] <DonDiego> are these messages arriving on ffmpeg-devel? [16:16:19] <DonDiego> they should go to ffmpeg-soc [16:16:40] <jai> that isnt mentioned anywhere afaik [16:16:59] <jai> also, more visibility on -devel [16:17:05] <DonDiego> i just looked it up on the wiki [16:17:09] <DonDiego> it says -devel [16:17:22] <jai> exactly [16:17:31] <DonDiego> jai: more visibility is not good in this case, -devel is too high traffic [16:17:42] <kshishkov> jai: yes, in a decade there will be more of you than in China [16:17:45] <DonDiego> there should be a filter installed in front of michael [16:18:10] <DonDiego> jai: don't you have a problem with the boy/girl ratio? [16:18:10] <jai> DonDiego: well, i was thinking more in terms that others on the list might have opinions as well... [16:18:29] <jai> DonDiego: in gsoc?? [16:18:38] <DonDiego> no, in india :) [16:18:49] <DonDiego> haha, yes, i'm speaking in riddles [16:18:56] <Dark_Shikari> I have a problem with the indian/everyone else ratio [16:19:03] <Dark_Shikari> then again, I just reject every indian, so that's rarely an issue [16:19:10] <DonDiego> BBB: i'll redirect people to ffmpeg-soc on the wiki if you don't mind [16:19:12] <jai> ah, yeah, in some parts [16:19:20] <kshishkov> Dark_Shikari: ask for help in CHina [16:19:20] * DonDiego looks around for other soc mentors [16:19:21] <BBB> no problem [16:19:30] <Dark_Shikari> kshishkov: I have a chinese friend that might be applying [16:19:38] <DonDiego> BBB: also, what about the "new regtest system" task? [16:19:42] <Dark_Shikari> though he's in the US, so it doesn't count [16:19:47] <BBB> dondiego: add it [16:19:50] <BBB> who will mentor it? [16:19:51] <kshishkov> Dark_Shikari: so what? One even got through already [16:20:03] <DonDiego> i talked about it with mru, he tells me there is no need [16:20:07] <jai> if someone is editing the wiki, maybe they might want to add the h,264 timestamps related thing michael said he'd mentor [16:20:15] <jai> *h.264 [16:20:18] <DonDiego> jai: add it :) [16:20:21] <Dark_Shikari> kshishkov: so what what [16:20:33] <jai> DonDiego: don't have the wiki credentials handy :| [16:20:54] <DonDiego> then add it the next time you have them handy [16:21:01] <kshishkov> Dark_Shikari: even a couple of good Chinese coders don't overcome the fact there are >1.2 milliard of them [16:21:01] <jai> k [16:21:26] <Dark_Shikari> kshishkov: it doesn't matter how many of them if a) they suck or b) they are not here ;) [16:21:48] <Dark_Shikari> you can have a trillion grains of sand on the beach, but if there's none in the shop, you can't make glass [16:22:15] <j0sh> for whoever's adding the h264 for gsoc in the wiki, here are some related small tasks: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-February/083177.html [16:23:16] <BBB> koth: the mentor (baptiste) should approve his qualification task for that particular soc project [16:23:29] <BBB> koth: we'll do it a bit different than last few years [16:24:08] <BBB> kshishkov: american word for milliard is billion [16:24:27] <KotH> BBB: oh.. didnt know [16:24:29] <KotH> BBB: thanks [16:24:40] <kshishkov> BBB: why do you shrink it thousandfold? [16:24:53] <BBB> kshishkov: billion in american isn't billion in european [16:24:54] <Dark_Shikari> kshishkov: you mean multiply it a thosuandfold [16:25:00] <Dark_Shikari> in stupid countries, billion == 10^12 [16:25:03] <BBB> europeans made up this weird billion = 1000*milliard [16:25:07] <Dark_Shikari> in cool countries, billion = 10^9 [16:25:11] <BBB> exactly [16:25:23] <BBB> europeans also made up this weird word milliard [16:25:25] <mru> anyone for a game of billiards? [16:25:27] <jai> j0sh: of course, that could be linked to on the small tasks page as well [16:25:34] <BBB> lol :) [16:25:35] <Dark_Shikari> mru: lol [16:25:36] <KotH> mru: sure.. [16:25:41] <KotH> mru: do you come to zh? [16:25:41] <mru> strictly speaking, europeans were first [16:25:52] <kshishkov> BBB: million too, it's from Italian "mille" = "thousand" [16:25:55] <mru> the yanks couldn't cope with it, so they simplified the language [16:25:59] <mru> or "lingo" as they say [16:26:04] <Dark_Shikari> mru: it's called "using metric" [16:26:05] <Dark_Shikari> ironically [16:26:08] <Dark_Shikari> really really ironically [16:26:14] <KotH> rotfl [16:26:25] <Dark_Shikari> I mean, who the hell thought "milliard" was a good idea [16:26:33] <mru> germans [16:26:36] <Dark_Shikari> probably the same guy who likes gallons per mile-fortnight [16:27:02] <mru> says the guy from the coutry where acre-inches is a unit of volume... [16:27:06] <KotH> Dark_Shikari: you mean they should have left that *ard away completely? [16:27:18] <KotH> Dark_Shikari: or do you mean just to leave out the milliard? [16:27:34] <kshishkov> hmm, "milliard" comes from French [16:27:50] <kshishkov> so it's stupid word for Americans [16:28:01] <mru> and then we have the chinese "man" for 10k [16:28:04] <Dark_Shikari> mru: yes, I'm saying it was the same guy [16:28:14] <Dark_Shikari> responsible for stupid shit like miles, acres, and milliards [16:28:18] <kshishkov> mru: greeks had "miria" [16:28:31] <mru> Dark_Shikari: the US is the only remaining country to use those silly units [16:28:38] <mru> britain is metric [16:28:43] <Dark_Shikari> mru: no, a few more do [16:28:45] <Dark_Shikari> shitty ones [16:28:45] <mru> both officially and in practice [16:28:48] <KotH> mru: even in daily life? [16:28:50] <Dark_Shikari> and yes britain uses imperial [16:28:54] <Dark_Shikari> actually britain is worse [16:28:56] <mru> KotH: to a large extent, yes [16:29:01] <KotH> cool [16:29:02] <mru> beer is still in pints [16:29:06] <Dark_Shikari> in america, I'm 175 pounds [16:29:06] <KotH> didnt take them too long [16:29:08] <mru> and roads are in miles [16:29:09] <Dark_Shikari> in britain, I'm 12.5 STONE [16:29:10] <mru> all else is metric [16:29:12] <Dark_Shikari> what the fuck is a stone [16:29:18] <mru> 14 pounds [16:29:23] <Dark_Shikari> yes, but the point... [16:29:28] <kshishkov> and guinea is 21 shillings :) [16:29:30] <Dark_Shikari> lol [16:29:39] <mru> and how long is a chain, anyone? [16:29:46] <mru> it's 100 links fwiw [16:29:48] <kshishkov> all its links [16:30:05] <KotH> mru: dunno, but it'll break at its weakest link ;) [16:30:17] <mru> and who knows the difference between a troy ounce and an apothecarie's ounce? [16:30:27] <KotH> (yes, i'm bored... i dont want to work) [16:30:29] <mru> no, neither of them is the fluid ounce [16:30:36] <Dark_Shikari> lol [16:30:42] <Dark_Shikari> fluid ounce is a measure of volume [16:30:46] <kshishkov> isn't that suspicious that the only survived non-metric Russian measures are for volume of alcoholic drinks? [16:30:55] <KotH> kshishkov: same in .jp [16:30:57] <mru> and don't forget the dram [16:31:01] <mru> or the grain [16:31:04] <KotH> kshishkov: sake is still measured in rice cups [16:31:06] <kshishkov> farlong [16:31:10] <mru> furlong [16:31:15] <mru> per fortnight [16:31:15] <kshishkov> KotH: six-tatami room :P [16:31:19] <Dark_Shikari> no no no [16:31:23] <Dark_Shikari> attoparsecs per microfortnight [16:31:27] <Dark_Shikari> best unit of measure ever. [16:31:34] <mru> no, the best one is the beard-second [16:31:37] <KotH> kshishkov: only for japanese style rooms... all others are measured in m^2 [16:31:38] <Dark_Shikari> lol [16:32:03] <KotH> kshishkov: looks very wierd on house plans when half of the rooms are measured in tatami, and the other half in m^2 [16:32:33] <Dark_Shikari> tatami-stone per microfortnight [16:33:03] <mru> Dark_Shikari: micro is way too metric [16:33:46] <kshishkov> mru: and in my homeland they often use hectograms - "tre hecto k\:ott" [16:35:15] <mru> sweden is the only place I know to use hectograms and decimetres [16:36:37] <kshishkov> could be [16:38:23] * mru includes norway in sweden [16:38:35] <kshishkov> too late for that [16:38:49] <kshishkov> for 105 years to be precise [16:39:32] <kshishkov> and 200 years for \:Osterland and part of Norrland (aka Suomi) [16:40:29] <KotH> mru: we dont use hectogram in .ch, but decimeter is quite comon [16:40:39] <KotH> mru: same for deziliter [16:40:56] <kshishkov> decimeter/deciliter is common even here [16:41:19] <mru> and 2.5 dl ~= 1 cup [16:41:40] <mru> not to be confused with the old swedish measure 1 kaffekopp == 1.5 dl [16:42:56] <kshishkov> I though 1 kaffekopp = fem minuter [16:42:59] <kshishkov> *thought [16:43:13] <kshishkov> and BTW, how much grams in one pound [16:43:24] <mru> 454 [16:43:25] <BBB> pound =~ 0.5 kilo [16:43:26] <mru> ~ [16:43:32] <BBB> ounce ~= 0.1 kilo [16:45:29] <kierank> nobody's mentioned knots and nm yet [16:45:38] <kshishkov> knot is mph [16:45:53] <kshishkov> nautical mile though [16:45:54] <kierank> you mean nmph [16:46:04] <kshishkov> 1852metres [16:46:10] <kshishkov> or something [16:46:19] <mru> 1 minute of arc at equator iirc [16:46:43] <mru> so if you're doing one minute per minute... [16:46:51] <mru> your mind forms a knot [16:46:53] <mru> hence the name [16:47:15] <kshishkov> s/forms/spins into/ [16:47:22] <kshishkov> it's angular minute after all [16:48:31] <KotH> a gordic knot? [16:49:19] <kshishkov> gordian [16:49:41] <kshishkov> you should have had major in Classics [16:50:30] <kierank> so you can learn dead languages... [16:50:43] <kshishkov> like COBOL [16:50:52] <kshishkov> or ALGOL-60 [16:51:47] <kierank> well cobol can easily be converted to LOLCODE [16:54:07] <KotH> kshishkov: there were no majors/minors at the eth [16:54:13] <KotH> kshishkov: the concept just doesnt fit there :) [16:54:36] <mru> eth sounds like a proper school [16:54:40] <kshishkov> KotH: and almost all education concepts don't fit in our system [16:55:55] <DonDiego> mru: what about adding __BSD_VISIBLE to cppflags for freebsd? [16:56:00] <DonDiego> the fate box needs it [16:56:31] <mru> why? [16:56:35] <mru> sounds wrong [16:57:00] <DonDiego> it could be wrong, but it won't build without [16:57:08] <DonDiego> we have similar hacks for solaris and netbsd [16:57:46] <DonDiego> i've given up hope of fixing the bsd platforms [16:57:55] <DonDiego> the hack is very small and self-contained [16:58:03] <DonDiego> http://fate.multimedia.cx/index.php?build_record=205517 [16:58:06] <kshishkov> mru: why idea of adding obscure flags to fix compiling on BSD sounds wrong to you? [16:58:15] <DonDiego> and it's in use on the fate box anyway.. [16:59:00] <mru> DonDiego: that doesn't mean it's the right thing to do [16:59:26] <DonDiego> it means that it's done in practice [16:59:44] <DonDiego> i know it's not the right thing(TM) [16:59:57] <mru> maybe there's a better solution [17:00:03] <mru> what breaks without it? [17:01:27] <DonDiego> the build :) [17:01:34] <DonDiego> let me fish out the details from a mail.. [17:01:37] <barque> anyone know how to do timing with lbavcodec? [17:01:41] <barque> libavcodec* [17:02:01] <barque> like I decode the frames, just wanna know the second/millisecond position it should be played [17:02:17] <barque> cause decoding is quite fast :P [17:02:32] <DonDiego> mru: bktr.c, ossaudio and udp stuff [17:02:39] <mru> not enough details [17:02:51] <mru> pile all the hacks you want _inside_ bktr.c [17:02:55] <mru> that's bsd-specific anyway [17:03:20] <mru> I'm also sorely tempted to simply drop all manner of bsd support [17:03:28] <mru> they're a huge pita [17:03:32] <DonDiego> we use global hacks for solaris and netbsd already [17:03:32] <mru> and nobody uses it anyway [17:03:39] <mru> and that's wrong [17:04:13] <DonDiego> i know i'm going back and forth but in the end this dogmatic approach buys us nothing i'm afraid [17:04:23] <DonDiego> one line in configure is well-contained enough [17:04:24] <mru> it buys us clean code [17:04:37] <mru> it can break other things [17:05:08] <mru> sometimes requesting BSD stuff gives you non-posix variants of some functions [17:05:16] <DonDiego> it apparently does not in practice [17:05:22] <mru> you don't know that for sure [17:05:37] <DonDiego> the fate box does it [17:05:37] <mru> our test coverage is pretty poor [17:05:46] <DonDiego> it's necessary for compilation [17:05:55] <mru> that's not what I'm talking about [17:06:12] <mru> I'm talking about random functions having their arguments reversed and shit like that [17:06:16] <barque> oh wait... av_gettime () gives you time in video? [17:07:05] <mru> show me exactly what breaks without that thing defined [17:07:23] <DonDiego> i just asked michael kostylev for a log.. [17:07:58] <DonDiego> but i think having hacks on the fate boxes is pointless [17:08:06] <mru> yes [17:08:14] <DonDiego> if they are used on the fate boxes they might as well be in configure [17:08:15] <mru> but that doesn't justify dirty hacks in the source [17:08:34] <DonDiego> it's just one line in configure [17:08:44] <mru> that impacts every last line of C code [17:08:46] <mru> no, thanks [17:09:24] <DonDiego> then drop those fate boxes? [17:09:52] <mru> I spent several hours digging once before discovering that some function had the arguments reversed between tru64 and solaris [17:10:11] <mru> it still compiled [17:10:15] <mru> not even a warning [17:10:47] <mru> tru64 is a bit bsd-ish [17:11:44] <DonDiego> i know that this is all true [17:11:52] <mru> then stop arguing [17:11:57] <DonDiego> but right now we have a split personality [17:12:08] <DonDiego> these hacks are used on the fate boxes [17:12:13] <mru> just get me those error logs [17:12:29] <DonDiego> i'll pass them along once they arrive [17:27:08] <mru> the things you find in the referrer stats... [17:27:11] <mru> http://en.wikipedia.org/w/index.php?title=Bit_field&action=historysubmit&di… [17:39:11] <DonDiego> Yuvi: you around? [17:46:38] <kshishkov> hmm, s/popular/less well optimized/ was a good edit [18:17:41] <ramiro> mru: lots of cheappills.com in referrer stats too? [18:18:06] <mru> quite a bit of spam, yes [18:18:22] <kshishkov> spam spam spam eggs sausages and spam [18:18:49] <mru> nowadays it's spam spam spam pills watches and spam [18:19:34] <BBB> merbanan's blog is full of pill-ads [18:19:38] <BBB> unfortunately :( [18:19:49] <mru> comment spam? [18:19:50] <kshishkov> he should post something about ATRAC there [18:20:11] <BBB> yes [18:20:34] <mru> no spam blocker? [18:21:03] <kshishkov> he neglects his blog [18:21:35] <DonDiego> \o/ [18:21:51] <DonDiego> libsdl 1.3 preview does not make ffplay crash immediately on os x [18:22:00] <BBB> ? [18:22:05] <BBB> ffplay works for me [18:22:06] <DonDiego> i can quickly test samples again, yay [18:22:12] <DonDiego> you are not on ppc [18:22:15] <BBB> oh [18:22:16] <BBB> right [18:22:18] <kshishkov> FFplay works for me too [18:22:22] <BBB> I have to admit that the visualizer is ... weird [18:22:29] <BBB> I've always wondered if that's a feature or a bug [18:22:31] <DonDiego> which libsdl version? [18:22:37] <DonDiego> i use macports [18:22:39] <BBB> mike melanson's blog showed the same img as mine though [18:22:42] <kshishkov> don't remember [18:23:14] <kshishkov> BBB: you've written something about GSoC2010 then [18:23:26] <kshishkov> what about the picture in my last blog post? [18:24:30] <BBB> http://multimedia.cx/eggs/wp-content/uploads/2010/02/ffplay-spectrum-wma-vo… [18:24:32] <BBB> that one [18:24:34] <BBB> weird [18:28:04] <ramiro> BBB: I get the same thing from ffplay [18:28:55] <kshishkov> at least it allows you to recognize instruments from voice without even sound turned on ;) [18:31:05] <BBB> it looks so weird [18:31:29] <kshishkov> only for the first time [18:31:38] <pJok> kshishkov, sounds like you really have a nice transport system in ukraine ;) [18:32:36] <ramiro> hmm, we are talking about the weird green lines, right? [18:33:23] <kshishkov> pJok: of course. Best Czechoslovakian transport from 70s and some Soviet and Chinese crap [18:33:48] <BBB> ramiro: the red also confuses me [18:33:54] <justlooking> wbs, bbb do you intend patching ffmpeg to parse generic youtube URLs to get the real rtsp2.youtube.com links such as http://www.youtube.com/watch?v=anwy2MPT5RE , id ask you question on #ffmpeg but you not one that channel. [18:34:24] <kshishkov> green - both channels are the same there, red/white - left/right channel only [18:34:32] <kshishkov> it's quite intuitive [18:34:36] <BBB> justlooking: that's almost playlist parsing... [18:34:42] <BBB> justlooking: so I'm not sure [18:34:51] <BBB> justlooking: but it should be easy to do and I could look at the patch [18:34:57] <BBB> I might conclude it doesn't belong in ffmpeg though [18:35:22] <jai> write a script and pass the url to ffmpeg instead [18:36:48] <kshishkov> BBB: you actually have so-called inner ear which acts as a frequency analyzer. Use it compare FFplay output. [18:39:24] <jai> O_O [18:39:56] <BBB> my inner ear is composed of tissue, it appears after a quick rough dissection [18:40:05] <BBB> doesn't look at all like that window in ffplay [18:40:18] <kshishkov> learn physiology [18:41:10] <kshishkov> and if you can't compare sound frequencies to FFplay output you need your neuron connections patched [18:43:04] <BBB> so what is the green line again? [18:43:21] <kshishkov> where frequencies for both channels are the same [18:43:27] * justlooking thought the " frequency analyzer" was the gray matter and the inner ear was the analogue sensor. [18:44:39] <pJok> kshishkov, isn't that when you say patch welcome? [18:45:12] * pJok wonders how his hearing will be after april 9th [18:45:14] <kshishkov> pJok: yes but in what format? [18:45:28] <pJok> kshishkov, something like a fpga probably [18:46:37] <kshishkov> well, there's only one man here who is supposed to know about human organism [18:46:42] * kshishkov looks at BBB [18:47:03] <_av500_> big buck bunny? [18:48:11] <BBB> I know little about the ear [18:48:13] <BBB> more about brain [18:49:28] <kshishkov> still you should know more than me [18:51:08] <BBB> unlikely [18:51:16] <BBB> zero divided by zero is undefined [18:51:36] <kshishkov> cmp, not div [18:59:14] <justlooking> BTW , FFmpeg version SVN-r22644 and > from http://ffmpeg.arrozcru.org/autobuilds/ lock up after reporting drop=12 on ffmpeg -i rtsp://rtsp2.youtube.com/CjcLENy73wIaLgkCo6RfCuxKFhMYDSANFEIQdGVzdC1kb21pbm… test.mp4, i assume its not a bad file! [19:00:00] <DonDiego> BBB: what about the regtest soc task? you added it in the first place.. [19:00:08] <BBB> ? [19:00:12] <BBB> when? [19:00:43] <BBB> I didn't add that one [19:00:57] <BBB> I copied it from the 2009 page [19:12:15] <DonDiego> ok, i will just remove it since it's just cruft apparently [19:12:30] <DonDiego> unless somebody can come up with a good reason to keep it.. [19:16:46] <BBB> DonDiego: feel free to remove [19:18:50] <bcoudu> hi guys [19:19:15] <kshishkov> heloo script from truncated nick [19:19:44] <bcoudurier> better :> [19:20:58] <kshishkov> yes, probably [19:21:52] <DonDiego> bcoudurier: hi [19:26:11] <CIA-24> ffmpeg: bcoudurier * r22670 /trunk/libavcodec/ (avcodec.h libx264.c options.c): Enable more libx264 options, aq, psy, rc lookahead and ssim [19:39:58] <CIA-24> ffmpeg: bcoudurier * r22671 /trunk/ (29 files in 2 dirs): Enable mbtree by default, and remove it from presets [19:48:16] <CIA-24> ffmpeg: mstorsjo * r22672 /trunk/libavformat/rtsp.c: Reindent [19:59:33] <BBB> j0sh: did I just get an empty email from you? [19:59:41] <BBB> maybe just random spam [19:59:42] <BBB> ... [20:08:21] <hyc> so, about rtmp again... can someone list the actual items that need to change in the patch I posted, to make it "acceptable" ? [20:12:51] <BBB> hyc: link ffmpeg to ssl and integrate it into our rtmp.c code [20:12:54] <BBB> deal [20:14:03] <hyc> BBB: that doesn't sound to me like keeping both code paths in parallel [20:14:33] <BBB> michael is ok with optionally linking ffmpeg to libssl [20:14:45] <BBB> there's no reason to not integrate rtmpe into ffmpeg [20:15:44] <hyc> right, but it's a hassle to backport librtmp into ffmpeg's rtmp code. it will take a lot more testing, and doubles the amount of maintenance I have to deal with [20:15:59] <BBB> right [20:16:01] <hyc> whereas just dropping librtmp in requires very little additional testing [20:16:06] <BBB> so you'll drop librtmpe and focus on ffmpeg alone, right? [20:16:13] <hyc> nope, can't do that [20:16:20] <hyc> since there are already other apps using librtmp [20:16:29] <BBB> does any of them not use ffmpeg? [20:17:02] <hyc> yes, some of them are just streaming tools, like rtmpdump, with no A/V functionality [20:17:54] <BBB> define "some" [20:17:57] <BBB> you're giving one [20:18:22] <hyc> anyway, I was trying to give you guys something, and now you're telling me that in order for it to be "good enough" to accept I have to rewrite the whole thing. [20:18:48] <hyc> That's pretty strong disincentive for contributions. [20:19:43] <hyc> re: some - rtmpgw, rtmpsuck, rtmpdump-yle to name a few more [20:20:25] <wbs> hyc: even if I prefer having everything within the same code base, I do see the situation that librtmp will be better maintained and up to date, so a patch that allows the usage of librtmp optionally instead of the built-in code would be ok for me [20:21:56] <hyc> wbs: ok. that sounds to me like an autoconf switch and not much more. is that what your're talking about? [20:22:23] <wbs> hyc: we don't use autoconf, but yes, have a look at how the integration with other external libraries work, and see if you can do something similar [20:23:06] <hyc> wbs: ok, will look at that [20:25:45] <wbs> hyc: I hope you understand the general reason for things, though - we prefer stuff written within the existing libav* frameworks, and simply dropping in external code within that doesn't really fit, so if one wants code merged into the project properly, it usually requires quite a bit of rewriting and/or polishing up, to use common routines and designs etc [20:26:39] <wbs> although all of us would prefer the libavformat rtmp code to be the best one, I don't think anybody can force you to work on that one if you don't want to :-) [20:27:21] <hyc> wbs: I would have assumed that one of the advantages of the modulear API is that you can drop in external code easily [20:27:33] <BBB> gstreamer is very modular [20:27:59] <wbs> hyc: modular yes, but not in that sense. not every single audio/video codec should bring their own half-assed fft for example [20:28:12] <_av500_> ffmonolithic [20:28:43] <hyc> wbs: I totally agree with that. if you've got a nicely optimized math lib it'd be stupid not to make the most use of it [20:35:40] <hyc> and while libavutil may have a couple things we could use, it still isn't enough to obviate linking an entire crypto library in [20:36:18] <wbs> of course not, and I'm actually a bit doubtful of reimplementing a whole ssl lib, therefore accepting using libssl or similar is a good decision [20:36:31] <hyc> ok [20:36:55] <BBB> michael is ok with an optional dep on libssl [20:37:03] <hyc> I get it, I know where you're coming from [20:38:08] <hyc> heh, I never read this configure script before, just assumed it was autoconf [20:38:26] <wbs> it's like a million times better than autoconf [20:38:38] <hyc> yeah, I can tell ;) [20:39:44] <hyc> ok, going to add a --enable-librtmp [20:40:15] <wbs> can't guarantee that others will accept it, but that'd be the normal approach for such a thing at least [20:40:36] <wbs> and given the current situation, i'd really consider using it [20:40:53] <hyc> and I guess thereought to be a separate --enable-libssl switch [20:41:09] <hyc> librtmp would require it, but you could optionally support https then [20:42:11] <Vitor1001> bcoudurier: was it your commit that broke regtest-ffm? [20:43:01] <bcoudurier> roh [20:43:30] <BBB> maybe I broke it, I committed something to ffmdec [20:44:07] <bcoudurier> well I feel it's the default flags [20:44:14] <Vitor1001> looking at FATE, it looks like 22699 is ok, 22700 is not [20:44:14] <bcoudurier> only lavf right ? [20:44:40] <Vitor1001> right. [20:46:21] <CIA-24> ffmpeg: bcoudurier * r22673 /trunk/tests/ref/lavf/ffm: 10l, update ref value for ffm since default flags changed and are stored in the file [21:02:23] <CIA-24> ffmpeg: stefano * r22674 /trunk/libavcodec/wmaprodec.c: [21:02:23] <CIA-24> ffmpeg: Make wmaprodec.c:decode_init() return AVERROR_INVALIDDATA / [21:02:23] <CIA-24> ffmpeg: AVERROR_PATCHWELCOME in case of invalid / unsupported number of [21:02:23] <CIA-24> ffmpeg: channels specified, rather than return AVERROR_NOTSUPP. [21:09:41] <wbs> ok, popular vote, which formatting style do people prefer for the ff_data_to_hex patch that I sent earlier? [21:10:07] <wbs> lu_zero preferred the original style, michael was ok with the new one. to apply or not to apply, that's the question [21:10:25] <wbs> (aka serious bikeshed) [21:11:11] * pJok sheds some bikes [21:12:14] <BBB> wbs: let's keep it, I'd like to know why [16] =""; changed the binary [21:12:16] <BBB> it shouldn't [21:12:30] <BBB> in particular because the new binary was likely bigger [21:12:34] <BBB> (was it?) [21:12:44] <wbs> don't remember, I can check [21:12:51] <BBB> nah [21:12:52] <BBB> don't worry [21:12:55] <wbs> ok [21:13:04] <BBB> so your curernt patch, is there any case where uri is not rt->control_uri? [21:13:28] <wbs> yes, for SETUP it's rtsp_st->control_url, and for some case of OPTIONS it's * [21:13:39] <BBB> ok [21:14:07] <BBB> then secondly, can we get rid of buf1[] in send_message()? [21:14:13] <BBB> (by using av_strlcatf()) [21:15:09] <wbs> yes, that should be fully possible (as a completely separate matter from this) [21:15:28] <BBB> yeah [21:16:07] <DonDiego> wbs: k&r style of course :) [21:16:10] <DonDiego> bbl [21:32:39] <wbs> hyc: the includes for external libraries (librtmp/*) should be with <> instead of "" [21:33:33] <wbs> except for that, it looks quite ok at a first glance [21:36:06] <wbs> BBB: cmd isn't unused for the announce case - it contains the Content-Type header [21:36:22] <BBB> but that's a static string [21:36:29] <BBB> so you can pass it directly into send_message() [21:36:36] <wbs> ah, yes, realized it after pressing enter right now ;P [21:36:37] <BBB> no need to copy it into cmd[], right? [21:36:41] <BBB> ok :) [21:37:16] <BBB> and then you can commit it all [21:37:28] <wbs> and for the if (auth_state) thing - the auth methods check for that themselves so it isn't needed here [21:37:32] <wbs> unless you want it for clarity [21:37:39] <BBB> I think it's better for clarity [21:37:43] <wbs> ok [21:37:50] <BBB> you could then maybe remove it from the auth methods [21:37:54] <wbs> extra lines aren't all that expensive anyway [21:38:02] <BBB> but whichever you like, I'd prefer if the function wasn't called [21:38:02] <wbs> sure [21:39:00] <BBB> you had several more patches to be reviewed right? [21:39:23] <wbs> only the old thread regarding handling of EINTR from select [21:39:35] <BBB> "[FFmpeg-devel] [PATCH] libavformat: Don't return errors if select is interrupted" [21:40:18] <wbs> yep, that one [21:45:05] <nfl> bcoudurier: hi what would be a good qual task for the seeking api gsoc task? [21:46:59] <BBB> "[FFmpeg-devel] [PATCH] Use the actual RTSP peer IP for RTP sessions" was applied, right? [21:47:12] <CIA-24> ffmpeg: mstorsjo * r22675 /trunk/libavformat/ (rtsp.c rtsp.h rtspenc.c): Add separate method/url parameters to the rtsp_send_cmd functions [21:47:13] <wbs> yes, that thread is finished for my part [21:48:28] <CIA-24> ffmpeg: mstorsjo * r22676 /trunk/libavformat/ (rtsp.c Makefile rtsp.h): [21:48:28] <CIA-24> ffmpeg: Make RTSP use the generic http authentication code [21:48:28] <CIA-24> ffmpeg: Still hardcoded to use Basic auth, without parsing the reply headers [21:49:15] <BBB> yay @ rtspauth [21:49:46] <CIA-24> ffmpeg: mstorsjo * r22677 /trunk/ (libavformat/rtsp.c ffserver.c libavformat/rtsp.h): Actually parse the auth headers in RTSP [21:50:33] <CIA-24> ffmpeg: mstorsjo * r22678 /trunk/libavformat/rtsp.c: Don't force basic auth in RTSP, but retry with the server-specified method on failure [21:51:15] <wbs> yay @ getting patches ok'd :-) [21:54:33] <CIA-24> ffmpeg: mstorsjo * r22679 /trunk/libavformat/httpauth.c: Remove a redundant null pointer check [22:05:29] <CIA-24> ffmpeg: mstorsjo * r22680 /trunk/libavformat/rtsp.c: Simplify ff_rtsp_send_cmd_with_content_async, remove an unnecessary buffer [22:10:39] <nfl> a quick question: where is pal8 used to build rgb output in the ffmpeg code? [22:11:00] <BBB> libswscale [22:16:25] <DonDiego> mru: http://www1.mplayerhq.hu/~diego/freebsd.log [22:16:48] <DonDiego> that's a log of a failing freebsd build, given to me by michael kostylev [22:17:30] * mru stabs bsd [22:20:15] <mru> they're all bugs in the system headers [22:20:55] <DonDiego> yes [22:21:26] <mru> bktr.c and oss_audio.c fail because the system headers use typedefs without defining them first [22:21:40] <mru> udp.c fails on IPPROTO_IPV6 which is quite standard [22:21:57] <CIA-24> ffmpeg: mstorsjo * r22681 /trunk/libavformat/rtsp.c: Reassemble the RTSP URL before replacing hostname with the numerical IP [22:22:00] <mru> the spec does not say a thing about special triggers needed to make it visible [22:22:37] <DonDiego> bktr.c could be fixed through __BSD_VISIBLE [22:22:43] <mru> has anyone asked bsd devs? [22:22:46] <mru> as if... [22:22:50] <DonDiego> dunno [22:22:56] <DonDiego> where to find them? [22:23:03] <mru> in the dungeon [22:23:09] <DonDiego> #freebsd? [22:29:44] <Kovensky> what would make av_seek_frame segfault? [22:30:25] <Kovensky> Program received signal SIGSEGV, Segmentation fault. [22:30:25] <Kovensky> 0x00007ffff7724d68 in FFLAVFAudio (this=0x763420, SourceFile=0x7fffffffe236 "campanella_op.mpg", Track=<value optimized out>, Index=0x70e730) at src/core/lavfaudio.cpp:58 [22:30:28] <Kovensky> 58 if (av_seek_frame(FormatContext, AudioTrack, Frames[0].PTS, AVSEEK_FLAG_BACKWARD) < 0) [22:30:32] <Kovensky> hurf, I'm probably in the wrong channel [22:35:18] <BBB> finally I submitted a patch myself again [22:47:17] <CIA-24> ffmpeg: stefano * r22682 /trunk/libavutil/error.h: Use consistent punctuation rules for the error message descriptions. [22:47:17] <CIA-24> ffmpeg: stefano * r22683 /trunk/libavutil/error.h: Prefer '///< ...' doxygen inline syntax over '/**< ... */'. [22:47:18] <CIA-24> ffmpeg: stefano * r22684 /trunk/ (5 files in 2 dirs): Implement av_strerror(). [22:50:10] <hyc> mru: there are already several uses of pkg-config in the configure script [22:53:37] <CIA-24> ffmpeg: stefano * r22685 /trunk/doc/APIchanges: Add APIchanges entry after av_strerror() addition. [22:54:04] <mru> hyc: that's no excuse for adding more [22:54:41] <mru> are there any other than for dirac/schrodinger? [22:55:11] <hyc> hm, no [22:55:12] <mru> whose retarded devs made it _impossible_ to use otherwise [22:55:18] <mru> well, you can guess flags [22:55:31] <hyc> and of course, you actually generate pkg-config files [22:55:53] <mru> I'd gladly remove that [22:56:30] <hyc> anyway, not disagreeing with you. I've only had bad experiences with pkgconfi [22:56:32] <hyc> g [22:56:47] <hyc> I was just confused at your message, since it appears that your stuff uses and supports it [22:57:09] <DonDiego> what msg? [22:58:32] <hyc> the email saying to ignore pkg-config

1 0

IRC log for 2010-03-24
by irc＠mansr.com 25 Mar '10

25 Mar '10

[00:09:24] <peloverde> j-b, yes I found the fix [00:10:18] <peloverde> I needed "--enable-shared --enable-pic" on ffmpeg and I had old objects left over in either ffmpeg or vlc [00:11:29] <mru> --enable-shared should have no effect on the static libs if you already had --enable-pic [00:11:34] <mru> except on ia64 [00:17:05] <j-b> peloverde: cool. [00:39:25] <ramiro> kurosu: you missed the patch =) [00:40:18] <mru> someone said gmail warns if you mention an attachment without actually attaching anything [00:40:46] <ramiro> mru: I have that enabled =) [00:41:15] <mru> do you have the full autopilot enabled? [00:41:24] <mru> http://mail.google.com/mail/help/autopilot/index.html [00:43:25] <saintd3v> mru: it's a labs feature [01:08:01] <CIA-24> libswscale: diego * r30954 /trunk/libswscale/ (utils.c swscale.c): AltiVec implies a PPC CPU, so there is no need to check for both. [06:26:36] <peloverde> kshishkov, I think I finally snapped or something because I started hacking on the AAC encoder again [06:26:59] <kshishkov> oh, welcome to dark side :) [06:27:08] * kshishkov is hacking BINKb decoder [06:28:44] <peloverde> I don't know if you heard but we found this in brussels: http://beeradvocate.com/beer/profile/3313/9157 [06:29:46] <kshishkov> have you sent a sixpack to RAD? [06:30:55] <peloverde> No, someone broke all the bottles on the table and we left in a hurry :) [06:31:20] <kshishkov> why? bar brawl is a half of fun [07:04:09] <saintd3v> peloverde: i'm pretty good at that subliminal messaging, aren't I :P [07:04:34] <peloverde> saintd3v, I guess so [07:04:56] <peloverde> I reached a point where i needed a break from PS [07:05:07] <saintd3v> hehe [08:23:05] <jermy> j-b: Yes, I have plenty of Panasonic P2 content [09:14:08] <j-b> jermy: I guessed so [09:42:47] * elenril kicks gnuplot [09:43:01] <elenril> anyone knows of a good app for 3d plots? [09:43:20] <kshishkov> gnuplot was rather fine [09:43:55] <elenril> gnuplot sucks at this [09:43:59] <kshishkov> IIRC all things like MathCAD can do 3D plots [09:44:32] * elenril wonders how hard would it be to import the data to blender ;) [09:44:51] <elenril> srsly, why can't they use normal spherical coordinates [09:45:15] <kshishkov> because they are not used even in geography [09:46:45] <kshishkov> maybe using octave as frontend helps? [09:46:57] <superdump> 'normal spherical coordinates'? [09:47:12] <kshishkov> superdump: in range -1.0..1.0 [09:47:19] <elenril> no [09:47:40] <superdump> r, theta, phi are the coordinates i always used in maths and physics [09:48:07] <kshishkov> x,y,z where x^2+y^2+z^2 <=1 is fine with me [09:48:11] <superdump> and afaik, theta and phi are (with a little translation maybe) used in geography [09:48:12] <jermy> j-b: We work with quite a number of post-production companies, so have quite a catalogue of random professional file formats [09:48:20] <elenril> x = r*sin(θ)cos(φ), y = r*sin(θ)sin(φ), z = cos(θ) [09:49:19] <elenril> gnuplot uses some other weird convention [09:53:22] <j-b> jermy: well, the only AVC-Intra files I have seen are from Panasonic, => my questions [10:07:34] * justlooking wonders if jermy can get these "post-production companies" to release some native original superHD and HD content pro clips under creative commons licences for ffmpeg/x264 use as there seems to be a lack of these around? [10:32:20] <kshishkov> hmm, if certain Haiku dev says "There are VNC servers for almost any OS out there, even BeOS." it looks like even he admits that BeOS sucks [10:39:34] <ramiro> yeah, that was funny... [10:40:52] <kshishkov> now we need Xiph devs to admit that Theora is not the best choice for streaming video [10:41:16] <elenril> it's not? [10:41:19] * elenril hides [10:41:50] * kshishkov sends full collection of RMS works to the hole where elenril is hiding [10:42:48] <CIA-24> ffmpeg: benoit * r22653 /trunk/libavformat/aviobuf.c: [10:42:48] <CIA-24> ffmpeg: Mask away AVSEEK_FORCE properly in some checks in url_fseek() [10:42:48] <CIA-24> ffmpeg: Patch by Tomas H?rdin $(name).$(s/?/a/ $(surname)) AT codemill DOT se [10:43:29] <KotH> o_0 [10:43:38] <KotH> email obfuscation reaching new heights ^^' [10:43:45] <elenril> http://tvtropes.org/pmwiki/pmwiki.php/Main/BigNo [10:44:00] <kshishkov> KotH: nah, you have not seen my commits [10:44:00] <elenril> why don't we just md5sum them ;) [10:44:03] <twnqx> KotH: write a "fixer" plugin [10:44:18] <twnqx> that's autoreplacing with machine-readbale email addresses [10:45:14] <kshishkov> KotH: svn log libavcodec/rtmpproto.c for example [11:01:00] <KotH> you seem to have a sporty aproach [11:01:14] <kshishkov> no, got lazy [11:01:41] <kshishkov> in all days it was shell constructs and more complex C expressions [11:04:22] <Kovensky> <KotH> email obfuscation reaching new heights ^^' <-- we need to get to the level of those perl one-liner signatures on perlmonks :P [11:12:14] <CIA-24> ffmpeg: cehoyos * r22654 /trunk/libavformat/matroskaenc.c: Silence ridiculous gcc warning. [11:19:02] <jermy> justlooking: Ah, now that might be harder. We can generate plenty of Sony HDCAM-EX ourselves, but getting rights on other material would require some level of cooperation from clients [11:19:56] <jermy> on the other hand, we could probably get a reasonable chunk of test footage from the camera makers themselves - but it wouldn't be very exciting stuff [11:20:28] <jermy> we have at least 4 different sets of clips of carparks [11:22:25] <av500> jermy: it does not have to be movie content [11:22:43] <kshishkov> av500: should it be deadly boring though? [11:22:45] <av500> just something what we can use to play with, like e.g. moving traffic [11:22:49] <kshishkov> pross-au: G'day, cobber! [11:22:53] <av500> kshishkov: well, not a static scene [11:23:12] <pross-au> Evening [11:23:13] <jermy> Yeah, but it's so much nicer to have stuff that isn't just of somebody's desk [11:23:27] <kshishkov> pross-au: look at that crap - http://shishkov.homeunix.net/binkb.patch [11:23:39] <pross-au> WOOOOW [11:23:59] <kshishkov> it decodes it but it still looks like total mess [11:24:57] <kshishkov> still images are quite recognizable on samples at MPHQ [11:27:29] <pross-au> I will check it out [11:33:36] <pross-au> Nothing major kshishkov [11:34:13] <pross-au> Nice work [11:34:21] <kshishkov> patchiswelcome :) [11:34:26] <pengvado> in inter-predicted codecs, the data you get after subtracting the inter prediction is called "residual". [11:34:29] <pengvado> in LPC codecs, the data you get after subtracting LPC is called "residual". [11:34:32] <pengvado> if I do both, is there a canonical pair of names to distinguish the data after each step? [11:35:02] <kshishkov> data - all prediction = residual [11:35:49] <kshishkov> you can all it inter-decorrelated data or lpc-decorrelated data in intermediate steps though [11:36:55] <Dark_Shikari> pengvado: inter prediction and LPC? [11:37:15] <kshishkov> sounds good for subtitles [11:37:25] <pengvado> well, median isn't linear, but it's close enough to use the same names [11:37:54] <pengvado> otoh, I have considered real LPC too [11:38:24] <Dark_Shikari> kshishkov: more like PPMD [11:39:44] * kshishkov remembers those funny PPM schemes [14:38:53] <Dark_Shikari> holy fuck I hate autotools [14:39:00] <andoma> +1 [14:39:15] <kshishkov> use them in x264 and hate them even more [14:39:15] <Dark_Shikari> I'm trying to compile xzutils (successor to lzmautils) on windows to decompress a fucking file [14:39:21] <Dark_Shikari> it fails on cygwin with link errors [14:39:24] <Dark_Shikari> on mingw, it won't even configure [14:39:31] <Dark_Shikari> it says "i686-pc-mingw" isn't recognized as a host or build [14:39:45] <Dark_Shikari> and if I just pass -mno-cygwin as ld/cflags, it doesn't realize I'm building mingw and defaults back to cygwin [14:39:52] <Dark_Shikari> and then fails on build. [14:40:41] <Dark_Shikari> and of course they have no binaries on their site [14:41:35] <Compn> Dark_Shikari : what link errors on cyg? [14:41:42] <thresh> you can always safely say it is a cygwin problem [14:42:01] <Compn> Dark_Shikari : then find out what build name it wants for mingw by reading configure script or readme / install doc ? [14:42:10] <Dark_Shikari> Compn: no, the correct packages are installed [14:42:22] <Dark_Shikari> it's a link error against libintl [14:42:34] <Compn> ugh [14:42:48] * kshishkov has been hating autotools since the times he was on dialup and autocrap took up to 90% or package contents. And always required the latest version of autotools [14:42:52] <Compn> got a nix box with cygwin crosscompile ? [14:42:59] <Dark_Shikari> Compn: I'm not that insane [14:43:05] <Dark_Shikari> also, I just want to decompress a fucking file [14:43:07] <kshishkov> invoke gcc manually? [14:43:10] <Dark_Shikari> why do they have to use nonstandard formats like this [14:43:13] <Compn> what file ? [14:43:16] <Compn> format [14:43:18] <Dark_Shikari> it's a .xz file [14:43:26] <Compn> ah [14:43:27] <Compn> crazy [14:43:28] <Dark_Shikari> they should just use .7z like EVERYONE ELSE IN THE WORLD [14:43:39] <mru> and _that_ is a standard format??? [14:43:53] <mru> or is it just pkzip format in disguise? [14:43:59] <kshishkov> lzma is creeping to standard though [14:44:04] <kshishkov> mru: no, it's not [14:44:33] <mru> the pkzip format has a per-field field for compression type [14:44:43] <mru> would be trivial to define one for lzma [14:44:56] <kshishkov> mru: it's just another of your favourite "save diskspace by melting CPU" archiver. Decompression is very fast though [14:45:04] <mru> I know what lzma is [14:45:22] <mru> on its own, lzma is just a stream compressor [14:45:26] <Dark_Shikari> 7z at least has a cross-platform implementation [14:45:35] <Dark_Shikari> and is implemented by multiple programs [14:45:43] <mru> to create a proper archive, you need something more [14:45:45] <Dark_Shikari> xz is implemented by exactly one, which is not cross-platform [14:45:46] <kshishkov> mru: and 7z uses some filters to increase compression [14:45:47] <mru> like .tar.foo [14:45:54] <Dark_Shikari> mru: yeah, xz is like that too [14:45:58] <Dark_Shikari> it's like bz2, i.e. one file compression only [14:46:24] <mru> oh, xz is YET ANOTHER compression scheme? [14:46:33] <Dark_Shikari> it's lzma [14:46:35] <Compn> Dark_Shikari : what xz file is it anyways? can you get it in a diff format? :P [14:46:38] <mru> gaaaah [14:46:58] <mru> so how is it different from plain lzma? [14:47:10] <Dark_Shikari> mru: it's a container format [14:47:12] <Dark_Shikari> lzma is the codec [14:47:19] <Dark_Shikari> it's like '7z' or '.lzma' [14:47:25] <Dark_Shikari> except FUCKING ANNOYING [14:48:10] <Dark_Shikari> lets see if it works with mno-cygwin [14:48:23] <mru> just get a damn linux box already [14:48:24] <Dark_Shikari> i.e. compiled with cygwin as host, but with mno-cygwin as cflags/ldflags [14:48:26] <Dark_Shikari> aka massive fuckery [14:48:31] <Dark_Shikari> mru: that's not the issue, I have linux boxes [14:48:34] <Dark_Shikari> this is a 350 gigabyte xz file [14:48:40] <Dark_Shikari> it will decompress to my entire external hard disk [14:48:41] <mru> whoa [14:48:44] <Dark_Shikari> I can't send it over the internet [14:48:56] <twnqx> why not? [14:49:00] <Dark_Shikari> my upload is 50kbps [14:49:01] <mru> boot a livecd then [14:49:06] <twnqx> torrent it :D [14:49:09] <mru> 50k??? [14:49:23] <twnqx> yeah, it might take some time :P [14:49:27] <Dark_Shikari> er, 50KBps [14:49:34] <Dark_Shikari> woot, mno-cygwin build failed too [14:49:35] <mru> oh, 500k [14:50:13] <kshishkov> Dark_Shikari: maybe try invoking gcc directly to link it, I did that many times [14:50:13] <Dark_Shikari> fuck you XZ, claiming that your shit works on windows [14:50:14] <Dark_Shikari> it doesn't. [14:50:27] <mru> well, I still thought my 1.2Mbps was low [14:50:35] <Dark_Shikari> I have 100mbit down [14:50:50] <mru> what bizarre kind of connection are you on? [14:50:54] <Dark_Shikari> university [14:51:09] <mru> I'm getting 18M down at the moment [14:51:26] <mru> at my university connections were 100M both ways [14:51:44] <mru> and that was 10 years ago [14:51:55] <mru> shit, I'm getting old [14:51:56] <kshishkov> 1mbps/512kbps here - my connection is more symmetric than yours! [14:52:44] <kshishkov> mru: your university was Swedish, so 100M/100M may be low even for those times [14:53:08] <Dark_Shikari> oh. the xz file is only 32gb [14:53:11] <mru> it obviously sat directly on the SUNET backbone [14:53:11] <Dark_Shikari> it _decompresses_ to 350gb [14:53:28] <Dark_Shikari> oof. this may take a while [14:53:33] <mru> but the accessible connections were all 100M [14:53:39] <Dark_Shikari> in fact, screw it, I'll pipe directly to x264 [14:53:44] <Dark_Shikari> I don't want to write that much data to disk [14:54:21] <mru> what is this file? [14:54:30] <Dark_Shikari> lossless 1080p source [14:54:34] <mru> ultra-high-grade porn? [14:55:55] <kshishkov> mru: since it's in .xz archive, pornography lies in the process of extracting it [15:21:40] <ramiro> mru: what do you think about making configure detect arch/os based on cross-prefix? [15:21:54] <mru> rejected [15:21:59] <ramiro> why? [15:22:07] <mru> I have systems that don't use a cross-prefix [15:22:17] <mru> it's just a convenience [15:22:27] <mru> and there are no hard rules about it [15:46:56] <BBB___> so what's this ohloh kudos system? [15:47:02] <BBB___> oh my nick is screwy again [15:48:17] * kshishkov does not care since "oh loh" translates into Russian as "aww, sucker" [15:49:18] <kshishkov> and check your IRC client, maybe it sets "screw nickname on startup" for this channel [15:49:51] <BBB> no, there's another user BBB I think [15:49:54] <BBB> I keep ghosting him [15:49:56] <BBB> he keeps coming back [15:50:29] <mru> then you need to /exorcise him [15:51:11] <roozhou> kshishkov: When will you fix RV40 deblocking issues? [15:51:27] <kshishkov> could be some other instance from your client messing [15:51:45] <av500> or janneg's BBB becomes selfaware.. [15:52:00] <kshishkov> roozhou: never. It deblocks fine and bitexact for I/P frames IIRC [15:52:23] <kshishkov> and I don't have any power over Real to make them fix it either [15:52:23] <roozhou> kshishkov: I mean B frames [15:52:49] <kshishkov> and what's visually wrong with them? [15:54:53] <roozhou> artifact in flat area [15:58:30] <kshishkov> hmm, got images? [15:59:15] <roozhou> of course, i can make screenshot from almost all my rmvb collections [16:03:00] <kshishkov> it may be not related to deblock filter at all [16:04:08] <kshishkov> B-frames use weighted prediction (i.e. like H.264) but someone was too lazy to implement those functions for lavc RV3/4 decoder [16:04:36] <kshishkov> it can be usually spotted during fade ins or fade outs [16:09:18] <DonDiego> kshishkov: you lazy lout, you! [16:09:37] <kshishkov> yep, me! [16:10:07] <kshishkov> you can ask Dark_Shikari to RE those funcs and write SIMD counterparts for them too [16:12:24] <kshishkov> personally I don't want to touch for next N years at least [16:12:38] <DonDiego> touch what? [16:12:52] <kshishkov> RV3/4 decoder [16:17:26] <av500> N := 1 [16:18:04] <kshishkov> N is a natural number [16:18:12] <kshishkov> can be indefinitely big [16:22:05] <kshishkov> DonDiego: you can make it a small task if you want ;) [16:22:23] <DonDiego> just add it to the wiki quickly [16:22:43] <DonDiego> you know exactly what you are talking about [16:33:45] <kshishkov> added [16:44:01] <BBB> spyfeng: good work (your curernt commits)! [16:44:16] <BBB> I bet you can get that file under 800 lines of code [16:46:07] <BBB> oh darn it, you're at 693 lines of code already [16:46:14] <BBB> what was the original again? [16:46:52] <BBB> 1305 lines of code [16:46:55] <BBB> you halved it! [16:46:57] <BBB> good job [16:47:42] <kshishkov> it all depends on source code and destination coder quality ;) [16:47:52] <BBB> I think he's ok [16:47:53] <BBB> :) [16:48:00] <BBB> reviewthe patch on the mailinglist [16:55:27] <cs011> Hi, there, is ffmpeg-mt stable, or it still has timpestamp problems with H.264? [16:57:48] <astrange> timestamp problems in what program? [17:00:06] <cs011> We had a discussion over Videolan forums http://forum.videolan.org/viewtopic.php?f=2&t=42328&start=75#p235886 about why VLC doesn't support multithreaded like Mplayer does. Videolan team claims ffmpeg-mt has many timestamps problems [17:00:26] <mru> could it be that vlc has timestamp problems? [17:00:46] <astrange> sounds like vlc's problem [17:01:12] <cs011> VLC is claiming that they are still using the singlethreaded version as to avoid timestamp problems. [17:01:17] <cs011> So it doesn't have that. [17:01:19] <astrange> -mt has different decoder delay, but h264 already has different decoding delay [17:01:26] <astrange> see ffmpeg -strict 0 vs -strict 1 [17:01:40] <astrange> if it can't handle one it can't handle the other [17:02:19] <astrange> the api for tracking timestamps (has_b_frames and reordered_opaque in avcodeccontext) works right [17:02:22] <astrange> in both cases [17:03:05] <cs011> I don't know if it's the right place to say that, but multicore support in VLC had been the subject of an endless blame game [17:03:23] <mru> our blame is stronger [17:04:28] <cs011> Videolan team blames the ffmpeg team for ffmpeg-mt being allegly "broken" (see link, and the previous page), and ffmpeg says that ffmpeg-mt is fine, and it's VLC fault [17:04:36] <kierank> just ask j-b [17:05:13] <cs011> Here is the start of the soap opera http://forum.videolan.org/viewtopic.php?f=2&t=42328&start=60#p225039 [17:05:15] <mru> we often get blame when we break people's assumptions which were never promised to be true [17:05:58] <BBB> we should merge ffmpeg-mt no? [17:06:10] <mru> have all problems been fixed? [17:06:14] <astrange> yes, i'm working on it [17:06:31] <BBB> lol :) [17:06:44] <mru> last I heard there were _other_ problems [17:06:48] <mru> nothing to do with timestamps [17:07:14] <Kovensky> like crashing [17:07:21] <Kovensky> :> [17:07:36] <astrange> vp3 and dependencies are finished now [17:07:48] <astrange> i don't have any crash reports [17:08:01] <Kovensky> you fixed those [17:08:09] <astrange> about h264 and -strict, that only applies to files without num_reorder_frames set [17:08:12] <astrange> http://astrange.ithinksw.net/ffmpeg/camp_mot_mbaff0_full.264 here's one [17:08:12] <Kovensky> (the theora seeking one was the last one IIRC) [17:08:22] <elenril> svq3 refuses to play anything with more than one thread [17:09:07] <cs011> @mru: Then, it's probable those "other_problems" that keep the VLC teams from going multithreaded [17:09:46] <astrange> [svq3 @ 0x10107ce00]SVQ3 does not support multithreaded decoding, patch welcome! (check latest SVN too) [17:09:52] <astrange> huh, why doesn't it just ignore it [17:09:54] <cs011> The stability of VLC (since version 0.99) has been their pride, so they don't want to see it crashing because ffmpeg-mt has "other_problems" [17:09:55] <elenril> yes, this [17:10:11] <CIA-24> ffmpeg: alexc * r22655 /trunk/libavcodec/aaccoder.c: [17:10:11] <CIA-24> ffmpeg: aacenc: Merge quantize_band_cost() with quantize_and_encode_band(). [17:10:11] <CIA-24> ffmpeg: If these two functions aren't matched results may be unexpected. [17:10:21] <elenril> dunno, the line was added by michael, log said it fixes something [17:10:29] <superdump> \o/ [17:10:42] <superdump> peloverde: working on ffaacenc now? :) [17:11:02] <BBB> \o/ indeed [17:11:17] <BBB> what happened to that guy applying for the wvp2 soc task? [17:11:18] <peloverde> superdump, Last night I was sick of PS and wanted something different... but back to PS today [17:11:26] <superdump> :) [17:11:31] <superdump> how is PS going [17:11:34] <superdump> ? [17:12:14] <peloverde> I think I can still get it done within a week from today, which was my original goal [17:12:33] <peloverde> (otoh at one point I thought I could get SBR done for xmas) [17:12:40] <Kovensky> after PS, we'll only need LATM to drop faad2 from mplayer :3 [17:13:53] <BBB> I'm wondering, theoretically, how bad it'd be to have to RE some codec from ffmpeg if you didn't have the source [17:13:58] <BBB> just purely theoretical question [17:14:12] <BBB> would it be better or worse than a dll in windows? [17:14:31] <BBB> or compare faad2 vs ffaac [17:14:34] <BBB> which would be easier to re? [17:17:51] <mru> good ffmpeg code is probably easy to RE [17:18:58] <astrange> write-combining makes it harder to figure out structure sizes [17:19:15] <astrange> other than that, probably easy as there's little code duplication [17:20:54] <cs011> When will ffmpeg-mt be without problems? [17:21:26] <cs011> When this happens, shouldn't you merge ffmpeg with ffmpeg-mt [17:21:26] <cs011> ? [17:21:42] <astrange> when it's merged it will have only as many problems as the rest of it [17:22:24] <cs011> @astrange Any estimate when this might happen [17:22:26] <cs011> ? [17:22:31] <cs011> In a year? A decade? [17:22:43] * Kovensky thinks a decade is pretty long [17:22:53] * Kovensky goes find his Captain Obvious custome [17:23:02] <kierank> cs011, same day as duke nukem comes out [17:23:37] <peloverde> When Opera mini is accepted to the app store [17:23:44] <astrange> it already doesn't have the problems you think it does though, so that's good [17:25:52] <elenril> Host en.wikipedia.org not found: 3(NXDOMAIN) lolwut? [17:26:01] <DonDiego> astrange: so you have theora multithreading finished? [17:26:30] <BBB> lu_zero: you'll mentor josh, right? [17:26:53] <pasteeater> elenril: i too can not connect to en.wik.. [17:26:53] <DonDiego> Yuvi: you around? [17:27:18] <DonDiego> Yuvi: siretart and i would love to get a quick status update for the theora and ogg stuff for 0.6... [17:28:36] <peloverde> Any idea how we are doing student count wise? [17:29:18] <j0sh> BBB, with rtsp over tcp in ffmpeg now, i think http tunneling for gsoc should be pretty easy, don't you think? [17:43:53] <BBB> j0sh: hopefully [17:44:02] <BBB> j0sh: but I haven't ever looked at it [17:44:12] <BBB> j0sh: btw ffmpeg always supported tcp as transport [17:44:25] <BBB> j0sh: the recently committed patch was for tcp in the rtsp _muxer_, not _demuxer_ [17:48:08] <BBB> wbs: I'm almost ok with patch #1 for httpauth [17:49:58] <BBB> wbs: also, you didn't document auth.h yet (with RFC references, and also some doxy in the DigestParams struct please?) [17:50:04] <cs011> To put it bluntly: Are you intending to use the Google SoC opportunity to perfect multithreading for ffmpeg, or are you going to waste it (again) on useless network-related ideas? [17:50:22] <cs011> It's not like Google will fund Soc forever [17:50:33] <av500> they are tight with money? [17:50:39] <j0sh> cs011, network-related stuff is not useless for all of us :) [17:50:52] <cs011> Sooner or later, they will have their own products, and they will eventually stop funding ffmpeg [17:50:54] <kshishkov> and some devs are still on single-core CPUs [17:50:59] <wbs> BBB: ah, forgot to add the rfc references [17:51:05] <kshishkov> good luck reimplementing FFmpeg [17:51:06] <cs011> Just like they will stop funding Firefox now that they have Chrome [17:51:13] * elenril thinks obvious troll is obvious [17:51:19] * av500 agrees [17:51:42] <j0sh> BBB, reading the apple specs for quicktime http streaming. seems straightforward [17:51:44] <cs011> They don't re-implement it, they take the code and make their own fork. Then they put it on embedded devices This is how google rolls. [17:51:54] <av500> anyway, there is so much metadata work to be done 1st.... [17:51:55] <cs011> Chrome, Android etc [17:52:11] <wbs> BBB: and will add more doxy to the header - forgot to add the rfc reference in the last round [17:52:12] <av500> cs011: still troll [17:52:13] <DonDiego> we shall see [17:52:42] <kshishkov> forking is about devs - that's why ffmbc may live and your fork will wither [17:52:46] <BBB> j0sh: straightforward would be cool [17:52:51] <elenril> av500: yeah, metadata ftw! [17:52:53] <j0sh> BBB, i think that'll be one of my tasks. rtcp looks like another area that could use improvement [17:53:14] <kshishkov> rtmp too [17:53:15] <av500> actually, google decided to write their own mediaplayer for android now [17:53:20] <BBB> wtf @ network troll [17:53:38] <cs011> @av500 Were did they based it on? [17:53:44] * elenril looks at himself still talking when there's chapters to do [17:53:48] <av500> cs011: no idea, did not look into it yet [17:53:55] <astrange> google uses opencore or something for android [17:53:57] <av500> they call it "stagefright" [17:54:03] <astrange> i've looked and the code is absolute nonsense [17:54:03] <av500> astrange: not for long any more [17:54:18] <cs011> Where can I find a list of all the software in Android? [17:54:25] <cs011> What media player it has, what browser etc [17:54:33] <av500> but I dont know if stagefright is to be used together with opencore [17:54:45] <av500> cs011: hmm, no idea, that code is locked away, no? [17:55:06] <cs011> @av500 Android is supposed to be opensource [17:55:39] <j0sh> cs011, android sdk would be a good place to start :) [17:56:01] <cs011> Where can I get the source for Android? [17:56:13] <BBB> cs011: wrong channel [17:56:19] <BBB> go email support(a)google.com? [17:56:32] <cs011> Sorry [17:56:43] <av500> cs011: google also does a search engine: http://www.google.com [17:56:58] <BBB> they say that search engine is pretty decent [17:57:04] <kshishkov> not in China ;) [17:57:15] <BBB> also, we're about to start discussing ffmpeg development again here, how about that? [17:57:32] <j0sh> would rtmp enhancements also be acceptable for gsoc? sounds like that's be useful to people too [17:58:22] <j0sh> i dont know how long each of these tasks is gonna take, the theora depayloader was only about a week of on-off work [17:58:24] <cs011> Why don't you give priority to ffmpeg-mt? [17:58:34] <av500> why dont you? [17:58:36] <cs011> Everything else is minor, everybody says [17:58:36] <av500> fund it [17:59:10] <kshishkov> BBB: this channel actuall was created only for devs to chat and not hear "how can I recode stuff to Fl$*!" question [18:00:08] <jai> lol [18:00:14] <av500> \\\ooo/// [18:00:20] <BBB> my apologies [18:00:22] <elenril> BBB++ [18:01:08] <BBB> j0sh: you could do that... I would sure as hell be in favour of it, but it'd be a different set of developers that know that protocol [18:01:37] <kshishkov> BBB: here's a bit to you - WMV decoding DLLs usually have several identical or near-identical get_bits() in a single .dll [18:01:59] <BBB> j0sh: but since michael appears to be ok with an optional dependency on libssl, rtmpe would be cool [18:02:12] <kshishkov> weren't you a mentor for RTMP last summer? [18:02:15] <BBB> kshishkov: that's true [18:02:15] <av500> mru: http://embeddedgurus.com/stack-overflow/2010/02/is-gcc-a-good-compiler/ [18:02:18] <BBB> that also [18:02:24] <BBB> kshishkov: weren't you the student implementing it? [18:02:42] <kshishkov> BBB: that's true [18:04:42] <j0sh> BBB, i can investigate rtmpe. will probably be a good stretch goal after other tasks have been done [18:05:15] <BBB> well, it'll keep you busy after soc is completed :) [18:05:24] <j0sh> true that [18:05:38] <kshishkov> especially with libssl reimplementation ;) [18:05:54] <kshishkov> (why not reimplement it if we can?) [18:06:11] <j0sh> fflibssl would be for 2011 gsoc, heh [18:06:49] * j0sh out for lunch [18:06:52] <BBB> anything that duplicates code ^d^d improves ffmpeg is good [18:06:53] <kshishkov> could be [18:07:25] <kshishkov> we don't duplicate code [18:07:49] <elenril> we're preparing for ffos [18:07:58] <kshishkov> on ffcpu [18:08:40] <av500> using fflaws of ffphysics [18:09:23] <elenril> ffftw! [18:09:45] <av500> fffeierabend! [18:09:52] <twnqx> lol [18:09:58] <twnqx> av500: i got some of the chips [18:10:03] <twnqx> via TI's sample program \o/ [18:10:08] <twnqx> for free even :P [18:11:31] <_av500_> :) [18:13:28] <kshishkov> twnqx: so when FFmpeg is ported on them? [18:13:48] <twnqx> uh [18:13:52] <twnqx> to voltage regulators? :S [18:15:27] <kshishkov> why not? it can manipulate input after all [18:15:36] <twnqx> lol [18:15:42] <DonDiego> oh [18:15:46] <DonDiego> BBB: first kick? [18:15:47] <DonDiego> :) [18:21:54] <DonDiego> wikipedia is down [18:22:12] * DonDiego awaits world's end [18:22:41] <kshishkov> once even google.com wasn't resolving [18:23:54] <BBB> DonDiego: second :) [18:24:02] <drv> wikipedia works here, somebody said just DNS was broken somewhere? [18:25:26] <elenril> yeah, i get nxdomain for *.wikipedia.org [18:25:36] <elenril> wikipedia.org itself works fine though [18:25:46] <kshishkov> works here again [18:27:32] <drv> heh, en.wikipedia.org is a CNAME pointing to a CNAME here [18:27:33] <drv> how ugly [18:27:55] <kshishkov> drv: you can work on bink-b decoder [18:28:15] <drv> are there any samples other than that heroes game? [18:28:27] <drv> i had a look at it once, audio is different from current versions too [18:28:51] <kshishkov> video too [18:29:07] <drv> yep [18:29:28] <drv> maybe someday, still have things on my TODO list though ;) [18:29:35] <drv> flashsv2 decoder is kicking around somewhere [18:29:44] <kshishkov> anything completed? [18:30:20] <drv> not yet, was trying to get a working test for the other zlib-priming mode in the encoder, but haven't yet [18:37:17] <mru> av500: I disagree with that so-called guru on quite a few points [18:37:24] <mru> including his opinions on gcc [18:37:38] <mru> there are plenty of faults with gcc, and he manages to miss all of them [18:37:44] <kshishkov> FATE disagrees too [18:38:16] <mru> I've been planning to write a blog post in defence of gcc actually [18:41:35] <CIA-24> ffmpeg: rbultje * r22656 /trunk/libavformat/ (asf.c asf.h asfenc.c): [18:41:36] <CIA-24> ffmpeg: Move put_le16_nolen() to asf.c and give it a ff_ prefix. This way, it is easier [18:41:36] <CIA-24> ffmpeg: to share it with e.g. MMS. [18:41:36] <CIA-24> ffmpeg: Patch by Zhentan Feng <spyfeng gmail com>. [18:42:14] <BBB> so what does an IP of 0xc0a80081 mean? [18:42:21] <BBB> is that 127.0.0.1? [18:42:28] <BBB> probably not [18:42:31] <kshishkov> no [18:42:46] <kshishkov> 192.168.0.129 [18:42:49] <astrange> 192.168.0.129 [18:43:02] <drv> just take each octet and convert to decimal [18:45:25] <peloverde> If you ever watch /The Net/ staring Sandra Bullock, there is an IP with an octet greater than 255... awkward [18:45:47] <bilboed-pi> peloverde, http://www.echopic.com/7vh :) [18:46:54] <drv> i never knew florida was made of PCB [18:47:09] <peloverde> blol [18:48:26] <kshishkov> probably black is for swamps [18:48:35] <BBB> wbs: rtcp/bye was a qualification task last year [18:48:40] <BBB> wbs: it didn't get far, unfortunately ;) [18:48:47] <wbs> BBB: oh great ;P [18:49:03] <wbs> BBB: the bugfix in the follow-up thread should be quite obvious, right? [18:49:58] <BBB> if ret<0)return ret; [18:50:03] <BBB> then it's ok, feel free to apply [18:50:19] <BBB> (I want to prepare the code for forwarding AVERROR() conditions to caller [18:50:25] <BBB> eventually [18:50:28] <wbs> ah, of course, yeah [18:50:41] <j-b> cs011 as opposite to you, I have patches for support of ffmpeg-mt in VLC. [18:51:06] <j-b> especially to export the needed extra information [18:51:09] <DonDiego> j-b: that nick was already kicked :) [18:51:15] <j-b> oh, shit [18:51:43] <astrange> do i need to see these patches? [18:51:54] <j-b> astrange: those were never showed to you ? [18:51:55] <j-b> O_o [18:51:59] <j-b> is this a joke? [18:52:07] <astrange> nope [18:52:10] <j-b> OMG [18:52:15] * j-b needs to kill a few people [18:52:21] * j-b will be back in 5minutes [18:52:58] * mru lends j-b the shotgun [18:53:16] <CIA-24> ffmpeg: mstorsjo * r22657 /trunk/libavformat/rtsp.c: Handle errors returned from ff_rtsp_read_reply in udp_read_packet properly [18:56:24] <_av500_> mru: i do not agree with this "highly paid consultat"(tm) [18:57:11] * kshishkov does not trust consultants much at all [18:57:37] <mru> that's overgeneralising [18:57:44] <mru> I've worked with a few very good ones [18:58:21] <kshishkov> their share in total number of consultants you know being? [18:58:43] <kierank> presumably only "medical consultants" [18:58:53] <mru> I'm talking about software [18:59:21] <kshishkov> I've been a consultant too [18:59:24] <mru> there are different kinds of software consultants [19:00:11] <mru> the ones that just blather about "process" and make you buy some expensive tools (which they likely get a commission on) are useless [19:00:24] <kshishkov> synergy! [19:00:27] <mru> those that have some rare expertise and actually solve the problem for you are good [19:01:06] <Dark_Shikari> [C[C[C[C[C [19:01:20] <Dark_Shikari> lol, running on local line editing is hilarious [19:01:46] <Dark_Shikari> apparently pressing "right" 6 times will move right 6 times... and then send the special characters too [19:02:08] <mru> yep [19:05:33] <Kovensky> irssi loves sending special characters when you have high ssh latency [19:05:39] <Kovensky> because it think you're pasting shit [19:05:40] <Kovensky> >_> [19:05:54] <mru> I've seen that [19:06:09] <mru> but only when there's been an interruption of a few seconds [19:06:27] <Kovensky> happens to me a lot when I'm not @ home [19:06:54] <mru> I get it mainly on the phone [19:06:56] <Kovensky> here I use xchat with several tunnels to irssi-proxy; elsewhere I use ssh directly [19:07:18] <Kovensky> and the place I can access the fastest internet is @ college, which has... a 2mbit tube for the whole campus [19:07:35] <Kovensky> fabulous speeds there <_< [19:08:04] <Kovensky> here @ home I have a 1mbit line split among 6 computers ._. [19:08:11] <kshishkov> ours had 32kbps at our department back in 2003 [19:09:13] <Kovensky> internet @ college is p. unstable too, it's often down (the domain controller is often down too, so it's also garbage internally) [19:09:17] <drv> hm, school i used to attend reportedly had an OC-48 just for the dorms [19:09:26] <Kovensky> and professors randomly turn routers off >_> [19:09:32] <Kovensky> drv: :O [19:09:39] <drv> dunno if it was actually true though :P [19:10:26] <Kovensky> sometimes the latency there is so high it takes like 2 minutes after I input text until it is echoed by ssh [19:10:26] <kshishkov> students here haven't seen internet at uni at all, dorms have something though [19:11:16] <Kovensky> we also are forced to use a severely locked down win2k with the wrong resolution (LCD native res is 1024x768 or 1280x1024 on the bigger ones; all computers are forced to 800x600) [19:11:26] <Kovensky> the gamma settings are also bad [19:11:41] <kshishkov> we have CRTs at 60Hz here [19:11:51] <Kovensky> they used to have CRTs @ 60hz there too [19:11:57] <Kovensky> but they replaced all CRTs by LCDs [19:12:20] * Kovensky has seen K6s running on LCDs just because "they look modern" [19:12:40] * kshishkov concludes that Brazil is a richg country [19:13:03] <Kovensky> lol [19:13:52] * Kovensky concludes that the only reason his college has all this luxury is because the owner/CEO is a friend of the governor's brother-in-law (and the governor is the daughter of the local political overlord) [19:14:46] <Kovensky> the southeast region (São Paulo mostly) however is rich indeed [19:15:17] <Kovensky> but the distribution is awful (IIRC one of the worst in the world) [19:15:38] <kshishkov> same here [19:16:06] <kshishkov> Dontesk region is rich, current president and mafia come from it too [19:16:12] <kshishkov> *Donetsk [19:26:48] <_av500_> mru: i dont say all consultants are bad either [19:27:52] <_av500_> but his: "'m expensive, so expensive are teh tools" annoys me a bit [19:28:22] <kshishkov> maybe it's the other way round [19:28:50] <kshishkov> here consulting is often viewed as a reason not to work [19:29:30] <_av500_> as long as ppl payfor it... [19:30:14] <kshishkov> become an IP lawyer then [19:32:34] <_av500_> cannot, Id sue myself the 1st thing and lose... [19:32:54] <kshishkov> but all your money will go to you [19:33:03] <mru> he already has his money [19:33:18] <_av500_> no, govt has my money [19:34:12] <mru> didn't we talk about that yesterday? [19:34:43] <kshishkov> _av500_: you're lucky, here you're not supposed to have money anyway [19:34:45] * _av500_ must have missed it [19:35:40] <mru> kshishkov: hmm? wasn't that communism? [19:35:45] * Kovensky made an edit to wikipedia to fix an typo and intentionally put 'fox typo' on the edit reason field [19:35:48] <Kovensky> :3 [19:36:07] <Kovensky> who was it that foxed the original typo, reimar? [19:36:09] <kshishkov> mru: no, in communist state you're not supposed to know about money at all [19:36:18] <_av500_> Kovensky: you missspelled it: fix tzpo [19:36:25] <CIA-24> ffmpeg: siretart * r22658 /branches/ (0.5/libavcodec/vorbis_dec.c 0.5): [19:36:25] <CIA-24> ffmpeg: Check validity of channels & samplerate. [19:36:25] <CIA-24> ffmpeg: This may be security relevant. [19:36:25] <CIA-24> ffmpeg: Based on 2 patches by chrome. [19:36:25] <CIA-24> ffmpeg: backport r19975 by michael [19:36:39] <Kovensky> _av500_: wtf, what kbd layout do you use D: [19:36:58] <mru> qwertz I'd suppose [19:37:01] <mru> silly germans [19:37:10] <_av500_> azerty ftw! [19:37:26] <mru> where's awertz? [19:37:26] * Kovensky uses US layout with compose key [19:37:42] <Kovensky> I tried using dvorak in 2008 but gave up; was too lazy to type slowly [19:37:44] <kshishkov> mru: Alsase [19:38:04] <mru> dvorak is stupid [19:38:19] <mru> the arrangement of the letters makes very little difference [19:38:19] <kshishkov> Russians had "jcuken" layout [19:38:33] <mru> dvorak has been thoroughly debunked [19:38:44] <mru> what matters is where the non-alnum symbols are [19:38:59] <Kovensky> I have also used .se layout for a while, for the lulz [19:39:04] <mru> those that are frequently used in your (programming) language of choice of course [19:39:10] <mru> .se is impossible for coding [19:39:20] <Kovensky> heh [19:39:32] <Kovensky> I don't see me switching from US+compose any time soon [19:39:37] * _av500_ has := on F5 :) [19:39:37] <Kovensky> I can type whatever I want <3 [19:39:49] <Kovensky> _av500_: you dirty pascal programmer [19:39:49] <kshishkov> Kovensky: and I used it for typing Swedish and once because I had Swedish notebook for a while [19:39:58] <Kovensky> heh [19:40:04] <Kovensky> physically, my keyboard is br-abnt2 [19:40:10] * mru uses something loosely based on US + some mode_switch combos for swedish etc [19:40:23] * kshishkov uses pure US mostly [19:40:25] <Kovensky> due to my insistence on US+compose, I can't type on any other computer but mine >_> [19:40:26] <mru> physically, mine is blank [19:40:46] <kshishkov> we know [19:41:24] <Kovensky> br-abnt moves around too many important keys just to put diacritics on the right of the alnum block ._. [19:41:28] <mru> it keeps visiting relatives from borrowing my computer to read their viruses [19:41:31] <Kovensky> (and the ç) [19:41:37] <Kovensky> mru: heh [19:42:00] <DonDiego> BBB: rtpdec.h:143: warning: function declaration isn't a prototype [19:42:07] <_av500_> they cant click at virus? [19:42:14] <DonDiego> lu_zero: that also goes for you i guess :) [19:42:17] <kshishkov> mru: what about installing VMS for guest OS for their convenience? [19:42:33] <mru> on the old alpha? [19:42:58] <kshishkov> so it's IE3 under NT for them? [19:43:59] <mru> they can bring their own netbook [19:58:02] <wbs> BBB: I don't think changing auth types to weaker ones actually happen in practice - ok to skip support for that, removing the second auth_type variable? [19:59:15] <CIA-24> ffmpeg: vitor * r22659 /trunk/libavformat/nut.c: [19:59:15] <CIA-24> ffmpeg: Fix warning: [19:59:15] <CIA-24> ffmpeg: libavformat/nut.c: In function ?ff_nut_free_sp?: [19:59:15] <CIA-24> ffmpeg: libavformat/nut.c:80: warning: passing argument 4 of ?av_tree_enumerate? from incompatible pointer type [19:59:15] <CIA-24> ffmpeg: ./libavutil/tree.h:92: note: expected ?int (*)(void *, void *)? but argument is of type ?void (*)(void *, void *)? [20:10:26] <BBB> wbs: yes [20:10:31] <BBB> wbs: that's what I was hoping for ;) [20:10:46] <wbs> BBB: ok with me, too. simplifies stuff nicely :-) [20:11:31] <BBB> I think most of patch #1 was ok, you can post if you want and then I'll probably ok it [20:11:39] <BBB> then I have to review #3/#4 [20:11:53] * BBB kicks lu_zero into reviewing [20:17:56] <wbs> BBB: there, new series, with hopefully all of it fixed [20:18:19] <wbs> #1 is a bit larger now, when the realm="" parsing has been included for basic, too [20:20:43] <BBB> is there a particular reason that you're av_strdup()ing before copying the realm? [20:23:12] <BBB> I suppose it's because you write into it right? [20:23:39] * BBB replies [20:25:59] <wbs> the parser needs to be able to write into the string, for simplicity when parsing e.g. quoted strings and such [20:26:46] * BBB goes fiddle [20:56:59] <BBB> wbs: see reply, let's try to do this without any extraneous copies [20:58:28] <wbs> BBB: yeah, it struck me too that there's quite a bit of almost-similar parsing code in there [20:58:48] <BBB> probably even my code is far from optimal [20:58:55] <BBB> but should at least be a little better [20:59:06] * BBB goes take a break and look at it again in +/- 5 minutes [21:00:44] <BBB> also my callback_get_buf() is missing key and len as parameters to be used for strncmp()s [21:01:22] <BBB> the idea is that you can do a series of if (!strncmp(key, "realm=", len)) { *dest=realm; *dest_len=sizeof(realm); return;} etc. [21:13:17] <wbs> BBB: hmm, that's a relatively good idea. the choose_qop function needs to be modified for this to work, but except for that, it seems doable [21:16:37] <BBB> cool [21:17:01] <wbs> and there are a few of the loop conditions that may need tweaking, but I got the idea :-) [21:18:39] <BBB> yeah the pseudocode was a little rough [21:37:56] <wbs> BBB: any preference for formatting of the strncmp lines in callbacks? [21:38:06] <wbs> i.e., either this: [21:38:06] <wbs> } else if (!strncmp(key, "qop=", key_len)) { [21:38:06] <wbs> *dest = digest->qop; *dest_len = sizeof(digest->qop); [21:38:20] <wbs> or this: [21:38:24] <wbs> } else if (!strncmp(key, "qop=", key_len)) { [21:38:24] <wbs> *dest = digest->qop; [21:38:24] <wbs> *dest_len = sizeof(digest->qop); [21:38:37] <wbs> the former uses less lines, the latter is a bit more readable [21:39:06] <BBB> latter is better imo [21:39:36] <BBB> oh boy I have like 10 unreviewed patches [21:49:26] <mru> BBB: that's nothing, I have at least 10 _unstarted_ projects [21:49:55] <BBB> oh I have an uncounted number of those [21:50:00] <BBB> uncountable, also [21:50:11] <mru> dang, beat me to it [21:51:18] <BBB> :) [22:01:08] <BBB> wbs: in #1, remove the if (!params) return in parse_key_value() [22:01:14] <BBB> that shouldn't be needed [22:03:10] <BBB> also, your else at the bottom doesn't handle escaped chars [22:03:48] <BBB> for (; *ptr && *ptr != '\"'; ) { -> no init / incr, so make it a while [22:04:00] <BBB> almost right :) [22:17:04] <BBB> oh, and wbs, people here generally dislike '\0', I'm not sure why, but try to use 0 instead [22:17:13] <BBB> I keep making that mistake also [22:25:41] <wbs> BBB: removed the unnecessary if. the else case shouldn't handle escaped chars, they're only allowed within quoted strings iirc [22:32:55] <CIA-24> ffmpeg: mstorsjo * r22660 /trunk/libavformat/ (httpauth.h Makefile http.c httpauth.c): [22:32:55] <CIA-24> ffmpeg: Split out http authentication handling into a separate file [22:32:55] <CIA-24> ffmpeg: This prepares for adding support for more authentication methods [22:39:37] <CIA-24> ffmpeg: lu_zero * r22661 /trunk/libavformat/rtsp.c: Issue a warning if the received CSeq isn't the expected one [22:44:55] <CIA-24> ffmpeg: vitor * r22662 /trunk/libavformat/nutdec.c: [22:44:56] <CIA-24> ffmpeg: Fix warnings in NUT demuxer: [22:44:56] <CIA-24> ffmpeg: libavformat/nutdec.c: In function ?read_seek?: [22:44:56] <CIA-24> ffmpeg: libavformat/nutdec.c:862: warning: passing argument 4 of ?av_tree_find? from incompatible pointer type [22:44:56] <CIA-24> ffmpeg: ./libavutil/tree.h:44: note: expected ?void **? but argument is of type ?struct Syncpoint **? [22:44:56] <CIA-24> ffmpeg: libavformat/nutdec.c:871: warning: passing argument 4 of ?av_tree_find? from incompatible pointer type [22:44:57] <CIA-24> ffmpeg: ./libavutil/tree.h:44: note: expected ?void **? but argument is of type ?struct Syncpoint **? [22:46:23] <BBB> wbs: if you can quote the rfc on that, patch ok with me [22:47:41] <wbs> BBB: the only non-quoted values are algorithm and stale, which have fixed, nonescaped values [22:47:50] <BBB> ok [22:47:52] <BBB> then it's fine [22:47:56] <BBB> I see you already applied it ;) [22:48:43] <BBB> #2 should be rather small, but don't forget Michael maintains that file so make sure he's ok [22:48:48] <BBB> so no inline if()s etc. :) [22:49:07] <BBB> sth. like table = lowercase ? 'abcdef' : 'ABCDEF'; and then use that [22:49:18] <BBB> and it should of course be a separate patch [22:49:24] <wbs> yeah, did something like that [22:49:25] <BBB> bonus points if you remove the hack in rdt.c ;) [22:49:31] <wbs> I did :-) [22:49:50] <BBB> \o/ [22:51:05] <BBB> so I suppose I should now review the rtsp patch? [22:51:39] <BBB> can you re-send them after #2 is done? [22:51:45] <wbs> yes, will do [22:52:29] <wbs> the first one of the rtsp patches is dead simple, http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100324/6534c… [22:52:48] <BBB> bonus point: if you rename your variable 'table' into 'hex_table', you don't need the last line of your patch [22:52:57] <BBB> (which renames hextable into table, basically) [22:54:14] <wbs> good point. :-) [22:54:17] <BBB> also: do a search for %02x in your #2 patch, there's several left [22:54:54] <BBB> oh wait that's intended of course [22:54:55] <BBB> hmm... [22:55:31] <wbs> I guess that could be done using ff_data_to_hex too, yeah [22:55:40] <BBB> what's the resoluton of lfg? [22:56:02] <wbs> 32 bit [22:56:10] <BBB> if it's 32 bit (since we don't care about endianness; it's random, after all), then just fill 4 ints with the response, and pass the resulting array to ff_data_to_hex [22:56:23] <BBB> but snprintf() is ok also [22:56:26] <BBB> don't worry about this one [22:56:29] <BBB> leave it for now ;) [22:56:38] <wbs> ok :-) [22:56:50] <BBB> any reason it's 50 bytes and not 21? [22:57:08] <BBB> and nc 10 instead of 9? [22:57:26] <BBB> rest of #2 is ok, if tested [22:57:27] <wbs> nope, they're all just rough estimates of what should be "enough" [22:58:08] <wbs> could lower them not to waste too much stack [22:58:31] <BBB> if you change these, patch ok [22:58:35] <BBB> need me to confirm on-list? :) [22:58:43] <wbs> nah, it's ok :-) [22:58:45] <BBB> I'll look at the rtsp ones tonight, I hope [22:59:02] <wbs> just waiting for an ack from someone on the ff_data_to_hex [22:59:43] <BBB> that'd be Michael [22:59:45] <BBB> #3 is ok also [23:00:53] <wbs> ok, will apply that one [23:01:50] <BBB> as for #4, I'd remove the separate allocation of rt->auth, just make it a static inline array of whatever size auth[] has in the call to ff_url_split() now [23:02:15] <BBB> ff_rtsp_send_cmd_with_content() that change should be separate from this patch [23:03:11] <BBB> wht's the purpose of the find_method_and_url() piece in there? [23:03:30] <wbs> the digest auth needs the http/rtsp verb and url separated [23:03:41] <wbs> e.g. "POST" and "/path/to/file" [23:03:54] <wbs> but they're all given as a large buffer to rtsp_send_cmd [23:04:42] <BBB> oh right [23:05:06] <BBB> how difficult would it be to change that? [23:05:17] <BBB> </crazy idea> [23:05:26] <wbs> i looked into it - in quite a few place we add extra parameters to the request by appending them to the cmd [23:05:55] <BBB> yeah, I remember [23:07:51] <CIA-24> ffmpeg: mstorsjo * r22663 /trunk/libavformat/rtsp.c: Make ff_rtsp_send_cmd simply call ff_rtsp_send_cmd_with_content [23:08:18] <wbs> as for doing the change to ff_rtsp_send_cmd_with_content separate to the rest of the patch - that'd temporarily break basic auth [23:08:46] <wbs> (currently we add the credentials blindly, but with this in place, we always first try without credentials and then add them if necessary) [23:16:33] <wbs> except for that, made rt->auth statically allocated as you suggested [23:38:21] <BBB> wbs: can you apply that first then? [23:38:35] <BBB> wbs: although... [23:38:40] <BBB> make sure it always adds it to every command [23:38:46] <BBB> not for each command "try without, then with"

1 0

IRC log for 2010-03-23
by irc＠mansr.com 24 Mar '10

24 Mar '10

[00:33:23] <Dark_Shikari> bah, how do I make a script that iterates over files with spaces in their names? [00:33:43] <mru> depends [00:33:53] <Dark_Shikari> i.e. for file in ls .... ; type [00:33:56] <Dark_Shikari> of thing [00:34:11] <mru> for file in *; do ...; done not working? [00:34:29] <Dark_Shikari> ah, that works [00:34:31] <mru> iirc wildcard expansion does the right thing [00:34:35] <Dark_Shikari> yup, it does. [00:34:59] <mru> $(command) expansion happens before word splitting though [00:35:13] <Dark_Shikari> yup. [00:37:22] <mru> if a simple wildcard didn't match the right files it would be a bit more complicated of course [02:17:55] <CIA-24> ffmpeg: michael * r22640 /trunk/libavcodec/ (7 files): [02:17:55] <CIA-24> ffmpeg: Change ref_index structure so it matches how its organized in h264. [02:17:55] <CIA-24> ffmpeg: Also revert the related error concealment hotfix. [03:35:52] <CIA-24> ffmpeg: mru * r22641 /trunk/libavcodec/ (fft.h arm/Makefile arm/rdft_neon.S rdft.c arm/fft_init_arm.c): ARM: NEON optimised RDFT [04:38:20] <peloverde> mru, I noticed the NEON RDFT... any word on how HE-AAC performs on ARM (vs libfaad2)? [06:28:52] <av500> maybe ffmpeg should at least move to http://svnhub.com/ [06:29:22] <kshishkov> prepare to be moved by KotH there [06:30:26] <pJok> god morgon kshishkov :) [06:30:44] <kshishkov> goda morgnar [06:31:26] * pJok hands kshishkov the view of skåne going by [06:31:42] * kshishkov goes to webkameror.se [06:33:36] <thresh> moroning [06:33:54] <pJok> nothing like the smell of öresundståg brakes in the morning [06:34:58] <kshishkov> try smell from IC3 diesel engine [06:35:45] <pJok> they aren't that bad [06:35:56] <pJok> try the old dsb wagons [06:36:10] <pJok> the sound of the brakes makes you think that you are still in 1960 [06:36:26] <kshishkov> our railroads still have to reach 1960s [06:36:52] <pJok> hehe [06:36:57] <kshishkov> I think heaters there still use wood [06:37:14] <kshishkov> (better ones use coal though) [06:37:39] <thresh> aaaaand you cant ask to make the heat lower [06:38:14] <kshishkov> thresh: wrong country. You can't ask for _anything_ [06:38:23] <av500> thresh: that is a universal fact! :) [06:38:33] <av500> existing heaters are always too hot [06:39:07] * av500 loves to watch people fight about opening windows on trains and busses [06:39:25] <pJok> av500, its easy here... you can't open the windows [06:39:31] <pJok> at least not on the trains [06:39:42] <kshishkov> no need to do that either [06:39:46] <av500> http://german-way.com/blog/2009/02/13/german-phobia-killer-draft/ [06:39:55] <thresh> kshishkov: you can ask for a tea [06:40:17] <kshishkov> thresh: and hot water is free when available [06:40:55] <pJok> kshishkov, depends on if you are in the airconned section of the train or not... it made a big difference this summer in the öresundstrains if you were in the non-aircon section or not [06:40:57] * kshishkov tries to forget his travels on local railroads and not having nightmares about it [06:42:00] <thresh> well, moscow-kiev 'branded' train is alrite [06:42:13] <kshishkov> pJok: I travelled by IC3 and electric version of IC3 last August [06:42:17] <thresh> moscow-sevastopol otoh is not [06:42:36] <pJok> IR4 [06:42:47] <pJok> they've been rebuilt, most of them for regional traffic [06:42:52] <pJok> ie not as comfy anymore [06:43:15] <kshishkov> you have not seen out trains [06:43:27] <pJok> no, i haven't [06:43:32] <kshishkov> lucky you [06:43:54] <kshishkov> kiev-kharkiv "express" 1st class still gives me nightmares [06:44:13] <kshishkov> while 2nd class there was merely sucky [06:45:13] <pJok> there is a 1sst class? [06:45:26] <kshishkov> it is called so [06:45:58] <kshishkov> but actually it's worse than 2nd [06:46:20] <pJok> http://www.kharkovapartmentsforrent.com/images/tourinfo/kharkov_train.jpg [06:46:55] <kshishkov> yes, that's it [06:48:12] <pJok> looks about as modern as the old dsb trains [06:48:34] <thresh> but they're modern [06:48:44] <thresh> at least in this part of the world, they are still produced [06:49:01] <kshishkov> cars are produced in Ukraine [06:49:35] <kshishkov> and you have power outlets only in 1st class cars (and they don't work there either) [06:50:22] <pJok> http://www.jernbanen.dk/Fotos/Motor/DSB_ME1507_2006.jpg [06:51:16] <kshishkov> here they haven't grasped an idea of rolling stock not looking like brick [06:52:23] <pJok> annoyingly i can't seem to find the wagons that those old trains drag along [06:52:29] <pJok> http://lh3.ggpht.com/_SxGMP8rXRho/RW43J_SNABI/AAAAAAAAArY/-L6Ksd0Ky1k/06100… [06:58:18] <pJok> http://www.l-eriksen.dk/toge/materiel/andre/blandet/1/3200.jpg [06:58:25] <pJok> they are blue now, but still as horriblle [07:01:18] <kshishkov> ours are more horrible [07:03:05] <kshishkov> http://rupoezd.ru/vagon/platskart.php [07:05:08] * av500 likes the seat numbering [07:05:43] <thresh> yeah, is it some kind of quest to buy seats in the middle of a wagon [07:05:56] <thresh> so you're not buggered by a nearby toilet [07:06:21] <kshishkov> Ð±ÐŸÐºÐŸÐ²Ð°Ñ Ð¿ÐŸÐ»ÐºÐ° Ð²ÐŸÐ·Ð»Ðµ ÑÑÐ°Ð»ÐµÑÐ° - ÑÑÐŸ ÐºÐ»Ð°ÑÑÐžÐºÐ°! [07:06:24] <av500> pick a middle number, like 36 :) [07:06:36] <thresh> 38 is waay worse :) [07:06:39] <kshishkov> yes, and you'll be near the toilet for sure [07:08:12] * kshishkov still gets warm feeling when he remembers SJ Liggvagn [07:08:23] <pJok> kshishkov, those are quite comfy [07:08:34] <thresh> that's why I miss a lot of good bike races in Crimea: there is no suitable flight there, and you spend ~24 hours in a train like that. Sum that with my height (i don't quite fit on a sleeping berth') and you will know my feelings. [07:08:37] * pJok took one from Stockholm to Malmö [07:09:10] <pJok> seat numbering is a silly international standard [07:09:11] <kshishkov> pJok: I took it other way around (and Stockholm-Oslo-Stockholmk) [07:09:32] <pJok> didn't get as much sleep [07:09:36] <pJok> but thats not unusual [07:09:42] * thresh has plans on testing french trains this summer [07:09:42] <pJok> since i sleep badly in general [07:09:47] <kshishkov> thresh: my feet usually reach sideway bench [07:10:01] <thresh> we somehow need to get from Andorra to Geneve [07:10:06] <pJok> the best thing about sleeping while traveling is that your effectiive traveltime is reduced to 0 [07:10:22] <kshishkov> thresh: and while Swedesh are not that high I was able to sleep extremely well in their wagons [07:10:50] <thresh> kshishkov: well, if you're travelling in a compartment, it is just about ok for me :) [07:11:00] <kshishkov> thresh: http://upload.wikimedia.org/wikipedia/commons/thumb/c/c4/Liggvagnskupe.jpg/… [07:11:11] <thresh> ha [07:12:20] <kshishkov> and I've tried travelling in a coupe carriage here - still got nightmares. They should have _ventilation_ at least [07:12:58] <pJok> ventilation is overrated [07:13:04] <thresh> i've only been to Moscow-Kiev train in coupes [07:13:08] <kshishkov> and still not enough place for feet not mentioning strange metal thingies on the walls that make you fell uncomfortable [07:13:09] <thresh> s/to/on a/ [07:15:06] <kshishkov> pJok: if you'll ever be my enemy then I'll invite you to try Ukrainian railroads [07:16:48] <pJok> hehe [07:18:29] <pJok> i will try not to reach that point [07:19:23] <kshishkov> another thing is that railroad car toilets here still made from metal [07:21:59] <pJok> i think they are too in those old dsb wagons [07:22:45] <votz> thresh: how tall are you? [07:23:16] <thresh> ~ 190 cm [07:23:25] <votz> ah nice, getting up there :) [07:23:40] <kshishkov> thresh: same height here [07:24:27] <votz> ~200cm [07:24:58] <kshishkov> pJok: our railroads are on the same quality as automobile roads, so riding our intercity "expresses" (with max speed less than ÃresundstÃ¥g) is quite uncomfortable too [07:26:38] <pJok> hehe [07:27:02] <pJok> even though the öresundståg have a top speed of 180kmh, they still have an average speed of around 50kmh [07:27:35] <kshishkov> express kiev-kharkiv has an average speed ~90 kmh [07:27:50] <kshishkov> but it makes only two stops on whole 500km route [07:28:11] <votz> thresh: kshishkov: do you know what percentile 190cm puts you where you guys live? [07:28:25] <kshishkov> no idea [07:28:58] <kshishkov> oh, here's another tall guy [07:29:13] <votz> superdump? :) [07:29:22] <kshishkov> yep [07:29:29] <kshishkov> as tall as me IIRC [07:29:46] * av500 looks down on kshishkov [07:29:49] <superdump> mmm, about the same i guess, yes [07:29:53] <votz> av500: how bout you? [07:29:59] <av500> 195 [07:30:03] <votz> when not on stilts :P [07:30:45] <av500> there's always hiking boots and wild hair... [07:30:56] <votz> lots of tall people :D [07:32:04] <kshishkov> who cares? [07:33:26] <votz> why a fellow tall person of course [07:34:34] <kshishkov> in my case it's rather fellow thick person [07:48:09] <KotH> hoi zämä [07:48:48] <av500> salut [07:48:55] <kshishkov> shalom [07:56:06] <CIA-24> ffmpeg: mstorsjo * r22642 /trunk/libavformat/rtsp.c: [07:56:06] <CIA-24> ffmpeg: Reconstruct the RTSP URL, in order to remove the auth part from the URL sent to the server [07:56:06] <CIA-24> ffmpeg: Don't modify the user-specified s->filename at all, keep all modifications [07:56:06] <CIA-24> ffmpeg: locally and in rt->control_uri. [08:00:12] <CIA-24> ffmpeg: mstorsjo * r22643 /trunk/libavformat/rtsp.c: [08:00:12] <CIA-24> ffmpeg: Parse options in the RTSP URL only from the last question mark onwards [08:00:12] <CIA-24> ffmpeg: This helps if the URL (erroneously?) contains question marks within the path. [08:01:25] <CIA-24> ffmpeg: mstorsjo * r22644 /trunk/libavformat/rtsp.c: Handle multiple RTSP transport options properly by adding all of them into the mask [08:30:43] <bcoudurier> hi guys [08:30:59] <kshishkov> hi script [08:31:15] <bcoudurier> I'm behind currently :) [08:31:25] <andoma> :) [08:31:33] <kshishkov> something went wrong [08:33:07] <bcoudurier> Dark_Shikari, I retested --threads 0 in lossless mode and in default settings is still slower than ffv1 on my 720p24 source [08:34:23] <Dark_Shikari> x264's default settings aren't really useful for lossless [08:34:26] <Dark_Shikari> speed-wise [08:34:37] <Dark_Shikari> anything slower than --preset faster is basically wasteful [08:34:46] <Dark_Shikari> gives like 1% total compression at most [08:34:59] <Dark_Shikari> also, as I said, the compression difference between ffv1 and x264 depends heavily on how noisy the source is [08:35:06] <Dark_Shikari> if spatial prediction is more useful than temporal, ffv1 will win [08:37:16] <twnqx> if you want a fast lossless h.264 encoder... there was a 30line C source recently :P [08:37:46] <kshishkov> you can have 30K line crappy H.264 encoder too [08:38:05] <twnqx> but that one is FAST [08:38:21] <Dark_Shikari> what one [08:38:53] <twnqx> the 30line one :P [08:39:00] <twnqx> no compression at all etc [08:39:37] <bcoudurier> humm ffv1 dates 2004 [08:40:07] <Dark_Shikari> twnqx: heh, cpm-olnly? [08:40:10] <Dark_Shikari> *pcm [08:40:29] <twnqx> Dark_Shikari: the discussin was in #x264 Oo [08:40:38] <kierank> he wrote a blog post about it [08:40:47] <twnqx> two days ago or so [08:40:55] <Dark_Shikari> I don't read every line of chat >_> [08:43:23] <twnqx> Dark_Shikari: http://www.cardinalpeak.com/blog/?p=488 [08:45:27] <av500> ...A great exercise to get to know h.264 and encoders in general.... [08:45:30] <av500> ??? [08:45:43] <kshishkov> yes, not a little exercise [08:48:28] <Dark_Shikari> that's cheating [08:48:34] <Dark_Shikari> he hardcoded the SPS/PPS ;) [08:49:14] <bcoudurier> rofl [08:49:23] <Dark_Shikari> and mb headers [08:49:26] <Dark_Shikari> and slice headers [08:49:28] <Dark_Shikari> yeah, that's cheating =p [08:50:18] <twnqx> ;) [08:50:22] <twnqx> and the image size! [08:50:34] <Dark_Shikari> that's implicit from hardcoding the sps [08:50:59] <twnqx> i was a bit surprised he didn't use the defines in the constants though [08:52:24] <twnqx> but i like the comment "There you have itâa complete h.264 encoder that uses minimal CPU cycles, with output larger than its input!" [08:53:08] <kshishkov> and fixed input size [08:53:35] <twnqx> argh, i lost my flac to alac command :( [13:45:39] <BBB___> merbzt1: done [13:45:44] <BBB___> hm, my nick is weird [13:46:07] <merbzt1> tnx [13:46:08] <jai> Big Buck Bunny with a tail [13:49:06] * Terminating due to: TERM [14:12:29] * /join #ffmpeg-devel ... [14:12:31] *** TOPIC: Welcome to the FFmpeg development channel. That is, development of FFmpeg, not using FFmpeg, nor libav*. | Users should redirect their questions to #ffmpeg | FFmpeg 0.5.1 has been released! | this chat is now publicly logged. [14:12:31] *** TOPICINFO: superdump!~rob@unaffiliated/superdump, 1267604523 [14:46:51] * Terminating due to: TERM [14:48:48] * /join #ffmpeg-devel ... [14:48:50] *** TOPIC: Welcome to the FFmpeg development channel. That is, development of FFmpeg, not using FFmpeg, nor libav*. | Users should redirect their questions to #ffmpeg | FFmpeg 0.5.1 has been released! | this chat is now publicly logged. [14:48:50] *** TOPICINFO: superdump!~rob@unaffiliated/superdump, 1267604523 [15:35:17] <BBB> spyfeng: did you send the patch yet? [15:41:48] <twnqx> broken mov: http://www.biol.uzh.ch/filme/molekulare_zellbiologie/animations/enzyme_cata… [15:42:00] <twnqx> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x13cc3c0]Could not find codec parameters (Data: 0x0000, 159 kb/s) [15:42:26] <twnqx> well, at least not decodable by ffmpeg :P [15:54:23] <merbzt1> twnqx: what says mplayer ? [15:54:45] <twnqx> same thing, since he tries LAVF [15:54:57] <merbzt1> vlc ? [15:55:07] <twnqx> "command not found" [15:55:09] <twnqx> :P [15:55:17] <merbzt1> \o/ [15:55:27] <merbzt1> almost quote worthy [15:57:49] <twnqx> nah, forget it i'll blame broken file [15:57:57] <twnqx> just tried quicktime in winblows [16:10:09] <jishnu7> hello all... i hav a problem after compiling... [16:11:45] <jishnu7> any thr one to help me..? [16:11:52] <jishnu7> any one thr to help me..? [16:14:12] <av500> -> #ffmpeg [17:23:18] <CIA-24> ffmpeg: cehoyos * r22645 /trunk/libavformat/dv.c: [17:23:18] <CIA-24> ffmpeg: Fix seeking in DV when filesize is unknown. [17:23:18] <CIA-24> ffmpeg: Patch by Tomas H?rdin, tomas D hardin A codemill D se [17:40:41] <CIA-24> ffmpeg: cehoyos * r22646 /trunk/ (doc/ffplay-doc.texi ffplay.c): [17:40:41] <CIA-24> ffmpeg: Add a loop option to ffplay. [17:40:42] <CIA-24> ffmpeg: Patch by Robert Kr?ger, krueger signal7 de [17:55:59] <CIA-24> ffmpeg: diego * r22647 /trunk/libavcodec/h264.c: [17:55:59] <CIA-24> ffmpeg: Remove unused variable, fixes the warning: [17:55:59] <CIA-24> ffmpeg: libavcodec/h264.c:1562: warning: unused variable `s' [17:59:31] <CIA-24> ffmpeg: cehoyos * r22648 /trunk/libavcodec/mpegvideo_enc.c: [17:59:31] <CIA-24> ffmpeg: Always check if ff_alloc_picture() succeeds. [17:59:31] <CIA-24> ffmpeg: Patch by Pavel Pavlov, pavel summit-tech ca [18:20:22] <DonDiego> ramiro: you around? [18:20:24] <DonDiego> hi guys [18:20:45] <mru> hi DonDiego [18:21:53] <DonDiego> siretart: you around? [18:24:51] <kierank> any idea what a "bitstream key" could refer to? [18:25:01] <mru> context? [18:25:05] <kshishkov> encryption or ID [18:25:10] <mru> some kind of decryption key? [18:26:13] <kierank> only context I have is a string saying "16-bit Dolby E streams must use bitstream keys. Enabling bitstream keys and continuing." [18:44:26] <jermy_> are the git and svn repositories kept closely in sync? [18:45:40] <mru> yes [18:45:58] <mru> the svn post-commit hook updates the git repos [18:46:39] <jermy> fair enough. Just wondering if the first thing to do about a dependency issue would be to switch back to svn [18:46:58] <mru> what's the problem? [18:46:59] <jermy> (and yes, I realise that asking any more would be more suitable over in #ffmpeg) [18:47:06] <jermy> "No rule to make target `libavformat/rtp_asf.h', needed by `libavformat/rtpdec.o'. Stop. [18:47:23] <mru> seems like a header file was deleted [18:47:35] <mru> make clean or rm libavformat/rtpdec.d [18:48:32] <DonDiego> -MP could solve that [18:48:49] <mru> and break god knows what else [18:49:01] <mru> these things are fragile [18:49:17] <jermy> thanks, mru. I'm an idiot for not cleaning first [18:49:19] <DonDiego> removed headers are a known problem [18:49:35] <jermy> I assumed a new configure would have fixed the dependencies [18:49:42] <mru> yes, but the side-effects of the workaround are not known [18:49:45] <jermy> (to require a new compile) [18:50:20] <DonDiego> just make a run with -MP and one without [18:50:27] <DonDiego> compare the .d files [18:50:27] <mru> not good enough [18:50:32] <mru> I know what it does [18:50:40] <mru> I don't know for sure what effect that has on make [18:50:51] <mru> playing with empty rules is a dangerous game [18:51:04] <mru> especially when we have headers that actually are generated [18:51:16] <DonDiego> but these have hardcoded rules [18:51:25] <DonDiego> as they have to have [18:51:25] <mru> gcc doesn't know that [18:52:48] <mru> I've broken things enough times to know I need to be careful [18:52:58] <mru> and don't see this fixing any big problem [18:53:09] <mru> headers are rarely deleted [18:59:08] <BBB> Vitor1001: thanks for the patch, I'll ry to get rid of the +1 offset at the top of the code, that way the yasm code should work well also [18:59:26] <BBB> might need a few nights of coffee-drinking+screen-staring [19:00:54] * kshishkov knows some devs who manage to live without coffee [19:01:21] * mru thought code quality was directly tied to strenght of coffee [19:02:13] <kshishkov> Benjamin said he does not like coffee [19:05:03] <kshishkov> so I'd like to see what he can writeafter a mug of strong coffee [19:05:11] <BBB> I was about to suggest the same thing [19:05:24] * BBB kicks kshishkov back into wvp2 REing [19:05:32] * kshishkov resists [19:05:35] <BBB> hmpf [19:05:45] * mru throws a pack of coffee beans at kshishkov [19:05:46] <BBB> can you copy rtmpe into ffmpeg's rtmp? [19:06:28] <kshishkov> mru: what brand is that? [19:06:51] <mru> the best [19:06:55] <kshishkov> rtmpe requires some encrypting [19:07:38] <BBB> so A) go write encrypting for lavu, or B) link to libssl [19:07:47] <kshishkov> here coffee is roasted from the best acorns [19:08:00] <kshishkov> BBB: there's no option B in FFmpeg ;) [19:08:10] <mru> over here acorns are used to make risc machines [19:08:21] <BBB> what's so bad about libssl? [19:08:27] <BBB> everyone uses it already anyway [19:08:29] <Dark_Shikari> over here squirrels eat them [19:08:37] <jai> the openssl code is a bit ugly iirc [19:08:45] <mru> understatement of the day [19:08:57] <mru> and some distros are afraid of its licence [19:08:59] <BBB> whereas ffmpeg's code is ultra-clean [19:09:06] <elenril> isn't libssl incompatible with gpl? [19:09:08] <jai> comparatively, yes [19:09:11] <mru> elenril: no [19:09:12] <BBB> not to mention that all distro's love ffmpeg's licensing "problems" [19:09:17] <jai> :/ [19:09:32] <BBB> as long as you don't copy ssl code into a gpl project, you're fine [19:09:34] <BBB> linking is ok [19:09:42] <kshishkov> and I told we need libavcrypt long time ago [19:09:47] <BBB> kshishkov: go go go! [19:09:55] * BBB sends a sixpack coke cola to kshishkov [19:10:02] <mru> we already have des and aes [19:10:12] <kshishkov> BBB: nah, I accept only Trocadero [19:10:30] <BBB> is that vodka? [19:10:33] <jai> and mru's patch for a zlib replacement [19:10:34] <elenril> http://en.wikipedia.org/wiki/OpenSSL#Licensing ? [19:10:35] <jai> :) [19:10:54] <mru> as a general rule, wikipedia is wrong [19:11:00] <mru> especially on legal matters [19:11:10] <mru> it's written by freetards [19:11:29] <kshishkov> BBB: no, http://en.wikipedia.org/wiki/Trocadero_(drink) [19:11:56] <BBB> swedish [19:11:57] <BBB> should've known [19:11:58] <kshishkov> probably the only caffeinated stuff I drank last year (not counting tea of course) [19:13:49] <saintd3v> weeeeeee ffh264 :P [19:14:12] <kshishkov> and rejected again! [19:15:06] * saintd3v pokes peloverde [19:15:15] <peloverde> pong [19:16:48] <saintd3v> a little birdie said you had some local changes to the aac encoder? [19:17:24] <kshishkov> to aac decoder too, so what? [19:18:41] <ramiro> DonDiego: pong [19:18:41] <peloverde> I do have some local changes, but they would make more sense after some changes I have yet to make but those won't be ready until I finish PS and a paid side project [19:19:12] <saintd3v> peloverde: exactly what I was wondering, thanks :D [19:19:44] <DonDiego> ramiro: i have a fix for the altivec vs. runtime-cpudetect failure, can you review? [19:20:20] <ramiro> I thought you had fixed that already... [19:20:28] <ramiro> I can take a look [19:23:58] <DonDiego> ramiro: http://www1.mplayerhq.hu/~diego/altivec_runtime.diff [19:40:30] <BBB> bcoudurier: that was a joke... [19:41:00] <BBB> DonDiego: gives me an empty document [19:43:28] <kshishkov> BBB: you may be gravely wrong about it beong a joke [19:43:34] <kshishkov> *being [19:43:39] <BBB> potentially [19:44:44] <DonDiego> BBB: the patch i posted? [19:44:53] <DonDiego> it's definitely not empty... [19:45:04] <Vitor1001> BBB: sorry was away from the keyboard [19:45:20] <BBB> oh wait, firefox downloads it instead of displaying it [19:45:28] <BBB> isn't .diff served as text/plain by mphq? [19:45:57] <DonDiego> no, as text/x-diff [19:46:05] <DonDiego> firefox is stupid for not displaying it inline [19:46:13] <kshishkov> maybe as original mimetype? [19:46:13] <BBB> Vitor1001: is ok, I'll try to 16-align all calls to rdft() over the next few days, thanks for the patch [19:46:17] <BBB> Vitor1001: should be possible [19:46:18] <Vitor1001> BBB: If you have any problem with that DCT stuff, feel free to ask me [19:46:20] <mru> text/* means it's, guess what, text... [19:46:22] <BBB> sure [19:46:53] <mru> there are unaligned rdft calls? [19:46:54] <DonDiego> safari does it [19:47:09] <DonDiego> is there a way to override such stupidity in firefox? [19:47:44] <mru> yes, use a different browser [19:47:46] <kshishkov> patch the source [19:47:51] <DonDiego> ramiro: reping [19:47:58] <mru> the android browser displays that url btw [19:48:02] <DonDiego> mru: well, what do you use? [19:48:39] <mru> still firefox [19:48:48] <mru> chrome insists on having dbus installed [19:48:51] <mru> and I'm not that stupid [19:49:05] <CIA-24> ffmpeg: vitor * r22649 /trunk/ (5 files in 2 dirs): Implement the discrete sine/cosine transforms DCT-I and DST-I [19:49:25] <kshishkov> ELinks displays attachments without any fuss [19:49:36] <kshishkov> and loads faster that Firefox on my hw too [19:50:03] <elenril> kshishkov: http://tvtropes.org/pmwiki/pmwiki.php/Main/CaptainObvious [19:50:37] <kshishkov> elenril: that link reflects its contents [19:55:01] <ramiro> DonDiego: what was the configure command that failed? [19:57:18] <DonDiego> --enable-runtime-cpudetect --disable-altivec [20:04:11] <CIA-24> ffmpeg: vitor * r22650 /trunk/ (libavcodec/avcodec.h doc/APIchanges): Bump minor version, I forgot in the last commit [20:06:48] <ramiro> DonDiego: your patch seems correct to me. [20:07:35] <ramiro> actually I don't even think it needs ARCH_PPC anymore, since HAVE_ALTIVEC implies that. [20:09:24] <DonDiego> right.. [20:25:05] <CIA-24> libswscale: diego * r30952 /trunk/libswscale/utils.c: [20:25:05] <CIA-24> libswscale: Do not compile AltiVec code when AltiVec is not available; not even in [20:25:05] <CIA-24> libswscale: runtime cpudetection mode. [20:25:05] <CIA-24> libswscale: Fixes compilation with '--enable-runtime-cpudetect --disable-altivec'. [20:27:13] <Vitor1001> DonDiego: Does it compiles now on PPC with "--disable-optimizations"? [20:36:21] <DonDiego> dunno [20:36:24] <DonDiego> i can try.. [20:37:08] * DonDiego starts a compile [21:21:38] * BBB needs a good gpg howto [21:21:43] <BBB> or pgp [21:21:47] <BBB> what's that stuff called again? [21:23:59] <mru> man gpg [21:31:09] <j-b> don't read it, you will never understand it and you'll save some time [21:33:08] <BBB> I see firepgp supports gmail [21:33:10] <BBB> hmmm [21:33:17] <mru> I don't trust crypto/security systems I can't understand [21:33:41] <mru> selinux being a good example [21:33:50] <mru> that's totally fucking incomprehensible [21:34:18] * elenril heard a few people saying it's NotThatBad [21:34:34] <elenril> tomoyo is quite nice though [21:35:47] <BBB> people around me keep telling me the dutch tax system is NotThatBad [21:38:17] * elenril kicks spherical coordinates [21:41:42] <mru> BBB: is it like the swedish system? [21:41:49] <mru> it works like this: [21:41:54] <BBB> that's the one that is worse [21:41:57] <mru> 1. How much money did you make last year? [21:42:04] <mru> 2. How much have you got left? [21:42:08] <mru> 3. Send it in. [21:42:11] <Dark_Shikari> lol [21:42:14] <BBB> lol :) [21:42:19] <BBB> dutch system is like this: [21:42:27] <BBB> how good is your accountant? [21:42:38] <mru> that's universal [21:42:41] <BBB> take that number as a percentage of your total pre-tax income and that's your return [21:42:42] <Dark_Shikari> american system is like this: [21:42:50] <Dark_Shikari> 1) send us all the money in your right pocket. [21:42:58] <Dark_Shikari> 2) are you self-employeed? take everything from your left pocket too, we want that. [21:43:17] <Dark_Shikari> 3) make a list of your business expenses and deduct them. But 90% of the things on your list don't actually count. [21:43:36] <Dark_Shikari> 4) You didn't send us enough. [21:43:39] <mru> here's mine: [21:43:47] <mru> 1. Get paid into an offshore account. [21:43:52] <mru> 2. Don't tell anyone. [21:43:55] <Dark_Shikari> 2. get audited by the IRS [21:44:11] <mru> so tell them about enough to keep them happy [21:45:29] <thresh> in Russia it's 1. Nobody cares 2. If they do, it doesn't matter if you paid it right. [21:48:22] <BBB> uhm... [21:48:37] * BBB thinks this thing is confusing [21:49:11] <mru> BBB: if you find it confusing you're not making enough money [21:49:33] <BBB> no, pgp is confusing [21:49:37] <BBB> my taxes are just annoying [21:49:42] <kierank> all countries have an extra step. If you earn above XXX taxes are optional [21:49:50] <BBB> it says "an unknown error occurred, this cannot be fixed right now" [21:49:52] <BBB> o so [21:50:12] <BBB> as in, thanks, that was incredibly useful and a true testimony to the quality of free software in general and firepgp specifically [21:50:21] <mru> BBB: if you earn enough, that's what the taxman says too [21:50:28] <BBB> :) [22:00:06] * BBB frustrated [22:00:09] * BBB disables firepgp again [22:00:21] <BBB> this is yet another piece of shit software like only freetards can make [22:00:24] <BBB> I cannot believe this [22:00:44] <BBB> don't people go to design school before they try to expose something to end users? [22:00:51] <mru> no [22:03:28] * BBB feels like shooting the firepgp developer [22:10:25] <jermy> So... what's the usual process for sponsoring some ffmpeg development? Contact a likely developer directly, or announce centrally? [22:11:07] <peloverde> jermy, usually sending an inquiry to the list unless you have a specific developer in mind [22:11:40] <peloverde> A few developers are listed at http://ffmpeg.org/consulting.html [22:13:04] <jermy> That'd suggest Baptiste a good person to talk to, then [22:13:24] <jermy> bcoudurier: Likely to be at NAB? [22:17:03] <Dark_Shikari> depends on what you want done basically [22:17:51] <jermy> Well, it's AVC-Intra - and I'm sure it's been mentioned a few times [22:18:05] <mru> what's that? [22:18:14] <mru> another bastardised avc variant? [22:18:47] <jermy> Pretty much. Intra-only, and 10bit at either 50 or 100Mbit [22:19:04] <mru> what? fixed frame size? [22:19:23] <jermy> Yeah [22:19:27] * mru looks at dnxhd [22:19:53] <mru> and you want to decode that stuff? [22:19:55] <mru> or encode it? [22:19:58] <jermy> There's a veritable clusterfsck of these things. Also check out Apple's Pro-Res [22:20:19] <mru> fixed frame size does make some things simpler [22:20:21] <jermy> decode only, so we don't mind throwing away two bits if ffmpeg will only otherwise support 8-bit [22:20:25] <mru> at the expense of quality [22:20:43] <BBB> I think ffmpeg already does 10bit formats, no? [22:20:45] <jermy> Very easy to write to tape :) [22:20:53] <mru> are the frames normal avc otherwise? [22:21:00] <jermy> Oh, sorry then, my misunderstanding [22:21:31] <mru> does ffh264 do 10-bit? [22:22:02] <jermy> I _think_ it's just pushing quite a few parameters to the limits of what would be considered usual, and using a few extra features not normally seen [22:24:06] <mru> if it's all in the spec we should support it [22:24:13] <mru> except probably the 10-bit part [22:24:25] <jermy> I'd probably have to try to work out what's currently missing [22:24:40] <mru> what happens if you try to decode such a file? [22:24:41] <jermy> There's 3D transforms in the spec - is that supported? [22:24:56] <jermy> gimme one second - I'm just building current head [22:25:02] <mru> in the h264 spec? [22:25:06] <mru> I don't remember seeing those [22:25:12] <mru> mpeg4-2 sure [22:25:20] <mru> it has everything and then some [22:26:08] <kierank> is there an avc intra spec? [22:26:24] <BBB> didn't x264 already support that? [22:26:31] <BBB> if so, there must be [22:26:31] <BBB> no [22:26:32] <BBB> ? [22:27:00] <mru> x264 supports fixed frame size encoding [22:27:03] <mru> iirc [22:27:19] <mru> I don't recall anything about that being per some specific spec [22:27:50] * BBB goes home [22:30:05] <Dark_Shikari> we have soc projects for both 10-bit and 4:2:2... [22:30:09] <Dark_Shikari> necessary for avc intra [22:30:29] <jermy> I'm currently getting http://jeremy.publication.org.uk/ffmpeg_avcidecode [22:30:58] <Dark_Shikari> or do you mean decoding as opposed to encoding [22:31:09] <jermy> just decoding for us [22:31:20] <Dark_Shikari> that would actually be really good [22:31:26] <Dark_Shikari> it would reduce the amount of work we would have to do [22:32:10] <mru> looks like the mxf demuxer isn't recognising the stream properly [22:32:54] <peloverde> mxf was recently failing regressions on some configs, did that get fixed? [22:32:58] <jermy> Hrm. I probably have an old version that has some MXF fixes on it [22:34:59] <peloverde> MXF fails on x86_32 / Linux / gcc svn 156187 [22:38:10] <jermy> More fun - this is attempting to decode an extracted stream from the file directly: http://jeremy.publication.org.uk/ffmpeg_avcidecode_stream [22:38:34] <kierank> jermy: does jm decode it? [22:39:27] <jermy> Yes, I think it does [22:39:39] <jermy> but I'll build and test it quickly [22:42:24] <kurosu> Could someone tell me if Ramiro Polla ever joins this IRC channel, and if yes, under what nickname? [22:43:30] <DonDiego> kurosu: ramiro has the nickname ramiro ... [22:44:08] <kurosu> thanks [22:49:14] <jermy> Yup, JM looks happy with it [22:49:37] <jermy> slow, but happy (that might be to do with writing out the raw YUV to a NFS share, though) [22:52:43] <mru> no, that's just jm being jm [23:06:03] <jermy> Although clearly I'm not having a very good attempt at converting from JM's output - http://jeremy.publication.org.uk/00014F.avi (450K, resized to 320x180) [23:36:27] <CIA-24> ffmpeg: ramiro * r22651 /trunk/libavdevice/x11grab.c: [23:36:27] <CIA-24> ffmpeg: x11grab: AVFormatParameters are always passed from av_open_input_stream(), [23:36:27] <CIA-24> ffmpeg: there is no need to check for it. [23:47:14] <j-b> peloverde: did you find the fix? [23:48:30] <j-b> jermy: you have AVC-Intra files? From Panasonic cameras? [23:59:44] <CIA-24> ffmpeg: jbr * r22652 /trunk/libavformat/ (Makefile flacenc.h flacenc_header.c): [23:59:44] <CIA-24> ffmpeg: Put ff_flac_write_header() in a separate C file to allow it to be shared without [23:59:44] <CIA-24> ffmpeg: duplicating code or adding a dependency on vorbiscomment.o.

1 0

IRC log for 2010-03-22
by irc＠mansr.com 23 Mar '10

23 Mar '10

[00:29:20] <mru> http://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/server/RequestProcess… [00:35:48] <peloverde> I always hated those Java APIs, multilevel factories belong in the special olympics [06:54:55] <thresh> moroning, fellow ffmpeg developers. [06:55:04] <thresh> kshishkov: does it remind you of anything? http://cheezpictureisunrelated.files.wordpress.com/2010/03/1291359111636215… [06:55:06] <kshishkov> morning, road worker [06:55:49] <kshishkov> yes, it's from series "guess country by picture" [06:56:00] <thresh> exactly [06:58:45] * av500 wonders what mathematical functions describes the full length of the chair back [06:59:23] <kshishkov> in Russia chair is used to describe math functions [06:59:35] <av500> kshishkov: come on, it cannot be too bad, he has chalk at least [06:59:46] <av500> y=chair(x) [07:00:21] <av500> and there are lights on in the room [07:01:15] <kshishkov> av500: yes, but I remember that sometimes students had to get chalk somewhere [07:02:18] <kshishkov> sometimes stealing or borrowing it from the next room [07:02:47] <av500> borrow? you bring back a fine white powder? [07:02:48] <kshishkov> and light was not permanent either (this being .ua, not .ru) [07:03:19] <kshishkov> no, "borrow" in local sense - you ask if you can borrow it and never return anything [07:04:15] <av500> ah [07:37:53] <KotH> o_0 [07:38:01] <KotH> kshishkov: 5th world country? [07:38:16] <kshishkov> 3rd world! [07:43:35] <KotH> can't be. uk is already a 3rd world country and they dont have such probs ;) [07:44:13] <kshishkov> what about sixties there? [07:48:35] <KotH> dunnno.. i'm not that old [07:49:41] <kshishkov> I'm not good with history but I heard they had quite similar conditions around there [07:49:54] <kshishkov> (including borrowing from IMF) [07:51:18] <KotH> well.. .ch had famines, just 100y ago... [07:51:40] <KotH> but thanks to the germans, we're now one of the richest countries in the world :) [07:52:46] <kshishkov> I heard it was true for Sweden 150 years ago too\ [08:23:30] <nfl> jai: ? [08:25:45] <wbs> Yuvi: you're familiar with xiph stuff, right? care to take a look at the av_xiphlacing doxy patch on the ML? [08:28:29] <siretart`> morning [11:49:25] <pross-au> OT: okay it only took 55 minutes for open office to open my 5MB Word 2003 spreadsheet file [11:50:18] <twnqx> Oo [11:51:48] <merbzt> open source roxx [11:52:31] <kshishkov> strewth! It's Java-based a bit so your <4GB RAM boxes are no good [11:52:57] * kshishkov tries to avoid running OOo on MacMini with 512MB at all [11:53:02] <pross-au> actuallys thats true kshishkov . the xml processing (this was an XML word 2003 file) is done in java [11:54:28] * kshishkov remembers trying to import small 50-page table into oowrite [11:59:21] <Compn> is that why google docs will not import any .docx over 900kb ? [11:59:37] * Compn has 5mb .docx and nothing to read it [12:00:16] <kshishkov> IIRC there was docs to odf converter at SF [12:00:31] <kshishkov> 20mb in size or something [12:00:37] <kshishkov> written by the very M$ too [12:00:52] <thresh> speaking of which, 32630 admin 16 0 13.7G 13G 6252 S 0.0 93.9 3:45.73 php [12:01:03] <thresh> nice, aint it? [12:02:48] <kshishkov> ain't nice indeed [12:03:06] <kshishkov> was that "PHP with all crap" installation? [12:08:23] <pross-au> kshishkov: it just attempted to autosave [12:08:29] <pross-au> that god for xkill [12:09:02] <kshishkov> kill -9 is usually good too [12:09:05] <thresh> kshishkov: rather 'developer with crap instead of brains' [12:10:09] <kshishkov> thresh, I don't suspect you of doing Java programming otherwise it would be pretty normal memory consumption for you. [12:10:23] <thresh> it isnt nice at all [12:10:39] <thresh> and not really normal, though that machine has 32G ram [12:10:43] <kshishkov> nothing that sudo kill -9 can't fix [12:11:01] <kshishkov> Parkinson's Law in action [12:11:01] <thresh> nah, that VPS was specially crafter for that project [12:11:09] <thresh> crafted [12:11:48] <thresh> managers think it's cheaper to buy a new server for EUR 20k each year than to rewrite it [12:12:14] <twnqx> 20k in developer salaries + side costs... would that be enough for a rewrite? [12:12:25] <kshishkov> yes, someone needs to create an environment for memory hogs [12:12:49] <twnqx> that's like one senior guy, 4 month [12:13:34] <thresh> that would be more than enough [12:13:46] <kshishkov> since this is not Moscow nor Russia nor Kiev, 20K EUR would be enough for 2 devs annual salary. Or 20 PHP monkeys [12:13:57] <pross-au> 20 PHP monkeys!! [12:14:17] <thresh> kshishkov: it is Moscow [12:14:41] <thresh> we're like ~10km away from it, so the salaries are +- Moscow ones [12:15:02] <kshishkov> ah, then about half a year of salary at most [12:15:19] <thresh> yep [13:03:27] <bubu74> hi all [13:03:35] <bubu74> there is someone [13:03:37] <av500> no [13:04:21] <bubu74> thnks [13:05:55] <jai> lol [13:07:15] <av500> or was I too unfffriendly? [13:07:46] <kshishkov> you've not kicked him at least [13:07:58] <thresh> so that was ultra friendly [13:31:02] <BBB> kshishkov: are you currently actively working on that wvp2 dll? [13:34:22] <wbs> BBB: ping on http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-March/085070.html :-) [13:34:39] <BBB> ugh, I'm behind on reviewing patches again? :) [13:35:10] <wbs> that depends on your definition of 'soon' :-) [13:40:55] <BBB> I forgot :) [13:43:44] * BBB should review all other patches also [13:43:45] <BBB> ... [13:54:34] <lu_zero> mru: ping [13:55:18] <mru> pong [13:55:38] <lu_zero> I read more stuff about the ogg-apologists [13:55:52] <lu_zero> "ogg made for streaming" seems the new excuse [13:56:11] <mru> but it fails at that too [13:56:11] <av500> it is perfect [13:56:21] <lu_zero> what I wonder is [13:56:28] <av500> that makes the whole "use ogg for yuotube" fail [13:56:32] <lu_zero> what the they would mean for "streaming" [13:56:37] <av500> since yuotube is not about "streaming" [13:56:42] <lu_zero> youtube uses already rtp for streaming [13:56:49] <lu_zero> thus they fail horribly [13:57:17] * lu_zero should make ffmpeg work with that btw... [13:57:21] <lu_zero> but [13:57:51] <wbs> lu_zero: what would be required to support that? [13:58:17] <lu_zero> wbs amr and h263-2000 format support apparently [13:58:45] <wbs> lu_zero: I added support for those formats not too long ago :-) [13:58:52] <lu_zero> uhm [13:59:01] <lu_zero> then why it isn't working here? [13:59:31] <wbs> no idea, haven't tested it against youtube, but normal 3gp files served over rtsp work fine at least [13:59:54] <lu_zero> btw I'm about to make ffmpeg reject message with bogus or missing cseq [13:59:56] <av500> lu_zero: I was refering to useing ogg for html5 video [14:00:29] <lu_zero> do you have opinions about that? [14:00:54] <lu_zero> av500: that isn't streaming at least IMHO [14:00:55] <lu_zero> ^^ [14:01:00] <j0sh> lu_zero, can you look over my xiphlacing doxy patch? [14:01:13] <av500> exactly, so if ogg is for streaming, it is NOT for html5 video, no? [14:01:21] <lu_zero> j0sh: tell me where to look [14:01:25] <lu_zero> ogg isn't for streaming [14:01:32] <j0sh> lu_zero, in the theora depayloader ML thread [14:01:38] <av500> [14:55] <lu_zero> "ogg made for streaming" seems the new excuse [14:02:00] <lu_zero> j0sh: the exact subject? [14:02:01] <wbs> lu_zero: being more strict with cseq sounds ok to me [14:02:33] <lu_zero> wbs: do you have a list of public testcase server btw? [14:02:38] <j0sh> lu_zero, http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-March/085441.html [14:02:45] <wbs> lu_zero: nope [14:03:14] <j0sh> wbs, thanks for all the reviews, i never would've caught half those issues [14:03:24] <lu_zero> check ffmpeg -i rtsp://rtsp2.youtube.com/CjcLENy73wIaLgkCo6RfCuxKFhMYDSANFEIQdGVzdC1kb21pbm… [14:04:13] <lu_zero> j0sh: please give me a link [14:05:39] <j0sh> lu_zero, http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100322/14417… [14:05:59] <lu_zero> thank you [14:06:46] <lu_zero> j0sh: seems ok [14:06:58] <wbs> lu_zero: hmm, seems to fail in following the redirect, looking into it... [14:07:02] <lu_zero> still I'm sorry I couldn't even find the thread =_= [14:07:11] <lu_zero> it seems to follow the redirect [14:07:31] <lu_zero> now I'm noticing that here seems to fail because it just uses udp [14:08:01] <lu_zero> (and here I'm beside a stupid adsl modem+router) [14:12:49] <av500> mru: I guess you saw that: http://www.osnews.com/story/23018/Ogg_Objections_Problems_with_the_Containe… [14:12:55] <wbs> lu_zero: I've messed up redirects in some refactoring recently, that's easy to fix... but then the amr depacketizer doesn't like the fmtp being "a=fmtp:99 octet-align", since it would want octet-align=1 [14:13:06] <mru> av500: yes, saw that [14:14:15] <wbs> lu_zero: ... but except for that, it seems to work [14:14:53] <lu_zero> wbs: I see [14:15:37] <wbs> lu_zero: generally, are such fmtp lines correct at all? the rfc only mentions explicitly octet-align=0/1 [14:20:27] <justlooking> i take it its not supposed to do this rtsp://rtsp2.youtube.com/CjcLENy73wIaLgkCo6RfCuxKFhMYDSANFEIQdGVzdC1kb21pbm…: Error while parsing header [14:23:27] <justlooking> that error is with the curent http://ffmpeg.arrozcru.org/autobuilds/ and your supplyed line above lu_zero [14:25:04] <lu_zero> wbs: you were saying? [14:25:06] <lu_zero> ^^ [14:27:09] <CIA-24> ffmpeg: michael * r22629 /trunk/libavcodec/ffv1.c: Remove the word "experimental" [14:27:14] <lu_zero> about octet-align seems a quirk indeed [14:29:38] <wbs> lu_zero: posted both patches required for successful playing of the url to the ML [14:33:04] <lu_zero> commented before it get swamped in the mailbox [14:33:12] <BBB> wbs: patch ok from me too [14:33:18] <BBB> (fw) [14:33:22] <BBB> does youtube work then? [14:36:07] <wbs> BBB: yes, with those both patches, the link above does work for me [14:36:32] <BBB> apply apply apply [14:36:35] <BBB> uhm [14:36:57] <lu_zero> BBB: question for you [14:37:01] <BBB> ok [14:37:02] <lu_zero> I'm going to check cseq [14:37:06] <BBB> ok [14:37:08] <lu_zero> should I warn or should I reject [14:37:09] <lu_zero> ? [14:37:15] <BBB> please add reordering first [14:37:25] <BBB> if possible [14:37:27] <lu_zero> reordering on rtsp? [14:37:32] <lu_zero> or rtp? [14:37:42] <BBB> cseq is pkt sequence number, no? [14:37:50] <BBB> that's rtp, yes [14:37:57] <lu_zero> cseq as the sequence number in rtsp ^^ [14:38:09] <BBB> rtsp has a sequence number? :) [14:38:11] <lu_zero> our current parser is quite lax [14:38:12] <lu_zero> yes [14:38:39] <BBB> do we currently parse it? [14:38:42] <lu_zero> yes [14:38:52] <BBB> grep cseq rtsp.c gives me nothing [14:38:59] <lu_zero> uh? [14:39:23] <lu_zero> rt->seq [14:39:24] <lu_zero> } else if (av_stristart(p, "CSeq:", &p)) { [14:39:24] <lu_zero> snprintf(buf1, sizeof(buf1), "CSeq: %d\r\n", rt->seq); [14:39:31] <BBB> grep -i [14:39:33] <BBB> aha [14:39:37] <lu_zero> that one [14:40:11] <BBB> does it fix a bug? [14:40:56] <BBB> I think warning is better, and then update the cseq accordingly anyway [14:41:17] <BBB> that way we can test how good/bad it is before making it reject [14:41:20] <lu_zero> BBB: so if cseq is missing or not updated overwrite it and warn [14:41:29] <BBB> yes [14:41:35] <BBB> say we go from 1120 to 1122 [14:41:37] <BBB> update it anyway [14:41:38] <BBB> and warn [14:41:46] <BBB> because likely we'll go to 1123, 1124 afterwards [14:42:25] <BBB> I want to see if it triggers before I say "reject it" [14:42:29] <BBB> I agree reject would be nice [14:42:36] <BBB> once we've tested it with warn for a short while [14:42:45] <BBB> to make sure it doesn't do crazy stuff with some servers [14:42:47] <BBB> you never know [14:43:42] <CIA-24> ffmpeg: mstorsjo * r22630 /trunk/libavformat/rtsp.c: [14:43:42] <CIA-24> ffmpeg: Use the caller's RTSPMessageHeader in rtsp_setup_input_streams [14:43:42] <CIA-24> ffmpeg: Currently, the caller doesn't get the status_code and location for rediects, [14:43:42] <CIA-24> ffmpeg: since rtsp_setup_input_streams uses a copy of RTSPMessageHeader of its own. [14:45:19] <CIA-24> ffmpeg: mstorsjo * r22631 /trunk/libavformat/rtpdec_amr.c: Interpret valueless attributes in AMR ftmp lines as being 1 [14:48:08] <lu_zero> BBB: let me see if it works [14:58:42] <CIA-24> ffmpeg: mstorsjo * r22632 /trunk/libavcodec/avcodec.h: [14:58:42] <CIA-24> ffmpeg: Add doxygen docs for av_xiphlacing [14:58:42] <CIA-24> ffmpeg: Patch by Josh Allmann (joshua allmann gmail com) [14:58:56] <wbs> j0sh: congrats on getting your first(?) patch applied. :-) [15:00:20] <j0sh> haha it was my first patch, thanks! [15:05:03] <CIA-24> ffmpeg: michael * r22633 /trunk/libavcodec/ffv1.c: [15:05:03] <CIA-24> ffmpeg: Throw out last experimental warning that was printed for colorspaces with more than [15:05:03] <CIA-24> ffmpeg: 8 bits per component. This does no good except scaring users away. [15:07:58] <CIA-24> ffmpeg: mstorsjo * r22634 /trunk/libavformat/ (rtsp.c rtspenc.c): Add support for TCP as lower transport in the RTSP muxer [15:07:59] <CIA-24> ffmpeg: mstorsjo * r22635 /trunk/libavformat/rtsp.c: Reindent [15:10:19] <lu_zero> BBB: as we parse the lines we don't have a way to know when the cseq is missing w/out doing something quite ugly [15:11:29] <lu_zero> (e.g set the rt->seq to -1 and see if it got changed later) [15:14:20] <BBB> that's not so ugly [15:14:29] <BBB> in fact, I'd consider it the right thing [15:14:39] <BBB> why don't we fill out reply->seq instead of rt->seq? [15:14:53] <BBB> oh, we do [15:14:59] <BBB> so, simply init it to -1 [15:15:04] <BBB> if unset, abort() [15:15:16] <BBB> if set, compare to rt->remote_seq [15:15:17] <BBB> right? [15:15:34] <BBB> rt->seq is ours, reply->seq is "them" [15:15:46] <av500> is there a way to tell configure to run again with the same options as last time? Or am I missing something? [15:15:58] <mru> make config [15:16:11] <lu_zero> let me reread [15:16:14] <av500> thx [15:16:18] <wbs> j0sh: almost there, now. :-) [15:16:19] * lu_zero is doing two things at the same time [15:16:22] * av500 missed something :) [15:16:37] <lu_zero> in one I'm trying to figure out how to prepare a stupid ui [15:16:42] <wbs> av500: make config is the best thing since sliced bread. :-) [15:16:44] <lu_zero> the other to check rt->seq [15:17:06] <lu_zero> BBB: you are right =_= [15:17:32] <mru> you can also copy&paste the configure flags from the ffmpeg banner [15:17:37] <mru> it's all properly quoted [15:17:49] <mru> useful if you don't have the build tree around [15:18:06] <av500> right [15:18:10] <j0sh> wbs, yup, recompiling/testing (caus the doxy patch touched avcodec.h, heh) [15:18:32] <wbs> j0sh: great - is there any public test url that I could try it out on btw? [15:18:44] <BBB> lu_zero's website has a test one [15:18:48] <j0sh> i just used a local instance of feng and gst-rtsp [15:19:32] <lu_zero> media.lscube.org should have one [15:19:46] <lu_zero> j0sh: do they work the same way? [15:20:07] <j0sh> wbs, rtsp://media.lscube.org:554/tests/rms_profumo_1.ogv [15:20:27] <j0sh> lu_zero, i havent tried that url yet, testing now... [15:20:55] <j0sh> wait, what do you mean by work the same way? [15:20:59] <j0sh> both have theora payloaders [15:21:13] <BBB> j0sh: whether the two are compatible [15:21:15] <BBB> they should be [15:21:18] <BBB> both based on the same spec [15:21:26] <av500> rtsp://media.lscube.org:554/tests/rms_profumo_1.ogv: Error while parsing header [15:21:43] <lu_zero> j0sh: media.lscube.org uses feng so if your local feng is working [15:21:51] <lu_zero> then media should as well [15:21:54] <j0sh> yeah both seem to work, although the streams they send are different... gst-rtsp will use multiple frames per rtp packet, feng doesnt [15:22:56] <j0sh> but TBH i'm not 100% sure if the frame concatenation code really works, i dont know if vp3.c will detect multiple frames per avpacket [15:23:11] <lu_zero> ffplay decodes something? [15:23:16] <j0sh> yeah it does [15:23:51] <wbs> j0sh: uhm, that rtsp url gives 404 [15:24:08] <j0sh> wbs, yeah i just noticed too (ffplay decodes fine locally) [15:24:10] <BBB> which reminds me that our RTSP error reporting is seriously poor [15:24:20] <lu_zero> checking the location now... [15:24:36] <lu_zero> seems somebody _re_moved them instead moving them =_= [15:24:54] <lu_zero> BBB: our network error reporting is poor [15:24:55] <j0sh> lu_zero, feng likes to segfault after playing a few theora videos [15:25:03] <BBB> that too [15:25:07] <lu_zero> j0sh: please fill a bug [15:25:08] <wbs> BBB: isn't requiring the user to fire up wireshark to find out the actual error acceptable? ;P [15:25:33] <lu_zero> bugs.lscube.org [15:25:46] <j0sh> lu_zero, will do... need to narrow down a reproducible test case first :) [15:25:47] <lu_zero> that code hadn't been touched in years^^; [15:25:51] <lu_zero> thank you =) [15:28:32] <BBB> good work btw [15:28:42] <BBB> another depayloader :) [15:29:07] <av500> libavdepayload? [15:29:27] <BBB> nah [15:29:36] <BBB> libavformat_open("rtsp://"); is enough [15:30:05] <j0sh> if anything we need a ffbeautifycode tool... i never realized my patch had so many spacing inconsistencies, heh [15:31:30] <lu_zero> j0sh: I have 3 lines in vim to do that [15:31:59] <lu_zero> and git usually tell you most of the issues in its default color diff [15:32:12] <j0sh> time to ditch svn then [15:32:38] <lu_zero> j0sh: I'd put a SoC just to do that... [15:32:39] <ramiro> Kovensky: have you ever tried mplayer with mingw-w64? [15:34:20] <j0sh> thats half the reason i havent done the common-code refactoring with vorbis yet -- i have too many changed files for this patch, can't do something like svn --exclude [15:34:46] * mru recommends using git [15:34:48] <lu_zero> =| [15:35:10] <mru> it's impossible to work on several things at the same time with svn [15:35:11] * BBB tried git and failed [15:35:15] <mru> try harder [15:35:16] <lu_zero> mru: nobody merged swscale and ffmpeg... [15:35:26] <BBB> quilt works in a completely broken but ok'ish way [15:35:32] <mru> lu_zero: I can do it in git [15:35:40] <mru> I found an easy enough way [15:35:51] <mru> which wasn't possible last time I looked at it [15:35:55] <lu_zero> BBB: fetch from the vlc wiki the git config for svn users [15:36:00] <lu_zero> oh [15:36:04] <lu_zero> which one [15:36:36] <mru> the problem now is that michael and diego are dead set against git [15:37:31] <jai> :/ [15:37:54] <jai> how do they get any work done with svn [15:38:07] <mru> beats me [15:38:20] <Compn> why hasnt anyone modified git to allow typo fixing in comments? :P [15:38:21] <jai> then again, michael doesn't really do the whole patch workflow :) [15:38:22] <lu_zero> michael shouldn't [15:38:36] <mru> Compn: it's possible, it just rewrites the entire history afterwards [15:38:39] <lu_zero> his only constraint is to get the tree merged [15:38:42] <Compn> ah [15:38:56] <mru> lu_zero: michael insists on "svn cp" [15:38:59] <mru> git doesn't have that [15:39:06] <mru> nevermind git tracks copies much better [15:39:08] <lu_zero> what's svn cp? [15:39:21] <mru> svn's broken copy tracking [15:39:27] <Compn> copies a file and all its history to a new file [15:39:28] <av500> it does not track [15:39:32] <Compn> then you chop the file down [15:39:33] <av500> it just copies [15:39:43] <mru> av500: that's why it's broken [15:39:53] <lu_zero> used to do selective history overwrite or to move stuff away? [15:39:55] <av500> it works as a copy [15:39:57] <mru> git manages to ferret out the precise origin of every line [15:40:14] <av500> mru: agreed [15:40:15] <mru> even when pieces from multiple files are pulled together [15:40:25] <mru> svn doesn't even begin to do that [15:40:29] <av500> no [15:40:35] <Compn> lu_zero : move stuff from one file to another mostly [15:40:45] <Compn> like splitting svq1 and mpeg4 decoder or so [15:40:53] <mru> nor does svn handle code moving around within a file [15:41:43] <lu_zero> uhm [15:41:58] <lu_zero> interesting [15:42:01] <mru> it just shows the lines as deleted in one place and added in another [15:42:10] <mru> git detects blocks of lines moving within a file [15:42:25] <mru> if you haven't tried "git gui blame" yet, do it [15:46:29] <j0sh> wbs, patch sent! *high five* [15:54:23] <elenril> in the last git vs svn flame it didn't seem like michael was dead set against git [15:54:53] <av500> that leaves doego? :) [15:54:57] <av500> diego [15:55:25] * twnqx understands that [15:55:31] <twnqx> git is hard to understand. [15:55:49] <lu_zero> twnqx: git isn't harder to understand than svn [15:55:54] <lu_zero> if you start from git [15:55:58] <lu_zero> or mercurial [15:56:04] <elenril> git is just different [15:56:04] <lu_zero> instead of cvs [15:56:07] <elenril> and _awesome_ [15:56:43] <lu_zero> still [15:56:46] <twnqx> what is really pissing me off about git [15:56:59] <twnqx> is that it stores all the stuiff that belongs on the server on my local harddisk. [15:57:12] <mru> that's what makes it so awesome [15:57:16] <av500> ack [15:57:18] <mru> it's not a server-client thing [15:57:20] <jai> +1 [15:57:24] <av500> slow server connection sucks [15:57:29] <twnqx> yeah, it's really awesome to download 1GB useless codes to get 100MB of source [15:57:35] <av500> once! [15:57:39] <mru> and the entire git history is smaller than one svn checkout [15:57:46] <lu_zero> twnqx: overall git storing the whole history takes less space than svn taking just twice your sources... [15:57:52] <twnqx> still GREAT if you just want the source and have a 30kb/s umts link [15:58:06] <mru> git is more bandwidth-efficient than svn [15:58:12] <siretart> git doesn't support changelog editing, which is used quite a lot in ffmpeg [15:58:19] <twnqx> svn with "give me THAT revision, and compress it?" [15:58:36] <elenril> git can do that too iirc [15:58:38] <lu_zero> siretart: you mean commit message editing? [15:58:46] <elenril> not that i've ever needed it [15:58:51] <siretart> lu_zero: sorry. yes, I mean that [15:59:19] <mru> and how the ffmpeg svn repo ends up containing 46k files is beyond me [15:59:32] <lu_zero> mru: uh? [15:59:38] <lu_zero> how so? [15:59:40] <siretart> elenril: not without breaking every existing clone of the affected revisions [15:59:57] <elenril> siretart: i was talking about shallow checkout [16:00:06] <siretart> elenril: oh, I see. [16:00:29] <lu_zero> siretart: the best way to to do such thing is having a separate branch for lint [16:00:53] <siretart> still, I'd love to see libswscale moved to ffmpeg, which would be a necessary before moving to git anyway [16:01:11] <siretart> lu_zero: lint? [16:01:20] <mru> commit message editing is used _only_ by diego [16:01:29] <elenril> anyway, commit message editing is used so much in ffmpeg _because_ svn allows it [16:01:33] <mru> the fact that he does that a lot is irrelevant [16:01:53] <mru> most of the edits are just adding/removing punctuation anyway [16:01:55] <lu_zero> siretart: you keep a/many scratch branches [16:02:30] <lu_zero> have a pull request and in that phase you rewrite the commit messages/history and other fine fixes [16:03:18] <lu_zero> so you keep the pull tree as clean as possible when you have public work tree [16:03:37] <siretart> mru: that is not necessarily right. I see lots of svn:log changes by stefano, mstorjo, michael, kostya, lorenm. I could to some statistics on that, but from skimming over the list, I wouldn't say that diego leads that list [16:03:52] <lu_zero> but I consider that bordering perfectionism [16:04:10] <mru> they only do it because diego tells them to [16:04:20] <mru> or because they fear he will [16:04:43] <lu_zero> anyway you might abuse git push -f and git checkout origin [16:04:50] <lu_zero> and archive more or less the same result [16:04:58] <lu_zero> but is a _bit_ ugly [16:05:17] <mru> editing history breaks every last clone out there [16:05:21] <mru> you don't want that [16:05:52] <siretart> how does git-svn deal with edited changelogs? does it update already imported revisions? [16:05:59] <mru> no [16:12:31] <mru> that would break any clones or branches you might have [16:14:40] <lu_zero> siretart: keep in mind that commit message in svn are optional metadata [16:15:08] <lu_zero> I'm not sure that those changes were tracked [16:15:18] <siretart> lu_zero: I'm not arguing technically, but how ffmpeg *uses* svn. [16:15:35] <siretart> lu_zero: technically, I'm convinced that git is superior to svn in many ways, no need to convince me of that [16:16:42] <iive> i thought that every git commit gets assigned unique uuid or something. in that case the text message could be relevant only if the uuid is derived from it. [16:16:56] <mru> so what's more important, fairly pointless message editing or actually usable branching etc? [16:17:15] <mru> iive: the commit hash includes the message [16:17:59] <av500> mru: that just means you have to try harder to come up with a better commit msg :) [16:18:15] <siretart> mru: looking at the frequency of editing svn logs, I fear that for ffmpeg, the former seems more important [16:18:36] <mru> to one dev [16:18:38] <lu_zero> we could put aspell as pre merge requirement in the server.... [16:18:44] <mru> one who does very little actual development no less [16:19:20] <mru> you're going about this the wrong way [16:19:34] <mru> you're looking only at what we'd lose by ditching svn [16:19:36] <siretart> you could try disabling that in svn for a few weeks and see who other than diego complains [16:19:38] <mru> not at what we'd gain [16:19:52] <mru> diego would kill me [16:19:54] <siretart> that feature is disabled by default anyway, after all [16:20:01] <elenril> or we could switch to git and see who complains ;) [16:20:25] <mru> switching to git isn't a trivial task [16:20:52] <mru> I'll need to make the repo read-only for a couple of days [16:20:58] <iive> btw, in git it is easier to revert the commit, so to satisfy diego he could revert the commit and demand new with proper message, could he? [16:21:00] <mru> merge it all together and manually clean out some mess [16:21:11] <siretart> I'd say get rid of the svn:external and place a copy of libswscale in svn first, and see what flamewars that causes [16:21:14] <mru> then set up an authentication system, obtain ssh keys from all devs etc, etc [16:21:23] <mru> siretart: very, very bad idea [16:21:55] <siretart> iive: reverting a commit in git is to create a revert commit. so you get 3 commits instead of 1 fixed one. plus 2 for any additional iteration [16:21:57] <mru> it will make checking out an old version impossible [16:22:15] <siretart> why? isn't svn:external a versioned property? [16:22:19] <mru> no [16:22:24] <mru> don't think so at least [16:22:30] <mru> versioning isn't the svn way [16:23:14] <lu_zero> siretart: svn:props aren't tracked I'm afraid [16:23:32] <siretart> lu_zero: depends. some are, some are not [16:24:43] <siretart> AFAIUI at least. and after reading the svn book, I fear mru is right, and svn:external isn't [16:25:40] <mru> if it weren't for that, we'd have put the current rev of libsws in ffmpeg long ago [16:25:55] <mru> and simply let history progress from there [16:26:28] <mru> the old history would of course still be in the mplayer repo [16:26:42] <siretart> so you propose to convert to git with libswscale commits woven in? [16:26:57] <mru> if we ever go git, that's what I'll do [16:27:11] <mru> but it's needs manual intervention [16:27:14] <mru> the svn history isn't clean [16:27:21] <CIA-24> ffmpeg: mstorsjo * r22636 /trunk/ (6 files in 2 dirs): [16:27:21] <CIA-24> ffmpeg: RTP depacketization of Theora [16:27:21] <CIA-24> ffmpeg: Patch by Josh Allmann (joshua allmann gmail com) [16:28:49] <lu_zero> j0sh: congratulations =) [16:28:59] <mru> he's earned it [16:29:07] <j0sh> thanks! (what does voice do?) [16:29:11] <mru> nothing [16:29:13] <j0sh> lol [16:29:25] <BBB> congrats [16:29:26] <lu_zero> when ops feel the case the could +m the channel [16:29:36] <wbs> j0sh: gives you lot of chicks and street cred ;P [16:29:37] <lu_zero> but it's basically a nag-target [16:29:42] <BBB> j0sh: voice gives you a blinking yellow dot, which is a sign of awesomeness [16:29:56] <av500> my dot is green [16:30:02] <lu_zero> so people will message you if nobody replies [16:30:15] <BBB> lol @ street cred [16:31:04] <j0sh> haha sweet [16:32:14] <BBB> and feel free to start working on your soc proposal, yours is a little more complicated than that of others because you'll probably be working on multiple smaller tasks [16:32:16] <j0sh> wbs, i ran the patch through tools/patcheck... nothing came up, where was the trailing whitespace? i noticed some in rtpdec.c but that was already there [16:32:20] <BBB> so feel free to post it for discussion [16:32:32] <j0sh> BBB, will do [16:32:48] <BBB> grep \ $ libavformat/*.c [16:32:50] <mru> there is no trailing whitespace anywhere in ffmpeg [16:32:51] <BBB> reveals nothing [16:32:59] <BBB> so no trailing whitespace [16:33:04] <mru> we cleaned it all out [16:33:04] <BBB> and svn commit would blow up if you did, I think [16:33:06] <wbs> j0sh: somewhere in a multiline av_log() iirc [16:33:11] <mru> and made it impossible to add new [16:33:43] * mru wonders what trailing whitespace does in python [16:33:52] <BBB> Vitor1001: I promise I'll look at the dct/dst, but a bit swamped, so might not be today [16:34:58] <lu_zero> mru: should do nothing [16:35:37] <mru> yeah, I know... just taking frivolous stabs at python [16:35:52] * elenril has an autocmd in vim that highlights all trailing whitespace green [16:36:15] <elenril> thus making it impossible to miss [16:36:51] * mru rejoices at his ld_preload hack defeating the broken licence checker in armcc [16:37:14] <lu_zero> pff [16:37:47] <mru> every once in a while it would fail, complaining that the system clock had been set back [16:38:10] <mru> playing some tricks with gettimeofday fixed that [16:41:11] <av500> so now gettimeofday() returns it time in 1ns incrmenents each time? [16:42:10] <mru> actually I only added a small delay to each call [16:43:12] <mru> I have a valid licence so I don't need defeat that part [16:43:21] <mru> although I'm sure it would be easy if I tried [16:43:28] <av500> I guess so [16:43:38] <mru> they use flexlm [16:43:43] <mru> it's well-known how it works [16:44:04] <mru> not as easy to break as the ibm xlc protection of course [16:44:09] <mru> that one's laughable [16:44:10] <av500> still I miss a hackled matlab, most hacks seem to use licence keys [16:44:33] <mru> I used to have a matlab licence for some then-current version [16:44:40] <av500> same here [16:44:43] <mru> playing tricks with time syscalls made it last forever [16:51:00] <Vitor1001> BBB: sure, no problem [16:51:12] <Vitor1001> BBB: Just I forgot to tell you two details: [16:51:29] <Vitor1001> 1. You should init the dct with half the size you are using now [16:51:47] <Vitor1001> 2. The ugly 1 element shift will remain :( [16:54:01] <Vitor1001> that means a memmove() will be needed to preserve the alignment :p [16:54:47] <BBB> ok [16:55:34] <BBB> I don't quite know what I should replace what code with [16:55:37] <BBB> but I'll figure it out [16:55:50] <BBB> and doesn't the dct->dst take care of the shift? [16:55:56] <BBB> I thought that was the idea, at least [16:58:17] <Vitor1001> No, it is hard to get away with the shift :( [16:58:23] <Vitor1001> It does get away with the mirroring [16:58:29] <Vitor1001> redundant data is ugly [16:58:46] <Vitor1001> mirroring + RDFT == DCT [16:59:16] <Vitor1001> iRDFT of that + ignoring half of the data == DST [17:09:05] <thomasshirley> Hello folks [17:09:37] <thomasshirley> I was just wondering, if FFMpeg have any plans to support the Broadcom Crystal HD Card for decoding? [17:10:41] <kierank> iirc __gb__ is working on it [17:12:23] <thomasshirley> Thanks :) [17:12:56] <thomasshirley> Are there any development blogs for FFMpeg? [17:14:07] <av500> thomasshirley: see also: http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/104147/focus=104292 [17:16:58] <thomasshirley> av500: Thank you. [17:17:09] <thomasshirley> I was poking around the bug tracker to see if I could find anything, to no avail [17:50:17] <Dark_Shikari> my fucking god the h264 encoder patch is awful [17:50:20] <Dark_Shikari> it uses static buffers [17:50:27] <Dark_Shikari> declarations of values 3000 lines away from where they are used [17:50:34] <Dark_Shikari> massively unrolled functions via 5 levels of nested macros [17:50:40] <Dark_Shikari> for things that should be asm'd [17:50:47] <Dark_Shikari> hardcoded versions of existing lavc parameters [17:50:57] <Dark_Shikari> internal overridden versions of lavc parameters [17:51:10] <Dark_Shikari> thousands of lines of duplicated existing lavc code [17:51:59] <av500> so you mean it wont be acked right away? :) [17:52:02] <iive> is that some new patch? [17:52:14] <kshishkov> probably it's old H.264 encoder from Takis [17:52:49] <Dark_Shikari> I haven't even gotten to the actual encoder while reviewing it and its garbage [17:53:13] <kshishkov> yes, sounds familiar [18:11:06] <mru> av500: I updated my blog with a photo of the nexus display [18:12:31] <kshishkov> would Nokia 1110 qualify as smartphone? [18:12:58] <BBB> does it have a touchscreen? [18:13:01] <BBB> can it play video? [18:13:10] <BBB> do people gasp "wow" when they see it? [18:13:17] <kshishkov> no, because it's smart [18:13:21] <BBB> if 2 or more of these answer "yes", then "yes" [18:13:42] <kshishkov> but people sometimes gasp at my 64MB USB Flash drive [18:14:13] <mru> "New inverted black and white display with amber backlight" [18:14:16] <drv> at least better than those knockoff 4GB or whatever drives that are really smaller but with broken FAT :) [18:15:14] <kshishkov> mru: the only downside is when I was in Finland it was hard to tell whose phone is ringing [18:17:37] <kshishkov> BBB: about your question - I don't really work on anything right now [18:29:18] * elenril lols@h264enc [18:29:40] <elenril> x264 is DOOMed [18:30:04] <BBB> kshishkov: so I think I have some parts of the decoding functions specific to wvp2/wmvp data discovered [18:30:13] <BBB> kshishkov: might not be a big thing but anyway :) [18:31:09] <kshishkov> yes, there was at least prite header reading function [18:31:16] <kshishkov> *sprite [18:31:36] <kshishkov> and something for affine transform IIRC [18:33:54] <Dark_Shikari> there, I submitted a whole patch review of the h264 encoder [18:34:14] <Dark_Shikari> it's possibly the single worst encoder patch I've ever seen submitted [18:34:17] <kshishkov> worst. patch. ever. ? [18:34:25] <Dark_Shikari> I've seen worse patches I think [18:34:27] <Dark_Shikari> but not worse new encoders [18:34:44] <BBB> kshishkov: well, so in that decoder struct (the one of size 0x2430), 0x28 is is_wvp2 [18:35:00] <BBB> and function calls under the 0x28h conditional trace to the same function group as those of the sprite error decoding msgs [18:35:05] <Dark_Shikari> BBB: woot, wvp2 :) [18:35:06] <BBB> that's about as far as I got [18:35:39] <BBB> I still have to try and actually have the wmv3 decoder understand wmvp/wvp2, so I can look at the remainder of the unparsed data and see where this all fits in [18:36:03] <kshishkov> ok, good luck [18:36:12] <astrange> Dark_Shikari: who did you send it to? [18:36:20] <kshishkov> I'll try to help [18:38:06] <Dark_Shikari> what, did I accidentally forget to reply all? [18:38:14] <Dark_Shikari> no, I replied all [18:38:20] <mru> I'm reading it [18:38:33] * kshishkov has done reading it [18:38:59] <astrange> hmm. my email is broken since 10am [18:41:27] <BBB> kshishkov: I was hoping you'd mentor it for GSoC [18:42:02] <kshishkov> unlikely and I'm not a good mentor anyway [18:42:30] <BBB> wbs: cool! [18:42:35] <BBB> wbs: will review (yes really) [18:42:38] <wbs> BBB: :-) [18:42:40] <BBB> kshishkov: it's not like I am [18:42:52] <BBB> kshishkov: you'll need multiple mentors for RE tasks, imo [18:42:56] <BBB> kshishkov: you'd be a good co-mentor [18:52:28] <Dark_Shikari> so, mru, which is worse [18:52:32] <Dark_Shikari> h264 encoder or vorbis encoder [18:53:11] <kierank> what about mp2 encoder? [18:53:12] <kshishkov> just compile and test [18:53:31] <Dark_Shikari> the mp2 encoder was written by michael iirc [18:53:33] <Dark_Shikari> so it can't be that bad [18:54:34] <mru> mp2 encoder isn't the greatest but usually good enough [18:54:49] <elenril> wtf, running ff on a remote computer just opens a new window for a running ff on _this_ one [18:55:00] <elenril> is that supposed to be a feature [18:55:20] <mru> how's our wma encoder btw? [18:55:20] <kshishkov> of remote shell client [18:55:24] <Dark_Shikari> the h264 encoder seems to go by the logic that more code == better [18:55:30] <kshishkov> written by MN [18:55:35] <Dark_Shikari> aka paste paste paste paste patse [18:56:20] <mru> elenril: firefox uses X messages to tell a running one to open a new window [18:56:57] <mru> and fails miserably if you have multiple displays [18:57:13] * elenril facepalms [18:57:40] <elenril> oh well, ff sucks. nothing new here [18:59:04] * elenril wishes there was a good browser [18:59:15] <kshishkov> lynx! [18:59:45] <elenril> obvious troll is obvious =p [19:01:00] <Dark_Shikari> internet explorer [19:01:02] <Dark_Shikari> ;) [19:01:36] <kshishkov> ie5 ? [19:01:45] <elenril> yeah, right [19:01:57] <kierank> ie2 [19:02:02] <Dark_Shikari> netscape [19:02:22] <kierank> elenril: try dillo [19:02:27] <elenril> at least it didn't require so much ram [19:02:31] <kierank> that was probably the most pleasing browser i ever used [19:02:43] <kierank> when ssl and cookies weren't needed [19:02:45] <Dark_Shikari> it required less ram because Yahoo wasn't a 1.5 megabyte site [19:02:46] <Dark_Shikari> filled with css and javascript and flash [19:03:03] <ShadowJK> 1.5M sounds low [19:03:23] * ShadowJK has seen 5meg .js files part of banner ads [19:05:46] <wbs> j0sh: btw, how did you do the tests with gst-rtsp? [19:06:38] <j0sh> wbs, i just compiled it and ran the test-ogg example [19:07:15] <wbs> ah, it's a completely separate project - that explains why I didn't see it in any repo [19:08:13] <j0sh> wbs, yeah, iirc, it took me a while to track down too... sorry about that [19:08:36] <j0sh> i couldnt figure out the gstreamer commands so this was easier [19:09:46] <j0sh> commented out the audio command though since that was giving me trouble, should be one line in the test-ogg main function [19:10:12] <j0sh> in g_strdup_printf, that is [19:10:35] <wbs> j0sh: ah, so this is more or less at the proof of concept stage yet, right? [19:10:56] <j0sh> what is? the gst-rtsp server? yeah, i think so [19:10:58] <wbs> gst-rtsp that is [19:12:43] <j0sh> wbs, but you can still use its theora packetizer with plain gstreamer, i think. its just that the fmtp is really convoluted since xiph also encodes the setup info in the sdp [19:13:23] <wbs> j0sh: yeah, but using plain packetizers usually is quite painful to set up compared to wrapping in the sdp and everything in rtsp [19:13:56] <wbs> lu_zero: btw, does feng support sending to the server (as in what the rtsp muxer in lavf does)? [19:14:33] <j0sh> wbs, the theora draft makes a remark about the possibility of the (fmtp) setup info being fragmented beyond the MTU since there is so much data, does ffmpeg rtsp handle that? [19:14:42] <astrange> oops, ithinksw.com expired. wonder when the guy who owns it will get out of bed [19:15:37] <wbs> j0sh: yeah, I think so, as long as it fits in the statically sized buffers along the way [19:17:29] <sander> Does anyone know a semi-generic way of parsing error messages from ffmpeg? [19:17:58] <mru> using eyes [19:18:20] <sander> I'm going to write an opensource ffmpeg wrapper.. [19:18:35] <sander> *on my way doing so* [19:18:52] <sander> So I need to parse it with a script. [19:18:54] <Dark_Shikari> aren't there already a few dozen of those? [19:19:05] <mru> s/dozen/thousand/ [19:19:08] <sander> Dark_Shikari, is it.. :-D [19:19:11] <Dark_Shikari> (though if you're looking to make something that Automatically Does The Right Thing for, say, a web video site, that would be VERY WELCOME) [19:19:15] <sander> any good ones? [19:19:15] <Dark_Shikari> because there is none that doesn't suck for that [19:19:29] <Dark_Shikari> and I have even written up specs for them [19:20:47] <sander> We're going to write a generic tool to encode video's uploaded from ftp/webdav/php.. with a php admin interface. [19:21:08] <sander> Dark_Shikari, cool. Can I get those specs? :-) [19:21:23] <Dark_Shikari> then I can send you my 15 minute spec [19:21:43] <Dark_Shikari> email? [19:21:43] <jai> hmm, anyone here have access to itu specs? possibly at work etc... [19:21:52] <Dark_Shikari> jai: many are free. which one do you want? [19:21:55] <peloverde> which spec? [19:22:02] <jai> Dark_Shikari: jpeg xr conformance vectors [19:22:27] <Dark_Shikari> also, sander, note that I worked on a significant part of facebook's system for doing exactly this [19:22:38] <Dark_Shikari> theirs was quite fancy [19:22:39] <jai> T.832 to be precise [19:22:49] <sander> Dark_Shikari, nice! :-) [19:22:53] <jai> i have a pre-pub copy [19:23:17] <jai> and FCD of the test vectors, but wanted to see if anything changed since [19:23:35] <peloverde> http://www.itu.int/net/itu-t/sigdb/speimage/ImageForm-s.aspx?val=10100834 [19:23:57] <peloverde> whoops that's T.834 [19:23:57] <BBB> too ... many ... patches [19:24:06] <sander> I whould also love to get some ffmpeg wrapper, to be able to parse error logs in a good way(thats the main part which is missing to my ffmpeg integration. [19:24:57] <peloverde> jai, T.832 seems to be actual JPEG XR and not conformance [19:25:16] <sander> Dark_Shikari, pm. [19:25:20] <jai> peloverde: yep, core coding specification [19:25:43] <jai> peloverde: i already got the test suite from http://ftp3.itu.int/pub/t/testsignal/SpeImage/T834/v2010_01/ btw [19:25:52] <Dark_Shikari> sander: already sent it [19:26:03] <peloverde> so you need the core coding specification not the conformance vectors? [19:26:17] <kierank> [19:22] <@jai> hmm, anyone here have access to itu specs? possibly at work etc... --> yes [19:26:50] <peloverde> <Dark_Shikari> jai: many are free. which one do you want? <jai> Dark_Shikari: jpeg xr conformance vectors [19:26:54] <jai> peloverde: yeah, and if the vectors have since been updated then those as well [19:27:07] <sander> I was thinking about detecing errors like: Unknown error, Unsupported audio codec, Unsupported video codec, This video cannot be encoded in this format, Wrong settings for audio, Wrong settings for video, Cannot retrieve info from this video, Not a video file, Unsupported video container, The audio can’t be resampled, [19:27:22] <Dark_Shikari> and "Segmentation Fault" [19:27:23] * Dark_Shikari runs [19:27:41] <sander> ..But I guess it can be simplified abit.. [19:28:38] <sander> I guess I can check the lenght of the output video, to determine of the video was encoded properly.. [19:28:58] <sander> But if sound isn't working.. Then the lenght might still be correct. [19:29:12] <sander> By length, I mean time in seconds. [19:29:18] <Dark_Shikari> there are plenty of issues you can't detect, like a/v desync [19:29:29] <Dark_Shikari> well, you could try. that might be possible if you have the original file [19:29:33] <Dark_Shikari> and a player that plays it correctly [19:32:10] <sander> Dark_Shikari, my approach is to create a command eg. "ffmpeg-batch".. which takes a bunch of dirs and or files.. and searches for config files with ffmpeg parameters in the directory(s).. [19:32:38] <sander> ..and encodes each files based upon that/those config files. [19:35:03] <sander> Dark_Shikari, I already have a python script to find the resolution which should be the best multiplum of 16, and not higher than x/y. [19:35:57] <astrange> x264 doesn't need to encode to multiples of 16 [19:36:24] <astrange> nor does ffmpeg really (the penalty is a bit worse but it's still not bad) [19:37:09] <sander> I'm thinking about supporting many diffrent formats which is known to work for diffrent devices. [19:40:05] <justlooking> http://en.wikipedia.org/wiki/List_of_common_resolutions [19:48:57] <_av500_> [19:51:02] * elenril agrees with _av500_ [20:19:39] <CIA-24> ffmpeg: michael * r22637 /trunk/libavformat/img2.c: Dont senselessly fail on rawvideo that isnt 3 files per frame. [20:27:40] <Kovensky> <@ramiro> Kovensky: have you ever tried mplayer with mingw-w64? <-- last time I tried I got stuck on compiling on several places [20:27:50] <Kovensky> mostly because mplayer's configure didn't notice my triplet was mingw at all >_> [20:28:04] <Kovensky> x86_64-w64-mingw32 [20:45:16] <lu_zero> BBB: I got another strange situation about networking ^^ [20:54:35] <BBB> ok [20:54:37] <BBB> ask :) [20:58:09] <sander> justlooking, Do you have a list of formats and they're coresponding ffmpeg parameters? [21:01:34] <ramiro> sander: do you have any work done on dshow input? [21:05:06] <sander> ramiro, I've never used dshow [21:07:08] <sander> astrange, The python script also tried to keep the diffrence between with/hight when scaling down a video. [21:13:24] <CIA-24> ffmpeg: michael * r22638 /trunk/libavcodec/ffv1.c: [21:13:24] <CIA-24> ffmpeg: Disallow VLC coding with more than 8 bits as there are several bugs [21:13:24] <CIA-24> ffmpeg: in that code that could lead to broken files. [21:13:24] <CIA-24> ffmpeg: AC coding is unaffected. [21:13:42] <Dark_Shikari> \o/ [21:15:43] <ramiro> sander: hmm, I think I've mistaken you for sancode =) [21:17:03] <sander> Dark_Shikari, is it any point in setting the aspect ratio when width/height is set? [21:18:17] <Dark_Shikari> to force it to 1:1 PAR [21:18:44] <sander> Dark_Shikari, why force it to 1:1 PAR?.. [21:19:37] <Dark_Shikari> because you already calculated the size making that assumption [21:19:41] <Dark_Shikari> and for web video you generally want 1:1 PAR [21:21:15] <sander> I think I want to keep the aspect ratio as original video.. so the video wont be strethed [21:21:26] <Dark_Shikari> er [21:21:30] <Dark_Shikari> where did I ever say you would stretch the video? [21:21:34] <Dark_Shikari> I said PAR, not DAR [21:21:40] <Dark_Shikari> DAR is of course the same [21:21:57] <sander> Sorry. i'm not that familar with those terms, i'll read up on it. [21:22:06] <Dark_Shikari> pixel aspect ratio [21:22:09] <Dark_Shikari> display aspect ratio [21:24:25] <sander> So because pixels dont have same hight as width.. an DAR of 4:3 will have PAR of 1? [21:24:54] <sander> ..That might be wrong to day.. [21:25:04] <Dark_Shikari> DAR of 4:3 may or may not have PAR of 1:1 [21:33:21] <sander> justlooking, Think i'll limit it to popular formats.. maybe 10-20 diffrent ones. [21:59:29] <CIA-24> ffmpeg: jbr * r22639 /trunk/libavformat/ (flacenc.c Makefile flacenc.h): [21:59:29] <CIA-24> ffmpeg: Move ff_flac_write_header() to flacenc.h, which removes the Matroska muxer's [21:59:29] <CIA-24> ffmpeg: dependency on flacenc.o and fixes the unnecessary dependency on vorbiscomment.o. [22:58:41] <Compn> Dark_Shikari : you reviewed the h264 encoder to look for optimizations ? hehe [22:58:54] <Compn> good review tho [23:06:18] <Dark_Shikari> optimizations? hahahahahahahahahaha [23:06:36] * mru thinks he was just looking for a laugh [23:35:10] <mru> http://daringfireball.net/2010/03/gif_h264_patents

1 0

IRC log for 2010-03-21
by irc＠mansr.com 22 Mar '10

22 Mar '10

[00:23:51] <Kovensky> <+twnqx> ok, blender doesn't die to ctrl-c <-- ctrl-\ ? [04:39:49] <ohsix> how fraught with peril is making these changes larger, 128 or more http://trac.perian.org/browser/trunk/Patches/ffmpeg-larger-internal-buffer.… [04:40:14] <ohsix> gstreamer isn't releasing frames so i've got all sorts of shit that eventually and without fail will abort [04:51:17] <astrange> it only uses more memory [04:51:26] <astrange> and it might fail no matter what size it is [04:56:58] <ohsix> k cool, yea it kept doing it on the same videos as i increased it, it just pushed the crashes out [04:57:44] <astrange> i don't like that patch myself, but i honestly can't understand how perian's lavc interface works in the slightest [04:58:08] <astrange> i'll probably rewrite it sometime and hopefully that won't be necessary afterwards [05:11:59] <ohsix> gst is just holding outstanding frames, i'm not qualified to really look into why; it staggers their release, they eventually make it out in bursts of 15, 16 frames, but it eventually gets far enough behind to abort [09:24:54] <CIA-30> ffmpeg: diego * r22613 /trunk/libavdevice/bktr.c: [09:24:54] <CIA-30> ffmpeg: Revert removal of _NETBSD_SOURCE definition. [09:24:54] <CIA-30> ffmpeg: It is indeed necessary to compile on NetBSD. [10:26:59] <CIA-30> ffmpeg: kostya * r22614 /trunk/libavcodec/bink.c: fix minor typo [11:04:42] <J_Darnley> Damn, I just found a compiling bug that is my fault! [11:08:59] * iive gives a bottle of cola to J_Darnley [11:24:51] <CIA-30> ffmpeg: vitor * r22615 /trunk/libavcodec/fft.h: DCT: remove unused field from context [11:29:32] <CIA-30> ffmpeg: vitor * r22616 /trunk/libavcodec/dct.c: Cosmetics: move ff_dct_init() to the bottom of the file [11:32:01] <CIA-30> ffmpeg: vitor * r22617 /trunk/libavcodec/ (fft.h dct.c): [11:32:01] <CIA-30> ffmpeg: Call DCT by function pointer. Needed for any future ASM implementation and [11:32:01] <CIA-30> ffmpeg: allows further cleanup. [11:35:55] <CIA-30> ffmpeg: vitor * r22618 /trunk/libavcodec/dct.c: Split DCT-II and DCT-III in different functions, they do not share any code. [11:37:04] <CIA-30> ffmpeg: vitor * r22619 /trunk/libavcodec/dct.c: Reindent after r22618. [13:56:32] <J_Darnley> Wow, doing things correctly makes them much cleaner! [13:58:38] <J_Darnley> No need to add stuff to lavc... [13:58:52] <J_Darnley> No need to detect which encoder... [14:28:27] <J_Darnley> elenril: There is a present for you on the mailing list [14:29:43] <elenril> w00tness! [14:30:21] * elenril waits six months until it's approved [14:41:54] <KotH> is anyone here interested in giving a lesson on how to write c code? [14:41:59] <KotH> our company needs one [14:42:17] * KotH will go bonkers if he continues to read such code [14:42:23] <Dark_Shikari> lol [14:44:02] * KotH just stumbled over a if(bitmask&1){ do_something_with(1)}; if(bitmask&2){do_the_same_with(2)}; ... [14:44:22] * KotH wonders whether the guy who wrote it was a datatypist or an engineer [14:44:37] <Dark_Shikari> what's so bad about that? [14:44:40] <CIA-30> ffmpeg: reimar * r22620 /trunk/libavcodec/ (dvdata.h dv.c dv_vlc_data.h): [14:44:40] <CIA-30> ffmpeg: Split VLC-related tables out of dvdata.h to make it easier to add support [14:44:40] <CIA-30> ffmpeg: for hard-coding tables. [14:44:48] <Dark_Shikari> if it went on to 4 and 8 I'd write a loop, sure [14:45:00] <KotH> it goes on until 256 [14:45:03] <Dark_Shikari> LOL [14:45:07] <Dark_Shikari> ok, that's hilarious [14:45:45] <KotH> i'd write a loop even if it was for two values, just to avoid code dublication... [14:45:59] <Dark_Shikari> if it's just a function call, I wouldn't [14:47:22] <CIA-30> ffmpeg: reimar * r22621 /trunk/libavcodec/ (tableprint.c tableprint.h): [14:47:22] <CIA-30> ffmpeg: Extend and move macros to create table printing functions to header. [14:47:22] <CIA-30> ffmpeg: Simplifies creating custom functions for printing DV VLC-related tables. [14:47:32] <KotH> ah.. the joys of thrid party code.... struct blah { uint32 reg1; uint32 reg2; ... uint32 reg8}; [14:48:12] * KotH blames the mexican hired by atmel for this one [14:51:04] <ramiro> KotH: if do_something_with() is static inline gcc might optimize if you call it with 1, 2, etc... it won't if you call it with a variable. [14:51:18] <Dark_Shikari> true, I've unrolled those sorts of things at times [14:52:31] <KotH> actually, do_something is not a function but some arithmetic operations and accessing registers [14:53:15] <ramiro> Dark_Shikari: I've asked a question yesterday but I don't think you were around. why would gcc - then + rsp here: http://ffmpeg.pastebin.com/9hGE8wkQ [14:54:04] <Dark_Shikari> because it's gcc [14:54:40] <ramiro> ok, good, that's what I thought =) [14:54:52] <Dark_Shikari> notice some other things wrong with the code [14:54:57] <Dark_Shikari> it should really have done: [14:55:04] <Dark_Shikari> add eax, edx [14:55:07] <Dark_Shikari> add eax, ecx [14:55:11] <Dark_Shikari> i.e. two instructions [14:55:18] <Dark_Shikari> try with a newer gcc maybe. [14:55:50] <ramiro> it's 4.4.2. what's wrong with using lea here? [14:56:04] <Dark_Shikari> pointless. no gain, extra instruction size [14:56:25] <Dark_Shikari> gcc 3.4 on cygwin Does The Right Thing [14:56:38] <Dark_Shikari> on x86_32 [14:56:57] <Dark_Shikari> the lea mess is probably because of gcc being stupid on x86_64 [14:58:34] <ramiro> gcc 4.4.2 on mingw32 uses add too. [14:58:46] <Dark_Shikari> which means it's an x86_64 suckage issue. [15:48:29] <jre2> what's the policy on submitting patches? would it be easier just to alert someone to a trivial (1 line) typo? [15:48:39] <Dark_Shikari> I meant mention the typo [15:48:41] <Dark_Shikari> not the question [15:48:43] <Dark_Shikari> >_> [15:49:55] <Compn> jre2 : much easier to mention the typo [15:49:58] <jre2> libavformat/asf.c:138 has a typo. '"album "' should be '"album"' [15:50:55] <jre2> someone submitted a patch to indent everything nicely and I assume accidently added that [15:56:00] <elenril> lol [15:56:06] * elenril blames himself [16:04:39] <CIA-30> ffmpeg: reimar * r22622 /trunk/libavcodec/ (dv.c dv_tablegen.c Makefile dv_tablegen.h): Add support for hard-coding the 256kB large dv_vlc_map table. [16:16:59] <KotH> wtf? 256kb?? [16:17:48] <Dark_Shikari> I have no idea why anyone would want to hardcode that [16:18:01] <KotH> embedded systems [16:18:17] <KotH> most times you've more than enough flash, but hardly enough ram [16:19:17] <Compn> ffmpeg: friend to arm and x86 alike [16:20:32] * KotH speaks friend and enters [16:22:05] * elenril remembers http://xkcd.com/424/ [16:29:58] <CIA-30> ffmpeg: reimar * r22623 /trunk/libavcodec/tableprint.c: [16:29:58] <CIA-30> ffmpeg: Do not use puts, it adds additional newlines making the generated files [16:29:58] <CIA-30> ffmpeg: needlessly ugly. [16:34:51] <CIA-30> ffmpeg: stefano * r22624 /trunk/libavcodec/g729dec.c: [16:34:51] <CIA-30> ffmpeg: Make g729dec.c:decode_frame() return AVERROR_INVALIDDATA rather than [16:34:51] <CIA-30> ffmpeg: AVERROR_NOFMT in case of invalid / unknown packet size. [16:34:53] <CIA-30> ffmpeg: stefano * r22625 /trunk/libavformat/utils.c: [16:34:53] <CIA-30> ffmpeg: Make av_open_input_file() return AVERROR_INVALIDDATA rather than [16:34:53] <CIA-30> ffmpeg: AVERROR_NOFMT if the format is unknown / cannot be recognized. [16:34:53] <CIA-30> ffmpeg: It is returned AVERROR_INVALIDDATA, in the sense that the data is [16:34:53] <CIA-30> ffmpeg: invalid within what the specific libav* binary supports. [16:34:54] <CIA-30> ffmpeg: That was the last remaining use of AVERROR_NOFMT, which is going to be [16:34:54] <CIA-30> ffmpeg: dropped at the next libavutil major bump. [16:34:55] <CIA-30> ffmpeg: stefano * r22626 /trunk/libavutil/error.h: Drop AVERROR_NOFMT at the next libavutil major bump. [17:10:07] <macman_> hello ..do we report problems here ? [17:10:20] <macman_> maybe bugs ? [17:13:55] <macman_> [mpeg @ 0x9d113d0]max_analyze_duration reached < -- is this something i have to worry about ? [17:14:04] <kshishkov> no [17:14:31] <macman_> let me throw my real problem out ok [17:14:58] <macman_> http://pastie.org/879808 < -- here is my full movie output [17:15:12] <macman_> this is the command i use .. i will be padding it [17:18:28] <macman_> http://pastie.org/879813 < -- the only way i get this to work is to do -target ntsc-dvd .. i haven't had this issue in the past but i have been having this issue and i can't do anything .. i try -ac 2 or -ac 6 or even -acodec ac3 -ar 48000 -ab 444 or even -acodec libmp3lame -ar 44100 -ab 192k [17:18:38] <macman_> regardless i get same output .. i think its a bug [17:19:09] * elenril points to topic [17:20:48] <macman_> i thought we submit bugs and stuff here ? [17:20:52] <kshishkov> make sure all those options are placed before output file name [17:21:09] <macman_> of course they are kshishkov [17:21:19] <macman_> kshishkov: output is at the end [17:21:28] <kshishkov> I mean -ac 2 [17:21:35] <macman_> yes before output [17:22:13] <kshishkov> then it should generate different messages than pasted [17:23:08] <macman_> if you don't mind looking one more time here is output of final with -ac 2 http://pastie.org/879823 [17:24:08] <kshishkov> it seems to recode [17:28:31] <macman_> takes forever but yes [17:52:08] <elenril> http://games.slashdot.org/story/10/03/21/1552221/Switzerland-Passes-Violent… o_0 [17:56:24] <kshishkov> it would be worse if they prohibit downloading violent games with torrents. Who cares about sales/distribution? [18:07:47] <CIA-30> ffmpeg: jbr * r22627 /trunk/libavformat/Makefile: [18:07:47] <CIA-30> ffmpeg: Fix FLAC demuxer dependencies. [18:07:47] <CIA-30> ffmpeg: Patch by James Darnley <james darnley at gmail> [18:21:59] * Compn wonders what video games KotH plays [18:22:00] <Compn> ehe [18:22:50] <KotH> the first one i played was called something like debug.exe ;-) [18:24:15] <KotH> but why are you asking? [18:26:29] <Compn> elenril's link about switz banning of violent video games [18:27:18] <KotH> ah.. [18:27:33] <KotH> yeah.. another law we got from the big canton in the north... [18:27:47] <kshishkov> debug.exe was violent - with all that poking around [18:48:20] <jai> wasnt that debug.com? [18:52:37] <kshishkov> maybe in older DOSes where it was smaller [22:24:27] <CIA-30> ffmpeg: michael * r22628 /trunk/libavcodec/h264_sei.c: [22:24:27] <CIA-30> ffmpeg: Ignore x264 build=0 as there is no such version, this restores previous [22:24:27] <CIA-30> ffmpeg: behavior approximately.

1 0